Wednesday, September 30, 2009

SMART goals

I was just reviewing the written goals for a project I've started working on and after looking at a few of them, I was reminded of how important it is to make sure your goals are "SMART".

For example, one of the project goals is: To create a standard framework that supports high levels of service. Hmmm... When I read that goal, I found myself thinking of the concept of SMART goals that I learned a long time ago. Somehow this goal doesn't seem to fit the SMART paradigm.

So, what is a SMART goal?

SMART is just a mnemonic that can help you remember how to effectively formulate a goal. Here's a brief description:
Specific - The What, Why, and How.
What are you going to do? What do you want to accomplish?
Why is it important (reasons, purpose, benefits)?
How will you accomplish the goal?

Measurable - Concrete criteria for measuring progress.
If you can measure properly, you can see change occur as you progress toward the goal. Ask questions like "how much?" or "how many?".

Attainable - Takes enough effort to be a bit of a stretch, but not so far out of reach that is nearly impossible to complete.

Relevant - "Do-able"...not "easy". The skills are available, the learning curve is not vertical and the goal is within bounds of the overall plan.

Time-Bound - A clear target date or time period to work towards. Without the time element, the commitment to begin action is often too vague.

I think the project goals I've been reviewing have most of the details that would cover the SMART elements elsewhere in the project docs, but I'm glad for the opportunity to review this method for stating goals.


Chen Shapira said...

SMART is a good method, but sometimes I feel that it leads me too much in the direction of safe and somewhat boring goals. Especially the part about "Attainable".

Some projects should have goals that are exciting and inspiring and fun :)

John Brady said...

I agree with the SMART thing for goals, as it helps me define them in terms that make it clear what needs to be achieved. The only part I often have a problem with is the 'R'. I have seen it stand for Resources and Results too. Check out What is a SMART Objective> which lists 'R' as Results-focused.

Personally I have always taken 'R' to mean 'Resources'. Do I have everything I need to be able to achieve the goal? Or is there an outside dependence on something else, which can stop me / us achieving the goal?

I also differentiate between 'goals' as things which are essential and must be achieved, and the other things which we would really like but are not actually essential. I don't have a single term for these other things, but they include things like 'stretch-goals', a 'wish list' and a 'vision' of where we would like to be in the long term. You would like to achieve those things too, but the difference is that they are not essential for one reason or another.

Database Performance Blog

Karen said...


To your point, I agree and think that is the biggest challenge in defining a SMART goal. You can set goals that are safe and boring but you can also set goals that are exciting, inspiring and fun. I certainly prefer the latter! But, I don't think it's the method that is to blame.

I think the Attainable element is intended to help with keeping your goals in the realm of possibility. I mean, you could have a goal to get a 1 microsecond response time for a transaction. But, if the application user is in China and the database server is in New York, that is likely not attainable.

Where I end up is that if you set a goal for something you know you can achieve without any stretch, it's not really a's a task. A goal, to me, is something that you aspire to make happen (with hard work and a bit of fun too!) and must really work to obtain. John mentioned how he differentiates between goals and other things, and I think that makes a difference in how you view and approach SMART goal setting.


I agree with 'R' being a problem child in the mnemonic. I like the idea of using Resources for the 'R'. Using Relevant has always seemed too close to Attainable to me so using Resources is a great alternative.

Joel Garry said...

This would upset me quarterly if I cared about unrealistic management as much as I care about my work.

The problem arises when there is little congruency between project/goal oriented management and the reality of wearing too many hats. You can say "this project must be completed by such-and-such," that makes perfect sense. But how do you make a goal when it involves responding to soft issues outside your control?

This week I pounded on an issue that turned out to be a bad decision involving reuse of a column named quite different than it's normal use, a "do this because I said so" type of decision some long-gone person told a long-gone programmer a decade ago. The problem reported by the user was a bad GL code in a system far away, but only under certain newly encountered circumstances. I certainly don't even want to have goal of dealing with such a thing, but someone's gotta deal with it.

The other thing I pounded on this week was a performance issue related to bad programming of a db-blind system that only shows up under one version of the generator and above a certain data volume.

So, how do I make a SMART goal out of these things? I've avoided the problem by only explicating defined projects, but is that an answer, or an indictment of the limitations of SMART? Fortunately my boss understands, his range of technical work is much broader even, but I really would rather have a managerial reporting system that reflects reality.

word: fiesce
word: subli