Project Management Book

...chapter 7 continued

This second page is for a sub team leader. There were half a dozen trainees in the team and he was asked to look after them. How do we know he is a full time member of the project team? He only has 2 hours a week on the 'Non-this-project time' row. Again he has 2 hours a week for the weekly team meeting and for time recording admin, but most of his time is down to mother-henning his team of trainees. And what might PCR Investigation be? It is in fact Project Change Request Investigation time. Please look at July.

The planner knows something we don't know. He is predicting a surge of change requests in July and has given this team leader 10 hours a week during July to investigate them.

The next three lines we might call 'real work'. The first is a 50 hour task to be done in the middle two weeks of August. What does that suggest about his team of trainees during those two weeks? Most of them are on holiday, so the team leader can do some real work while they're away. And the planner has made an interesting assumption that by October those trainees will have had four months experience and won't need a full time mother hen anymore, so the team leader can do some real work in October as well as keeping an eye on his team. In smaller projects, the project leader would look a bit like this: a mix of supervision and real work. In huge projects there can be several layers of leaders who do nothing except control those below them.

Before we leave this team leader, please have a look at his vacation plan then go back to the project leader's plan: if you were project support and you were reviewing this project plan what comment would you make? Back.

Yup, the project leader and team leader are both on holiday at the same time at the end of August. Luckily there was in fact another team leader who looked after the shop while they were away. But this does illustrate the sort of thing it is quite easy to pick up if you are doing an independent review of a project plan.

The plan below is for one of the real workers. The plans for the majority of people in a large project would look like this. As you can see, his first task is 'orientation' which suggests he joins the team at the beginning of June. He's only with us until the middle of August and the planner has put 17 hours contingency at the end of his plan just in case he runs a bit late on his tasks. As you'd expect, almost all of his time is assigned to real work tasks. Please look at task number 253 - how many hours should that task take him?

It's 24 hours work over a 3 week period. And what is task number 254? It is a 3 hour task for John to sit down with other people to check his work for any errors. What, therefore is task 255? Rework - correcting any errors found by the quality inspection. How did the planner (the project leader) know the rework would take 3 hours? Was that a guess he made? It was not a guess.

On previous projects time had been separately planned for doing, reviewing and re-doing, and time recorded separately against each of those three tasks, so they knew for a fact that rework averaged around 10% of the time it took to do the task in the first place, so the planner assumed rework would be 10% this time, to the nearest hour. Of course, John Spencer might make no errors, zero rework, or he might make a complete hash of it, 30 hours rework. But across all team members across the whole stage it will probably work out to about what it was last time. This is a good example of using past factual data when planning future projects.

There are something like 400 different types of tasks in a software development project. It is surprising how few of them are fundamentally changed when switching to a new technology or a 'new' development methodology.

You can see that some of John Spencer's tasks are rather more than 30 hours, and some are 3 weeks long, but again this is a good example of a realistic plan which would easily pass the project support censor: John is in no doubt what he has agreed to do and by when.

It is also obvious that if you have a team of 20 people, planning like this will take a lot of brain time if it is all to fit together. That 3 hour task to review John's work involved two other people so they will each have had time in their plan to participate in the review during that week. Quite tricky to get it all to interlock. But invest the time and project execution will be a joy to behold.

Please don't be frightened by the chart on the next page...

I.T. Project Management Book. How to manage IT projects. Planning and Scheduling IT projects.

...next

project management course

Privacy Policy and Cookies