The purpose of this article is to highlight the edge in project risk management an Agile method provides when compared to traditional methods like waterfall.
Normally when I talk about some type of project management in Agile, I make sure to distinguish that each side has its pros and cons. This time, I plan on doing something different, I plan on explaining how Agile allows for better project risk management.
To start off we first need to establish what project risk management is identifying, analyzing, and responding to risk during a project. The next question is what exactly is risk itself? Risk is the chance of loss or injury. Risks can also have a positive side to them though. Take for example you are hiring for a new project. You have two choices, a contract worker with an expansive and varied portfolio, or someone fresh out of school and ready to find a job. Each of these choices have a risk tied to them, the contract worker will probably be better initially, but they will be gone once the contract has expired, and the other candidate will probably not have as much proficiency to start out with, but they are more likely to stay with the company and work on future endeavors. Risks are everywhere, some are small and some are not so small, they can pervade every aspect of a project so it is imperative that you know how to deal with them.
Back to risk management, risk management is essentially how you deal with risk. You can respond to risks in multiple ways, you can try and lessen their effects, you can try and prevent them entirely, or you can just let them happen. There is more to it than just that though, here are the seven processes to managing risk management.
Planning- This is where you plan how to manage risk activities, at the end you should have a written plan.
Identifying- This part identifies which risks are more likely to affect a project and you document the details of the identified risks.
Qualitative Analysis- This ranks the risks based on their chance of happening and how much they will actually affect the project.
Planning Response- This part is used to enhance opportunities while minimizing threats.
Implementing Response- Implement your plan from the previous step.
Monitoring Risk- You monitor risks, look out for new ones, and evaluate how well your strategies actually did in dealing with risks.
Each of these parts has more to them than what was laid out here, but these are the broad strokes. For example, there is a lot more to the identifying step, there are several methods that you can employ for this step like brainstorming, interviewing, or using the Delphi technique. There are also several ways you can be affected when it comes to performing qualitative analysis, you can be impacted financially, employee morale could be affected, etc. This is just to show that project risk management is more in-depth than I am giving you.
Here is a tool called a risk matrix, it is meant to catalogue risks based on their likelihood of happening and their severity of consequences.
Image source: https://www.wrike.com/blog_images/398446/Risk-Matrix-chart.jpg
The processes I was giving you earlier for project risk management pertained to traditional methods. But in Agile it is a good bit different. Due to the nature of Agile, it is not just a list of steps where once you are finished with the last step you are done. The incremental and repetitive nature of Agile makes it more like a cycle rather than a once-and-done kind of list. So once you get to the last step, that probably means you are done with the sprint and you are about to start all over again. But what exactly are these steps?
Setting context- This part is conducted at the start of each sprint, or the kickoff, uncertain aspects of the project are discussed with stakeholders. The stakeholders decide what actions to take with these risks. A risk register is created and updated during parts of the spring cycle.
Risk Assessment- This step is quite long and is broken up into three steps.
Identify- Potential Risks from the identified.
Analyze- How much damage the risk is able to create.
Determine- What to actually do with dealing with the risk.
Implementing Risk Response- The plan from the previous step is implemented.
Monitoring Risk- The plan and other potential risks are monitored. In Agile there are several places this is done, like standup meetings or sprint reviews and retrospectives.
Just from viewing the steps alone, you can see that the processes and steps are similar when compared side-by-side. But there are things built into Agile that build on the steps. For example in a traditional method, you would have to go out of your way to plan or have meetings regarding risk, but in Agile, you can just include that in the kickoff meeting. There are aspects of Agile that help to accomplish project risk management goals. Another example is the iterative nature of Agile means you are running steps one through four multiple times. It allows you to be able to detect more problems and manage them differently. In traditional methods, you really only have one go-around with your plan, but in Agile, if something does not go right the first time, you can have multiple attempts to fix it. There is also just more communication in general, being able to discuss options with stakeholders allows for a good outside view of the project, and just knowing the thoughts of the people who want to see your project and what things they want to specifically see from it is probably the best thing you can ask for. It all comes down to how Agile is structured, it has parts built in that allow you to do things like project risk management, when ordinarily in a traditional project, you have to go out of your way to do this kind of stuff.
To conclude, while Agile is not the best thing for every situation ever. It is able to give an edge when it comes to certain fields, like project risk management. There are things that are inherent to Agile that allow for a more thorough and natural process that is unlike something in a traditional project.