Risk Management Games
According to PMI: “project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” In this definition, risk is considered both negative and positive aspects. If negative risks may cause failures of achieving project’s objectives, positive ones reveal good chances to get project better and increase possibility of project success.
Project Risk Management is the process of identifying, assessing, responding and monitoring & controlling risks on a project. If traditional project is looking into risk management as one of its processes, Agile project where philosophy of value-added representation is intensified is mixing all risk-based activities into daily work. The same techniques but different implementation.
There is no difference of the techniques being used in Agile and Traditional Risk Management. E.g.: For risk identification, you might use Assumptions and Constraints Analysis, Document Review, Brainstorming, Delphi techniques, Force Field Analysis,….for APM and TPM as well. Or only having 7 strategies of risk responses as: Acceptance, Transfer, Avoidance, Mitigation, Exploit, Share and Enhancement are considered in APM and TPM. These techniques are beyond this article; however you might want to refer to PMI PMBOK for more details
The Ownership of Risk Management
Although anyone interest in achieving those objectives should be involved into Traditional Project Risk Management, Project Manager is accountable for its success. Project Manager is expected to use Risk Register in keeping track of all risks associated with project as well as results of risk analysis and risk responses. Risk Register is maintained and controlled during project lifecycle. In regular reviews, the risks will be checked in/ out upon on their status, some of them may be obsolete that need be taken out or some new ones appear by changes of project will be added to Register. Although risk analysis usually gives someone in team as the owner of risk response from Register, Project Manager is always responsibility on course of actions. By highly responsibility, Project Manager is given a great power of managing all risks. Depends on leadership styles, a servant Project Manager can state and perform the risk plan with objective of serving his team’s work. While a dictated Project Manager running the plan in context of self-direction
Although formal process of traditional risk management is giving the responsibility of monitoring risk’s triggers to be sure risk status is realized in-time as well as performing risk response, in realization of many projects this responsibility is only one person (usually PM). It is very lucky if he/she is experiencing on that risk basis, otherwise risk occurrence may not be identified in advance or risk response can be performed inappropriately.
With APM, managing risks is collective ownership that requires whole team involved in identifying all risks as well as defining appropriate responses during the sprint planning meeting, sprint review and retrospective meeting. Having the team involved in those kinds of activities is bringing deep insight about risks & its responses to the team. That would make their awareness of importance in risk management, and then they perform their work in manner of risk consideration. The collective ownership is also revealed by how project risks are controlled and monitored. All team members are expected to keep an eye on risk’s status and perform appropriate response to them. All risk info is accessible easily and available at visible information radiator (1). Most Agile team finds it is necessary to have a plenty of whiteboard space for risk info in their room.
Figure 1- Risk Burn-down graphs are used for seeing if the total project risk is increasing or decreasing over time
A question here is what are responsibility and authority of Project Manager in APM risk management? Sometimes, you can see Project Manager exists in APM that playing role of consultative leadership – more shepherding less directing. Project Manager‘s responsibility is to create an empowered environment where the team is able to perform all risk activities without impact of external parties, E.g. interruption from upper management. Instead of involving into making any decision to risk activities or not performing any project work, he/she is behaving in a way to enhance human relations. Therefore, an Agile Project Manager should be an analytical thinker, a great listener and effective communicator.
As mentioned above, traditional risk management is usually giving a specific person to response plan while agile risk management is carrying out by whole team. Therefore, it is not surprised when you come to Agile environment whole team sitting together in hot discussion to response to a major risk. Obviously, the differentiator of ownership is leading to changes of working environment – more collective ownership, more awareness and absolutely more fun.
The Value Representation Consideration
Even when you’re working on APM or TPM, balancing costs of prevention and correction is necessary. They have to be analyzed in detail before picking an option for risk response. E.g. you may accept risk of reworking (correction) on a part of software if its cost is rather lower than having a team of 3 experts to perform a spike (2) in 1 month with purpose of verifying testability (prevention). Or you will not build a Data Center to mitigate risk of data damage for your project. However, it would be necessary demands of buying the insurance for your sensitive project’s data.
Both APM and TPM have a deep insight on risk costs of prevention and correction, but with APM, it also looks into the benefit of risk response at the moment of executing. When risk analysis results to the responses, those ones may be treated as items of product backlog where they are evaluated on the value they bring to client. A risk response will be performed prior to other backlog items if its value added is higher than others.
Product Backlog in Context of Risk Management
In Agile environment, it is joint responsibility of whole team in identifying risks on the iterative basis. However, the team must be aware the value-added which risk response bring to project. By using Prioritized Product, a risk action can be assessed and compared its value to other backlog items before put it in. High “value” risk actions appear at top of backlog while lower ones are in bottom. The challenge comes in determining where and how risk’s response inserted into the backlog. A Product Owner has responsibility to prioritize the items in backlog. He can use Expected Monetary Value (EMV) technique to figure out risk’s consequence in term of money.
An example:
Buying a new reporting tool for your project would cost at $2,000. You feel there is 30% chance of reducing $10,000 labor cost for manual stuff with that tool that. It means you will have
-($2,000) + 30% * ($10,000) = + ($1,000) from buying that tool.
I assume that your product backlog with business value consideration as below. Then, you would add the item of buying a new reporting tool between Item 4 and Item 5.
In Conclusion
Agile risk management is a transformation of traditional risk management. It appears that there is not too much of differences in techniques, however sense of responsibility in managing risks and value representation consideration are being key differentiators. Whatever your project types you are working on, whatever techniques you are using, I believe that risk management should be shared ownership.
(1): Information radiator: An information radiator is a large display of critical team information located in a spot where people can see it as they work or walk by.
(2) Spike: Spike is an indicator used by Agile software to build theoretical features that should be included in software.
