Thank you for your interest.

Understanding business requirements

Extract from the book by Cenred Harmsworth and Dr Jack Jacoby, Managing Change Initiatives.
Available in Hard Back, Soft Back and eBook from Amazon

DEFINITION AND OVERVIEW

In terms of a change management project or initiative, business requirements are the business attributes, capabilities, and characteristics that need to exist in the business after the completion of the change or project initiative.

Key Points

1. The BRD (Business Requirements Document), next to the project schedule, is probably the most important document developed by a project or initiative.
2. If the BRD is inaccurate, then you will not get from the project that which was intended or needed to get the benefits promised.

Key Actions

1. Review past projects.
2. Determine whether each project had a BRD.
3. Assess the accuracy of each project’s BRD with the outcomes of those projects.
4. Do they align or is there a mismatch?
5. Contemplate this analysis.
6. What were the consequences of the matches and mismatches?

THE DIFFERENCE BETWEEN BUSINESS REQUIREMENTS AND BUSINESS PROCESSES

The business requirements represent the structural, technical, functional, human resource, and operational elements that need to exist in order for the organization to secure the benefits that justify a change project or initiative in the first place.

A business process is the way an activity flows through the organization.

A business process is (or processes are) commonly one aspect of a business requirements document.

Key Points

1. A business process is the way an activity flows through the organization.
2. A business process is (or processes are) commonly one aspects of a business requirements document.

WHY IS THIS IMPORTANT?

An accurate and carefully considered description of business requirements is really important. Small changes or errors can have major cost, timing, and outcome implications.

A description and definition of the business requirements is represented in a document termed the “business requirements document” or BRD.

The BRD is the measure by which all project decisions are made and against which external suppliers are asked to tender and deliver. A robust BRD therefore provides an effective checklist against which a project’s outcomes can be assessed. In other words, the project was meant to deliver the BRD description of the future state - did it?

Key Points

1. The BRD, next to the project schedule, is probably the most important document developed by a project or initiative.
2. If the BRD is inaccurate, then you will not get from the project that which was intended or needed to get the benefits promised.
3. A robust BRD therefore provides an effective checklist against which a project’s outcomes can be assessed.

WHEN DO YOU DO IT?

Without a detailed BRD, it’s impossible to establish exact project costs or to get vendors and suppliers to provide detailed and fixed price quotations for work since they don’t know exactly what is required.

Therefore, it’s logical that the BRD occurs in the following sequence:

Phase 1: The Need

Determine and understand the problem.

Phase 2: Authority

Someone in authority (or the board itself) authorizes that time, effort, and resources can be applied to investigate the options available.

Phase 3: Options

The authorized person or entity reports back to the initial authorizing person or entity, arguing for a specific approach to solve the problem.

Normally, the authorizer will ask for a detailed business case that clearly identifies costs, benefits, risks, resources, and timelines.

In order for this to happen, it’s necessary to determine what changes (if any) are required to the organization’s structural, technical, functional, human resource, and operational elements in order to solve the problem or satisfy the objective.

This is the BRD.

The options that are considered in this phase therefore need to deliver the BRD. If one doesn’t know the BRD’s required outcomes, then how does one choose the optimal option?

Sometimes the choice of option may impact the ultimate BRD as some features of a chosen option may not have all the attributes desired or defined by the BRD.

Here the authorizer may agree to compromise some ultimate benefits to be provided by the change initiative in consideration of cost, timing, complexity, or other context-relevant consideration. If this occurs, then the BRD is modified in a manner that enables it to be an effective tender description for vendors and suppliers.

Without a BRD, a project cannot progress to a robust and detailed business case for approval.

Key Points

1. Establish the need.
2. Get the prework authorized.
3. Then assess options—to do this, you must develop a BRD.
4. The BRD must be complete before a robust business case can be developed and submitted for final approval.

THINGS TO WATCH OUT FOR

Since the BRD is so important to the approval process, the tendering process if an external supplier is contemplated, and to the achievement of the project goals, there are a number of things to watch out for:

