In an earlier article I discussed the importance of segmenting your team’s Analytics (or interchangeably data science ) work into four (4) buckets to help you effectively prioritize. At the end of that article I mentioned seven (7) key mechanisms for successfully sticking to your allocation investment strategy and prioritization without being randomized. One of those mechanisms is insisting that all strategic projects begin with a well-written Business Requirements Document (BRD). In this article I will provide a brief example of what makes for a well-written BRD. The BRDs I insist on receiving for strategic projects have only three basic questions:
- What are you asking for?
- What is the business value of your ask?
- What are the high-level steps necessary to accomplish your ask?
The typical BRD is just 3–4 pages long; they must be written in prose to enable the writer to clearly articulate the requirements and they should include visuals wherever necessary or possible to articulate the requirements clearly.
What are you asking for?
A well-written BRD begins by explaining in plain English what you are asking for. The request should be economical but comprehensive and clearly lay out the big vision for what you need. It should be easy for anyone to understand and avoid jargon as much as possible. Let’s walk through a (made-up) example of what you should be writing when laying out your ask.
In April 2019 we will be launching Project Houdini, which will enable our customers to order custom clothing at convenient, nearby brick and mortar retail stores that will complement our online ordering channel. Project Houdini will see the unveiling of 10 stores distributed across the Washington DC region; the goal of the project is to measure customer demand for ordering custom clothing in a physical, retail setting instead of our traditional online channel. Over the next six (6) months Project Houdini needs to answer the following business questions:
1. How many customers visit our retail store? How many are completely new customers? How many have previously ordered online before visiting a retail store? How many order online after visiting a retail store? How many order only through a single channel (i.e., online, retail store)?
2. What is the distribution of order quantity and dollar amounts for orders placed by channel (i.e., online, retail store)? Do the distributions change for customers who have only ordered through a single channel? What about those who have ordered through both channels?
3. How does the frequency of purchase change by channel?
4. How does the distribution of customer segments (e.g., small business, wedding, sorority, et cetera) change with channel?
5. How far do customers travel to purchase at a retail store?
6. How does demand for help with their custom design change depending on the channel? Do customers who visit a retail store engage more or less frequently with our graphic designers compared to customers who order online?
7. How does the types of blanks (i.e., pre-customized clothing) customers select change with channel? Do customers who order at a retail store move up to better quality blanks? Can we infer that "touching and feeling" the blanks better communicates to the customer the difference between good, better and best quality blanks?
8. Does opening a retail store cannibalize online orders within the vicinity of the store? Or does opening a retail store grow total demand from that region?
These business questions should be answerable using a Tableau application built specifically in support of Project Houdini. The application should provide high-level views of the data that will support weekly and monthly business reviews; and the same application should also enable "deep-dive" analysis of the business questions. Business users should be able to select the aggregation of the data at the daily, weekly, monthly and yearly level. The Tableau application should scale from a single retail store to multiple retail stores aggregated together and permit the comparison of online and retail orders and customer behavior. Wherever possible, the data should be viewable on a map to enable business users to understand customer behavior geographically.
This (made up) example of a well-written "What are you asking for?" enables a Data engineer and business intelligence engineer to understand, in plain English, what are the key business questions that you need answered. When we understand those business questions, we can help you design and compute the correct business metrics, and select the correct visualizations that will make the data easy to digest. Notice what is missing in a well-written answer to this question:
- It is not a list of metrics (e.g., % of customers who ordered at a retail store)
- It is not a set of charts (e.g., Excel-based examples that say "build exactly this chart in Tableau")
- It is not 10 pages of requirements
What is the business value of your ask?
After explaining what you are asking for, a well-written BRD explains what is the business value of investing in building what you are asking for. The business value should be clear, precise and honest in what is known versus what is assumed. It should also focus on the boring "nuts and bolts" of why your request should be prioritized and invested in.
Project Houdini was approved and launched under the assumption that retail stores will complement and not cannibalize online orders; the project assumes that retail stores will attract new customers who would never (or mostly never) order custom clothing online because they prefer to "touch, feel and interact" with our products before placing an order. We further assume that customers who prefer ordering at a retail store (instead of online) have a higher preference for the personal touch that is intrinsic with visiting a store and interacting with our store associates; we believe these customers need the reassurance that comes with dealing with a person face to face when ordering custom clothing. Our estimates is that Project Houdini will generate a 10% lift in orders (with similar average order value) within 15-miles of the retail store (i.e., will generate 10 retail orders for every 100 online orders placed within 15-miles of the retail store). If our assumption is true, the retail store network will generate an incremental $35-million dollars in annual revenue ($3.5-million per store) and have a payback period of 3.5 months assuming a $1-million CAPEX investment to launch the average retail store.
The Tableau application we are asking for will enable us to easily understand the performance of Project Houdini and verify that the assumptions underlying the project are correct. If we do not invest in building the application, it will require 40 hours of weekly work across two (2) people to manually build reports using Excel. The manual creation of these reports will decrease the quality of the data and delay our reporting on the performance of Project Houdini. With a Tableau application we expect to meet weekly every Monday afternoon with senior business leaders to review the prior week’s performance; without the application we will have to wait until at least Thursday to review the prior week’s performance. Furthermore, the Tableau application will enable us to quickly perform "deep dives" into the data during the Monday afternoon weekly review to answer any questions asked during the review whereas manually reporting with Excel will force us to spend an additional week of time after every weekly business review to pull the data and come back with answers to questions asked the prior week.
In summary, manual reporting using Excel will introduce a 1–2 week delay in understanding the performance of Project Houdini, decrease the quality of the data, and require investing 40 hours a week of manual work by two (2) people to prepare the data and Excel-based reports. For a company with $350-million in annual revenue, a $10-million investment in Project Houdini is not an insignificant amount so it is important to maximize the quality of the data and minimize the delays in measuring and understanding performance so that we can quickly take action to make Project Houdini successful.
Notice that this example clearly articulates in plain English all the assumptions and reasons why this project should be prioritized and invested in. It does not simply say "This project will generate $35-million in annual revenue" but explains the "nuts and bolts" negative consequences of not meeting the ask: 1) major delays in measuring performance; 2) decrease in the quality of the data; and 3) tying up two (2) people every week to build Excel-based reports of suspect quality. It also describes how large of an investment Project Houdini is for the business and how enabling its success would impact the entire business.
What are the high-level steps necessary to accomplish your ask?
This is often the most difficult questions for the writer of the BRD to answer; it is oftentimes necessary for a data engineer and/or analyst to help the writer in this section. But I use the word "help" very deliberatively because it is the responsibility of the requestor to write the BRD him-/her-self. The data engineer and/or analyst can explain to the writer what needs to be done but it is the responsibility of the writer to become sufficiently educated that they can write down what needs to be done at a high-level. Sometimes I get asked "why not just write this yourself instead of forcing the business user to learn from you and then write it down?" There is a very good reason for this: it forces dialogue between the data engineers and/or analysts and the business users who are asking for help. That dialogue provides something of value to both sides:
- For the data engineers and/or analysts it helps them understand the business requirements and business value of the ask; they get an opportunity to ask clarifying questions that might not have been considered by the person writing the BRD
- For the business users writing the BRD, it helps them become educated about the technical details of their ask; the data engineers and/or analysts get an opportunity to explain what needs to be done to provide the business user with that they are asking for
The two-way dialogue helps both sides better learn what the other person is trying to do and, most importantly, why.
To build the Tableau application necessary for Project Houdini, the following high-level steps much be done:
1. Ingest the transactional database for the online ordering system into our Business Intelligence (BI) data warehouse
2. Ingest the transactional database for the retail ordering system into our BI data warehouse
3. Design and build a data model that combines the two transactional databases into a standardized and clean set of data objects (i.e., star schema) that enable us to answer the business questions
4. Write documentation for the data model and performance Quality Assurance (QA) on the data model to verify the correctness of the data
5. Define the metrics that answer Project Houdini’s business questions
6. Design and build the back-end data structure for the Tableau application
7. Design and build the Tableau applications UI/UX
8. Review the draft Tableau application with the business user stakeholders
9. Incorporate feedback from the business user stakeholders
10. Write documentation for the Tableau application
11. Launch the Tableau application
In my experience, almost every BRD will have 8–12 bullets in this section listing the high-level steps that need to be executed to meet the ask. Notice that there are two items in this list that are explicitly mentioned but almost always forgotten: 1) documentation, and 2) QA. These must be explicitly mentioned and no project can be considered complete until the documentation is ready; in fact, we never "launch" any strategic project before completing the documentation to avoid the temptation to just move onto the next project and cut corners.
So, above you have a good example of a BRD. You will notice it is concise, clear and easy to understand. A good BRD for an analytics project does not need to be a scary amount of writing; I rarely ever see the need to write more than 3–4 pages for any analytics project.
Hotly Debated Topics
The example BRD above 1) avoids providing a list of metrics, but 2) it assumes the right solution to the problem (i.e., a Tableau application). Does this make sense? In my experience, this is a hotly debated topic. I will explain why I insist that a BRD avoids listing all the metrics and why I am OK with the writer of a BRD assuming a solution. First let’s discuss "the metrics" and then discuss the "assumption of a solution".
The analysts and/or data scientists are – by definition – the experts in analysis (and Data Science), not necessarily the business user writing the BRD. By asking the business user to describe the business questions they are trying to answer, it enables the analytics team to better understand the business and how business leaders think about it, and it encourages the analytics team to think deeply about the business and what type of analytics would answer the business questions. That process is cut short when the BRD is a list of metrics because the tendency becomes for the analyst or data scientist to simply compute whatever metrics are requested even if those are not the "best" ones for answering the business question. The BRD is a mechanism for forcing conversation between the analytics team and the business team. That conversation makes it more likely the business team will get the best analytical solution possible, and it will make it more likely the analytics team’s solutions are truly business value added (i.e., less academically oriented).
If your business "complains that your analytics or data science organization is disconnected from the business", the primary reason (in my experience) for that disconnect is that there are no mechanisms for forcing conversation between the analytics and business teams (e.g., like a BRD that avoids listing metrics to compute). You always want to put in place processes that encourage the business users to explain the business (e.g., the key business questions) to the analytics and/or data science team. That ensures that the analytics team is tightly integrated into and thinking about the business in concrete terms. In the other direction, you want to ensure that your analytics and/or data science team is fully using their expertise and skills to benefit the business. Maximum business value will not come from having your expensive analysts or data scientists computing metrics selected by the business users; the maximum business value will come from having those analysts deploy the full suite of mathematical thinking and techniques they’ve spent 10+ years learning. That will only happen if they are consistently exposed to the business in concrete terms. Avoiding a list of metrics in a BRD is one way to ensure that (there are other mechanisms we will discuss in the future).
Over my career, some have disagreed with BRDs making any assumptions about "the solution" to the business problem or questions. Philosophically, they disagree with a BRD that makes statements like "These business questions should be answerable using a Tableau application built specifically in support of Project Houdini." Instead, they prefer to discuss only the business problems or questions (and features they’d like in any possible solution) and leave all discussions about any possible solution out of the BRD. I sometimes have agreed with that opinion and other times disagreed. I have vacillated back and forth because strictly excluding any discussion of a solution (even conceptually) sometimes has made it difficult for the writer and the reader to understand the ask because it can lead to very abstract BRDs. On the other hand, BRDs that are very prescriptive about the solution can create the same issue that we discussed when I insisted that the BRD not (just) include a list of metrics to compute: the analytics and/or data science team "turns off their brain" and simply builds the thing asked for. That can become a problem if the solution requested is not the "right" or "best" one.
My experience to date has driven me to adopt a somewhat middle ground approach to the question about assuming solutions in a BRD. I believe allowing the business user to assume a conceptual solution when writing the BRD is important to enabling them to clearly describe their business problem and what they’re looking for. On the other hand, it must be clear to business users that the assumed solution is conceptual and the solution implemented will come from the review of the BRD (and the back and forth conversation during its review). The analytics team will design the solution that meets the requirements described in the BRD; and that solution may ultimately be different than what was assumed.
Want to Learn More?
To remind yourself of the seven (7) key mechanisms for successfully prioritizing analytical work, look at my part one article. If you are a bit more statistically curious today, try [[this article](https://towardsdatascience.com/better-communications-between-data-scientists-and-business-users-46f493ce24ba)](https://towardsdatascience.com/the-three-most-important-statistical-tests-in-business-analytics-fd958a8e2a90) about A/B testing or this article about the three (3) most important statistical tests. Finally, if you want a very fast 1–2 minute read, try this article on eight (8) tips for improving communications between data science and business users.
