I once had a project where an adjacent landowner almost came to blows with my site inspector before any ground was broken. Although we purchased a piece of his land and showed him the plans before the construction bagan, he decided once he saw construction folks arriving on site that the project was going to impact the drainage on the land he still owned (we disagreed).
Requirements Management
Collecting requirements is the first step in project scope management, as defined by the project management body of knowledge (PMBOK). Before you can define a project’s scope, you need to define the requirements the project must satisfy.
As you can imagine, defining stakeholder needs is an important project planning exercise. Since scope changes and their related issues are the number one cause of project failure, the scope needs to be well defined. And if your stakeholders needs are not identified very well, or the stakeholders themselves are not all identified, the project is doomed from the get go.
A requirements management plan can be contained within an overall project management plan. As a minimum, it needs to contain a simple listing of all the requirements of the project.
Watch out for the Hidden Requirements
Now, if you’re thinking that your project doesn’t really have any requirements except its core product, I want to stop you immediately. Every project has secondary requirements. For example, if I develop my basement, there are requirements to obtain building permits, ensure noise levels are adequate, avoid damage to the lawn or walls when moving supplies, and complete the project before Uncle Bill needs to move in because the social assistance cheques ran out.
If I can think of those things off the top of my head for this, the simplest of projects, surely your project has some secondary requirements you’re not allowing for.
Stakeholders = Requirements
In a complete project management plan, a stakeholder register will identify each stakeholder in the project. Each stakeholder will have one, or more, requirements. If they had no requirements, they wouldn’t be a stakeholder.
Who are the stakeholders in your project? What requirements do they have?
Do I need a Requirements Management Plan?
For small projects a listing of the requirements is adequate. For larger projects, say anything above roughly 1,000 man-hours of labor, a more complex requirements management plan might be worth the effort.
The goal is to define the scope. If you undershoot the scope, your client or boss will have to pay for the extra. If you overshoot it, somebody paid too much. Either way, the project manager is at fault for lack of planning so the trick is to get it right at the project planning stage. That’s what the requirements management plan is all about.
What’s in a Requirements Management Plan?
A good requirements management plan can contain the following sections:
- Identification
- Analysis
- Prioritization
- Management & Control
Identification
This is where the requirements are identified. I don’t have any special advice to make sure you have them all. Just expert opinion, the more the better. Brainstorming, affinity diagrams, and swot analysis may help, but you just have to make sure all the project requirements are identified.
If your project is to create a cell phone app, this is a fantastic exercise. I’ve seen, and invested in, developers who fly by the seat of their pants, and the end result is disjointed and lacking functionality that seems obvious after the fact but isn’t at the outset. A simple listing of requirements keeps things focused.
If you miss anything, the project scope will need to be changed during the project. We all know this never happens (ha!) but sarcasm aside, you need to avoid scope changes if you can.
Analysis
Each requirement should be analyzed for its root cause. For example, let’s say, hypothetically speaking, that an angry landowner thinks that a new development on his land will impact the drainage on his land that is left. This, of course, is an extremely rare occurrence and was picked for its hypothetical nature. The requirement at the outset could have been identified as “avoid drainage impacts on surrounding land.” It could also have been “Ensure strong communication with surrounding landowners.”
Maybe it should be assumed that some project stakeholders are the type of people who love to stir the pot, don’t work well with anyone, and are attracted to conflict like flies on dung. On second thought, nope, never.
Prioritization
The prioritization section attempts to differentiate between the requirements.
For the Burj Dubai project, designing the tallest skyscraper in the world was important; Money was a little lower on the priority scale.
Sometimes a certain number of features need to be developed. If the budget is running low, which one is to suffer? What about if the schedule is not being met and something must be cut out. Establishing these things in a project management plan before the problem develops is the best way to remain firmly in control and ensure the right decisions are made.
Management and Control
Now here’s the kicker. No matter how well you identify the requirements at the outset of a project, they are likely to change and need to be managed and controlled. Writing a fantastic project management plan does not itself make you a great project manager, just like drawing a good map doesn’t get you to your destination.
The requirements traceability matrix is the project manager’s tool for keeping track of requirements throughout the project. It can be a simple table, spreadsheet or otherwise, and should be revisited weekly, daily, or whatever is deemed necessary by the size and complexity of the project.
Requirements Management Plan Template
Introducing the incredible, stunning, all new, requirements management plan template! …Okay fine, but we’ve got even more explanations and checklists. Together with this post you won’t need anything else. It’s available as a free download in [download id=”2230″] or [download id=”2235″] format.
If it stops you from coming to blows with out-of-control project stakeholders even once in your career, it’s worth the effort.
How do you keep track of project requirements? Let us know in the comments. I’d love to hear your experiences.
