SYMPTOMS

Searching for symptoms that demonstrate that emergency action is required can be a complex task. There is no one place that you should search. Instead there are various places within the project where problems may be lurking. Regrettably you are unlikely to have time continually to search them all and so you need to look for symptoms of failure. Failure may occur in a task with one resource or a task with multiple resources. The task itself may be small or it may be large and complex. However, in all cases the task should have a plan that sets out what is supposed to happen. It is the plan and changes to it that you should watch. One of the most obvious symptoms of something going wrong is consistent failure. You should be watching for tasks that continually have small deviations from the plan and that are continuously reporting problems.

Finding tasks that deviate from their plan on a consistent basis is relatively easy if the control mechanisms described earlier in this book are in place. These control mechanisms analyse progress against plan and alert the project manager when problems arise. Looking at the ratio of actual plan to baseline plan for the different work packages and their work within the work packages will quickly allow an assessment of where things have gone wrong. Where things continuously go wrong, action needs to be taken.

When you suspect there is a problem you need to be careful in the way that you act. Work package managers when confronted with a consistency problem generally react badly . Rather than deal with the problem they often try to deny the problem. Instead they prefer to try to deal with the problem in private. Their initial reaction is to produce many excuses for the failure and to suggest that contingency and reserve should be used to get the task back on track. You need to cut through these excuses and explain clearly that you have evidence that shows the project is consistently failing. You need to ensure that the work package manager agrees that he or she needs help and that a suitable action plan is required.

There are many reasons why a project might fail. For example, the team may be completely demotivated. They may feel that the work they're doing isn't valued. They may feel unappreciated or simply they may be getting asked to do something that they are not capable of doing. Whatever the reason it is important that you and the work package manager recognize that action needs to be taken. Usually a task that needs rescuing will be on or just about on the critical path of the overall project. It will have reached this point because it will have continuously slipped. For example, it is possible for the installation of a cooker switch to hold up the completion of a new building.

You need to be clear with the team that there are problems. You should resist the temptation to pacify the team by telling them that they shouldn't worry or that these things happen. The team need to understand that they have failed. They have failed to deliver what was needed. Even although this might demotivate the team, you need to be blunt. You should tell the team that performance must improve. The team should be reassured that they will be supported in trying to improve performance. However, they should be left in no doubt that ultimately it is up to them to improve performance and they need to do so quickly. You should undertake this discussion with the team instead of asking the work package manager to talk to the team. This ensures that the relationship between the work package manager and the team is not significantly damaged. It also helps to reinforce to the work package manager that he or she too has failed. You also need to have a blunt conversation with the work package manager. You must explain that the work package manager has failed and now must get things back on track.