Chapter 1: Introduction


Chapter 1: Introduction

Overview

As organizations move toward a project approach as their preferred way of developing new products and services, the difficulty of maintaining aligned business strategies, resource needs, functional budgets, and delivery dates increases exponentially. Common symptoms of this misalignment are perpetual "fire fighting," weekly reprioritizations, and missed deadlines.

Many of the projects deemed failures in the project-management literature are not such, but the consequence of poor organizational policies or perverse modi operandi. Projects launched under seemingly good conditions soon become disasters when the necessary resources are not made available on time or promised deliveries from other projects are delayed. Under these circumstances, there is little that the project manager or his staff can do. The solution to chronic scheduling and budgeting problems requires not a new method of planning but avoidance of the conditions for failure.

In his book The Logic of Failure [1], Dörner states, "Failure does not strike like a bolt from the blue; it develops gradually according to its own logic. As we watch individuals attempt to solve problems, we see that complicated situations seem to elicit habits of thought that set failure in motion from the beginning. From that point, the continuing complexity of the task and the growing apprehension of failure encourage methods of decision making that make failure even more likely and then inevitable."

Illustrating how situational complexity leads to failure, Figure 1.1 compares the results of a simulation involving the simultaneous execution of three identical projects with the isolated execution of the same projects. The assumptions behind the simulation are few and realistic: Projects in the multiproject environment share resources, and prioritization is not guided by any particular policy but rather by whoever seems to be screaming the loudest at any given time. Also, there is a 1-day penalty each time any resource stops work in the middle of a project task in order to work on another project.

click to expand
Figure 1.1: Project simulation results: x-axis shows project duration; y-axis shows number of occurrences for a given duration. (After: [2].)

In the example shown, the project sponsors in the multiproject scenario must wait an average of 350 days to get their results instead of the 150 days corresponding to the promised duration of each project (see Figure 1.2). This should come as no surprise, since the work necessary for a simultaneous execution of the jobs exceeds the organization's capacity. However, by simply delaying the start of the projects by 20 days with respect to one another in order to minimize resource contention, and by giving priority to the projects according to when they were begun, the average waiting time could have been reduced to 170 days.

click to expand
Figure 1.2: Expected results versus what really happened and what was possible.

As this example shows, the need for coordination with respect to competing projects is self-evident. Although this fact seems both obvious and well understood, coordination problems plague the multiproject environment. I conducted an informal study within my own organization which found that 58% of the problems mentioned in risk and progress reports were due to lack of resources and insufficient coordination across projects (see Figure 1.3). Furthermore, in a study of 271 U.S. Department of Defense projects [3], respondents reported that technical problems accounted for only 25% of observed slips. Coordination problems such as funding stability, requirement changes, and "other causes" accounted for 75% of the delays.

click to expand
Figure 1.3: Actual progress report showing typical coordination problems in multiproject environment (employee and product names have been changed).