How to Organize
"Preparedness prevents peril." - Chinese proverb
"Be prepared." - Boy Scout motto
"I have a plan!" - Dr. Strangelove
A fundamental principle of project management is that the more complex the project, the more detailed the plan for mitigating risk. Transforming a health care organization to more integrated, technology-enabled, cost-competitive clinical processes is a complex and risky endeavor. Yet, the wreckage of over-budget and delayed IT implementations throughout the health care industry makes the case for proper planning at the onset of these projects. Often, organizations fail to appreciate just how vast and complicated a clinical transformation project is. Sometimes, a sense of urgency to cut to the chase can give short shrift to the planning process. Perhaps it's the perception that planning isn't really taking action. After all, when the government commissions a study, we don't expect decisive action anytime soon. To the cynic, planning connotes inaction or even procrastination.
In reality, project planning is essential to project success. Far from a passive endeavor, planning is a time for the most active and talented people to focus their multiple fields of expertise on a plan that will guide the project through system implementation and beyond. The considerable time and effort spent planning and organizing a clinical transformation are well invested. Measured against the very real risk of failing at a mission-critical initiative, an implementation team soon realizes that project planning pays off handsomely.
One health care system, for example, took the time up front to identify the right staff to participate in the implementation and then trained them to use the chosen products so that they knew the functionality and capabilities of the applications before the project began. This organization also identified the skills that were essential to the project's success and interviewed consultants and IT vendors to acquire those skills. They insisted on the right to exclude from the project any personnel proffered by vendors who didn't bring to the table desired attitudes or skills. This organization invested in meticulous pre-implementation planning. It should come as no surprise that the subsequent implementation was a recognized success.
Fast or Right?
The philosophy behind project planning is that doing it fast is less important than doing it right. By the time a clinical information system goes live, a methodical approach to project planning always proves its worth by assuring a product that's well worth the investment in time and money. While there are legitimate, methodical ways to accelerate a project's timeline, these methods must not cut short the necessary steps of planning or stakeholder involvement.
Plan the Work to Work the Plan
A proper project plan will provide a level of detail that is appropriate for the work that needs to be done. It will keep everyone involved in the implementation focused on what needs to be done — and not distracted by features or functions that are beyond the scope of the project. How much planning is enough? More than what's required for an average construction project. A useful rule-of-thumb estimate is that approximately ten percent of the duration of the overall clinical transformation should be devoted to detailed project planning. It is not uncommon for IT vendors writing proposals for systems that will cost upwards of $50 million, and will occupy implementation teams of hundreds of people for several years to schedule just a few short weeks for intensive planning. Such an approach fails to appreciate the magnitude of complexity that a proper implementation plan must address.
A project plan must set up an infrastructure for the implementation and develop the wide-ranging sponsorship that assures the system will be adopted by physicians, clinicians, and others throughout the enterprise. An incomplete or sloppy plan can multiply many-fold the unpredictability and risks associated with a project as complex as implementing an advanced clinical information system. A lack of planning will undoubtedly lead to overruns and delays over the course of the project. Proper planning will never fully eliminate delays or overruns, but it will minimize these factors.
Charters and Work Plans
The project charter provides the foundation for the project by defining its scope, objectives, and overall approach. The charter contains key information required to initiate a project, such as high-level project plans, the organization, and staffing approach. Most importantly, a charter provides the project team with a clear definition of the project direction, expectations, and the approach to managing changes to the project.
The work plan, like the charter, provides an opportunity to get things right up front, which prevents delays, budget overruns, and systems that don't deliver promised benefits. The intersection of complex technologies with varied organizational structures, different interrelationships among clinicians, and unique clinical processes makes for an extremely complicated system implementation project. These complexities translate into unpredictable implementation results, which translate into disappointed executives. Tackling such an undertaking that is both extremely complicated and mission-critical requires a cogent and detailed plan.
Work plans provide a level of detail that helps to visualize and identify the elements of a project, and the interdependencies among various software applications. With this information, the level of effort and resources needed can be estimated, and budgeted appropriately. A work plan is a map for moving forward. Inevitably, that map will change, but the map provides a consistent track to which adjustments can be made.
| Sample Project Charter |
|
The purpose of the charter: Sponsorship Sponsorship is critical to the success of the project. Sponsors have the operational authority and accountability to support the strategic and tactical decisions made by the teams. The role of the sponsor includes:
Ensure future design meets business requirements. Meet regularly with team leads to support issue resolution. Ensure appropriate representatives are involved during design, testing, etc. Solicit input from operational leaders across all facilities. Support design decisions when challenged by colleagues and peers. Manage expectations of end users regarding requests for improved functionality. Maintain a system perspective and support standardization as required. Provide time commitment of two to six hours per week on average. Project Overview and Purpose A high-level overview summarizes the vision and purpose for the project. Goals and Objectives The charter describes the benefits that are expected when the project is fully implemented and the measures that will be used to assess its performance. Scope of Deliverables This section tells specifically what the project will have accomplished at its conclusion. Organizational Scope The charter lists all of the organizations and entities that are included in the scope of the project and details the responsibilities for each. It also lists the organizations that are not involved in the project. Temporal Scope The charter includes a schedule for the project, including timelines for all major tasks. Functional Scope The charter describes the functionality, capabilities, and interfaces of each of the various applications and processes that make up the overall system implementation. Out-of-Scope Items The charter details items and issues not within the scope of the project. This helps prevent team members from getting distracted by items that are not part of the current project. Project Assumptions Project plans are always based upon some basic assumptions, which sometimes change during the course of a project. Since these assumptions guide the implementation effort, it is useful to understand what they are and how changing the assumptions may impact a projects timelines and budget. Project Approach This section breaks the project down into a complex array of activities or work plans and describes the events and work products that each activity needs to deliver. Changes Changing the direction or scope of the project must be accomplished through a process of escalation and approvals described in this section. Risk Management Considerable care and effort should be devoted to discovering the risks associated with the project and to developing a strategy or contingency to mitigate each risk. Project Organization The overall structure of the project teams must be specified, as well as the roles and responsibilities of each individual contributing to a team. Logistics for Schedule, Meetings, Communications Procedures must be developed for reviewing schedules, conducting milestone meetings, and communicating results between and among project teams.
|
Sample Work Plan Activities
Planning and Evaluation
- Develop program structure
- Identify and secure sponsors
- Complete the project charter
- Confirm project scope
- Structure the team
- Confirm skills required and develop plan for project team training
- Develop workplan
- Define meeting schedules
- Develop status reporting tools
- Develop communications plan
- Develop database to log and manage issues
- Plan for integration of process improvement opportunities and technology system design
Analysis
Design
Conference Room Pilot Activities
- Translate the design into data entered into the system
- Interact with stakeholders to obtain input into the design of the product functionality
- Plan conference room pilot logistics
- Build the conference room pilot prototype
- Create conference room pilot scripts
- Draft new policies and procedures
- Orchestrate technical support for the conference room pilot
- Execute conference room pilot to facilitate end-user interaction with the system to validate that the build supports end-user requirements
- Document feedback from end users
Build Activities
- Complete build activities
- Establish code-change controls and owners of code tables and build tools
- Resolve open issues and design decisions
- Monitor the application build
- Communicate legacy-system changes
- Ensure that the legacy-system build changes are in sync with the timeline
- Interact with user representative(s) as needed
- Install hardware to be used in production to support testing
- Build ops jobs
- Create unit test check list
- Coordinate build with interface requirements
Testing
- Identify regression testing approach and test scripts
- Unit test entire build
- Write system test scripts
- Conduct 100% testing of all application code, interface code, ops jobs, reports, and charges
- Coordinate testing with legacy systems as appropriate
- Write integration test scripts
- Prepare testing environment
- Work with education team to begin writing training materials
- Conduct integration test cycles
- Document findings/log issues
- Conduct daily status meetings
- Modify test scripts as appropriate
- Resolve and retest testing issues
Training
Implementation
- The project team will support the following implementation activities:
- Conversion
- Device deployment
- Final testing
- Preparations for live use
- Cut-over activities
- Dress rehearsal
- Go-live activities
- End-user support
- Issue management
- Continue to implement process improvements
- Conduct post-conversion support and evaluation
- Monitor and report on expected benefits
- Conversion
Integrated Approach
Clinical transformation results from concurrent improvements in IT, organizational change, and process improvement. No part of the equation can occur in isolation. Workable applications require close collaboration between clinical and technical teams. For example, teams implementing process improvements need to be mindful of the strengths and constraints of the enabling technology. Each order set or clinical process designed by the clinical team must be within the capabilities of the chosen applications. Getting processes right requires close communication and coordination among clinicians and IS technicians. Managing these collaborations is in itself a complex process.
More complex still is the integration of multiple, individual workplans — perhaps dozens of them — into a comprehensive project workplan. For example, there must be workplans for testing and training an interface, or data integration, workplan; a technology support workplan; and a communications workplan. There are workplans to address process improvement, and workplans for each individual application. In a clinical information system, there may be workplans for order management, clinical documentation, medical records, patient access, pharmacy, radiology, and laboratory applications. All these individual workplans need to be integrated into one project workplan, so that the appropriate resources can be brought to bear on them, and interdependencies coordinated. Planning and productivity applications such as MicroSoft Project and other web-enabled tools help hospitals track a project's progress, milestones, and interdependencies on a weekly or daily basis. Many organizations are beginning to use the Web-enabled enterprise-wide planning tools to manage and update multiple projects, as well as track resources and benefits on a real time ongoing basis.
Building a Plan
It is a useful exercise to compare the planning requirements of a major system implementation such as an enterprise-wide clinical information system to a major construction project, such as building a new hospital wing. The financial investments are similar. Yet, in spite of the fact that no reasonable person would begin to erect steel beams without an architectural blueprint, system implementations are often begun with only rudimentary planning. The planning comparison becomes even more lopsided if the enormous complexity of a CIS implementation is considered. For example, in a construction project, the building components interact in predictable ways. Design challenges are based on vast prior experience and can be foreseen. In system integration projects, individual applications are constantly evolving and interactions among them can be unpredictable. These complexities make planning a clinical transformation potentially more demanding than planning a construction project. Where there is risk, there needs to be robust and knowledgeable planning to address and mitigate that risk. Viewed from this perspective, health care providers would do well to heed their own medical experience regarding the worth of "an ounce of prevention."
