Project Practitioners > Risk Management, in the REAL World

Risk Management, in the REAL World

By Matt Glei

One of the things I've observed in life, in attending PMP prep classes and teaching those classes since, is that most project managers don't spend much time or effort in performing and updating risk management activities. I also consult with companies both small and large in improving project management execution, and again I find a lack of effort in risk management areas, except in highly-regulated areas, or in highly-evolved companies.

There are two kinds of risk management, PROJECT risk and PRODUCT risk. Both are well-covered in the content. My point is that, although the methods and processes are known, many companies and their project managers do not perform solid risk management at the right time to really help and also do not update the risk items periodically to retire the risk or enhance the plans.

I'm not advocating that everyone spend hundreds of hours on risk planning, qualitative analysis, quantitative analysis and mitigation or contingency plans and updates to the above, in a formal, PMI way. BUT, using the methodology to do a brief evaluation and ranking of risks can lead to avoidance of significant risks and the resulting damage in even simple projects.

Not every project is a bet-the-company project or creates a life-support product. In those cases, management must insist and ensure that adequate effort be spent to evaluate and mitigate those significant risks. Medical device companies (and some other highly-regulated fields) are required to do product risk management to prevent harm to the user, consumer or patient. But those same companies do not spend much time on PROJECT risk and most non-regulated companies don't seem to understand that an ounce of prevention is worth a pound of cure (I'm not sure what the metric equivalent is) in BOTH areas of risk.

Simply put, for PROJECT risk management, even a few hours spent with the project sponsor (or management team) and the project team and key stakeholders can identify areas where assumptions are not the same and where the participants with deeper knowledge perceive higher risk. A simple brainstorming process can unearth many potential risks, and a short time discussing those risks can lead to understanding their relative risk and some possible avoidance or mitigation approaches.

I have seen the following as PROJECT risks not being imagined or dealt with in real-world projects, even though they seem to happen in every project. These are just examples and are not specific to any technology. Nonetheless, even spending a few hours considering these possibilities, issues and assumptions can lead to a short list of risks that can be addressed and thus have a major positive impact on project performance and success. Good luck.


  • No plan for holidays or vacation time in the project resource calendar. No one is ever sick. No one leaves for another job or project.
  • Needed resources are available when and where needed. No time or effort allowed for recruiting, hiring, or training.
  • Each resource can work 8 hours per day (or more) on the project tasks, and that NO time is required for non-project activities.
  • No training for the project staff is needed, or even allowed.
  • Overtime will be used to mitigate any schedule issues (only true to a point).
  • Other projects will not interfere (prioritization).
  • Specific resource loading is ignored (so some people need to work 24 hours a day).
  • Capital and significant expense money is available at the planned instant of need, and any approval process will not delay the project tasks.


  • There are no technical unknowns (even though there usually are).
  • The best and brightest resource does each task, and has done the task many times before.
  • The team has worked together before and done this type of technical project before (usually NOT the case).
  • There will be no defects (or bugs) to fix, that no time is needed for the fix and re-test.
  • No detailed plan or allowance for verification or validation tasks, effort or documentation of the plans.
  • No time for integration at key milestones, testing or bug fixes at those points.
  • Unclear about how to agree on architecture, compiler, microprocessor, other development and testing tools; and the time and timing to make those decisions.
  • Performance, reliability and quality targets, processes and capabilities are well-understood.


  • Subcontractors and suppliers are identified or already approved.
  • Regulatory issues, processes and timeframes are well-understood.
  • Needs of the marketplace and customer/users (requirements) are understood and documented.
  • No impact by weather, security, emergency issues.
  • No potential intellectual property issues.

Project Management:

  • Estimating, planning, monitoring & controlling and communication are all methods that the project or company has done successfully for a long time.
  • Project metrics are understood at all levels.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.