9. Should the Healthcare Organization
Go Ahead with the Project?
So far, our business analysis of the automated patient medical record project has looked at project objectives and business requirements all dealing with the beneficial aspects of the project. In the next chapter, we will deal with the obstacles to the project, i.e., the costs and complications of introducing an automated patient medical record system.
After identification of both benefits and obstacles, an initial evaluation of the project should be done by upper management. This evaluation is very important, but also very complex.
These benefits and obstacles are used in the initial Evaluation step. See figure 2.5. This initial Evaluation step asks the question: “Given the benefits and obstacles identified to developing and implementing the project (an automated patient medical record system), is it worthwhile for the organization (an HMO) to do so?” The answer to this question lies in the answers to some other questions:
1. Is there at least one solution that is feasible and which benefits the organization?
2. Will the project (the automated patient medical record system) support the mission, objectives, business strategies and goals of the (healthcare) organization?
3. Will the projected return on investment of the project (the automated medical record system) support its costs? Or if not, is there another justification in going ahead anyway?--for example, regulatory requirements.
4. What are the obstacles to the success of the project? Can these be managed?
5. Are there more important projects which need to be done instead, that are lower cost or can better fulfill the mission, objectives, business strategies and goals of the company?
The initial evaluation falls into the category of a feasibility study [1], evaluating projected--instead of actual--costs and obstacles versus benefits. This initial Evaluation step is done by business analysts and is presented to upper management.
At this point, upper management, must decide whether or not to continue with the project. Note that return on investment values are likely to be very gross ones at this point and will be more accurate after the project is completely scoped out in the Project Plan step, where the project will be broken up into phases. Upper management should take this into consideration. And they may decide to continue the project for re-evaluation after the Project Plan step, when more accurate return on investments values are likely to be available.
If management decides to continue the project, they should make one or more of the following decisions:
1. to continue the project until the step to break up the project into phases and determine then whether to continue with the project, as more information on the project will be known at that time, including more accurate return on investment estimates
2. to determine that the project is going largely the wrong direction, and change objectives, strategies or constraints as a result, possibly requiring that the Business Analysis step be re-done
3. to determine that the project is going the right direction, but to change, delete or add objectives, objective priorities, strategies, constraints or business requirements
4. to identify now how the project should later be broken up into phases
5. to identify how the project could be improved
6. to pare down the project
7. to give an absolute go-ahead for continuing the project to the next evaluation point.
There is a potential danger in paring down a project: losing the context of the project. If the intent is to later do the larger project, then the business analysis work done so far should not be lost, so that the pared down project could be developed so it could later be extended to produce the larger project. This may, for example, require building the pared down project with additional information in data bases or building the application as if the larger system was there, but leaving out the actual code or interfaces.
See figure 2.5 again. The business analyst does an analysis and reports to upper management on how the project objectives achieve the organizational objectives. The business analyst reports on the future systems and environment and how they change the existing systems and environment. And the business analyst identifies obstacles to doing the project and makes an analysis of whether they are manageable or not, including whether the obstacles are so significant that management should consider not doing the project at all. The technical group presents technical obstacles, such as potential system performance and scalability problems.
Upper management uses this information to compare the project against other possible projects, and give directions on how to proceed. As a result of this process, upper management may choose to change strategies, goals or constraints, reprioritize objectives or to make the project more compatible with organizational objectives. The Business Analysis step might, as a result, be redone, with changes to business requirements and the future, changed, system as a result of changes to project objectives, strategies, goals or constraints. Additionally, the Business Analysis step may have to be re-done, adding or changing business requirements as a result of the identified obstacles to the project.
In the Evaluation step, upper management has a chance to review and update the description of the future environment and systems. This is important because this description presents a clear description to the organization of how the project results will be used in the future.
The next chapter looks at the part of the Evaluation step that deals with obstacles to the success of the project.
An Evaluation step should not only be done in the overall analysis but also should be done at various points in the project. See figure 2.3. For the overall analysis step, the Evaluation step should be done early on. Evaluation steps for each phase, called “gates”, are done at any time during the project as warranted by the project or should be done when new significant obstacles are identified. Section 14.2.1.
References
[1] Ian Sommerville, Software Engineering, Addison-Wesley Publishers, Ltd., 1996, p. 67.
Copyright
© 2000 Michael R. McGuire
Duplication not permitted without express written permission
Comments? mailto:Michael.McGuire@abac.com