Herding Cats

Risk Management - the Good, the Bad, and the Ugly

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:

1. Misunderstanding of the requirements
2. Failure to manage end user expectations
3. Unclear/misunderstood scope/objectives
4. Scope creep
5. Lack of dedicated, full time project resources
6. Lack of frozen requirements
7. Bad estimation
8. Not managing change properly
9. Lack of top management commitment to the project
10. No planning or inadequate planning
11. Lack of available skilled personnel
12. Lack of effective project management skills Improper
13. Definition of roles and responsibilities
14. Failure to identify all stakeholders
15. Changing Scope/objectives
16. Poor Risk Management

And another list from the National Audit Office of the reasons for failure:

1. Intent
2. Sponsor
3. Design / Definition
4. Communications
5. Supplier / Vendor
6. 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.

Revisiting Risk Management

Andrew Sparks Blog on Oracle's site mentioned a book he just read, The Failure of Risk Management. I have not read this book, but the publisher's jacket description and the Amazon reviewers like the book. What struck me as interesting was a comment from a reviewer about the issues with how risk management is performed (as described by the author)

• Subjective scoring methods
• Independent events that create dependencies
• The famous "black swans"
• Empirical risk management

The appears to be a good description of the failings of risk management. My thought was the author and possibly the reviewers have not read other works on risk management. Works used by those accountable for managing engineering and programmatic risks.

Here's a few we use on the programs we work. These guide the "management of risk" in ways that are the source of failure described in the book.

• The DoD 2006 Risk Management Guidebook, 6th Edition (Version 4.0) 4 August 2006. 

This site will prompt you to accept a certificate. Go ahead and accept it, it's the US Department of Defense. This is the guidebook for program managers on US DoD programs. Managing Cost, Schedule, and Technical risks is the critical activity for producing a credible Performance Measurement Baseline.

• "An Approach to Technical Risk Management," Richardo Valeridi and Ron Kohl, MIT Systems Engineering Division.

The MIT Systems Engineering Division is a source of guidance for many aspects of systems development. Risk management is a Systems Engineering discipline. This paper is just a sample of the materials available at MIT.

• The Software Engineering Institute has a Risk Management section.

New Directions in Risk: A Success Oriented Approach, Audrey Dorofee and Christopher Alberts, is a good starting point for the framework of how SEI views risk management.

• Mitre Corporation's Systems Engineering Program Office is a good resource for risk and system architecture. Mitre has a Risk Management Toolkit, that can be directly applied to any program. It has an Excel risk management model and a handbook.

• Edmund Conrow's book Effective Risk Management: Some Keys to Success, 2nd Edition, AIAA Press is the corner stone of our risk management approach. If you're going to buy one risk management book, but this one. It's expensive, but it's got everything you'll ever need to be a credible risk manager. This is not a survey book, or a book written for those entering the field. This is a heavy duty technical textbook.

• Visit the government and commercial sites for some more background:
  

• NASA's Risk Management
• The archive of risk management papers at NASA
• Bayesian Inference for NASA Probabilistic Risk and Reliability Analysis. This is the background material needed to avoid the errors in estimating the risk so commonly found in IT and general environment projects. This is how the "big boys" think about risk.
• Department of Energy Risk Management and the O 413.3-7 Risk Management Guide
• As an example here's guidance for "accelerated path to closure" and the Programmatic Risk processes. I was a participant in the programmatic risk planning for a small section of a Department of Energy Nuclear Weapons plant closure project.
• Aerospace Corporations Risk Management Quick Reference Guide
• "Understanding the Roots of Process Performance Failure," Laura Dwinnel, CrossTalk, April 2004. CrossTalk is a good source of software management information. The items mentioned here need risk mitigation plans.
• Probabilistic Risk Assessment, this is a core manual for anybody working in the technical risk management world.
• RiskWorld
• Risk Doctor
• The Genesis Project Case Study. This is a program I'm familiar with. I was in a briefing room, when the spacecraft crashed in the Utah desert. The colored chart at the end of the presentation is a unique approach to describing the "risk retirement" processes that must be present in any credible project management process.

This is just the tip of the iceberg regarding risk management.

The reviewed book is probably a good starting point for the uninitiated project manager. But there are valuable resources on the web for managing programmatic and technical risks as well.

