written by: Jean Scheid
• edited by: Michele McDonough
• updated: 5/20/2011
The scene: You’re the project leader and everyone loves you! You want to dive right in and get things going right away but once you do, the game changes. Avoid the unforeseen by writing a business requirements document—learn real examples here.
Basically, a business requirements document (BRD) ensures the stage is set—for every element of the project before you begin to deal with client changes, user disappointments, team conflicts and just about anything else that could (and might) go wrong.
Via the BRD, project leaders can be assured that no unexpected changes will occur, nor will they have to change game plans halfway through the project.
A BRD is written prior to the project scope and while they can be lengthy, once you get past your first effort, you can use the basic outline again and again.
Mind Tools says all BRDs should include five key elements:
Interpret and Record Requirements
Signing Off on the Requirements
slide 2 of 6
Real Examples of BRDs
So, you’ve downloaded the free BRD and you’re ready to begin the task of developing your own, but wait—here are some real examples of process business requirements documents showing one that missed the mark and one that won using an effective BRD.
slide 3 of 6
The Chrysler PT Cruiser
If the Chrysler Group would have thought ahead and used a more in depth BRD before production of their PT Cruiser, they may have saved all the headaches that followed. Using the above elements, let’s look at how their BRD failed.
Stakeholders – Chrysler pretty much had most of the stakeholders identified including teams, vendors and the production of the PT Cruiser. Stakeholders that weren’t identified included the dealerships that would be selling the Cruiser and the end customer purchasing the vehicle—these two stakeholders were simply left out of the BRD entirely. An oversight indeed as perhaps these two stakeholders were the most important.
Stakeholder Requirements – Again, Chrysler did a pretty good job when it came to everyone at top levels supplying and overseeing the build. What they didn’t do was question the timeline for production (manufacturer to market), end users (customers) or dealers (sellers) on things such as price, model availability, demand and optional equipment. Had they taken the time to gather these requirements, perhaps those unforeseen delays in product delivery could have been swayed. Many consumers awaited the PT Cruiser to hit the showroom floor in models and colors presented in brochures only to find not only were the color choices slim at the get go, the vehicles didn’t arrive often until months after they were promised.
Categorizing Requirements – If Chrysler’s BRD included the requirements of all stakeholders, they surely would have discovered not only the end user needs and wants but also realized why vehicle production was delayed—in advance of production.
Signing Off – Every BRD requires signatures from project sponsors, lead stakeholders and stakeholder representatives to ensure the project will be delivered as required and requested—and on time. Chrysler also failed to do this meaning the actual money maker for the Cruiser (the customer) was left out of the picture and another important stakeholder (the dealers) were left returning deposits to unhappy customers.
If Chrysler would have utilized a well thought out BRD, this example of a process business requirements document may not have failed but succeeded on every level. In fact, Chrysler stopped production on the PT Cruiser in 2009—that alone speaks of failure.
Stakeholders – Apple did a good job of keeping everyone involved including the end user and retailer—that included focus groups.
Stakeholder Requirements – The eyes of Apple developers, retailers and end users all got to participate in things like options, design, and pricing. Apple’s in-depth research was to hit the market with a product that delivered what was promised—and they did just that.
Categorizing Requirements – Apple looked at most desired features, the ability to customize, and Internet access among other elements. Stakeholders from top to bottom were pleased with the results and the iPad would become a hot ticket item.
Interpret and Record Requirements – From focus groups and developer ideas, Apple was able to find what was most important for the iPad to succeed and what could be left in the background, or as a customization option. They knew what was wanted and delivered on that promise.
Sign Off – Both developers and real end users got to test the iPad before Apple’s BRD was given the go ahead and signed off by all involved. This ensured a product that had quality, desirability, and a price that would make a profit for Apple, happy retailers and end users.
slide 5 of 6
Final Thoughts on BRDs
The two sample process business requirement documents we looked at here offered two very different results. The Chrysler failure due to an incomplete stakeholder analysis left out two of the most important stakeholders causing project requirement delays and customer dissatisfaction.
Apple on the other hand, took the time to involve stakeholders and their expectations and the end product resulted in a hot seller for Apple and a happy consumer.
The key to successful BRDs is understanding why it's important to get every detail, desire and requirement from all stakeholder before the game, not allowing the game to change once it's started.
Do take time to learn how to write a business requirements document and once the first one has been tackled, you can utilize your outline as a template for all future projects.
slide 6 of 6
Mind Tools, Business Requirements Analysis - http://www.mindtools.com/pages/article/newPPM_77.htm
Stroud, DeLayne - iSixSigma, Business Requirements Document – A High-Level Review http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1076:&Itemid=190