Never underestimate the value of documenting business requirements.
All too often I have seen projects which were clearly on the road to failure, even before they formally started. Why? Because they didn’t have fully defined and documented business requirements.
Most people would say “But we understand the scope, and we’ve set a budget and timeline, and resources are committed, so what’s the problem? The problem is …If you don’t have fully defined and documented business requirements, then how can you say that you understand the scope of your project?
That’s as good as saying.. I want you to build me a box. As long as it has four sides I’ll be happy. So.. I go off and build you a box.. I create it based on what I think the size needs to be. It’s fully enclosed with no openings at all. And I paint it red.. because I like red. Oh, and it’s made of wood.
I’m feeling pretty good about having managed this project, because
- I’ve completed it ahead of time,
- You’ve got a box, which is what you asked for,
- And.. I saved some money along the way, because the timber was on sale when I purchased it.
When I hand you the box.. You look at it and I can see you’re not happy. I ask you “What’s the problem, I’ve given you what you asked for?
If I’d bothered to work with you to fully define your business requirements for this ‘box’ I would have found out that:
- The box needed to be a certain dimension, to fit in a hole that you already had
- The box needed to be made of glass or something similar, because you needed to see inside it
- It needed to have an opening so that you could put things inside it, and take them out again
- It also needed to have a door in it, because you wanted the things once put inside it to be stored safely from the environment
I think by now you’re getting my drift.
The business are the only team of people, as users, that really understand their requirements. If you don’t ensure that you capture all of your requirements in enough detail, then there is no way that you are going to fully meet either their requirements, expectations or needs. Not very good customer service I’d say!
Business Requirements do not need to be 100 pages long. I find that setting up a table format works well, where I capture each item (need) as a requirement. Remember, this is not about solutions, it’s fully about needs. What is it that they need?
For example: Ability to capture client phone numbers in two forms i.e. local phone and mobile phone
This says nothing about ‘how’ this might happen, it is simply stating the need. Business requirements don’t need to describe the ‘how it will happen’, that is what functional specifications are all about.
Let’s face it. Your customer might want more than you can deliver, both from a time perspective and a cost perspective. Things always cost more than is estimated, and usually take longer than is estimated. This is where I find value in adding in the details of whether this ‘need’ is a should or must have, or simply a ‘nice to have’. Do yourself a favour and ensure that you only include the necessary items or those ‘must haves’ in the first phase of delivery. That way you can really ensure that you CAN deliver. What I found was there were times when, in coding up a project the programmers could include some of the ‘nice to have’ items as they went along, at no extra charge. What we did was under promise and over deliver. Happy customer.
In capturing business requirements it is also very important to capture the non functional items. Here I am talking about expected delivery time of search queries (for a database search) for instance, or the importance of traceability and tracking. Also remember to build reporting into your capabilities. These are areas that the business usually really wants, but forgets to ask for. And, is then disappointed, when they don’t get it.
Do a first draft of the requirements, have then reviewed, updated and then signed off, before you start. Believe me, you’ll be very glad you did.
Taking the time to document that requirements is well worth it in the overall project scheme of things. I have personally found that it saved time, money and stress levels on the project. There was greater clarity and no question marks. Documenting business requirements is time well spent.
Written by Karen Munro