How to Organize

by Manuel Lowenhaupt, M.D.
David Friedman, Capgemini

June 30, 2003

Building a computer information system from the ground up is analogous to undertaking the construction of a new hospital building in terms of expense and complexity. Careful planning is essential. Charters and detailed work plans are a good place to start the planning process.

PDF download

“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

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:

    • Document agreement between client organization, team sponsor, project
    team, team leader, and project manager.
    • Provide a clear statement of purpose of the implementation project and
    what the team is committed to deliver.
    • Define the project roles and responsibilities.
    • Provide the baseline for scope and expectation management.


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:

    • Approve scope of work for team.
    • Ensure future design meets business requirements.
    • Meet regularly with team leads to support issue resolution.
    • Ensure appropriate representatives are involved during design, testing,
    • 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

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 project’s 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.


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


  • Conduct current state assessment to validate key current state processes and
    user requirements for future state

  • Complete gap analysis between the current state processes and technology enablement
    and user requirements for the future state

  • Develop future state vision and gap analysis
  • Confirm improvement opportunities; quantify potential benefits
  • Identify issues and barriers
  • Communicate performance expectations and standards


  • Determine design topics
  • Collect leading practices
  • Determine standardization requirements to facilitate identification of discrete
    data items to support the development of an enterprise-wide database structure

  • Build options for demonstrations to facilitate decision-making
  • Schedule/conduct design sessions
  • Develop plan for implementing process improvements
  • Implement process redesign “quick results”

    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

    • 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


    • 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


  • Work with the training team in the development of training materials
  • Establish training environment
  • Determine refresh activities
  • Support the orientation of users to applications as well as changes in the
    processes and policies related to system use

  • Support education team responsible for training


    • 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

    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.”

    Share Button

  • No comments yet.

    Leave a Reply

    You must be logged in to post a comment.