Do you understand how to gather business requirements or the need to?
A Business Requirements Specification (BRS) or Business Requirements Document (BRD) is a key document that should form part of any project document suite. You should have Business Requirements produced as one of the first documents in a project. Consider that the business requirements are just as important as a Business Case.
Why are BRS or BRDs so important? Business Requirements form the basis for all of the work in the project. You need to gather business requirements to define the scope of the project.
Without detailed business requirements you will have:
- a project that delivers you a system that doesn’t do what the business/users want; or
- a project that only delivers part of what the users want; or
- a project that doesn’t deliver any of what the business wants, and ends up being a complete waste of time and money.
Now you understand why I say they are so important.
Understand current processes
Gathering business requirements is not a simple task. One of the best ways to start is by understanding what the current processes look like (and yes you have heard me say this before), but if you start from the business process then you gain a clear understanding of the current situation in order to identify what needs to change and why which in essence is forming your project.
Gather the current state picture of your process. With this, you will be able to identify who your key stakeholders are. The systems impacted by any proposed change. What else is impacted, for example, reporting will then be visible.
You do this by talking to the people that currently undertake the work. Talk to the people currently impacted. They will explain the current state. The information they provide will help with gathering details of what is required. Ask ‘Who does this today?’, ‘Who is involved in the total process from end to end?’ This will help you find all of the right people that you need to speak to.
Don’t go into solution mode
Business requirements should be written from the perspective of what you want a process to do/perform. They should not be written from a system solution perspective. The system requirements are what is developed in a System Requirements Specification (SRS).
If you develop business requirements that talk about the system you are actually in solution mode. This isn’t a good place to be because a lot of the time there are other ways to solve your process change problems, and so by defining them in your BRS/BRD you could be missing out on a much better way to perform your change.
Let the technical team determine what the system solution looks like. In gathering your business requirements stick to the business process facts.
Be sure to look at the end to end process
If you work in a large organisation, it is very important when gathering your business requirements that you talk to each area of the business that uses a process to determine if they might currently be doing something differently, or have a special requirement that you don’t currently know about.
I can’t stress enough the importance of talking to more than one process user, or Subject Matter Expert (SME). You limit the amount of knowledge of the current process if you only talk to one person and you are doing this at your own peril because it will inevitably lead to users not getting what they need from the system change.
Also, be sure to validate your BRS/BRD with key people in the business. They are the ones using the process. They are the ones that will be able to tell you if you’ve missed something.
The time that you take to undertake these additional steps in your requirements gathering will come back to you tenfold in the project and ensure that the business actually gets what they want and need.
*Image courtesy of Stuart Miles at FreeDigitalPhotos.net