Print This Page | Send This Page
Site Map | See Article Categories

Exploring trends and developments
in project management today.

- Home
- Articles
- White Papers
- Methods & Tools
- Templates
- Events
- Forums
- Bookshop
- Glossary

# Project Plans: 10 Essential Elements

Get the PDF Version
By Trevor Roberts
9 Feb
2009

Firstly, I need to make sure we are all on the same page when it comes to what a plan is. Many people (and a distressing number of project managers, too) think only of a Gantt chart when they think of a project plan. You may recognise it as what you get from Microsoft Project. This is better called a project schedule, in that it shows when we expect the various sections of the project to happen. We will come back to this later.

What we want to have in our project plan is:

1. Aim of project
2. Outputs
3. Quality criteria
4. Resources
5. Management structure
6. Milestones
7. Tolerances
8. Dependencies
9. Risks
10. Schedule

Let's have a look at these in turn, and see why they are needed, and what we want to achieve with each of them.

## Aim of Project

What do we want to produce? The aim of the project is a mixture of the reasons for doing the project and the benefits that are expected from it. This section of the plan can be either fulfilled by linking to the main business case, or by restating it in language for the expected audience. For example, your business case may have been written for high level approval in your organisation. You may want to now put it in terms the project executive expects.

## Outputs

Given the aim of the project, what do we actually need to produce to get there? What will your completed project be made up of? These need to be clearly defined. For example, your project's aim may be to upgrade the IT infrastructure in an organisation. Your final output would be a completed computer network, a new computer on every desk, and all appropriate software installed and ready to go.

## Quality Criteria

Now we have the outputs, we need to understand what quality they need to be of. In the example above, we have an output of a completed computer network. However, we need to know that the network can actually cope with the amount of traffic going over it!

This means we need the completed output to be of a certain quality, and we need to define what that quality is. These targets tell you what success is, what completion of the project is. They need to be SMART:

- Specific: Clearly defined and precise.
- Measurable: e.g. not "new computers," but "computers with 2Gb of memory," etc.
- Attainable: Don't ask for the impossible.
- Relevant: Is the criterion actually related to the aim of the project?
- Time-based: Enough time to achieve this. There is no point expecting a year's worth of work in one week!

It is important you take some time with the stakeholders in your project to produce this list. The final customer of the project will naturally be very involved, but don't forget your business head - don't promise everything without considering the costs. Your project executive, and a representative of those who will be doing the work, will have major inputs into this also.

Finally, you will also need to decide who has the final say over the quality of the outputs. Hopefully your work on defining the quality criteria will mean there are no arguments over the quality (i.e. no qualitative judgements, only quantitative) but you need to make sure you schedule in time and people to do the evaluation work.

## Resources

