Requirements are the lifeblood of projects. That’s one of my mottos anyway. If you don’t have a list of what needs to be completed, how do you know what to accomplish, or even when the project is actually finished? This is why requirements are critical to a project’s successful outcome. A project that is started without good, complete requirements in place is definitely in trouble from the beginning.
You’ll need several basic things to get started:
- You need to start the project with funding secured, of course.
- A good mission statement.
- A Statement of Work (SOW) with high-level requirements, milestones, assumptions and key dates in place.
- A project schedule or Gantt Chart.**
**To create your schedule, you’ll need a solid Project Management scheduling tool such as FastTrack Schedule (which excels at Gantt Charts and works on Windows and Macintosh machines) to begin building the plan that you, your team, and the project customer can use to effectively kickoff the project.
Once the high-level requirements are captured and the basic plan is put into place, low-level requirements are the next thing you need to tackle and they must be captured in as much detail as possible so that the project manager and the delivery team can go off and build an accurate and usable solution for the project customer. If the team doesn’t start off with explicit requirements, you may never reach a successful end solution. And you almost certainly will never get there on time, on budget, and with much degree of customer satisfaction … no matter who’s fault it is that the requirements are bad or incomplete.
Poor requirements mean you end up performing re-work. Or you develop a solution that doesn’t work for your project client. It’s a painful lesson to learn, but if the requirements aren’t good or complete, then it’s best to put the project on hold till you fully define the requirements rather than kick off the development of a solution with an ill-defined path on how to get there. There’s no question that the quality of your requirements can make or break your project.
What goes into good requirements?
So, what are the characteristics of a good requirement? In the project management world, it is generally accepted that four certain criteria need to be met in order for requirements for a given project to be considered good, usable requirements. These are:
Good requirements are clear and understandable.
When developing your requirements, try to leave no room for interpretation. If there is room, then the requirement is not detailed enough or needs to be broken down further. A good requirement cannot be misunderstood. It expresses a single thought and does not imply anything or leave major room for assumptions. It is concise and simple. The more straightforward and plainly worded, the better. Use short, simple sentences with consistent terminology for requirements. Too many words and too many references breed inconsistency and confusion.
State your requirements positively whenever possible.
It is easier to develop and test a product that does something specific than one that does not do something specific. Proving the positive when testing a requirement is much more straightforward than trying to prove the negative.**
**Tip: Grammatically correct requirements really help with interpreting their exact meaning. You may find it beneficial to include a Technical Writer in this process.
Good requirements are verifiable.
A requirement must state something that can be verified by inspection, analysis, test, or demonstration. As you review a requirement, think about how you will prove that the product meets it. How will you test that the end solution is delivering what the requirement is stating as a need? Determine the specific criteria for product acceptance, which will ensure verifiable requirements.
Good requirements meet specific needs.
In simple terms, a requirement is a basically a statement of something someone needs. The something is a product or solution that performs a service or function. That someone may be an end user, the customer, a tester, or some third party. And don’t forget – the project team needs to be able to distinguish between needs and wants. Even if it is verifiable, attainable and well stated, a requirement that is not necessary is not a good requirement. Putting down wants as needs can add unnecessary expense and restrictions towards developing and building a solution.
Good requirements are attainable.
Make sure that the requirement is something that can be achieved. It must be within the budget and schedule and be technically feasible. Don’t write requirements for things that cannot be built or that are not reasonably within the project budget constraints that you and your team have been given. If there are questions on technical feasibility, be sure to reach out to the right technical resources to get those questions answered as you’re trying to nail down good requirements.
Summary / Call for Input
Without complex, well-documented, verifiable and meaningful requirements… success on most projects is just not going to happen. They are the basis – on a technical project, for example – for design, testing, user acceptance testing, and solution sign off… as well as the baseline for all change control processes.
Readers – what’s your takeaway? Do you agree with this – what would you add? And what requirements pain points have you experienced? Please share and discuss.
