Sending out an SOS

A clear mandate is essential for an incoming project manager in order to help turn around problem projects. This requires acceptance by stakeholders that there is a problem and that doing nothing will be worse than doing something. Gareth Hartwell shares his experiences.

How often have you taken over the management of an existing project only to find that everything was running smoothly and there was little that you needed to change? I suspect that, for many of you, the answer is not very often. In my career as a project manager, more often than not I took over an existing project, and more often than not the previous project manager had been moved or left because there was a problem with the project.

As a result, I want to find out about best practice in improving (and in some cases recovering) existing projects. The shelves of many bookshops and libraries are filled with the latest techniques and tips on project management, but many of these tend to assume a blank sheet. Advice on turning around a failing project can be difficult to find; last year I trawled the internet, a major university library and a large London bookshop, amidst hundreds of book lauding the merits of the latest techniques was just one which was of any help Making it happen by Sir John Harvey-Jones. Although is written with the board room in mind, I found that many his thoughts and approaches could be adjusted and helpfully applied in a project transformation scenario. Even so, surely some more directly applicable guidance is well overdue?

There have been some recurring themes to the issues in the projects I have taken over (most of which were software development projects with teams of 20 40 and budgets of several million pounds). Often they have been running over budget but this has not always been transparent. Both scope and cost controls were often poor. Delivery dates were often missed, the client was usually unhappy and team morale was sometimes low. The quality of reviews and record-keeping was often not as good as it should have been. Compared to any standard project methodology, many things were wrong compared to best practice but in some cases these would take many months to change. In the absence of any other information, I relied largely on common sense and advice from some experienced colleagues but learned from the experience so that the next time I had a much better idea of how to approach the issue.

My starting point was to regard the transformation of the project as a project in itself so I took some time to identify the requirements in this case the problems which needed to be resolved. This meant talking to all of the major stakeholders the client, project team, my managers and subcontractors about their perceptions of the problems and potential solutions brainstorming was the most useful technique here. Of course, the demands of the main software development project didnt stop during this period and I had to resist the temptation to suspend the problem-gathering exercise in order to firefight the latest disaster. Once I had explained to the client and internal management what I was trying to do and why I wasnt responding to their immediate questions, they were usually understanding and pleased that somebody was finally trying to deal with the real problems.

The most important starting point was the commitment of the team and I was lucky that I usually had this. Clearly, tact was required to ensure that this was the case even when the previous project manager had been replaced because of the project problems. The key was to make it clear to them that I was only interested in ensuring that the project succeeded, not in attributing blame for previous failures. On the other hand, I was very open with the results of the problem gathering exercise internally while ensuring that individuals were not implicitly or explicitly implicated. This ensured that both the team and management were fully aware of the extent of the problem which helped me to buy some space to start to resolve the problems rather than having to spend a large amount of time answering questions about the latest failures.

Even if the client and internal management were supportive, the window or opportunity was always limited and insufficient to solve all of the major problems usually I had at most a few weeks before I needed to start to show some concrete results. This meant that prioritisation was paramount, but what were the criteria? Uppermost were those things needed to effect the transformation, rather than the client or managements immediate priorities. Only in this way, could I hope to start a virtuous circle which would allow us to gradually improve the situation. This was difficult to explain to both client and management, but I was able to use my honeymoon period as a new manager to insist on this approach. This was essential because had I allowed myself to be distracted from getting the fundamentals in place, I would probably have not had the opportunity to do so again.

A major difficulty was that many of the problems are interlinked; I couldnt hope to solve them all at once, but equally it wasnt possible to solve one in isolation from the others. Following the problem-gathering exercise, I was able to draw a diagram of the major problems and the relationship between them which I refined in discussion with my team (see figure 1 for the results on one of the projects in question).

(Above: Figure 1)

Change control

As Figure 1 shows, the initial major cause of the problem was a serious underestimation of the amount of work to be done. This was exacerbated by the failure to ensure that an effective change control procedure was in place which resulted in substantial scope creep.

These initial problems were serious enough but the failure to understand and address them caused a vicious circle to develop which caused the situation to deteriorate. Because of the initial underestimate, the budget and resources applied to the project were inadequate, so the resulting plans were impossible to achieve within the constraints. This caused deadlines to be missed and even when they were achieved, the quality of the deliverables was often poor because of the lack of resource and pressure to deliver. Obviously, this was noticed by the client but it also resulted in the need for re-work, so the quantity of work increased further. The project managers response was to increase the pressure on them to deliver, thus resulting in poor team morale.

I set about trying to improve the situation by using a two track approach. Firstly, I tried to address the root cause of the problem by establishing a true estimate of both the baseline cost and the major areas of scope creep. This led to a process of securing additional budget (after much negotiation this came partly from an agreed drop in profit , partly from the client and partly from change control) an re-opening discussions where scope had increased, especially in those areas where we could identify a cheaper way of producing a similar benefit to the client. In order to succeed in this process it was necessary to ensure that the client understood both the seriousness of the situation, and the very real possibility that my organisation would withdraw from the project. It was also necessary to consider carefully the clients position and the possible reactions to everything that we might say and do; this required a good understanding of their culture, business situation, and the key individuals we were negotiating with.

In parallel to this, I tried to establish a virtuous circle to start to undo the damage as shown in the vicious circle in Figure 2. While I couldnt immediately agree a realistic plan for the whole project with the client, I could at least produce a realistic for the next few weeks based on deliverables which could be achieved with the current team and a few additional resources.

(Above: Figure 2)

Team morale

The client was surprisingly receptive. Therefore, when the deliverables arrived on time, and were of the appropriate quality, relationships with the client improved, as did team morale. Discussions with my management were very difficult because of the huge deficits I was uncovering, but at least there was clear evidence that I was improving the real situation so they had to back me! To motivate the team, I aimed at an improvement in the project, rather than the project itself, as that goal was the more achievable.

I have found this iterative approach to turning around a failing project successful on several occasions and believe that with a clear mandate, painful changes can be kept to the bare minimum.

• Gareth Hartwell currently works as a project manager for the programme and project management department for Ericsson. His experience includes managing telecommunications, software development and systems integration projects in telecommunications, space and defence from small specialised projects to fixed price turnkey projects with large teams and budgets.