SMART Requirements

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)

  • Specific
  • Measurable
  • Attainable (Achievable, Actionable, Appropriate)
  • Realistic
  • 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.

About these ads

16 Responses to SMART Requirements

  1. AlexM says:

    I found your site on technorati and read a few of your other posts. Keep up the good work. I just added your RSS feed to my Google News Reader. Looking forward to reading more from you down the road!

  2. Longinus says:

    Thank you.

  3. DonnaB says:

    Good practical advise -much appreciated!

  4. This was a Excellent wordpress post, I will save this in my Clipmarks account. Have a good day.

  5. Roel Vossen says:

    Great primer on smart requirements! Thanks

  6. Rakesh Garg says:

    Good !!!!! Clearly described the requirements characteristics

  7. Maximilien LERAT says:

    Very good job !! It is described in very smart way !

  8. kolagen says:

    Thanks for your personal marvelous posting! I truly enjoyed reading
    it, you are a great author. I will be sure to bookmark your blog
    and may come back someday. I want to encourage you
    to ultimately continue your great posts, have
    a nice evening!

  9. oca.re says:

    I have read so many posts concerning the blogger
    lovers but this piece of writing is truly a pleasant piece of writing, keep it up.

  10. bad says:

    There’s certainly a great deal to find out about this topic.
    I really like all the points you’ve made.

  11. Lydia Perry says:

    Thanks . That was very helpful. There is a lot of activity going around in my company about scrum and some teams are having daily stand ups etc. Do you think that like PMP, having a Scrum certification will help me in my career?

    • jessica80304 says:

      Lydia –

      That is a tough question – I think each company environment is unique and what is important in one, may not hold weight in another. I do still values the structure that the PMI has set out and certifies via the PMP. I think it is a great structure for Project Management thinking and the principles are widely applicable.

      Agile Methodologies, including Scrum, are increasingly popular and I do think they work really well in certain situations. My concern is applying them broadly across all project types and whether that is appropriate. I think it is healthy to do an assessment of what key deliverables you need along the way for a project and whether Scrum is a model that works with that. Currently, I am working in a development area that requires significant planning and research for each feature. It’s not a GUI environment that can be broken into logical small chunks and therefore efforts to apply Scrum have had mixed success.

      All that being said, certifications often open the door to new opportunities and are used, right or wrong, as a litmus test, so I try to get them where they make sense. While I don’t practice Scrum a lot with my current teams, I did find the background knowledge I obtained when getting my CSM to add tools to my overall PM toolkit.

      -Jessica

  12. iKurniawan says:

    Thank you for this post, need this as a reference for my assignment :)

  13. Greetings I am so delighted I found your webpage, I really found you by mistake,
    while I was looking on Aol for something else, Regardless I am here now
    and would just like to say many thanks for
    a fantastic post and a all round interesting blog (I also love the theme/design), I
    don’t have time to read it all at the moment but I have
    bookmarked it and also included your RSS feeds, so when I
    have time I will be back to read much more, Please do keep up the
    great work.

  14. Edwin Ritter says:

    Reblogged this on Ritter's Ruminations & Ramblings and commented:
    I’ve been ruminating lately on the interplay of the following : assumptions, requirements and expectations. Being a good listener and taking time to ensure understanding are involved as well. Segue to a a snippet of dialogue from a favorite movie scene :
    Man: “You’d better tell the Captain we’ve got to land as soon as we can. This woman must be taken to a hospital.”
    Woman: “A hospital? What is it?”
    Man: “It’s a big building with doctors and patients, but that’s not important right now.”
    Which reminded me of SMART. A quick search led me to this blog which captures what I agree with on the having clear, defined expectations and the big ‘R’ word, requirements. It should not always fall to the project manager to sort this out of course. Sponsors and customers can be SMART. Wouldn’t that be nice? Which implies process and management styles – I’ll save that for later.
    How often are your projects SMART?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: