Professional project managers have a huge set of tools, a vast set of jargon, and usually some helpful experience to produce plans. The work to produce the plan for a major programme of work requires skill and expertise, but the fundamental activities in producing a plan are not that complex and are easy to apply for reasonable sized projects. Planning builds on the normal human approach of breaking problems that are too large to resolve in one go into smaller chunks, and this process is called decomposition by project managers.

I am first going to define the logical activities in producing a plan, and then I shall describe how to create a plan in practice. The six activities in producing a plan are to:

1. Divide the overall project into its component tasks, and continue to divide the component tasks into smaller tasks until you have a comprehensive list of things that must be done to complete the project.

2. Estimate the length of time each task will take.

3. Order the tasks into the right sequence.

4. Determine the people, money and other resources you need to meet this plan and determine their associated costs.

5. Check what resources you actually have available and refine your plan to take account of this. Once you have done this you have a complete plan.

6. Review the plan – does it match your needs? Looking at the plan – can you actually do it, and should you do it?

The six activities are shown here as a simple logical sequence. In practice you will go through these activities several times before your plan is in a state you are fully happy with. Before you start to develop your plan, I introduce these topics in some more detail.

The component tasks and milestones

Breaking big activities into component tasks is something we all do all the time. Whether it is as simple as planning a trip to London – thinking about the three tasks of driving to the station, taking the train to Paddington, and then using the Underground to the final destination – or a complex activity that breaks into hundreds of tasks, decomposition is something we all do naturally. However, in a project it is generally more complex than the activities you are familiar with on a day-to-day basis. Breaking down a major project into the relevant tasks requires lots of thinking and effort. Determining the task breakdown enables you to bring any experience to bear, whether it is your own or anyone else's familiar with the type of project you are planning.

One of the problems for people new to project planning is what level of detail to go to in breaking tasks down. This is a subjective judgement and there are no hard and fast rules, but remember the purpose of the plan: you are not defining a detailed step-by-step instruction for carrying out each of the tasks in the plan, but a structure you can use to estimate times and costs, allocate work to people, and manage delivery. The questions to ask once you have broken your work into its component tasks are:

• Is it enough to help you manage the work?

• Does the detail help you estimate and schedule the project?

If your project lasts any length of time, especially if it is over a month and you are inexperienced, it is helpful to add some milestones. Milestones are points in a project that identify when you have completed an important stage of the project. Once you start to manage a project, you will find that the detailed tasks tend to shift around – the milestones should not.

They are useful to track progress at a high level and to communicate to people outside of the project; in other words, to understand where you are in project progress without knowing all the details. They are not activities in their own right, but reflect the completion of a series of activities and the production of some key deliverable. One milestone a month is a good rule of thumb.

Estimating time

The part of planning that people find the hardest, and which they often get stressed doing, is estimating how long the project will take. Accurate estimating is difficult and most people are simply not very good at it. The first thing to understand is that whilst it is helpful for your estimates to be as accurate as possible, don't try to make them perfect. They are inherently uncertain as they are a judgement about the future. If you try to make them perfect you will spend more time estimating than doing anything else on your project. Estimation is as much an art as it is an accurate science – and is best done with experience of doing similar tasks before.

The next thing to clarify is what you are estimating. Your estimates should be the effort it takes to do a task, not a guess as to how long it will take before you have completed the task (which is the duration). This is a subtle but critical difference. The effort is how much time you must spend working on something to complete it.\

The duration is how long it takes you to get around to doing it. It may, for example, take you one hour to read a business report (the effort), but if you start reading it, then go off and do something else for four or five hours and then complete reading it, the time to actually complete the task from starting will be five or six hours – this is the duration. In planning you should only be interested in the effort to do the reading – one hour. The beauty of planning is that the duration will be derived automatically when you look at the sequence of events you need to do in the project.

The next thing about estimates is that they should be a judgement of how long a task takes normally. What is a reasonable length of time to do it in? Most tasks take different lengths of time in different situations. For example, it may take you typically two days to read a book if you sit down and read it end-to-end without interruption – but some books will take half a day, and some may take four days. If I ask you how long will it take you to read 100 books, you may think – well anything between 50 and 400 days. When planning use the average time at two days per book; this gives a total for 100 books of 200 days. You may be thinking, but doesn't that mean I risk running out of time in the project? Yes, but this is dealt with by something called contingency, which will be explained later. In practice when people are asked for estimates, they often give the maximum time a task takes. But if you do this, your plan will stretch out for much, much longer than the project will really take.

