I’ve often said that requirements are the lifeblood of the project and it’s fairly easy to understand why I feel that way. Good requirements help the project get started on the right foot. They make it easier for the project manager to manage scope, manage the project timeline, manage the project budget, and provide a meaningful and useful end solution to the customer.
On the flip side, bad requirements mean rework, budget overruns, project delays, a potentially disastrous end solution and almost certainly a very dissatisfied customer when the project is winding down.
Therefore, the process of defining requirements – assuming that your customer hasn’t come to you with 100% complete and detailed requirements (which is never the case) – is extremely critical to your project’s success. Let’s look at one scenario of how to conduct a productive requirements meeting…
The meeting
Once the meeting has begun, review the project charter with the group. Ask for questions and clarify any concerns up front. Make certain, to the best of your ability, that everyone has the same understanding of the goals of the project.
Next, examine the deliverables (if they were defined prior to this meeting). Provide everyone a printed copy of the list you've compiled so far. If deliverables were not identified prior to this meeting, this is your starting point. Ask the participants to name the major deliverables for the project (or identify missing deliverables from the current list) and start writing them down. This is a simple brainstorming session where everyone is encouraged to participate and say anything that comes to mind.
You can use several other techniques, in addition to or in place of brainstorming, to get the requirements process rolling. (These techniques are applicable to determining the major deliverables as well.) One technique is to send surveys to the key stakeholders prior to the meeting, asking them to list their requirements. Or you could use an interview process if there are only a few key stakeholders involved. Yet another technique is the sticky note process. Everyone in the room is supplied with a sticky notepad and a marker. Ask the participants to place one, and only one, requirement or deliverable per sticky note, being as precise as they can. You'll act as facilitator and gather the sticky notes, placing them on the white board as they're turned in. Eventually, a pattern will emerge, and you can group similar requirements together, eliminate duplicates, and so on. Tell the stakeholders to not hold back anything. They should list everything they could ever want or dream regarding this project at this stage.
Requirements are the lowest common denominator and cannot be broken down further. When you're defining requirements, make certain to take into account business rules and policies. A business rule is something that must occur in a specific fashion or is a result of a policy or regulation. As an example, a business rule for a financial institution might state that all loan requests over a specific amount must be approved by a vice president.
Here's where the lines begin to blur between deliverables and requirements. Deliverables may already be broken down to the lowest level, in which case you could consider them either deliverables or requirements. Don't get too hung up on deliverables versus requirements. The main point is that you document what needs to be done in order for the project to be successful. Remember that deliverables are the specific items or services that must be produced in order to consider the project successful, and requirements are the specifications of the deliverables or project goals.
As long as you've diligently tried to uncover all the deliverables and requirements and then recorded them, you're well on your way to creating better project planning documents. Document the deliverables and requirements whether the project is going to take two days or two years to complete. It eliminates misunderstandings and saves your neck when the stakeholder comes back and says, "That's not what I wanted."