ImaginativeThinking.ca


A developers blog

How the Heck do I define SMART Goals?

By: Brad

Hi Brad,
My project manager tells me we need to define goals for our project. Why do we need to define goals for the project and what the heck is a SMART Goal?

Defining good goals are not only important for a project but also for your own career development; you should be setting goals for yourself, weather your company requires you to do so or not. Believe it or not a good goal will keep you motivated and on track.

In my career my employers have always seen the value of goal setting for personal development. As such I’ve been tasked with setting goals for myself per company directive for many years. I struggled with this for the longest time and probably still do today if I’m being completely honest. Creating goals is a hard thing to do. You don’t want to set lofty goals that can’t be achieved or goals that don’t align with the direction you want to take in your career.

Why should I be setting goals for myself or for a project/team?

For starters goals keep you motivated and focused on the task at hand.

Lets look at a project that is using a traditional plan driven project management approach (i.e. Waterfall). At the start of the project all the plans are made and the objective is set. The objective being to deliver a product with the given list of features by such and such date. The project is planed to take 12 months to finish. Now I’ve worked on projects like this and I can tell you that a few weeks into it I start to lose focus, I mean I’ve got ~11 months so what if I’m slipping here or there or decide to take a few days off part way through the project I’ve got plenty of time (I’m reminded of a Micky Mouse cartoon my son likes to watch where one of the character keeps taking detours and slacking off during the rally race as he is faster then all the other participants so he has plenty of time, sort of a tortoise and hare story). Now I’m not really that obtuse, I know the tortoise wins in the end, but I’m human and I can’t help but get demotivated over time. I call this Project Fatigue; that is when your working on a never ending list of tasks with no real sense of accomplishment in the short term. You just keep chasing that carrot and in 12 months you finally catch it and see if it was really worth all that running. The point is that along the way you start to forget why you wanted that carrot in the first place and start to get distracted by that yummy apple to your left.

Now a project managed by Agile principals does work to deal with Project Fatigue by focusing on working software first and for most. So the overall project (i.e. the time that its estimated to take to complete all requested features) may be the same 12 months as the plan driven project however we get to catch that carrot at the end of every interval which helps to keep the team on track; however, without setting a goal for the interval you can start to loose sight of the objective of the project as a whole; Why are you even making this product in the first place?

By having goals that align with the answer to the question why are we even making this product you can keep the team motivated and focused on achieving a high quality product with maximum customer value.

Well defined goals can help against Project Fatigue in planed driven projects and can help keep the focus on maximum customer value for Agile managed projects.

By having interim goals set through out the course of the project you are setting up rally points where the team can celebrate a victory early and often to keep their spirits up and eye on the prize. When I was working on a plan driven project I just sat their typing until my fingers bled for 12 months not knowing if I was succeeding; however, if I had a series of well defined goals set for myself and/or my team that were aligned with the projects objective and the companies goals I would know I was succeeding all through out the 12 month period and better yet I would have known exactly when I was not succeeding and could take measures to get back on track. The same goes for Agile managed projects, a well defined goal for each interval will help me keep the big picture objective in the forefront of my mind. I would know that this interval is adding maximum customer value and contributing to our collective success as an organization because it is achieving a given goal which is inline with the overall project goal which in turn is inline with the organizations primary objective.

Ok I see why I should be defining goals but what makes a good goal?

When defining goals you want to be smart about it, the point of the goal is to help the team rally their spirits and keep them on track and motivated. Defining goals that can’t be achieved or even identified as having been achieved will work against you and actually demotivate you and your team. Equally devastating is to define achievable goals but then forgetting about them by saying you have the full length of the project (i.e. 12 months) to achieve it. Again you will unconsciously fall into that I’ve got plenty of time mentality and push it off until its to late to achieve the goal. What you want to do is define SMART Goals.

SMART Goals

smart

  • S – Specific
  • M – Measurable
  • A – Achievable
  • R – Realistic
  • T – Time-based

Specific
Goals should be as specific as possible. Setting a vague goal like Our goal is to improve the quality of the product is open to interpretation and different members of the team will conclude that the goal has been achieved or not achieved in their own way. This makes the goal unable to be shared and if it can’t be shared it can’t be a rally point for the team.

Measurable
Goals should be measurable; how do you determine that you actually improved the quality of the product? What degree of improvement were you looking for? With the above goal of improving the quality of the product one could say that by adding a single unit test you improved the quality of the code and declare the goal achieved. A goal needs to be measurable so you know when you achieved it. If you leave it up to a feeling (I feel like we improved the quality enough) then the goal does not have the same sort of impact, it doesn’t feel like much of an achievement.

Achievable
Goals need to be achievable! This is the most important part of a SMART Goal, you need to be able to achieve it. I’m not saying that the goals need to be easy and that everyone gets a gold star just for showing up; goals need to be challenging but they also need to be achievable. Setting a goal to have a team update your software to work with a new piece of hardware but not give your team access to that hardware makes the goal un-achievable and will hurt moral.

