[2] Introduction

During the 4th quarter of 2001 the leadership team of Confluence, a software development company in Pittsburgh, undertook four simple but extraordinarily powerful changes to the management process of the company.

* First, the leadership team adopted an enterprise-wide prioritization and scheduling policy for all the projects of the company.

* Second, the leadership team enacted a weekly meeting between a high-level executive and all the resource managers of the company, during which the near-term deployment of the company’s development resources was determined (that meeting continues at this writing).

* Third, the leadership team required the use of a more effective project-planning process for all new development projects.

* Fourth, the leadership team acknowledged the existence of variation in task duration and in project duration, by requiring the project plans of the enterprise to account for such variation in their designs.

The effectiveness of these changes is illustrated by the control chart of the duration of the projects of Confluence, for the two years before the management changes and for two years after the management changes. Average project duration was reduced from 140 business days per project to a mere 46 days per project. The rate of project completion increased from six projects per year to more than eleven projects per year. And throughout the entire period, Confluence did not hire a single additional developer.
Of the four changes that created such a massive improvement in the logistical performance of Confluence, the first two can be implemented exclusively by the leadership of a company (these will be discussed in a later work that I intend to leave for the two of you). No project manager possesses the authority with which to make the first two changes happen. But the latter two changes (the use of a more effective planning process and the development of project plans that capture and minimize the effects of variation) were merely enabled by the leadership of the company. These latter two changes are entirely within the span of authority of any willing project manager, and they are the heart of Robust Project Design. They will be within your span of authority during the early portions of your careers, when you are most likely to contribute to project plans or perhaps even to manage entire projects. I base the rest of this work on the assumption that at some time early in your careers one or both of you will be asked to fill the roles of project managers.

However, I must also caution you. Although your use of Robust Project Design will yield a measurable benefit, you cannot ever hope to achieve for your employer all that Confluence achieved, unless the leadership of your company deploys the same enterprise-wide multi-project scheduling policy and the weekly meetings. Still, your use of Robust Project Design can bring a non trivial improvement in performance, and it may even alert the leadership of your company that it is possible to nearly double the company’s throughput of projects without hiring a single additional developer, with just some minor policy changes. Your use of Robust Project Design also will provide you with useful, predictive models of your projects, rather than the highly misleading models that your counterparts will be creating.