Home Planning Risk The Forgotten Task
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
The Forgotten Task Print

What do PMs almost never do? In my experience, I have rarely seen any significant time spent on contingency planning; for example, preparing for expected anomalies, preparing for unexpected anomalies, control of slack time and dependencies, and quantification and contingency budget as a part of the project planning activity. In many cases, a new product will launch with major materials shortages and problem-ridden or late software.

One approach we can take to help mitigate these nightmares is through the use of a document similar in concept to the failure modes and effects analysis (FMEA) methodology. If we view the project timeline as a directed graph analogous to a production flow diagram, we can also visualize the sequence of the time line as the beginning of an automotive or HACCP-style control plan. One of the tools used to reduce risk in the production process is the process FMEA, which matches the process defined in the process control plan step for step, often identifying multiple failure modes for each step.

What approach can help?

We recommend a modified version of the FMEA approach, tailored to the needs of project and program managers. We will model the time line as a control plan with minimal controls other than the typical tollgate reviews and, perhaps, team meetings. We know from personal experience that treating potential failures systematically can often forestall risky events completely.

What does it look like?

Our approach uses a header section much like the automotive FMEA so that the document can be appropriately identified, team named, and other information added for tracking purposes. The main fields are

  • Project identified
  • Key (responsible) personnel
  • Document registration
  • Product / project name
  • Revision control

Here is a partial sample of such a document:

Project Risk Analysis

