Business requirements gathering (BRG) is a critical and often overlooked step in a software evaluation and technology selection process. Understanding what your systems currently deliver and the key objectives of a new technology acquisition—is essential to realizing a successful IT investment. Here is a best practice approach you can use to ensure proper requirements gathering for your enterprise software selection project.

Business requirements gathering is the first step in creating “As Is” and “Future” states.
Often, BRG is combined with standard operation procedures and practices (SOP)—but all too often, BRG is not documented very well—leading to poor solution choices. For your software evaluation, BRG provides the framework for your SOP. When preparing for an enterprise software selection your organization must assess its current state and where you may want to go. BRG is the first step in creating the “As Is” and “Future” state for a functional and technical SOP document.

Business Requirements Gathering Methodology

Let’s talk about BRG best practices. When creating business requirements documents there are several approaches to gathering the information, documenting in a structured methodology, definition and prioritization of current and future needs and differentiation between needs and wants are several areas to focus on. These components encourage accuracy and ensure a complete and balanced document for organizations to present to vendors in an RFx or purchase process.

Vendors then conduct their business process mapping to match their features/functions to your organization’s specific practices and configure the system to maximize your organizational processes. Take advantage of RequirementsHub to expertly create and manage your requirements project.

Requirements Gathering Techniques

The following is an approach describing how to create a proper structure for gathering corporate business requirements. This structure provides a framework that can be replicated for each business process.

There are several dozen methods and frameworks to gather business requirements such as TOGAF, ZACHMAN FRAMEWORK, AGILE etc. Since most of them pertain to building products we will stick to techniques that can be used to solicit business requirements within an enterprise software selection process. The key outcome in this exercise to fully document every step of a workflow, business process and task. This attention to detail will simplify the RFX process later and also assist the vendor in proper and optimal system configuration once a software is selected.

Select the Right Software with the Free Lean Selection Book

Several methods of gathering business requirements are:

• Focus Groups within the company – a group of users that perform specific duties and tasks that can be polled to ascertain their duties, functions and system interactions within the company.

• Interviews – an account of what is currently being done to support the business

• Interface Analysis – an examination as to inputs, outputs and intermediary steps that may be required for the system to function and define interoperability to existing systems

• Surveys – an internal account from different points of view as to how operations and processes actually happen

• Observation – this is refers to walking around and drawing your own conclusions as to how things are done

Business Requirements Gathering Methodology Framework

The graphic represents all of the components to include when creating the BRG document. Each piece is defined below.

Business Requirements – This comprises the business objectives, how they are currently executed and what you want the system to accomplish in the future (creating the “As Is” and “Future” states).

User Requirements – The functional and technical requirements that employees utilize when using company systems to complete their job on a daily basis.

System Requirements – This represents the system integrations, inputs and outputs to existing systems and what requirements are needed currently, in the future and integrations between systems. Deeper investigation into this process reveals the interoperability requirements for systems all system to communicate properly.

Wants & Needs – This represents the operations and tasks and workflows in terms of features/functions that the organization requires. Wants are desired features/functions that do not currently exist but that employees would like.

As Is – This represents the current state of operations and practices used by the business and workers to support the business today.

Future – Refers to possible functionality that may be required to facilitate growth, adapt to changing business models and agility for data and portability purposes to enable different deployment models.

Prioritization – There are three dimensions as to how to prioritize an operation or feature/function. The first dimension is to rank and rate a specific feature/function with respect to another, the second dimension is its priority in supporting the business. The third dimension is the overall importance of where this fits organizationally. When prioritizing criteria, using this approach will provide perspective as to the actual want versus need debate.

Select the Right Software with the Free Lean Selection Book

Task – An individual component defined as any piece of work.

Process – A series of tasks that comprise a particular outcome.

Workflow – A series of processes that comprise a definable end.

Putting together your software requirements document

Combining all the above components will create a solid framework to compose your BRG document. A best practice approach is to understand how each task creates a process, then where it fits into the workflow organizationally. All the while considering the priority of business function as to how important it is to support the business. Inclusion of business functions, user requirements needed to execute processes and workflows on a daily basis, how the system is used in terms of inputs, outputs and data usage are all components that need to be considered when creating the BRG spec.

Dissecting each business function to be addressed by a potential software solution

A manageable approach is to dissect each business function, document it both functionally and technically starting from a high level, then working through the details of the process, then once the workflow is created, prioritize the importance of that operation. It is imperative that all processes be documented fully including the exceptions.

The BRG document includes practices carried out within the course of business that may not be executed daily but once in a while, such as closing the books at the end of period or a returns (reverse logistics) process etc. Adding the exceptions to current “As Is” processes also assists in defining the “future” state as the new system should be able to satisfy the need as it is required to support the business.

Then to complete the document try to project what features/functions may be required should your business change, grow and adapt to changing customer needs and business practices. This last step will create the “Future” state of the BRG document.

