Seven Steps to (Objective) Heaven

Part 1 of the “How to Plan Successful Projects” series

Introduction - Seven Steps to (Objective) Heaven - Defining Your Deliverables

One of the earliest, and most important, lessons in project management is the importance of identifying a project's objectives. This article describes the seven essential steps you need to take at the start of every project...

start quotation The first lesson I learned in project management was that identifying and documenting the project’s objectives is vital. The second was that the person telling you what the objectives are may be wrong...

When I picked up a PRINCE2 manual for the first time in 2003, I discovered that identifying objectives and stakeholders are the crux of “SU: Starting up a project”. PBMOK recommends much the same and, if you dig under the surface, you will find the same thing in pretty much every methodology including agile development.

James Pels, CEO

The first two of the "Seven Steps" deal with those early lessons James learned. They are to identify exactly what it is you are being asked to do and make sure you know who really needs to be involved. The next five build on that to give an accurate understanding that will give you a firm foundation for any project.

Step 1: Prerequisites

The two main prerequisites you need in place are the Project Mandate (outlining the project itself) and the Project Board (who will provide project governance).

Mandate Format

The Project Mandate is the initial request for a project. At the least, it should comprise a description of the business problem the project is intended to solve; it might also include a proposed solution and some detailed requirements if they are known.

The mandate can be formal or informal, verbal or written and in any format but, without it, you will not be able to identify the stake-holders or progress with the project. However you receive the mandate, attempt to write it up formally and clarify it with the person who gave it to you.

Project Board

Once you are comfortable with the mandate, you can work on the Project Board. This is the management team that will take responsibility for the project. Strictly, this is not the PM's responsibility but chances are some or all of it will get delegated to you and it is often in your favour to at least be involved. The three roles you must ensure are filled for each project are:

  • Project Executive: the ultimate decision-maker – the buck stops with this person so make sure they really are empowered to make all necessary business decisions, including financial ones.
  • Senior Supplier: represents the needs do the people doing the work and might be made up of several internal and / or external people.
  • Senior User: represents the needs of the people using whatever the project produces; again, the role could be made up of more than one person.

In an ideal world, the Project Board will have been in place from the start and the person who approached you to be the PM will be the Project Executive. However, you need to make sure that this person has the authority they say they have - very often they will be a "sponsor" (somebody driving the project) but not having the real authority to make executive decisions. This is a tough situation and is a good test of your people skills!

It is hugely in your interest to make sure the Project Board is effective so be prepared to negotiate with the business over its composition if necessary.

Step 2: Identify The Stake-holders

Once the prerequisites are in place, the first step in working out your project’s objectives is to identify its stake-holders. These are the people or groups that have a vested interest in the project, even if they do not realise it at the outset.

Think about everybody who will be impacted by the project – not just the end users but the support team who get to look after it, the sales team who have to sell it and so on.

The stake-holders are the people who understand what the project needs to do and what it will impact on so you absolutely must get their involvement at the start.

Step 3: Identify your Objectives: the Three “W”s

Now that you know your stake-holders, you can work out the project’s goals – we call these “Objectives”.

Be careful not to get your objectives and deliverables mixed up. An objective is a desired outcome for the objective whereas a deliverable is something you produce to help meet an objective. We will cover deliverables later.

Each Objective should address the three key “W”s: “What?”, “When?” and “Why?” Typically, most of the “What?” will be well understood even if the boundaries are not fully defined; the “When?” is “yesterday” and they “Why?” has not been thought through.

“Because our competitors have one” is NOT a good enough reason – it might make sense for them to have one... or it might turn out to be the thing that bankrupts them.

Despite the difficulties in answering “Why?”, this is perhaps the most important question to get to grips with. If you cannot answer this, there is no sound business basis for the objective and the project needs to be reconsidered.

Many people would also consider “How?” and “Who?” at this stage. Our preference is to leave this out for now. We feel these are best addressed when we look at Deliverables. “Who?” could be interpreted as meaning “Who needs the objective” but this should be clear from the “Why?”. Do, however, feel free to document the stake-holders interested in each objective for future reference.

