Project Management Book

Chapter 7 - Planning

Planning who will do what when - or scheduling as some purists would insist - is fairly straightforward if you have a team of two people. But with a team of a hundred people it can be difficult to work out who will do what and to get it all to interlock neatly. But get the plan right and your projects should run like clockwork and before long your colleagues will be saying you're the one who always gets the easy projects to manage.

There is a big difference between planning small projects and planning large ones. For a small project a back-of-an-envelope plan may suffice but this won't work for large projects (unless you have a very large envelope).

Every member of a project team has a right to expect it will be clear to them which tasks they will perform, when each task should be done and what each task should deliver. In a two person project the project manager can easily plan the work for the two team members. But in a hundred person project there is no way the project manager can personally produce the work plans for every team member. On these larger projects we will need to employ team leaders to produce the detailed work plans for their teams.

In a large project the project manager will not be interested in the thousands of individual tasks in the plan: we need to find some way of summarising the project plan, and progress against it, for the project manager. And for the project sponsor an even more summarised plan is needed, maybe just showing the resource profile and key milestone dates. But what the sponsor sees should be no more than a summary of the mass of detail that will be required at the working level in a large project.

Good plans:

• help make best use of resources - a bad plan can mean people sitting around with nothing to do because something they need hasn't been produced yet.
• show each team member what they must do and when.
• include everybody who has some work to do in the project - there is still a tendency among IT people only to show IT people in the project plan. The plan must include everyone: in principle if someone only has one 1 hour task in the whole project they should be shown in the project plan.
• are visible and intelligible. It is very reassuring when you walk into a project team's working area and up on the wall is a whiteboard across the top of which is a calendar of week-ending dates and down the side the team members' names and in each week some indication of what each person will be doing in that week. Why is this reassuring? If the plan is that visible and that public everyone will have critiqued it and pointed out the errors and it will have been changed so that it is now a viable and realistic plan. By contrast you get very nervous when you see a plan that you can't make head nor tail of and very nervous indeed if no-one will show you the project plan: what are they hiding? Have they even got a plan? The plan must leave nobody in doubt about what they must do and when.
• are agreed by everyone mentioned within them. Some team leaders get everyone to sign the plan to evidence the fact they've seen it and think they have a fighting chance of achieving their part of it.
• lead to better quality deliverables - put the other way around, will a badly planned, chaotic project deliver good quality? It's less likely.
• take time and expertise to produce - planning a large project is quite an art.
• are revised as the project progresses.
• are a key factor in project success. Good plan, successful project: pay rise and promotion for the project manager. A bad plan can lead to a great deal of stress during the project.

Stage planning and task size

Imagine the project on the right is a year long. At the project definition stage is it possible to plan the whole year out in detail, task by task? No. How far into the future is it possible to plan in detail? Perhaps a few months. This is one reason for breaking the project into stages. So, in the project definition stage we only produce a detailed plan for Stage 1 and a high level overview plan for Stage 2. Which implies that one of the tasks in Stage 1 will be a task to plan Stage 2 in detail. One of the deliverables from any project stage is the detailed plan for the next stage (assuming there is one).

When building the detailed plan for a stage, how large or how small should each task be? If you could choose, what would be the ideal task size? One hour? One week? Six weeks long?

If each task was one hour long there would be a vast number of tasks and you'd never keep track of them all. And what would be the problem if the tasks were all six weeks long? You'd never really know where you were. Tasks would be started and open for weeks and it would be difficult to gauge how far through they were. Overall progress would be hard to assess.

Ideally each task would be about a week long, about 30 hours work. In practice some tasks will be bigger than this and there will be some very small ones. A good sniff test of a stage plan is to see how many hours it includes, divide by the number of tasks to get the average task size. An average around 25 hours suggests the plan has about the right level of detail. An average much smaller and there are probably too many very small tasks. An average much bigger than that and there probably isn't enough detail in the plan.

Avoid long thin tasks. A task may be only 10 hours work but if it's spread over 10 weeks it can cause control problems. Ideally no task will span more than two or three calendar weeks.

Each task should have an unequivocal end point: the meeting has been attended; the test case has been written; the object has been successfully tested.