The unit of time being estimated depends on the size and scale of the project. You may estimate in terms of hours, days, weeks, months or years. The units of estimation can be man-hours, man-days, man-weeks, man-months etc. – where a man-hour is the amount of work one person can do in an hour, a man-week is the amount of work one person can do in one week and so on. In practice estimating to man-days is normally sufficiently accurate for a small to quite large project.

Estimating to man-hours usually just gives a spurious feel of accuracy. In fact, if you are doing this, you have probably gone into too much detail in your task breakdown. For larger projects man-weeks, or just possibly man-months of effort are usually sufficient. Man-years are normally never accurate enough!

But what if you really don't know how long a task will take? There are many specialist ways of estimating task durations, but essentially you have five options:

1. Ask someone who does know. This is the best option. Experience is usually the best way to estimate.

2. Use any available rules of thumb. For instance, if it takes about 1 hour 15 minutes to install a PC on a desk, someone can probably install about six a day. To install 100 will take about 17 days for someone allocated full time to this task.

3. Model it against other similar tasks. If you don't know anyone who has done this, have you ever done anything similar? How long did that take?

4. Break the task down further until you get tasks you can estimate. Such an approach works in situations in which a more detailed breakdown gives clarity. However, if you are getting to a set of tiny tasks that each take an hour or two, you are going too far. To an extent, by breaking down tasks into smaller chunks, you make estimation easier. However, at some stage you have to make an estimate, and guessing the length of ten small tasks is inherently no more accurate than guessing the length of one big task!

5. Make an assumption. At this stage an assumption is nothing more than an educated guess as to how long it will take. If you have no better information, do this.

Having planned your tasks and estimated their lengths, you can create a first-cut plan. However, you may be concerned about errors you have made in planning. You may also be concerned that in real life things may go wrong – how do you deal with this? You deal with this by setting aside a pot of money and time that you will try not to use, but will resort to only if there are problems. This is called contingency. The amount of contingency you set aside depends on how risky the project is and how much experience you have of doing similar things.

For low-risk projects, doing things you are familiar with, a contingency of 10 per cent for time and money is normally enough. For higher-risk projects, you may want to leave a contingency of 20–25 per cent, and for very high risk and unfamiliar tasks it may be 50 per cent or more. You may think – isn't this just cheating or a sign of poor planning on behalf of the project manager? No, it's not.

Contingency will not be used unless it is really needed, and it is there because a good project manager knows he or she cannot predict the future with 100 per cent accuracy, especially for a high-risk or unfamiliar task.

The importance of contingency also depends on what happens once your project is finished. If it is a personal project and it does not really matter if it is a little late, or over budget, and you are using project management simply because it is a complex task and you want to be sure it gets done, then you do not need to worry about contingency. If, however, it is a critical project, that once you have completed someone else will immediately start some major business initiative, you want to be sure that the date you give as the end date is achievable. This requires giving yourself some buffer in the form of contingency. Having such a buffer is not being over-cautious, it is sensible management.

Ordering the tasks

If your project breaks down into 100 tasks you can, in theory, start all 100 tasks at the same time, and the project will take as long as the longest task. There are two problems with this idea:

• There are dependencies between some tasks.

• People can only do so many things at a time, so tasks have to wait until people are free to do them.

A dependency is a link between activities, which means that they can only be done in a certain order. For example, for me to drive my car I have to put petrol in it – the task of driving is dependent on the task of filling up the petrol tank first. There are many forms of dependency, but in practice the only one you need to think about is the predecessor dependency. What tasks have to be completed (or started) before another task can be started? These are shown on your plan as predecessors.

One specific type of predecessor you need to be aware of is an external dependency. This is a dependency on a task that is not being done within your project or under your management. For instance, consider the situation in which you are running a project to design and build some new houses, and you are not involved in buying the land to build them on or in getting planning permission for the building.

