How to deal with a rogue project

You have identified your rogue project. But before you swing into action to fix it, work out beforehand where the root of the...

You have identified your rogue project. But before you swing into action to fix it, work out beforehand where the root of the problem lies and what needs to be done.

Once the warning bells start to sound, call a halt on the project and conduct a major review to discover what has gone wrong. Do not wait for things to get any worse.

PA's Chris Harden recommends allocating around four weeks to get to grips with the problems.

"We look at how the project is organised, and whether roles and responsibilities are clearly defined. We ask if the people on the project are sufficiently experienced," he says.

Inexperience need not necessarily be a problem, provided that the number of inexperienced people is not too high and that there are plenty of people with the experience necessary for the task in hand. Look at your resources - does everyone know how to use them properly?

"We check whether the technology can do what suppliers say it can," says Harden. "People blame the technology because they don't find out about something [it can or can't do] until late in the project."

"If you find out early, say, that the technology is limited to only 128 users, then the suppliers have time to make the changes to the products you need - but people don't identify these issues up front," say Harden.

He blames the traditional "waterfall" approach to projects - where each step pours its results into the following, and each step requires all its input from the previous one, so every step has to be completed before the next can begin - for delaying critical aspects until too late in the day.

"The approach has to be right for the type of project; you have to understand the constraints, such as time or cost, but these might not be appropriate to the project."

A safety-critical system, for example, is a poor candidate for being time constrained. A quality control project cannot be rushed. However, if your project entails building an online channel and taking it to market in less than six months, a rapid application development approach is perfectly acceptable.

Bolster your team's morale
Turning around a failing project can mean bringing in a third party - especially to do the review. But that is not the cure-all. Before any steps are taken to turn around a flagging project, the morale of the team needs to be boosted.

"Morale can go down a black hole in a failing project, and team members will be frustrated," says Harden. "But as morale rises, people start getting bullish and start achieving their milestones, turning back into a functioning team."

Narrow your sights
For KPMG's Andy Cole, the most urgent task is to rein in, or "de-scope" the project. If deliverables are not arriving, there may be too many demands in the timescale required, so reduce what needs to be delivered. "Deliver something on time rather than everything late. Go for [delivering] the quick wins."

The result of this is that fewer, easily achievable goals will both bolster morale and prove productive. The rest of the project can be delivered later, but make sure the timetable is realistic.

No amount of money will turn around a rogue project if the problem is a lack of the full spectrum of resources, from design to user acceptance testing. One area that can be fatally easy to under-resource is the contribution from the business side. A perennial problem is a lack of staff. Then it is time to get tough.

"You have to get businesses to release their best people," says Cole. If necessary, he adds, get interims in to do their day jobs until the project is completed.

Cole stresses that adequate resources for the project should be lined up at the start; no project manager should start a project until they are there. If a lack of people is causing project failure, the project manager should down tools until there are enough people to do the job properly. If there are not enough people, and the project manager decides to carry on regardless, then he or she should do this only after issuing the direst of warnings further up the line.

Know what you're doing
Even if no one is clear as to what is causing the problems, call a halt straightaway. If the methodology is top heavy, change it. It's not always the case that all the processes in a methodology need to be followed by every project, he adds.
The management overhead should not be a drag on the project's momentum.

"The cost burn rate [on a rogue project] can be horrific. Stop the spend and find out what's wrong," Cole advises.

"The best methodologies are frameworks - but if they are too specific or rigid they take out flexibility and the team starts following a ritual," he adds.

A change of project manager may be needed. "The old [manager] may not be bad, but they will have made promises that were not delivered, so the perception could be that they are not up to the job," says Cole. A project manager, he adds, "should have scars to show you". Ideally, they should not be scars gained on your project.

Get a life
Everyone on the team should be able to see a life beyond the project. Cole advises that people should be promoted out of a project. That way they will have no reason to delay the project and gain glory for good delivery.

Finally, even if a project is not going wrong, people may perceive that it is. The remedy is a good dose of communication between the project manager and the doubters, but make sure the case for the "good news" is compelling and unquestionable. Trying to hide trouble is the very worst option you can take.

But sometimes saving a rogue project is the wrong choice to make. Projects that have been running hopelessly behind can finish so late that the problem they were designed to solve has been resolved in some other way. In which case, delivering the project will bring no business value at all. It's time to turn off the life support and flatline the project.

Useful reading
Runaway Systems (KPMG) Taking risk out of business change projects' - joint workshop with Cranfield and Impact, 2 May.
Project and Programme Support Office Handbook, published by Project Manager Today,

Read more on IT project management