How could I have better handled this problem project?

Question

I was working on a project with two other people, one of whom wasn't putting in any effort at all. Since our modules were different, I didn't care about his work at first. After finishing my modules I went home for vacation, since I had been away from home 9 months and my vacation was a long time coming.

When I returned, the project was in its last stages and only the deployment was pending. Due to a crunch in resources I was asked to handle the whole deployment by myself. Soon after I took it up I realised how badly the project was done. For example:

1. Riddled with bugs.

2. No naming conventions, just the default names generated by the IDE.

3. Bizarre deployment approach.

4. A terribly long document riddled with grammatical errors and nonsensical language.

Soon I was putting in extra long hours trying to fix the project. The other people in the project were just citing excuses to not help. The deployment used to take 3 hours; client talks: 2 hours; trying to tell my manager - who handled it terribly - what I talked about with the client: 1.5 hours; fixing the bugs found after last deployment: rest of the hours. I was working more than 13 hours a day.

During this time, the deployment approach was changed at the behest of the client. The client also changed the requirements multiple times. This went on for almost two months, after which the project was scrapped. I was asked to write a report on causes and actions taken which of course no one else could have written.

Is there something that I could have done differently from the start or in the middle that could have improved things earlier? Could something during the deployment have been done differently?

Answer 1

There are a whole stack of issues here:

• No leadership
• lack of standards over coding/design patterns etc
• No QA or testing
• No code review
• A lack of concern, the person's lack of effort didn't bother you until you had to clean it up.

The team has fundamental issues, in fact you aren't a team at all. A team collaborates and takes care of each other and doesn't leave the other members in trouble like this.

The person's bad input is just a symptom, not a cause, the root issue is at the team level, and your employer needs a leader to come in and address it, someone needs to set standards and ensure people meet them, everything else is just symptoms.

Answer 2

Whoever was responsible for the whole project messed up massively. So if I understand this correctly, for nine months three developers worked without any oversight, one (you) did a good job, another one put in a good effort with unknown outcome, and one did a rubbish job. The person responsible didn't notice anything. You noticed that one person visibly didn't put in any effort.

Assuming that you were not the one responsible for the whole project, but responsible for your part, the lesson should be that if your project fails it doesn't help much if you did your job. The project failed. When that happens, your whole team could get fired including you, and nobody cares who worked hard and who was lazy. Or the person seen as guilty could get fired, and if that lazy colleague is much better at office politics than you, then you might be seen as the guilty person.

So the rule is: Do your job, but also do what you can to make the whole project succeed. Or try to move to a project that will succeed if yours is going to fail. You should never ignore things that will make your project fail, because the outcome will not be good for you.

So you should have raised concerns when you saw problems and not ignored them.

At a level which is really irrelevant to the workplace, but relevant to software development: Code reviews are absolutely essential. You wouldn't have been in the mess with code reviews. Unit tests are really useful to make sure that your code works (and they need to be reviewed as well, to check that they test something useful).

Answer 3

Communication is the key for any project with more than one layer of responsibility overall. First thing you should have done when getting a new role after vacation, is to analyze and report the current state of affairs.

This would have put a clear line of succession from previous leadership and you.

After that, logically, you had to create a plan for each issue point in your previous report, perhaps even with estimated timelines for fixing it.

As per client requirement: How did communication go? Did you have a dedicated analyst to communicate with him?