Writing objectives
Ah, the Novartis performance management system… I have plenty of draft blogs and notes to myself about what works, what doesn’t, which parts to ignore, which parts are good, why this stuff is hard and important… perhaps I’ll dig my way through that and make some of it legible and useful enough for a blog post or two. My one line-summary would be something like “oh well… let’s make it useful”.
So let’s start somewhere practical: what I’ve found makes a good set of objectives.
A caveat: this works for me, and it’s what I’ve asked my team to do for their docs. It may or may not be appropriate for you, your team, or your situation. It depends on what you do and the context of your work. But, if you have no strong reason for doing something else, I’d recommend you try this.
How to Write an Objectives Document
Use a word document or a sheet of paper. Do not attempt to do this in the PMP system. Use that simply to cut and paste stuff into at the end, minimizing your pain.
Think of the most important things to accomplish in the timeframe of the objectives document – typically 12 months, but sometimes as short as 3. THAT is what should be in this objective document.
This is NOT a comprehensive list of the elements of your job description.
This is NOT a project plan.
This is NOT a contract where the numbers add up to 3.3.
It’s a list of your top goals.
Aim for 6-8 goals. Not 3. Not more than 10.
Objectives should be short. 1-3 sentences. Not paragraphs. Not having many sub-elements, each with their own objectives.
This is not a Gantt chart, nor a PhD thesis. This is a goal, not a detailed plan.
The objectives system asks for “priority” and “% of time”. In the majority of cases, these numbers are irrelevant. Leave them empty or make something up, unless you and your manager both feel these numbers actually have relevance.
Think of objectives as one of five types:
Type A: specific, measurable goals. “Deploy X to Y by Z”. These are used to set a stake in the ground – a very clear target. I usually aim to have 2-3 of these. I often inherit a few of these from Mark, and often pass these through to the individuals who are directly responsible for them.
Type A objectives are ones that are often referred to as “SMART” goals. The “SMART” acronym just makes me roll my eyes… If you get “Measurable” and “Time-bound”, then you’re good. That will make it Specific. No one can ever remember what the A and R stands for.
Type B: aspirational, directional objectives. “Roll out a pilot biology lab notebook.” “Develop and implement first phase of data curation strategy.” Etc. These aren’t specific because you don’t know enough to be specific yet. But you know enough to know they are important.
It’s often the case that the lead for an activity will have a Type B goal, but that many of her reports will have several Type As that roll up into that Type B. E.g. an appropriate Type A would be “Complete user acceptance tests of first pilot group by end of June.”
For team leaders, there should be at least one of these around the development and fostering of the team. If that can be a Type A, so much the better.
Type C: job description goals. Objectives that are “activities”, not really “goals”. I don’t like these much, but they are necessary in some cases. “Maintain stable operations.” “Manage to financial guidelines”.
Sometimes these are there because they are simply such a huge part of your job that they have to be mentioned. But if you have several of those in the document, something is wrong. Objectives are more specific than “just do my job”. These, frequently, are on the objectives list largely in case there’s a problem. Don’t screw those up.
Type D: optionally, a development goal. “Attend course on X, and put learnings into practice.” “Mentor Fred, whether he likes it or not.” “Learn a new programming language and write something useful in it.”
This may be related to your own goals around self-improvement, it may come from the context of your team, or it may be related to a performance improvement plan. In any case, this is should be on there to help make them explicit and to have the discussion with your manager.
It’s usually optional, but I encourage it.
Type E: the “everything else” objective, but only if you have to.
In some cases, dependent on context of job, local expectations, and so on, it may be necessary to actually have the objectives document line up with the job description on paper. Or you may want to ensure that you do discuss your entire job scope during objectives setting and performance management.
If you have an Everything Else objective, use a clause like this: “All other job duties and responsibiliti es, as noted in my job description and in discussions over the course of the year, including X, Y, and Z.”
But don’t do this unless you really, really have to.
That’s it.
So, to recap:
- It’s about goals, not about everything you do
- 6-8
- Be specific where possible
- Be aspirational where it’s not possible to be specific
- Be general if you really have to
- Aim to have a development goal.
Why?
In my view, the objectives document serves two important purposes.
- As a high-level planning document for the year (or relevant time period), answering the question: “what are the most important things to get done?”
- As a framework for conversations to discuss: “how well did I do in accomplishing that goal, what worked, what didn’t work, what can I do better?”
And, for those purposes, it’s best if it’s simple and focused, not long and complex.