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)
Specific: a good requirement is specific and not generic. It should not be open to mis-interpretation when read by others. This is the most important attribute to get correct. Avoid using conjunctions (and, or, but) as they can confuse or misconstrue the meaning. Avoid indeterminate amounts of time (soon, fast, later, immediately) as they are open to wide mis-interpretation which results in dissatisfied customers.
Weak Requirement: The report should display all the monthly data from the marketing department
Why it is weak: Anytime you see all, always, never and other global adjectives, beware. What if the marketing dept adds more data; do you need to immediately update the report? What if “all the data” that you are aware of from marketing is different than what your customer (the report requester) perceives as “all the data”? Even if you and the customer agree, what about a third reader?
Strong Requirement: The report shall contain the following columns: Total Sales for Month, Average Retail Price, Total Units Sold, Remaining Inventory, Total Cost of Goods Sold.
It is appropriate and expected to list every column – it might be 100 of them, but list every one exactly. There should also be a subsequent requirement that lists what the column headers should be as well.
Measurable: this answers whether you will be able to verify the completion of the project. You should avoid signing up for any requirement that cannot be verified as complete. These are especially risky when you use non-quantitative terms (best, optimal, fastest) for acceptance criteria.
Weak Requirement: The system shall have an optimal response time for the end-user.
Why is it weak? There is no way you can be successful with this requirement once the new system goes into production. It’s similar to being specific, in that optimal is not defined and really cannot be defined.
Strong Requirement: The system shall have user response times on user click-events that are 5-seconds or less during business hours of 9AM-5PM, Mountain Time, Monday-Friday.
Now this requirement can be measured once the system is in production. In the first example, you might end up in a never ending loop with the customer after the system is in production trying to define “optimal.”
Attainable: also referred to as achievable, actionable, or appropriate. All are fine attributes and are intended to ensure that the requirement is physically able to be achieved given existing circumstances. There is arguably overlap between attainable and realistic. I generally reserve attainable to check the likelihood that I will be able to achieve the requirement including whether the requirement is too grandiose (which is the overlap with the term realistic).
Weak Requirement: The monthly marketing sales report and the monthly financial statements shall both be delivered on the 1st business day of the month.
Why is this weak? This may not be obvious initially and may be realized only after analysis is done. In this case it becomes un-attainable when the project manager learns that the sales report takes 28 hours to run, so it becomes physically impossible to deliver these reports both on the same day with the current systems that are available.
Strong Requirement: The monthly marketing sales report will be delivered on the 1st business day of the month. The monthly financial statements will be delivered on the 3rd business day of the month.
Note: The resulting strong requirement was broken into two requirements. As mentioned before, avoid using and as it can create ambiguity. Here it would arguably have been ok, but just avoid it as good practice.
Weak Requirement: The resulting web site shall be so popular that it gets 1,000,000 hits within the first week.
Why is this weak? This falls under the grandiose category (or in some minds, realistic) and is possibly more of a wish of the customer. Just because both parties know it’s not achievable does not make it ok to write it down. Work with the customer to re-write something quantitative that still captures the essence of their goal.
Strong Requirement: The resulting web site, when reviewed by XYZ site-rating agency, will receive at least a 3 out 5 five rating in the category of “Fun websites to visit.”
Realistic: answers whether the requirement is realistic to deliver when considering other constraints of the project and requirements. I personally reserve this category not to check for the grandiosity or the sometimes ridiculous requirement (see attainable), but instead look to answer whether the requirements and other project constraints in their entirety are able to be met.
Weak Requirement: The marketing sales report will be delivered into production on or before November 1, 2008.
Why is this weak? At first glance, this is a good requirement. The specificity of the date is good. The problem here is after the PM analyzes the amount of work to be done and the resources that are available to work on it, he realizes that the date is not possible to meet. This can be addressed in several ways: adjust the date, rephrase as hours to complete work, add additional resources to complete the work. Once you determine the best way to address the situation for the particular environment, re-write the requirement as required. If additional resources are negotiated, the requirement may not change. The important point here is to not “sign-off” on the completed requirements until you verify that you can complete them.
Time-bound (timely, traceable): where appropriate each requirement should be time-bound or specify by when or how fast a requirement needs to be completed or executed. In software engineering, you may see the “T” in SMART being used to mark whether a requirement is “traceable”, which is my opinion is a separate but important topic in developing software. For this general requirements overview, the focus will be on the time-bound requirement.
Weak Requirement: The report will be available soon after month-end close.
Why is it weak? Who is to say what is “soon”? You cannon rely on what you consider to be reasonable expectations of the customer. You may know the time cycle of month-end close and that it takes the first 5 days of the month to complete. The customer may assume that soon means on the 1st of the month.
Strong Requirement: The report will be available by noon on the first business day after the successful completion of the month-end accounting reports (insert identifying report id).
This clearly explains to the customer when they can expect the report (first business day, not on a weekend) and only after a successful run of the closing monthly reports from accounting.
This summarizes how SMART can be used to review your requirements. Requirements are an important part of setting expectations with your customer. In the absence of facts and details, the customer will make up assumptions in their head. State everything in your requirements. If it is not stated, it is not committed to be completed.
Once you believe you have a completed set of requirements, it is a best-practice to review them with your customers and “sign-off.” This can be done literally on paper, or electronically via email, but is a step that should not be skipped. It enforces that both parties review and completely agree on what work is being done and what is to be delivered. Do not settle for a verbal yes; people forget, change their minds, etc. By going through this formal step it helps your customer understand that you are serious about delivering what they need and to do this on-time (now defined in your requirements) and on-budget (also specified or estimated) you need a clear representation of their needs.