Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
The situation is: A developer has apparently been working on an important project for a year and hasn't been able to get the product in a commercially usable form.
Im sure there a plenty of situations that someone has to resurrect a project.
What we need from a developer to help ensure a smooth transition?
"No bad soldiers only bad generals" Napoleon Bonaparte once said.
Let me rephrase him. No bad developers only bad managers. Start this transition from the analysis of your own mistakes, which are:
Also, this article may help you: How to Fire Someone Right
If that developer hasn't been producing and was a bad choice for the project, then there isn't much more he/she can possibly contribute.
By bringing in another developer to take over the project, that developer is going to need to look through the entire project and make a determination of whether or not there is any value to any code written so far.
Ramp Up Period for New Developer
You'll need a developer who is capable of reading code, not just writing code. Many developers' first instinct is to toss out any code and just rewrite from scratch. That's not always the best decision, and you'll need to make sure the developer taking over knows the difference between something that can be brought to market with determination and elbow grease and something that is not salvageable.
Project Manager Must Understand Learning Curves Exist
The project manager will need to understand that the developer taking over can't just jump in and immediately show results. There will be a learning curve, and it will take time for the developer to assess the current state of the project.
Goals of Project May Change Based on Stakeholder Communications
Additionally, since it's an important project that is now a delayed project, the goals of the project may have changed. For instance, if time to market and timely delivery is critical, the PM will need to make sure the developer understands that -- if at all possible -- he or she absolutely must work with what the previous developer left. That means that things might not be perfect. The decisions here largely depend on the client/stakeholders and what their needs are.
In summary, the project can be salvaged, in most cases, but it takes having the right people take over, having a clear understanding of what the modified goals are of the project, and maintaining excellent communication with stakeholders.
In the ideal situation I'd start with a quick analysis what went wrong and why. It is possible that developer is a problem but it's also possible that the source of the issue lies somewhere else.
If you're sure you should address the problem to the developer it would be a comfortable situation to have someone other to work with the current developer hand to hand to take over the project. I could go into details here (like having both developers pair program) but well, we rarely live in the ideal world.
The next important answer is what happens with transited developer. If he's fired you'd tackle the issue differently than when he's moved to another project. In the latter case you can expect much support for a new person in the project. If the former is true, it's tougher issue.
If you have enough time you can ask to document the work, which would help to take the project over. If you don't I wouldn't reject quick and dirty method which is overtaking the project in whatever state it currently is. Actually I did a few times and I'm always surprised how easy it went comparing to the hell I'd expected. A bit of well-tunneled motivation works miracles.
Openness to answer questions from the new developer while the new developer gets up to speed.
Learning someone else's code can be challenging. Having the original developer available for questions can make all the difference in the world. That's not to say the new developer will use what the old developer wrote, but it provides a frame of reference in understanding the approach they were taking to solve the problem/deliver the solution in the spec.
With that said, you do need to have a good specification describing what it is they are supposed to be building.
As a manager, I would make a list of all the skills needed for the job - technical skills as well as soft skills.
The statement made by yegor256 is right. As a manager I need to be clear of what is needed in a resource to be able to make my project a success. So if the developer does not have enough experience, or enough brains to debug things, or enough teamwork to ensure they work with the team to produce good results - then it is my problem as a manager that I recruited this person.
I would immediately concentrate on what I 'can do' and get another developer, but first learn from my mistake of recruiting the other guy.
Some qualities I would look for:
It is difficult to get good people, and even more difficult to retain them. Sometimes people who are good at what they do display an arrogant attitude. But not all people with an arrogant attitude are good at what they do.
If the developer hasn't been able to deliver it (in a year) then look for mistakes somewhere else.