All the tasks involved in selecting and buying land, and applying for and gaining planning permission are outside of your project and will not appear in your Project Plan. However, you still have a dependency on them – you cannot build without the land or the planning permission – and so the order of your tasks has to at least acknowledge when the necessary external predecessor tasks are complete. (The external dependencies should have been identified in your Project Definition.)

When you review your plan, you can find tasks that you think 'Oh, I can do half of the task and then I need to wait a week whilst something else happens before I can complete it.' Divide such a task into two parts. A good example of this is when you have to order something from a supplier. If your project requires you to install new screens to all the PCs in an existing office, you will have a task to install the new screens which is dependent on the supply of new screens.

As part of this task, you will actually remove the old existing screens as well. You cannot install the new screen until you have received them from your supplier, but you could remove the old screens. Split the task into two halves. The first half of the task (Remove the old screens), can be done straight away, and the second half (Install new screens) waits until the completion of the predecessor task (Supply new screens).

It is important to differentiate between, on the one hand, tasks that have been ordered because they have predecessors and, on the other, tasks that are ordered to take account of the availability of people to do the work. In the latter situation a project can sometimes be speeded up by using more people, whereas in the former it cannot.

You may think simply adding more people will always speed up your project. It may do, but beware as not all tasks can be broken into many pieces for different people. This is shown by the project management aphorism: 'It takes one woman 9 months to have a baby, but nine people cannot have a baby in 1 month.' No matter how many resources you throw at having a baby, it cannot be done any earlier than 9 months. Also be aware that as you add more people, it becomes more complicated logistically and takes more time to manage them.

The people in your project team

Once you have a task list you are in a position to identify who you need in your project team. In practice, you probably had a good idea of who will do the project work prior to completing the Project Plan. However, it is essential you get the right project team. Without the right team, no matter how good a plan you have, the work will not get done. When choosing the people to work on your project, consider six things:

1. What skills are required – and what skills do the people you are choosing have? You are looking for a match between your needs and the skills of the people chosen.

2. How many people with each type of skill do you need?

3. Which people have these skills?

4. Are they available? It is no good trying to run a project with people who are 100 per cent busy on other work.

5. Can you afford them? People usually do not work for free, and different people usually are paid different salaries. If you have to pay for people from your project budget, can you afford the people you have chosen?

6. Do they have the right attitude? This is often forgotten, but you do not only want people with the right skills available and affordable for your work, but ideally you want people who want to be involved in your project. A person who wants to be involved and is energetic and excited by the work will often produce more than a nominally more highly skilled individual who is not interested.

As the project manager, you are also a member of the project team. Do not under-estimate the work of managing the project. On a small project you can be a part-time project manager and also be allocated some of the tasks in the plan. On a large project, the job of managing the work will take 100 per cent of your time – you will not have the time to be doing any of the individual tasks as well.

Dealing with costs

The costs of a project fall into two main categories:

• Costs associated with doing the work on the project. This is usually mostly people's time working on the project. It may also include things you have to buy or rent to do the project. For example, you may rent a room for a couple of months for the project team to work in, and may want to buy a copy of some project management software to help you run the project.

• Costs associated with things you must buy to create the deliverables. For instance, if the project is to do with building some houses, this would include cement and bricks; if your project was to develop a new computer service, it would include buying PCs and software.

I am not going to deal with the accounting treatment of these costs as it is not relevant to project management. However, it is helpful to identify variable costs that depend on how much of something you use or buy, and fixed costs which you have to pay irrespective of how much you use. To calculate the cost, identify all the variable and fixed cost elements.

The budget you need for a project is the total of the costs of all of these elements. Some organisations do not allocate the cost of staff time to the project. In the detailed example I provide below, I have charged people's time. This is good practice as it forces you to make sure that people do things in the time you expect of them. If you are charging staff time to your project, don't forget to include your own time as project manager.

Usually some costs are known or can be easily looked up, such as the cost of a PC. Other costs need to be estimated, and most of the same principles used for estimating time hold. Where possible ask someone with experience. Where this is not possible, you must make an assumption and estimate the cost to the best of your ability. The more you need to guess costs, the more risk that the budget will be wrong, and the more contingency you should have.

Thanks