No project succeeds without a plan. But remember, the plan is not the project. The plan is there to make the project work. As project manager, use the plan to get the work done; don't drift into acting as if creating and updating the plan is the same thing as doing the project. That attitude will stress you and probably kill the project. But like carbon monoxide poisoning or hypothermia, you won't know that you are suffering from that attitude until it is too late. So, for sponsors among you, watch your project managers and help them steer clear of this risk.
The project management plan consists of all the management plans and performance baselines established by the endorsed project management methodology. Note that the plan should includes baselines, where the type of project warrants it. A baseline is the initial budget or estimate for how long project activities will take and how much resources, including time, people and money, will be required. (See the 'PMI says' box for a fuller definition.) The reason for including a baseline is to ensure that progress against the plan can be measured. In some circumstances, such as projects that are not priorities and are very small, it may not be worth including a baseline, but as a rule, in a project of any size, a baseline should be included, though perhaps not in the initial version of the plan. As changes to the plan are approved, the plan may need to be re-baselined to reflect the changes. As project manager you should ensure that all key stakeholders know what the current baseline is. Avoid the situation, for example, where the project sponsor thinks that the baseline for the project is $1m of spend to go and deliver the summer after next, but the chief executive of the organization thinks that the baseline is half as much and delivery is twice as soon, because the chief executive is working to the old baseline.
The project management plan explains what the project is, why it is worth doing, and how it will work. The how part is the most important part of the plan, and is about how the project will be executed, monitored, controlled and closed. The project management plan includes outputs produced during the planning process of the project; that is, when you come to write the project management plan, you are not starting from scratch; there should be a number of documents you have already produced by that stage in the project lifecycle that form sections of the plan, for example the scope statement. These may need to be revised and updated in the light of new information which you have learnt since their last versions. Project management is an iterative process, or, more bluntly, it can be a constant struggle to keep on top of changes and keep the plan and reality close enough together so that you and the project team can do your job with the least possible stress.
The plan has two different purposes. It helps you and the project management team control and manage the project, that is, it is a control and management tool. It is also a communications tool, a means to communicate to key stakeholders what is expected of them in order for the project to be a success, and what they should and should not expect of you and the project.
What should the plan look like? What should be in it? This depends on the type of project. The fundamental principle to apply is to make the project management plan reflect the size, complexity, scope and risk associated with the project. A plan to sell mobile phones through athletic shops will focus on consumer behaviour, marketing and the risks of unsold goods and changing fashions. It will have quite a different structure from a plan to build, say, a new nuclear warhead, which will focus on risks of a different kind. Your organization may have templates for project plans of different kinds, and your organization may also mandate that certain sections must be included in project plans. For very small projects, the project charter with an added timeline or Gantt chart may be sufficient for a plan. What matters in a plan is that it will work, that the document that is the plan will enable you and the project team to deliver the project and to communicate the plan to stakeholders in a way that is acceptable to them. It is a mistake to take a template for one kind of project and apply it unthinkingly to projects of another kind. A Google search on the Internet should find a number of good templates for your kind of project. (Examples of project plans can also be downloaded from http://www.aldpartners.com/.)
The project management plan could include, among other sections, separate sections for the following:
Much effort is needed to integrate all these parts into the overall project management plan, and effort is expensive and takes up time. Project integration management is about avoiding unnecessary work by making sure you do only the things that are necessary at the right time. The unnecessary expansion of the project management plan complicates your job as project manager. Work out what sections need to be in the project plan, and make sure that you have them in the plan, but only them. What sections should be in the project management plan depend on the requirements of the particular project, the personal preferences of the sponsor and possibly other stakeholders, and the conventions and mandatory requirements of the organization in which you are managing the project.
The project management plan tells you and others how the project will be done, or, to use language currently popular which means exactly the same thing, how execution will happen. The plan describes what the project is and what principles it will follow. Much of this is unexciting, similar in a way to which side of the road shall we drive on, in that it may not matter which particular principles or approach is followed (e.g. whether project meetings should be on a Monday or on a Friday, or whether to use one software tool or another), but what does matter is that everyone in the project is driving on the same side of the road, so to speak. Much of the value of the project plan comes from setting out this kind of unexciting, but critical, detail. The plan also shows how the project will manage scope, time and cost. The direction given by the project management plan is to specify not only what must occur, but also how it is to be measured, controlled and completed.
It is not necessary to plan the latter parts of the project in as much detail as the early parts. Planning can, and perhaps should be, a rolling process. It often makes sense to plan in detail for the next phase of the project, and leave the plan for the subsequent phases as a sketch or as no more than high-level plans. The advantage of this is that it avoids wasted effort of replanning later phases as new information becomes available and changes affect what is required.
Once the plan is finalized, or nearly finalized, it is common to hold a project kickoff meeting with key stakeholders and the project team, to mark the start of the project and to go through the plan. This meeting is useful from an integration point of view because it is a means to communicate and coordinate matters concerning the project. Such meetings deserve careful planning, and the project manager and sponsor should together decide what they want out of the meeting. Possible aims include verifying risk management plans, building synergies with other projects, or selling the approach or parts of it to individual stakeholders who appear not yet to be fully bought in.
Project planning methodology
A project management methodology is defined as a series of project management process groups and their related processes. The control functions used are also part of the methodology which is then combined to form an overarching approach to the project. The methodology followed by a company could apply a formal set of established project management standards, or it may decide to tailor the processes in a more informal way to suit the project needs. A formal or informal technique can be used, as long as it assists the project management team to develop an effective charter and project management plan. The methodology used is therefore a key input as to how many of the processes will be conducted. The selection of methodology will first be reflected in the project charter.
The three most important things in project planning are to:
Chapter 5 says more about scope and WBS.
The biggest mistake in project planning is to start with a Gantt chart. Gantt charts are excellent tools, but can be very dangerous if they are used without first doing a WBS.
Benefits of planning
The benefits of planning should be obvious, but in the real-life pressure when stakeholders may pressure you to cut back on planning time and instead 'get on with real work' you may find it useful to remind yourself, or them, that planning is real work. Here are some benefits of planning:
How to plan
How to plan varies much from organization to organization. Increasingly the project planning process is becoming standardized and controlled, and runs on software packages and intranet sites. However, some of the main ideas used are:
It is worth understanding how these things relate. None of the others make any sense unless you have first defined activities. Likewise, for Gantt (timeline) charts or PERT (network) charts to make sense and not to be sources of major risk, it is necessary first to have a work breakdown. Gantt charts, also known as timelines, show elapsed time most readily, and PERT (network) charts show dependencies. You can manage projects without understanding how these things relate to each other and why, but you will have a much easier time and a greater chance of success if you ensure that you understand this and work accordingly in planning your project.
Figure 4.2 shows a very simple Gantt chart for a small project, while Figure 4.4 later in this chapter on page 116 shows a Gantt chart for a much larger project. Figure 4.2 shows how lines can be added to a Gantt chart to show dependencies, but if your aim is to show timescales, then you may wish to minimize clutter by not adding them. A major problem with most graphical representations of projects is the clutter in them.
Figure 4.2. A Gantt chart showing dependency relationship
An activity is a 'component of work performed during the course of a project' (PMI PMBOK Guide (p.350)). An output is the result of an activity or task. It is vital to distinguish between the activity and its output, but it is easy to get confused because activities are often named after the outputs they are intended to produce. Shelling peas is an activity: the bowl of shelled peas is the output. The distinction is important because the arrival of the outputs is the signal that the activity has finished and subsequent activities can begin, subject to the outputs meeting quality standards (that is, being fit for purpose). If the outputs exist and are complete then it is easy for the project manager to know the state of progress on an activity (it is finished). But if the outputs do not yet exist then the project manager must assess how much work remains to be done on the activity, and there is usually much more uncertainty in such progress estimates.
A key concept in project planning is activity duration, which is the time required to complete the activity. Durations can be fixed or variable. A fixed-duration activity takes a fixed length of time from start to end, no matter how much effort is allocated. For example, lead times on specialist equipment might be six weeks, and it will remain six weeks whether we allocate one person, 100 people or nobody at all to wait for it to arrive. Variable-duration activities can usually be shortened by allocating more people to do the work. An example of a variable-duration activity is painting a wall: theoretically, we can halve the time required by doubling the number of painters. Now consider digging a hole. We might be able to also halve the time to dig the hole by putting more people in the task, but if the hole is narrow and deep, there may be room for only one person in the hole.
This simple arithmetic for variable-duration activities is appealing, but it is unwise to try to apply it simplistically to most real projects. Imagine that you had been asked to manage a project to cook dinner. Some activities are fixed duration (cooking times in the oven), but some tasks are variable duration. How much shorter would the dinner project be if you were allocated a team of 10,000 people to help you? Of course, it would take many times longer than if you had a team of three, because you would have to spend so long breaking down the work so that everyone got to do something, allocating tasks, coordinating and supervising. This is why project managers know that trying to speed up a late project simply by adding people will slow it down further. Adding resources can sometimes help, but it must be done intelligently.
People assigned to work on a single activity together must talk with each other and coordinate their work. With only two people on the activity this is a relatively small overhead, but as the number of people rises, everyone must spend more and more time just negotiating with their activity colleagues, and soon very little activity-related work is being done. It is this need for coordination and communication that means every person added to an activity adds slightly less than one person's worth of effort, and also degrades the effort available from those already assigned. This is one reason why it is so important for the project manager to plan projects so that self-contained activities can be allocated to individuals in such a way that everyone knows the exact scope of their own work, there is a minimum number of multi-person activities, and communication overhead is kept to a minimum.
Project planners use some words in specific ways. The word effort usually means the number of hours or days of work involved in a task or project. It is often measured in man-days. Effort and duration are related but must not be confused. An activity could involve four hours of effort but have a duration of a week if the work is spread across several days or it is a fixed-duration activity. Ten days of effort could be finished after only three or four days of elapsed time if three people share the work though, for the reasons outlined above, they might put in 11 or 12 days of effort, which consists of 10 days of work and two days of coordination time.
Another favourite word of project planners is resource. Resources are the people, infrastructure and equipment that are made available to the project by the firm. Resources are anything that could be used elsewhere in the firm and that should be booked to make sure that the project can use them when needed. This definition includes things like meeting rooms or project rooms, but by far the most important resources on any project are people. All projects rely critically on their people resources, and it is important to book people for the project in good time, whereas it is often safe to leave planning for things like meeting room access until the last minute. For this reason, many project managers who talk about resources mean people.
During planning, the planner estimates task duration and effort using skill and experience. However, once work is executed, the duration and effort actually required may be different from what was in the plan. Hence we distinguish between planned and actual effort and duration.
Work breakdown structure (WBS)
A work breakdown structure is the easiest place to start with project planning. Creating a WBS will also help you to define the activities defining activities and creating a WBS are often best done in parallel. A WBS is no more than an enhanced list of all the activities of the project. The enhancements explain how the project is broken down into tasks, groups of associated tasks and sub-projects, and they also give some information about effort or duration.
You may find it convenient and useful to represent the levels of the project breakdown graphically as well as by using the levels of indentation on the work breakdown structure list. This can be done easily by drawing the project structure as a hierarchy of tasks and sub-tasks, as shown in Figure 4.3a. Activities which together constitute a logical sub-project or phase are listed together in the work breakdown structure, under the appropriate sub-project title.
Figure 4.3a. Example work breakdown structure (WBS) for 'House Build' project
Each activity at each level can always be broken down further, so that it becomes itself a title for a group of constituent tasks. The overall breakdown of the project into phases is given by the first level of titles, and under each phase title, the major blocks of work are listed, each with its constituent tasks. This process of breaking down tasks into ever-finer levels of sub-tasks can continue indefinitely, and it is sometimes helpful to explore what goes on inside activities in this way in order to make sure that we really understand how much work is involved. However, it is also easy to get carried away with this process and end up with a structure with dozens of levels, the lowest of which describe tasks equivalent to 'stand up' and 'open door', as illustrated in Figure 4.3b.
Figure 4.3b. Example of excessive detail in a WBS
It is extremely unlikely that there will be any value in taking the analysis to this level (the exception may be in generating formal work instructions for standardized factory-like processes, but these do not really fall within the scope of an overall project plan). The task breakdown should be taken to the level where individual tasks for individual people (or for a group that works together) can be identified, with a clear explanation of all the necessary inputs and outputs. In practice, even very large and complex projects do not usually need more than about six levels, and most projects can be satisfactorily represented on three or four.
Once the list has been created, we can estimate the time required to do each task and write it next to that task (see Figure 4.3c). The times used should be the effort required for each task so that the total effort required for the project and each sub-project can be calculated simply by adding the column total. It is also useful to record task durations, especially since these will be needed when turning the work breakdown structure into a Gantt (timeline) chart. Durations should be in a separate column from effort to avoid confusing the two. Durations can be entered directly if they are fixed durations, or they can be calculated from the relationship between the effort required and the allocated resources.
Figure 4.3c. Example of completed WBS, showing effort and duration in days (d) or weeks (w)
It is conventional to give each task in a work breakdown structure a number or other identifying code so that it can be identified in summaries.
Most project planning software packages can produce work breakdown structures, group tasks together into high-level blocks, and let the user enter effort, duration and resourcing information. Task identifier numbers are usually added automatically.
A work breakdown structure is a convenient way to record and group the blocks of work that will make up the project, but it does not contain information about dependencies between tasks, or task sequencing. There is no way to record the fact that task X cannot start until task Y (which is part of an entirely different sub-project) has finished. It tells us how much total effort will be involved, but it does not tell us how long the project will take since it does not tell us which tasks must follow from each other.
Once we have identified the tasks and how long each will take, it is a relatively simple step to add some information about the sequence in which tasks must happen, so that we can get some insight into how long the project is likely to take. For each task, identify the other tasks that provide its inputs and which therefore must be completed before this task can begin. For example, we cannot usually test a solution until it is built, we cannot build it until it is designed, and we cannot design it until the user requirements are known. In project planning language, testing depends on build, which depends on design, and so on. This chain of dependent tasks gives us the first indication of how long the project will take.
Product breakdown structure (PBS)
Sometimes it is useful to do a product breakdown structure (PBS) of the project's product, either to understand the product better or as a way of getting at the work breakdown and tasks necessary. The concept is the same as for the WBS, but the product rather than the work is decomposed.
Table 4.2 gives a product breakdown structure for a sailing boat.
PERT charts, also known as network diagrams or dependency diagrams, are covered in more detail in Chapter 6, Project Time Management.
Gantt charts (also known as timelines)
A Gantt chart starts with the list of project activities in the same format as the work breakdown structure. In line with each named activity we draw a box on a timeline to show when the activity is planned to start and finish. Project planning software packages will do this automatically from the information entered into the work breakdown structure. If you don't have a software package specially for project planning, then a spreadsheet such as Microsoft Excel will do a perfectly reasonable job as Figure 4.4 shows. Your Gantt chart should show tasks in the right sequence, which you can get from your WBS. Dependencies between tasks can be shown on a Gantt chart with an arrow that links the end of the first task to the beginning of the next, as Figure 4.2 on page 109 showed. Chapter 6, Project time management, says more about dependencies and representing and planning with them.
Figure 4.4. Project Grapple Gantt chart
Top of Page