Why is it that so many organisations fail to set up their change and improvement projects in a way that improves the chances of delivering something useful?
I’ve worked with numerous clients and been asked to help get projects kicked off effectively, or get them back on track after they’ve stalled. Often it’s the simplest elements of setting up a Project that cause the most confusion.
Most organisations these days have a project methodology, or lifecycle model, that they use to run projects. In the public sector PRINCE2 is popular, but there are plenty of other perfectly good models.
All these models typically take projects through lifecycle stages that include:
- Initiation – setting up the project at its inception
- Definition – creating a clear statement of what needs to be achieved, by when, with what resources
- Planning – detailed development of plans (time, resources, quality requirements)
- Implementation – the “doing” stage
- Close-out – wrapping up the project and transferring solutions to “business as usual”
- Review – identifying learning points to build into future projects
In this and the next four posts I want to focus on some of the basics to help ensure a project is initiated successfully.
Let’s set up a project!
Those who come up with the bright idea for a project may not be the people who have to run it and deliver solutions. So, the ability to turn the bright idea into something that can be run as a project (by someone else) is a critical stage.
It’s not unusual to need two separate stages of “Initiation” and “Definition”, unless there is sufficient information available right at the start for a clear definition to be produced. You might know the initiation stage document as a Project Charter, Project Mandate, or Terms of Reference. For the purposes of this article I will refer to it as a Project Initiation Document (PID). The more detail you can provide, the more likely it is to be a Project Definition Document. In some ways the name doesn’t matter: it’s not about filling in forms, it’s about being clear about what the project has to achieve.
At this stage, you need clarity and focus. A 20 page PID is not going to be read by many people and, in my experience, it’s likely that project sponsors or managers will be too confused by excessive project jargon to produce anything of value. Here’s what you need and some examples of where people go wrong.
What’s the problem?
Sometimes, a good place to start on a PID is a definition of the organisational problem you are trying to solve. It can be easier than going straight to objective setting. Identify the current performance issues that have caused the project to be initiated in the first place. Not all projects set out to solve problems, so if you’re working on an opportunity, describe that instead.
You can then use these statements to focus on setting SMART objectives (what would “good” look like?”).
Write a one line statement (or a few concise bullets) that specifies what the project is trying to achieve. Objectives should begin with the word “To…”; e.g.
- To reduce time to respond to complaints by 50%, by November 2011
- To increase income by £50k, by 31/03/12
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.
So, objectives must define quantitatively, 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.
Benefits are the positive outcomes of a project and sometimes only become “obvious” after a project has been completed (occasionally many months later). They should be identified early in the Initiation stage and part of the detailed planning will be to ensure that they can be realised when the project moves into its implementation stage. Some benefits may emerge early in the project (Quick Wins) and these are important as they can demonstrate the value of the project to stakeholders quickly. The earlier you can deliver benefits, the sooner you will be able to justify the investment in the project.
Benefits may be financial (e.g. cost savings, waste reductions) or non-financial (e.g. audience increases, employee satisfaction improvements), but either way, they should be as tangible and measurable as possible. Often, your stakeholders will be able to tell you what they expect the benefits to be. Remember, benefits come from people (stakeholders) using the deliverables which the project produces. Be realistic about the potential benefits; at the end of the project you will be expected to demonstrate that they have been achieved.
As well as identifying the expected benefits, it is important to establish when you would expect these to be realised and be clear who is responsible for their realisation. When during the project, or how long after implementation, will they be confirmed? How will they be measured and who will confirm that they have, in fact, been achieved?
Part 2 will describe Scope and Deliverables.