BRD: Really a Need or Time-Crusher?

BRD: Really a Need or time-crusher?

BRD-timecrush1BRD-timecrush2As a BA the one thing which strikes in our mind is to design a high a quality BRD (Business Requirement Document). In my last post I have written an overview of BRD which includes the features of a good quality BRD. Few days back I was attending a webinar on the same topic in which the presenter was discussing all the details. It was really interesting to know that BAs devote most of their times in designing an easy to understand document which contains business requirements. A BA first discusses the details with different stakeholders do the brain storming and then designs a document using all his writing skills to make it as simple as possible so that the others can understand the requirement and the project can run smoothly…. Oh God how much intelligence required in that!

But this all gave me a thought that after designing a document of 100+ pages with all the efforts to include the business requirements will the document find the intended audience? Will that document find space in the INBOX, which is usually flooded with other mails (in a survey it was found that the business decision makers usually get 85+ mails per day), of the stakeholders and will all of them spare their time in reading those 100+ pages? I think NO. So if the answer to this is no, then why BAs are devoting their time in designing BRDs. Documenting a requirement sheet will require tremendous efforts in organizing, double-checking, typing, copying, pasting etc which will turn out as 85% of clerical job and in turn it will reduce the strategic competence of a BA. Thus it can be accepted that a BA who is sparing 85% of his energy in doing clerical job can’t make impact on the organization with his strategic skills.

BRD-timecrushMulti-page BRD often results in blind approvals as many of the reviewers get tired of reading whole version several times and they often feel that the latest version which has landed in their inbox would be most correct. This impression results in project progress with a BRD with blind approval which in turn heavily impacts the project life-cycle at later stages. It is confirmed by several BAs that more than 50% of requirement feedback comes at later stages of the project.

A BRD is prepared after several brain-storming sessions with different stakeholders but a BA is also a human and he has all rights on this earth to forget some of the contents of the sessions. Due to this sometime a BA misses some important notes and which results in an incorrect version of a BRD. Several reviews of the same will then open different loops and in turn the TO-DO list of a BA increases. He most of the times then has to collaborate all the changes proposed and write a common requirement document. This again is a chokepoint in the progress of a project.

Requirements are the result of imagination of the stakeholders. In the requirement gathering interviews and other brain storming sessions stakeholders usually imagine what they want in the project and texting down all those imaginations is not simple for a BA. Thus BA usually has to write more and more text to elaborate the actual requirement. This increase in the text increases the size of a BRD but the credibility of the BRD decreases as the multi-page BRD will result in more blind approvals. To overcome this scenario a BA has to design some prototypes to show the requirements in the form of a image instead of a text.

Thus we have seen that a BRD which on one hand is actually required by the development team to start the project is a time-crusher and sometimes career-crusher for a BA. To sideline this issue, BAs are advised to use some of the requirement gathering tools instead of using spreadsheets and documents to write whole story. There are many advance products available in markets which decrease the clerical job of a BA and helps in analyzing the actual requirement. They not only help in clear understanding of the requirements but also increase the credibility and strategic skills of a BA. Most of the BAs are now using software tools which help them in defining the requirements in just few mouse-clicks.

Happy Reading!!!

4 thoughts on “BRD: Really a Need or Time-Crusher?”

  1. Hi Aniket,

    With all due respect, your posts are focused but if you try sharing the tools you use will be much more informative to the readers.

    I would like to share some of the templates/tools I use in my BA work:
    Below is the site which offers free requirement management tool and Templates useful for BA’s

    http://pragnalysis.com/index.php?option=com_content&view=article&id=109&Itemid=61

    Download the tool kit, use it and don’t forget to share your experiences.

    Meanwhile Aniket we would like to hear which tools/Templates you use.:)

    1. Hi Nutan,

      Thanks for sharing useful information here. I would definitely try to use this tool and share the experience. The other requirement management tools available in market are developed by “blueprint”, “enfocus solutions” etc. You can try to use anyone of them. I believe they are not free tools (may be you can get free-trial version). I am using rational tools for my work.

  2. The BRD is a container for the results of Requirements Discovery. The only people who have to review and approve it are the people who participated in the requirements discovery, so they already know what is in it, and will also know if something is missing. These are the people who the sponsors said would provide the requirements,so their approval should be sufficient for any sponsor to sign-off. (Also, brain-storming is not a good technique for requirements discovery, come by http://www.iag.biz for info on good techniques and Requirements is general.)

    So, a BRD is not a novel or story; people outside the sessions should not be expected to read it, except for those who use parts of it for input, like design and testing. So, it should not be a burden and time crusher, it should come out right out after the sessions, especially if you use Paired Analysts, one to facilitate, another to capture and architect the doc in real-time. This is how I and my IAG peers work everyday.

    1. Hi David,

      I think there is a gap in understanding the views. I have mentioned here about the difference in writing the stories and using the tools to design the BRDs. I understand that the BRD is the result of requirements discovery, but writing complete story can sometime become tiresome and also the approver may feel difficult to understand. Also there may be some cases when the approvers have to go through long list of awaiting mails, which may result in the delay in the approval of the same. Hence i pointed to use some tools instead of visualizing and writing contents of requirements.
      Accepting the views in article is totally at readers discretion. I hope this may fill the gaps.

Leave a Reply