Why Most Project Managers Fail to Differentiate Between Risks and Issues

3/3 Articles Read This Month

Unlock Premium Access

$129

Annual Membership

Save 15% annually

Join Now
  • Access 100s of PDU's
  • Expert Articles Access
  • Resource Downloads
  • Live Weekly Webinars
  • On-Demand Webinars
  • Training & Courses
Written by Praveen Malik
Praveen Malik, PMP, has two-plus decades of experience as a project management instructor and consultant. He regularly conducts project management workshops in India and abroad and shares his project management thinking in his blog, PM by PM.
Share This Post
Have your say!
00
2 Comments
  1. Praveen, good observations. There’s a reason 24 of the 48 processes (50%) in PMBOK are Planning processes. This is because the focus of project management should be on trying to foresee and plan the future (risk management included). Executing a well-planned project is straightforward work. Good project managers aren’t really managers—they’re prognosticators.

    But most companies do not share this view. In fact, most companies do not want to invest the time, people and resources to do proper planning. But they always find the extra money to fix problems later which ends up costing them much more money than if they had planned properly in the first place. I’ve pondered this over the years, and I think it’s because there is a human bias towards action. It’s hard to sit down with an already busy team and have them ponder and plan. And senior management won’t ever support this approach unless they’ve personally experienced the benefits (which is very rare).

    What usually happens is just what you’ve said: projects are left to chance, and the busiest PMs are lauded as they run around chasing their tails while the completion date slips and costs skyrocket. Contrast this with the PM with open books spread across his desk, staring out into space pondering the future and how to prevent past organizational sins: he’s told to get off his ass and to start running around like his “busy” peers.

  2. To have a Risk Registry and no Risk Reserve in the schedule would be inconsistent. To have a Reserve, the Registry needs to include each risk’s potential delay and likelihood after mitigation. Then, the necessary Reserve can be calculated using DPRODUCT. Use the unlikelihood of the risk, e.g. if the likelihood is 20%, the unlikelihood is 80%. The criteria are the Reserve, e.g. >1 day, >2 days, >3 days, etc.

    Enter a Risk Reserve as a lag on the product delivery task’s predecessor. Manage the Reserve manually when a risk actually occurs or when a risk can no longer occur. For example, if there is risk of a key resource being unavailable to begin their first project task, then after on-time arrival, the Reserve can be reduced since the resource can no longer have begun late.

    Issues are managed by Change Management, not Risk Management.

    Estimating uncertainty can be included in a schedule by copy/pasting the column of High estimates into the Work column to get the product delivery date, then pasting a column of Median estimates into the Work column, and taking half the difference in product delivery dates as a buffer. Implement the buffer by a Start No Earlier Than constraint on the product delivery Start date. Thus, the buffer is dynamic. If the project penetrates the buffer by 1/3rd, plan recovery; if penetrated 2/3rds, compress the schedule to recover the buffer using fast-tracking, crashing, crunching, or defer scope to an enhancement project.

    If a Risk Reserve is used, the estimates need to disregard risks to avoid double counting them. Implement the Risk Reserve before the estimating buffer so that the buffer does not eat up the Reserve.

Leave a Reply