...chapter 7 continued

It relies on each team member recording each week how many hours they have actually worked (paid or unpaid) on each project task, and for unfinished tasks how many hours it will take to finish them.

Have a look at Frank Barlow's time sheet. This is his blank timesheet given to him at the beginning of the week. How is Frank doing so far on the project?

Frank is 7 hours behind schedule and should have finished the first 4 tasks last week. The 'Planned Hours This Week' column tells us how he should be spending his 37 hours this week. Let's hope he puts in a bit of extra effort and does those tasks as well as catching up the 7 hours and 4 tasks from last week. Clearly, this time sheet shows a mixture of data from the project plan and Frank's actual status as of last Friday. (The first W under DAILY HOURS stands for Weekend.)

The time sheet captures hours actually worked on each task rather than chargeable or paid hours. If it took 90 hours to do a task we want to know that. Depending upon your environment you may also need to record paid hours and paid overtime hours for charging purposes.

If the project team is working unpaid extra hours but are running on schedule, should we care? We should. We are relying on the team's goodwill - which has its limits. And if they work excessive hours to keep on schedule diminishing returns set in, and eventually they may get so tired that the lid suddenly blows off the pressure cooker.

Most time recording tools allow individuals to enter their time directly. However, this can result in made up numbers being recorded and the data not being used.

An alternative is to have the team leader speak to each member of his team on a Friday afternoon for a five minutes one-to-one discussion about the team member's week and to go through their hard copy time sheet. You might even want to consider insisting that the team leader keys in the time sheets for each and every one of his team - that way you know the team leader has at least seen the data. The team leader should also quality assure the numbers: if he suspects Frank is making up random numbers, visit Frank at the end of each day to go through his time record for that day. He'll soon get fed up with that!

Time recording has to be sold to the team and there are a couple of ways of doing it. "Team member, I've estimated this task at 30 hours but frankly it is a guess. If it actually takes you 90 hours or whatever please let me know by recording that on your time sheet so next time I'll know to estimate 90 hours and it'll be less stressful for you next time around." Secondly, show the team how you will use the time sheet data to track and control progress. If the team see there's real value in accurate time recording they are more likely to do it.

We are primarily recording project time on these time sheets. In principle if someone worked on three projects during a week they will get visits from three team leaders on Friday. Time sheets are a project tracking mechanism: if someone is assigned to your project for, say, 20 hours a week we only want to know how they spent the hours they worked on the project, we're not interested in what else they did during the week.

Miscellany

Even if you have a plan a bit like the one we have been through, still buy a whiteboard and put a summary of the plan up on the wall so that everyone can understand at a glance what is going on. If the team is spread across several sites also buy a webcam.

Large projects can be divided into 'work-intensive' and 'milestone' projects. In a large work-intensive project there are many people mostly working full time on the project - the sort of plan we have been through is appropriate in those circumstances. However, some very large projects in terms of budget are of a different nature. In these projects a succession of high cost items is delivered and installed. The project plan consists largely of milestone dates and the project manager's main job is chasing suppliers to make sure they deliver as promised. Even if several people are involved and they are doing critical things the number of hours they will work on the project is relatively small. This sort of project needs a milestone chart or a critical path network diagram rather than a mechanism for counting and analysing hours and tasks.

When planning a long stage - say 5 or 6 months - it may not be desirable at the start of the stage to plan the whole stage at the task level. One way round this is to have 'block' tasks. For example a block task of 250 hours for a team member in months 5 and 6 that covers code, review, correct, write test data, test, and handover of a part of the system. Perhaps only in month 2 or 3 would the planner break this out into 2 coding tasks, 2 review tasks, 2 correction tasks, etc, i.e. the one block task becomes 14 work tasks. This is fine but it can look as if the plan is growing because the number of tasks is increasing. Counting the block task as 14 tasks from the outset can overcome this.

Some planners plan all the easy tasks at the beginning of the stage. Their rationale might be that this aids team morale. But all the hard tasks come at the end and they're the ones that tend to overrun. If you can, plan the chewy tasks at the start and plan the easy, predictable ones at the end of the stage.

If you publish a design document on June 1st, does the design stage end on that day? Probably not. What happens when any document is published for review and sign off? Nothing. Which means you must go and chase people to read the document. And then they start asking questions, want things explaining, request changes, etc. If you assumed your team were going to be available full time to work on the next stage you will get a nasty shock: they keep getting pulled back to do these tidy up activities. At the end of Stage 1 allow effort for tidy up that overlaps with perhaps the first two weeks of Stage 2. Stage 1 actually finishes two weeks after Stage 2 has started. More on this in the tracking, controlling and reporting chapter.

Always plan and track in hours, never days or half days. People will argue how long a day or a half day is but an hour is an hour is an hour.

Net vs gross can be a source of confusion. Firstly an hour is an hour is an hour - there are no net hours or gross hours - just hours. For the purpose of illustration let us assume that a full time project team member will do 29 hours project work a week on average over the course of a year. There are 4.333 weeks in a month, so the person will on average do 29 x 4.333 which is around 125 project hours a month. This is sometimes referred to a gross man month - a full time team member will do 125 man hours project work per (gross) man month. This is useful for working out how many people the project will need: the project requires 49 gross man months of effort? That's about 7 people on average for 7 months. Usually when people refer to man months they mean gross man months. If people do use terms such as net man days or gross man weeks ask them to explain exactly what they mean - a pound to a penny they won't be able to.

We have seen how very small projects can have simple plans and we have also seen the sort of detail that will be needed for larger projects. Only you can gauge what will be most appropriate for your project.

Whether large or small, well planned projects tend to cost less, take less time to do and deliver better quality than badly planned ones.

Project Management A Beginner's Guide.

Please click here to go to Project Management Book Chapter 8

Project Management Course

Privacy Policy and Cookies