We don’t like doing Project Risk Management

Project Management Basics Comments Off

We know we SHOULD do Risk Management

But many PMs don’t do it. (Based on paper from PMJ Sep 2009; and ad-hoc surveys during PMI 2010 Congress)

It isn’t because the complexity of the mechanics/process, which seems easy enough, well documented as a Knowledge Area in the PMBOK guide: You have a risk register or log, you identify risks, analyse them e.g. for probability and impact, look into responses, remediation or contingency measures, and keep revisiting and updating the register as project moves along…

As usual, the challenge is applying theory to practice.

You think you have done it right, and then some new Risk still hits you because of unknown unknowns (remember Rumsfeld talking of WMD in Irak?), Murphy’s law, “shit happens”, etc.  Sometimes your buffer time and budget will be enough to cover it, other times it won’t…

Examples: The winner of the PMI 2010 Project of the Year, the decade long building of the National Ignition Facility in California, explained during a Dublin PMI Congress presentation that their two main issues were risks they had not considered and were not in their register - The construction site got flooded because of El Niño storms. And sure they were not expecting to find mammoth bones when excavating… Both events consumed money and time, though the project recovered.

Other examples are the typical external (to the project) factors such as weather/Nature (Ash cloud closing Northern European air space; Hurricanes, earthquakes), political changes, economic crisis (Iceland, Greece, Ireland, Portugal), etc…

And this is clear when you realise that the Input to Risk Management Planning, according to PMBOK guide, are “internal” docs, such as Scope Plan, Cost Plan, Schedule Plan, and so on. We can plan for what we know, but isn’t Risk Management too ambitious when trying to control and have a response for the unknown?

Therefore, how much work do we need to put into identifying this very long list of things that may happen? The cost and time needed is a first negative factor. (Sponsors/customers want cheaper and faster)

Then you have the human element of having to talk about Risks…it is all negative and worse-case, it highlights the project or company gaps, our badly prepared areas, our legacy problems…and the PM is the messanger for all those bad news.

No wonder many PMs prefer not doing Risk or doing a “light version” / once off at start. First, as seen, many external factors will be missed -we can’t plan for everything-. Secondly, PMs rather avoid the confrontation with stakeholders and other managers to discuss “potential bad news”.

We need to re-think how we do Risk Management in practice. We need to support PMs to plan appropriately (How Much? 80/20 rule? Set a time and cost limit for Risk Management? Who decides?). Perhaps even a Risk Function should be the owner of this activity for all projects (Portfolio Risk Management – like a mini PMO focused on Risk), where this function has more size and power to get the appropriate cost and time to buffer the project(s).

Don’t bore me, tell me what I need to know – Status Report

Project Management Basics Comments Off

Some PMs, when asked by their managers how their project is doing, tend to go into a lot of detail explaining the complexities of their  latest issue or current activities. Other PMs like to keep it to themselves and say very little, i.e. all is good, trust my feelings, don’t ask me more questions and let me go. The truth is that the question on project performance can be answered professionally with significant and relevant data, and management should be clear on how that looks like.

 

Status reports, or progress reports, are probably the best known document during the life of a project. Other documents such as Business case, Requirements, Architecture, Test Plans, etc are in many cases once off documents that not necessarily all project team sees. Status or Progress reports however, are updated frequently (e.g. weekly) and shared with all the project team, customers and stakeholders. I am using both terms status and progress as synonyms here, as in practice organizations use either when refering to the same document -same purpose. Usually, the report is a one page with both status and progress information.

 

Don’t bore me, keep it simple and tell me what I need to know. That means Significant and Relevant to the audience. We’re talking of a one-pager, a short document that shows me two things: The Baseline, and any Variations. The baseline is what the project has agreed, the project boundaries in planned scope, cost and time. This should not be too detailed. It includes a summary or the more important deliverables (the scope), the planned budget (and people’s planned hours if not included in the budget), and planned milestones (some key dates from the schedule). Just looking at those few lines and figures, I can get a good idea of what the project is about, and its size/complexity based on budget and hours. This bit should not change during the project –it is the baseline-, that is,  the base against which we will measure if the project does well or not. Variations are deviations to the planned baseline. For example, actual cost higher than budgeted, or not meeting set milestones. We may also have issues or risks that if not already affecting the project, they might in the future. Put that info together and you have a nice Progress report showing planned vs actual data on deliverables, cost and time. The status report section can be done with some text explaining the project phase or stage that we’re in, one line saying what task is ongoing (to give an idea of current position within project life cycle), and a traffic light signal (green, yellow, red) to flag when we think we may face trouble (yellow) or for when we already know we won’t meet the baseline (red).

 

Improve the report. Add forecasts.  Earned Value and all the forecasted cost and dates are not so complicated. The PMBoK and Wikipedia have good explanations. I think a good status report should always show the Estimated at Completion data to better illustrate any deviations and their estimated final impact.

 

In summary, a Project Status/Progress Report should show in one page:

  1. Life Cycle Phase and one line summary of current activity
  2. Flag (Green/Yellow/Red)
  3. Main Deliverables
  4. Planned budget vs Actual
  5. Planned hours vs Actual
  6. Milestones vs Actual dates
  7. Main Risks and Issues, with impact and actions to resolve

Entries RSS Comments RSS Log in