Projects generally start with an idea or a concept, and as ideas take shape, the documentation related to the project starts getting populated with several types of details – the feasibility aspect, sourcing of funds, the product vision, deciding the team, etc. These dynamics play an important part in planning the project. However, there is one parameter which can significantly affect the success of a project – the risks associated with the particular project – and even though experienced project managers try their level best to provide plans for contingencies, in practice there always exists a possibility that you don’t have a plan “B” and a plan “C” to deal with unforeseen circumstances that can arise over time as the project commences. In real life it is almost next to impossible to plan a perfect project in which risks don’t exist – they’re going to be there and will surface when you least expect them to do so. A practical approach would be to have a mechanism in place that can deal with risks as and when they arise, rather than spend time and efforts in planning the “perfect” project in which they can be avoided in totality.
Just like in any other project management framework or methodology, product owners or project managers have to deal with risk mitigation to ensure that the project is successful. It’s worth taking a look at how risks can be resolved using Waterfall or traditional project management techniques and Agile.
You can remove a risk provided you can identify its occurrence in the first place; therefore the first step in risk management is to identify potential risks. Whenever a project is incepted, the management and all senior members of the team carefully study the documentation and try to identify the probable risk areas. Based upon their analysis, they make changes in the proposed work processes and try to eliminate the risks before they can occur. At times, if system architects are employed to work for the team, they study entire processes and present potential pitfalls before the team so risks can be collectively dealt with. This is a typical scenario in the case of organizations following traditional project management methods which do not have an “in-built” plan to deal with risk mitigation.
Agile does not have any provisions for identifying risks. When a project is envisioned in Agile, the client conveys the product vision to a product owner, who can be compared to a project manager in traditional management systems. The product owner is responsible for the outcome of the project and usually, he/she tries to identify risks by analyzing the project. The PO may take the help of other team members if a team has been decided at that time. It is important to know that even though Agile does not directly support any activity for identifying risks, its working process is more than adequate in identifying risks at any stage of project development. The framework is geared to operate upon the “inspect” and “adapt” principles which highlight risks when they manifest themselves or are likely to occur. The ongoing retrospective sessions in Agile aid in identifying potential risks provided the team is practicing Agile in a proper manner.
Analyzing risks after they are detected can be difficult or easy depending upon their nature and complexity. Risks can be of any type – operational, conceptual, development associated, and even due to the technology used to develop the project. Typically project managers, decision makers, subject matter experts, and stakeholders may participate in technical discussions to get a clear insight into the root cause of the risk and how it should be ideally dealt with. Risk analysis is a specialized subject. Businesses may have to hire individuals specially trained in the subject to analyze project-related risks if the project is very large or very complex in nature.
Agile risks are analyzed when the team becomes aware of them. The biggest plus point is that the entire team collaborates and tries to mitigate risks, rather than a single person, or a group of senior members. Agile teams are self-organizing and self-managing. Moreover, teams are cross-functional i.e. a single team member is competent in more than one activities. This further ad on to the proper detection and analysis of risks since the team is familiar with the ground reality and often has the maturity to anticipate where the risks lie and how they can possibly occur.
Once risks are identified and analyzed, plans should be made to remove them. Depending upon the type of risk and when it’s likely to occur, plans have to be made to mitigate them at the project planning level or at the development and implementation level by finding alternative solutions to deal with them. This is the most important part of the project as the project manager has to account for the project if proper planning is not done to eradicate risks.
In Agile, when a risk is identified and analyzed, the entire team gets together and plans how to remove them. Inputs and opinion may also be taken from other technically sound personnel or even stakeholders if the product owner and the team feel that their participation can be helpful. The biggest advantage of Agile is that the framework can be implemented by the team in any manner it considers suitable, so provisions can be made to incorporate special processes to deal with risk mitigation – the flexibility of Agile frameworks allow that.
The actual removal of risks is crucial to executing a successful project. This is an important part of project management as it has to be ensured that the root causes of risks are addressed in a proper manner and steps are taken to remove them. Often, risks are removed, and it is later discovered that bug reappears, thus proving that their removal was not properly addressed.