Creating a Project Plan (part 1 of 3)

Just to step back a moment, this idea of a project plan isn’t specific to any one methodology and therefore I’m going to avoid using methodology specific terminology throughout.

The central point of Project Management is to ensure that you achieve your objectives within a predicted timescale and within, what is usually, a fiscally limited budget. To help visualise and document the project goals, checks and balances and the finally deliverable, we use a Project Plan.

Depending on the environment that you find yourself in, the Project Plan could be a simple Excel sheet or substantially more complex document inside MS Project Server or something in the middle.

Something to play with

I’m going to write this post based on the fictitious need to move into a new office for a number of reasons, your employer has already found a location that they are happy with and they’ve signed a contract with a landlord and now you’ve been asked to get things ready for a successful transition between an old office and a new office.

You’re going to need to identify suppliers, estimate timescales, work out a provisional budget, look for risks and mitigations. You’re going to need to understand who is available to you, who will make up part of your team, what skills they have, what they can manage, what you will have to hand off to suppliers, etc etc etc.

The bad news

Project Plans do not always tell you what you want to hear! Perhaps your target is to move by the end of August and you have a £200,000 budget, but when you start mapping everything out onto a project plan you can see that this is not achievable. Either you need more time or you need more resources (which cost money).

In some cases, this type of scenario will answer the question ‘Does the project make business sense?‘ perhaps the time/cost limits are hard and the business needs to back away from this project at this point. In most cases, the realisation that you’re not going to meet the expectations of the business often means that the business needs to offer some level of tolerance. Tolerance usually relates to cost, time or quality. A tolerance for an office move might be End of August + 1 week (+2 weeks with C-level sign-off), £250k ± £50k (+£100k with C-level sign-off).

Introduction to the Project Plan

At the most basic level, a Project Plan is just a list of tasks that you need to complete. This plan should show the order of tasks, the length of time for each task, and who is responsible for each task.

So fundamentally a Project Plan is used to detail how long the project will take and how much it is going to cost. But it does so much more. You can use a Project Plan to explain the project to other people, it allows you to move resources in order to meet goals (work allocation) and it is the basis for managing the project through to successful completion.

Planning builds on the basic human desire to break problems down into smaller easier to understand problems and tackling each one in turn (Decomposition).

1. Divide the project into component tasks, continue to divide component tasks into smaller and smaller chunks until you have a detailed list of what needs to happen in order to complete this project.
2. Estimate the length of time each task will take (this is probably the hardest step for new project managers).
3. Order the tasks into the right sequence (there’s no point having desks delivered before having the new floor laid, you’re just going to slow the floor fitters down).
4. Determine the people, the money and the other resources you need to do the tasks in your plan.
5. Check what resources are available and refine the plan to take account of this.
6. Review the plan, does it actually make sense? (Can you do it and should you do it?).

You may find that you go through a number of these steps multiple times before you have a finished plan. You may also find that breaking down the component tasks into smaller tasks is quite difficult.

Humans are actually very good at breaking down big problems into smaller problems quite naturally, if you decided to go on vacation to Iceland for example, you don’t merely turn up there, you plan what you’ll need (money and clothes), you find a plane ticket that meets your budge, the time window you want to head out there, you book a hotel or similar, maybe you hire a car to get around or book some excursions when you’re there, etc etc etc.

Breaking down a project into component tasks can be difficult, especially if this is your first time. What you need to remember is that the purpose of the plan is to create a structure whereby you can estimate costs and allocate resources in order to successfully deliver the project. You don’t need to know, or to detail, every step, you just need to detail that there is a step and that it is likely to take this long. Reaching out to your Project Team can be a real help at this stage as whilst you may not know how long it takes your networking team to build a new network, the team probably does have some pretty good ideas on how long it will take.

Milestones

In some situations, milestones will be required, perhaps by your employer, or perhaps as a result of some methodology that you’re following. In other cases, milestones are simply good ways of breaking down the overall delivery into smaller chunks which can not only help you understand how close you are to the project baseline but also offer your team the chance to celebrate many small successes along the way. Of course, we don’t want to celebrate everything, but certainly the important stages.

An important concept to remember is that a project plan is a live document, tasks can move around and frequently do, milestones however, should not. Milestones are useful for high level tracking and for communicating status to those outside of the project. If you have regular meetings with a Project Board for example, they will likely be interested in the milestones.

Another important concept to remember is that a milestone is not an activity, but a collection of activities.

In part 2 I’m going to talk about Estimating Time and Contingency.