(Editor's note: an xls version of the risk analysis template is available in the downloads section)

We start by identifying potential risks to which the project can be subjected.  This can be done individually and brought back into the team for compiling the total risks seen by the team.  Some of these risks maybe transferred outside of the project.  For those risks that are not transferred, a specific individual is defined with the task of monitoring the project for symptoms associated with this risk.  This person is responsible for monitoring the activity / risk and report back to the team, or initiate the risk response actions identified.

One of the most significant fields is Risk Description, where we explicitly identify the risk. In general it is wise to include enough information that a casual reader can understand the risk situation; that is, a clear, concise, and complete description of the potential issue. It is important at this stage that we do not include potential solutions, because the table has special fields for this.

We define other fields to be

  • Severity
  • Probability
  • Controllability
  • RPN,

RPN = Risk priority number

RPN=severity x probability x control

Example: S = 10, P = 7, C = 4 : RPN      = 280

Alternate version:


Example: S = 10, P = 7, C = 4 : RPN = 1074

Having identified the risk (quantified) we associate a dollar amount with this potential risk should it come to fruition.  If the risk were to occur, this would be the amount of money that would likely be at stake.

Risk Quantification and Detection

The SEV, PROB, and CTRL fields quantify the amount of risk to which the project is exposed.  The higher the number, the more risk to the project. This information is used to prioritize and generate action to mitigate or eliminate (transfer) the risk.

Also, we wish to identify the detection—how do you know the risk is eminent or has been encountered or is likely to be encountered. The identified responsible person or persons have an established completion date for the action as a stimulus to completion. If our actions are successful, we would expect to see the following changes to the fields

  • SEV
    • After mitigation, severity may be reduced
    •  In many cases, the severity will remain the same but the other two factors will decrease

Example of severity assessment values:

Assessment of Severity:

 Description level
 Value scale
 Minor impact on cost schedule performance  1 to 2
 Moderate impact on cost, schedule, performance   3 to 4
 Significant impact on project baseline   5 to 6
 Very significant impact on project baselines  7 to 8
 Disastrous impact probable project failure  9 to 10










  • PROB
    • The probability of the event should be reduced
    • Reduce this factor will affect the post-mitigation RPN

Example of probabilities to be used in the table:

1       10.00%  Very unlikely  
2       20.00%         
3       30.00%  somewhat unlikely      
4       40.00%         
5       50.00%  50/50 chance   
6       60.00%         
7       70.00%  highly likely  
8       80.00%         
9       90.00%  nearly certain
10      100.00%


  • CTRL
    • The control should have a reduced value if we have implemented one or more improved controls into the process

Example of controllability numbers:

Assessment of Controllability

 Description level  Value scale
 Essentially avoidable through selected risk mitigation  1 to 2
 highly controllable through organization or project actions
 3 to 4
 moderately controllable through organization or project actions   5 to 6
 largely uncontrollable by the organization or the project
 7 to 8
 uncontrollable by the organization or the project
 9 to 10









  • RPN
    • The post-mitigation RPN should be reduced over the pre-mitigation RPN
    • If this is not the case:
      • We have to live with the risk (if RPN is not very high)


  • We have an issue that should be elevated to higher levels of management


  • $$ RISK
    • We may choose to sort our table on $$ risk rather than severity to highlight significant financial challenges
    • Sum of $$ Risk is contingency $$ for the project

The trigger is a new concept to those acquainted with the FMEA approach to problem elimination. We could use, for example,

  • The Schedule Performance Indicator is an index showing the efficiency of the time utilized on the project, as compared to the estimates for the project.. Schedule Performance Indicator can be calculated using the following formula:
    • SPI = Earned Value (EV) /Planned Value (PV)
    • OR
    • SPI = BCWP / BCWS
  • The formula mentioned above gives the efficiency of the project team in utilizing the time allocated for the project.
    • SPI > 1 indicates project team is very efficient in using time allocated to project.
    • SPI < 1 indicates project team is less efficient in using time allocated to project.

Risk Response and Contingency Budgets

Each risk dollar amount at stake is multiplied by the probability of risk occurrence.  This dollar amount per risk is added together to generate the total contingency budget for the project.

When up front due diligence regarding risk is not employed, contingency budgets are a guess or based upon the last project over-runs, or a percentage of the total budget, random generated, or non-existent.  When employing any of these techniques, you are “hoping” for the best instead of planning to make the delivery and accounting for the risk.

How do we follow-up?

The risk status section should provide us with some follow-up notes on the result of actions taken, including our approach to risk handling. Risk handling includes the means by which we identify, evaluate, select monitor, and implement our choices to reduce or eliminate the risks we have previously identified. This approach includes the specifics on what we need to do, scheduling, responsibility, and budget. It is common to see the term risk mitigation, which is a subset of risk handling. The point here is that we must employ planning followed by execution in order to control our quality, schedule, and costs against plan. Some of the options we have for doing this are as follows:

  • Risk control
    • Seek to reduce or mitigate the risks
    • Example: explicit identification with explicit actions
  • Alternative Design
    • Create a backup option that uses a lower risk approach
    • Example: new technology risks
  • Tradeoff analyses
    • Arrive at a balance of engineering requirements in the design of a system
    • Example: Pugh concept selection
  • Early System Design
    • Use of simulation in early system design
    • Example: Digital mockup units to verify fit between associated parts
    • Example: hardware in the loop simulation of proposed function (data bus)
  • Early Prototyping
    • Build and test prototypes early in the system development
    • Use of simulation in early system design
    • Working models
    • Example: stereolithographic models to verify fit of mechanical parts
  • Incremental Development
    • Design with the intent of upgrading system parts in the future
    • Staged releases with known good releases
    • Example: staged releases with planned test sequences and always-correct core design
  • Robust Design
    • Parameter design
    • Tolerance design
    • Makes product insensitive to noise
    • Example: screwdriver head robust enough to be abused as a hammer
  • Reviews, Walk-throughs, and Inspections.
    • These three actions can be used to reduce or eliminate both the likelihood and potential penalties of actualized risks through evaluation of actual or planned events
    • Example: code inspections in software development
  • Design of Experiments.
    • This engineering tool identifies critical design factors
    • Can be used in tandem with robust design
    • Example: combinatorial testing of multiple electronic inputs simultaneously
  • Open Systems
    • Carefully selected commercial specifications and standards whose use can result in lower risks
    • Open source software
    • Example: mature and relatively risk-free open source software like Ruby and Python.
  • Real World Measurements
    • Carefully selected specifications and standards whose use can result in lower risks
    • Example: use of standards such as ISO for performance or exposure of the hardware
    • Example: perform actual measurements of the environment for the proposed system.

The primary task for the project manager can be summed up with the word “anticipation.”

To anticipate challenges, the project manager must either fill the function of boundary spanner or recruit someone (more likely multiple people) from within the project team to perform that function.  Factual and objective assessment of the project environment is necessary to ensure the delivery to planned schedule and budget. In addition to anticipation, the project manager will add “execution” and “follow-through” to make a complete package for project success

"Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory nor defeat"
-Theodore Roosevelt

Jon Quiqley and Kim H Pries (c) 2008

About the Authors

project managementKim H Pries APICS: CPIM: ASQ: CQA, CQE, CSSBB, CRE is responsible for all test and evaluation activities and automated test equipment at Stonebridge Electronics-North America. He holds a masters degree and presently teaches the ASQ Six Sigma Black Belt Certification. Kim has written Six Sigma for the Next Millennium A CSSBB Guidebook published by American Society of Quality Publications and co-authored with Jon Quigley the book titled, Project Management of Complex and Embedded Systems: Ensuring Product Integrity and Program Quality, published by Auerbach Publications.

Project Management of Complex and Embedded Systems: Ensuring Product Integrity and Program Quality




project managementJon Quigley MBA, M.Sc.PM, PMP, is Manager of Electrical / Electronic Systems and Verification group for Volvo 3P - Product Development North America. He holds two Masters Degrees and is a certified PMP.
Jon has secured four US patents and in 2005 was part of the team that was awarded the prestigious Volvo-3P Technical Award in 2005 going on to win the 2006 Volvo Technology Award in 2006.

Six Sigma for the Next Millennium: A CSSBB Guidebook

Comments (3)Add Comment
written by Jon Quigley, February 03, 2009
Business Process Outsourcing only defers the risk. In the end, some measures have to be made to account for the risk. If you outsource because the risk is too great, then you have to have some assurance that the company you are outsourcing to will not be impacted by the risk or is able to meet the risk in a better manner then you would be able to. In the end, if the risk comes to fruition and they are no better prepared, you as a customer will still be impacted.

From the perspective of the collapse opening up new opportunities, We entirely agree. Does it necessarily mean outsourcing overseas? This seems to always be the first answer during down times. However if you are looking at risk mitigation - oversees outsourcing may solve some issues but not others. It is also possible that we are seeing a shift from full-time employees in some areas to free agents who are willing to shift to areas of need. The employment ‘pool’ would then become a floating resource.
written by Gerard Szatvanyi, January 26, 2009
With the recent financial crisis, many companies have seen the value of risk management and contingency planning. Others chose to turn to Business Process Outsourcing. Do you think BPO can provide a solution for the crisis affected market? We’ve put together a White Paper regarding this issue: http://www.outsourcing-factory...risis.html . Looking forward to hear your professional opinion on this topic.
written by Daemeon, December 21, 2008
I find it very interesting that from a perspective of contingency planning (which we tend to think of as planning for snow storms and power outages) you very quickly realize that one must look at contingencies for all risks, large and small, high and low probability. Recovering failing projects is easier if one has a risk (and contingency) inventory. Avoiding failure is easier if one has done some contingency planning, as unknowns risks often are similar enough to risks whose contingencies have been assessed that we are not momentarily paralized. I have also been successful in moving the responsiveness to the NEED for a contingency down into my work teams by routinely asking about risks (big & small) and then asking what are our workarounds (and then documenting & sharing same).

Thanks for a good article.

Write comment
bold italicize underline strike url image quote Smile Wink Laugh Grin Angry Sad Shocked Cool Tongue Kiss Cry
smaller | bigger

Copyright © PROJECTmagazine (c) 1998 - 2019 for practical project management information. All rights reserved.