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.
| Planned Hours For: TEAM LEADER|
|3A code duplex interface||-||-||-||-||-||-||-||-||-||25||25||-||-||-||-||-||-||-||-||-|
|3A code web query||-||-||-||-||-||-||-||-||-||-||-||-||-||15||15||-||-||-||-||-|
|3A test web query||-||-||-||-||-||-||-||-||-||-||-||-||-||-||-||10||10||10||10||-|
|Week Total Non-project||3||3||3||10||10||3||3||3||3||3||3||37||37||3||3||16||3||3||3||3|
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?
| Planned Hours For: JOHN SPENCER|
|279 OR Orientation||20||-||-||-||-||-||-||-||-||-|
|252 CM OLT Tables||-||19||26||21||-||-||-||-||-||-|
|253 3A code web OE||-||-||-||9||12||3||-||-||-||-|
|254 Q3 review OE code||-||-||-||-||-||3||-||-||-||-|
|255 R3 rework OE code||-||-||-||-||-||3||-||-||-||-|
|256 3A test OE||-||-||-||-||-||21||10||-||-||-|
|257 Q3 review OE test||-||-||-||-||-||-||3||-||-||-|
|258 R3 rework OE test||-||-||-||-||-||-||4||-||-||-|
|282 FD email enq UFD||-||-||-||-||-||-||13||7||-||-|
|259 ID email enq IT des||-||-||-||-||-||-||-||25||31||-|
|286 Q1 review enq UFD||-||-||-||-||-||-||-||3||-||-|
|287 R1 rework enq UFD||-||-||-||-||-||-||-||2||-||-|
|260 Q2 review enq IT des||-||-||-||-||-||-||-||-||-||6|
|261 R2 rework enq IT des||-||-||-||-||-||-||-||-||-||8|
|262 CO Contingency||-||-||-||-||-||-||-||-||-||17|
|Week Total Non-project||13||16||3||3||23||3||3||-||3||3|
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...
Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
This book must not be copied either as is or in modified form to any website or other medium