Project Management Book

Chapter 10 - Tracking, Controlling and Reporting

Project control is very simple in principle. It boils down to knowing where you are and what you have done, comparing that to where you should be and what you should have done, spotting the difference and deciding what to do about the difference. Simple as that. Shall we move on to the next chapter?

Make your friends groan with this one. It works better spoken than written. Controlling a project is great fun if you remember the three basic laws of project management. Do you know what Murphy's Law is? "If it can go wrong it will". Do you know what Sod's Law is? "It will go wrong in the worst possible way". Do you know what Cole's Law is? "Coleslaw is finely chopped cabbage in mayonnaise."

The old adage that no news is good news does not apply to projects. An information black hole conceals one thing only: bad news. And if you have data about the project you could interpret in several ways only the most painful interpretation will be the correct one. This is no place for optimists.

What is the purpose of project control? It helps the project deliver as committed: dates, costs, quality, etc. It also enables accurate reporting of project status. Clearly, we must be able to spot deviations from the plan and sort them out, but the real art of project control is looking forward to foresee potential future problems so that we can avoid them. This Porsche driver has had a bit of a plan deviation, you haven't got to be a genius to figure that out and even the corrective action is fairly self evident.

Identifying a plan deviation

Taking corrective action

But we want to be more like this next Porsche driver who has a sensitive, forward looking problem alert mechanism (a pair of eyes). He sees the pylon coming, makes a small course correction and just skims past it. This is what good project control comes down to - spotting the problems in advance and avoiding them rather than discovering them the hard way.

Identifying potential problem

And avoiding it

Control boils down to 'are we on plan?' which implies we have a plan. But imagine we have a plan that only contains half the work we will actually need to do. Knowing we are bang on plan is highly misleading. For good control we need a good plan.

Where are our commitments written down? In the Project Definition Document (PDD), stage agreement and the plan itself. But suppose we are half way through a 5 month long stage. Are we still tracking against the plan we built two and a half months ago? Almost certainly not - over those first two and a half months we will have had to change the plan and we're now tracking against that changed plan.

Who authorises changes to the plan? Maybe you're thinking 'the sponsor'. Imagine at the start of a stage we told the sponsor it would cost 10,000 hours of work. But at the end of week 1 we realise we have made a mistake: we don't think it will cost 10,000 hours, we think it will 10,001 hours. Should we get the sponsor to approve the 1 extra hour? No. But suppose at the end of week 1 we don't think the stage will cost 10,000 hours we think it will cost 20,000 hours, should the sponsor approve the extra 10,000 hours? You bet.

Where should the boundary line be drawn? There should be a predetermined tolerance limit - only variances outside that limit need be approved by the sponsor. If the tolerance is too small the project manager would spend all his time getting tiny variances approved. If the tolerance is too wide the sponsor has little or no control over costs. Before a stage starts the project manager agrees how much he can change things by without seeking sponsor approval - i.e. his tolerance limits. The project manager must then decide how much of his tolerance he will delegate to those below him in the chain of command. The sponsor may have the freedom to move the end date by a month without seeking the approval of anyone more senior, but would you allow that same tolerance to the most junior member of the team? Probably not. The amount of tolerance you have depends upon who you are. We will discuss some actual amounts a little later.

Bear in mind also that tolerance is not on the current position vs the plan but on where we are going to end up. So, if we're currently 25% over budget but nevertheless confident of completing the stage on budget, no approval is needed. If we are currently on budget but think we will end up 25% over budget that requires approval (unless we have a very generous tolerance limit indeed!).

Let us consider the tracking, controlling and reporting activities that we would expect team leaders, project managers and project sponsors to perform.

Team Leader

What should a team leader do to keep a grip on the work for which he is responsible?

• Monitor team's status. Know exactly where the team is versus their plan.
• Check tasks really are completed. Particularly at the start, and for new team members, if someone says a task is finished check that it really is finished until you know you can trust what they say.
• Responsible for quality of team's work. Individuals are accountable for the quality of their work but if someone in your team delivers bad quality that will feature in your appraisal as team leader too (see the quality management chapter).
• Keeper of project records. On large projects the project office will look after most of the record keeping but on smaller projects it often falls to the team leader(s) to keep the records straight.
• Collect weekly time sheets. Once a week establish precisely where each team member is versus their individual plan.
• Keep the team work plan up to date. This is a thorny one. At the extremes team leaders come in two flavours. At one extreme are the theoretical perfectionists. At the end of week 1 of a 4 month stage they spend the whole weekend moving tasks planned for months 3 and 4 around for some theoretical precision in the plan. And at the end of week 2 what do they do? Move them back to where they were in the first place and shuffle several hundred other tasks around in pursuit of that theoretical perfection. The other extreme, however, is much worse. The lazy sods. Once the work has started they never update the plan so after the first few weeks the plan bears no resemblance to what is actually happening and is never seen again. Somewhere between these two extremes must be a happy medium. Each Friday the team leader captures actual status from each member of their team - tasks finished, hours worked, etc. The team leader then revises the team plan so that at least over the next 6 weeks or so the plan reflects exactly what we now think will actually happen over those next 6 weeks. Critical path tasks more than 6 weeks out should be replanned if we know they're going to be late, but as long as the plan is roughly right between 6 weeks out and the end of the stage leave that part of the plan alone. Do whatever is right for you, but don't waste time being a theoretical perfectionist and don't be lazy.
• Weekly team meeting. The team leader gets their team together for an hour once a week. Each person says where they are and what they are doing. Risks, issues and changes relevant to the team are reviewed.
• Report status weekly to the project manager. See below.
• Liaise with other team leaders. Keep your team's work synchronised with other teams'. Escalate to the project manager if you can't.
• Agree tolerance limits with team members. The team leader may have an understanding with each of their team members rather as follows: As long as you can complete your tasks by their scheduled end dates I will be happy. If that means you must work a few more or a few less hours than planned just get on with it. But if you will not be able to meet any task's deadline let me know and I will change the plan.

The team leader manages the work of his team.

...next

Privacy Policy and Cookies