How to Set SMART Goals (The Right Way)

How to Set SMART Goals (The Right Way)

“I know what is expected of me at work”. According to the Gallup organization, the extent to which an employee agrees with this statement is a primary predictor of that employee’s engagement (or lack thereof).

Take a look at your organization. Does each employee know what they need to achieve on a daily, weekly or monthly basis that clearly signifies to them, “I am doing a good job”?

It stands to reason that if we want to fully engage our employees, we must give them clear expectations of what “a good job” looks like.

SMART Acronym.

I like the SMART Goals acronym for describing how to structure Goals and Tasks, but there are literally dozens of versions of this acronym. One researcher examined 40 websites that used the acronym SMART to define the criteria for goals. When he looked at all the words they used for the different letters, he calculated that it was possible to form almost 9,000 versions of the SMART acronym.

The version I use has worked for me and the companies I’ve worked with. It should work for you, too. In my SMART acronym, the letters stand for Specific, Measurable, Achievable, Relevant, and Time-bound.

Here’s more about what each letter means:

Specific

State your Goal or Task in a way that makes it obvious what needs to be done. Anyone in your organization should be able to read what is written, and say, “I understand exactly what needs to be achieved here.”

Metrics (Key Performance Indicators) are numbers that track our actual performance vs. a target level of performance. When you use the traffic light to color-code your metrics, you set the target “green” threshold for performance as an obvious numerical value that needs to be achieved.

For Strategic Projects (Big Rocks), negotiate which Tasks are “in scope” and which are “not in scope” so everyone on the Project team knows and agrees on the specific components that will be completed to achieve the agreed milestone by the due date. There must be no ambiguity about the finish line (or progress milestone).

For individual Tasks, the action item must be stated as a clear and specific instruction of the work to be done. My rule of thumb is that if the Task were seen in isolation from the Metric or Project it is associated with, it should be clearly obvious to every person from the Task wording, what needs to be done, by whom, and by when.

Don’t combine Tasks: e.g. “Provide 2 training sessions on new sales process”. Better to create these as 2 separate Tasks and check each one as complete when it gets done.

Don’t be vague: e.g. “Work on the new website landing page”. Be specific about exactly what landing page you will complete on the new website, by what date. Tasks should be binary, in that they can only be answered yes or no. It should be clear to everyone whether or not the task was completed by the due date. 

e.g. “Create the website landing page for the software demo offer – by (date)”

Don’t be generic: e.g. “Make some sales”. The Task must be an action that is within the control of the Task owner, and clearly state what they will do, by when.

e.g. “Finish SpaceX proposal and courier it to them – by (date)”

Measurable

It should be obvious when you achieve the desired outcome. This is how you know when it’s time to praise and acknowledge your people for their achievements.

Each of your Metrics, Projects, and Tasks should pass what I call the “Champagne test.” They should be so clearly stated that everyone knows the precise moment when the outcome has been achieved, and thus when it is time to pop the cork and celebrate.

Achievable

When setting due dates for Projects or Tasks, I recommend a conservative due date. Most people fall victim to the “Planning Fallacy“. Choose a due date that the person is willing to be held firmly accountable for. Yes, we “hope” to get it done sooner, but the due date in your software dashboard is a “commit”; a promise that everyone is counting on.

Let’s face it, “stuff” happens. Nothing goes exactly as planned. There are always unforeseen delays, disruptions, and scheduling issues. As a manager, it is better to negotiate with your team members and agree on a completion date you can count on vs. a date that someone is not fully committed to. Otherwise, we are all deluding ourselves and setting ourselves up for failure.

When it comes to Metrics (KPI), most managers tend to set the green performance thresholds too high, thinking that setting stretch metrics will motivate their people, but it tends to have the opposite effect. When your “good people” can’t achieve the target level of performance with a reasonable amount of effort, they quickly become discouraged and demotivated. Their failure is staring at them on the software dashboard every day.

You cannot shame your people to higher performance. Shame is not a motivator. A dashboard full of Metrics that are colored red will demotivate your good people.

Research on employee motivation has shown that employees are strongly motivated by seeing progress, so it helps when you make progress visible on their dashboard, and praise people for their “small wins” every step of the way.

As a manager, you want your “good people” going home at the end of the week with a smile on their faces, knowing that, “I had a good week”, rather than feeling like a failure with their Metrics “in the red”.

For setting Metrics targets, my rule of thumb is:

“A good person, doing a good job, should achieve the green level of performance 90% of the time”.

In essence, a competent person, with the right tools and training, doing an honest week’s work (i.e. they are not a slacker), should achieve the “green” performance standard 9 times out of 10 ( i.e. 9 days out of 10 for daily metrics, or 9 weeks out of 10 for weekly metrics).

If not, the green performance threshold is too high. 

The same principle applies to any Projects or Tasks we assign to people. Assuming the person has the appropriate training, support, decision-making authority, and resources to do the job, due dates should be realistically achievable, and not just based on an optimistic best-case scenario.

Relevant

This is the part of the SMART acronym I see most people get wrong, and it is probably the most important. Many people say that “R stands for Realistic,” but, to me, that means exactly the same thing as Achievable. Relevance is what we are looking for here.

  • Is the Metric relevant to the critical success factors that drive your business model?
  • Is the Metric performance target relevant to the current market reality?
  • Is the Project relevant to your company strategy?
  • Is the Task relevant to one of your Metrics or Projects?

Time-bound

The difference between a dream and a Goal is that a Goal has a deadline.

Metrics are automatically time-bound in that the current score is compared to the target threshold for “green” performance for the given time period.

Projects and Tasks have a due date by which they must be completed. More than “a hope”, the due dates should be a conservative date that factors in time for unforeseen delays and distractions. It needs to be a due date that everyone in the team can count on. The Project/Task owner must be willing to be held firmly accountable for getting it completed before the due date.

Set yourself and your team up for success.

Don’t let your employees feel pressured into slavishly agreeing with unrealistic Metrics targets or Project/Task deadlines just to please their manager. You are only postponing the inevitable disappointment for everyone down the track, and likely to disengage your people.

It takes courage for an employee to speak up and negotiate their Goals and Tasks with their manager, so as a manager, you need to make it safe for them to do so.

The aim is for everyone to be smart about it, and set SMART Goals that everyone clearly understands, is happy with, and fully committed to achieving.

This article contains excerpts from the book: Business Execution for RESULTS, by Stephen Lynch

***

Until next time…
Stephen