Using the BRG techniques listed above will provide an approach to gathering the information, then combining the BRG Methodology Framework provides the know-how as to a proper and complete functional and technical SOP document.

Select the Right Software with the Free Lean Selection Book

The following two examples apply to gathering requirements for a BI system or ERP system. Note the top business process, the tasks and criterion within the process and how it applies to the overall workflow. Criterion are individual short sentences that define needs and wants.

Tip & tricks for creating effective requirements

There are certain tips and tricks that ease the creation of the BRG document. We have three tips to assist you in the creation of an effective BRG document.

• Employee Communication and Engagement

To avoid unnecessary confusion down the road, it is important to define to purpose of requirements gathering to the selection team as well as the individuals involved in the process. It is imperative for the organization to understand the importance of this process and the consequences of not getting it right. More often than not, internal resources tend to overlook this process which creates a lack of commitment for the project, culminating to inaccurate results as well as large gaps within your RFX. The gaps are often caused by a miscommunication, omission, or lack of proper two-way collaboration. This can result in an organization not being able to fully utilize the system optimally, may cause discontent and low corporate adoption when the new system is implemented.

• Defining the requirement

Requirements are perceived differently by individuals within an organization. Companies have a very difficult time writing a business process and/or articulating a requirement, mainly because they were never required to do so. A good exercise is to provide a template or an example of a defined requirement. For example, is the requirement a defined business process, a necessary feature or a specific functionality as it relates to your business. This will make the process easier and avoid less back and forth activity to clarify requirements.

• Define don’t assume

Organizations tend to try and solve what they think is needed before the actual definition is completed and the problem actually defined. They may not fully understand what’s wrong or what is required and a potential solution is offered. Asking the correct questions and forming consensus beforehand can often cause incongruity and possibly not cover the initial business concern. Let the entire BRG process takes its course in identifying and highlighting the real issues by completing the individual components of each task, process and workflow.

Select the Right Software with the Free Lean Selection Book

Caveats – keep it real

There are a few caveats when creating a BRG document. Highlighted are a few areas to more closely examine when creating the documentation.

• Prioritization Needs versus Wants

The idea of a new technology entering an organization often creates an anxiety for better processes. This results in overzealous requests and unrealistic expectations from an enterprise software solution. Companies and individuals often convey a “want” over their “need” when looking at business or enterprise software solutions. Placing a “want” over a “need” will create a very different picture of your organization from the software vendors point of view. The wants will shape the solution put forth by the vendor and may not include the original requirement thereby not satisfying the organizational criteria.

This creates a very unrealistic RFI. The problem with this approach is that a vendor is chosen based on the premise that their solution will fit your “wants” not your “needs”. This creates a disconnect between stakeholders, decisions makers and vendors and wide gap between expectations.

The implementation and utilization of the software are very different from your initial expectations. Prioritization of your requirements is very important because it allows the solution provider to know what requirements are more important to your organization. BRG are often created as just the current state of affairs and the future state is rarely documented or considered which often confuses a need and a want.

• Scope Creep

Within a software evaluation the requirements gathering process is commonly susceptible to scope creep or requirement creep. More often than not, the results are inaccurate definitions, false prioritization, overlooked business processes and requirements. The result of this can distort a software vendor’s understanding of your operations and needs.

There are several ways to avoid scope creep within the requirements gathering process of a software evaluation. A common approach is to use PMI methodology to manage this portion of the project as a mini project within the larger scope of the software selection. Following the initiation, planning, execution, controlling and closing of each business process will quickly establish a structure to follow. This creates entire end-to-end workflows that are incorporated and added to the other workflows to create the overall business structure.

Defining the purpose of requirements gathering is essential, this provides clear guidelines for internal resources to follow and gives them an understanding of their responsibilities within the process. This assists in illustrating the importance of how the employee fits within the process and the organization. Documenting your requirements and processes is one of the most important components within a software evaluation process. Controlling the requirements gathering process goes back to your method. If you have a systematic method to define and prioritize your requirements it can substantially avoid scope creep. Conversely, not providing full disclosure to the vendor can also lead to a lack of functionality expected when the software is implemented.

Sending your completed requirements to software vendors

Once your business requirements document is created this provides the next step as to the creation of the RFI or RFP that will be issued to the vendor. The vendor then uses the RFI to match and business process map the required elements from your organization to its software, how it will be configured and which features/functions/modules may be required.

The techniques and approaches utilized above provides an easy foundation to create a polished and complete document to serve as the basis of the RFX and then the vendor demonstration scripts. This is the importance of getting the BRG document correct. Using the recommended approach ensures a thorough analysis of exploring current and future business requirements and provides the data to complete an RFI which is the next phase of the software evaluation project.

Select the Right Software with the Free Lean Selection Book