Requirements Based Risks, Written by Ori Schibi, M.B.A., PMP

What can we learn from project failures?

Fact: More project failures are related to business requirements than anything else. Yet, few resources know how to manage requirements properly. Worse, we consistently do not allocate the time and resources necessary to manage requirements properly. Worse yet, we know that we have the answers – but we still fail.

Although we understand what a requirement is and what it takes to make it complete, valid, and testable et cetera, when it comes to doing it right, we often fall short. Then we add the word “risk” to it and what we get is a combination of two things that, on their own, are not done properly, and together just exacerbate each other’s deficiencies.

We can look at requirements based risks from a few points of view, yet they all lead to the same unfortunate place: a combination of one or more of the following: unacceptable product, missing functionality, unhappy customer, difficulty in planning the project, unacceptable quality, unnecessary features, wasted resources, lower profit margins and a bad reputation.

The views of requirements based risks should focus on risks related to requirements development, project impact–risks driven by requirements development, and other risks related to mismanaging certain aspects of the project (i.e., role definitions, stakeholder analysis, communication, and definition of success).

What are Requirements Risks?

Requirements risks are risks that are associated directly to specific requirements. The inclusion or addition of a risk can have a number of impacts on a project’s risk profile.

Certain requirements may expose risks of regulatory non-compliance, legal issues, PR issues, unexpected costs or process bottlenecks, and so on. In this case, each requirement comes with a cost-benefit-risk profile, and each of those aspects need to be considered when analyzing requirements.

Requirements can also have an impact on a project’s capacity to deliver on its objectives. Consider an overworked project team which is asked to add on a few more features.

The project should have a change control process to manage the change to the scope of work and the process should consider risks to the project that will come up as a result of accepting the new requirement. Will the new requirement cause cost or schedule over-runs? How will the requirements be perceived by stakeholders? Will it affect the quality of the solution? Do teams really have enough capacity to take on the work required to properly consider the analysis and design aspects of the new requirements, and so on.

What are the Best Practices when managing requirements risk?

One of the most important tenants of risk management is to realize the response strategy to pick for each of the risks identified and analyzed. These options range from avoidance and mitigation to transference and accepting. Then we must dig deeper and pick an action to take that is associated with the risk response strategy. Eventually we need to come up with a contingency plan.

In the context of requirements risk management we will narrow down the management strategies further to subsets of each of the following: dropping a requirement, handing off a requirement, changing a requirement, or maintaining a requirement.

Drop / Avoid

By dropping a requirement you are avoiding the risk that comes with it altogether. You are also dropping the benefits that come with it.

Typically, the requirement will be related to delivery issues such as capacity, or skills and feasibility, but not always. Risks can also come from the end product being available to operations. For example, marketing campaigns to sub-prime borrowers has had a negative impact on many lenders.

When you look to drop a requirement remember to assess the benefits you are forgoing. What does dropping a particular requirement do to your business case? Also, what does it do to your stakeholder acceptance of the solution? Don’t take this strategy lightly. A requirement is there for a reason. Dropping requirements requires serious analysis and usually significant communications effort.

Change /Mitigate

You can mitigate requirements risk by putting something in place that will, if the risk eventuates, minimize the impact of the risk. Requirements risks can be mitigated by identifying compromises to the requirement, or additional requirements that act as fail-safes. Business continuity processes and hardware redundancy are good examples of mitigation plans.

If you have a requirement that presents a particular requirement risk (i.e. it’s a key requirement) what can you do to ensure the impact of failure is minimized?


The classic example of risk transference is insurance, but how do you transfer a requirement? If your organization is mature enough to be managing risks pro-actively there is a good chance it’s managing a portfolio of projects, and many of them are run through a project management office.

Requirements transference can be the process of projects handing one requirement across to another project.

In example: a company wants to offer staff discounts to its employees for the services it sells. At the same time it is deploying a new employee database. Both projects will probably need to call on things such as employee email addresses and phone numbers. One of the projects is going to have to construct an interface with the existing staff email database.

In this scenario there will be uncertainty about the requirement for each project as there will be constraints generated by the other project (for example, the availability time.) As a result, there is risk. A solution to the risk could be for one project manager to agree with the other to hand the requirement to only one project to manage. This is an example of transference.

Maintain /Accept

As with any project, there are certain low-level risks that are acceptable.

In this face-paced technology world, there are plenty of features that have intermittent failures and the developers have decided to launch anyway and ignore or fix the bugs in production.

Consider this: if you can live with a requirement risk, do you really need the feature?