Each task must be assigned to one person. If four people will attend a meeting there will be 4 tasks in the plan - one each.

The above guidance, however, only applies to what we might call 'real work' tasks. Plans, certainly for larger projects anyway, will contain two other sorts of tasks. Tasks that are fixed in time such as a team meeting every Monday morning 9am - 10am and control tasks that span the whole duration of a stage. For example, a team leader may have no 'real work' tasks to do, he just controls his team. His control task will be as long as the stage. In a small project it's all real work, but in very large projects there could be multiple layers of team leaders and sub team leaders who just control others.

So there you are at the beginning of a stage and on your desk is a very large but blank piece of paper - except at the top where it says 'The Plan'. How do you go about transforming this blank piece of paper into the plan for the stage? Where do you start?

1. Understand what must be delivered from the stage. It is surprising how often people do not think this through and thus miss deliverables. If we're planning Stage 1 the deliverables might be the requirements document, UFD, Stage 2 plan, etc.
   
   
2. On another piece of paper, write a very long list showing every single work task that will need to be done during the stage. Referring to past projects and standards will help. Team input could be very valuable.
   
   
3. Estimate, in hours, how much work each task will take. Bear in mind the number of hours will depend upon who does the task.
   
   
4. Put week ending dates across the top of 'The Plan' and your first cut of who will be in the team down the left hand side then shade out the time people will not be available to work on the project: Christmas, public holidays, holidays, courses, etc. (If someone says they're not sure when they're having holidays don't fall into the trap of putting no holiday in their plan! Guess when they might take it.) Allow for their non-project commitments and commitments to other projects.
   
   
5. In another colour as it were, shade out time for 'investments' such as team leading, coaching, orientation and meetings. Allow time for handling change requests and contingency (see below).
   
   
6. Having allowed for everything that will prevent each team member from doing 'real work' tasks, we can now turn to that list of 'real work' tasks and start the tricky business of trying to fit them into the remaining white space. This could take a lot of time and have you tearing your hair out, but stick at it. You will very likely have to add or subtract people and/or adjust the end date you were aiming for. Involve the team in this planning activity.
   
   
7. The stage plan is beginning to take shape. You now know when you will need people who are owned by other managers. You may have vague resource promises from Directors, but now you can be quite specific with people's direct managers about when you will actually need their people. We will consider how best to formalise resource agreement in the chapter on stage agreements.
   
   
8. When you believe the plan is finished, get the team together and present the plan to them line by line, task by task. Will the team find errors in your perfect plan? They will. A bit embarrassing, but better to be embarrassed one Friday afternoon than to spend the next six months having a slow motion nervous breakdown.
   
   
9. In some companies there would now be a rule that for a large project the project manager must spend an hour or so running through the plan with project support. Project support do what they can to make sure the plan seems to have been put together properly. Project support can't second guess whether the plan is complete and correct and achievable, but if someone presents a plan to you it is usually pretty obvious whether it's at the right level of detail, clearly assigns tasks to people, includes contingency, etc. and seems to have been properly thought through. (As we shall see in a later chapter, the project support person is a peer project manager who has been there seen it and done it and they'll know whether the planning has been done properly or not.)
   
   
10. Record your plan in a tool such as Prima Vera or Track-It or Microsoft Project. We have not mentioned tools earlier for a good reason. So often team leaders get sent on an MSP course, come back and are then asked to plan a project. They open up an MSP plan and, brain totally empty, expect the plan to appear by magic on the screen in front of them. There are two totally unrelated skills at play here: one skill is knowing how to plan a particular type of project and the other completely unrelated skill is knowing how to use MSP. You could be the world's best novelist yet completely unable to use a wordprocessor. Equally you could be a Microsoft Word expert but unable to string an intelligible sentence together. Some project managers would even forbid a novice team leader from using any planning tool on their first project: make them plan on a large piece of paper and track that way too. Then they find out what planning is really all about and on their next project understand how a tool like Track-It can actually help them. Whatever you decide, avoid novice planners getting lost in the tool and losing sight of the real job: building a viable plan.

...next

Privacy Policy and Cookies