Preparing For Success: Early Planning For Large Healthcare IT Projects
Introduction
Serious issues in large healthcare information technology (HCIT) projects are never in short supply. Negative patient impacts, substantial revenue shortfalls, leadership turmoil: the consequences can be serious and prolonged. At the very least, they cost time, attention, and focus at moments when all three are in short supply.
But it’s not that nobody is trying to avoid trouble. In fact, there’s a large team of highly skilled individuals working to avoid just these issues. Nor, in most cases, is the issue one of basic competence or drive. The people working on these projects are often the most seasoned clinicians and managers in the organization, and they have a deep desire to make their organization better. Why, then, does it happen that the projects encounter so many problems, both during and after implementation?
As often than not, the problems arise from simple challenges in project management: fixing scope, handling unavoidable issues, and keeping on target for a successful go-live. And, in our experience, critical failures frequently happen early, in the pre-implementation planning that could have set the stage for success. Nor, to be frank, are these failures unpredictable. In fact, they often come down to a small set of seemingly obvious tasks that are ignored or neglected at the wrong moments.
Failure 1: Wasting the “early time”.
Approval for a new IT project, especially a very large one, is a prolonged and uncertain task. At the outset, those who see the need must create a case, establish a rough budget and timeline, and secure approval at every level. It takes months, and during that time the organization itself is often “frozen” – anticipating new changes but unwilling to plan for them.
In fact, though, this early phase is a tremendous opportunity. While resources (particularly budget) are often scarce, the “pause” at the start can be exploited to identify stakeholders, collect concerns and issues, and document the current state of the organization. This work is frequently done in any event, during technology selection or other decision-making phases. The degree to which these critical activities can be continued during the approval phase, and the degree to which they fold seamlessly into project planning are key drivers for the success of the overall effort.
Even more than that, the “early time” activities help to weld the project sponsorship and champions together. This is the exciting time in a project: broad horizons, uncertain staffing, unclear roles, but a shared sense of doing something transformative. To the extent that project management can unite that entrepreneurial moment with actual work to be done, the project will benefit hugely.
Failure 2: Not assessing current state.
Closely related to the “early time” task challenge is the paired risk of failing to assess the state of the organization prior to implementing the new system. We frequently hear “our systems are just a mess”, or “we’re throwing it all away”. So why would we want to wallow in an examination of the unsatisfactory present rather than looking to the bright future?
Unfortunately, IT implementations never happen in a vacuum. Few new hospitals are being built, and even fewer are built with an open selection of software. In the vast majority of cases, one technology suite is replacing another, or is replacing finely tuned paper processes that have existed for years. With that situation comes the simple fact that change management will be a primary task of the project. And change management requires a baseline.
Understanding the baseline state of the organization is a non-trivial task, arduous at best and unending at worst. The larger the organization, the more likely that there are areas of significant variability, dysfunction, or alternative practices. Not all variability is bad, and there is no one functional style that is the best, but differences add to the scope of the project. And missed scope that comes from missed current-state analysis is an incredibly common cause of project failure. A thorough current-state analysis is the best insurance possible against last-minute surprises.
Failure 3: Unclear or incomplete planning after contracting but prior to kickoff
When a project “kicks off” – when the team begins the organized activities that define, configure, and test the software prior to go-live – the project plan must be fully fleshed. MedSys Group has seen many projects struggle because the project plan was simply not completed.
Key documents – project charters, timelines, governance structures, budgets, staffing matrixes, and communications structures – should be done well and approved broadly. Decision-making templates need to be tested and evaluated, and processes for input need to be practiced. The pre-kickoff time is an excellent opportunity to set and practice meeting structures, risk management activities, and status reporting. While none of these replace actually doing the project work, practice and refinement in these areas will pay off many times over when the work is at hand.
Even more critically, these early activities help to educate and prepare the project team. When the building, testing, and training kick into high gear, there is a necessary time when teams work in parallel silos, counting on other teams to do the same. Management oversight helps to coordinate this work, of course, and planning helps, but the more that teams can review the work to be done and be comfortable with the overall plan before the heavy lifting starts, the less likely that the project will see unexpected discrepancies and delays.
Failure 4: Failure to establish effective governance
No large IT project proceeds without change. New scope, unexpected organizational change, new regulatory or financial requirements, staff turnover – all of these and more will happen in the months following kick-off. Consequential decisions will need to be made, and organizational buy-in to those decisions is critical.
The early planning for a project must include establishment of effective governance. Governance for a project must not only arrive at good decisions, but it must include methods to ensure that those decisions are effective, well-documented, and trusted. These things are not automatic.
Effective IT decision-making means that not only are the IT questions answered, but the decision is endorsed by the operational and clinical leaders who have the authority to enact the needed organizational change. That is, the people sitting at the table making the IT decisions need to be the people who will then tell their doctors, nurses, and staff to carry out the new plan. Critical failures of effective governance occur when technologists make (or are thought to make) decisions in a vacuum that either cannot or will not be supported operationally.
Closely coupled to this is the documentation of decisions. When a choice is made, particularly if it changes a previous stance, the documentation must clearly explain the decision. Communication must be broad and transparent so that the inevitable “chatter” about change can focus on facts, not rumors. Our experience is also that the more that the rationale for the decision is part of the overall documentation, the more likely it is that the decision will be well understood and carried out in the years that follow implementation.
The final area of danger in governance is trust. Every organization is different in its people and its politics. This inevitable fact of life means that every organization arrives at confidence in the decisions of its leaders differently. A governance plan for a major IT initiative must take into account these issues and match the decision-making style of the organization to the decision-making style of the project. Thoughtful planning of the committees, authorities, and executive scope will produce great dividends.
Failure 5: Failure to anticipate failure
In large healthcare IT projects, there is no perfect implementation. People make mistakes, technology turns out to be inadequate, and surprises are around every corner. The complexity and cost of these projects, not to mention their huge cost and tight timeframes, means that there will be failures – challenges that threaten the project. Project plans that ignore this reality turn small issues into large ones, and large ones into organizational legends.
Anticipating failure in the project plan means considering every step, understanding the risks involved, and building mitigations into the project structure. These can be as simple as ensuring adequate contingency dollars or as complex as requiring every key leader to have an “understudy” who can take over in the case of incapacity. Allowing for date flexibility, ensuring time after testing for fixes and updates, and ensuring that additional staff are available at key times are all measures that should be considered.
A final measure to consider in this area is to make a practice of documenting failures. Calling them “lessons learned” may reduce the sting, but the mistakes made and the information thus gleaned are crucial assets produced by well-run projects. Planning for this and ensuring its execution can create surprising value to an organization.
Conclusion:
Large HCIT implementations will have challenges. Recognizing this fact at the outset, and planning for the challenges as well as the successes, reduces costs, risks, and delays. The best people in the world – smart, caring, and highly educated – need structure and process to work at their peak. Proper planning sets the stage for success.
