Business Requirements Analysis – Part Of Project Managers Role

I have discussed before the advantages to a project manager of getting involved in the business requirements gathering and analysis phases of a project. Accurate and clear requirements (formally documented or not) contribute to project success so a project manager needs to be involved to some extent during these phases, whether it is technically part of their role or not.

It is, however, important from the project manager’s perspective to see the “big picture” and remember that some stakeholders can develop a narrow view of the project based if it is entirely from their own perspective. When gathering requirements this must be done from the different angles of everyone affected by the project so don’t just talk to senior management – get anyone else involved who might have some useful input.
Planning

A clear process needs to be established by the project manager to ensure that these processes are understood by everyone. The project manager has a key role here in the development of clear and unambiguous process to be followed universally across the project by everyone. As with all other process these are described and included in the project management plan.

Requirements Gathering

Brainstorming is a great way to generate lots of input in a short space of time but it must be done in a place and at a time when there will be no distractions and with a relatively small group size, whilst still offering a range of people the opportunity to be involved. It is important that everyone sees it as an opportunity to have their opinions and ideas included and not as a chore to be endured.

The success of gathering requirements can very much depend on the attitude of those involved. Everyone needs to feel that their ideas and participation are valued and, again, whilst not strictly a project manager’s role it is invariably the PM who can facilitate this.

A common theme when analysing projects where the final deliverable did not meet all of the client’s expectations is that the client did not know what the finished product would look, feel or work like.

They had read the requirements and maybe even the technical specifications but could not accurately visualise the final product, process or system. This is a particular problem when the deliverable is something completely new to them so for these types of project it can be useful to produce a prototype of the product or system to help the visualisation process. Prototypes can be a lot of extra effort and on some projects such as IT development, for example, can take a considerable amount of work to make meaningful and realistic to the end user. However, prototypes are sometimes the only way to identify inconsistencies, potential problems and usability issues.

Requirements Analysis

Once all of the requirements are known it is necessary to assess what is actually needed to fulfil the business objectives because not all of the requirements raised may be essential. During this stage the business objectives themselves should have become clearer if they weren’t already; they may even have changed, but it is important to stay focused on those objectives. Doing so is the only way to identify what is needed to deliver the product, system or service – this is the defined scope of the project.

One of the major problems with all projects, and a common cause of failure, is when the project starts to tackle areas outside its scope, this is known as “scope creep” (see later). Every individual task or activity in a project must contribute, even if indirectly, to the end result. If circumstances change and new requirements are introduced then as much care and diligence needs to be exerted on these emerging matters as was applied to the original ones.

Documenting the Requirements

Documenting the business requirements may not be the responsibility of a project manager but do expect to get involved with it. The requirements need to be documented in language that is unambiguous and easy to understand so should avoid technical jargon whenever possible. If it is necessary, then there should be a clear glossary stating exactly what each term means, especially any abbreviations.

All of the requirements must be measurable or quantifiable in order to be able to verify that each has been completed. Requirements always need to be documented for a project but the form of that document; the amount of detail and the amount of flexibility within the requirements will vary, especially if a project is using an agile methodology.

The process of documenting and refining the business requirements helps to identify conflicting requirements and potential issues early on in the project lifecycle but are not expected to describe in detail the solution to the business needs; they simply describe the business needs. On some projects additional technical documentation may need to be prepared to describe how the business needs will be met.

The focus of a project must always be on solving the business problem or capitalising on the opportunity and all projects, whatever the methodology being followed, should have a certain amount of flexibility to change requirements or specifications en-route to the end-product.

Some of the key elements to good Business Requirements are:

•   Clear, unambiguous wording
•   Statement of the business objective
•   Sufficient detail to achieve the end-product (or next iteration)
•   Every requirement contributes to the business objective
•   A scope statement
•   Completion/success criteria

The business requirements document effectively defines the Scope of a project; the description of what will specifically be included in the project.

Scope Creep

It is worth mentioning again here the problem of scope creep because avoiding it is necessary to prevent un-authorised or un-budgeted tasks creeping into the project – tasks that are not essential requirements for the final deliverable. That is not to say that a project should have no flexibility or opportunity to change but that changes should be controlled to ensure the project stays focused on the business objectives, which can, of course, also change. Managing the changes falls well and truly within the responsibility of the project manager and doing so effectively is a key element in a successful project.

It is natural for stakeholders to see opportunities for adding or improving business value as a project progresses but it is important to weigh up those extra benefits with the impact on the cost and schedule of the project and negotiate a compromise where necessary. It is important to stay focussed on the original business objectives but also recognise that in some fast-changing environments it is possible for the original business objectives to change part way through the project.

As a project manager, don’t be too worried about what is and isn’t strictly part of your job description. It is the people, and especially the project manager, who will make the difference between a successful project or not. Just make sure that you handle the requirements with tact and diplomacy, appreciate that stakeholders cannot always articulate their requirements nor visualise the final deliverable. Accept that they change their minds and seek a balance between control of the work and flexibility to change. Getting that balancing act right is different for every project but is key to delivering something that meets the objectives at the point of delivery of the end-product.