Risk Management – the Good, the Bad, and the Ugly
October 11, 2009 @ Herding Cats from Glen B. Alleman
There is a large amount of material floating around on managing risks in projects. I'll start with a nice post at SeaLight, "Making Theory Usable: A Risk Register for the Rest of Us." The top 16 reasons projects fail and the categorizations of the causes of these risk is a useful guide to the discussion of risk and its management.
I'll repeat the 16 items here for effect - with acknowledgment of SeaLight's original post so I can connect the dots:
- Misunderstanding of the requirements
- Failure to manage end user expectations
- Unclear/misunderstood scope/objectives
- Scope creep
- Lack of dedicated, full time project resources
- Lack of frozen requirements
- Bad estimation
- Not managing change properly
- Lack of top management commitment to the project
- No planning or inadequate planning
- Lack of available skilled personnel
- Lack of effective project management skills Improper
- Definition of roles and responsibilities
- Failure to identify all stakeholders
- Changing Scope/objectives
- Poor Risk Management
And another list from the National Audit Office of the reasons for failure:
- Intent
- Sponsor
- Design / Definition
- Communications
- Supplier / Vendor
- Project discipline
The next step in the risk discussion came when I was invited to link to PMPFeed.com. From there, I came across the USCS Extension Project Management site, with an article on a Risk Register along with other articles on risk. These are all good suggestions.
But first let's look at a better tool than the one suggested in the "Making Theory Usable" article.
The Mitre Systems Engineering Program Office (SEPO) Risk Management Tool Kit is one of the better "free" starting points. The down loadable risk register and manual are used in a variety of government domains.
While the narratives at the USCS Extension make some statements about risk, they don't define the source of the risk. A better example goes like this ...
From the Requirements document:
- Requirement reads: "Use Common Operational Picture (COP) in DII COE Release 1.5"
- Identified risk: availability of DII COE version 1.5 when needed
The Risk statement reads:
- IF DII COE version 1.5 is more than 1 month late,
- THEN Program xyz release 1 will experience a day for day schedule slip
So Here's the Bigger Point to all This
When we start down the road of tools, processes, "magic beans," or any other variety of "fixes" for poor project performance, we MUST ask how this proposed solution will address the inherent risks to the success of said project as listed above.
As Tim Lister famously said ...
Risk Management is How Adults Manage Projects
So if you've got a PM 2.0 tool or anything conjectured solution and are trying to convince "adults" that your tool should be adopted for managing their project, you must be prepared to show — in tangible measurable outcomes in units meaningful to the buyer — how this new tool will address the 16 causes and the 6 problem areas of project failure.
Otherwise you'll just be considered a salesman not a solution provider.
Comments
Got something to say?