Dena Somers, a consultant with the Pittsburgh-based Aspen Advisors, has spent 15 years consulting with hospitals and health systems in a wide variety of areas, specializing in planning large-scale IT implementations, process improvement activities, operational improvement activities. The Denver-based Somers has a technical background in health information management. Recently, she spoke with HCI Editor-in-Chief Mark Hagland about her experience in working with a large, multi-hospital system in the West, as that organization’s executive, clinician, and IT leaders prepared to go live with a revenue cycle implementation from a major IT vendor. The challenges included the complexity of the organization and its processes, the very large number of end-users being trained on the new applications, and some technical problems that were being uncovered at the last minute. Below, please find excerpts from that interview.
Please tell us a bit about the background of this consulting engagement.
It took place in the summer of 2010, and it was 90 days prior to their scheduled go-live date with an enterprise-wide revenue cycle management solution, in a large, complex multi-hospital system.
You were engaged to do the planning?
I was engaged to assess their readiness to execute on their go-live schedule. They were way into the project, and scheduled to go live in 90 days, and they wanted an independent assessment of their readiness to go live.
Is that common?
I’ve seen other organizations do that, but usually much earlier in the project planning. I think I was brought in because the CIO knew me, and there were concerns about their actual ability to go live.
So you went in and met with stakeholders?
Correct. So the approach to this was to review documents, for example, the most current status reports, the most current issues lists, documents around their go-live plan, any documents to prepare for this, so any document review that would give me a sense of how they were tracking, to have everything ready for go-live. The second part of this was to interview the stakeholders and to sit in on some of their more strategic, high-level project meetings.
How long were you in that phase?
The entire engagement was only a couple of weeks.
What did you basically find?
There was one key area that was really concerning, and that is that their integrated testing was not complete. The testing to make sure that the system functioned as designed, that it matched the operational workflows, that the interfaces were all working properly—the basic thing you’re testing for is, are the charges coming through, and are you going to produce an accurate bill from which you can get paid—and until you can complete that testing, you can’t go forward. When I came in, they were a full month behind, and this was on their critical path.
So what did you determine?
They had struggled, because they had had several different testing coordinators, each of whom had had a different approach to doing it. So they had already recognized that that was a problem, and had put in one of their senior leaders to run it. So that particular executive had said, and I supported it—that the way she designed this was the way this would be done. In others, the key to making this happen was to conclude all the discussions and all the churning that had taken place around the approach to this go-live, and to buckle down and get it done. They were dithering about the approach, because they had had a number of leaders involved, none of whom was a senior leader. So the root cause was the lack of senior leadership involvement at that phase of the project.
You so validated one leader’s approach and said, we have to go with this?
That’s right. They needed to adhere to their plan, lock down their scope, enforce strict change control, and again, run it under the direction of a senior IT leader. She was at the director level in IT, a director of business applications or similar title.
Did everything go smoothly once that was untangled?
Again, my engagement was to do an assessment and tell them what to do. And they did go live. But another element was that they were continuing to do a lot of new development, and the direction there was, you’re going to have to do this later.
What kinds of new development were being executed?
They had a lot of programming changes they were going to implement to accommodate workflow issues at the academic medical center. They were “nice-to-haves,” but really, it was important to focus on the go-live and put these nice-to-haves in the future optimization plan.
What kinds of takeaways would you offer from this situation?
The first one is that at a key point in a project—and that point will vary depending on the size and complexity of the project—there’s a key point at which you have to recognize that it’s no longer business as usual. The lesson learned is that at a critical point in the project, you have to switch from business-as-usual to a sense of critical urgency. You need firm deadlines for action. That was the biggest takeaway; they just kept acting like there was more time, and there wasn’t.
I think the other one, which is probably an overarching kind of thing, and that is to start thinking about what your go-no-go criteria are early on, and continue to keep that in front of you. They actually had that, but weren’t treating the red items with that sense of urgency.
How do you balance that dynamic tension between moving too slowly or too quickly, in terms of getting stakeholder buy-in?
That really is how this client ended up where they were; they kept adding to the scope and still trying to get to the perfect. I think it has to do with building strong plan; I think the other piece is the governance, so that when you get to that point—because that’s what ultimately happened to this project, it was me saying, if you keep doing what you’re doing, you won’t go live, and the executive suite said, we’re going to do something different. So it means planning for both, but when you’re faced with competing priorities, you need to have the governance in place to make things happen. That’s actually what pulled them through in this case.
Based on this experience and others in this area, what advice would you like to share with CIOs and other healthcare IT leaders?
When I look back at organizations that tend to do better than others at this kind of thing, they’re organizations in which the CIO has good leadership under them, because they can’t possibly be on top of everything. So they need to delegate, but they need strong people to delegate to. The CIOs who don’t do as well either try to micromanage, or they try to delegate to someone, but the person to whom they delegate doesn’t have the position in the organization to make it work. You need a solid IT leadership and a solid organizational leadership structure, with the two working in partnership.
