Project Management Book

...chapter 7 continued

Tools

The best planning tool of all? Book a conference room. Lay the tables in a line almost corner to corner. Get a roll of plain wallpaper and lay it out along the tables. Draw lines across the roll every foot (30cm) or so to delineate weeks and write in week-ending dates. Get the team in the room, write each task on a Post-It note and have fun planning the project stage by jigging the Post-Its around until it all fits together. Roll the plan up, put it on the office wall and track progress against it using different coloured Post-Its.

We have nothing against MSP or other tools, only the tendency for them to get in the way rather than aid the planning process. Indeed, a good tool is a great asset for larger projects as we shall see in this chapter and also in the tracking, controlling and reporting chapter.

Part Timers

Have you ever had someone on your project team who was assigned for, say, 50% of their time to the project? They can be difficult to manage - you never really know when they're going to be there. Instead of nominally 50% all the way through try for something like this: you have them full time in week 1, nothing in week 2, full time in week 3, etc. Or even full time on Monday, nothing on Tuesday, etc. It is definitely worth the effort if you can get this sort of arrangement.

Critical path

If a task on the critical path slips, by definition the end date slips. Try and avoid one person in the team having all the critical path tasks in their plan and all the pressure therefore heaped upon them.

Having said that, relatively few tasks in software development projects will really be on the critical path. If you're building a block of flats the bricklayer can't lay the bricks for floor 2 unless floor 1 is there. Things have to be done in sequence. But in a software project you can write the programs in any order you like: the writing of program 2 isn't dependent upon program 1 having been written. Milestones like handover to system test are about as close as you get to a critical path task - if that slips the end date may well slip. Tools such as Microsoft Project (MSP) lay great store by their critical path analysis capabilities but these are much less relevant to planners of software projects than planners of construction projects or planners of large IT hardware projects.

How long does it take to plan a project stage?

Suppose you were planning a project stage that was 5 weeks long and employed 2 people. With the aid of that envelope it might take you an hour or two to get the plan done.

But the next stage you are asked to plan is 5 months long and will employ 30 people who are owned by 10 different managers. Can that be planned in a couple of hours? No chance! This could take more like 6 weeks. Say it's mid March and the stage will begin on June 1st. You approach one of those 10 managers and ask provisionally for one of his staff full time for June. And he says yes. You ask manager 2 for a body for July and he says yes too! This is going to be easy. You ask manager 3 for a person for August but he says that person is on holiday in August, but by chance has nothing to do in June - could you take him off his hands? So you go back to manager 1 and see if you can switch his guy from June to August...

You can see that by the time you have been round ten managers - who usually won't give you quick answers - and round again, and round again - six weeks can very quickly zip by. This is not 6 weeks full time work, it is spreading the planning out over that period. But if you start early enough, by the time you get to June 1st you should have firm resource commitments in place and people should then turn up when you need them. You will then find that when you finish the project everyone will say how lucky you were - everyone turned up by magic when you needed them. It's an old adage, but: the more you plan the luckier you get. You really do make your own luck in projects.

There is only one snag with this. Suppose a critical business need pops up from nowhere. A project involving 30 people owned by ten managers must start on Monday morning - you've got 3 days to plan the project, not 6 weeks. What would you do (other than panic)? You might ask the sponsor to tell those 10 managers to come to an all day meeting tomorrow and you might ask the sponsor to attend and bring his baseball bat with him to help you extract the resource commitments from those 10 managers. This will require some quick outline planning by you before the meeting and a lot of tidying up afterwards - not to mention removal of blood from carpet. Planning a large project can be done in a short time, if painfully, but if you have 6 weeks take 6 weeks.

Change and contingency

We mentioned above the need to put change and contingency into the plan. But where in the plan should they be put?

Imagine we are planning a 10 week long user functions design step. Let's say we have decided that 10% of all the hours will be spent investigating and implementing change requests. (Change requests will be fully considered in a later chapter but to give an example: half way through the UFD step the users want to alter their (signed off) requirements, so they raise a change request.) Those 10% of the hours must appear somewhere in the plan, but where? We will consider two extreme options.

