Frequently in my workshops, I ask participants what they found to be the most challenging topic we have covered. Invariably the response is the writing of project objectives. I am not surprised. In my experience even seasoned project managers and certainly senior executives have a difficult time pinpointing precisely what their projects are designed to achieve. So let's start with some basics. What is the purpose of a project objective statement? Principally it is to define what project success will look like. And a project will be deemed successful if it delivers its promised benefits - the very ones described in the objective statement. The statement should be used to answer the 'why?' question as in 'why are you planning to implement this project?’. As such it is a vital piece of documentation providing a beacon that lights the way throughout the project journey. It also plays another less well-known function. It should be used assist those charged with the responsibility of validating the success of the project when the appointed time (part of the objective statement) arrives usually well after the end of the implementation phase.
What about on time and on budget? These are different questions, relating to how well the project is managed. Important as they are, these are not the focus of a quest to clarify objectives. Besides, in the end we would rather have a successful project a little late and over budget than a beautifully managed disaster which fails to deliver on promises.
So why do people find objective writing difficult? I have read and listened to thousands of project objectives presented by their authors. The following are the primary shortcomings I have heard.
They don't obey the SMARTA criteria
These are Specific Measurable Achievable Time-framed and Agreed - elaborated below. Except for measurable these are pretty straightforward. Some balk at providing a timeframe for benefits realisation, These same people would presumably not wish to pay for a service (say a plumber) who says the problem should go away at some point in the future, which for all practical purposes is like saying it may never go away.
They Stray into a description of project deliverables.
An example of this type of error is the objective statement: "To produce a database in order to provide more information to business analysts". This tells us not only why we are doing the project (which is its role) but also how it will be done and what product we shall have to do this, which is not. The mention of a deliverable in this way is only acceptable if the scope of the project has been narrowed to provide the benefits in a prescribed way (e.g. to design a database) which implies that the project manager, while always the solution provider, is not in this case the solution identifier but rather sits downstream in the decision process from that person.
The provide vague and lengthy introductions.
The objective statement should be a concise, punchy and clear statement of the purpose of the project. I encourage people to begin with positive change words (to improve, to enhance, to increase, to reduce etc). The example from the previous paragraph might better be expressed as as "To increase the quality of information to business analysts by the end of this calendar year”. Further paragraphs can always be provided to elaborate where this is needed and a preceding ‘Background’ section is always useful to provide historical context
They provide subordinate objectives
Consider the following example of what I mean here: The statement "To Increase the quality of information to business analysts in order to improve the efficiency of marketing campaigns". Note how the ‘quality of information' is no longer the primary carrier of value in itself but appears as a sub-objective supporting the real one - "to improve efficiency of marketing campaigns". Either the latter is the main objective, in which case only it should be stated without the sub-objective, or perhaps both this and the 'quality of information' are regarded as having value, in which case both should appear as objectives, at the same level, presented perhaps as bullet points to show their equality.
They neglect clear statements of evidence that will support a claim for project success
Where evidence is not quantitative, it is necessary to provide a clear description of what the environment will look like once the project has been completed and its deliverables have been given time to start being effective. Further suggestions appear below under the ‘Measure’ criterion below.
They don’t align claims to the evidence
As mentioned earlier, part of the purpose of writing objective statements is to provide a description of what success will look like. When the benefits promised are quantifiable, this is rather easy to describe - we provide a number or a range. For example, "Cost savings will be in excess of $30000 per year". The more challenging type of benefit is one that does not yield to such measures. In these cases we need to provide a descriptive explanation, a paragraph or two of evidence that will be available after some stipulated period of time after the project completion. Here project managers often outstrip their authority in their claims. A workshop participant once stated the claim that he would secure Australia's food supply when what he really hoped to achieve was to improve weather forecasting techniques. As a weather scientist this was a claim he could make. He could then strengthen the value of the project by providing a causal link between weather forecasting and food supply security but he could not justly lay claim to improving the latter if for no other reason that there would be many scientists working on this who might have similar claims.
The SMARTA criteria
Good project objectives should satisfy the SMARTA criteria. That is, they should be Specific, Measurable, Achievable, Relevant, Time-framed and Agreed.
'Specific' simply means we should avoid vagueness, generalities and fuzzy thinking. An objective definition needs to be sufficiently specific to allow us to run a project against it.
As stated already, attaching 'measures' to objectives is necessary if their ultimate realisation is to be verified. The following table shows some examples of measures in various contexts.
Improved Customer Services
Survey Results/No of Complaints
Output per input expended
Greater Educational Reach
Number of students graduating
Higher Quality Product
Number of faults, breakdowns or complaints
More Streamlined Procedures
Number of people required to contribute
However, It is not always easy to measure benefits. Many of these are intangible, defying quantification. These need a descriptive paragraph or two that provides a multiplicity of angles by which success can be judged. This is sometimes called 'triangulation' and derives from a estimation technique utilising more than one perspective. The ideas as that the overall sense of success across these perspectives will suggest success even if some are not fully realised.
Capturing the meaning of success can be challenging, particularly in relation to projects that involve involve design, research, analysis, writing or the development of software, policy or curricula. These are very much more difficult to measure. Nonetheless we should try.
'Achievable' simply means at this stage we feel good enough about the project to continue. It is not technically impossible. Achievability is a weaker criterion that feasibility which is what needs to be judged once the preliminary project definition or initiation phase has been completed.
'Time-framed' refers not to how long the project will take but that time point beyond when we think the benefits will be ultimately be realised.
'Agreed' implies that the project owner, key stakeholders and other important figures have provided written support for the project before it gets off the ground.
The following examples of objectives satisfy the SMARTA criteria.
- “To reduce the number of traffic accidents at intersection A by 75% by June 30 of next year”
- “To improve throughput in the dispatch area by 5 deliveries per day by December 31 of this year”
- “To reduce the number of complaint calls received about the company's billing system by half before the end of the year.”