Business requirements should inform every investment in new software and technological infrastructure. You don’t launch a new project, purchase a new piece of enterprise software, or develop a new process unless it’s in response to a core business need.
But understanding exactly what that need is can be a challenge in itself.
Even after spending time, resources, and energy trying to identify a problem that needs to be solved, organizations can find themselves in a situation where there is a fundamental mismatch between what they have planned for and what they actually need.
Undertaking a careful business requirements analysis can help you avoid this mismatch.
Taking the time to carefully identify, analyze, and document your core business requirements can lead to a smoother procurement process with an outcome that delivers measurable results.
In this chapter, we’ll explore:
- The fundamental elements of an effective business requirements analysis
- Some common pitfalls and mistakes that can compromise the process.
What’s involved in a business requirements analysis?
A business requirements analysis is all about identifying, analyzing, and documenting the key requirements related to a business problem that needs to be solved or an organizational objective that needs to be met.
This is the foundation of a successful procurement project:
- First, define each requirement clearly so that you can assess the time and resources you will need to allocate to the project
- This first step will help you understand the difference between need-to-have features and nice-to-have features in the solution you’re looking for
- It is also the first step on the way to making the vendor selection process as smooth as possible.
And while identifying business requirements may seem simple enough, a thorough analysis of these requirements involves several important steps:
1. Gathering stakeholder requirements
2. Categorizing stakeholder requirements
3. Analyzing and interpreting requirements
4. Documenting requirements
Let’s examine those in a little more detail.
1. Identifying key stakeholders
For a new technology procurement project, an effective business requirements analysis starts with identifying the key people in your organization who will be affected by the project outcome.
This includes the teams that will be working with the new technology you procure, the end-users, and anyone else in your organization who will be involved in the project.
It’s important to ensure your list of stakeholders is comprehensive. The end-users of a new technology may be spread across different departments and teams, for example, and therefore have diverse needs.
It’s also important to consider the requirements of the executive suite. Although senior executives may not be directly involved in a procurement project, they are core stakeholders who should not be overlooked.
2. Gathering stakeholder requirements
The next step is to identify what each stakeholder needs. Here are a few different ways to go about this:
-
Interviewing stakeholders
- Conducting group workshops and focus groups
- Making a prototype available for end-users
- Developing test cases for users to run through (low-fi prototyping is often good for this).
The objective here is to clearly understand your key stakeholders when they describe what they want, need, or expect from a new technology solution. This will allow you to form a clear picture of the requirements that a solution must meet and the goals it is meant to achieve.
3. Categorizing stakeholder requirements
One thing about stakeholder requirements is that they can often be all over the map.
So the next important step is sorting stakeholder requirements into useful categories in order to build a cohesive picture of the project’s business requirements. These categories should include:
-
Functional requirements: how a new technology product should perform for the end-user
-
Technical requirements: a focus on the technology issues to be considered so that the solution can be implemented effectively
- Operational requirements: a focus on the operational issues to be considered so that the solution will be able to function for the long term
- Change management requirements: how to ensure the transition and adoption of a new technology solution will go smoothly.
4. Analyzing and interpreting requirements
Once you have categorized all of the requirements, the next step is to analyze them in a number of different ways.
First, you’ll need to clearly define them. This involves distilling what stakeholders have told you into clear and well-defined requirements. Next, you’ll need to:
-
Identify the highest priorities
-
Determine which requirements are achievable and feasible
-
Understand and address any conflicts between requirements
-
Draw clear, measurable connections between requirements and business objectives.
5. Documenting requirements
After analyzing all of your stakeholders’ requirements and identifying priorities, the next step is putting together a clear, detailed report on stakeholder requirements and business objectives. Once you’ve circulated this report to your stakeholders and it’s been given a green light, the document can serve as the foundation for the rest of the procurement process.
5 common pitfalls in a business requirements analysis
The stakes involved in conducting a business requirements analysis are high: it takes a lot of time and resources, and if requirements aren’t identified correctly and documented thoroughly, even the most sophisticated and beautifully designed technology solution may not meet your organization’s needs.
But the path to correctly identifying core business requirements is often not a straight line.
Not only are there many moving parts, diverse stakeholders, and complex analytical metrics to consider in an effective business requirements analysis, there can also be many complications along the way that organizations will find themselves struggling with.
Here are five of the most common pitfalls in the business requirements analysis process.
1. Missing Stakeholders
Although it may seem simple at first, understanding exactly who your stakeholders are is actually a complex task. That’s because your stakeholder group includes not just the obvious end-users of a new technology solution. It should also include the implementation team, the operations team who will maintain the new technology, and the people in your organization who will be affected downstream by changes in the processes related to it.
This task can be accomplished by drawing a map that accurately identifies all of the people in your organization who will interact with or be affected by the new technology.
At this point, an external consultant can provide support by working with you on a thorough stakeholder analysis that identifies and prioritizes stakeholders and maps out their relationship to the new technology.
As counterintuitive as it might sound, bringing in a third party at this point can be quite helpful – they’ll be able to take an objective view of your organizational structure.
2. Vague Requirements
It can be challenging to ask your stakeholders the right questions – and get the right answers. As you gather your stakeholders’ requirements, you’re looking for focused and reliable information about what will be needed to successfully implement a new technology solution.
Organizations often have trouble finding the questions that will generate these actionable responses and end up with a list of vague requirements that are difficult to turn into concrete plans.
Conducting effective interviews and focus groups is a key step to take here. This involves communicating clearly about the scope of the new technology solution, asking questions that reveal specific stakeholder needs, and anticipating any issues stakeholders might overlook or ignore.
This task is made easier when someone on your team has experience conducting interviews, as well as a familiarity with the kind of new enterprise technology you are looking to procure.
3. Unclear Priorities
During the stakeholder consultation process, every requirement can seem critical. Because every stakeholder sees their own needs as a top priority, it is important to take a step back and make the distinction between a nice-to-have feature that will satisfy some of your stakeholders’ wishes, and a need-to-have feature that will achieve business objectives.
An external consultant can help you make these distinctions. Third-party consultants and analysts can often identify core business requirements more easily because they don’t have a vested interest in any one particular requirement. Instead, they are able to focus on identifying the features that will help achieve business objectives, and those that won’t.
What’s more, they can draw on previous experience with similar projects to help prioritize your requirements; if a feature was a nice-to-have for another similar organization, it may be a nice-to-have for yours as well.
4. Mixed Signals
Your stakeholders’ perspectives can often clash. It’s inevitable, and it can throw a wrench into the gears of your project if you’re unequipped to sort out their conflicting requirements, determine where any mixed signals are coming from, and resolve the conflict as early as possible.
Making sense of mixed signals and following up on any conflicts involves asking yourself (and your stakeholders) a few questions:
-
What is the source of the conflict? Is it a conflict between the needs and goals of different departments? Or could it be that end-users are not entirely sure what they want or haven’t been asked the right questions?
-
Which requirement takes priority? If a conflict between stakeholder requirements can’t be resolved, which requirement is more likely to achieve business goals? Which requirement can be met more feasibly within the scope and limits of the procurement project?
-
Can both requirements be met? Is there a workaround or technical specification that would permit the new technology solution to meet seemingly conflicting requirements? What would that look like when it’s implemented?
5. Communication Barriers
Product end-users and members of an organization’s technical teams sometimes speak a different language. Your analysis should clearly communicate the key business requirements to both camps – without this, requirements may be misunderstood or overlooked, and the new technology solution may not be able to achieve all of your organization’s business objectives.
Bringing in a subject matter expert (SME) can help you avoid these barriers to communication. Whether an SME is a tech-literate team member, an analyst, or an external consultant, they should be capable of producing a report that will communicate end-user requirements to both a technical audience and your organization’s stakeholders.
Chapter summary
- An effective business requirements analysis can serve as the foundation of a successful procurement process.
- Complications can arise during a business requirements analysis, including incomplete identification of all stakeholders, clashes between stakeholder perspectives, and poorly defined business requirements.
- You can avoid these pitfalls by being aware of the basic steps involved in conducting an effective business requirements analysis, and by having any potential complications on your radar from the start.
- Bringing in an external consultant can be of value at this point in the process. Third-party experts have experience navigating vague requirements and stakeholder conflicts, conducting focused interviews, analyzing responses, and distilling the results into documentation that sets out the objectives for a procurement project. They also bring with them past experience with other similar projects and a good understanding of what worked (and didn’t work) in those projects.
- A business requirements analysis is a high-stakes game. Poorly defined requirements account for many software failures, and they’re often the subject of complaints during any difficult procurement process. It pays to get them right from the start.