‘Risk management’ can quickly turn into template-filling, and into long debates about what counts as ‘a risk’; that is, into bureaucratic busy-work. None of which moves you or your project toward success.
But you and your sponsors know that project management, and project success, are all about risk.
That’s why they have you as project manager.
Risk is the effect of uncertainty on objectives. In any project, there is uncertainty about whether the project objectives will be achieved. Uncertainty of success in projects is greater than in business-as-usual. In a project, there is anxiety about delivery on schedule and within budget. Achieving project benefits and strategic goals is even less certain, and the stakes are higher, at least from the enterprise perspective. Unintended side-effects and dis-benefits are also possible, from any change.
PRINCE2’s diagram showing the relationship between outputs, outcomes, and benefits. From PRINCE2® 2009, Figure 4.1 on page 22, with re-alignment to highlight the symmetry between good and bad project effects at different levels. PRINCE2® does not show a link from dis-benefits to strategic objectives, but there obviously is such a link.
Ultimately all risks, costs and benefits affect stakeholders: the enterprise and its clients. Those stakeholders are exposed to risk, and they should be the ones to decide which risks are worthwhile in relation to benefits and costs. The project board represents the stakeholder interests and objectives when it makes decisions. When a project board makes a decision, even a decision that you carry on, it is always accepting risks and trade-offs on behalf of stakeholders, whether it says so out loud or not.
Real project risk management begins with a good understanding of the project objectives. The SMART way to define objectives is as a statement about the world that will be true or not true at a given date in the future. A SMART objective is Specific, Measurable, Achievable, Realistic and Time-related; there are many variations. We often talk about positive objectives we want to achieve, perhaps something like ‘the enterprise makes sustained profits after project completion’. There are also objectives to stay out of trouble, which we want to avoid, perhaps resembling ‘someone gets killed or injured as a result of the project’.
For every objective, there is a planned end-point representing the intended degree of achievement or avoidance. There is also potential for unplanned deviations to a different end-point. Unplanned end-points may be better or worse than the planned end-points, by varying degrees. For the planned achievement end-point ‘the enterprise makes sustained profits after project completion’, one unplanned deviation is the alternative end-point ‘the enterprise makes good profits for two years, then loses out to competitors who had a better project’. Another deviation is that ‘the project leads to enterprise bankruptcy’. For avoidance objectives, a planned end-point might be ‘no deaths or injuries as a result of the project’. Unplanned end-points of deviation might include ‘limited minor injuries consistent with business-as-usual’, or ‘someone is killed as a result of the project’.
For every objective, there is a range of possible end-points: the planned end-point, plus better and worse deviation end-points on either side of that.
There is much more to ‘objectives’ than achieve vs avoid.
PRINCE2® identifies four ‘organizational perspectives’ for project risk. PRINCE2® calls them the Strategic, Programme, Project, and Operational perspectives. Those labels need some explanation. You can find that explanation within PRINCE2® and in the TSO source Management of Risk: Guidance for Practitioners (also available from AXELOS).
Here’s a more direct way of looking at those organizational perspectives. Those ‘organizational perspectives’ are a really a nice way of separating four categories of project objective.
- Strategic objectives are project effects on the positioning and capabilities of the client enterprise, or perhaps affecting the whole industry and marketplace. Achievement of strategic objectives may be hard to measure in numbers, and may be disputed years later, but those objectives can be overwhelmingly important. Strategic objectives have the longest life, typically spanning many years, with no defined end-point. At the end of the project, you will still be guessing whether they will have been achieved.
- Benefit objectives are project effects on the future activities and metrics of the enterprise. ‘Benefits’ are the most obvious reasons for undertaking the project. A typical project benefit objective is about making enterprise operations more efficient, in a precisely defined way, and to thereby improve profitability. Other benefit objectives might focus on safety, security, scale or some other attribute in place of efficiency and profitability. Achievement of benefit objectives is usually measurable during post-project enterprise activity, and might be tightly quantified, like profits. Benefit objectives have a long but finite life, usually spanning multiple years, after which the situation will have changed. Benefits are best measured some months after project completion, perhaps in a formal Post Implementation Review. ‘Benefit’ objectives are seen from the PRINCE2® ‘Programme’ perspective, because PRINCE2® feels that project benefits are managed from the ‘Programme Office’.
- Project objectives refer to achieving the full scope of project delivery on schedule, within budget, and perhaps with desired ‘quality’ characteristics. These objectives are sometimes called ‘delivery’ objectives. Beginners in project management can see these as the sole objectives of the project, without recognising the Strategic, Benefit, or Operational objectives at all. The ‘project’ objectives are meaningful only during the time the project is under way, so the time horizon is relatively short and well-defined. Achievement of project objectives is clear when the project ends.
- Operational objectives are about minimising any disruptive effects of the project on enterprise operational activities. Operational objectives are important only while the project is interfering with operational activities, typically in building and commissioning stages, which usually covers only part of the project’s duration. Diversion of key staff from operations to the project is another form of disruption. You will know that operational objectives are achieved or not, when you get an angry phone call from the operations manager. Operational objectives have the shortest of time scale.
Your project board is accountable for achievements and avoidances on objectives within all four categories, looking at the project from all four perspectives. As a project manager or contracted provider, your accountabilities may be limited to achieving the ‘Project’ objectives for delivery on time and budget, and perhaps the Operational objectives. That can lead to a successful project, but only if the project board has someone else looking out for the Strategic and Benefit objectives.
Your project board wants the project to achieve all the objectives in all categories. Assuming they don’t have other teams responsible for some elements, they want you and your project team to make it all happen.
The board will also want forecast end-points for each of the objectives, with regular updates to those forecasts. A forecast can mean a simple statement of which of the end-points—planned or deviant—is looking most likely, for each objective. That is obviously a useful kind of forecast, which at least says more than a traffic light will ever say.
A more complete kind of forecast, supporting board-level decisions directly, shows for each objective in each category:
- the estimated likelihood of reality matching the planned end-point
- the estimated likelihood for each potential deviation end-point.
This kind of report shows them everything they need to know about forecasts, and about risk, in a single view. It shows every objective, with a confidence level for the planned achievement. It also shows whether each nasty deviation end-point is comfortably unlikely, or not. The Clear Lines on Audit and Risk call this kind of report the Risk Based Outcomes Forecast. There is a full example (for an enterprise) on LinkedIn.
Effective risk management can report that level of assurance to the board, and supports that assurance with hard facts, robust analysis, and frank admissions of remaining uncertainties.
If you’re not able to report ‘project risk’ in such a powerful form, it’s probably because your version of ‘project risk management’ has been side-tracked by templates, standard scales, the ‘risk matrix’, look-up tables, and bureaucracy. You may have dabbled in the traditional but unhelpful display of risks as dots on a ‘heat map’. Or perhaps you have dazzled with a brand-new form of risk ‘visualisation’. What you need to ‘visualise’ are your project’s success end-points, and its possible other end-points. None of the distractions are required by PRINCE2®, nor by formal risk management standards such as ISO 31000. Another common trap is to focus on all the little problems and unknowns involved in any project. There are always plenty of those, but why do they matter? You know why they matter when, and only when, you link them to project objectives.
Your project board, clients, PRINCE2®, and the risk management standard ISO 31000, all want you to stay focused on the project objectives. There are at least four different kinds of project objective on which to focus. Everyone that matters want you to see project risk as the effects of uncertainty on those project objectives. That’s probably how you want to engage with risk, too.
This post was written specifically for re-publication in the June 2019 issue of PM Magazine, so it assumes that you are a project manager.