Talk about the objectives with all your stake-holders. You need to understand what they do, why they do it, what external systems they interact with and what constraints they are under. Your project should aim to improve things; at the very least it should support things without making them worse.

Chances are that your project will impact on a number of people and need them to work in a different way without offering them any direct benefit. These people are frequently overlooked but important stake-holders with a lot of power to make your life as a PM difficult or easy - getting their buy-in early on will head-off a lot of potential objections and unnecessary work later in the project.

Step 4: Be SMART

Each objective should be SMART:

  • Specific: it should address a known issue or requirement
  • Measurable: it should have tangible benefits with a way of measuring success - if you cannot measure it, you will never know if it has worked.
  • Achievable: it is OK to stretch the project team but each objective must be within bounds of reality.
  • Relevant: it should be relevant to the wider business context
  • Time-bound: it should have an associated target date – if there is no deadline, it does not matter if it never gets delivered so it cannot be a true objective!

If an objective is not SMART, it either has not been fully understood (go back to your stake-holders and clarify it) or it is too complex (break it down into more manageable pieces).

Another useful sanity-check is whether or not you can identify a single business “owner” for each objective. If this is not clear, either you do not know all the stake-holders (go back to Step 1) or the objective is too complex and needs to be broken down.

Step 5: Work out the Business Benefit

Once you have identified the objectives, you are ready to have a meaningful conversation with the business about what benefit, or value, each objective has. This is one reason why answering “Why?” in the previous step is so important – without it, you have no way of knowing what value the objective has.

Business value will sometimes by a financial amount – “increase profit by 20% over the next three years” or “save £75,000 in annual operating costs by the end of this financial year” – but often it will be more like “remove reliance on xxx software before support runs out in July” or “improve customer satisfaction scores to 85% within two years”.

The important thing here is to make sure the benefit is measurable, even if you cannot put a direct financial value on it, and that there is an achievable time-frame for realising the benefit – see “Be SMART”, above.

Step 6: How Much will it Cost?

Budgets are obviously an important part of the project. The business may have an idea of what it is willing to spend but you cannot set a true budget before you identify the objectives as the stake-holders will not know what they need. Equally, you cannot leave it any later as you need to know if the project is achievable.

You should also involve your suppliers (whoever is delivering the project – internal or external) to get their view on costs to meet the objectives. Exact figures do not matter and will set false expectations at this stage – so long as everything is within the same order of magnitude, you will be fine.

Orders of magnitude are a good way of getting rough estimates. Each order of magnitude is 10 times the last one, so they start with tens, then hundreds, then thousands and so on: £3,000 and £8,000 are in the same order (thousands), as are £2.5M and £8.2M (millions).

Each order may seem to have a very large range but the approach is good enough to identify if it is worth putting any more effort into the project. For instance, if Manufacturing thinks it will cost “hundreds of thousands” to deliver but the budget is “tens of thousands”, you know you have a problem.

With a little experience of the size of projects you deal with, you can refine this scale to suit.

Step 7: Review the Objectives

The final step is to review the objectives with the stake-holders so they can decide whether or not each objective represents value-for-money (Return on Investment or RoI in finance-speak) and what to do about them.

Some objectives will be fine as they are, some may be altered to reduce costs, some may be put back into a later phase to spread costs or assess interim benefits and some may even be canned at this stage.

Whatever happens, ensure you have the Project Executive’s approval and document ALL decisions in your RAID Log. This is not about assigning blame but you do need to cover yourself - most organisations have some form of office politics going on and it is very easy to point fingers at the PM when things do not go quite as planned... (have you ever seen "The Apprentice"?!)


The aim of this step has been to understand what your project is trying to achieve, who will be affected by it, what outcomes and benefits it should have and, very roughly, what it will cost to achieve.

If you have achieved all this, congratulations! You know what you are trying to do and are well on the way to running a successful project.

Next: Defining Your Deliverables