It is appraisal cycle in most of the companies now. This means you have to fill the goals for the next cycle. If you are in IT Industry for few years now, you would have heard this term SMART Goals at least some 100 times from your managers, HR Team members etc.
S – Specific
A – Achievable
R – Realistic
T – Time bound
Are we writing SMART Goals every time?
Not necessarily. Every year, we attend a session on writing smart goals and every manager we worked with us, has asked us to define SMART goals. But, still most of us are not sure how to do this. We all have defined goals which are not specific and measurable.
Why? Reason is simple. The devil is in the details. It is not as simple as it looks.
Why should I learn this stuff?
When a manager and a team member know how to write a SMART goal, it helps in reducing the subjectivity in the performance appraisal cycle. If there can be a review (1:1) every month, based on this goals, there is no way in the world where the manager and the team member will have different expectation on how one is doing. This will definitely reduce the expectation mismatch at the time of appraisals.
How to Write SMART Goals?
Let us take a personal goal as an example before moving to professional goals. Most of the people in IT would definitely like to reduce their weight. So, if we have to write a personal goal around this it could look something like this.
Let us write one more personal goal.
Bank balance in Prakash’s Saving Account will be >500000 INR by Dec, 2011.
Immediate thing which may come into your mind is, Prakash this is good. But, you know we are working on software development which is very complex in nature.
Writing a personal goal on weight reduction might be simple. But not goals in our work environment. How do we write goals?
The first thing to identify while writing goals is to define what are we trying to achieve out of the whole exercise. Meaning, we should know what we want to achieve and achieving that should give us some sense of accomplishment.
Example: You are in Bangalore and let us say one day you have headache and you feel like drinking filter coffee will do good for you.
• If you have to have a goal of drinking filter cofee (when you are in bangalore), if you drink one will you have a sense of achievement? Every corner dharsini will serve you filter cofee.
• Let us say you are in New York and you want to drink South Indian Filter coffee from a Restaurant. If you some how manage to achieve this, I am sure you will have a definite sense of achievement.
The point which I am trying to make here is that the same stuff, If something is easily available and you achieve it (low hanging fruit), you may not really get a sense of achievement. If something is not easily achievable, achieving that makes our life interesting.
I am a Developer. Can you give me an example relevant to me?
Unit test coverage will be >=80% for all the new features developed by Prakash in the next 6 months starting feb, 2011.
Can we measure this goal? Yes, we can. How do you measure?
1. Code coverage can be found by code coverage tools.
2. New Features developed by prakash can be retrieved from TFS or any other tools which you are using.
Is this Specific? Yes, it is.
Do we have time line? Yes, for the next 6 months starting Feb, 2011 (Feb, 2011 to Jul, 2011)
Is it realistic? Yes, looks like realistic.
The realistic part is something which the team member and manager has to review every month.
Say for example, when we agreed to this goal during the goal setting period, it looked like we will be developing new features. But when we entered march, we have decided that we will be focusing on stabilizing our product for next 4 months (sounds familiar :)). This goal may not be relevant in that situation and you have to change your goals. If you do not get this reviewed with your manager every month and if the above mentioned happened, you will still have surprises at the appraisal cycle.
Is it Achievable? Yes, 80% Code coverage is achievable. But, make sure you review it every month and see whether its achievable. There are cases where you may have to increase or decrease the %age.
One More Example, Please
# of bugs fixed by Prakash in PRODUCT ABC will be atleast>1 every day for the next 2 months starting Feb, 2011.
I am a Test Engineer. Can you give me an example relevant to me?
# of tickets logged by end users will be <15 on the features tested by Prakash in product abc version 1.1 between the period Feb,11 to Jul,11
I am a Project Manager. Can you give me an example relevant to me?
By automating PRODUCT ABC, the regression testing effort will be < 15% from the current effort by Jul, 2011 .
Velocity for the Team abc will be >10% from the current velocity by Jul, 2011.
Is this measurable? Yes, but you need to know your current velocity. As a manager, if you do not know what is velocity then nothing can be done.
I am a Second Line Manager. Can you give me an example relevant to me?
Revenue Generated by the teams managed by Prakash will be >Xxx$$$$ by Dec, 2011
Some points to remember while doing this exercise.
1. Define a goal which will give you some personal sense of achievement.
2. Goals are like documentation. It’s very important to keep it alive. Review it with your manager so that the other person where you stand in your goal.
3. What you measure is what you get? Say for example, if you write a goal around # of test cases automated, you may end up automating all primitive test cases to meet the target which may not add any value.
4. Learning goals should have some completion. Meaning, there is no point in defining a goal like “Learn SharePoint in next 6 months”.
5. If you are a manager, make sure that you help your team members define their goals. If you define the goals for them, it will always stay as your goals and will never become the team member’s goal.
6. Do not define more than 6 goals. # of goals you define should be somewhere between 3 and 6 for the next review period.
7. Print your goals and stick it in your cubicle. This will help you to remind yourself daily.