Let me support this call for reform with a brief history of project management and then argue for more than a patch to fix some bug, or for better-trained and motivated managers. We need a new form of project management that rests on a broader understanding of work and a new definition of control. In this new form of management, projects will be managed as a production system designed to get the job done, maximize value and minimize waste.
Think of the way we manage projects, as a suite of “project-ware”made up of the tools and techniques that work together like Word, Excel and PowerPoint do in Microsoft Office. “Project Management 1960.99," the current release, includes modules such as planning and control, estimating, quality control, safety, contracting, and finance. The first release, PM1960, was developed just after the publication in the late 1950s of “A Manual approach to CPM”by John Fondahl at Stanford. Since then, “updates” have been released to enhance its capabilities. Perhaps resource leveling was included in PM1960.65, Integrated Cost Schedule was in PM1960.68 and Earned Value Analysis in PM1960.70. These upgrades have increased our ability to “manage” each piece and its apparent relationship with the project. But the core operating system, the activity centered “contracting” engine, that drives project management has remained unchanged since the first release in 1960.
Here is how it works today. Projects are managed by breaking them into pieces, estimating the time and money to complete each, putting the pieces in order, and then contracting externally or assigning internally to establish responsibility. In either case the pieces or activities are treated much the same. Project managers give each “notice to proceed” on the earliest date. Project controls determine if each activity is within cost and schedule limits. CPM, along with integrated cost/schedule and earned value analysis, turbo-charges the “contracting engine” by strengthening the manager's ability to monitor the application against plan of time and money used to complete each activity. Information from these control systems is supposed to alert managers when activities are over limits. This information itself provides no insight as to cause, rather it is supposed to motivate the responsible manager to discover the cause and take action.
But there was an unintended consequence1. Increased monitoring at the activity level led to greater pressure to assure its performance against budgets. This made it more difficult to move resources between activities to improve project performance. Schedules showed simple sequential relationships between activities and contracts gave owners and general contractors the right to change the sequence and timing of each activity. Activity managers were held accountable for local results even though they lacked the authority to assure them. As a result, each manager worked to maximize their interests with little regard for others. It was a vicious cycle. As managing work became riskier, more was contracted to subs, increasing the focus on activities. By 1985 struggle had turned to a fight. The corrosive environment caused by the project management system itself limited success on even relatively stable projects. Everyone had a favorite villain but no one questioned the role of the activity centered project management system itself or realized that the pressure to optimize activities resulted in sub-optimal projects. A patch2 was required.
1Matzen's law. “For every function, there is an equal and opposite malfunction.”
2A patch fixes an internal problem; a new release adds new functions. A new operating system changes makes possible the solution of different problems.
