Guest Post: Gathering Good Requirements
IT/Project Management consultant and author Brad Egeland explains what makes a project requirement a 'good' requirement...and the consequences of not having them for your next project:
Requirements are critical to a successful project. In fact, in my opinion, they are the lifeblood of any project. A project that is started without good, complete requirements in place is definitely in trouble from the beginning.
You need to start the project with funding secured, of course. And you need to have a good mission statement and a statement of work with some high-level requirements, milestones, assumptions and key dates in place. Those are the items that you’ll use to begin building your initial project schedule or Gantt chart – and you can use a tool like Smartsheet to start building that initial schedule in a very collaborative and straightforward fashion for you, your team, and the project customer to help kickoff the project.
Image 1: With Smartsheet, you can manage all aspects of your project, including sharing files, automating workflows, and viewing tasks with dependencies in a Gantt chart.
But requirements are the next thing you 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 good requirements, you may never get to that 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.
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. And finally, make your requirements grammatically correct. Good grammar is essential for understanding.
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.
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.
Brad Egeland is an IT/Project Management consultant and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT.pre-built template for gathering requirements to help users hit the ground running.