The Agile Project Management discussion is built around a supposed paradigm shift from the past to the future. Although not as strongly worded recently, the notation that the processes of the past have failed us and we need to move on is still is the “undertone” of the conversation. This conversation fails to distinguish between an inappropriate process and the inappropriate application of an appropriate process.
This issue has been addressed several decades ago in the design of complex systems. I’d like to strongly recommend that Eberhardt Rechtin’ s Architecting Systems serve as a model for how to think about APM.
Rechtin describes four “views” of a solution domain:
- Normative
- Rational
- Participative
- Heuristic
When combined, these four “views” provide a foundation for constructing solutions to complex problems – project management being the current target problem space. Here’s how.
Starting with a normative set of guidelines
- Project accounting - where did the money come from and where did it go?
- Performance measurements - what did I get for the money I spent and in what units of measure do I account for it?
- Responsibility - Who’s responsible for what? How do I know? How does the responsible person or group of persons know?
- What are the success criteria for the accomplishments of the project - What does done look like? How did I recognize it when it comes along?
- When will be done - in some normative unit of measure say time for example or budget?
We can move to the rational layer and focus on
- How do I determine value?
- Does the buyer and the seller agree on the same definition of value?
- Is value recognized by an outside 3rd party, say a COO walking the halls?
BTW is does little good state “we are focused on value flow” if there is no way to measure value in some degree of unit of measure – dollars is a good one.
Participative processes include:
- Providing environments for creativity
- Recognizing that projects are a “solution creation” process and require people to create the solution, not procedures
Finally moving to the heuristic aspects of projects with
- Situationally appropriate processes.
BTW the “situationally appropriate” is a red Flag in any mature manager's eyes. When asked, “Is the process (normative or heuristic) currently employed producing the desired results,” the answer can easily be “well we’re using a situationally appropriate approach” – meaning I can do pretty much what I think is needed for the situation, regardless of what someone thinks is good, better, or best. Not an encouraging phrase for assessor of success, return on investment, and similar questions asked by senior management in our SOX- oriented world. More of an anarchist approach it seems to me.
If we’re searching for a basis of discussion for APM, Rechtin could serve as a starting point, leading to a broader understanding that much of the APM paradigm is already in place in Systems Engineering and only needs to be “read and understood.”
