Frank Patrick commented on my quick post on what the OP called Top Down compared with Bottom Up project management. I had not meant to be so blunt as Frank made me out to be. But on second thought he's right.
Starting the discussion of PM 2.0 in the way the OP started, is a non starter. There is no actionable outcome. Just buzz words, poor comparisons, and no path to increasing the probability of success.
First, the comparison between Top Down and Bottom Up is not the comparison between tradition and agile. Top and Bottom are topological terms not verbs describing the functions of project management.
Second, is the use of the words in the Top Down. Inflexibility, Bureaucracy, Overall Control, Imposed Processes, and my favorite No Moral Motivation. I won't use Frank term. My term is Nonsense.
Nonsense, first in there is no context, no examples, not domain of applicability for that presentation.
Nonsense, in the comparison of the agile terms flexibility, agility, collaboration, and high motivation.
Who says formal CMMI ML5, full NASA verification and validation software development projects have no moral motivation. Wanna see grown men cry like babies. Attend a launch of a Mars Oribtor. Be in the control room when that orbitor is captured at Mars. Or better yet be in the control room when a sample return vehicle crashes in the Utah desert after 3 years flying around the sun. No moral motivation my ass.
If the role of project management is ever to improve, we must do the following:
- Stop labeling the processes as agile, traditional, waterfall, or what ever, without also stating tangible, measurable, and verifiable beneficial outcomes for each of the labels. Agilest who do so have unlikely ever worked a project where formal methods are successful. So it'd be hard for them to know what that what they are complaining about is actually bad management.
- Stop confusing bad management with bad processes. This is the most often encountered mistake with agilest who are not actually project managers in the domain applicable for more formal methods. Instead they start with software development paradigm and extend their experiences to the role of the project management.
- Understand that developing software with Scrum is not managing the project in which the Scrum developed software is a participant. No matter how hard the agilest want us to believe this, software is one part of the solution to the problem. Yes, many of the methods found in Scrum are applicable to managing the overall project. But it does not replace many other methods needed for success.
- Start defining effective project management processes in units of measure meaningful to the participants. "If you do this, you will achieve a 10% reduction inf rework of technical specifications." Things like that. Remember Jerry McGuire - "show me the money."
- Demonstrate these process are effective in specific, named, domains, and contexts. No more blather of "my buzz words are better than your buzz words."
To improve the profession and processes of project management we must ask and answer the following:
- What processes - no matter what they are - increase the probability of success?
- What are the mechanisms of this improvement, so we can understand how they scale, where their inherent weaknesses are, and where the latent risks reside?
- What measures can be found that show these processes are effective in a statistically sound manner. With real, validated data, using credible sampling and measurement techniques?
- And most importantly, how the lessons of the past can be used to improve the probability of a projects success in the absence of the traditional agilest approach - "old ways are bad, new ways are good." Alistair Cockburn's works are a good place to start. Domain and Context sensitive. Outcome Based. Theoretically sounds and buzz word free.
That's the basis of Project Management 2.0
Let's get started and stop the nonsense of confusing buzz words with actionable outcomes that beneficially impact the success of the project.