Option A would be to spread the hours out evenly, i.e. assign to each team member 10% of each week - which is half a day - for dealing with change requests. Their plan would therefore have 4.5 days work each week with, say, Friday afternoon set aside in case a change request comes along. The last task in each team member's plan is scheduled hard against the committed end date of the UFD stage.

The other extreme option would be to put those 10% change hours at the end of the UFD plan. 10% of 10 weeks is 1 week, so each team member has contiguous tasks for 9 weeks with the last week showing as reserved for handling change requests.

Which extreme do you think would be better? Before you decide, there is one important condition. Even if all the change time is at the end of the UFD plan this does not mean that all change requests are left to pile up until the tenth week. If a change request arrives in week 1 it would be given to a team member to deal with straight away, and of course all his planned tasks would shuffle along a bit to make way for the 'deal with change request' task. With option A, where half a day is left for change each week, perhaps only two or three tasks have to move along to make way for the change task.

There are good arguments for both extremes but if forced to choose one or the other we would go for option B - all the change time shown in week 10. Why? Option A has half day gaps all along the plan. If no change request comes to fill a team member's half day gap at the end of week 1, will he start his week 2 task early and get half a day ahead of schedule? Everything is possible, but the risk is he won't. People usually work to whatever they perceive to be each task's deadline. Those carefully planned half days for change will just evaporate away, and when the change requests do arrive guess what? We haven't got the time to handle them. With option B that won't happen: everything else being equal, that last week that's reserved for change is going to be there until you choose to use it.

Luckily in practice you do not have to choose one of the extremes. What might trigger the users to raise requests to change their requirements during the user functions design step? When the users see prototypes of screen layouts and dialogue flows what happens? They will say things like: "Er, which screen is the discount code entered on?" And the designers say: "Discount code? What discount code?" And the users say: "Oops, we left that out of the requirements." Result: one change request.

Strange though it may seem one can often predict when change requests may be raised, often coinciding with things such as prototyping, reviews and sign offs. Why, therefore, might there be a mini change surge in the first week or two of the UFD step? The users are focusing their attention on the requirements document and, one hopes, signing it off. Strictly speaking it's debatable whether a change to the requirements document prior to sign off is actually a change request or error correction - either way work to change the requirements document is likely.

So, plan the change time when you think change requests might arrive and if in doubt put the change time at the end of the stage plan, with maybe a little bit of it spread all along for those few change requests that will dribble in.

In addition to the 10% for change, the sponsor has agreed that a further 5% of the effort/budget can be set aside for anything unexpected that crops up - in other words contingency. Whereabouts in the stage plan should the contingency be located? At the end. So the last 3 days or so of the UFD plan simply says 'contingency'. The UFD stage plan now has two end dates: the one the project manager has committed to the sponsor and one three days earlier which will be achieved if nothing crops up to use the contingency. Should you show both end dates to the project team? YES. Put the plan up on the wall and make it clear to the team that while you have committed the later date to the sponsor their target and their commitment to you (upon which their appraisals depend...) is the date 3 days earlier. Only if and when something crops up that you didn't expect will you, the project manager, raid contingency, create new tasks in the plan, reset the team's targets and move their earlier date a bit closer to the date you committed to the sponsor. In this way you can be honest with the team about the contingency but avoid Parkinson's Law: work expands to fill the time available for its completion.

Have a look at the picture on the right. If you see a plan with the change and contingency effort distributed a bit like this it is quite reassuring - the planner has thought about it. They have put the change effort in the plan when they think change is most likely to arrive and they've put contingency at the end. The picture represents a stage, the area above and just to the right of the green line is change effort, the red slice is the contingency. We might assume the green notch near the start coincides with sign off of the previous stage's output and the larger green notch three quarters of the way through coincides with design reviews and prototyping. A small amount of change time has been allowed all the way along, and some of the change time is at the end of the plan, just before the contingency slice.

Very small and quite large

Project disaster lies in wait for the project manager who is "very experienced", but very experienced in running small projects. He learns over and over again a very unfortunate lesson: you don't need to bother too much about the planning. Just tell the two guys what you want them to do and that's it, that's the planning taken care of. That project manager is then given a large project to manage: he knows (whatever the theory says) that in reality you don't need to bother with formal planning so he doesn't and... disaster. Large projects and small projects are totally different animals when it comes to planning.

...next

Privacy Policy and Cookies