Business Requirements Documentation (BRD)

Business requirements documentation or BRD. If ever there was a phrase to chill the heart of any experienced project manager this would be it. In fact I would actually put it up there in the top 3 nightmares of any experienced project manager.

But why should this be? After all business requirements appear to be a seemingly simply concept to understand and execute. They are after all simply what the project sponsors and project management stakeholders expect delivered. Now surely everyone has a clear view of what is required, so hard can this piece of work be?

Well don't be fooled. The project management requirements gathering phase in general is fraught with problems which only manifest themselves later on in the project management lifecycle. At this stage it is of course too late to do anything about them other than firefight the issues away.

After all, undoubtedly the hardest part of developing a system (hardware or software) is deciding, understanding and determining what needs to be built. Get this wrong and you are facing an escalating project budget, timeframe slippage and the dreaded scope creep. Oh and for good measure, your project sponsors will blame you for the resulting mess despite your efforts!

Not a pretty picture is it?

Now the only good news about business requirements documentation (BRD) is that it is usually at a high rather than detailed level. The reasons for this are two fold. Firstly the business stakeholders aren't interested in how the functionality is implemented; they simply want what they have specified to be delivered. Secondly a BRD is usually defined as part of the project initiation document. Sometimes though if a project has to be rushed to meet tight timeframes it can happen long after this, as is currently the case on a huge project I am delivering.

So an example of the kind of thing you would see in a business requirements document would be something along the lines of the following:

The user will be able to purchase the product via the website using paypal

As you can see this is a very general statement. It doesn't go into the technicals about how exacly the user will be able to do this, it simply states that this is requirement for the project to deliver. Actually determining how it will be delivered is then the subject of innumerable requirements workshops where the individual use cases can be discussed and updated accordingly.

Business Requirements Documentation - Tip

If you have been assigned to the project at the stage when the business requirements documentation is being detailed then definitely go along to the relevant meetings, as this will be your opportunity to influence what your project needs to deilver as well as knocking on the head any flights of fancy the business stakeholders may come up with. Plus it will give you a good opportunity to devise a "cunning" stakeholder strategy to ensure that moving onwards in the project, you will seamlessly be working with stakeholders with ease.

---