I’m working with several clients where people are being asked to initiate projects, but seem unable to understand the difference between Objectives, Measurements and Deliverables. This really hinders their ability to come up with do-able projects, with clearly identifiable benefits. I’ve written a quick guide to Objectives Measures and Deliverables, and there’s a more detailed overview of Project Initiation here. If you prefer, you can read the guide by clicking on the “Read the rest of this entry” hyperlink below.
Project Objectives:
Write a one line statement (or a few concise bullets) that specifies what the project is trying to achieve. Objectives are often expressed in the form: “To [improve/increase/enhance/etc.] something, by [x amount], by [dd/mm/yy date]; e.g.
To reduce time to respond to complaints by 50%, by November 2008
To increase income by £50k, by 31/03/09
Ideally, they should be SMART, or be capable of being made SMART once further definition work has been done. SMART = Specific, Measureable, Achievable, Relevant, Time-bound. If you can track achievement against the objective on a graph, then it’s probably a SMART objective.
They don’t contain words such as “optimise”, “maximise”, “minimise” and they don’t have deadlines such as “Autumn” or “Quarter 3”. They certainly aren’t “ongoing”.
They should not describe what you plan to do, how you plan to do it, or what you plan to produce.
The only type of project where you probably cannot write a SMART objective is a scoping, or feasibility project, where the aim is to deliver a recommendation or report.
An objective “To implement a new xyz IT system” is not an objective. What is the expected organisational benefit here? If you can see it, feel it, file it, trip over it, or put it on a shelf, it’s probably a deliverable, not an objective! You won’t be able to draw it on a graph.
So, objectives must define desired benefits, outcomes or performance improvements that you expect from the project. What you need to measure on your project will naturally fall out of the definition of good objectives.
Project Measurements:
What you need to measure on your project will naturally fall out of the definition of good objectives. Measurements are about data and should therefore be capable of being summarised on a graph. There aren’t that many things you can measure, although there are many examples and many potential derived measurement ratios:
Some Measurement Examples…
Volume: Input volume, Output volume (yield), Number of…, Frequency & Usage rates (No./Day)
Time: Activity processing time (Duration), Cycle-time (end-to-end), Delay (waiting time)
Cost: People cost (from time & overhead), Resource costs (non-people), Profit/Loss, Value-add
Success Rate: Accuracy, Error Rate, Response Rate, Attrition Rate, Completion Rate, Wastage Rate, Non-compliances
Conformance: % Achievement of specification, Completeness, Availability
Timeliness: On-time Delivery, No. or % Delivered within target, No. or % Delivered late
Perception: Satisfaction, Happiness, % Agreement/Disagreement, Intention to re-purchase/re-use/recommend, Loyalty
Physical Parameters: Length, Weight/Mass, Volume, Area, Time, Acidity, Velocity, Acceleration, Current, Voltage, Energy
Project Deliverables:
These may also be called “outputs” or “products”. Too many Project Initiation Documents specify Deliverables as their objectives. Deliverables are only produced in order to enable achievement of the objectives.
Deliverables are the tangible things that the project will produce to enable the objectives to be achieved. The focus should be on the “real” deliverables (such as new facilities, paperwork, equipment or materials), not the “internal deliverables” (such as a Project Definition, a Business Case or a Risk Log). It is these “real deliverables”, when used, that will deliver the project’s proposed benefits.
Deliverables will often have a level of quality or specification associated with them, against which their performance can be assessed.
Many IT and Facilities projects suffer from having deliverables expressed as objectives. The result is that the focus of the project is on delivering “stuff”, rather than improving organisational performance.
Written by Ian Seath, Improvement Skills Consulting Ltd (one of ShoNet partners)
Improvement Skills Consulting Ltd. was established in 2007 by Ian Seath who has consulting experience going back to 1990 (and internal consulting and facilitation prior to that). Ian has worked with more than 200 clients and helped implement a wide range of approaches to improve customer satisfaction, reduce process cycle-times, drive out waste and actively engage staff in continuous performance improvement.