Previews of Jim Highsmith's new book The Agile Revolution are available on the web from Addison Wesley. I'm interested in the book and I should be excited about the concepts of Agile Project Management he presents. But I'm troubled y several things:
- The view that project management is a road block and an administrative overhead
- Project managers and project management practices are focused on compliance
- Predictability versus adaptability is the choice, where agile projects are adaptable and it is assumed non-agile projects seek predictable approaches.
I know Jim has specific experiences in mind, and certainly the IT world is full of "bad projects." I've managed a few my self. But I've learned over the past 5 years or so - by hanging around large construction, environmental remediation, and spacecraft development projects - that approaches to managing IT projects are seriously flawed when compared to these other environments.
Each construction, environmental remediation, and spacecraft project had a:
- Clearly defined outcome measured in monetary units. "Done" was envisioned several times over, but it was always shared, communicated, and syndicated down to the lowest level of the organization.
- Clear and concise requirements, or a clear and concise as possible at the beginning of the project. These requirements changed many times. Some because of the customer, some because of an unanticipated discovery, some because the solution turned out to not actually work.
- Unequivocal measures of success, both monetary, technical, political, and operational. Agile does this well by the way.
- Risk management processes in depth. 2 or 3 layers deep. For technology, funding, operational, and general unanticipated problems risk management. "Risk Management is How Adults Manage Projects," was a posted hanging in our work area at one Multi-Billion Dollar environmental remediation project.
Capability Based Planning and IMP/IMS
So what's different between a "poster child" IT project Jim speaks of where project management is seen as an unnecessary overhead and project managers just get in the way of progress and my recent experience in project and program management?
- Maturity of the organization? These companies are project centric. They manage projects for money. "Project Completion Services," was a NPR sponsorship tag line for one of my former employers.
- High Risk / High Reward / High Experience? The three firms I mention engage in high risk / high reward projects for the most part. Maybe not all monetary rewards (7%GM is about the government rate). But managing in this environment seems to bring out the best in people. Either through skill and cunning or through natural selection.
- Professional roles? The three firms from my experience, and the mentoring firms we used as well as neighbor firms all treated project management as a core competency. The technical staff knew this, was involved daily in the project management processes and was rewarded by the project managers success as well as their own. One large construction firm promoted project managers to VP positions (I was one), and emphasized a ladder of business progress starting at associate project manager.
What's interesting from my point of view is all these examples treated projects as "increasing" maturity assessment opportunities. Planning is done with a "planning horizon." The future is vague, the present needs to be stable. Exploration of alternatives is good risk management - "risk buy down" is the operative term. Technology insertion, technology and managerial on ramps and off ramps (code words for immediate adaptability to change) are explicitly programmed in to the planning process. Explicit (monetary) measures of value are mandatory (Earned Value or some equivalent) are used along with Technical Performance Measures.
By the way, the use of the term "customer value" in the Declaration of Interdependence for Agile Project Management has no units of measure, therefore it has no business value in practice. It's a wonderful principle, but in practice is of little use without a unit of measure.
TPMs have monetized units of measure to go along with their technical compliance units (mass of the final product versus cost versus time to market as a function of invested cost and schedule is a common discussion topic in the morning stand up on my current project).
Program maturity assessment points, with significant accomplishments, accomplishment criteria and supporting tasks are mandatory. Along with the Program Events that explicitly map to the statement of work, the customer value stream (monetized technical performance measures) and 0%/100% measure of "done" on fine grained boundaries. These are the "currency" of project managers in construction and aerospace.
What would happen if IT projects were to adopt some of these measures, processes, maturity assessment approaches, paradigms for defining "done?" Would the role of a project manager be seen as overhead any more? "Buy pizza and say out of the way?" may become rarer. Would actual bookable value to the firm be made visible to all the participants on the project raising the esteem of the project manager?
Maybe in IT we're trying to solve the problem in the wrong way. Maybe we should look at the successful project management methods in other domains and ask if they know something we don't.
I've order Jim's book never the less. The more the idea that project management is a profession the better.
