Requirements Risk Management: What's In It For Business Analysts?

Risk management, though closely associated with project management, also has relevance in the world of business analysis.

Requirements risk management however differs from project risk management. Requirements risk management focuses on actively identifying and managing the uncertainties associated with the recommended solution while project risk management focuses on the uncertainties linked to the project. Requirements risk management can however, complement the project manager’s risk management effort and is particularly essential to delivering successful projects as it aids anticipating and solving problems that may affect requirements during the course of implementation.

Requirements risks are occurrences or conditions that can affect the successful development of an end product if not properly managed. As part of elicitation efforts, BAs typically identify risks by asking “What-if” questions. When elicitation efforts focus on identifying exceptions and failure points, it’s a form of risk management. The idea is to find potential solutions to these questions and include them as part of requirements to reduce the probability of missing out on critical requirements.

To simulate the usefulness of this technique, let's take a look at this requirement:

“The system shall reduce an employee’s leave balance by 1 day if their attendance record is not detected for that day.”

Here are some “What-if” questions you may ask to identify the risks linked to this:

“What if the staff’s attendance records are not uploaded to the system by the security team?”

The fact that staff’s records have to be manually uploaded has become a potential “risk” to the project. A risk statement could then be posed as:

“If attendance records are not uploaded to the system, leave balance deduction will be inaccurate”

One response to this risk is the introduction of a requirement to ensure that “Attendance records are automatically uploaded” to avoid the delays and risks associated with manual upload of data.

Due to the central role that requirements play in successful projects, it’s important to actively identify and manage the risks associated with them.  For effective risk management, the following steps should be taken:

1. Organize a session for project stakeholders to brainstorm on possible risks

2. Rank the risks based on the probability of their occurrence (How likely is it that an identified risk will cause a problem?) and the impact (To what extent will the risk affect requirements?)

3. Discuss/evaluate ways of managing identified risks - make sure at least one team member is responsible for monitoring each risk and that all team members understand the impact of their actions on requirements and the eventual success of the implementation.

4. Actively monitor the project and identify additional risks where they occur. 

Requirements Risk Mitigation

Here are some general requirements risks that apply to most projects (and requirements) and some ideas on how they can be mitigated:

1. Lack of involvement of the technical department

- Identify the technical stakeholders

- Run requirements by them early enough before they are due to be implemented

2. Scope creep

- Ensure that all stakeholders understand the scope 

- Validate requirements as often as possible

3. Poor impact analysis

- Document requirements and get all relevant stakeholders to review them for any missing and dependent requirements.

Thinking of requirements risks can help to build stronger requirements and close gaps not already covered by the recommended solution. Through the use of complementary techniques like interface analysis, document analysis, etc, BAs can come up with requirements aimed at preventing risks from becoming reality. Controls designed to address each risk should be put in place though this may lead to the creation of additional product requirements.

Requirements Risk Log

Interested in keeping a log?

Here are some possible headers for documenting requirements risks:

1. Risk ID
2. Risk description
3. Probability of occurrence and
4. Impact of occurrence, for ranking risks

Thinking of the risks linked to each requirement can certainly help to identify critical requirements that may otherwise, be missed. There’s certainly significant value to be had by proactively monitoring requirements for potential risks before they are implemented.