OPTIONS

Now the team have been briefed that a rescue project is being started you must act swiftly to get the project planned and work under way. You must ensure that the team feel a change in pace. The team need to believe that things have changed and are going to continue to change until the task is completed successfully.

Initially the most important issue for you is to understand the problem. You should examine the task concerned from the four aspects that are the foundation for projects, scope, resource, timescale and quality. Wherever possible you should involve one or two team members in the investigation. This helps to ensure the team will be brought into the final solution.

To examine scope successfully you need to analyse what the initial requirement was. This can be achieved by talking with the project sponsor and the various team members. Since scope is a common cause of failure it is likely that the accounts given by the project sponsor and the implementing team member will be different. Where this is the case you should clarify exactly what is required. You should take care in this process to ensure that they follow the project processes correctly. In this instance this is likely to mean you will need to raise a change request to add or remove functionality. Whilst following the process you should try to find out what went wrong with the process. This should enable you to improve the process to ensure that similar mistakes don't occur again.

Once the analysis of scope has been completed you should examine resource. You should start by understanding what resources were planned for the task. This involves returning to the original estimates and checking how they were developed. Once this research has been completed you should examine whether the planned resource was correctly applied. Applying the correct resource has two aspects: firstly, whether the number of people was sufficient and, secondly, whether they had sufficient experience.

Surprisingly it might not be possible to find out whether the right amount of resource was applied to the task. Although most large organizations have and use time-recording tools extensively, they fail to use them accurately. Staff do not believe in the value of the tool and so often don't put in accurate figures. Therefore when analysing whether the appropriate amount of people have been put on the task it is often more effective to interview the people who were involved.

The second aspect, ˜Did the resource have the right experience?', is often a harder question to answer. You must consider all of the team members and their roles. You need to assess whether each team member has the skills and the ability to complete his or her part of the task. A common difficulty, resulting in the formation of rescue projects, is team members being given tasks that are beyond their ability. This does not mean that people are not capable, just that they are not capable at the level required. Where this has occurred you should consider either replacing a person or if possible giving that person more support. Unfortunately it can also be the case that a team member is simply incompetent. Where this happens the team member should be removed.

Analysing problems associated with timescale often ends up being the same as analysing the problems associated with scope and resource. Scope and resource problems tend to result in timescales not being met. This should be evident to you from the analysis of scope and resource. Where there is a clear link you should not spend significant time examining the problem.

One timescale problem that may not have been picked up through the analysis of scope and resource is the task being impossible to achieve in the given time frame. This can occur for a number of reasons that are genuinely outwith the control of the task team. You may find that the team have put together realistic timescales but that circumstances make the task impossible to achieve. For example, the team accurately estimate and submit plans for the development of a software module. The plans state that the work will take one month to complete. The software module relies on a delivery from a company in Sweden. You schedule the work to happen in June and July. The task team suggest a one-month slip on the task. A rescue project is instigated because the task length has doubled . The reason for the slip is Swedish holidays. In Sweden generally most companies take four weeks' holiday in June and July making it impossible in this case for the task team to deliver according to the original schedule. These instances should be relatively simple to find and correct.

Quality is the last factor that you should examine. It is a topic that will have been discussed when analysing the other areas. As a result the analysis for quality should be relatively straight-forward. It is highly likely that you will find that quality has been affected. What you need to assess is why it has been affected. The most likely cause of quality standards slipping is the team cutting corners. Corner cutting will have occurred if the task was significantly deviating from the baseline and the task team have tried to bring the task back on to the plan. It is often a simple way of making it seem as though the schedule is being adhered to.

Corner cutting is, however, not the only reason for quality slipping. The other reason that is often found is that the task team are unable to achieve the desired level of quality. This may have been picked up during the resource analysis. If not then it should be examined as part of the quality investigation.