Principles, Practices, and Processes to Increase Probability of Project Success
One of the critical success concepts in many domains is "mission assurance." A mission focused to planning is the starting point of this paradigm. This changes the planning process from making lists and checking them twice to defining the mission success criteria and planning the work for their fulfillment.
For an IT program, there are lessons to be learned from another high risk / low risk tolerance environment - space flight:
This approach is the basis the Integrated Product Team (IPT) organizational structures found in aerospace and large construction projects. Transferring this paradigm to IT projects is just starting. There is much to be learned from these other domains.
There were some thoughts on the allocation - or not allocating - risk on a web forum. The "agile" approach was to share the risk amoung the team members.
After responding to those postings that the allocation of risk is one of four risk management steps, I poked around a bit and find some lessons learned on risk management from some "high risk" programs. One example was the Genesis vehicle that orbited the Sun and returned to earth earlier this year. It crashed in the Utah desert, but most of the science was recovered.
There are several "lessons learned" from the initial risk management plan. First some previous lessons learned.
From these learning on many spaceflight programs several solutions have been derived.
The major outcome here is that risk CAN NOT is collectively "owned" it MUST be devolved to the parties effected by the risk. These parties will then be responsible for mitigating the risk in a manner most appripriate to the risk, their technical, financial, and schecule domain.
Just finished an article for Projects @ Work on integrating risk management into the planning process. The next step is to review the probabilistic risk analysis approach used to assess the schedule and cost risk profiles of the Master Schedule.
Here's some resources on this topic
The point here is that before proceeding with a risk management program take a look at how those who manage risk as part of the day-to-day routine do it.
I was reading through a pile of systems engineering presentations in prep for some meetings next week (final pass at Integrated Baseline Review and the inclusion of several dozen trade studies being introduced into the master schedule).
The theme from the material goes like this
Customer Related Inhibitors
Organizational and Cultural Inhibitors
What is the most powerful statement from these materials (a variety of US and foreign systems engineering and program management resources) is...
Systems Engineering and Project Management are two sides of the same coin
I'll go way out on a limb and conjecture that until we in the project management community come to understand this, we'll always be behind the curve when it comes to influencing the outcome of projects. We'll want to be recognized as "professionals" without an actual problem to solve - until we connect the practices of project management with the specific domain of the "project."
Yes the skills of project management have general purpose set of practices - planning, budgeting, assessing, and all that. But in fact those have domain specific practices within themselves. Trying to certifying a project manager based on general competency in the absence of a domain is like certifying an animal trainer in the absence of the animal. Certified Lion tamers are not the same as certified hamster trainers.
Log ago I was sent a paper by Professor Christophe Bredillet of the University of Lille. I was not taken by the paper mainly because is was too wrapped up in the linear process thinking of the day - CMMI appraisals and all.
It is worth looking again "Killing the false gods of Project Management," describes many of the approaches agile project management and development are currently taking. It worth reading if only for the perspective of an academic.
Just as an aside, Rethinking Project Management has some more reports on the topic of "rethinking project management"
I borrowed a book from the shelf of the Planning Manager on our program. Augustine's Laws, Norman R. Augustine, Chairman and Chief Executive Officer, Martin Marietta Corporation, 1986, revised edition, Viking Press.
I have several other "history" books about Martin Marietta and Lockheed that I'd also recommend.Raise Heaven and Earth: The Story of Martin Marietta People and Their Pioneering Achievements, William B. Harwood, Simon & Schuster, 1993.
The Augustine book has many dozen's of Law's as well chapter introductionquotations. The core of the book is Augustine's experiences as the CEO and Chairman of Martin Marietta during growth and merger times. He was the CEO with Martin merged with Lockheed. Some samples for Augustine's Laws focused on business and business development.
Some that resonanted with me regarding the projected benefits of modern software and project management processes, especially agile:
and my favorite all time quote for architecture, process, design, or anything that involves "structuring" the solution
Both books can be found on www.alibrus.com
There was discussion awhile back on New Grange about the risk and opportunity management. The conversation went around the topic of managing risk and managing opportunity using the same concepts.
One approach is to look through guides to the topic before deciding how to approach the issue. Here is a starting point that may prevent the approach of "having to make things up as we go."
The Real Point
The point of listing these materials (and they're just the tip of the iceberg) is there is a wealth of information on this topic - and almost any other Project Management topic - in the public domain. The tendency is to use only what is "gospel" from the offical outlet - PMI is most cases.
This is a mistake. In many instances the PMI approach to project management is both too broad (too general purpose) and too narrow (does not consider domain specific practices) at the same time. Although there are useful elements in things like PMBOK, this is far from the last word on the "body of knowledge" for project management.
In an earlier post the Project Breathalyzer was mentioned. It's time to revisit this concept for several reasons:
So here the basic outline of the Project Breathalyzer. The idea is a Project Manager asks these questions at the morning stand up.
Now there are several ringers here.
The Project Breathalyzer comes from the Software Program Managers Network (www.SPMN.com) and has more detail below the 9 items.
The current issues of Crosstalk has a nice article "Measure like a fighter pilot." Col. John R. Boyd developed the OODA Loop as a winning strategy for air combat. OODA stands for
The phrase getting inside the enemy's decision loop was the result.
What does this mean for Project and Program Management?
Who is the enemy? Why the project of course. No the customer, not the team, not general management - but the processes of the project that are conspiring to cause damage to the success of the project.
A Program Manager should:
For a Program Manager the OODA Loop represents a Principle to Live by.