Strong business requirements are essential to solution delivery. Inadequate and unclear requirements are the number one reason that projects fail. Organizations need a consistent, repeatable, and prescriptive set of guidelines that inform how business requirements gathering should be conducted.
Requirements gathering demands involvement from a variety of stakeholders. Inaccurate requirements definition can lead to significant amounts of project rework and hurt the organization’s performance. It will also damage the relationship between the vendor, the organization and IT.
The following information outlines best practices and provides a guide for those who are gathering business requirements for an application or system review.
A business requirement is a statement that clearly outlines the functional capability that the business needs from a system or application. There are several attributes to consider in requirements. Requirements should be
Having a standard process for defining requirements gives your organization a frame of reference for gathering them. Building an effective process will save you time and money in the future as you determine the best systems and applications for your digital transformation.
Many associations and non-profits do not have dedicated Business Analysts (BA) on staff. Often the IT Director or a project manager plays the BA role to gather requirements for a project. In this role, their job is to elicit, analyze, specify, and validate the business needs of stakeholders.
A successful requirements gathering practitioner is someone who has found balance between communication, documentation, collaboration, and control. In associations, that balance should sway towards communication and collaboration.
A robust process for business requirements gathering is essential for project success. However, most organizations do not take a strategic approach to optimize how they conduct business analysis and requirements definition. The following graphic outlines how this process is ideally conducted.
The main objective is to understand the target business needs for the requirements process. Start by examining the business process, then tackle technology. When gathering business requirements, it's critical not to assume that layering on technology to a process will automatically solve your problems. Proper requirements gathering views projects holistically (i.e., not just as an attempt to deploy an application or technology, but as an endeavor to enable new or re-engineered business processes). Neglecting to see requirements gathering as business process enablement leads to failure.
Start by identifying the challenges you are currently experiencing. A great way to do this is via a whiteboarding activity. Work with the subject matter experts to come up with challenges, write them on sticky notes, and place them on the whiteboard. As a group, review all the sticky notes and group them into themes. What objectives will help you overcome these challenges?
Now let's turn these objectives into goals. Visualize how you want requirements to be gathered in your organization. Do not let elements of the current process restrict your thinking. Articulate the motivation for optimizing requirements management and establish clear goals.
Then, select the project specific KPIs used to track the value of requirements gathering optimization. You need to ensure your requirements gathering procedures have the desired effect and adjust course when necessary. Establishing an upfront list of key performance indicators that will be benchmarked and tracked is crucial. Without following up on requirements gathering by tracking project metrics and KPIs, organizations will not be able to accurately gauge if the requirements process re-engineering is having a tangible, measurable effect. They will also not be able to determine what changes (if any) need to be made to SOPs based on project performance.
"Without requirements that correctly articulate the underlying needs of your business stakeholders, projects will fail to deliver value and involve significant rework. In fact, An Info-Tech study found that over two-thirds of projects fail due to poorly defined business requirements."-Ben Dickie
Director, Enterprise Applications, Info-Tech Research Group
You have defined your goals for requirements gathering and what KPIs for how you will measure the performance of our requirements gathering process. Before you can dive into most elicitation techniques, you need to know who you're going to speak with. Not all stakeholders hold the same value.
There are two broad categories of stakeholders:
The elicitation phase is where the BAs meet with project stakeholders and uncover the requirements for the application.
A mediocre requirements practitioner takes an order taker approach to elicitation: they elicit requirements by showing up to a meeting with the stakeholder and asking, "What do you want?" This approach frequently results in gaps in requirements, as most stakeholders cannot free-form articulate an accurate inventory of their needs. A strong requirements practitioner first decides on an elicitation framework – a mechanism to anchor the discussion about the business requirements. The BA can work through several key questions:
One key element to elicitation is using the right blend of tactical techniques to gather information. Interviews are the most popular means, but focus groups, application design sessions, and observational techniques can often yield better and more expedient results. There is a time and place for each technique. Diversify your approach based on the elicitation goal.
Conducting elicitation typically takes the most significant part of the requirements management process. During elicitation, the designated BA(s) should review documentation and conduct individual and group sessions with key stakeholders. Providing a guide for your BAs with a shortlist of recommended/mandated elicitation techniques based on business scenarios can be helpful. Your guide should also suggest the order in which BAs use the techniques for initial elicitation. Generally, document review comes first, followed by group interviews, individual discussions, and observational techniques.
You will need to record and capture requirements in solution-oriented formats. Unstructured notes for each requirement are challenging to manage and create ambiguity. Using solution-oriented formats during elicitation sessions ensures that the content is digestible to IT and business users.
A typical elicitation output may take the form of a requirement matrix or process narrative. In addition, this table shows other solution-oriented formats for recording requirements. Determine which formats the development team and BAs are comfortable using and create a list of acceptable formats to use in projects.
Read More: Role of Consulting in AMS Vendor Selection
Phase 3 covers the analysis and validation sections of the framework. At this stage, you must determine how you will analyze the results and validate the requirements package with stakeholders.
First, categorize requirements to identify and highlight requirement relationships and dependencies. The table below shows examples of requirements by various categories.
After elicitation, it is very common for an organization to end up with redundant, complementary, and conflicting requirements. Consolidation will make managing a large volume of requirements much more manageable. When collapsing redundant or complementary requirements, it is imperative that the ownership and priority metadata be preserved for future reference. Avoid consolidating complementary requirements with drastically different priority levels.
Conflicting requirements are unavoidable; identify and resolve them as early as possible to minimize rework and grief. Conflicting requirements occur when stakeholders have requirements that partially or fully contradict one another. As a result, it is not possible or practical to implement all the requirements. Resolve conflicts whenever possible during the elicitation phase using cross-functional workshops to facilitate discussions that address and settle conflicts in the room.
Prioritization is the process of ranking each requirement based on its importance to project success. The implementation subject matter experts will use these priority levels to ensure efforts are targeted towards the proper requirements and plan features available on each release. Use the MoSCoW Model of Prioritization to order requirements effectively.
The MoSCoW Model of Prioritization:
You can also prioritize requirements by category as shown below.
Before final sign-off, ensure that you have pulled together all the relevant documentation in a user-friendly requirements package. The requirements package is a compilation of all the business analysis and requirements gathering. The document will be distributed among major stakeholders for review and sign-off.
Some may argue that the biggest challenge in the validation phase is getting the stakeholders to sign off on the requirements package; however, the real challenge is getting them to actually read it. Often, stakeholders sign the requirements document without fully understanding the application's scope, deployment details, and how it affects them. Remember, this document is not for the BAs; it's for the stakeholders. Make the package with the stakeholders in mind. Create multiple versions of the requirements package where the length and level of technical details are tailored to the audience. Consider creating a supplementary PowerPoint version of the requirements package to present to senior management.
Before proceeding with the process, requirements should be verified by domain subject matter experts to ensure that the analyzed requirements continue to meet their needs. This step is often overlooked because it is laborious and can create additional work; however, the workload associated with verification is much less than the eventual rework stemming from poor requirements.
Use the sign-off process as one last opportunity to manage expectations, obtain commitment from the stakeholders, and minimize change requests. Procurement of the application cannot begin until all have approved the requirements package of the critical stakeholders. This will be the third time that the stakeholders are asked to review the requirements; however, this will be the first time they are asked to sign off on them. The stakeholders must understand the significance of their signatures. This is their last opportunity to see precisely what the solution will look like and make change requests. Ensure that the stakeholders also recognize which requirements were omitted from the solution that may affect them.
The sign-off process needs to mean something to the stakeholders. Once a signature is given, that stakeholder must be accountable for it and should not be able to make change requests. Note that some requests from senior stakeholders can't be refused; use discretion when declining.
Finally, Phase 4 focuses on managing and any changes to the requirements package and communicating the application/system changes.
Once the stakeholders sign off on the requirements document, any changes need to be tracked and managed. To do that, you need a change control process. Thoroughly validating requirements should reduce the number of change requests you receive. However, eliminating all changes is unavoidable. The BAs, sponsors, and stakeholders should have agreed upon a clearly defined scope for the project during the planning phase, but there will almost always be requests for change as the project progresses. Even many small changes can negatively impact the project schedule and budget. Route all changes, including small ones, through a formal change control process to avoid scope creep.
Analysts and developers will run amok with their own processes if appropriate governance oversight doesn't exist to create and enforce operating procedures. One of the best ways to properly govern your requirements gathering process is to establish a working committee within the framework of your existing IT steering committee. This working group should be responsible for policy formulation and oversight of requirements gathering operating procedures. Both business and IT sponsors (e.g., a director, BA, and "voice of the business" line manager) should comprise the governance body. The governance team will not be executing the requirements gathering process, but it will decide which policies to adopt for elicitation, analysis, and validation. The team will also be responsible for ensuring – either directly or indirectly through designated managers – that BAs or other requirements gathering processionals are following the approved steps.
Before implementing any changes, you will need to communicate the reason for the transition to all staff and stay on message throughout the change. Successful change leaders spend considerable time developing a powerful change message: a compelling narrative that articulates the desired end state and makes the change concrete and meaningful to staff. They create the change vision with staff to build ownership and commitment. The change message should:
With all parts of the process considered you should now have an guide for requirements gathering that is comprehensive and effective with concrete steps for all parts of the framework. Those managing the requirements gathering process have a clear roadmap of best practices to plan, monitor, manage and communicate applications and systems changes as well as the elicitation, analysis, and validation of requirements.
If you’re interested in creating a requirements gathering program for your IT department or organization, give us a call or shoot us a message.