A few mechanisms in agile projects help us reduce risk. For example sprint reviews of spring results allow us to make adjustments when solutions do not meet the user’s expectations or if the project’s parameters have changed. Quantative metrics like the burn up charts even help during sprints to identify problems. But are these options enough for effective risk management or do you perhaps need a systematic approach for identifying and minimizing risks?
As a project manager you take on the task of carrying out initial risk appraisals for the project. A risk is a potential problem that one should take preventative action against. Anything that could negatively affect the project in terms of costs, time and quality of solution poses a potential risk and consequently endangers the entire project’s success. To be clear: we are talking about the project risks, not business risks which the company faces if it fails. The first step to identify the risks. Then you need to evaluate them and decide how you are going to protect yourself against them.
Where could risks be looming? If you cannot see the risks your project faces immediately then you need a systematic method for identifying them. We would recommend the following:
Begin, very broadly initially, by investigating the potential sources of risks. Then figure out what kind of risks could come out of the risks sources you have found. That sounds easy, but how does one find the risk sources? You could use a risk table to do so. It can help you to get clarity on the kinds of risks that are relevant to your project. The table discerns four potential types of risks:
- System-/product risks. These refer to the software under development. They mainly arise due to complexity.
- User related risks. These are technical considerations, they pertain to the circumstances in the user areas.
- Technology related risks. These are connected to the hardware, system, software, network or communication technology etc. The more unfamiliar or untested they are, the higher the risk.
- Team related risks. These can spring from the combination and interactions among the team members.
List possible risks sources for each risk type in the table. Tick off the property per risk source that applies to your project. You will then be able to see immediately if a low, medium or high risk is present. For your overview you will find four tables for the four potential risk types. A table for system-/product risks might look like this:
|Income / expense||simple||average||complex|
|Interface with other systems/products||simple||average||complex|
|New/adjusted business processes||zero||several||many|
|Qualitative goals||normal||high||very high|
The table for the domain related risks contain the following risk sources:
|DOMAIN RELATED RISKS||LOW||MEDIUM||HIGH|
|Significant features/epics||known and quite stable||partly known||unclear|
|Users’ future IT- expereience||large||average||null|
|Support by management||large||normal||low|
|Degree of technical innovation||low||average||high|
Of course there are technology related risks too:
|TECHNOLOGY RELATED RISKS||LOW||MEDIUM||HIGH|
|Technology (hardware, network, system- and software, libraries and frameworks etc.)||simple||average||complex|
|Goal environment||known and tested||partly unknown||still unclear|
|Development environment||known and tested||partly unknown||still unclear|
|Degree of technical innovation||low||average||high|
And risks related to your team:
|Team size||1 – 5||6 – 10||more than 10|
|Project duration||1-3 months||4-6 months||longer than 6 months|
|Team’s experience with technology||large||average||null|
|Team’s development experience||large||average||zero|
|Team’s knowledge about users||deep||average||null|
|External or only partly engaged team members||zero||several||many|
|Conflict in potential in the team||low||normal||high|
|Working environment and technical infrastructure||very good||satisfactory||poor|
This project risk is just the beginning. You should definitely expand on them, ideally together with your requirements engineer.
Identifying and evaluating risk
Requirements engineering is useful for creating value for your stakeholders in your project development. What are your stakeholders’ goals? What requirements can you derive from that information? Which relationships exist between individual requirements and various technical components? This knowledge about relationships is important for identifying and evaluating risks. Requirements engineers can help a lot in identifying system-/product risks by continually entering into discusions with stakeholders about features and epics, and asking questions like: What main risks do you foresee this feature facing for this project? The result can be recorded separately, for example in the feature’s forms or Epics if you use tools in your requirement engineering.
Of course the requirements engineer can formulate a risk evaluation immediately, making suggestions for defensive action.
Focus on the top risks
After your risks have been identified keep the following in mind: not every potential risk is an actual risk. And not every risk is equally threatening. Analyze and evaluate the cited risks. We recommend giving up on trying to address every single risk. Trying to respond to every single risk is the reason why risk management ends up not taking place at all in stressful periods in the project. Costs and benefits should be reasonably balanced within the risk management framework. Develop a top ten list of risks. Define the ten most important project risks. Bear in mind that it is a rough estimate. Of course the real number could be eight, eleven or 14. But not 50 or 200. Concentrate on monitoring the most important risks and defining defensive action. Decide exactly how you would deal with every one of the top risks. You have the following basic alternatives:
- You can try to avoid the risk or to reduce the probability of them materialising.
- You can try to reduce their potential damage.
- You can try to combine risk avoidance and risk reduction.
- Or you can accept the risk and forsake the planning of measures. If the risks materialize, then you can determine your approach from then on based on the current project situation.
So how should you determine the top risks and the defensive action? Make them visible for all the interested parties in the form of a risk board.
These estimates will not remain constant. Risks will be added and subtracted as time goes on. Once the team has begun with the development work and the requirements engineer has started adding more features to user stories everyone has more responsibility for developing a solution and maintaining a functioning risk management system. The risk board is a tool that is meant to benefit everyone in the team. What should happen if the solution cannot happen as planned? What happens when the purchased control functions differently to what the provider promised on their website? What happens when the most important knowledge source for a specific area in the team is no longer available etc.? Technological and personal risks must be ascertained within the team, evaluations must be planned and carried out. That could happen using sprint planning, for example.