Skip to content

Business requirements and project managers

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content

At the start of any project the client will have an idea of what the project is intended to achieve; sometimes the idea is vague, sometimes clearly defined. Sometimes the benefits are clear but how it will be achieved is not and conversely on occasions the ‘how’ is clear but the benefits are not.

Whatever type of project it is, there is always something to be gained from taking the time to gather and analyse the business requirements to understand the main key benefits and drivers and also to understand as much as possible about how these will be delivered in practice. This is desirable even in a fast-paced or agile project environment where the detail may not initially be readily available or apparently necessary. 

Don't be tempted to get started too early, without sufficient preparation even if you have a tight deadline (or especially if you have a tight deadline). It can be hard to resist this temptation when pressure is being applied by senior management or the client, but embarking on the project without a clear idea of the requirements, the business objectives and the benefits can easily become a waste of time and effort. Even in an agile environment where work is done in short bursts, then the requirements reviewed and adapted, you still need to know what you are trying to achieve in each iteration before you start.

But is the collection of business requirements and the analysis of them the project manager's job? 

Perhaps not in theory, but unless you work for a very large organisation where the business analyst's role is quite separate, you may have to become involved in this process, not least because the client may need some guiding towards a workable solution.

The finalised business requirements represent an agreement between all those with an interest in the project (the stakeholders) and should help them understand the totality of what to expect once the project is completed, and will ensure that the end-product does actually deliver a benefit to the business.

All new projects come about in response to a business opportunity or problem but, all too often, the resulting project deliverables do not meet that need or resolve the problem. This is often because the requirements were unclear or inaccurate and that is true whether they are in the form of a long, detailed document or a short, rapidly produced agreement in an agile environment. The key to project success is to ensure the requirements are as clear and accurate at the start of the project as possible and importantly that they are altered as and when circumstances change or more information becomes available throughout the project.  

Fortunately there are some useful techniques for gathering this information such as brainstorming and prototyping for instance. But don't just talk to senior management, who may only see the project from their own perspective; get end-users, subject matter experts and anyone else who might have some useful input involved.

For a project manager the identification of anything that contributes to project success is something to be encouraged (even if it means altering plans) as in this way it is possible to have some influence over them, so don't assume requirements gathering and analysis is not part of your role. 

You can read more about requirements gathering and analysis at Parallel Project Training's Community.

Other blogs in this series:

This is a Project Management Fundamentals blog written and sponsored by Parallel Project Training. For more about our project management training courses visit our website or visit my Google+ profile.



Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Paul Naybour
    Paul Naybour 10 December 2014, 01:56 PM

    JohnThanks for your comment. I am not an expert on agile but I do hear some worrying stories. One is sponsoring a project to update a website; its quite a popular website with several hundred thousand visits per day. The project is being run in an Agile way and the supplier will not commit to what functional will be delivered, by when, for the contract price because that is not compatible with the Agile method. I do find this a bit worrying and it sounds like cost plus by another name. I would be interested to hear how agile can work with a fix price scope and time scales. Paul 

  2. Michelle Symonds
    Michelle Symonds 18 July 2014, 11:23 AM

    I have been in the same situation where the business users of new IT systems are reluctant to get involved in the requirements even though they are the ones who will benefit (or not). I think that, as PMs, we have to believe we can work with the business to get a solution - in fact, don't we have an obligation to do so, after all who wants to start managing a project where there is no clear idea of the requirements and the potential benefits.The solution lies with some middle ground between long, wordy Business Requirements documentation that nobody in the business can be bothered to read, and actually having something documented.We should start with the benefits and work back to what we need to do to achieve the benefits. I've worked with teams where we put together a high level BRD, without too much detail, so that at least we can get agreement on something, then we gradually work up to introducing the detail we need once the project is underway. Not always perfect.I like Adrian's idea of an innovation centre - count me in...

  3. Adrian Bailey
    Adrian Bailey 17 July 2014, 11:53 PM

    Unfortunately the loudest advocates for "Agile" need to shoulder some blame here. While the discipline and methods are conveniently ignored or simply not heard by Clients or internal Users, the message of "deliver and iterate"  seemingly without ever having to home in on specific requirements (or even articulate an underpinning need beyond a single vague statement) is picked up and reflected back with desperately depressing regularity.There is a shared understanding that for IS-enabled change it is harder clearly and unambiguously to converge solutions and the ethereal business requirements than for a tangible asset like an aircraft. And yet efforts to help the "business" to do even basic "analysis" are resisted at every turn, even though it's their business. Literally.Of course, I'd love to create a sensibly equipped innovation centre to allow Users to play all day to reach some consensus (preferably facilitated by a Business Analyst), but apparently I can't prove value for money beforehand to get approval to do that either .......