BA risk examples, risk attributes, risk management strategies

All teams are aimed to develop a high quality product. But there is always a risk that not everything will go according to a plan. So, it is good to identify and work with possible risks to limit any uncertainties. Knowing risks also gives us more clarity when prioritizing tasks as risks are one of the key aspects in that process. Identifying risks also helps when estimating tasks. Finally, the sooner you discover you can’t work with a risk by yourself, the easier it will be to work on transferring the responsibility for the risk.

Büyük Kardıçalı Khan in İzmir

So, what are the steps when you work with risks?

#1 Identify. Of course, a risk should be identified. It can happen during any activity — discovery, planning or even on the development stage. Instead of waiting for a risk to appear by itself, you can try to brainstorm risks with your team considering those tips:

• Try to look at a bigger picture,
• Try to be pessimistic,
• Consider common risks for your domain,
• Find a subject-matter expert to consult with,
• Conduct a research in your company,
• Conduct a research outside of your company,
• Use models like simulations, scenario role-playing, SWOT-analysis, flowcharts, risk mapping.

#2 Describe. Once a risk is identified, it should be raised in a certain manner. The description for a risk should be in a condition-consequence format. Action-reaction or effect & cause in other words. There is even a song about how you shouldn’t mix them up:

So, describe a condition and don’t forget to provide a consequence. For example, a condition can be that “we only have one developer who combines tasks for ingestion and backend”, and consequence description will be “he isn’t able to provide tasks for backend fast enough so frontend developer will have gaps in his development”. Don’t forget also that multiple conditions may be a cause for only one common consequence, and vice versa multiple consequences can be a reaction to one condition. The description should also include how the risk can affect the project:

• Cost of the project,
• Size of the team,
• Schedule,
• Scope,
• Quality.

#3 Evaluate. On top of that, the description should include the probability of the risk happening. Usually it is good to gave a numeric value from 1 to 100 at this point. Then include impact: how strong will be the impact on a project if the risk will happen? Usually, it is enough just to state whether it is high, medium or low. However, some situations may require a percentage, for example. It is not always possible, but you can also try to estimate time on risk investigation. Finally, prioritize it using weighted or absolute score.

#4 Plan, act or communicate. The strategies of how you can work with risks can be:

• Avoiding risks,
• Accepting risks,
• Transferring risks,
• Mitigating risks.

So, at first you select a strategy for each risk independently. Then you propose some action points how to make chosen strategy work. Those action points should include responsible people as well as process of regular checking the status of a risk. It may good to form a contingency plan in case you choose the strategy of accepting risks.

#5 Close the risk. There is no need to never close a risk as in time you will need your focus on other more important tasks. So, as soon as the risk has disappeared or became very low in probability, it can be closed.

Assumptions & Constraints

There are also assumptions & constraints that are needed to be identified among with risks as they usually are associated with each other. Business analyst should work closely with stakeholders to identify them as they usually come from stakeholder’s concerns. They are better to be documented with at least those attributes:

• Owner,
• Date of identification,
• Associated risk,
• Impact.

Assumptions are the statements that in terms of a project are believed to be true. Constraints are the facts that add limitations to a project.

BA Risks examples

I’ve written a lot about risks in theory but let’s list some of the most common risks for a business analyst on a project:

• Not engaged stakeholders,
• Changes in scope that you can’t control,
• Language, currency and time zones functionality and assumptions associated with it,😅
• Unmanifested requirements,
• Bad planning,
• Hidden stakeholders,
• Poorly-developed non-functional requirements,
• Stakeholders disagreement between each other,
• Changes in laws or by other regulators,
• Lack of time to provide business analysis,
• Stakeholder too pushy with their requirements,
• Not enough knowledge in project domain.

To conclude, it is very important to identify and work with those attributes of risks:

• Probability,
• Impact,
• Owner,
• Priority
• Time to discover.

Here is also a mind map that can summarize the article for you: