We have been on the project for 10 months and the client is not happy with project. I have 8 guys doing work on this project, and the client is just not happy with the progress. The project is very, very complex, and as my main programmer said ... having a new team doing this mid-stream would bring them basically into a deep sea of code that they may not understand well.
My question is - what suggestions do you all have in transitioning off to another team or other developers? I know how it is: no matter what project, if there is existing code, the new programmer is going to say it is not written well. This poses a problem for me, as the client has paid a lot of money up to this point to get it developed, and we are just no longer pleasing him.
You may want to consider sitting down with the client and discuss this with them at length. They may not realize that going with a new team is going to cost them more inasmuch as it will take a substantial investment of time for the new team to just familiarize themselves with the current code base. Is it possible that your team and the client can re-align and move forward? It might be worth considering bringing your strongest programmer to a lead position (if you haven't already) and dropping a few of your weakest members and replacing them with new developers. It is easier to familiarize a few people with an existing team and code base than it is to bring in an entire new team.
This is an old story and most of us who are in the offshore development world have been through it. Before you talk to your client, I would be sure to have 100% clear position on where the project is, if the project is actually poor or not, and whether it's a good idea to switch teams mid-project. These are huge decisions and although the client is ultimately in charge, it's up to you to give strong, confident advice about what to do.
What is your personal opinion on the team's progress? If they are doing OK and there is no chance that another team will do much better, then there is little to be gained by going through the pain of changing teams. If they are sluggish or burnt out, then so be it but that decision has to come from you first and only as a last resort should you agree to such a drastic move only because the client asks for it.
If you are to change, you need to do it quickly. You need to do it aggressively, and you need to make sure that the previous team provides all the assets and if possible they stay on for an overlap period. You can usually negotiate this with a good team if necessary.
If you really get into a jam, there are people like me who specialize in bail-outs of trouble projects.
Out of curiosity, what is your relationship with the team (i.e. are they a permanent team of yours or a first project, etc.), where are they located, and what language/environment is the app in?
First of all, before you accepted the project you need to make sure that your developers can handle the job.
If that's the situation now, you need to talk to your client and ask for an arrangement. If you're looking additional experienced programmers, we can definitely help you out.
Sometimes the client's expectations are not reasonable, especially if they are not programmers. Non-technical people think we just push a button and it's done. Because that is how they use programs. They don't understand there is programming involved in making the button do things.
And sometimes it could be that the client doesn't want to pay, or can't pay, and they're looking for things to complain about.
You really should get the clear view if the project is really poor, not the client tryin' to avoid paying you. Humankind remains the same, I'm afraid
Have you considered that a factor to consider why your client is unhappy is because of your programmers? Eight people doing the project and the client isn't satisfied? How long have you been working with your staffs? Or you just hired them for the project? Sometimes the mistake there is how "skillful or knowledgeable" your staffs are. Have you tested their skills before you hired them or you hired the because of how well they answered your questions? One major mistake managers commit is that they are complaisant with where they got their employees: ei. from monster.com or careerbuilder.com unknowingly that those whom their hired are inefficient and incapable. That's why trial is very important before hiring.
So it's either the staff is not good enough for this specific client OR the client doesn't know what he really wants for the project.
Actually managing a big project is tough to handle properly. But if you'll take some steps project will be much easier than before. Divide your project in modules [sections] and assign that module to specific programmer. Do not him more work to that programmer til he end his recent module. test module after completion and integration. When it'll pass then you can submit another module to develop to that programmer.
The OP seems to have lost interest in the question, so there's not much point in continuing to offer suggestions.