The July 18/25, 2011 edition of Aviation Week & Space Technology has a Viewpoint article by Aaron Shenar titled "The Shuttle Era: Lessons Learned." In it he speaks of four lessons that are directly applicable to project and program success in any technical or business domain.
But first you need to read Aaron Shenhar and Dov Dvir's book Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation, Harvard Business School Press.
This book, along with IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne W. Ross, Harvard Business School Press, speak to the "decision rights" of managers and the resulting accountability that flows from those rights and the decisions.
The notion of "decision rights," emerged from studies of many 100's of enterprises around the world. Weill qnd Ross argue that IT business value (not to be confused with earned value), directly results from effective IT governance.
Governance is the firm's allocation of IT decision rights and accountability. Shenhar and Dvir speak to five strategies for successful projects:
- Adopt the right management style for each project.
- Understand the inherent uncertainties, complexities, and variables of each project.
- Communicate unforeseen developments accurately to team members.
- Identify the project's unique performance drivers
- Strategically and realistically allocate project resources.
Project Management, Project Governance, and Agile
The notion that agile provides competitive advantage to IT organizations has merit. The notion that agile replaces project management and now it seems that agile replaces "governance," has no merit in the absence of tangible field evidence. There was a post this week about Australian banks moving away from Steering Committees. The notion of replacing a governance process with another process or no process needs to be tested in a variety of domains before we get too excited about a single instance.
Shenar's paper on "Mapping the Dimensions of Project Success," should be read before any decision is made around dropping those pesky steering committees.
The Three Lessons Learned
From Shenar's AW&ST article, here's the three (of the four) lessons learned.
- Short trem efficiency will always result in long term, much bigger, and costly losses. The notion of avoiding "design up front," is just that notional. The statistically sound data that "refactoring" at the architectural level has yet to appear in any credible manner. The cost of change ALWAYS is higher later in the project.
- Executive must listen to the engineers or developers. Without this communication channel the "real" status of a project, the "real" forecast performance and work effort will not be heard. When executives set goals that cannot be reached, they set the foundation for failure. No software development method is going to fix this. If you work in a place where unrealistic goals are the norm, think about finding new work - you're going to fail.
- Developers must analyze the real challenges in their endeavors, and more importantly, find ways to communicate them well to decision makers. By "real challenges" I mean actual risks, their handling, and the plans for the handling. The notion that agile iterations have not cost, schedule, or technical margin is poorly understood outside domains where cost and schedule are managed on a weekly basis. Agile process are fundamentally Level of Effort. "We work down the story list until the money or time runs out." The notion that agile can provide "usable" product at the end of every iteration is wonderful. But the "minimum set of shippable features," needs to be delivered at the planned time for the planned budget. That requires planning, control, and corrective action.
These activities are called PROJECT MANAGEMENT. So when PMI speaks of the "role of project managers" in those Agile CoP webinars, they better be speaking about "project governance" and Decision Rights for the project.
Here's the papers from Shenhar around the topic of "project success."
