In my opinion, requirements are the most under-rated aspect of most projects. In an unbelievable number of corporate projects they are completely non-existent and in the vast majority they are really no more than a paragraph or two of high-level requests which are unlikely to be delivered on successfully. In a very few of the countless projects I have worked on I have seen adequate, or an attempt at adequate, requirements. These projects, without fail, are the most successful projects that I have seen.
Why the passion, you ask? Without clear, complete and agreed upon requirements there is almost zero-chance, yes zero, that the project will be delivered successfully. And when I say successfully, I mean on-time, on-budget and matching the desired scope. Sure, most projects will get delivered without good requirements but you will see project delays (possibly numerous), budget overruns, and final scope that doesn’t satisfy the customer. Many people believe this is the way projects should progress or at the very least consider it a natural course for projects to take. This is not the case. Starting with adequate and thoughtful requirements can eliminate, or at the very least, significantly reduce, the amount of issues and re-work that are required in a project. So let’s start with the basics of requirements.
Requirements Analysis and Management is a discipline in and of itself. But there are some basic rules that any project manager should know to recognize good requirements, and frankly, many projects aren’t afforded a skilled requirements writer to complete this step and the responsibility is left to the project manager. In this article, I will cover what a requirement is and the basics for writing or determining if a requirement is sound.
A requirement is nothing more than an expected outcome of the project. Requirements are generally defined by the customer in conjunction with the project team. If you think about it, many things we engage in at work and in our lives have requirements. At work you might ask a subordinate to update an existing report with the market data from the previous week. In reality, you have just supplied a set of requirements.
It makes some assumptions that you have previously clarified which report to update, where the market data comes from and the definition of previous week. It has probably even happened that the subordinate made a mistake and you realized, “Oh, you should have updated the ABC report, not the XYZ report.” Here, you failed to provide detailed enough requirements and now there is re-work. This is a small case, but it has happened to all of us, and on a big project you can begin to see what kind of impact that would have.
So what makes a good requirement? There is a commonly used acronym (SMART) that is used to remember and guide requirements development. I will review that and provide both good and bad examples of requirements. There are additional attributes that should be considered, but understanding SMART requirements is a good place to start.
SMART Requirements (alternate namings in parenthesis):
- Attainable (Achievable, Actionable, Appropriate)
- Time-bound (Timely, Traceable)
We will discuss each requirement individually in the next articles in this series.
Jessica Popp is a practicing project manager in software engineering. She has more than 13 years experience in software development, project management and people leadership in both Fortune 500 and startup companies. She has a wealth of hands-on project experience from the smallest project to projects whose budgets exceeded $50M per year. Jessica holds a BBS in Information Systems, an MS in Decision Sciences and has a current PMP certification. Jessica runs Project Management 101, a blog dedicated to disccussing various topics about Project Management.