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.
A project manager is not responsible for defining the business needs, but on projects where those needs are not being defined then a project manager can steer the business in the right direction. After all it is in the PM’s interest to have well-defined business requirements otherwise his/her project will just run into trouble. Sometimes we assume the business are capable of producing the necessary documentation (or think they should be) but, in my experience, some hand-holding never goes amiss. It’s those soft skills again…
Michelle Do you think there’s a difference between project requirements, business requirements and benefits. Can the project manager be held responsible for the failure to deliver the business benefit. My understanding with the Universal credit project was that the high level policy had not been clearly defined before they started developing the solution. Is the project manager responsible defining the business need?
There is an interesting article by Prof John Seddon from 2011 where he describes the reasons the Universal Credit Project will fail, and 3 years on it turns out he was right. Although the Major Projects Authority (MPA) have introduced a new classification for this project, which is “reset”, DWP are not admitting, after 3 years of delays and design faults, that it is a failure although in effect it is now an entirely new project.
Michelle as you say often not enough attention is given to the definition of requirements before the project starts. If you look at the Universal Credit Project you can see the cost of this mistake.