Our mid-size development team is doing a multi-year project. We always had major technical concerns that were never resolved. 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. But the project already has significant momentum, and management doesn't see the danger or feel concern about the problem. Although the warning signs of low quality, continuing arguments, and fuzzy requirements are showing. As a project manager in the middle of the project, how should I 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 2-3 months. How do I save a project that is starting to run off its rails?
8 Answers
This is a political question, with all due respect to the (solid) answers that are already here. The answer is to be found in a deep understanding of the goals, motivations, relationships, and psychology of the important players, from management on down.
Since your question contains no insight into the politics, we can't possibly answer it. The only possible way you can save this project is by getting people to start behaving in a different way than they are behaving now. That's politics. It depends dramatically on the people. No two people are alike.
Start by thinking about the top manager. What motivates that person? What does the top manager want?
It sounds like you need to go back to planning and (with the project sponsor's input) clearly define the objective and deliverables for your project. Then get everyone on your scattered team focused on those deliverables. If you need to make major changes and throw away work, it's best to do it as soon as possible. Better to change direction now than let your team members continue working on activities that will be thrown away in the next few weeks.
Great things have been developed out of seemingly chaotic environments.
Use your risk management and escalation processes. Assuming these processes are reasonably performing for you, your risk folks should have these threats--with root cause and triggers--well documented and analyzed. Assuming you report to the project's governing body on some frequency, make this a top agenda item and present to them your threat assessment with several alternatives with benefits, costs, and risks of each. Facilitate a decision.
If they choose to do nothing, then you have a decision to make. Do you jump off the train or persevere? There is a ton of missing information, e.g., are you a supplier or employee, type of contract under which this work is being performed, etc.
Some good advice so far.
First question to ask - does anyone else on the team see it that same way as you?
As Joel said, in situations like these it's largely a matter of politics and approach, so the more team members that you have that see it the same way, the more credibility you'll have. Have a review meeting with those doing the work and compare expectations with progress - is what we're doing going to provide the expected outcomes? If not, then as SB said, document why, and what the issues are, and what needs to change.
Then follow David's advice and bring it to mgmt in a risk review meeting. Present your opinions and the threats as you see them, the solution options, and let them make the decision.
Depending on their response, you will then have to determine, according to your own feelings, your next move.
But from a pm perspective you will have done your part. You managed the project, and you brought issues to the Sponsor for input. Ultimately it's their project and they get to direct it their way. If it doesn't work, at least you were responsible in your actions and did what you could to correct it.
As pointed out by David and Bill... Right away list the current issues/risks and how the impact the project. Prioritize that list... then figure out 2 or 3 mitigation options for the top issues.
Now the hard "fun" part... you have to talk to the stakeholder/manager who is responsible and can make decisions. Essentially point out the top issues you see and what options there are for correcting them.
For architecture & design issues maybe some war rooms, maybe finding 2 or 3 top requirements, break those down with the team and deliver them in iterations...
Essentially it sounds like everybody was handed chunks that were too large with out enough direction as to where things are supposed to fit in a big picture. Fist warning is that you mentioned this is a multiyear project. That, imo, pretty much means it'll go off the tracks unless you have a well defined set of milestones (your choice of doing it iteratively, fixed dates, whatever.)
Go back and get buy-in...
When a project gets off track, I always go back and ask myself two questions:
- Did we set the right goal?
- Did we get buy-in for this goal?
It's absolutely reasonable to revisit these questions...especially as you and your team get new information about the project.
But the buy-in is absolutely critical. If you can't get the right buy-in, you and/or the executive sponsor need to resolve that before moving forward.
Here is a two level approach:
- Tactical: Start document where you are right now. In a complicated software project, you often have pieces that are working well and others that are completely worthless. Also, dig through the fuzzy requirements and try to identify a handful of key problems that need to be addressed. Makes sure that you, your bosses, and the stakeholders have that information for when they re-do/re-plan/re-build a project. If you don't have that information handy, they are likely to start off on the wrong foot (again).
- Strategic: Time to start talking to the key bosses and stakeholders. I find that an approach of "we have risks and we need your input" is better received that "we have problems". If you can avoid the blame game for past mistakes and instead concentrate on what should be done from now on, you might get better responses. However, you still need to be clear that current work is not going to produce a solution that meets people's expectations.
Sit down with your team collectively and then individually and ask them what they think. If their views/opinions align with yours, then that's a good sign. If they don't, then maybe you should communicate with them more often about what matters? Regardless of whether their concerns match up 100% with yours, ask them how they can help you, and you them, to get the project on track again. Good luck.
