Documentation is critical for any Business Analyst and/or Project Manager. But the fact of the matter is that the current practice of using a paper-based Business Requirements Document to define solution intent is no longer proving to be enough to effectively manage the complexity of requirements. Rather than propelling your organization forward, your Business Requirements Document (BRD) may actually be holding you back. Aside from being prone to errors, manually-driven documentation is also not an effective way of aligning the customers’ needs with the capabilities of the IT team.
As technology becomes more pervasive, and the demand for quality products becomes more widespread, organizations today must reconsider the status quo and push for more innovative ways of communicating product requirements to all stakeholders. Not only will this ensure that the products being delivered live up to the expectations of the user, but also that they will be delivered faster, on-time, and within budget. In order to do this, requirements need to be consistent, easy to understand, and relevant.
5 Reason Why Your BRD Doesn’t Cut It
While you may be comfortable and used to working with a Business Requirement Document, they are now proving to be less effective than their digital counterparts – requirements management tools. Here are 5 reasons why your Business Requirements Document (BRD) just doesn’t cut it anymore:
1. They’re Wasteful:
By setting everything up as a requirement, we confuse priorities. As a result, developers end up building more than they need to without adding any additional value to the end user. In fact, a study completed by Standish Group Report found that of the projects that were successfully delivered, 45% of the features were never even used!
2. They Often Don't Prioritize the Customers’ Problem:
By nature, BRDs require you to start documenting features and requirements up front. However, by doing this, you’re missing a critical component of development – you’re not prioritizing the customers’ problem or engaging with the design and engineering teams.
3. They’re Likely to Be Outdated:
Things change quickly! But by the time the BRD has been written, it’s extremely likely that it’s already out of date. This leads to endless hours of rework (both on rewriting the document and redeveloping the product) and unsatisfied end-users.
4. They’re Open To (Mis)Interpretation:
The person who writes the BRD and the person who has to read/act on them often isn't be the same person. Essentially, this opens up the document to becoming like a game of broken telephone – riddled with errors, misinterpretations, and missed requirements.
5. They Limit Your Product:
By using a BRD you are effectively capping the possible outcome, while simultaneously reducing the scope as you begin to run out of time and resources. This means that your customer expectations are immediately overlooked just so you can ensure that you’re actually delivering something functional.
3 Sources Of Error That Cause Misalignment
The shortcomings of your BRD can result in 3 critical errors. Not only do these errors impact your bottom line, but they also adversely impact your relationships with external stakeholders.
The three errors are:
Misunderstanding - Business, IT, and external stakeholders all speak in different languages and work in disparate tools. This increases the chances of misunderstanding across all fronts, but the main challenge of this is that the BRD is riddled with ambiguity which is the start of most challenges through the development lifecycle.
Mistranslation - Since the BRD is plagued with vagueness, developers and testers are likely to interpret it in different ways and create user stories/test criteria based off of different translations of the document. Not only does this impact the actual product being delivered, but it also results in endless hours of rework for all IT teams.
Misconstruction - Ultimately, misunderstanding and mistranslation have a significant impact on what product is delivered at the end of the release, and often times it's not what the end-user expected.
Learn More: How To Avoid The "This Isn't What I Paid For Conversation"
So, what's missing? Alignment.
What’s The Alternative?
To avoid the obvious setbacks of a BRD, organizations should put greater emphasis on the importance of cross-functional alignment.
Designed to bring greater efficiency and value to the software development lifecycle, cross-functional teams are the best way to provide on-time delivery of high-quality solutions while optimizing delivery and removing requirements bottlenecks.
Learn More: Breakthrough The Requirements Bottleneck
Borrowing the first principles of the Agile manifesto, working collaboratively within one team to design the right product for your customer is absolutely critical. To bridge the customer-centricity gap as efficiently as possible, here's what you should be doing instead of wasting countless hours writing a Business Requirements Document:
Focus on Individuals and Interactions:
Instead of relying on a Business Requirements Document (BRD) that encompasses every minute detail of the product, you should switch gears and focus on working in an iterative process. This will promote cross-functional collaboration, ensure your requirements are up-to-date (and/or added as needed), and embrace the needs of the end-user throughout the entire development process. Collaboration will yield faster, clearer results because they were achieved in conversation with all applicable stakeholders.
Focus on Delivering Working Software:
Because business and IT stakeholders work in silos it's very difficult to properly interpret what the end-user expects from a Business Requirements Document. Rather than each team individually interpreting the Business Requirements Document and then working in their own tools, cross-functional teams should work together to determine what requirements should be prioritized. One way to do this is by creating visual models that depict the user's journey. This will ensure user stories are consistent, relevant, and easy to interpret.
Focus on Customer Collaboration:
If you want to build something valuable, you have to collaborate with your customer. Cross-functional teams work closely with their customers to understand what problems they're trying to solve. When everybody is on the same page, the risks associated with misinterpretation are significantly reduced.
To learn more about effectively transforming your requirements management practice check out our latest eBook: Overcoming Modern Software Challenges With Requirements Management.