First Pass of PMI Practice Standard for Project Risk Management

I've started through the PMI Practice Standard for Project Risk Management.

First my biases in general. The absolute best book on "risk" is Ed Conrow's, Effective Risk Management: Some Keys to Success. I have read and reread this book dozens and dozens of times. It that kind of book. Each read brings out something new. As well the history of PMI's risk approach was based in the risk value of Probability of Occurrence x Impact to give a risk value. This is simply not possible in the mathematical operator world, since the probability of occurrence is a Probability Distribution Function (an integral equation) and the impact is a scalar value. Multiplication is not defined between these two constructs. 

The new practice guide moves away from this notion toward the accepted DoD approach of defining the elements of the Probability and Impact Matrix. But does a weak job of stating how to construct the various elements. Look in the DoD Risk Managers Guide for a much better approach.

After the first read there is two show stopper concepts:

• There is no formal separation between technical risk management and programmatic risk management.
• They include the notion of threat and opportunity.

Only if the Project Manager is a technical manager can these two notions be handled by one person. There is a picture in Figure D7 that lists the taxonomy of risk - the Risk Breakdown Structure (RBS). This notion is poorly developed when compared to places like NASA's Probabilistic Risk Analysis handbook and the INCOSE Systems Engineering Handbook. But I would suspect the authors don't travel ion those domains.

• Technical Risk – uncertainty about the functional and performance aspects of the program’s technology that impacts the produceability of the product or creates delays in the schedule
• Programmatic Risk – uncertainty about the duration and cost of the activities that deliver the functional and performance elements of the program independent of the technical risk

Without separating technical from programmatic risk, the management of risk is clouded by the possible "risk handling" processes. They are not identified, classified, handled, reported, or analyzed the same.

I have mixed opinions about the threat / opportunity notion. Rarely are threats and opportunities. Interchangeable. They should not be treated in the same discussion. This is a very IT centric view of risk management, so I'll stay away from the discussion. The article "Opportunity Management: By Careful What You Ask For," Edmund H. Conrow and Robert N. Charette, Defense AT&L, March-April 2008, should be your starting point before getting excited about mixing these two concepts.

This brings up another issue. PMI likes to invent their own set of words and processes, when there are already well defined and broadly used definitions for the processes. SEI's Continuous Risk Management (CRM) and DoD's Risk Managers Guide have clear and concise definitions of the risk management processes. No need to invent yet another set of confusing words, in an already confusing world of risk management.

A previous post Risk Handling shows two options for this.

For all those wanting or needed to start at the beginning for risk management here's Risk Management in Five Easy Pieces.

So far I'm luke warm on the Practice Guide. It's all personal and all based on the defense and space point of view.

Risk Management Resources (Updated)

The previous post titled Risks are Not Issues triggered by several things.

• The notion of risk mis-applied in many IT domains as the management of "issues"
• Many - OK most - non-defense or non-mission critical environment - risk approaches have serious flaws.

So here's a set of risk management resources that have served me well over the years. These are available on the web, but I've moved them to the local library for convenience.

• Dealing with UNK UNKs
• DoD RMG 2006
  
• Managing Project Uncertainty Variation to Chaos
• Project Management Under Risk
• USN Top11 Ways Risk
• Uncertainty Ambiguity and Complexity in PM
• Uncertainty and Project Management
• Risk Management Consolidated Training

These are the tip of the iceberg of ~600MB in the local file server on the topic of programmatic risk. This does not touch the materials on technical risks in a variety of domains and contexts.

I'll keep adding to the list. I'm writing the Risk Management section of the Management Approach in the tech Volume of an Air Force proposal this week and next

Risks and Issues Are Not The Same

Josh has a nice post on his PMStudent blog from Susan de Sousa speaking the "Contingency Plans." A bit of reading reveals this is actually about risk management. Risk Management is of course part of project management. Tim Lister's quote...

Risk Management is How Adults Manage Projects

is the good starting point for all discussions around riks.

But when you follow Susan's link down into her Blog where the topic of risk management is discussed you'll find lots of useful information. But there is a critical disconnect there and many other places in the risk management world.

Risk ≠ Issue

This is a common mistake and one made by Susan. She lists some risk developed in a work shop

Now these risks should fall into one of the following categories which are:

