2.2 The multiproject environment


2.2 The multiproject environment

The diagram in Figure 2.1 depicts the principal variables upon which management tends to act in an attempt to keep projects on track. Such variables tend to address the current situation, as long-term approaches such as process improvement and competence development are seldom a remedy in the case of late projects.

The arrows in the diagram describe influence relationships among the management variables. For example, overtime hours lead to worker fatigue, and fatigue affects productivity, leading to project delay. When a project is delayed the project team shifts its focus from low-visibility tasks, such as inspections, reviews, and testing, to high-visibility tasks, such as coding and integration; this causes an immediate reduction in the project workload and some of the delay is recouped. Unfortunately, errors that would otherwise have been caught through these low-visibility tasks have moved to the next stage in the project's development, at which time the cost to fix them is of an order of magnitude greater than the time originally recouped by eliminating them. As the schedule pressure continues to mount, the quality of the decisions made by the project team deteriorates, the number of errors increases, and the project falls even further behind. At some point, the project begins to attract special management attention, and the project staff is asked to work harder on "value-adding" activities.

The team gets the message, and begins to put in longer hours while the focus on quality-oriented activities continues to drift away. The extra hours soon pay off in the form of boosted output, but as people become fatigued, their productivity drops and the number of mistakes made increases, creating another vicious circle.

The next weapon in the conventional management arsenal is to increase the project head count. This measure could help or damage the project, depending on the circumstances. We know for a fact that some effort is associated with taking the newcomers through the learning curve, and this implies an increase in project workload for the original, already overloaded, staff. To add to this, through the learning period, the new staff is far from being 100% productive, which lowers the average team productivity. Furthermore, if the work was not planned from the beginning to accommodate the extra head count, a significant effort might be needed to partition and later integrate the new interfaces. Also, as the team grows larger, its productivity diminishes as a result of an increase in the communications overhead and process losses [5].

Finally, after the above approaches fail to produce the desired result, the project scope is reduced. This, which effectively cuts the workload, also comes with a price tag: Interfaces must be reworked and adaptations made. In the end, this may result in less product functionality and no real savings.

Outside the sphere of the offending project, other otherwise unrelated projects begin to experience delays, as the resources they need are not made available on time. Projects waiting for deliverables are also affected. As the number of projects in the queue increases, resources are multitasked across several projects in order to keep the project sponsors happy. Such ad hoc multitasking further hinders the overall productivity of the organization. To add to the mayhem, limiting the scope of the offending project has resulted in a number of Band-Aid projects intended to pacify customers who were promised now defunct features. This adds to the organizational workload, further reducing the resource availability and increasing the multitasking, which further reduces the productivity, which further delays the projects, which adds to the workload, which further reduces the productivity. Breaking the circle calls for something truly dramatic.