2. A Large-Scale Complex Project
in a Healthcare Organization

This book describes how to do a project to create an automated patient medical record in an HMO, a very large-scale complex project. This chapter describes in detail how to do any large-scale complex project in a healthcare organization, thus providing the structure for the remainder of this book.

If the reader is less concerned with the details of how to do a large complex project such as automation of the patient medical record, and more concerned with the possible results of such a project, the reader may wish to skip to section 2.10, which presents a summary of this chapter.

The method of doing a project presented here is based on my observations over my thirty year career. I was a major player—from requirements analysis to system design to programming—in a number of successful large-scale projects, including one to develop a patient appointment and resource scheduling system, a software system currently used by 35,000 users, serving 2 ½ million healthcare organization members. I have also participated in the requirements analysis for an automated patient medical record system.

2.1 A Successful Project

A successful project within any organization has the following characteristics:

· Organizational needs: The project fulfills a logical set of important needs of the organization.

· Integration: The project together with other projects, existing systems and employee workflows, support the totality of needs of the organization in the most efficient way.

· Adaptability: When the organization changes, the project or resulting systems and employee workflows continue to fulfill the needs of the organization or can be easily changed to do so.

2.1.1 Fulfillment of Organizational Needs

Another term for “organizational needs” is “organizational objectives”.

For an organization to be successful, upper management of the organization must identify and work toward organizational objectives. For example, for an HMO these organizational objectives might be the following: (1) provide excellent patient care, (2) generate sufficient money to run the HMO well and expand the HMO, (3) have sufficient information to manage the HMO well, and (4) fulfill all the requirements of government and regulatory organizations.

Projects are selected which, together, fulfill these organizational objectives with the greatest benefit to the organization. The project objectives [1] of each of the projects must thus be compatible with, and support, the organizational objectives.

For example, the broad objectives of a project to automate the patient medical record might be (1) to provide better patient care, (2) to save money for the healthcare organization and (3) to provide better information to manage the healthcare organization. These project objectives all support the organizational objectives. To be useful in the evaluation of the success of a project, these project objectives must be measurable, so the organization can determine whether these project objectives have been achieved once the project is complete.

To measure a project objective, the organization can set targets to be met that can be measured and that lead to the final objectives. Such targets are called goals [1]. A goal can be set after a particular phase of the project or at the end of the project to measure whether or not an objective is being achieved. For example, “goals” for a five year project might be to have an immediately available automated patient record for 40% of the HMO patient visits after three years and 95% of the HMO patient visits at the end of the project. The project’s final success can be determined by how closely the project meets the objectives for it as measured by the final goals for the project.

Strategies [1] that lead more quickly to the objectives and fulfillment of the goals also need to be established. One “strategy” might be to implement the automated patient medical record system first in the west coast region of the HMO, where 50% of the healthcare organization’s membership is located, before being implemented in other areas of the United States where the healthcare organization functions.

2.1.2 Integration and Adaptability

A project must enhance organizational objectives: the needs of the organization. Other positive attributes of a project are “integration” and “adaptability”.

“Integrated” in the context of an organization means that all the employee workflows, automated systems, and other parts of the organization function well together, meeting the totality of the objectives of the organization. “Adaptable” means that an organization can be changed to adapt to new business needs, functioning at least as well after the changes as before the changes.

Projects must produce products (changes in employee work flows, automated systems, etc.) that are integrated with the organization. The products should be adaptable so they can easily be changed to produce changed products that meet the changing business needs of the organization in the future.

Frederick Brooks in his classic book, The Mythical Man-Month, [2] wrote about “integration” and “adaptability” with respect to automated systems. He wrote about integration of automated systems with other automated systems, and about adaptability of automated systems.

“Integration” of an automated system with other automated systems in an organization means that there is real-time sharing of common data with other automated systems via networks or databases so all systems can be kept in synchronization. For our automated system, a patient medical record system, sharing of data between systems is especially important: inconsistent data in an automated patient medical record could be disastrous as it could result in incorrect medical decisions.

“Adaptability” for an automated system means that the system can be easily maintained and updated, including

1. The system is scalable (i.e., it can increase in size with more users or more data usage).

2. The components of the system (whether software or hardware) incorporate strategies that allow the components to later be more easily replaced by improved components (e.g., use of industry standards).

3. The system is well documented and put under a change control process, where only agreed upon changes are allowed and where changes can be backed out if necessary.

