How do you bring a failing project back on track? [closed]

Question

You must have heard the archetypical story of a failing/failed project:

1. A team of inexperienced programmers work 24x7
2. Bugs are fixed only to introduce new bugs
3. Customer is screaming that he could not even do the basic stuff (Saving/Querying) etc.
4. Programmers used to having the spec handed down struggle to improvise
5. No automated unit tests aggravate the situation
6. Architecture document that looked nice on paper was not followed in practice
7. Third party components used become bottlenecks not having been tested for fitness in the first place
8. Milestone after milestone missed
9. The team is not able to come up with a delivery date as nobody agrees as to the quantum of work actually needs to be done
10. No technical leadership / or a Cowboy Coder that can take on the technical issues

Now, If you were to be brought in as #10 what would be your first steps?

Update: First of all: Thanks to you all for chipping in. Well... I'm being brought in as #10. I was the original Architect anchoring the solution when we made the proposal to the client. Then, unfortunately, I couldn't take on the delivery responsibilities as I was assigned somewhere else. :)

Let's say it's a webification of an existing desktop application. I'm now being brought in as #10. Running away, sadly, is not an option. I'm sure this can still be reversed by following agile best practices and just wanted to tap the community for ideas.

The larger question perhaps is this: If the development team does not have specs but only the (baselined) code for a running application, the original solution called for looking at the code and extracting business rules on the fly. Now, the inexperienced programmers are reluctant to look at VB 6.0 code and want documents! So how do you fight this if you were to instate Agile processes?

Answer 1

Vyas, I feel like I could have written this question. My previous job involved resurrecting a KVM project that had failed after a year's development. Specs were in the form of a user manual and developers' experience with similar products. I ended up teaching C to 3 assembly programmers and re-architecting from scratch. We brought the product successfully to market in 4 months. (Then I resigned. Go figure.)

Some of the things I'd do again, particularly with an inexperienced team:

1. A team of inexperienced programmers work 24x7
10. No technical leadership / or a Cowboy Coder that can take on the technical issues

• Give them a (short!) break from the project to "recharge." Maybe a day, maybe an afternoon, or maybe a long lunch on you. It will mark the end of the "old" project and the beginning of success.
• Get their agreement to work their butts off when they return, and promise that you will be their go-to guy, cheerleader, and flak jacket. You, collectively, are a team, and your job is to forge their path, eliminate distractions, and lead them.
• Plan an immediate success, no matter how small, and maintain a "can-do" attitude.

8. Milestone after milestone missed
9. The team is not able to come up with a delivery date as nobody agrees as to the quantum of work actually needs to be done
3. Customer is screaming that he could not even do the basic stuff (Saving/Querying) etc.

• Take small bites! Break each piece down as far as possible, then deal with the small components. You'll identify "gotchas" early and be better able to scope the whole project.
• Define your interfaces. Anytime you can isolate a chunk, do it. This allows parallel development, because you've already decided on parameters, preconditions, assumptions, what happens inside, and return values. You can stub it out, and build other modules and tests independently.
• Prioritize. Focus on the defects and issues that affect the customer first. New features come last. If necessary, defer features rather than delivering buggy code.
• Assign responsibilities. Volunteers are preferred, each in his/her area of expertise, but one person must be accountable for each task.
• Track defects, and record everything that will help you reproduce, locate, and fix them. Document any that remain at delivery time, so the customer won't be surprised.

4. Programmers used to having the spec handed down struggle to improvise
6. Architecture document that looked nice on paper was not followed in practice

• You will create the spec details as you go, each piece just before it's needed. It needn't be pretty, complete, or even written, as long as everyone understands the current task and you've got the big picture.
• Discuss the implementation, one piece at a time, when the developer is ready to code it. Write the skeleton yourself if necessary, and let the team fill in the "guts." You want to keep them focused on each task, without "improvising."
• Be available to answer questions as they arise. Your primary goal is to keep the team productive.

2. Bugs are fixed only to introduce new bugs
5. No automated unit tests aggr[a]vate the situation

• Plan and start unit testing ASAP. If possible, enlist resources outside the team.
• Fix small problems before they grow larger--or get hidden. Confidence in each small piece builds confidence in the whole.

7. Third party components used become bottlenecks not having been tested for fitness in the first place

• Brainstorm solutions when you're not coding. Don't let them stop your progress if at all possible. Can you encapsulate or code around them? Replace them?

General suggestions:

• Stay ahead of the team. Anticipate and try to solve problems before your team hits them. Gather any necessary information before it's needed.
• Communicate constantly. Make it clear that you want no surprises, and solicit concerns, questions, status, roadblocks, etc throughout each day. Encourage collaboration and share "discoveries" across the team.
• Celebrate every success. Compliment a clever solution, bring donuts when a problem is solved, demonstrate a new working feature ... anything that shows the team you appreciate them.
• Get each task done, then move ahead. Don't waste time tweaking, enhancing, or reworking anything that isn't a direct barrier to success.
• Keep your promises to the team, the customer, and your management.

Good luck -- please keep us posted!

Answer 2

Run away or find a new job. This is a death march and they need a scape goat.

Often, the death march will involve desperate attempts to right the course of the project by asking team members to work especially grueling hours, weekends, or by attempting to "throw (enough) bodies at the problem" with varying results, often causing burnout.