Many organizations are embracing Client/Server and Open Systems technologies only to find that a host of unanticipated issues prevent the realization of expected benefits. The study team* found that these problems were, like heart disease, often not visible until a catastrophic event crystallized the problem. What is the project manager's equivalent to a heart attack? The study team concluded that “roughly 70 percent of Open Systems projects will come in materially late, materially over budget, or will fail to meet significant user expectations.”
If I had a 70 percent chance of having a heart attack, I would be taking some immediate action to reduce my risk. The good news is that the study team identified 16 specific issues that can improve the performance of these projects and, hopefully, help prevent a number of project manager heart attacks (figurative or literal!). In this short discussion we will explore some of the most significant findings of the research project, and refer the reader to the full text for the study published in the June 1994 Project Management Journal.
Defining Open Systems
Since the widespread acceptance of the personal computer in the early ‘80s, a new area of information technology has gained critical mass. Collectively called Open Systems, this new technology provides many advantages over single-vendor, proprietary systems. For purposes of this discussion, Open Systems includes Client/Server (personal computers accessing a network of servers and other large computers) and Unix (an operating system that allows applications to be transportable to other hardware). The primary benefit of this new generation of systems is that it allows applications to be transported to other computing hardware and dramatically improves the ability of computer systems to be compatible (interact with each other). This creates competition for hardware dollars and reduces a user's dependence on a single vendor. It also has produced a large library of available software packages that can work in many different computing environments.
The study team developed a method of scoring project outcomes and identifying the issues that contributed to project success. Following are discussions of some of these key issues.
Technology Focus versus Project Management Focus
Which is the greater contributor to positive project outcomes? Figure 1 shows the correlation between overall project outcome score and the project's technical score. Note that many projects had excellent technical scores yet produced average or poor project outcome ratings. Note also that several projects had poor technical ratings but produced average or above average project outcomes. It is most distressing to note the large number of projects with very poor project outcomes and excellent technical scores. This may be attributable to a false sense of security generated by the excellent technology.
Figure 1. Project Outcome versus Techical Score
Figure 2. Project Outcome versus Project Management Score
Figure 2 shows a very close relationship between project management score and positive project outcomes. The relationship is well within the tolerance of this study.
In contrasting technical excellence and project management, the study team makes the firm conclusion that effective project management is directly linked to positive project outcomes, whereas technical excellence shows only a minor correlation. The overwhelming recommendation is for managers to downplay the technical aspect and focus on identifying and executing the correct project management tasks.
Up-Front Reconciliation
Up-front reconciliation of objectives, scope, deadlines, expectations, budgets and who will do what, when, and how was an issue that emerged so frequently that the study team combined several questions and ranked this attribute according to its overall importance. The primary mistake made by the unsuccessful project teams was to charge ahead with a new technology or concept without reconciling these key issues. This resulted in projects that appeared to start well but quickly suffered from a variety of symptomatic problems. Midway through, the project team often found that:
- Overall project objective seemed unclear or changed frequently.
- The project's scope was way beyond anything realistically attainable.
- Deadlines were arbitrarily set and represented no basis in reality.
- User and management expectations were so high that Star Trek's Commander Data couldn't meet them on a good day.
- Project budgets were exhausted, with no chance of completing the project.
- It was unclear who was responsible for individual tasks and objectives, so work progress was spotty and uncontrolled, particularly regarding third parties.
- Regarding what would be done, project delays and problems caused the project team and management to reduce the scope of what would be delivered by the project.
- Regarding when, schedules were delayed several times and actual completion appeared as a distant fog on the horizon.
- Regarding how, it was discovered that a key technology component was unable to do what it was expected to do and the entire project was jeopardized.
All of these common Open Systems project problems are symptoms of failing to balance and reconcile these key issues before the organization is committed to the project. Nearly every negative outcome in the entire study can be attributed to shortcuts or omissions in this area. The successful project teams consistently showed the discipline to effectively manage these issues up-front.
Planning Process
The planning process identified all of the key steps, hardware, and software during the planning process so that no material, credibility, time, or cost was lost. This was the acid test of effective planning. Some argue that Open Systems projects are so volatile that it is not possible to plan effectively. The top projects demonstrated that it is possible to identify all of the key steps and major hardware/software cost factors during planning. It should be noted that the top project teams did not plan the projects down to the micro level of detail but used the Work Breakdown Structure and Technical Breakdown Structure concepts to plan down to an effective level. (These techniques allow complicated tasks and technologies to be broken down into parts that can be effectively managed and controlled.) Overall effectiveness in this area was measured by the absence of material omissions.
Project Manager Characteristics
Project manager responsibility/authority mix and experience level is a most difficult item to measure but may rank among the most important. It was observed that the top project managers consistently demonstrated two key items in common:
- Experience managing two or more Open Systems projects of progressively increasing magnitude.
- They were empowered to control the course, nature, and priorities of the project. The study team attempted to quantify authority and responsibility with 100 percent representing complete responsibility/authority and 0 percent representing none. Sixty-five percent became the study team's choice to represent a breakpoint. Recognizing that this is somewhat arbitrary, we request that the reader internalize this general concept: If a project manager held substantially more than half of the authority and personal responsibility for a project, that project tended to perform significantly better than projects where this was not the case.
Some tests that determine the true level of authority include whether the project manager can:
- Stop the project
- Affect expectations, scope, and budgets
- Choose or dismiss team members
- Make decisions and operate openly for the good of the project without fear of recrimination.
This issue is most clearly identified by the symptoms shown by projects with an inadequate authority/responsibility mix for the project manager. In these cases it is common to find that the project manager is midway through the project, knows what needs to be done, and simply cannot exercise sufficient authority to do it. Frequently the project manager will become the scapegoat for all project problems when the real fault lies with his or her management for ignoring the issues presented in this study. The overall recommendation from this project success attribute is to use experienced Open Systems project managers, vest them with sufficient authority, and see that they remain personally responsible for the project.
Conclusion
Positive outcomes can be realized from Open Systems projects by learning from the experiences of others. The recommendations contained herein are the product of a large sample set and meaningful correlations. The reader is encouraged to resist anecdotal or biased recommendations and look closely at the true motivations of those advocating certain technologies or solutions.
It is important to remember to keep technology in its proper place. By prioritizing the issues mentioned above and the other issues identified in the full text of the study, the reader should be able to dramatically reduce the figurative and literal chances of a “project heart attack.” ∎