4. The reasons for the current design of the system are recorded and well understood so that future changes to the system can be made which are compatible with the design.

The book The Mythical Man-Month refers to an integrated system as a “programming system”, to an adaptable automated system as a “programming product”, and a system that is both as a “programming system product”. The author of The Mythical Man-Month, Frederick Brooks, contends that, for an organization, a “programming system product” is many times more useful than a comparable software product that is not, but may take up to 9 times as much money to develop.

It should be noted that “adaptability” whether for the entire organization or for a single automated system, requires anticipating future business needs of the organization so that the organization or system can be made adaptable. This anticipation of the future requires management ”vision”. In anticipating such future business needs, management assumes a significant probability of being wrong, as anticipating the future is often extremely hard to do.

2.2 Basic Project Model

Figure 2.1 presents a project model applicable to a large complex project. This project plan promotes the three requirements for a successful project listed in the last section: (1) that the project fulfills organizational objectives, (2) that the project is compatible and integrated with other projects and with all aspects of the organization, and (3) that the project is adaptable, and can be easily changed to meet the changing requirements of the organization.

Large-scale complex projects such as ours need to be broken into smaller sub-projects, or phases. An overall design of the entire project is done at the very beginning that includes breaking the project into phases. At the beginning of each phase there is also a determination of whether the phase will significantly change the previously agreed-upon design of the project. If so, the overall design of the project may be re-done at the beginning of the phase.

For example, our project begins with a complete overall design of the automated patient medical record. The project is then broken up into phases to implement the automated patient medical record. An early phase in our project, for example, might be to rewire hospitals and medical offices and implement the networks for the future automated system.

This project model has a number of advantages over others, foremost of which is always knowing what direction you are going on the project. Doing a complete initial overall design allows the final products of the project to be predicted at the beginning, with each phase then developing products or immediate products that can be adapted into producing the next product leading to the final products of the project. Possibly redoing the overall design after an analysis later in the project during the start of a phase allows redirection of the project, with the project personnel again knowing what products to develop. Thus, the people doing and controlling the project always know where they are heading!

Other advantages of this approach are the following: (1) Going from one consistent design to another is much easier than trying to fix an inconsistent design. (2) The final products of a large-scale complex project often cannot be completely defined at the beginning; this project model allows redefinition of the overall products as more is learned about the project over the life of the project. (3) Breaking the project into phases allows the results of the project to be given to the organization at bit at a time, early on, with early payback to the organization--phases can be ordered such that those producing immediate results are done first. (4) The project can be evaluated early on and continuously to determine if it is meeting the project and organizational objectives and goals, with this evaluation possibly resulting in early revision of the project or termination of the project before too much money is spent. (5) This approach minimizes the cost of expensive re-working of the project, as re-working is done as soon as possible, before it becomes too costly. (6) Phases of the project may be done concurrently, effectively using available resources.

Products of a project could include automated systems, changes in the way employees function in doing their work, rewired buildings with installed workstations, etc., or different combinations, or “sets”, of these products that function together. Each product set during the lifetime of the project should be adaptable, allowing change of the products to produce the next product set.

The project model in figure 2.1 is similar to project models referred to as the “incremental model” [3], the “iterative model” [3], the “evolutionary delivery method” [4], the “staged model” [5], and the “spiral model” [6].

Doing the overall design up front, and potentially re-doing it again before each phase, insures both that the project meets the needs of the organization and that the final product is integrated and adaptable.

Revisiting the overall design of the project before each phase allows upper management to verify that goals are being met and strategies are being followed to work toward the final objectives of the project. Costs can be reviewed after each phase and kept under control. Return on investment can be evaluated. It thus allows upper management to have control over the project.

It will insure adaptability by allowing early redesign of the project if necessary. After each phase, the phase and the overall project can be reviewed, revised, improved or restructured. New or changed requirements can be incorporated.

It will insure that other automated systems using the same information are integrated by allowing redesign of the project as necessary so that all automated systems are properly integrated.

In order to make the model in figure 2.1 somewhat more flexible, we allow the project model to have the following additional characteristics:

· Depending upon the complexity of the upcoming phase, re-visiting the overall design may involve only reviewing a part, rather than the whole of the overall design. Prior to simple phases and phases where much was known ahead of time, the overall design phase may not need to be reviewed at all.

· Phases may be added or changed as a result of revisiting the overall project design.

· Maintenance of a phase occurs immediately after a phase is complete and could result in such significant changes that a new phase is required, with possible revisiting of the overall design.