We have now set down what outputs we need to produce, and what quality they need to be at. This means we are now in a position to look at the resources we will need to achieve this. Resources include staff time, particular knowledge or skill sets, money (e.g. buying equipment), and time (some tasks can't be increased by throwing more people at the problem, e.g. delivery times, setting time for concrete, etc.).

## Management Structure

How are we going to manage the work? You need to describe the general approach to the project here. Who will be the decision makers for the various different streams of work? For example, you may be doing a significant procurement - who makes the decision about what company to buy from?

How will we share progress on the project? Who will we share it to? For example, you may decide to have regular project team meetings - who needs to attend? What level of information will you be sharing? Who else needs to be kept informed, at what level of detail, and how often? For example, you may want to keep the project executive updated at an overview level of detail on a weekly basis, while you keep other managers appraised at a higher level of detail.

You will also need to spell out the relationship of yourself to the project executive, in terms of the monitoring of progress. Equally, you need to put down how you will be monitoring progress of the allocated tasks.

There is no one right answer for how this should be done, and indeed it will vary with every project. Make sure you think about the size and complexity of the project, and also the organisation's ethos and current management style.

## Milestones

Here you need to think about how you will break up the project. Unless it is very small, you don't want to have the entire project as one lump of work, with the only check on progress at the very end. Instead, it makes sense to break the project up into discrete chunks, where related tasks can be lumped together, with a sensible milestone at the end of them. For example, in the technology refresh in the example above, you may want to break the project down into something like:

1. Requirements Gathering
2. Tender Writing
3. Tendering Process
4. Contract Negotiation
5. Deployment
6. Testing

It makes sense to have a defined milestone, so you know when each section is completed. There is also another benefit of breaking the project into chunks, which I'll come back to.

## Tolerances

You will have already looked at the resources you need. Now we need to set how far you, or the project executive, can let the project stray from these targets before needing to sound the alarm. For example, you could set a tolerance in terms of finance of +/- 5%, and a tolerance in terms of time of +/- 10%. Equally, you may want to look at tolerances of quality - i.e. how far from the quality criteria are you willing to accept?

It is remarkably unlikely that a project will not deviate from its resource or quality targets. Setting tolerances allows you to be able to manage the project without continually seeking guidance from the project executive as to whether you should carry on. This is not to say that you should be happy with these deviations, and you should try to avoid them, and monitor them closely. That way you can build your understanding of the project for the future.

## Dependencies

This is where you look at what needs to happen before something else. For example, in our example above, you need to complete the requirements gathering before you can finish the tender documentation. You need to start thinking about the dependencies so you, and the project team, can understand the impact of changes in any part of the project.

These dependencies should include both those internal to the project (i.e. those under your control), and those external to it (i.e. those outside of your control). For example, you may need an accurate figure for the number of staff in the organisation. This needs to come from your HR department, and would be an external dependency.

## Risks

Simply, what could go wrong? What could happen that would damage your ability to deliver the project? Are there things you can do to avoid them, or minimise them?

## Scheduling

This is the Gantt chart-style information that many people envisage when a project plan is mentioned. In this, you need to put down what you expect to happen when. It will include your dependencies, milestones, and probably resources. At this point, it will be a relatively high overview of the whole project.

There is something you need to understand about this schedule, and that is this: it will be wrong.

I know that seems a strong statement, but it is vital that you understand that you cannot make a perfect schedule. You really would be getting into the realm of prophecy if you think you can sit down now, and accurately and precisely pinpoint the date the project will end. No, what you need to do here is achieve the possible.

The schedule needs to include the overview, with the project broken down into sensible chunks. This is the other advantage of breaking the project into chunks we mentioned above. By having the project broken up in this way, you will be able to start planning the first section in quite some detail, extending out for a few weeks. But from then on, it will start to be based more and more on blind guesswork and faith. Don't try to be artificially precise - keep it vague, use rough figures.

As you come to the end of each chunk of the project, you will be able to plan the next one. You can use the information and experience you have just gained from the previous section, and thus you will be able to be more confident.

Make sure you explain this to your project stakeholders! Often your project executive may look at a schedule, and imagine everything is laid out and known. You must get this idea out of their head straight away! Explain that the early part is firmer than the rest, and make sure they expect changes as the project moves on.

Your executive will crave certainty, and absolute dates for the project, from the very beginning. You must resist the pressure to name a specific date, and explain why. While there may be a temptation to give an answer (no doubt of a date plucked, essentially, from the air) you need to instead be realistic about what is and isn't possible in terms of scheduling. Anything else can only lead to trouble for you, the project, and ultimately your executive further down the line.

## Don't Panic!

Phew! That's a lot to fit into a plan! But don't worry, you won't be doing this alone.

You see, you cannot know everything you need to complete the plan, and you shouldn't expect to. I've mentioned bringing other people in to decide what success looks like, and it is vital that you bring people in to help with the scheduling. You will have a project team who will be doing the work, and it is probable, if not certain, that they will have a better idea than you of how to break down a chunk of work into specific tasks, and how long those tasks will take. Make use of their knowledge! This has the added benefit of bringing them into the project, and helping to start the process of turning a group of individuals into a team.

Trevor Roberts runs his own project management consultancy, and has worked as a project manager for business and government. He also writes www.projectmanagementguide.org where he aims to help you learn more about project management. You can follow him on Twitter at twitter.com/trev_roberts

Comments page 1 of 1
Click here to add a comment

Your Name:

Image Verification:

Comment:

Chris Bishop
Posted 226 days ago
It is reassuring that within any project we are not alone and, providing good working relationships prevail, we can rely on the support of others.
Bill Duncan
Posted 315 days ago
You missed what may be the two most important element of the plan: project success criteria and a mechanism for keeping the plan up to date.
<1>

Agile Project Management

Best Practice

Business Case

Case Studies

Change Management

Communications Management

Cost Management

Earned Value

History of Project Management

IT Project Management

Lessons Learned

Lifecycle & Methodology

Microsoft Project

Miscellaneous

Outsourcing

Pareto Principle

PMBOK & PMP

PRINCE2

Programme Management

Project Documentation

Project Management Office

Project Planning

Project Portfolio Management

Project Sponsorship

Requirements Management

Rescue & Recovery

Risk Management

Role of the Project Manager

Scheduling

Scope Management

Six Sigma

SMART Goals

Stakeholder Management

Team Building

Training

Work Breakdown Structure

### Related Articles

Project Planning A Step by Step Guide
The key to a successful project is in the planning. Creating a project plan is the first thing you should do when undertaking any kind of project. Often project planning is ignored in favour of getting on with the work. However, many people fail to realise the value of a project plan in saving time, money and many problems.

Use SMART Objectives to Focus Goals, Plans and Performance
What's so smart about SMART? Why has this acronym become part of the vocabulary of project planning and performance management? Objectives that are SMART (Specific, Measurable, Aligned, Realistic/Relevant, and Time-bound) are likely to be achieved.

17 "Must Ask" Questions for Planning Successful Projects
Why do some projects proceed without a hitch, yet others flounder? One reason could be the type and quality of the questions people ask at the very start. This article suggests 17 insightful queries that can expose the uncertain aspects of your project, and thereby help you avoid expensive surprises later. You can thus achieve your project goals with much less guesswork and far fewer problems than you may have experienced in the past.

Useful Techniques to Fine-Tune Your Project Schedule
One of the most common problems that project managers weep about is "unrealistic timelines," a common consequence of clients having set their expectations too high even before the project starts. Ironically, there are occurrences in the duration of a project when a staff is sitting idly, waiting for a colleague to finish so he can start his own task. In this situation, does the project manager shout foul and blame other people? Chances are, as a project manager, he needs to give the project schedule a second look.

21 Ways to Excel at Project Management
The popular project management e-book now fully updated and available as a website for the first time.