Got in over my head on a project, how do I tell my boss I can't do it anymore?

Question

I have been working as a Jr. Developer at my current job for about a year and half. After been at my job for about 5 months I volunteered to do complete rewrite of a very old system that the company had. At the time I said I would do it I was confident it would take a few months at the most, but it has now been over a year since I started to work on the projected and it has proved to be much much harder then I expected.

I just had my review for the 2013 year and it was mentioned that this project is running much longer then I had stated. The biggest things that have caused the project to run long is that I had to learn a whole new coding style (I knew this going in) and I am required to use a framework that was developed in house and is way above my ability to understand and build off of.

Looking at this project now I am fairly confident I can no longer complete it within the extra time given to me (it is now one of my 2014 goal to complete the project). How do I best explain to my boss that I don't think I can complete this project in any decent amount of time and that I should no longer be the developer for this project?

EDIT: Everyone is assuming that I saw this project as a failed project within months of starting it, that is NOT THE CASE. I know the project was going to be hard but I thought I could handle it. Every time I hit a wall in the project and I was able to over come it I thought I could keep going. It has only been over the past few days I have come the realization there are too many walls left and I don't have the skill to do this project.

Answer 1

Some questions that you'll need to be prepared to answer:

- What have you been doing all this time?

Be prepared to show work and discuss hurdles that you have been unable to jump over to accomplish the job.

- What do we have if we stop now? Is any of this salvageable?

Hopefully so. If you have part of the system working, show it, as that can take some of the sting away.

- Why didn't you come to me sooner?

This one is going to be hard to answer. As a junior developer, you probably were blinded by hubris. Most projects' estimates come in under their actual completion time. This has gone from months to years, so some big explanations will be necessary.

The bottom line is your boss won't be happy with this, but you're a junior dev, so mistakes are expected. You need to fess up to them a lot sooner in the future. I don't think it's a fireable offense, but it may be a write-up or some sort of verbal warning. Good luck.

Answer 2

In addition to Garrison Neely's excellent answer, I'd advise that how you say this is almost as important as the fact that you say it.

Instead of something like I failed; I can't complete this project, try framing it more positively - something like I'm hitting a wall, and need some help from a more senior resource to get past it. In addition to allowing you to potentially salvage success here, it serves a dual purpose in explaining why you're behind schedule, as well as proposing a solution to that very problem.

Answer 3

I second anyone who tells you that you need to tell your boss ASAP.

• Give an unadorned status report on the project but don't just say you failed - such a succinct assessment would stick to you like indelible black ink on a white shirt.
• Start your status report by saying that the project is behind the schedule you had worked out, then go over the parts that went well and the parts that didn't go well.
• Don't just go over the parts that didn't go well, because if you do, you will give people a distorted perception of your abilities and your efforts. Let them work out what they want to do next.
• Lastly, Cut out the volunteering for anything for a while.

Answer 4

As you are a junior developer, treat this as a learning opportunity. One of the things that a junior is usually not expected to be able to do is to oversee the scope and consequences of tackling a large project as the one you are involved in.

The best course of action now is to schedule a meeting with your direct supervisor and admit to him that you are in over your head with your project and that you would like some guidance in how to proceed. You can expect some tough questions, like the ones in the answer from @GarrisonNeely, but the most important thing when answering them is to tell the truth and not to try to make things look better than they are.

If you have a good manager, admitting that you are in over your head as a junior developer is not necessarily a bad thing. It is possible that your manager already knew that you wouldn't be able to complete the project by the new deadline and is waiting for you to step over your pride and admit failure yourself. I would value that more than having to forcefully pull someone from their task because it has become obvious that they can't handle it (yet).

As for the future of the project, it can go in several directions.

• It can be dropped altogether, especially if the project wasn't that important to the organization in the first place
• It can be reassigned to someone else, with you getting a job that is a better fit to your current capabilities
• You can get additional, more senior, developers assigned to the project to help you out.

Answer 5

If you are planning to bail out, present argumentation why you are need to do so. If your plan stretched that far, you need to have strong arguments. In this case, prepare a project plan for the upcoming, say, 6 months of work, and prove that none of those work was anticipated when you started. Give as much information is possible. Include why it's been over a year, and what extra/unexpected work has been completed to date.

Once you have an overview of your past performance, as well as your future expectations of yourself, you can present this to a manager with something like "According to my observations, this is taking longer than expected. Here are my findings. Due to this reason and this reason (put some strong arguments here), it may even take longer than that. Should I continue working on this project?" With this, you are effectively saying, "Yes, it's taking longer than expected, but I kind of know where I am going, and where I went wrong in the past, but I also let you, the manager decide the outcome". Managers like to decide, so you get a +1 here right away.

For future projects (I am assuming you are not gonna drop development work just cause you failed once), never take on something you perceive as complicated. Chances are you will either never complete it (like this one), or it will take longer than expected and the benefits will not be worth it (from the management's perspective).

Instead, take work that you find super simple (and achievable in less than a day). It will often end up stretching 4-5 days, so you will learn how to estimate, but also the company would not lose as much money on you. Fail fast, and often. Remember, you learn from your mistakes, not your successes.

If there is no small work, try to break down the work you have into small self-sufficient pieces, i.e. each one should have a value and stand on their own. You need to estimate your work before you start it. I.e. never have something like "well, it's a research task, so it's gonna take 2 weeks, maybe a month..." Know the area, know the questions are going to solve.

If you don't know what exactly you are researching, don't commit to a time frame, say "I need 1 day to build a project plan for my research, I'll provide an estimate then". Use this time to get a better understanding of your problem.

If you cannot make an estimate on a task, you don't know what you are doing. Don't start a task, if this is the case. Get more information, until you are absolutely confident it will take X days. Sometimes it helps to use your past experiences, i.e. "this should take 1 day, but a similar task 3 months ago took 5 days, maybe I am missing something..."

Answer 6

It sounds like you are including some assessments you are not qualified to make, such as "[the framework] is way above my ability to understand" and "I should no longer be the developer for the project". These assessments will require your boss to do some extra digging to find out what actually happened, what should have happened, and what should be done now.

Rather than focus on such assessments, your focus should be to provide your boss with specific factual details about the project, including specific limits of your understanding. For example, "I worked for 3 months on rewriting the login component. By this time it was supposed to interface with LDAP, and it still doesn't. It does statefully track login attempts. Since I don't understand the LDAP hash protocol, I don't know whether the code I wrote can be adjusted to interface with LDAP, or whether it requires a totally different approach. ..."