PM Clinic: Week 11 Summary
Topic: Fixing a train wreck in progress
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
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
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.
- Heavily revise the vision document to be a useful, accurate, realistic thing.
- Revise the work item / estimates list to be sane.
- Reallocate resources based on the vision and estimates.
- Hold a risk planning session, where the team lists their concerns. Prioritize and
take action to minimize the most important.
- 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.
- 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.
Wideband delphi came up again. Andrew recommended this technique for development estimates.
Gretchen Hartke, Faisal Jawdat, Neil Enns, Andrew Stellman, Scott Berkun (editor dude)