Rick Graham PMP
Everyone knows that a risk event is something that may or may not happen, and, if it does, will impact the project. For worse is a risk, and for better is an opportunity. And certainly, if we follow the PMBOK approach to risk management, then we know that threat and opportunity management are simply mirror images of each other. For opportunities we identify, analyze, prioritise, and respond just as we do for threats.
The value of opportunity management seems beyond challenge, and yet, whilst all organisations with mature project management processes have rigorous processes to manage threats, far fewer seem to reflect the process in terms of opportunity management (or, more specifically, as part of the risk management process). I would like to suggest some reasons why this may be, and also to suggest some solutions.
So why do we not do rigorous opportunity management?
A number of managers have suggested answers: the opportunity side of the equation seems qualitatively different from the threat side; we have difficulty defining opportunities as simple yes/no events; we don’t like to be too optimistic about opportunities because our management then sees ‘best case’ as ‘expected case’; it’s pointless using opportunities simply to register the possibility that threats don’t happen; threats are far more likely to materialise than opportunities, so we concentrate on threats.
Certainly, opportunities do appear to behave differently from threats. As I drove to the airport last week through snow, I pondered on the fact that I could think of at least 5 realistic threats to catching my flight (snow blocks road, jack-knifed lorry, breakdown, cancelled flight, traffic jam), but no useful opportunities: clear roads, or fantastic weather might indeed get me to the airport early, but my flight will not leave earlier, and it’s no use to the client if I get to site earlier.
Indeed, PMBOK’s examples of opportunities, that the cost or schedule is reduced, or performance or reputation improved, do not seem to reflect mirror images of the equivalent threat. Cost: just as with the skewed curve used to estimate confidence in cost uncertainties (the +75%/ -25%), there are many ways for threats to increase cost, but fewer ways for opportunities to reduce them; Schedule: late is almost always a problem, whereas early is not always an advantage; Performance: whilst there are many ways to underperform, or to miss requirements, delivery of an over-performing system is not always an advantage. And what about reputation? Arguably, the negative impact of under-delivery is usually greater than the positive reputational impact of over-delivery.
Opportunities should not simply be that threats don’t happen
In any case, it does not seem to be a useful application of opportunity management to populate the risk register simply with opportunities that threats/problems don’t happen.
Playing devil’s advocate, as I have above, is not useful without some suggestions as to how we may practically use the opportunity management side of the process. After all, it is hard to argue that advantage may not be gained from rigorous opportunity management. It is therefore important to examine where this leaves us practically.
The new 6th edition of the Guide to the Project Management Body of Knowledge (PMBOK6), points the way forward. The preamble to the Risk Management knowledge area points out that all forms of project risk should be considered. This extends not only to ‘event’ (yes/ no) risks, but also to other project ‘uncertainties’ such as variability and ambiguity, and other uncertainties such as estimating uncertainty. It also points out that risk management must extend beyond the project, to risks to the delivery of projected business benefits, and ultimate achievement of organisational strategic goals.
This starts substantially in the identification of risks. A common challenge faced by project risk facilitators is that, at first pass, sometimes very few of the identified ‘threats’ may actually be risks in an event, yes/ no, risk register sense. We may see sources of risk (‘we are using a new technology’), categories of risk (‘contractor’), questions (‘are we translating into Spanish?’), actions (‘we must check compatibility’), constraints (‘all staff must have level 2 clearance’), estimating uncertainties (‘we do not know the competence of the client project manager’). Of course none of these can be entered into the risk register as they are. They are not yes/ no events, and cannot therefore be assigned a probability, impact and priority.
In a practical sense, however, these may all point to types of uncertainty, and must be addressed. Typically this involves the risk process facilitator taking everything raised during the risk identification process, probing into these where necessary, and appropriately processing all these uncertainties. For example: ‘all staff must have level 2 clearance’: were there problems on previous projects? ‘contractors’: what contractor problems do you foresee? ‘new technology’: what potential problems flow from this? And even if these do not all lead to yes/ no threats, other areas of uncertainty will be identified, which should be appropriately managed.
The same must go for opportunities
To be useful, a similarly broad view must be taken of opportunity: as with threats, these do not exist simply as yes/ no events. The risk facilitator must provide a creative environment in which participants can bring specialist knowledge to all the areas of the project that may allow us to leverage opportunity. And, similarly to the identification of threats, ‘non-event’ opportunities should have the opportunity to emerge. ‘We are using new technology’: could this be a competitive advantage? ‘All staff must have level 2 clearance’: would the client pay more if we provide level 3 cleared staff? ‘Are we translating into Spanish?’: would it be worthwhile thinking about other language versions for additional markets?
Indeed a recent trend is for organisations to require that to enter an opportunity, an action must be added that promotes that opportunity. Let’s promote the new technology; let’s make sure our staff have level 2 clearance; let’s translate into Spanish.
Of course the question arises as to the extent to which the project team is responsible for the leverage of ‘business benefits’, however it would be a mistake to limit the ‘project risk’ process to simply identifying direct project risks, (or indeed, unimaginatively, threats and associated opportunities that threats don’t materialise). Only by ensuring that project threats and opportunities are consolidated under the bigger picture of business case and the project’s projected contribution to company strategic objectives, can the organisation be sure that project risks are properly understood and managed.
No responses yet