Business Requirements Management

The bad news is that business requirements management is an absolutely thankless task. The good news is that it is one which the business analysts are supposed to pick up. If you don't have any business analysts on your project then I'm afraid that you, as the project manager have got the short straw, and will have to do it yourself.

Now you may well be thinking, "but the business requirements documentation has already been written and approved so what's the problem?". Well you would be surprised at the amount of times I have seen 20 people leave a meeting, all supposedly with exactly the same idea of what the project is delivering, and the result is what you see below.

Shocking isn't it? And this is what tends to happen on every project, unless of course it is a really small one.

So what can you do about it? Well business requirements management is, as I've already mentioned is best left the business analysts. If you were to ask, "what is a business analyst?" well they are the people who should have a clear idea of what the requirement says and more importantly what the business sponsors mean't. This reduces the amount of intepretation the project team leads have to do, which in turn ensures a more accurate deliverable is produced.

The other thing to bear in mind are the use of change requests. What you need to realise is that a business requirements document (BRD) is basically a "wish list" from the business. Often when you start doing the detailed requirements you discover that it is virtually impossible to deliver what is required.

For example on a recent project the business insisted in the BRD that results had to be sent out by SMS. However on closer inspection it appeared this was something which none of the Organisation's system supported. To make the change would cost an additional $100,000 which had not been included whilst estimating project costs. When it was discovered that there was no ROI (return on investment) case to back up the expenditure, the requirement was dropped. This mean't a change request had to be raised by the business analyst to which then caused more paperwork to be generated due to the change request management required.

Business Requirements Management - Tip

When it comes to doing business requirements management, make sure you delegate the job to your business analyst team. You cannot possibly have a detailed understanding of potentially 272 requirements (as on my current project), nor the time to deal with all the queries which result. After all this is a key part of the role of a business analyst, and as such, if you want to stay sane you need to delegate to those with the right skill sets. In this case someone with the right business analyst skills.

You are better off spending your time concentrating on managing project teams and working with your project management stakeholders to ensure their expectations are met in the event of the need to de-scope some functionality as part of the change request process.

---