Saturday 26 January 2008

Failing projects 2: How to save a failing project

This section is written under the assumption that you are the office-based manager of a project team led by a field officer and the project appears to be failing. If you are the field officer, see part 3.


Houston, we've got a problem

The first step you need to take it to recognise that there is a serious problem. Accept it. If you spend all your time complaining that it isn't going as planned, you will not be in a positive enough state to drive through any improvement.


We are where we are

If saving projects was easy, none would fail. There are losses; some will be irrecoverable; not all outcomes will be achieved. You should be thinking about damage limitation: what are the key outcomes? How could we get there from here? It is important to remember that whatever you plan, it will probably have to be delivered by the existing team, the team which is already performing poorly. If they have taken 50% of the time and resources to do only 40% of the work, you have two problems: there's 60% of the work still to do, and at the current rate that will take 75% of the available time.


Do something now

Every week of underperforming creates a bigger problem to be addressed. Minor changes early on may do as much as drastic actions later.


"Do" and "Don't"

Don't tell them it's easy

There is no point saying that you could do it quicker or better, or somebody else could. They are finding it hard; unless you are intending to actually do the work yourself, the fact that you could do it standing on your head is irrelevant.

Don't apportion blame: leave the autopsy until the patient is dead

There is a time and place to work out what went wrong. Surrounded by frazzled staff who have been quietly panicking about how it is going isn't one of them. Save it for the post-project review, which will usually conclude that decisions were made with the best intentions in the circumstances as they appeared at the time.

The review may well show that the problems were caused by a combination of bad research, bad planning, overoptimistic costing, remote management, bad luck and bad weather, as well as project implementation. Often such problems only become obvious at the fieldwork stage, but that doesn't mean that's what caused them.

But even if it is true that the fault lies with the field team, who are no doubt demoralised and unmotivated, telling them this is hardly likely to inspire them.


Don't tidy up

You could clean up the cabins and tool stores and make the site look a bit smarter. But it won't help: although a dirty site is a symptom of a failing team, the obverse isn't true. The problems with the team need to be addressed if anything is going to change.


Don't work overtime and weekends

The extra work done won't compensate for the administrative and logistical problems caused, and productively in core hours will suffer.


Maybe send people on holiday

This will be good for them, and good for the site, since it provides a break which will alter the team dynamics. It's actually a good plan to include a break in projects on purpose: the need to hand over to someone else is a very good discipline.


Maybe replace the field officer

This might seem the obvious solution, but it is fraught with difficulties. For a start, it seems to personalise the issue into a matter of their competence. It will probably irreversibly damage their working relationships in the future. And it will be resented by the staff (paradoxically, this is true even if they have spent the last month complaining about how useless they are), the staff you are hoping to lead forward to success.


Maybe provide more staff or more time

Again this may seem an obvious solution. But throwing more resources into the mix will have little effect unless the fundamental problems are addressed; in no time any new staff will have gone native and be just as unproductive as the rest. And adding a few weeks to the project may be felt to be extending the prison sentence.

Even if this doesn't happen, there's likely to be friction between old and new staff, especially if the new members have been labelled as 'the ones who are coming to sort it out'.


Do make hard decisions

In general, problems arise because people defer hard decisions, rather than because they choose wrong. But archaeologists will be understandably reluctant to depart from accepted methodology. If you are going to abandon stone-by-stone planning, the decision should be made by the senior archaeologist involved, after careful thought. The team may well be reluctant: it is important to explain to them the rationale, not just the outcome.


Do support your field officer

Help them by smoothing any practical issues, listening to their views, respecting their opinions. And make sure you are available and visit site often: long distance management only works when projects are running well.


Do talk to the team

Give them information about the background to the project, what your priorities are, and how they fit in. They should be made to feel part of the company, even if they are only there for a single site.


Do listen to the team

You never know, you might learn something.

1 comment:

Anonymous said...

This is a nice, comprehensive article about the subject of failing projects.

I'm not sure everyone will agree with you on some of the points:

- Give staff vacation: The question is, will the staff enjoy the vacation, will you, as a Project Manager, enjoy they're having a vacation. It's probably better to make some promises of nice, relaxing vacations after the project's done.

- Provide more staff: A lot of Project Managers think that this will probably do more harm than good. More staff means that this staff has to be trained, this staff has to adjust to the project, as well as an increase in the communication channels.

I did publish a while ago an article on how to really fix a failing project. Take a look, and let me know what you think about this article.