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.