Enterprise Services
Showing results for 
Search instead for 
Do you mean 

Removing Risk from Risk Management

‎08-25-2014 07:13 AM - edited ‎09-30-2015 07:06 AM

By: James (Jim) R. Hughes, Global Business Analysis Capability Leader, Hewlett Packard Company


Risk Management word cloud.jpgAuthor’s note: My blogs address the challenges that limit applications solution delivery success, and how to overcome them.


Many organizations delivering IT projects have a documented process for risk assessment and management. For example, they might start with the process defined by the Software Engineering Institute, and adapt it as follows:


Typical Risk Management Process



Identify potential risks before they can materialize as adverse problems for a project (using techniques such as brainstorming, assumption analysis, and lessons learned workshops).


Synthesize and structure risk attributes (e.g., probability, possible impact, time-frame, priority), and calculate a risk level to facilitate decision-making.


Identify (immediate and future) risk avoidance, risk mitigation, and risk recovery strategies for each risk. Implement identified actions as applicable. Define measures and metrics (e.g., Early Warning Indicators and thresholds) for monitoring identified risks.


Monitor metrics to trigger risk avoidance, mitigation or corrective actions.


Activate risk management actions; for example retire a risk which has expired or implement a risk mitigation or risk recovery strategy.


Report risk status and associated avoidance, mitigation or corrective actions.


Even though organizations have a defined process to identify and manage risks, many executives are still often surprised by project failures—unbudgeted requests, unplanned delays, and unexpected overruns. In theory, if their project teams are actually identifying and managing risks, then there should be very few surprises. Then, why are there so many? Some suggest the primary reason that project risks become a reality is because the project estimates were overly optimistic—i.e., if we could just improve our estimating to account for risk there would not be many surprises—particularly those resulting from inaccurate expectations.


However, our problem with project risk is not only the result of poor estimating. We need to assess and manage risks at a project and portfolio level so that we can make better decisions, incorporate adequate contingencies, negotiate fair contracts with a better understanding of the potential challenges, and improve cooperation by increasing communication.


Since risk management can be so helpful for delivering successful projects, why is the process so ineffective? Some of the reasons appear to be:

  1. Lack of training. Organizations may have a documented risk management process, but project teams are not adequately trained in how to apply the process. They do not know how to identify potential risks and distinguish them from the causes or effects of risks.
  2. Lack of diligence. Project teams are not applying the process, or are only doing the minimum to get sign off on their project plan. Then they shelve their risk management plan and do not actively manage risks, by applying avoidance, mitigation, or corrective actions.
  3. False optimism. Project teams are misled by false optimism, which leads to:

    * Missing potential risks or dismissing them without a proper assessment.

    * Not anticipating failure and underestimating the likelihood of serious delays—for example, a third-party supplier who has to deliver a key component on time. Since industry data indicate that 80% of projects are late, projects should plan for their suppliers being late.

  4. Task parallelism. Project teams do not understand that task parallelism compounds risk. If risks are associated with two parallel tasks, the probability of a risk being realized at that point in the schedule is not the greater of the two, but the multiplier of the two. For example, if a milestone is dependent on two suppliers delivering software, and the probability of one being late is .4 and the other .5, then the probability of the milestone being late is not .5, the greater of the two, but .7 (1 - .6 * .5). As projects introduce more parallel tasks with associated risk, the probability of a milestone being affected by one of the risks approaches 100%.
  5. Missed opportunities. Project teams often consider risks too narrowly; only thinking about what could potentially go wrong. However, potential opportunities can also be a complement of risk management. Not considering missed opportunities for improving a business process or for delivering more sales is a form of risk.

If we address these challenges when applying our risk management process, we can remove much of the risk from risk management.


Other blog postings by Jim Hughes, which address the challenges that limit applications solution delivery success, and how to overcome them:



Blogs in the Producing Quality Software series by Jim Hughes


Other blogs by Jim Hughes:


Jim-150X210.jpgAbout the Author


James (Jim) R. Hughes, Global Strategic Capability Leader, Hewlett Packard Company

Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Analysis and Configuration Management. Jim also manages a team within the US State, Local, and Education division of HP. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He currently lives in Toronto, Canada.

0 Kudos
About the Author


Jim has been with HPE for almost 35 years and leads a matrixed global Strategic Capabilities Management team. His specific focus is on the Business Analysis capability. Jim is also a member of a team within the US Public Sector division of HPE, responsible for delivering application software to Federal and State governments. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He lives in Toronto, Canada.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Aug 29 - Sep 1
Boston, MA
HPE Big Data Conference 2016
Attend HPE’s Big Data Conference to learn from peers in every industry and hear from Big Data experts and thought leaders in an exciting, energy fille...
Read more
Sep 13-16
National Harbor, MD
HPE Protect 2016
Protect 2016 is our annual conference and is the place to meet the world’s top information security talent, discuss new products and share information...
Read more
View all