Realistic
Goals need to be realistic. If your a junior developer, setting a goal to become the CEO before the end of the year is probably unrealistic. The goal won’t be achieved and as such won’t give you any value; The goal is null and void. Similarly setting a goal to get 100% code coverage is also probably unrealistic as there are parts of the code that just doesn’t make any sense to put under test (like initializes which have concrete dependencies). Again this type of goal will set your team up for failure and will reduce you and your teams moral and confidence.

Time-Based
Goals should be time based. A goal without a dead line is a low priority goal, other activities will always come first. Your goal will be pushed off and pushed off until it no longer relates to your current objectives and will simply be scraped. The goal will not give you any value and will become null and void. Setting a dead line to the goal forces you to prioritize it among your other task to make sure it gets done on time.

Example of a SMART Goal:

As a team we want to achieve 25% code coverage of our product’s business logic within 2 months so that we can make more confidant changes to our code in order to speed up our turn around time for bug fixes and new feature request to our end customers. In 4 months we want to have 50% of our business logic under test and in 6 months time we want to achieve 70% code coverage. By the end of the project we want to have a steady 85% code coverage, higher then that is viewed to have little ROI.

The above was an example of a four part goal ( 4 separate SMART Goals grouped together into a single SMART Goal Statement).

Step 1: As a team we want to achieve 25% code coverage of our product’s business logic within 2 months.
Step 2: In 4 months we want to have 50% of our business logic under test
Step 3: in 6 months time we want to achieve 70% code coverage
Step 4: By the end of the project we want to have a steady 85% code coverage

Is step 1 SMART? Yes
Its Specific; What are we doing? Getting the business logic under test.
Its Measurable: We know we’ve achieved the goal when 25% of the business logic is under test.
Its Achievable and Realistic: Assuming that the team will have the tools and resources required and that the organization is in favor of improving the products quality then I don’t see anything unrealistic or un-achievable here.
Its Time-Based: The team has 2 months to achieve this goal.

Similarly steps 2-4 are also SMART defining a metric to determine if the goal was achieved and a time box stating when the goal is required to be completed by.

This type of goal is an excellent rallying point for a team who is dealing with a legacy product which needs to be updated to bring further value to the customer.

Goals need to be Inline with you and your Organizations Objectives

Goals need to resonate with you or no matter how SMART they are you still wont do them. Case in point my Mum is Irish and as such I was interested in learning Gaelic. Now my Mum does not speak Gaelic nor does anyone I know nor have I even been to Ireland but I liked the idea of learning Gaelic all the same. I bought a book with an audio track and spent a little time on it while I was on a business trip. Can I speak Gaelic today? No and the book is on a shelf in my home office. Would I still like to learn Gaelic? Yes but its not a goal that is inline with my current path in life so there is little motivation to achieve it even if I define it as a SMART Goal.

So before you sit down and start defining SMART Goals for yourself and your team you need to ask the question Why. For a team or organization ask Why does this team/organization exist? For yourself ask Why do I do the things that I do, and what are my motivations? For example: Why do you want to lose 10lbs? Why do you want to learn Gaelic? Why do you want to improve your code coverage? Why do you want to add this feature to the product?

In the above SMART Goal Statement the answer for why they wanted to increase their code coverage was answered with the line: so that we can make more confidant changes to our code in order to speed up our turn around time for bug fixes and new feature request to our end customers. One could assume the answer to the question why their team/project exists is to maintain and improve an existing product that their customer uses so as to improve their experience and make their actives (whatever the produce does) easier, and the answer to why their company exists it so solve the problem that the user had when they did whatever it is that this product does the old way (before they started using your product).

So that is why you should, and how to define SMART Goals. Setting goals is about motivation and focus and a good SMART Goal need to be Specific so you know exactly what your trying to achieve, and needs to be Measurable so you know when you have satisfied the goal and can mark it done. They also need to be challenging while still being Achievable, no point setting a goal for yourself or the team if you know you won’t be able to achieve it, and they need to be Realistic. Setting a goal which is technically achievable but given your current situation isn’t realistic that you will achieve it simply sets you up for failure and goals should be about positive motivation. Also a good SMART Goal need to be Time-Based, setting a goal for yourself without an idea of when you would like to achieve it will put that goal on the back burner until you forget about it in which case why did you set it in the first place? Lastly you should know why your setting the goal, ask yourself the Why question to figure out what the motivation is for. Motivation is good but there needs to be a direction other wise your just wondering.

Thank you, if you have a different view or have any comments or questions feel free to leave them below and I’ll try to answer them as time permits.

Until next time think imaginatively and design creatively

Brad

My interest in computer programming started back in high school and Software Development has remained a hobby of mine ever since. I graduated as a Computer Engineering Technologist and have been working as a Software Developer for many years. I believe that software is crafted; understanding that how it is done is as important as getting it done. I enjoy the aesthetics in crafting elegant solutions to complex problems and revel in the knowledge that my code is maintainable and thus, will have longevity. I hold the designation Certified Technician (C.Tech.) with the Ontario Association of Computer Engineering Technicians and Technologists (OACETT), have been certified as a Professional Scrum Master level 1 (PSM I) and as a Professional Scrum Developer level 1 (PSD I) by Scrum.org as well as designated as an Officially Certified Qt Developer by the Qt Company. For more on my story check out the about page here

Feel free to write a reply or comment.