1.4 Summary


1.4 Summary

The last decade has seen an impressive growth in the number of organizations using the project approach to conduct their business. But this growth, explained by the effectiveness and flexibility of the project work form in an environment of increasing complexity and demands for "faster, better, and cheaper", has created problems of its own: conflicts between projects competing for the same resources, lack of coordination between complementary initiatives, and loss of sight of the organization as a whole. Coincidentally, there has been an increase in the number of work hours, the level of stress, and the number of work–family conflicts experienced by employees.

The same set of circumstances reported across organizations and industries points to a systemic or structural, rather than a performance problem. This book proposes the creation of a new business function, the PO, as the means of coordinating, managing, and reporting on projects across the organization.

Introducing a PO into an organization is a substantial undertaking, and it is essential to remember that all change, especially change involving the entire organization, takes time. The establishment of the infrastructure necessary to support the PO is only part of the solution. The organization must allow its culture to evolve—and it must be prepared to do business in a different way—in order to succeed.



References

  1. Dörner, D., The Logic of Failure: Recognizing and Avoiding Error in Complex Situations, Reading, MA: Addison-Wesley, 1997.

  2. Goldratt, E., Project Management the TOC Way, Croton-on-Hudson, NY: North River Press, 1998.

  3. McNutt, R., "Reducing DoD Product Development Time: The Role of the Schedule Development Process," Ph.D. diss., Cambridge, MA: Massachusetts Institute of Technology, 1998.

  4. Cagno, E., et al., "Project Prioritization in a Multi-Project Environment", IPMA 14th World Conf. on Project Management, Ljubljana, Slovenia, 1998.

  5. Light, M., The Project Office: Teams, Processes, and Tools, Gartner Research, 2000, http://www.techrepublic.com.

  6. Belzer, K., The Program Office: A Business Results Enabler, R. Dorsey & Company, http://www.pmforum.org/library/papers/ProgramOfficeFinal.htm.

  7. Pisano, G., The Development Factory: Unlocking the Potential of Process Innovation, Boston: Harvard Business School Press, 1997.

  8. The Standish Group, "The Chaos Report," 1994, http://www.pm2go.com/sample_research.

  9. Pittiglio et al., Recipes for Growth in Technology-Based Industries, 1998.

  10. Duxbury, L., and C. Higgins, Work–Life Balance in the New Millennium: Where Are We? Where Do We Need to Go? CPRN Discussion Paper No. W/12, October 2001, http://www.cprn.org.

  11. Cooper, C. L., and J. Marshall, "Occupational Sources of Stress: A Review of the Literature Relating to Coronary Heart Disease and Mental Health," Journal of Occupational Psychology, Vol. 49, 1976, pp. 11–28.

  12. Miranda, E., L. Rosqvist, and M. Hultin, Managing Multiple Projects: The Project Office Organization, Roles, Responsibilities, Processes and Tools, Linköping, Sweden, University of Linköping, 2001.



Chapter 2: The multiproject challenge

2.1 Introduction

In a multiproject environment, decisions made within one project tend to affect other, seemingly unrelated, projects—even those not yet in execution.

The model shown in Figure 2.1 illustrates how the consequences of local project decisions, such as raising the level of overtime or delaying the beginning of a task, ripple through the project portfolio via invisible links created by the use of shared resources. The model is based on my own observations over many years—first as a software developer and then as a project manager—as well as the observations of my colleagues and the extensive project modeling work done by Cooper [1], Abdel-Hamid and Madnick [2], and Sterman [3]. The basic assumptions behind the model are as follows:

  • Even the best-planned projects are plagued with uncertainty.

  • Projects in a portfolio interfere with one another.

  • The multiproject environment is a complex behaved system.

click to expand
Figure 2.1: Relationships among principal management variables in a multiproject environment.

2.1.1 Project uncertainty

Uncertainty means variability, and variability is the fundamental rationale behind project management. If there were no variability in the time or effort required to complete a given task, the project approach would be simple: One would simply devise good plans and then execute them. But no matter how good the plan, the estimates on which schedules and resourceallocations are based rest on a multitude of assumptions with respect to task complexity, worker ability, the ability of suppliers to deliver on time, the availability of resources associated with other projects, and even unknown unknowns (see Figure 2.2).

click to expand
Figure 2.2: Sources of scheduling uncertainty. (After: [4].)

A project will finish on time or late depending on which of these assumptions turns out to be valid or invalid during project execution and on how those involved choose to react. The use of probability distributions, such as the beta distribution and the triangular distribution in critical-path calculations, is intended to capture these facts.

2.1.2 Project interference

In the modern project-based organization, projects have explicit and implicit links. These links originate in the sharing of resources and results among projects, extending to other projects in the portfolio the consequences of actions taken within one project. It is for this reason that decisions that seem to make sense in the context of one project might not be such a good idea when considered in light of the entire portfolio. As shown in Figure 2.3, the number of potential interactions among projects increases geometrically with the size of the portfolio and the number of line functions involved in project execution.

click to expand
Figure 2.3: Interactions in the multiproject environment.

2.1.3 Complex behaved system

A complex behaved system is a system whose responses are nonlinear, time-lagged, and time-dependent. The whole is not quantitatively equal to its parts, or even qualitatively recognizable in its constituent components. Results cannot be assumed to be repeatable; the same experiment may not come out exactly the same way twice, as outcomes are not only a function of the input conditions but also of the time at which they occur.

Complex behavior can be seen in any system made up of a large number of interacting constituents, be they atoms in a solid, cells in a living organism, consumers in a national economy, or in our case, projects, resources and sponsoring organizations. But in the multiproject environment, the sheer number of interactions is not the only source of complex behavior; the feedback loops that exist among the principal management variables, and the fact that time is an independent variable, also play a role.

The problem with systems exhibiting complex behavior is that they cannot be steered in the desired direction by applying any single action at any given time—in the case of a multiproject environment, increasing the head count in one project means delaying the start of another, increasing the use of overtime means diminishing the productivity of the whole organization, and not fixing some defects now means fixing them later at a higher cost. There is also an omnipresent risk of "oversteering" the system.