· Phases may be added or deleted from the project plan for other reasons, for example, because of changes in organizational strategies or cost considerations.

· It may be appropriate to re-visit the overall design to account for multiple upcoming phases, rather than just one.

· Unlike what is shown in figure 2.1, phases can partially or completely overlap one another in time.

This project model is necessary because a large project takes a long time to complete and thus must be broken down into phases, but all phases of the project must, at the end of the project, fit together seamlessly into a whole.

Use of this project model is not an excuse to do bad design. In fact, a large complex project is only feasible if the total of the design at each step fits together impeccably. Any significant error in the design may be embedded into the project and require significant re-work to get rid of it. Fixing multiple errors in a large project later on in the project may be cost-prohibitive or impossible. The earlier in a project a problem is detected, the lower the cost to fix it. For example, it has been estimated that fixing a problem early on during the requirements phase of an automated system could be 1% as costly as making the fix after the automated system has been coded [7].

2.3 Participants in a Project

Many people, of varying roles, and aptitudes and interests, must be participants in a large project for it to be successful. These many diverse groups must work together as equals with the professionalism of each group respected by the other. The reason this cooperation is required is that a large-scale complex project is a single organism rather than the sum of its parts, with any one decision in one part of the project (e.g., a database design decision) potentially effecting any other part of the project (e.g., the user interface, with a possible consequential effect on patient care).

Accordingly, this book, unlike many others, does not look at a project from the single point of view of a project manager, but from the points of view of the many participants in a large-scale project.

The most successful projects involve meetings involving a diversity of different categories of people who meet together and learn from each other, creating a group dynamics to exchange information, thus creating a unified product that meets the many diverse needs of the organization (e.g., provide excellent medical care, have good system response time, supplies information needed by government and regulatory agencies).

There are four important categories of people who should be involved in a large-scale complex project: domain experts, content facilitators, upper management, and process facilitators. Domain experts are experts in the project subject area (e.g., patient care and medicine). Content facilitators gather information from the domain experts to design and produce the product. Upper management pays the bills and determines the organizational objectives for the project. Process facilitators work in group meetings to insure that meetings are productive, that group dynamics are established and that participants learn to run their own meetings.

Domain experts include workers in the organization (including upper management), who know how the organization functions, customers who know how the organization provides services, and experts from the outside world who know what happens outside the organization.

In our project developing an automated patient medical record system, the organization will be a particular type of healthcare organization, a Health Maintenance Organization (HMO). An HMO is a corporate entity that provides comprehensive health care for each member of the HMO for a fixed periodic payment paid in advance by the member or his employer; such a payment system is referred to as “capitation”. Our HMO has its own hospitals and medical offices spread throughout the United States. This is a fictional HMO, but is representative of a very large HMO that may exist in the United States.

Upper management in our example are management physicians who control the operations of the HMO. Being management physicians, they care very much about quality patient care as well as about the financial health of the HMO.

The workers in the organization include everyone in the HMO, but especially “caregivers”, those who provide medical care to patients: physicians, nurses, medical assistants, hospital unit assistants, etc. The customers are the members and patients of the HMO. The outside world includes suppliers, the government, regulatory agencies, and software and hardware suppliers, and other healthcare organizations.

Content facilitators for a project include business analysts, systems analysts, database analysts, domain analysts, members of the technical staff, and project managers. Business analysts gather information from upper management, workers, customers and outside experts to identify what an improved organization would look like and to identify business requirements that would accomplish these improvements. Systems analysts take the business requirements and a description of the improved organization to create requirements for automated systems. Part of systems analysis is determining new and changed databases--databases are places to save information; database analysts work with system analysts and domain experts or domain analysts to define databases for a project or for an organization, or change existing databases. A domain analyst is an expert in how a particular type of business functions and works with domain experts to facilitate solutions; for example, a domain analyst might be an analyst who is also an expert on provision of medical care and work with domain experts (e.g., the caregivers) in an HMO to reengineer medical care, changing work flows. Technical staff create and implement automated systems. Project managers schedule activities making up the project and guide personnel in their execution.