We should select the requirements risk management strategy based on our stakeholder analysis and assessment. This should incorporate consultation with the key stakeholders to the requirement.

Can Project Managers Integrate Requirements Risk Management?

It is important to include these requirements risks in the project risk register. They should be included for discussion at general project risk management forums, but the requirements manager will probably be doing most of the legwork and analysis to deal with it.

Having said that, we should perform a simple cost-benefit analysis to ensure that we do not go overkill – quite a common overreaction for organizations. Leveraging the existing project risks management methodology that is in place for the requirements will be appropriate and prevent over dedicating resources and efforts.

How to Do It

We should start by assessing whether any of the requirements are associated with particular risks to the project. We should then include and incorporate the requirements based risks into the project risk management processes. This will allow us to consider each requirement based on clear criteria before it is being accepted and approved as part of the review process. Keep in mind that every process, procedure, guideline, ground rule, check, balance, checklist and best practice we establish is part of our project and requirements risk management and in turn will reduce the overall risk associated with the requirements.

User Requirements Management

Whenever an organization considers buying, upgrading, enhancing, or developing new software to support its business, it is critical to know what the requirements are of the stakeholders that are going to use and support the application.

For some reason though, it is too often that analysts have hard time identifying all or the correct user requirements. At times, there is no proper realization of the importance of these requirements to the success of the endeavor. This leads to misunderstandings that in turn disrupt the communication between users, developers, testers and other stakeholders. Unwanted software is then developed, effort is put toward less important things, or the business ends up with too much software – all these costing more costs and time.

To reduce this risk, we should first identify the user requirements. We then look at it from the other side and identify the risks associated with each part of the software and its associated importance to our requirements, the stakeholders, and the project. We then match the user requirements to the risks and try to create structured statements for each user requirement.

When there is a gap between the established user requirements and the identified risks, it can serve as a sign that some user requirements have no matching risks, or that some risks have no matching user requirements. Either way, we should now focus on filling this gap and thus achieving the desired “completeness” and quality of user requirements. It will also define the impact and measurements of the risk and will assist us in coming up with possible options for solutions.

Just like with any other risks, the earlier we act, the better the focus, coordination and communication on these items will be. Cost, effort and frustration will also be lowered.

The process will conclude by defining the acceptance criteria for each matched user requirements and risk, in order to check if they are compliant with the business needs. A clear set of acceptance criteria is a measure of success that provides values that will be accepted by those who have been identified or pre-authorized to make these decisions.

It will help us combine aspects of analysis, development and tests in one overview and, if done early enough, it can be utilized to assist in requirements management, process measurement, effort estimates for development phases, lessons learned and post implementation reviews, overall risk analysis and communication.

Are there some recurring requirements related risks?

There are some factors that we can call ‘usual suspects’ in contributing to requirements related risks. These include:

  • Project strongly tied to business strategic plan
  • Project supports core business activities
  • Errors in finished solution have safety implications
  • Errors could cause loss of revenue
  • Schedule is critical
  • Product, service, or user base is new
  • Large number of requirements exist
  • Complex requirements exist
  • Stakeholders had difficulty explaining requirements
  • Requirements may change
  • Analysis team did not have resources necessary to complete work

When we see any one or more of these elements in our project, we need to pay special attention to our requirements and follow best practices in writing, eliciting and requirements to reduce risks.


A common misconception about risks, prevalent also among those of us who deal with requirements, is that we live in a linear world. Many of us see the reality as an action-reaction based, without considering dependencies, escalating conditions, downstream impact or -in short- the big picture.

In linear systems, one can perform the same task multiple times and get the exact same results. The system is predictable. However, our reality is much more complex due to cross-project dependencies, cross requirement dependencies, technology, organizational, external and environmental factors. Add to that sever time, resource and money constraints and we get complex, nonlinear systems, where one can perform the same task multiple times and get completely different results, which leads to complete unpredictability.

Recognizing that our requirements are part of something bigger and more complex, will allow us to take a sober look at what we do, think about the context in which we operate, and that any risk that affects our ability to effectively elicit and develop requirements will eventually be found in the worst timing, and undesirable form – in our product.

That system view combines the realization of who the major players are what they need and how we can best deliver it to them.


  1. Podeswa, Howard “The Business Analyst’s Handbook” Course Technology PTR 2008.
  2. Schedlbauer, Martin “The Art of Business Process Modeling: The Business Analyst’s Guide to Process Modeling with UML & BPMN” CreateSpace, 2010.
  3. Brennan, Kevin “A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)” Kevin Brennan (Editor)
  4. Leffingwell, Dean “Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)” Addison-Weasley Professional, 2011