Risk Management — The Bad and The Good
How Risk Management Is Done Often — But Sadly
Today, I want to share some thoughts with you how risk management could be done — whether in the agile or the traditional project management or in IT and non-IT related projects:
Risk Management — The Bad and The Good.
Ok, let me tell you a story — it should sound familiar to you:
A young project manager learns at first, in her PM training
"Projects are a compromise of risks within the magic triangle of Schedule resp. Time, Scope resp. Functionality, and Resources resp. Money."
However, when the young project manager hears the word "Risk", immediately she starts with the project Gantt chart and details it as much as possible by drilling down tasks, activities, and resources to all possible details.
And then, when the project plan is finished, the young project manager remembers herself:
"Oops, there was something called «risk»."
Then, the young project manager gets rashly a few team members and some stakeholders immediately together for a so-called "risk management meeting".
In this meeting
- everybody shouts out as many risks potential as possible popping up in her mind as a sudden,
- the participants evaluate the individual average possible likelihood of their occurrence by thumb and gut feelings only.
- and since the Gantt plan is so detailed, the participants chose possible mitigations like a sledgehammer to crack a nut or touch them at the surface only.
- worst and sad, project risks are identified in an ad-hoc manner most only later on without any sustainability within the project.
Do you echo yourself in this or in the funny Monty Python video?
Take Risk Management Seriously
Ok, coming back to the thought part in any project manager's life. For the following, it does not matter whether you follow the agile mindset or the traditional way of project management. I'm sure, for both mindsets the follow general statement will hold:
"Projects are a compromise of risks within the magic triangle of Schedule resp. Time, Scope resp. Functionality, and Resources resp. Money."
The three cornerstones "Schedule/Time", "Scope/Functionality", and "Resources/Money" always determine failure or success of any project. And more, they are continuous sources of risks while you run your project:
- Scope Increase: the functionality may change over time. Either the customer wants more explicitly, or "simple" changes imply more effort (Resources) accordingly.
- Fix Schedule: the date of delivery is fixed contractually right from the beginning. You will get in trouble — even without a scope change — if your customer might bring this date forward. You will get in more trouble if scope change happens simultaneously.
- Fix Resources: in the case of fix-price budgets, all the money to spend is fixed contractually right from the beginning.
Risk Management á la Monty Python
Whenever you start identifying risks in the very early stage of your project, there is the certain danger, you will waste time and effort by
- identifying and assessing unrealistic risks because only of their small possibility, that they might could happen: "attacks by fresh fruits";
- detailing these unrealistic risks to extreme granularity in a disproportionate amount of time: "we did apples, grapes, oranges, grapefruits, pomme grannies, lemons, plums for the last nine weeks";
- developing immoderate mitigation strategies that are totally exaggerated: pistols, 16t weights, lions;
- whereas the worst, really possible risks are put aside completely: "attacks by pointed sticks?? - Shut up!!!"
Ok, there are some ways to handle these problems. Both, the agile mindset and the traditional way of project management agree on the three cornerstones mentioned above. However, they diverse in the way to realise them. In the following just chose the line fitting you best.
Traditional Risk Management
In traditional project management, risk is managed by a collection of best practices (PMBok), or specific process areas for its own (ISO/IEC 15504, SPICE, and Capability Maturity Model Integration, CMMI).
The CMMI model explains the following activities related to a mature risk management process:
- Determine risk sources and categories.
- Define the parameters used to analyse and categorise risks, and the parameters used to control the risk management effort.
- Establish and maintain the strategy to be used for risk management.
- Identify and document the risks.
- Evaluate and categorise each identified risk using the defined risk categories and parameters, and determine its relative priority.
- Develop a risk mitigation plan for the most important risks to the project as defined by the risk management strategy.
- Implement risk mitigation plans: monitor the status of each risk periodically and implement the risk mitigation plan as appropriate.
- Establish resources, responsibilities, and training.
ISO/IEC 15504 (SPICE) sets up risk management in a similar way as individual process area with specific base practices and artefacts:
Practices:
- Establish risk management scope.
- Define risk management strategies.
- Identify risks.
- Analyze risks.
- Define risk treatment actions.
- Monitor risks.
- Take corrective action.
Work products:
Risk measure, Recovery plan, Risk management plan, Risk mitigation plan, Risk action request, Corrective action register, Tracking system, Risk analysis report, Risk status report.
Agile Risk Management
The Agile approach is best in situations where it is much more difficult to (a) define detailed requirements for the project prior to the start; b) less planning is possible upfront. In the final consequence there is far less certainty that the desired business value is not achieved. In other words, the Agile approach is most appropriate in environments where the risk that the project might fail is high.
Interestingly, risk management is not a genuine part of any agile framework. Nor it is in Scrum, neither in other, more disciplined, scaled agile frameworks (Scaled Agile Framework, SAFe, or in Large Scale Scrum, LeSS).
However, Agile does not ignore risks. Instead, Agile sees risk as something that increases complexity since it may happen in all kind of projects. Risks occur and cause unexpected or unanticipated outcomes — positive ones ("opportunities) or negative ones ("threads").
- "Embrace Risk!" ((Alan Moran: Embrace Risk - Agile Risk Management)) — Core elements of traditional risk management are integral constituents of agile methodology and of the agile mindset "Inspect & Adapt":
-
- short iterations (sprints) — identify deviations and defects early;
- the dedicated focus on working software — sets always the customer in front to build the right system.
- the strong emphasis on automated tests (continuous integration) — ensure quality continuously to build the system right.
- frequent customer deliveries (continuous delivery) — shows business value frequently.
- In addition, extra activities related to risk management are part of agile ceremonies:
- Planning (sprint, release) — the team plans each sprint and for larger projects each release upfront. In this planning sessions the team estimates the complexity for tasks needed to realise the sprint/release goals, where complexity equals to (technical) difficulty of implementation and possible, endangering, risks.
- Reviews (sprint meeting, sprint reviews, release reviews, retrospectives) — in reviews after each sprint and each release, and frequent retrospectives the team focuses on continuous improvement and learning.
- In Agile, there are also some artefacts to manage risks: the risk register and the so-called risk burndown chart. ((Mike Cohn: Managing Risk on Agile Projects with the Risk Burndown Chart)). The risk register is less complex than those of traditional risk management.
I recommend to build the risk register in the planning and reviews of the first sprints and to monitor it then steadily.
Conclusions
So, what the heck, how does this all relates to the Monty Python movie? Some simple answers:
- Both, the traditional and the agile approach, have activities and instruments to identify, monitor, and manage risks continuously.
- Both approaches allow to do no risk management at all.
- For both approaches I recommend, to do some initial risk identification at the start of the project — or in agile speech — in the first sprints.
- The benefit of agile is that there is always a certain amount of inherent risk management right from the beginning due to the fundamental characteristics of Agile.
Further Readings
- Satheesh Thekku Veethil: Risk Management in Agile
- Mike Cohn: Managing Risk on Agile Projects with the Risk Burndown Chart
- Charles G. Cobb: An Agile Approach to Risk Management
- Alan Moran: Embrace Risk - Agile Risk Management
Leave A Comment