Of all the things you need for a successful Six Sigma project, having a great Business Requirements Document (BRD) cannot be overemphasized. 

Most organizations have templates or outlines to help a project manager create one. You can also peruse any handouts from certification courses. Plus, instructors often share their methods with students.

The Business Requirements Document is sometimes considered to be the same as a project charter. 

However, some managers use them as two separate documents for different jobs - and I do too.

Let us look at each in turn.

The Project Charter

The Project Charter is an agreement between the management and the project team. It makes clear what is expected from the project. 

The Charter has the following details:

• The problem statement
• Project goals, and
• The scope

You can use it to keep the team focused and aligned with stated organizational priorities. It could also make use of SIPOC, Fishbone, or any other tool to determine the scope and direction of a project. 

The Business Requirements Document Template

More thorough than a typical internal document, a Business Requirements Document template provides the rationale behind business decisions, project choices, the challenges that can be faced and provides answers to questions such as :

• What’s the importance of a particular process? (Value added or Non-value added)?
• Have you identified the problem in the process?
• What's the cost of the problem? (Cost of poor quality)
• How do you know what the cost is?
• What current measurements are available?
• Are current measurements accurate?
• Have you identified the scope of the project?

What's the difference?

You create a Charter with team members and internal stakeholders of the project while you construct the Business Requirement Document with both internal and external teams like suppliers or clients. 

It is beneficial to complete the Charter before the Business Requirements Document to concentrate on reflecting on the Charter from several viewpoints to eventually result in a great project.

What makes a project great?

A project should:

• Bind project parameters with defined goals. If it looks too big, then maybe it is.
• Align with critical organizational issues and initiatives, thus engendering full support from management.
• Reflect (value-added) needs of the customer and thus have a significant impact.
• Possibly work with other contemporary projects for a combined effect.
• Measure improvements at a local level. It's difficult to take action and manage improvements in remote operations.

The discussions surrounding a Business Requirements Document help to determine both project deliverables and scope. Also, it helps you identify any project metrics and data collection processes. So, putting these metrics into the Business Requirements Document formalizes the baseline for the project to all the participants. 

What should the BRD include? 

Your Business Requirements Document should include items like:

• Scope and deliverables
• Any performance specifications
• Estimated Schedules (figuring a certain number and timing of iterations)
• A rough estimate of costs, budget, and returns
• Resource requirements, including the timing of the resources, use or consumption
• Project metrics
• Teams or departments involved (internal and external) depending on the scope of the project
• Questions and compiled responses from VOC interviews
• More than one team, construct a Responsible, Accountable, Consulted, Informed (RACI) Chart
• Reporting mechanisms and their expected frequency
• Project approval markers

Document the above factors for consideration and approval. Since everyone has to agree on the baseline, approval must be mutual across the parties involved. So your team members, external clients, suppliers, and senior management must agree.

What does the customer want?

Accurate Business Requirements Documents depend on creating a shared understanding of what the customer wants. So get members of all teams involved. Focus on high-level requirements and leave implementation details to the Control phase.

A VOC matrix can be beneficial in this portion of the project. So, make it a team effort. When each group brings unique insights, it allows for a more robust discussion on the impact of the project.

Interview Template for better insights

Create a customer and supplier interview template to document their insights. For this article, I’m focusing on the template that deals with the client’s angle. If your project is broad, customize the template to show that you understand how important they are.

In your interviews, the biggest challenge in eliciting project requirements is the details. Customers often do not perceive issues and are uncertain about how a process modification will help. The toughest challenge may be to help the customer realize their requirements.

During customer interviews, add a team member to get direct information from a customer and not from a salesperson’s notes. It will also provide a chance to delve deeper while this specific topic is fresh in the customer's mind. 

Do you know the answers to the following?

When selecting the type of customers for VOC interviews, use the following criteria to identify common concerns. 

A) Use a broad cross-section of possible customers to gain valuable insights

B) Avoid random selection of customers, or interviews of your favorite customers

C) Identify complex categories such as:

• Lead users,
• Happy users,
• Demanding customers,
• Lost customers, and
• Customers you never captured.

Elements to track during interviews

You won’t find a predefined way to distill customer requirements. So you might want to know some of the elements to track during your interview. You must prepare because it shows your readiness as a person or an organization to help customers resolve a business problem.

Here’s how you can do that:

Read the Project Charter to get a clear picture of the project scope and possible impact on the client (positive or negative). Albeit focus on the kind of support you may need from the client to complete the project.

The way you arrange your questions is critical. Keep all pertinent questions within reach, so you’re sure to ask relevant questions. Document all responses from clients, even if they sound random during responses. Be sure to highlight the essential features of responses. 

You must know your customer

• Make sure you are very clear about the customer’s needs so that you know all the pain points and how they relate to the core goal of the project.
• Perform your due diligence. Study the customer to understand their product or service focus, market position, competitors.
• Know the jargon of the customer’s industry. You do not have to be an expert, but prepare for any terms they may come with their responses.
• Can you create a sandbox instance showing a potential impact to your customer? Make sure you set up the instance with relevant industry content. In that way, the customer knows what to expect.
• Have a clear idea of the level of detail that a customer requires. Provide them with a list of topics you plan to discuss so they can come prepared to share internal examples and data.
• Discuss the project’s complexity at their level of comfort so that you’ll have their buy-in from the onset.
• Re-read their responses to them to make sure you distilled the important points they wish to convey. Then document all information (including questions asked) in the Business Requirements Document for any further reference.

Supplemental suggestions

I’ll recommend that you use the documents below as addition to Project (for Control Phase)

Create a Control plan

This plan includes data collected, logged, and totaled on an established timetable (iteration timeline). By monitoring this information, the process remains in control, and you’re aware whenever that changes. Design a VOC plan to track customer satisfaction and receive feedback (increase or decrease). 

If you engage in several iterations at the same time, use A/B testing to merge the best attributes of changes.

Create a “Watchdog” plan

Since you’ve highlighted the essential data, assign a champion. The champion will have the information and authority to control the process and ensure no deviations. (Delegate this in RACI chart)

Create a Feedback plan

This plan will help you if the process does get out of control. What you do is collect and analyze data from on-going VOC interactions or surveys. Then incorporate measures and goals of improvements (A/B test results) in charter or Business Requirement Document.