1. Management - The risk that there won't be enough Sponsor or Stakeholder input to ensure business requirements are delivered.
2. Resources - The risk that there will not be enough resources available to deliver the project
3. Requirements - The risk that the requirements will not be either fully specified or not correctly understood
4. Technical - The risk that the proposed deliverables cannot actually be delivered, or else won't work utilising the technology used within the Organisation
5. Environment - The risk that something will change in the environment the project will utilise.
6. Acceptance - The risk that either the Project Sponsor / Client will want to change the scope of the deliverables, or else will not accept the defined deliverables once developed.

These are not risks, they are issues. They are issues that are impediments to the progress of the project. But they are not risks as defined in all risk management books, government guidance, and even the PMI PMBOK Risk Management Chapter.

If this confusion is made the project balloons with risks and the project management becocmes a clerk trying to manage all the issues masquerading as risks.

Let's start with the US Department of Defense definition of risk:

Risk management is concerned with the outcome of future events, whose exact outcome is unknown, and with how to deal with these uncertainties, i.e., a range of possible outcomes. In general, outcomes are categorized as favorable or unfavorable, and risk management is the art and science of planning, assessing, and handling future events to ensure favorable outcomes.

From the DoD Risk Management Guide, 2006:

Risk is a measure of future uncertainties in achieving program performance goals and objectives within defined cost, schedule and performance constraints.

Risks have three components:

• A future root cause (yet to happen), which, if eliminated or corrected, would prevent a potential consequence from occurring,
• A probability (or likelihood) assessed at the present time of that future root cause
• occurring, and
• The consequence (or effect) of that future occurrence.

Now let's look at the "risks" listed from the post

1. The risk that there won't be enough Sponsor or Stakeholder input to ensure business requirements are delivered. This ISSUE must be dealt with in the chartering session. A Responsibility Assignment Matrix defines the accountabilities of all the project members. Failing to provide te needed information from the right person is n "Issue" that must be addressed in the weekly status meeting.
2. The risk that there will not be enough resources available to deliver the project. This ISSUE is a resource planning and management failure. We know the number of needed resources, we know the capacity for recruiting and retention. A plan to sustain the project is needed.
3. The risk that the requirements will not be either fully specified or not correctly understood. This Issue is directly addressed through the requirements management process.
4. The risk that the proposed deliverables cannot actually be delivered, or else won't work utilizing the technology used within the Organisation. This Issue has some parts risk and some parts issue.

So let's look at 4. to see how to sort this out.

There is a probability that the deliverables don't do what we want them to do. But getting to do what we want them to do is an "issue." Planning, execution, testing, verificcation and validation are part of the issue.

Where the risk comes in is that the deliverables can NEVER be made to do what we want them to do. You'd have to invent new physics to get them to do what we want them to do. That is where the risk part comes in...

There is a probability that what we have planned (and assumed we could execute if we did our job right) will not actually work.

That's a risk. Everything else on the post regarding risk is pretty much an Issue. A final piece of advice from the DoD Risk Management Guide

Risk management is the overarching process that encompasses identification, analysis, mitigation planning, mitigation plan implementation, and tracking. Risk management should begin at the earliest stages of program planning and continue throughout the total life-cycle of the program. Additionally, risk management is most effective if it is fully integrated with the program’s systems engineering and program management processes—as a driver and a dependency on those processes for root cause and consequence management. A common misconception, and program office practice, concerning risk management is to identify and track issues (vice risks), and then manage the consequences (vice the root causes). This practice tends to mask true risks, and it serves to track rather than resolve or mitigate risks. This guide focuses on risk mitigation planning and implementation rather on risk avoidance, transfer or assumption.

Risk Management

There have been several posted recently about "management of risk." Many times risk gets mixed up with issues.
    The best place to start to understand how risk management is performed, is to look at how it is performed in the world where risk is always present and the consequences of not "handling" risk are severe.
    The US Department of Defense Acquisition Technology and Logistics Community of Practice site has a Risk Management group. There are many other communities at DAU, so browse around to see what else is interesting.
    This link may ask you to confirm the certification acceptance. Most DoD sites do this. So answer "yes" and proceed with confidence.

