Business requirements and project managers

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:

• Project management - an introduction
• Project management processes and phases
• People and behaviours in project management
• Using a Gantt Chart to manage a project schedule
• Project managers don't forget about behaviours and attitudes
• The basics of an effective project plan

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.