For a large-scale complex project, meetings between project members are likely to occur over an extended period of time. For any long-lasting meetings of project group members, there should be a process facilitator, or simply “facilitator”, until the participants in the group or sub-group learn how to work together (in which case the whole group assumes the responsibilities of the process facilitator). Along with the participants, the process facilitator develops processes to be followed during meetings to enable the group to work efficiently and make decisions (e.g., “It seems that our group has decided upon the following process: Any agreement this week will be written down. During the following week’s meeting we will either finalize the agreement or retract the agreement. This allows us to think over our agreements between meetings and discuss the agreements with our various groups.”). The process facilitator also teaches the group about interventions to be used if the group bogs down; for example, when multiple people are talking at once, the process facilitator might say, “Just a moment, one person at a time. Joe you were first, and then Carol”. An excellent book on facilitation is [8].

When there are automated systems, members of the technical staff are involved in the procurement, development and implementation of these automated systems. This staff may include the following: system architects, people who define how computers and other devices are linked logically and physically, how data is distributed between databases on the computers, and how software is distributed; capacity planners, people who get information from business planners on anticipated number of users and customers, and who determine and anticipate the transaction loads of systems and networks, thus anticipating overcapacity problems; software developers, who design software; and other DP personnel such as programmers, programmer/analysts and testers who program and test the software. Additionally, vendors may supply off-the-shelf software in place of organizationally developed systems.

The next section describes the different steps (or activities) making up a project and which participants are involved in each step.

2.4 Steps in a Project

The overall project analysis and each phase of the project can be broken down into the following steps:

· Business Analysis step: Determine the changes to the organization from the project or from the phase from a business point of view.

· Evaluation step: For the project as a whole during the overall project design, or for a phase, evaluate the projected value or actual success of the project or phase. Determine whether to continue, change course, or terminate the project or phase; included in this process for the overall analysis is whether to re-do previous phases and re-do plans for future phases.

· Business Reengineering step: Determine how employees will function differently due to the project or phase. Included in this process is determination of user interfaces for automated systems.

· System Analysis step: Determine technical requirements for new automated systems and changes to existing automated systems as a result of the project or phase.

· Project Plan step: For the project, break the project into sub-projects, or phases; for a phase, break the phase into tasks in order to develop or implement the phase.

· Development step: Develop or make changes to automated systems based upon information from the System Analysis step. (This is done only as part of a phase.)

· Implementation step: Change the way employees function in the organization, or implement or change automated systems in the organization. (This is done only as part of a phase.)

Figure 2.2 shows the project plan in figure 2.1 expanded to include the above steps.

Although figure 2.2 shows the Evaluation step for a phase as occurring at the end of the phase, an Evaluation step for a phase may occur at any time, or not occur at all, within the phase. The Evaluation step within a phase determines whether to continue, change or terminate the phase, other phases, or the entire project.

2.4.1 Business Analysis Step

Figure 2.3 shows the Business Analysis step, in which business changes to the organization as a result of the project or phase are identified. This is the first step in the initial overall project analysis or in a phase.

Looking at the needs of the organization and the current environment and systems, upper management identifies potential projects. By analyzing the current environment and systems, management identifies problems in the organization. Based upon these problems and the needs of the organization, upper management identifies potential projects to further the needs and fix the problems.

Each phase within a project constitutes smaller project within the project.

For a project or phase, upper management identifies objectives, strategies, and goals for the project [1] or phase. Objectives are the future positions of the organization expected from the changes resulting from the project or phase. Strategies are ways to accomplish these objectives. Goals are targets to be met and measured at specific points in time that can be used to measure the progress or lack of progress of the project in achieving the project objectives.

For example, for the automated patient medical record project, some project objectives might be to save money for the HMO, to have the patient medical record instantaneously available, and to have the system calculate all charges to patients and insurance companies automatically. Strategies might include to create a common hardware infrastructure throughout the organization so the automated medical record system can be easily implemented; to implement the automated patient medical record first in the west coast region of the HMO to implement it the quickest, before rolling it out to other regions; and to immediately work with insurance companies for a data format to transmit healthcare charges to them. One goal related to the objective of saving the company money would be to have a positive return on investment by the third year (where “return on investment” is a comparison of the total costs of the project with the increased revenue accruing from the project.).

These (project) objectives, strategies and goals would later be used to evaluate the progress and success of the project in a later Evaluation step. They could also be used to compare this project against other projects, whose project objectives might also be important for the organization, so money can be allocated between the projects according to their value to the organization.

Project objectives, strategies and goals are derived from objectives, strategies and goals for the organization. This is done by identifying aspects of the project that further these organizational objectives, strategies or goals. These become the project objectives, strategies and goals. For example, if an organizational objective is patient satisfaction and some aspect of doing the project strongly promotes patient satisfaction, then this would become a project objective.

