When you really consider your business, your specialty, your audience and your methodology, you can avoid the troubles with business requirements templates.
In our evolving world of deliverables, has standardising the template for your business requirements document become a headache? Do the varying business needs, project types and solution approaches form a moving target? Are people stuck in muddle of practices, haplessly delivering business change?
The good news is you are not alone, these are typical troubles with business requirements templates.
There are many good reasons for the business requirements document, and, sure, there are many free business requirements specification templates available that give guidelines. But be aware,
… downloading a template from the internet or using the template given in a training course and simply changing your corporate logo may well result in a document that is difficult to complete, and that stakeholders neither read nor understand – fast becoming irrelevant.
That’s not what we want to achieve.
To safely arrive at a standard template, one that we can leverage across projects, we must appreciate the complexities we face and respond to them accordingly.
Here are some of the challenges and how we can overcome them:
#1 No one-size fits all
A business requirements document speaks to the heart of a company’s business architecture. And since no two businesses are identical, believing in an industry standard, or even a standard across peer businesses, is not realistic.
Great business requirements templates are tailored to fit the company or department, …
where they are applied, talking directly to the holistic and unqiue aspects of the organisation, people, processes and technology.
#2 The business analysis evolution
As the business analyst function has evolved, the role has branched off into specialist areas, such as strategic business analysis, business process modelling, requirements engineering, and many more.
The business requirements document standard of five years ago can not begin to fit today’s approach.
To arrive at a useful standard, requirements templates must cater for the specialist responsible and how other specialities fuse together to deliver business change projects.
#3 Our broad stakeholder wheel
To further complicate arriving at a standard, today’s audience of business requirements is much broader than the SME’s and analyst programmers of yesteryear.
Multiple stakeholders need to be able to access business requirements from their own reader perspective.
Whether business sponsors, subject matter experts, process owners, project managers, systems analysts, developers, test analysts or change managers, everyone has their own viewpoint.
#4 A rock and a hard place
Many organisation’s work with a hybrid ‘waterfall / agile’ environment, where stakeholder documentation expectations depend on which side of the methodology fence they sit on.
Finding the happy balance between business and technology approaches is key to transition.
Any disconnect between the business management team working within a structured process (Waterfall) and the development team focusing on soundbite requirements (Agile) turns the business analyst every which way but loose.
It is important to have business requirements recorded in support of business change, and equally important to maintain requirements relevance. Understanding these challenges is a good place to begin, and a great philosophy to embrace is akin to a great approach to have in life:- it is a journey (not a destination).
Some of the most useful business requirements document templates I’ve seen have the following characteristics in common:
- They are embraced by the project team as a ‘living document’
- They provide flexibility and are fitted to the type of assignment
- They mirror the problem approach taken to arrive at the solution
Business requirements documents must empower the business analyst to make an effective contribution to the business change. In as much as they capture the business situation, they are the tool that helps the business analyst facilitate the organisation to a worthwhile conclusion.
When defining your standard, consider your company, consider your speciality, consider your audience, consider your methodology and make the business requirements document a living document, one that evolves throughout your business analysis journey.