General discussion


Support and honesty are crucial

By theo ·
I have been involved with attempts to rescue failed projects. The ones that seemed to turn around like magic are where there is (1) executive support for the recovery work, and (2) the new leader has the time and authority to understand the root cause of the failure.

I agree in general with the abstract notion that the effort to rescue a failed project is itself a project (DUH- wink), but beyond that, let's discuss and define what is different about the rescue project in terms of its characteristics, especially the critical success factors: focus on the process failures and understand why the project failed, honest communications, adequate resource commitment, and executive support.

Morale, or lack of it, is usually a big issue for failed projects, as is effective communication between team members and the product owner. These have to be overcome immediately, or the rescue project will never make any progress, and the project may fail again.

Without the intial focus on determining the root cause, many second attempts fail again from "get thereitis", the compulsion to see a late project meet some deadlines as a measure of the success of the turnaround. The most important focus for the recovery project is on fixing the process issues rather than the goals of the original project. I have had to explain the need to determine the root cause of the project's failure to management, and I usually describe it as the ?best way to avoid repeating the earlier failure again?. Often, a second failure would be the final failure, so people are usually receptive to an experienced turn-around agent. A good technique to use to uncover root causes of a process breakdown is the ?5 Whys? technique of Six Sigma.

Using the root cause as the diagnosis, the prescription should be to get the project back on track, and make adjustments to the process to avoid repeating the failure. You may need to remove unreasonable expectations and to refocus project requirements, commitments, and the schedule. You will certainly need the executive support I mentioned earlier to accomplish this.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Honesty is the most crucial of all.

by jkameleon In reply to Support and honesty are c ...

Alas, it's pretty much like mineral oil.

Once it's pumped out, turned into cash, and burned, it takes a couple of billions of years to form again.

Collapse -

... be prepared not to receive any gratitude...

by Thorarinn In reply to Support and honesty are c ...

My only 'major' rescue project was five months late when I joined the company. Two of the three 'project owners' had left the company a couple of weeks earlier.

Six months later we eventually delivered the 'final' system on the very day it went live. We sorted out the last show-stopper literally hours before 'go'. This was a date we could not possibly change.

Hardly a single line of code was more than around four to five months old. In effect we took every single module of the system and started from scratch. There were mostly performance problems but there were also some functional issues.

In addition to that we had problems with the servers, the network, the database, the application server (each one sold and serviced by different vendors - don't ask why - 'politics'!) and some other software that was part of the solution but not our project.

A week after we delivered the system, I was given the boot. To this day I remain convinced it was the last remaining 'owner' protecting his own backside. The fixed price project was probably ten times over budget and I was made a scapegoat.

I had very little project management experience and got neither support nor honesty from the company. It was only after a couple of 'crisis meetings' with the client's 'big brass' that we got the help we had been demanding for weeks.

I don't know if knowing the "5 Whys" of Six Sigma would have made any difference. (Knowing about the state of affairs before signing my contract would have!)

What I do know is that morale was non-existing and the communication between the team and the remaining 'owner' was based on a lie. The team told him what he wanted to hear; that the system was nearly 'complete' when in fact it was 'complete rubbish'.

At that point in time the system did some of what it was supposed to do but v e r y , v e r y s l o w l y . . . The team figured they could swing things around, after all they had another six months before going live and they just wanted the 'owner' out of their hair.

Right from the start of the project the team got going in the wrong direction but no one seemed to notice or be bothered. The team was desperately 'lost', the project got seriously derailed and the owners could not jump ship soon enough.

I'm pretty certain the 'root cause' was lack of planning, lack of vision and most importantly, lack of proper ownership.

I don't think there was any serious planning done and certainly no proper design of the system based on the analysis provided by the client. No wonder the team got lost.

The icing on the cake was the fact that they e-mailed me my notice, after I left work on a Friday afternoon, the last working day of that month!

Collapse -

project rescue

by adent888 In reply to Support and honesty are c ...

Not to belabor a point, but properly planned projects have provisions for unrealized objectives. If someone wants to rescue a failed project suggest scrapping the project and starting over clearly defining milestones and course of action if deadlines aren't met. Attempting to revive stalled or dead projects without redefining objectives, timelines, and responsibilities is a recipie for continued failure.

Collapse -

Blame the consultant

by generapharm In reply to Support and honesty are c ...

The best tactics in the case of a project melt down is to bring in an expert consultant. Make sure to do this as late as possible because if brought in on time there might not be a crisis. Let the consultant waste time trying to find out what you already know. When senior management finally notice that the project is irretrievably lost fire the consultant. Point out that it cant have been your fault because even the consultant couldn't do it.

An increase in emails shortly before the crisis is discovered will always be useful.

Malcolm Ross-Project management consultant [non IT]

Collapse -

The consultant can blame everyone else!

by yeoman In reply to Blame the consultant

Most of the projects I have managed have been IT projects, and the failed ones I took over were all IT projects.

One of the first was a small Fixed (?Term?) Deposit system for a finance company that had ground to a halt with no project manager. I was originally hired as a contract programmer, then a permanent ?Consultant?. Business requirements were sparse but mainly there. Missing were the management reports and support processes (backup, etc.). The fundamental failure was quality control ? no one reviewed the design or the programs nor was there any testing evident. There were deposits maturing on 31st February and customer documents were not printing out properly (no one had figured out how to get the document printer to work).

The steps I took were:
1 Confirmed and updated the business requirements
2 Negotiated a new completion date
3 Fixed the system problems
(a) corrected a structural error in the database and patched the data already keyed in
(b) fixed the program errors
(c) got the document printer working and customer receipts printed correctly
(d) organised system backup procedures
4 Trained the operators and managed the rollout to three branches

The Chairman of the Board turned up one day and gave me an angry blast for delivering the system late (blame the consultant) in front of his staff. Fortunately I had the support of the General Manager, who understood what was involved and was more interested in a successful outcome which he could see was imminent.

Principles of PMBOK that applied:
SCOPE ? confirmed and updated it.
TIME ? agreed a new timetable and kept to it.
COST ? it was a fixed-price contract so no additional cost to the client.
QUALITY ? made sure the system worked as it should: proper testing.
HR ? convinced the staff we were on a winner: quite a boost to morale!
PROCUREMENT ? negotiated with client to purchase more disks for daily database backup.
COMMUNICATIONS ? key stakeholders were apprised of plans and progress (I had never met the Chairman before that date, and never again, so had not included him as a stakeholder)

(One advantage of being the consultant called in late: you can blame everybody who was no longer around!)

Related Discussions

Related Forums