During the Business Analysis step, upper management identifies constraints for the project or phase. The most important constraint is the amount of money allocated to the project or phase.

Also, during the Business Analysis step, a vision for the project should be developed. This vision takes ideas from many different sources to predict or define the future of the organization and outside world with respect to the project, in our case with respect to the automated patient medical record. Ideally, by meeting the vision, the product would have an extended life span in that the resulting product would fit into the organization as it changes and, where applicable, the resulting product would later be compatible with, and perhaps could interface with, systems in other organizations. In the case of our automated patient medical record system, this vision might include integration of the automated patient medical record with a possible universal patient health record that would be available to many healthcare organizations both inside and outside the HMO.

Vision, anticipating the future, also applies to determining how this project effects other projects, in the interim and once completed, and how other projects effect this project. This provides upper management with important information to select, evaluate and coordinate projects within the organization.

Vision entails significant risk that the prediction of the future is wrong. Thus risk management, planning alternative measures if the prediction turns out to be wrong, is important.

After the development of objectives, strategies and goals, the workers and domain experts would then identify the current environment and systems as a baseline for evaluating any changes. From detailed observations and analyses of the current environment and systems, essential business practices that must be preserved are identified. The workers could then identify improvements they would like to see in the current environment or automated systems. From upper management’s ideas for change, objectives, strategies, and goals, from various people’s vision of the future, from the worker’s list of improvements, and from an analysis done by the workers, upper management, domain experts and business analysts, a proposed future environment and automated systems is described.

Finally, the business analysts and domain analysts together with workers and upper management create a list of business requirements (changes to the organization together with things to keep the same) to transform the current environment to the future one. Business requirements include both requirements for changing the organization and for creating and changing automated systems.

As a method to clarify ideas, models of systems, workflows, etc. may be created, presenting conceptual views, or less abstract, more concrete views, of the systems and working environment. These conceptual views are vehicles for communication and for critique, especially for people who find that working with objectives and business requirements alone is too abstract for them.

When a project or phase involves an automated system, then storage of information on databases is required. Because developing databases is so terribly difficult, a start should be made at the start of the project or phase to items making up the database: business objects (e.g., a physician order), database objects (e.g., order status, order type of a physician order) and relationships between objects (e.g., each caregiver order has an order status such as “in process”, “completed”, “results returned”), and requirements for new information that is not on any existing database. Existing corporate databases—databases that are currently being used throughout the organization—that could be used by the project should be identified; use of corporate databases is one way of integrating the different parts of the organization.

Finally, expected products of the project, including potential new and changed automated systems, and changed employee workflows, are identified.

2.4.2 Evaluation Step

Figure 2.4 shows the Evaluation step, in which the project, so far, or as projected to be in the future, is evaluated.

The business analyst and systems analyst present an evaluation of the project or phase to upper management. The business analyst explains the business side of the project and related issues. The systems analyst presents the technical and automated system side of the project and related issues.

From this evaluation, upper management determines if they are, or will be, getting what they are paying for. This evaluation compares the changed, or projected future, work environment to the initial work environment and determines if the objectives, goals and vision of the organization are indeed being fulfilled by this change. Evaluation also involves identifying obstacles to the project that must be considered, both for determining if an obstacle makes the project too difficult to do, and also for inclusion into the project in the form of additional business requirements that handle an obstacle or in the form of a contingency plan, a plan to be followed later on if the obstacle does occur. The results of the Evaluation step may be termination of the project, changes to the project, or continuing the project as planned.

The Evaluation step during the initial overall analysis is there to ask the question, “Should we continue with the project?”. In our project model the Evaluation step for the overall analysis occurs directly after the Business Analysis step, as enough information has been gathered to make management decisions but an inordinate amount of time, money and effort has not yet been expended.

On the other hand, in our model, the Evaluation step in a phase can be scheduled to occur anywhere in the phase. These Evaluation steps are put in less to ask the question “Should we continue with the project?” but more to ask “Where are we? Are we meeting our goals? And if not, what changes to the project do we need to make?”

The first evaluation point in a project, as part of the initial overall analysis, is actually done before any changes are implemented; thus, the evaluation is entirely based upon projected changes to the organization due to the project rather than actual changes. Such an evaluation study in the initial overall design before any project changes are implemented falls under the category of a feasibility study.