Topic: Fixing a train wreck in progress

Compiled: 1/17/2005

The Situation:

Our mid size development team (About 15 people including test, etc.) is 5 weeks into a 30 week project. Some of us had major concerns during initial planning that were never resolved (to our satisfaction). Now we find ourselves part of the way over a cliff: the architecture direction is misguided, the business plan doesn’t make complete sense, and the team is overly scattered, and not focused on the same goals (Some think they are, but I certainly don’t :).

But the project already has significant momentum, and management doesn’t see the danger or feels concern about the problem (Though the warning signs of low quality, continuing arguments, and fuzzy requirements are showing). How as a project manager, in the middle of a project, work to prevent what I think is a train wreck in progress? How can I protect the development team, and the project, from what I think will be painful major changes (and throwing away of work) in the next 4 or 5 weeks? How do I save a project that is starting to run off it’s rails?

– Cassandra in the Caboose, Cupertino, CA

Advice

If things are clearly going poorly, and you’re not alone in seeing the train wreck, but no one seems worried, why are you? Although pride and emotional investment are all things we want to place in our work, if you’re surrounded by others that aren’t alarmed by the threat of project disaster, don’t necessarily take their burden on your shoulders – Only be a martyr for a project if it’s really worth the emotional investment.

In situations where the project hasn’t been managed well, and you haven’t been granted the power to affect change, then you shouldn’t be holding yourself responsible when things beyond your control go wrong. (Although you are responsible for telling your superiors that you feel you are in such a situation – they may not realize they’ve put you there).

Consider who has ultimate accountability – who is the overall project manager? Someone higher that you may be the true project manager, with overall responsibility for the entire fate of the project. If they are unaware (or in denial) of what’s going wrong, it’s up to someone like you to give them the low-down. Have a clear and short 1-on-1 conversation about what you’re observing, and what types of actions you think they need to take. Even if they don’t listen, you’ll feel better for having tried.

Good project teams periodically inspect their progress, and give people like you a chance to point out cracks in the foundation that need to be investigated. If there is no weekly or monthly status type meeting, call one. Set the agenda to be "review current risks against the schedule" and get everyone to bring their concerns about meeting the project schedule.

Perhaps you’ll need to start small (your local small team of developers and testers) or maybe you have enough clout to go big (other managers and lead types), but once you have the meeting, roll up the concerns, prioritize them, and take them to the people you think have the power to impact change. Say, "here’s the top 5 issues the team is concerned about right now in being successful on this project." It’s hard for anyone to ignore lists like this. (Faisal called this a risks list – and suggested that you should be prepared to back up claims, and perhaps offer to drive these issues to resolution, so you’re not seen as a doomsayer. Andrew suggested making a daily ritual of reviewing the list ).

Consider performing a project overhaul – Andrew described a 5 step (ok, it’s 6) process for resetting expectations and getting the project back on track.

1. Heavily revise the vision document to be a useful, accurate, realistic thing.
2. Revise the work item / estimates list to be sane.
3. Reallocate resources based on the vision and estimates.
4. Hold a risk planning session, where the team lists their concerns. Prioritize and take action to minimize the most important.
5. Add a status meeting to the schedule every two weeks – review all tasks done since previous meeting, and allow people to raise new risks/concerns.
6. Publish everything on an internal website, and design it to be accessible for all project stakeholders and senior managers. Finding time to do all this may be a challenge since until it’s done the project is still rolling, but there’s no way around that (unless you get management to agree and fully support the projectectomy).

Let things implode. Let the train wreck happen. Some people only learn when they are forced to. You may need a train wreck to have enough ammunition to convince someone that things need to change. I’m not saying commit sabotage, just keep in mind that your best opportunity for making change happen might be right after a disastrous project.

Look for a different job – If you are expected to continually manage projects that are out of control, and have low odds of meeting their goals/expectations, it may be time to look elsewhere. Teams that have chronic management problems regarding project management are lousy places for good project managers to work – the skills involved are clearly not as valued as they might be elsewhere. Don’t assume all organizations suffer from the same problems yours does.

References

Wideband delphi came up again. Andrew recommended this technique for development estimates.

Contributors

Gretchen Hartke, Faisal Jawdat, Neil Enns, Andrew Stellman, Scott Berkun (editor dude)

PM Clinic discussion group

General info
How to join
Full archives
Other web forums