How do you define clear objectives that direct the project but don't paint you into a corner?

Nick Maxwell of WM Partners explains how capturing PaMPeRed (Plan, Must, Previous and Record) values for objectives has given him both clarity and room for manoeuvre when delivering.

Unclear objectives are a root cause of project failure

Time and time again, research into IT project failure concludes that a key cause is unclear objectives. This reflects my own experience; unclear or misaligned objectives are a common theme when I've been asked to review projects. So it should come as no surprise that for the past few years, the Standish Group 'Chaos Report' has consistently ranked clear business objectives as one of the three most important success factors for a project.

Evidently, defining clear objectives at the start of a project, or even when trying to get it back on track, is imperative. But what is it that makes objectives clear?

Most of us know about and use SMART objectives to describe the properties of clear, unambiguous objectives; Specific, Measurable, Achievable, Realistic and Time-bound (see 'A recap on SMART Objectives' sidebar). If you take the time to ensure that your objectives are SMART you should find that they are precise, clear and understandable. But SMART objectives aren't always enough.

The problem with SMART

SMART objectives can be prone to 'objective gold-plating' where objectives are set like sales targets - a stretch in the hope that delivery is somewhere near the goal. When used like this, they leave a project manager no room for manoeuvre and can be self-defeating, especially when—as is often the case—objectives are antagonistic (eg deliver rich functionality quickly and for minimal budget).

SMART objectives can also paint too black and white a view of success and failure. For example; as part of implementing a new electronic trading system it had been agreed that it was critical to be able to implement new exchanges quickly. This was expressed as an objective to implement trading on new futures exchanges within 40 working days. Once delivered, the first exchange took 45 working days to be implemented. Was the project a failure?

To help answer this question of success or failure, I borrow from Tom Gilb, who has been a major influence on the agile software movement with his thinking on evolutionary delivery, inspection and attribute specification.

Describe the objectives acceptable range

A number of years ago I had the opportunity to work with Tom and he introduced me to the idea of recording Past, Must, Plan and Record values against different project attributes (for a more in-depth discussion refer to his book 'Principles Of Software Engineering Management'). I've found these very useful not only for a projects non-functional requirements (such as availability, transactions per minute, number of concurrent users), but also to better describe business objectives. The definitions of these values are as follows:

Past is the value that is achieved through any previous system or process. This is typically a target that should be matched, but not always. Sometimes it is desirable to sacrifice aspects of previous performance to ensure better performance in other areas. Note that gaps between the performance that is delivered and the past level of performance may require stakeholder expectations to be managed.

Must is the value that is the absolute minimum to be reached; anything less than this is considered a failure, anything more than this is considered a success.

Plan is the value that is planned to be reached. This is the desired value, and is different to the Must score (Must vs. Plan is "What is the absolute minimum you can accept?" vs. "What are you aiming for?"). The gap between the Plan and Must score can be thought of as an objective's tolerance (in PRINCE2 parlance). It is this tolerance that gives those tasked with delivering a project (the project manager, steering group and executive management) flexibility to make trade-offs between the different, and sometimes opposing, project objectives. This flexibility can be crucial in ensuring project success.

Record is the best score, relevant to the project's context, that anyone or organisation, has ever achieved. A project that sets out with an objective that matches or improves on record levels is clearly pushing boundaries, and will be far more challenging and costly, than one that has more modest goals. Record values can be useful in highlighting why a project is so challenging.

Using these values to frame a conversation on objectives with executive management really highlights to me what is key versus what is desirable. Once I have these values I document each objective as follows:

Objective	Specific, actionable and relevant description of the objective eg Implement an electronic futures trading system that allows new futures exchanges to be easily added and then traded
Measure	The way in which the objective will be measured eg The average number of actual working days to implement trading on three futures exchanges; ICE, CME and LIFFE
Timeframe	When the Objective is to be delivered by eg Ready for trading the first exchange by August 2008

Past	Must	Plan	Record
100 working days	80 working days	40 working days	30 working days

From this example, it can be seen that the Plan value is just ten days longer than the Record value so will be challenging. The Must level is double the Plan, but this still represents an improvement on the Past score. Given these values, the project that delivered it's first exchange in 45 days was a success, since it beat the Must value by a long way, and was only just short of the Plan level.

Some do's and don'ts

Clear but wrong objectives Well crafted objectives are a great tool to give direction and clarity to a wide range of stakeholders; eg the team, steering group members and the project's customers. However, take care with what is expressed.

A good example of this was a project I reviewed with an objective to create an online sales channel by a target date for a small set of initial customers and product offerings. This was a clear and well expressed objective, but it was wrong. In reality, the real objective was to decrease the overall cost of sales—this is what the company's board had signed up to—the internet was as a means to achieve this. Unfortunately, the current project had no means of achieving this. Recognising this, the only course of action was to suspend it.

Don't have too many objectives A few key objectives are better than a long shopping list - it's too easy to forget some and lose a sense of what's important.

Conclusion

Capturing four different values (Past, Must, Plan and Record) against objectives, has given me a means to devise clear objectives that help direct and align the project team, steering group and project's customers and still give me room for manoeuvre when delivering.

If you'd like further information on how to bring clarity to your objectives or are interested in our Project Review service, please contact Nick Maxwell directly.

A recap on SMART Objectives

Peter Drucker is credited with first coining the acronym SMART in his book 'The Practice of Management' as a means to describe the properties of good objectives in. The letters stand for:

Specific Objectives need to be as specific as possible. Quantify the outcome by being clear on a rate of expected improvement or the absolute number that is the goal.

Measurable You need clarity on the measure used to determine progress made towards an objective, or to confirm if an objective has been met.

Achievable Objectives can be challenging, as long as they are realistic and achievable. Unrealistic objectives serve only to de-motivate the team asked to deliver them.

Relevant Objectives should add useful value within the context they are set, for example they should be aligned with overall business strategy and goals.

Time-bound Objectives need a (realistic) timeframe within which they are to be completed else they risk never being completed. Even the Knights who say 'Nee!' in Monty Python's Spamalot realise this, giving King Arthur first 2000 years, then 12 seconds before finally settling on 'until teatime' for his quest to bring them a shrubbery.