Managing in the Presence of Uncertainty

    There are some in the project management and software development community that insist on use Waterfall, determinism, and point estimates as the starting point for the counter argument in support of their favorite method.
    For those sign up for the Uncertainty in Engineering course at MIT OPEN Courseware. This will provide some insight (hopefully) into how engineering and the related projects management profession work in the presence of uncertainty.

    The MIT Open Courseware site has a wealth of resources on a wide variety of topics. Many are project management focused in constuction and aerospace engineering.

Risk Management and Project Principles and Practices

Paul made a comment regarding the role of risk management for the previous post. The topic of risk management has many points of view:

• PMBOK(r) Chapter 11
• DoD PMBOK(r) Chapter 11
• DoD Risk Management
• David Hillson's approach described in his several books, Effective Opportunity Management for Projects, being a recent one
• Edmund Conrow's approach described in Effective Risk Management, AIAA Press
• SEI Continuous Risk Management
• INSEADS paradigm of four views of managing in the presence of risk
• NASA's Risk Management paradigm
• US Department of Energy's risk management paradigm
• MOASIC (Mission-Oriented Success Analysis and Improvement Criteria)
• Tools like Active Risk Manager and Ares's risk tool as well a Mitre's risk tools and paradigm

I've applied, used, or been involved in the application of each of these paradigms. Personally I'd not recommend PMBOK, instead read DoD PMBOK as a start. Depending in the domain and context any one of these - other than PMBOK(r) Chapter 11 - could be applied.
    But, and this is a very big but, risk management is not in the same league of an individual process area or a practice. It is separate and at the same time all encompassing. Those doing this best are working in the space flight business. There the role of Safety and Mission Assurance (S&MA) guides he risk processes. This includes:

• Identification and management of the risks and their handling.
• The Program Planning and Controls staff "owns" the role of programmatic risks and integrates these risks in the Integrated Master Schedule
• The Systems Engineering staff "owns" the role for technical risk in terms of impacts on the system
• The Technical staff "owns" the role of mitigating or retiring - retiring being preferred - for their individual disciplines. The SE's for the system as a whole.

Here's a very simple view of the interconnections of cost, schedule, and technical perfomance with the risk activities between the three.

In the absence of a 3 day workshop and a specific context and domain, this picture shocul be considered "notional."
    While risk is considered along with cost, schedule (not time), and Technical Performance, it is also an over arching process. A Systems process. But this diagram speaks to the artifacts of the risk management practice - cost, schedule, and technical performance margins. In the NASA approach and other DoD views, risks are defined as possibilities and need mitigations or retirement plans that impact cost, schedule, and technical performance.
    But this narrow band channel of a blog limits discussion around this important topic. Suffice it to say the PMBOK approach is not the starting point. Instead I'd recommend the SEI Continuous Risk Management book. But that is just a process maturity assessment outcome guide - with descriptions of what a good risk management process looks like. Conrow's work is the seminal approach for domains I work in. There are a multitude of dimensions to risk management, so a single paradigm will rarely cover what is needed in practice.

There may be other works in other domains.

Project Failure Modes

Lots of conversations around why projects fail. One of the best lists I've come across is from the UK OGC Best Practices site - with some slight edits for non-governmental domains.

1. Lack of clear links between the project and the organization's key strategic priorities, including agreed measures of success.
2. Lack of clear senior management and business ownership and leadership.
3. Lack of effective engagement with stakeholders.
4. Lack of skills and proven approach to project management and risk management.
5. Too little attention to breaking development and implementation into manageable steps.
6. Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits).
7. Lack of understanding of, and contact with the suppliers of technology at senior levels in the organization.
8. Lack of effective project team integration between clients, the supplier team and the supply chain

Learnings from Risk Management training

Working on some proposal language and came across a PMI Risk SIG May, 2005, Tim Lister found several critical concepts:

1. The biggest risk an organization faces is lost opportunity, the failure to choose the right projects.
2. The real reason we need to do risk management is not so much to survive the risks, but to enable risk taking.
3. The only reason to quantify cost (schedule and budget) is to have something to compare the quantification of the benefits against.
4. There is no sense making cost quantification more accurate (precise) than the value quantification.
5. An aggressive delivery date is often driven by cost containment, not by the actual delivery date.

Risk Handling

An agile thought leader provided an advanced outline of a paper on integrating risk and real options for an upcoming conference. A comment was made that traditional project management tries to "avoid" risks. Risk management has four options for "handling" a risk, with Avoidance being one:

