You're reading...
Agile/Scrum, Project Management

Not all projects can have (proper) SMART Objectives

There’s lots of talk and advice about setting SMART Objectives for your project, but it’s not always possible. SMART has various versions, but I tend to use:

  • Specific – it is clear what you are trying to improve
  • Measurable – you can collect performance data to check if improvement has happened (either subjective or objective data)
  • Achievable – there is evidence that the new, desired, level of performance is feasible (perhaps based on experience elsewhere, or from benchmark data)
  • Relevant – the improvement is meaningful and aligned to some overarching organisational strategy
  • Time-bound – there is a deadline date when the new level of performance will be seen

It’s very clear from this sort of definition that SMART Objectives are a way to describe a desired improvement in performance. Therefore, you should be able to express them on a Time Series Graph.

SMART Objectives - 2

At a recent workshop, we were discussing a range of projects that the participants had brought with them and it dawned on some of them that they couldn’t write a SMART Objective. Their projects were not about improving performance, they were about building capabilities so that other people could use them to improve performance.

The picture I drew on the flipchart helped people identify whether or not they could write a truly SMART Objective.

SMART Objectives 1 - 1

The key messages:

  1. If your project (or programme) is expected to improve performance, you should write improvement-based SMART Objectives
  2. If your project builds some form of capability for others to use to improve performance, you can’t write a performance-oriented SMART Objective, but you’d better be really clear about what improvement it is expected to contribute to and how much improvement is required

So, what do you write if your project is only building capability? You write an objective that describes how the project will meet the needs of its customers.

For example:

  • To create a signed-off, available website that meets the needs of Marketing, by dd/mm/yy
  • To hand over an approved, compliant, Purchase Order system, by dd/mm/yy
  • To deliver a validated, user-tested, workflow for order processing, by dd/mm/yy

P.S. I don’t subscribe to the view from some methodologies that Programmes deliver Benefits, while Projects only create Products. I’ve facilitated numerous projects over the years where we have specifically improved performance (delivered benefits) such as cost savings, customer satisfaction increases and process cycle-time reductions.

P.P.S. It’s possible to achieve improvements during the lifecycle of a project (or programme); you don’t have to wait until the end and, if you’re using Agile methods, this would be an expectation.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Advertisements

Discussion

Comments are closed.

Connect with Ian Seath

Find us on Facebook Improvement Skills Consulting Ltd. on LinkedIn Follow IanJSeath on Twitter

Archives

Copyright Notice

© Improvement Skills Consulting Ltd. and Ian Seath, 2007-17. Unauthorised use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Improvement Skills Consulting Ltd. and Ian Seath with appropriate and specific direction to the original content.
%d bloggers like this: