Risk Analysis: Why Bother?

You can measure opportunity with the same yardstick that measures the risk involved. They go together – Earl Nightingale

A risk is an event or condition that may or may not happen. If we fail to manage or identify risks before they happen, they can become serious problems. To avoid constant firefighting on your project, risk analysis should be approached proactively.

The word “risk” often connotes something negative but this is not always so. A risk can be negative or positive. When a risk has positive effects, it's called an opportunity. As BAs seeking business improvement, we should always be on the lookout for both positive and negative risks that may have an impact on the project or the organization, should they occur.

A typical day in the life of a BA is fraught with assumptions. Assumptions are believed to be true despite the fact that there is no proof. They are a potential source of risk, especially if they turn out not to be true. Consequently, it's paramount to document all assumptions and monitor them closely.

Let's take a look at this scenario:

You've elicited requirements from stakeholders on what the solution should deliver. You prepare the RSD and send it to stakeholders for feedback. Most of the stakeholders respond and you request for sign-off.

Here are a number of (negative) risks that can be drawn from the above scenario:

Risk 1: Requirements change prior to sign-off
Risk 2: Stakeholders misunderstand the RSD
Risk 3: A few key stakeholders are unavailable to participate
Risk 4: One stakeholder refuses to sign-off
Risk 5: Key requirements are missing from the RSD

You will agree that anticipating and preparing for these risks ahead of time would help you avoid them (prevent them from happening), mitigate them (reduce their probability of occurring or their impact when they occur), transfer them (assign someone else to bear the responsibility) or accept them, should they happen.

Risk Analysis is an important activity for all members of the project team and should not be left solely at the doorstep of the Project Manager. BAs in the course of interacting with stakeholders and eliciting requirements, should keep a pulse on stakeholders' commitment, requirements-related risks and any other factors that may constitute a problem to the project.

Why Bother With Risks?

• Identified risks can interfere with your ability to follow the business analysis plan. For example, a delayed approval of requirements can affect your schedule.

• To help stakeholders prioritize requirements, you should understand the risks associated with meeting or not meeting certain requirements. For example, the business may agree to implement risky requirements first, so that if their implementation fails, the project can be cancelled with minimal loss of time and revenue.

• Risks associated with change requests are used to decide whether or not changes should be accepted. Traceability matrices where available, shed light on the impact of changes.

• In recommending a particular course of action or developing a business case, the business analyst should include the risks associated with each course of action. A key aspect of developing a convincing business case is an assessment of solution feasibility, technical, financial and organizational risks.

In assessing a risk, it is also important to examine the impact (how much damage/benefit it will bring) and the probability of it occurring, in order to rank it. Ranking of risks influences how actions or requirements are prioritized. Risks are not an open-and-shut matter and should be managed consistently throughout the lifecycle of the project.

Managing risks does not mean you will be able to fend off all unwanted events on your project but it does imply that when or if they do happen, you are prepared to respond to them. Even if these risks don't materialize after all your analysis and planning, you still get the benefit of sleeping with both eyes closed, which is not a bad trade-off.

No matter how hard you try, it is impossible to plan ahead for every single risk. As soon as you notice that something is not quite right, don't mull over it excessively - voice it out and collaborate with the project team to develop an effective strategy for responding to it.