1. Control the risk - lower the probability of the risk event occurrence.
2. Avoid - eliminate the opportunity for the risk to occur.
3. Assume - acknowledge a future risk event and accept the potential consequences without efforts to control it.
4. Transfer - reduce the risk exposure by reallocating the risk from one part of the system to another part.

The framework in which these "risk handling" options are available is guided by one of two concepts.
The DoD Risk Management Guide

Or the Software Engineering Institute Continuous Risk Management Guidebook:

    Both provide clear and concise guidance on how to management a Risk Management program, the elements of that program, and the artifacts that are produced during the operation of the program.
    So when something is mentioned about "risk management," looking at one or both of these framework may provide insight into how to conduct risk management in your project.

Risk Management in Five Easy Pieces

Risk management is essential for any significant project. and is useful for any project where an unfavorable outcome is undesirable. Certain information about key project cost, performance, and schedule attributes are often unknown until the project is underway. The emerging risks that can be identified early in the project that impact the project later, are often termed “known unknowns.” These risks can be mitigated with a good risk management process. For risks that are beyond the vision of the project team a properly implemented risk management process can also rapidly quantify the risks impact and provide sound plans for mitigating its affect.

Risk management is concerned with the outcome of future events, whose exact outcome is unknown, and with how to deal with these uncertainties. Outcomes are categorized as favorable or unfavorable, and risk management is the art and science of planning, assessing, handling, and monitoring future events to ensure favorable outcomes. A good risk management process is proactive and fundamentally different than issue management or problem solving, which is reactive.

The Five Pieces are:

1. Hope is not a strategy
2. All point estimates are wrong 
3. Without integrating Cost, Schedule and Technical Performance you’re driving in the rear view mirror
4. Without a model for risk management, you’re driving in the dark with the headlights turn off
5. Risk Communication is everything

Risk Management is How Adults Manage Projects

This title has been posted before. It's good to remind yourself every once in awhile of the phrase. I'm headed to the nations capital during the inauguration to work a program as the Senior Risk Adviser. This position supports the Program Manager and his staff in the context of programmatic and technical risk.
    This brings me to a quote:

"A good project plan has some form of contingency, mitigation, or alternative action built in to allow time for critical decisions" David Mercer, National Grid, Warwick, England (Liquefied Natural Gas plants and transmission system of 4,100 miles of pipeline)

Not only decision time, but recovery time for less than planned technical and programmatic performance.
Planning is Necessary but not sufficient, You have to Have a Credible Plan
    An agile thought leaser once side in a quote in a book

do the planning, but throw out the plans

which is course is completely wrong, "It isn't even right enough to be wrong," as Wolfgang Pauli says.
    Plans are the strategy for the successful completion of the project. Success almost always means the delivery of the deliverables that provide the business value the customer ordered. So if you have a Plan, what are the risks that will prevent the successful delivery of the deliverables that represent the business value? What are the mitigation's and or retirement's of those risks? Are those mitigation's and or retirements budgeted, resourced, and scheduled? If not, you don't have a credible plan. In fact your Plan is now a risk unto itself.
    If you follow the agile thought leaders advice "do the planning, but throw out the plans," you late and over budget before you start, and most likely the value you're trying to deliver is going to disappoint as well.

Going to the Dark Side

    I'm not a PMP. I'd like to, but I'm not motivated. Besides, I'd have to unlearn several things in order to pass the PMP.
    BUT, there is a PMI-RMP that I've signed up for. And there is the PMI-SP, the Scheduling Professional. Both I could get into. But the Risk Management Certification will be the first. Chapter 11 of PMBOK is about risk management. There are a few flaws in Chapter 11. Multiplying probability of occurrence with outcome to get a risk rank is one problem. The two variables are probability distributions and multiplication is not an operator on an integral equation representing the probability distributon function.
    The second issue is the Department of Defense has a Risk Management Work Flow. PMI has process areas. These areas have a linear relationship and a single feed back loop. The DoD PMBOK version has all the same chapters, but much correct guidanmce in many areas. It's also FREE. DOD PMBOK Chapter 11 has a diagram showing the process flow and has words around how to develop a "risk value" that does not involve doing un-allowed mathematics.
    So I've bought the study guide, reading the PMBOK Chapter 11 again and this time making notes and filled out my application. Maybe by the end of the year I'll be a Certified Risk Manager.

More Thoughts on Risk Management

I'm preparing a paper for the 2009 NASA PM Challenge conference. Walter Majerowicz is a constant contributor to the professional of project and program management. I finally met Walt at the PMI College of Scheduling conference this year.
In a previous PMChallenge presentation, Walter mentions several sources to project and program risk that are worth restating.

• Poor or unrealistic activity duration estimates - the "art" of estimating is largely overrated. Using probabilistic estimating techniques where the upper and lower bounds of the cost or duration is the starting point. With these estimates, classified is a geometric expansion series, the sensitivity of the cost and schedule model can be exposed. The traditional estimating process of asking for "high" and "low" estimates has been to shown to be seriously flawed.
• Deterministic / single point activity durations in logic network not based on expected value of 3-point estimates - "no single point estimate can be correct," is the starting point for programmatic risk reduction. All cost and schedule values are random variables. Without understanding the statistics of these random variables, the schedule and cost models will be wrong.
• Not capturing 100% of total work scope in schedule - no side bar work, not under the covers work, no work can be performed on the project that is not scheduled to be performed.
• Inadequate or incorrect resource planning - the notion that people will sort out the sequencing of the work for themselves is nonsense. A resource assignment plan at some level of granularity is needed.
• Inadequate or poor project logic - in what order the work is to be performed is the basis of utilizing resources and producing increasing value. This sequence is held in the Schedule.
• Insufficient schedule reserve - with cost and duration values being random variables, schedule and cost "margin" is needed. How much margin needs to be determined by some analytical means. Guessing and using some standard (20 days per year) usually is wrong. Knowing where to put the margin is the next step. Solving this problem is the role of Monte Carlo Simulation.
• Multiple convergence paths / merge bias - this is a subtle but critical issue. Parallel work tends to drive the delivery date later. This is counter intuitive but it is a fact. Look for the term "merge bias" to read about the theory.
• Overuse of directed constraints that override true schedule logic - a good schedule has all the tasks marked "AS SOON AS POSSIBLE." All other constraints need to be "real." The START NO EARLIER THAN and FINISH NO LATER THAN approaches are the kiss of death for analyzing the impacts of schedule slippage on the outcome
• Unrealistic schedule baseline – if the schedule is not credible to begin with, it never gets better
• Poor performance – late starts mean late finishes. No completing on time – as planned – simply pushes all the work to the right. The developers (or any project content provider) MUST start on time in order to finish on time. Late finishes usually mean late starts for the next collection of tasks. You can't make this up by working harder. That just spends more money.
• Uncertainty in work scope (e.g. new design, advanced technology, new processes) – adding more variance to the schedule cannot improve its credibility.
• Inexperienced project management – nothing succeeds like success. You’ve got to start somewhere, so start as a deputy to a good project or program manager and learn the ropes from her success.
• Improper or poor change control – the baseline is just that. Making changes in the absence of an impact analysis is nonsense. “Emergent” anything needs to go through a change control process. Simple, informal, formal – it doesn’t matter in the end if the right questions are asked and answered.
• Complex organizational interfaces – the more touch points the more places things go wrong. Managing the interfaces is a Systems Engineering discipline. Learn from the profession of Systems Engineering how to do this right.

Risk Management is How Adults Manage Projects

If your project management method does not start and end with Risk Management, you're whistling in the dark, hoping things will work out.

• Hope is not a strategy - hoping to get things done on time, on budget, on specification is not the same as having a plan to get things done. Having the plan does not mean it will happen. But not having a plan assures is will not happen
• All point estimates are likely wrong - cost and durations are random numbers drawn from an underlying probability distribution
• Follow a risk management processes - the DoD process is probably the best. There are others.
• The connection between cost, schedule and technical performance is inseparable - there is a lot of noise about "breaking the Iron Triangle" of project management. It is just that "noise." These three independent variables are inseparable. These re three of the irreducible elements of project management
• Communicating all this information is not an option - having a risk management plan (RMP), a risk communication plan (RCP) and all the other artifacts of risk management is important. But most important is showing the risk, their mitigations and retirement in the schedule

In the end is the risk mitigations or risk retirements are not in the schedule, with dependencies, resources, and funding - then when the risk become an issue - you will have already failed.

The Best Risk Management Sites on the Web

• Risk Doctor
• DoD Risk Management
• PMI Risk SIG
• Mitre Risk Management
• APM Risk Management SIG
• UK Institute of Risk Management
• OGC Guide to the Management of Risk

Doing Risk Management Right

Many organizations give lip service to managing technical and programmatic risk. They say they are doing risk  management, but of course they are not. This is more common than you might think, even for large enterprise projects. Managing risk as part of the project management process is the right thing to do. It is also a hard thing A simple motivation is o remember:

Hope is Not a Strategy

Simple words, but of course it's harder than just reciting a phrase. But a second motivation can be:

"What if" is worry, "If then" is action - action beats worry every day

This can be the start of actionable outcomes for managing risks.
    There are several good risk management process flows. The DoD version is the best. The PMBOK one is OK, but just OK. This months Harvard Business Review has two articles on risk. While these are targeted as business risk management, they have all the core elements of project risk management. One has a nice, simple, clear and concise set of processes:

1. Identify and understand the major risks - many organizations confuse risks with issues. Which risks will actually put the success of the project in jeopardy?
2. Decide which risks are natural and therefore which ones should be retired as part of the normal project activities and which ones should have mitigation plans shoudl they ever come to be true.
3. Determine the capacity and appetite for risk- there is no sense scaring everyone if they don't have the appetite for dealing with the risks. The risks won't go away, but at the same time they won't be handled.
4. Enable risk management in all project management and technical decision making processes.
5. Align the project governance process and the organization management processes around risk. Build a system and infrastructure for monitoring and managing technical and programmatic risk.

Reasons to Avoid Risk Management

The DACS Gold Practice (tm) Practice Series, Formal Risk Management speaks to the reasons risk management is more difficult than it appears.

• We have no cost/schedule risk because new technology will increase our productivity by 5-to-10 times.
• We are using a proven method, so it’s not a risk. The conference speaker said so.
• Our job is to develop software, not fill out bureaucratic forms.
• No one on the staff knows how to do risk management.
• This is development…why should we worry about supportability and maintainability risks.
• My customer doesn’t want to hear that he/she is a source of risk
• We deal with problems as they arise.
• Our customer goes ballistic whenever he/she hears of a potential problem.
• Making our risks public will kill the project.
• Give us an hour and we’ll tell you our top 10 risks.
• We have no risk.
• Using that tool is not a risk. The vendor said so.
• The project is too small to do risk management.
• New technology we’ve never used before will mitigate the risk.

It's breathtaking how many of these statements found in large and mature IT organizations.

Risk Management Resources

The topic of Risk Management has come up again at a number of clients. As well I'm presenting at the Denver PMI Symposium with a topic titled "Risk Management in Five Easy Pieces," with full With apologies to Carole Eastman and Bob Rafelson for their 1970 film staring Jack Nicholson.

Those Five Easy Pieces are:

1. Hope is not a strategy, only preparation is
2. No point estimates of cost or schedule can be correct
3. Cost, schedule, and technical performance must be integrated for risk assessment to have credibility
4. Risk management requires adherence to a well defined process
5. Communication is the number one risk management success factor

There are many resources on Risk Management, but a good one I've recently discovered is Risk Doctor. This site has well formed concepts of managing risk, with many links to other vetted sources.

Testing is a Waste? Updated

Some in the agile community would suggest that "testing is a waste."
This position misses the critical success factor for projects:

• Risk identification process must be part of any credible project management framework.
• Testing provides information
• Information has value
• This information "retires risk"

Testing produces information, which adds value by retiring risk which is a non-recoverable sunk cost

• Testing is NOT a Waste

In the absence of risk management, the recognition that risks exist independent of the development method, and the very short sighted approach of not considering the end-to-end "systems" view of a project - testing will be seen as one of those Irreducible Complexities that will be jettisoned  by those wanting us to believe we don't need some of the processes of project management.

Irreducible Complexity

The notion of a Irreducible Complexity has caught my mind share. I'm working on a white paper for a PM Journal on the idea that there is a minimum set of project management process. Go below that number and you're headed for trouble. Add more than that minimum and you may not get your money back.

More coming soon, as I sort our the concepts of the actually mealing of the Irreducible Complexity of Project Management.