As member of a project team, have you ever read a project document and thought ‘I know exactly what they want’ and then during the project or nearer the end you are thinking ‘why didn’t someone tell me all this at the start?’
Where does it go wrong?
In my experience, I’ve read many ‘Business requirements’ documents or tender request documents that are, in reality, functional specifications.
It’s important to understand the difference:
- A functional requirements document tells you what the project should deliver.
- A business requirements document tells you what is needed and for what reason (and may provide information on expected deliverables).
When you know how, it’s fairly simple to spot what’s what. Does the document tell you why something is needed? If not, it’s not a business requirements document. A document that only tells you only what or how something is to be developed is a functional requirements documents (regardless of the document’s title).
Why is this important?
The underlying understanding of why this project is being done is just as important as knowing the expected deliverables. By knowing what business needs this project is going to fulfil, you are better equipped to design and deliver a solution that meets those needs.
An example: An e-commerce project might have a business requirement specified as ‘to add a wish list’. That might seem like a business need, but it doesn’t tell you why. The more detailed the document gets on the functional needs, the less anyone is able to say if that’s a good idea, or if it will achieve the desired results.
There are good reasons for the implementation team to know why something is required:
- They streamline their effort towards that goal. Reducing scope creep and reducing wasted effort on needless requirements that don’t work towards the goal.
- They work towards achieving results, not functionality.
- They know the answers to small details required for the project because they know the bigger picture.
What impact can this have on a project?
If you don’t have clear business requirements giving you an understanding of the project goals and business needs, then during a project you can’t tell if the decisions you or your team make are correct.
You might even have incorrectly captured functional requirements at the very beginning of the project, as the business leaders don’t always spot when a functional detail is misaligned to a business need. This might not get spotted until nearer the end of development and by then the design team, development team and testing team have all worked hard to produce the wrong results.
The sooner it’s spotted that a part of the project is going in the wrong direction the less impact that issue has on the project effort overall.
As well as potential wasted effort, there is another important reason why the business matters in Business requirements: team synergy, which will result in efficiency and the delivery of a better product / solution.
Your software is going to be designed, built, tested, and implemented by a team of people. If each person within that team focuses on his or her own understanding of the project’s functional needs and goals, it is possible you will get exactly what you asked for. Most likely, however, it will not be what you require and you will spend more time than necessary building functional software that will then further amendments to fit the business’ needs.
If that same team know the purpose of what the software will be used for and what you hope it to achieve, then they can work together to complement each other’s skills and assist with their ideas, knowledge and experience to reach a collective goal.
How a project is approached at the beginning lays the foundations and affects the ongoing structure of the project, get them wrong and it’s a lot of work to correct. A common mistake, and VERY easy path to take, is to get the functional needs defined and start work based on those, but short cuts are always short cuts.
By working out and defining the ‘business needs’ first and foremost you get:
- A team working towards the same goals, making the result greater than what the sum of the individuals could achieve.
- Better efficiency. Less wasted effort on functional requirements that don’t contribute to the business needs.
- A guide for the entire project. Everyone knows what the business needs are, and when those really detailed functional questions come up, it’s easier to know the answer based on the business need. You get better project estimates and have less time required to get the right solutions.