Write

Taking On A Failed Project

It seems like every couple of weeks I get an email along these lines:

We have a website that cannot be completed by the current developers….is this something you would like to work on?

Over the years I’ve responded differently, from simple one-line “no thanks” to more involved responses declining the work.  I thought I’d write up a more detailed blog post both to record my thought process in responding and as way to have a link to send out in the future when these requests come in.

Who Fired Whom?
As the potential late-comer to the project, unfinished projects are little mysteries waiting to be solved, and you’re asking me to put on my trenchcoat. 

You are only telling me one side of the story and using vague words that make me suspicious.  Are the current developers unable to complete the site because they don’t have the technical savvy? Or the developer doing most of the work took a new job?  Did their salesperson over-promise? 

Then there is the other side of the coin - what if the current developers have stopped working on the project because you stopped paying them?  Or you were a horrible client with shifting expectations and schedules?  Did you not, as a potential client looking to spend thousands of dollars, do your due diligence in finding a development partner capable of building what you needed?  To be a bit crass, why are you coming to me now in “salvage a failure” mode but not when the project was new?

All of this is probably answerable with a few uncomfortable phone calls to both parties, but maybe not. Will you be totally upfront about these issues or gloss over them in hopes of getting me signed on? Either way, will you compensate me for the time spent researching the project history?

Increased Costs
Speaking of getting paid - does the project have any budget left? Or has the current developer soaked up all the profit leaving the nit-picky (and time consuming) details undone that are tough for me to quote or you to pay for by the hour? 

Don’t forget the reverse-engineering time. A web project is not a web project. Different developers have different methodologies and any half-baked site that’s getting turned over to a new developer is going to need to be reverse-engineered by the new guy. If your current developers did a great job documenting what they did this might be easy, but if they aren’t able to complete the work what are the odds of them doing a good job with documentation? More likely I would have to go through everything line by line to get a sense of the build approach. That time also needs to be compensated, so are you prepared for spending more than you initially budgeted to get this project done even though the scope hasn’t changed?

Possible Junk
What if the existing work sucks? I’ve logged into some sites that were horribly built and not even close to something I’d feel comfortable delivering to a client or having my name associated with. Are you prepared to pay me several hours time to both investigate the failure situation and reverse-engineer the site only to come back and tell you it’s a lost cause?

High Risk, Little Reward
Projects in failure mode are risky. People involved in trying to salvage them are tense - someone expected this thing to be done by now and it’s not. Trust has already been broken so the second guy is going to have to work harder to earn it. The project now has baggage - the initial developer will continue to be the elephant in the room during the rest of the project development. Budgets are usually thin and it’s hard to justify spending even more money on something that’s already a failure. The second guy isn’t responsible for the project being in failure mode but is expected to take on the stress of getting it done - a virtual super-hero flying in to scoop up the fallen heroine and fly her to safety just before the earth cracks wide open.

Ultimately the risk is only worth it if either the reward is greater than taking on a project in non-failure mode or the potential second developer doesn’t have any other less risky and stressful projects to do. I’ve never needed the work that badly and haven’t been able to bring myself to charge significantly higher rates to a client in this position. But that doesn’t give (possibly innocent) clients in this position a way out of this mess.

Any Advice?
How about you other developers?  Have you taken on a project in failure mode? How did it go? Are there ways to surmount the challenges as the newcomer to the project? Or did it end as it began? Would you do it again?

Comments are closed, but you can read the comments other people left.

  1. Matt Weinberg on December 31, 2011

    Thanks for the post, Mike. I know exactly what you’re talking about, as we often get inquiries like this as well. The first thing we try to figure out is whose fault it was. Are we just walking into an awful situation?

    One thing we’ve noticed is that the more bad things the prospective clients says about their old developer, the more likely it is that the issue is the client’s fault. A professional client may say something like “It just didn’t work.” In many cases, that’s legitimate—sometimes it just doesn’t work between two companies. But if the first 10 minutes of our initial call are spent with the client complaining about their old developer, we walk away. That isn’t a professional client and it’s likely they’ll find reasons to dislike working with us as well.

    Excellent post though, and a big issue.

  2. Paul Burton on December 31, 2011

    You’ve only got two possible choices in this scenario: Politely decline the job or ask as many questions as is necessary to learn the true nature of the situation. Then make your decision.

    You aren’t simply dealing with a failed project. You are dealing with a client who is predisposed to not trust you.

    And it makes no difference who was at fault in the previous relationship.

  3. Nevsie / Modeten on January 02, 2012

    I often find these projects to be full of pain - but yes a few calls can easily resolve the issues.
    Of the projects i then choose to take on often i find this the most rewarding to show that not all web guys are idiots outsourcing offshore without a clue, and then the clients become the most loyal.

    But then again I recently fired such a client - who was a good payer and earner, but an old phrase from twitter “your lack of planning is not my emergency” occured on every project and the stress got to me.

    Loyalty and regular clients are good - but you can also become too tied to such clients leaving you in a cannot say no situation and as you would not like to lose them. So do not always say no…

    But regulars - you know how they pay… new can be more risk. I guess it depends how busy you are - and the Boyink seems to always have enough on his plate…!!!

    Last note - recently took on a project that was done by some famous EE author and who now runs a big agency and it is rewarding to see the work they do not being above and beyond my own skills level - programming and custom modules aside!!!

  4. PXLated on January 03, 2012

    Did one of these this summer. Talked to both parties involved, neither bad-mouthed the other, both were at fault in their own way.

    I was recommended to the client by one of their trusted sources so I came in more as a savior so they weren’t predisposed to mistrust.

    In general though, I agree with almost all of your thoughts on this Mike.

Back to Article

Commenting is not available in this weblog entry.