• Don’t guess the BRD. Go to the effort of doing the analyses that are required to determine an accurate set of business requirements.
• Talk to all affected stakeholders so that you capture their needs and concerns accurately. Ensure that their needs are captured within the BRD. If you skip this process, you can expect and will have to manage the inevitable stakeholder pushback during the project.
• Consult DOWN the organization with those people who have to work in the proposed new environment. Do they think that the BRD is doable? What are its operational consequences? Ensure their needs are captured within the BRD. If you skip this process, you can expect and will have to manage the inevitable operator pushback during the project.
• To avoid “white-anting” (i.e., internal sabotage), run a few key workshops with important and influential individuals, departments, and functions. Capture their issues and try to resolve them in the workshop. Get their commitment to the resolved BRD in the workshop format in front of others. Document decisions and participants’ presence at the sessions. Have them “own” the workshop outcomes.
• Look at external benchmarks (example of what you are trying to do in other organizations and contexts) just to check that your BRD is realistic, doable, and not beyond your organization’s ability (and resources).
• Identify all assumptions being made within the BRD and decide whether they are realistic and what happens if the assumptions are wrong or don’t eventuate. What impacts will there be on the BRD and the project outcomes?
• Sit with project sponsor and authorizer(s) to talk through the BRD before it’s finalized. This will avoid major rework, demotivation of those who have contributed to the BRD, and avoid the threat to managers’ status and reputations.
• Sit with potential IT/IS or other suppliers to talk through the BRD before it’s finalized to ensure that what you want can be technically achieved at a reasonable cost. This will avoid major rework, cost blowouts, and scope changes. Better to abort a project that can’t be afforded before it starts than to wait until you have already spent significant funds and time before you decide that it needs to be aborted.
• If the change relates to a systems or IT change, then you will also need to be aware of the following:
  • If the future state defined by the BRD is far in advance of the organization’s current capability, will the organization be capable of understanding and using the new system?
  • Are there any security issues that require consideration?
  • Are there any hardware, software, or system constraints?
  • What level of technical support is currently available, and will that be suitable and sufficient for the new environment?
  • Will the new system integrate into existing and out of scope systems, and is the “making fit” process included in the BRD?
  • Is a new system backup capability required?
  • How easy will it be to migrate relevant data from the existing system to the new system?
• Be on your guard against “scope creep,” which is the moving of a project’s scope that has not been authorized or budgeted for. It’s useful that the BRD spell out how requests for changes to scope are to be handled. This will minimize conflict during the project. Such changes are usually handled through a change request procedure and approved by stakeholders.
• It’s inevitable that certain gaps in building the BRD become evident, often after the BRD has been approved and after the project has started. Sometimes this new information is important and will benefit the organization. Therefore, although it’s clearly the desire to approve a robust BRD and stick to it, this should not happen at the expense of the organization or the effectiveness of the project. Therefore, instead of “sticking to the BRD” because that was what was approved; a more useful attitude is “we will stick to the approved BRD unless there is a strong approved reason to change it.” Such changes often have resource, cost, and timing impacts on the project.

Key Points

There are a number of things to watch out for in developing a BRD.

Key Actions

1. Review past projects.
2. Determine which of the “watch for” issues were issues in past projects that affected project outcomes.
3. Contemplate this analysis.
4. What were the consequences of the matches and mismatches?

HOW DO YOU START?

In section 3.2, we discussed how to develop a change vision. Therefore, the steps you will have completed before the BRD is finalized are the following:

1. Assemble an appropriate change vision development team.
2. Determine the problem to be remedied. This can occur through discussions, workshops, or in formal documents.
3. Establish the objectives of the effort to follow: that is, to remedy a problem.
4. Determine the measures and metrics that will be used in evaluations.
5. Understand the aspects and constraints of the problem, which, if remedied, would remove the problem.
6. Discuss what an environment without that problem would look like.
7. Define what an environment without that problem would look like: that is, conceptualize the new environment.
8. Agree whether the picture of the environment without that problem is attainable and right for the organization.
9. Consider options available to achieve the change vision.
10. Agree a preferred option.
11. Determine how and to what extent the environment without that problem contributes to the organization’s or function’s KPOs. In other words, is it worth doing?
12. Agree that the environment without that problem is the change vision.
13. Test and validate the new environment.
14. Get buy-in and ownership of the change vision from as many stakeholders as is practical.
15. As early as you practically can, define the characteristics of the change vision from all aspects of the hierarchy of decision making discussed in section 2.6.
16. Refine the change vision to accommodate operational, structural, and market realities.
17. Use this change vision as the basis of the project’s BRD but be prepared to modify it as more information becomes available. Therefore, the task of the BRD is to translate the often-abstract image of the change vision into a detailed description of the organizational and operational specifics sufficient for people to understand what has to be built and what that looks like once built. Note that commonly, the BRD does not discuss the “how” but rather the “what” that has to be built.

Key Points

To build a BRD, you need a change vision.

Key Actions

1. Review your change vision.
2. Step by step, take each element of the change vision and describe in sufficient detail so that its end state is clear enough for someone to build it exactly as you wanted.
3. When complete, circulate to the stakeholders, asking them to review it all, but particularly the parts that impact on them.
4. When all feedback is in, amend the BRD draft and recirculate to stakeholders requesting further comments.
5. Continue this process until it’s decided that no further changes are required.
6. Publish final version of the BRD and commence authorization and approval processes.

RESOURCES

It’s not normally the role of the change manager to prepare these requirements.

This would normally be done under the management of a project manager who would engage business analysts (BAs) to do this in conjunction with subject matter experts (SMEs)

However, the quality and preparation processes in preparing these requirements are of vital interest to the change manager. If it’s a sloppy job, then the change manager will have to deal with the complaints from the business community.

Knowledgeable business specialists and subject matter experts should always be involved in helping prepare them, as well as the reviewing and approving business requirements.

A number of teams and partners are commonly active in developing the BRD:

• Project core team
• Business partner(s)
• Process owner(s) or representatives
• Subject matter experts
• Product management
• Quality department and/or IT management
• Project sponsor
• Change manager
• Project manager
• Business analysts
• Other appropriate stakeholders to review the business requirements

Key Points

A robust BRD requires the involvement of suitable people across the organization. Certainly it includes not only those directly impacted by the change, but also others who have broad functional or operational responsibilities, as well as certain stakeholders outside the organization.

DELIVERABLES

The BRD document is the deliverable from this activity.

The BRD should have a logical flow and be easy to follow, even by those who don’t have a detailed technical understanding of the focus of the change.

Typically, a BRD will contain the following sections but should be varied to better reflect the nature of the change proposed:

• Business problem statement
• Project overview including project charter information
• Key business objectives
• Scope statement(s)
• Stakeholder list
• Project completion criteria
• Functional requirements
  • Current business process
  • New/modified business process
  • Process detail table (input, form of process activity, output)
  • Overall project business rules and constraints
• Non-functional requirements
• Features and functions
• Quality measures
• Data retention/archiving
• Training
• Limitations
• Risks
• Assumptions
• Impact assessment (fishbone for process functions)
• Functional requirements
• Schedule and budget
• Team information
• Reporting requirements
• Delivery method
• Terms and definitions
• Approver information

Where the change includes process change, the level of detail and other requirements that should be included in the BRD include the following:

• Clearly define start and end points of the processes being covered by the BRD.
• Include process function detail down to three process functions.
• Identify areas of rework and nonvalue adding steps.
• Provide information regarding cycle times, capacities, and rework information for each process step.
• Provide appropriate data that identifies current process metrics compared to the required/expected new process metrics. These metrics will be used to assess the success of the new processes.
• Allowable defect rate (where relevant).

If you would like to have the initial discussion to see if A&M can assist you, or if you have any questions about our diagnostic and methodology, please contact Dr Jack Jacoby, the Head of Client Satisfaction at [email protected]