Why SMART Objectives Could Just Be Called Metrics

I hope you've heard of a SMART objective.  My favorite expansion of the acronym is

  • Specific
  • Measurable
  • Achievable
  • Relevant
  • Timed.

SMART objectives can and should be found in lots of places - action items in meeting minutes, project plans, strategic plans, employee performance reviews, etc, etc.

But I think you could ignore S, A, R and T if you could only get M - Measurable - right.  Then we could just call it a Metric.  Let's take a project / service delivery example - getting a new data centre up to speed.

Sure, Specific, Achievable, Relevant and Timed sound like very good things.  Maybe you should start there?  But Measuring your success is the absolute devil.  Ohh, you might think you're Specific until you try to get two people to agree on what number to assign to it.  Then you'll find out the two people likely don't mean specifically the same Specific.


When is your data centre working?  100% servers online?  What does "online" mean?  50% servers at greater than 50% CPU load?  What if the users aren't working the system?  97% of servers ping inside 100ms for 90% of business hours?  By the time you can agree on some kind of number, you'll get Specific for free.

Measurable and Achievable

As your two protagonists try to hammer out the details and agree Specifically on what you're really Measuring, the one who is responsible for delivering it will immediately start to review whether or not they'll be able to measure up - is this new number going to be Achievable?  "99.9999% available, 24x365 per server?  That gives me 5 minutes per server per year - I can't change a password in that much time!"  And that person will almost certainly try to guide the definition and measurement into an area that they feel can be Achieved.  "How about 99.9999% available, 9am-3pm business days averaged across all 100 servers?"  So you get Achievable when you try to get Measurable, as long as you include the deliverer in the conversation.


You're almost certainly undertaking the exercise in order to make some kind of improvement.  Once your deliverer feels you're into Achievable territory, then they'll bid for the resources to make the desired improvements.  "We're at 99.5% now.  I'll need 2 more staff to provide that level of service, plus we need to upgrade to Gold on our vendor support package."  Then the requestor will start totting up the cost/benefit.  "You're asking for another $500k in our budget!"  And now the question of Relevant gets drawn in.  Is this cost/benefit right for the organization -  does it contribute to the stated goals - can it get funded?  And the target number will get negotiated until the right level of Relevancy is found.  "Could you do 99.9% with just the Gold upgrade?"


The deliverer will know the improvement work will require some duration and can't happen instantly, even with the resources provided.  "Sure, 99.9%, once we've run through the initial patch cycle.  Say February."  And there you have it, you've got yourself a SMART objective just by trying jointly to figure out what you're going to Measure.  "99.9% availability averaged across 100 servers in 9am-3pm business days, from 1 Feb."

So start with your Metrics.  But woe betide you, if you try leaving ‘M’ for last, SMARTy-pants...