This 5-minute read proposes a more comprehensive systems view of project risk management, moving on from the fill-out-the-template approach.
Risk pervades our lives, shapes our strategies, and influences our behavior. It accompanies every project, but unlike the triple constraint, you can actually ignore it and (with some luck) be successful. Please don’t; this is not the recommended approach. In fact, I am convinced that expertise in risk management should be a priority for every project manager (PM), right after mastering the triple constraint. My proposed starting point recognizes that risk evolves during the project and can be assessed using systems thinking. This will make the PM’s job easier, improve the project’s chance of success, and yield an excellent payback for the effort required.
Start with a better risk model
Systems thinking usually requires an intelligible model of the subject that integrates all the components in the environment, covers all the bases, and encourages analysis. Techniques such as the risk cause and effect model described in PMBOK (Guide to the Project Management Body of Knowledge) published by PMI have their use, but are best applied in the context of such a model. Lacking this context, I have early memories of attempting to comply with trending demands for ‘risk management’ by identifying all possible risks that might occur and listing them carefully in an appendix to the project plan, where they were doubtless admired!
Here is an evolutionary model of project risk that makes sense because it mirrors the complete project lifecycle, and can be expanded out into numerous useful elements:
Risk is always in the future, so although the model is presented in the present tense, the macro question is also asked in the future tense – will we deliver, will we benefit? (For clarity, when a risk occurs and is now in the present, it is usually labeled as an issue or an obstacle to progress.)
Organizational Responsibility for Risk
The model shows there is more to this than listing risks and delegating the PM to get on with it. The degree to which the related responsibilities of the three key stakeholder groups are fulfilled greatly impacts project risk:
- The Sponsor (Project Owner) is primarily responsible for project selection and benefits management.
- The Vendor (Performing Organization) is responsible for the bid decision, project policies, risk-based portfolio management, resourcing and hiring practices, Standard Operating Procedures (SOP), and evaluating performance, client satisfaction, and profit.
- The Project Manager (Client/Vendor PM) is responsible for project risk mitigation in response to the question “what might prevent the work I am authorizing from meeting the project objectives?”
The PM’s position if bad things happen
So where does the PM stand in response to this encompassing model of risk? The responsibilities listed above are not all the PM’s, nor is the PM consistently engaged through each phase of risk as it evolves, but risk must still be identified, communicated, and mitigated. Poor outcomes include:
- The Wrong Project: The PM has little mandate for engagement during feasibility, but must be prepared to offer an assessment if asked. The PM identifies risks and mitigations arising from a poor decision. A more influential role is required if the PM carries accountability for the benefits, and not just the deliverables of the project.
- Lost Bid: The vendor PM is usually a junior partner in the sales effort, led by the sales executive who will wisely ask for the PM’s assessment of the bid opportunity (see the January 2019 post). The PM’s efforts are directed more towards the delivery risks and ensuring that price negotiations don’t lead to cuts in proposed project resources.
- Poor Initiation: Concerns usually revolve around resources – availability, skills, and experience. And sometimes belatedly discovering it is the ‘wrong’ project! Accountability is in transition as the sponsor steps back and the PM picks up on commitments and assumptions presumably made by his superiors. Therein lies risk. The PM must have a clear understanding of those commitments and assumptions.
- Inadequate Plan or Contract: This requires significant vendor PM engagement and authority, on a par with the sales executive, who nonetheless remains accountable until the contract is signed. In-house projects initially use the project charter to mitigate planning risks, written by the PM and signed by the sponsor, a user liaison manager, head of the performing department, and the relevant functional/resource manager(s).
- Bad Execution: The hypothetical assessment of risk is now replaced, or supplemented, by the actual performance of the project, risk indicators, and classic risk register analysis. This is the accountability of the PM.
- No Benefits: A project may be delivered successfully, but does not yield the benefits that justified its selection, frequently due to insufficient follow-through by the sponsor. Should this be added to the PM’s responsibility? For many reasons, my view is ‘no’, but the PM must be very clear on this point before the project starts. If the PM is to be held accountable, then she must be properly engaged and carry authority during project selection.
Your organization might see things differently from the above baseline positions. Find out.
The politics of risk
The questions in the risk model inevitably play into governance and corporate politics. For example, at the macro level, the expected ‘right’ answer to an early phase question is ‘yes’. But, counterintuitively, the ‘yes’ answer causes the most anxiety because now the PM must analyze the factors that threaten this cozy assurance. A ‘no’ answer will at least come with a clear reason, and if the answer is ‘no’ (during the early phases) then there is no project, no risk, and we can take the day off.
What about the ‘speaking truth to power’ mantra? The reality is, if you are dealing with significant organizational or personal power, your unpalatable news will likely be ignored unless it’s a showstopper in black and white. My painful career example was telling a CFO that the hardware was underspecified, requiring a major upgrade. The political fallout came not from the CFO (just anger) but from the manufacturer who consistently assured the client that the spec was adequate. I was blacklisted.
But black and white is a tough criterion. Consider the familiar example of a client demanding a tight deadline. Can the PM really stand up and clearly state that it can’t be done? Very rarely, and if you do, you lose your job. The point is that in these situations we are dealing with the uncertainty of estimates, and the client will view your estimate as inferior if it doesn’t meet her needs. In such cases, a risk-based dialogue might bring you both to a conclusion you can live with.
The takeaway
A good inclusive project risk model can provide a solid base for taking the systems approach to risk. Each phase of risk can then be systematically analyzed using derivative questions, secondary risk models, checklists, and tailored risk techniques. Many examples of these are found in Commercial Project Management – A Guide for Selling and Delivering Professional Services, summarized here.
Speaking truth to power needs an impersonal framework, as well as guts. Risk modeling facilitates this approach, depersonalizes concerns, and deals in probabilities rather than assertions. Negotiation, if needed, can secure extra funding for mitigation or contingencies, in return for properly anchored project commitment and increased probability of success.
A PM fluent in the language of risk is more likely to avoid the personalization of failure and an excess of finger-pointing. The conversation centres around the risks and the correct response plan, not the futile accusation – “you screwed up”.
Expertise in risk analysis is a valuable asset for a PM and reinforces his authority. When confronted with pressures averse to the project position, or where personal preferences are over-riding logic or reality, the PM can use risk models to develop a more constructive discussion leading to better project outcomes.