gathering project requirements
Not getting good project requirements can destroy your project

I have a few things that I say over and over again and one of them is this… “Requirements are the lifeblood of the project.” Start a project that is poorly defined and lacks a good foundation of solid, detailed requirements and you’re likely going to end up with one or more of the following:

An end solution that misses the mark

  • Excessive re-work trying to ‘get it right’
  • A budget that is frequently out of control
  • A project timeline that is constantly off schedule
  • A very frustrated customer – even if they are partly or mostly to blame

I know there is often excessive pressure from above or from the customer to ‘get started’ and ‘show some progress.’ When a project starts out of the gate with what appears to be excessive planning, people start to ask questions, the money people get frustrated, and someone important somewhere begins to lose confidence in your ability to succeed and deliver.

What the project manager needs to do is keep his team and the customer focused on clearly defining the goals of the project and mapping out good, detailed, understandable requirements that can be used to scope out the project and create an end solution that will provide what the customer truly wants and needs. Without those in place, you simply aren’t ready to proceed and it would be foolish to do so no matter who is pushing or complaining.

So, what are good, detailed requirements? What do good requirements even look like? What information do you need to create a solution from? There’s no question that the quality of your requirements can make or break your project so this is an important question to answer. Why? Because good requirements give you control over your project development and prevent rework. They make your efforts meaningful and keep the project moving forward. In general, a good requirement meets four basic criteria…

#1 – A good requirement meets a specific need

A requirement is a basically a statement of something someone needs. That something is a product or solution that performs a service or function. That someone may be a company, a user, a customer, support, testers, or another project or product.

When establishing good requirements, you will need to make a distinction between wants and needs. Even if it is verifiable, attainable and well stated, a requirement that is not necessary for the end solution is really not a good requirement. Of course, the definition of need will depend on the context or circumstances and that will need to be fleshed out by the team and the customer.

#2 – A good requirement is verifiable

A requirement must state something that can be verified by quantification, inspection, analysis, or testing. As you review a requirement, think about how you will prove that the project meets it or how it will be verifiable. Determine the specific criteria for acceptance, which will ensure verifiable requirements.

#3 – A good requirement is attainable

The good, detailed requirement is attainable. It must be within the budget and schedule and be technically feasible. It’s important not to write requirements – or let the customer slip in requirements – for things that cannot be built or that are not reasonably within the project budget. Keep in mind that this is not always easy to determine or you may not have the expertise to judge whether a requirement is technically feasible. If that is the case, make sure you include members of the development team in the review process to foresee technical problems. You may need to conduct research to determine a requirement’s feasibility before it is added to the project baseline.

#4 – A good requirement is understandable to everyone involved

A good requirement is understandable by all involved in the project. It expresses a single thought – it is concise and to the point. It is written in short, simple sentences with consistent terminology – and be sure to do this consistently for all requirements across the project. Use common names across requirements for different areas or segments of the solution so that you are using a common language that makes sense to everyone. That way, as you progress into the design and development phases, everyone will still be making sense to each other when questions and discussions arise over different areas of the solution as they inevitably – and constantly – will.

One more thing to keep in mind….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. It is extremely difficult, if not impossible, to test that something does not happen. This type of testing is expensive, time consuming and can break a project’s budget.

Get a demo to see how to manage your requirements with a project charter.