It never fails.  In the early stage of any project management initiative; the team starts by articulating the goals and objectives they are trying to achieve and someone will remind us all that we need to make sure our goals are SMART.    Then a lucky person (often the project manager) gets tagged with defining the project on paper and is left to his/her own devices to determine how to do that.  They often end up getting lost in determining how to make a goal measurable or specific.  The goals end up being complex and wordy.  (Its about this time that the rest of the project team seems to conveniently disappear).



SMART goals of course refers to goals which are supposed to be Specific, Measurable, Attainable, Realistic, and have a Time Frame.

SMART goals are fine for defining individual performance goals (employee evaluations) because you cannot and should not be overly verbose.  "You must increase your performance by 10 widgets per day within 90 days".

They also fit for most personal improvement endeavors - "I am going to eat less potato chips and walk 30 minutes each day and I plan to loose 15 pounds by July 4th."

They even apply to OK to small projects that don't warrant a full investment in detail.

But, for most efforts we take on which involve larger teams, have a significant cost, represent a large opportunity and carry a typical degree of risk, - the use of SMART goals is too simplified.  It takes more than a few goal statements to be smart because you cannot articulate the desired results in just a few sentences.

You must determine what goal setting approach works for your company and your projects; but my preference is to use a top down approach working through Goals, Objectives, Critical Success Factors and Measurements.

• Goal statements should be broad and clearly attached to core business reason you are doing doing this project/initiative in the first place.


• To these you then add Objectives, which may be easier to refer to as benefits.  An objective or benefit will usually be able to connect back to one of your goals.  If not, maybe you missed a goal?


• From here, list out the Critical Success Factors (CSF) which will let you know when you actually achieved the objective or benefit.  Again, if you can't tie the CSF to a benefit, maybe you need to add another benefit to your list.


• Finally, spend some time thinking of a few ways to you can quantify the results in the form of a measurement.  Sometimes this is easy because the CSF are simple.   Oftentimes though these is where the hard work comes in.  You need to make sure that you capture the details here to make the result measurable, which will require a before and after comparison.  Think in terms of percentages, dollars, quantities, rates, etc.   Make sure you include a realistic time frame as well.

Lastly, review your list.  If you took the time to work from the top down, you should be able to focus on your success factors and the metrics to see if they articulate the results you project is supposed to deliver.  You may find some are just not worth the effort to actually measure due to lack of historical information, an unreasonable burden to actually collect the metric, etc.  The focus should be on working to capture those which are most important and which the team can agree to track and measure.  If you can look at that list and your company execs or project sponsors would say "yep, if this project does that, then I'm happy" - you know you've got a good list.

No, it isn't a fool proof program and there are not simple solutions which can apply in every scenario.  In the IT projects I work in, every situation is different and the process must be adjusted; but this seems to work as a nice guide and might give you a sense of direction - which you may need when you're left alone because your team has abandoned you while you set off to define a smart goal.