Agility and PMI

April 24, 2011 Category Scrum 46 Comments

The Project Management Institute has recently made announcements about its program to incorporate agility into its project management program.  I of course welcome this and look forward to PMI shifting from its previous approach to an agile approach. The test of this will be, of course, the success of the projects that adhere to its principles. In the past, the success (or yield) of their predictive approach has been less than 50% of projects (on time, on date, with the desired functionality.) Most agile methods have a much higher success rate, including the success in cancelling low return on investment projects early. We will watch and see if those that employ PMI’s agile approach enjoy such success, or at least an improvement on the 50% mark^1,2,3.

PMI in the past has embraced the predictive, mechanistic approach to project management. This was first espoused by Frederick Taylor in “Principles of Scientific Management,” which was the basis of the Ford Model T assembly line. It is an approach for predictable, high volume, low cost manufacturing. Its benefits accrue from squeezing all of the unpredictability from the problem space through standardization and repetition. Perfect planning, training, and repeatability are the hallmarks. Plan and then do over and over again. The measurement of success is the yield rate, which is often very near 100%. Productivity is optimized through perfect processes, invariant workflow, and optimized use of resources (people or machines).

Agile processes, by way of contrast, work for development of complex products, where there is some repeatability but there is more new development than old. Products have to be devised anew each time as the requirements, the technologies, and the capabilities and creativity of the people change. In these situations, we’ve found that just-in-time planning, with frequent inspection and adaptation is required. Risks are managed and predictability created by limiting the time span between these planning events, and by ensuring the transparency of all artifacts. We have also found productivity, quality, and creativity is greatly enhanced if the people doing the work also plan their own work. They are not managed as resources, but as people that can do their best when they figure out how to do the work themselves. Self-organization and cross-functionality are vital to the success of these teams.

We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems.

In Scrum, we have removed the project manager. The Product Owner, or customer, provides just-in-time planning by telling the development team what is needed, as often as every month. The development team manages itself, turning as much of what the product owner wants into usable product as possible. The result is high productivity, creativity, and engaged customers.

We have replaced the project manager with the Scrum Master, who manages the process and helps the project and organization transition to agile practices.

How PMI bridges the profound difference in philosophy, thinking, leadership and management between its traditional predictive approach and the new agile empirical approach will be fascinating to watch. How it refashions the role of project manager will be an exercise in agility itself. I for one wish the people at PMI the best. They certainly need a better success rate than 50% to regain the trust of their customers.

———————————————————————-

1. Derived from “The Rise and Fall of the Chaos Report Figures”, January/February 2010 IEEE Software, J. Laurenz Eveleens and Chris Verhoef, Vrije Universiteit Amsterdam.

2. 2009/2010 Standish Chaos Report, Standish Group, indicating:

• 32%   Successful (On Time, On Budget, Fully Functional)
• 44%   Challenged (Late, Over Budget, And/Or Less than Promised Functionality)
• 24%   Failed (Canceled or never used)

3. In addition to a low yield rate (rate of successful delivery), statistics also point out that over 60% of the functionality delivered is rarely or never used, a tremendous waste of development and support funding. Resulting from not prioritizing requirements. http://en.wikipedia.org/wiki/Software_bloat, “Software Bloat.”