How do I fix my reputation with a client when I fell through for a project?

Question

So I've run into this predicament. I over-loaded myself with work and not enough time. Then, I became ill a couple of times which set everything back even more. Long story short, I had a communication break down with two clients and feel like I've ruined my reputation; even if not publicly I feel I've let myself down. I've spent more time apologizing for missing work than actually demonstrating new features and staying available.

One of the clients is fine. I explained the situation to them. They decided we could step back and do fewer hours. I never heard from them but I imagine that's simply because of the holiday season. Regardless, it's sort of on their shoulders now whether they want me back.

The other client is whom I'm very worried about. We got pretty deep into his project. It's a very specialized piece of software that he can't/won't handle and he's invested a small sum of money into it. I don't want him to lose out on his investment nor do I want to come crawling back and feeling pitiful. I want to make things better. Especially since I know how hard it is to find people to work on things like this for a reasonable rate and it'd be a pain for someone else to try to step in and pick up where it left off.

As an independent developer, my livelihood depends upon my reputation. Not only that, I actually became slightly depressed, extremely stressed, and even un-motivated because I let myself get so far behind on everything and didn't live up to my own (or their) expectations. Not once did the client treat me bad and he is a very great person to work with.

Do you have any suggestions on how I can fix this situation? I still don't have a lot, if really any, free time. I'd love to just say I could finish the rest of the project for free but I honestly don't think I have the time nor spare brain power to see it to completion. At least not with the depth of customization and agile-development we had taken. Even if I never do another independent development job and can ignore my reputation, I still want to fix this so that client isn't left with the bad end of the deal. I've been beating myself up over this and that's not doing either of us any good.

So, what are my options to try and repair my relationship with these clients?

Edit: I just wanted to include some technical details. I was not paid up front for this project. We decided on a bi-weekly payment. In fact, I'm actually behind on payment. However, I'm not worried about the pay. It's seeing this client's project followed through and not being able to meet his or my expectations that's making it a very stressful situation. I'm just hoping there's someone who's been there before, on either end of the relationship, and can give me some good advise or options I hadn't thought about.

Answer 1

Kurtis, I ran my own business for about 7 years, and I completely understand where you're coming from. As I see it, you have several issues:

1) You are either not able to accurately determine what you can do in a given time, or you see it quite well, but are not willing to commit to less than what you think the client is expecting of you.

You're actually still doing this, even though you see that not only is it getting you in hot water, it's not doing your clients any favors. So, you say that you can't afford the bandwidth to truly see your client that you're mostly worried about safely to the end of the project. This suggests you are doing other work for a different client. Focus on keeping that client happy, or you'll wind up with three really unhappy clients under your belt.

You need to learn to estimate better. What works for me is to break the project up into all the tasks that need to be completed, and estimate each of these. Until you're confident that you are accurate, then add at least 25% extra, because tasks will take longer than you thought or there will be ones you forgot. You're better off adding more like 50%. Always under-promise and overdeliver. Bear in mind that poorly-written code will make it almost impossible to estimate accurately, so always strive to write the cleanest code you are capable of at that moment, even if it seems that it will take longer in the short run.

Make sure you identify areas where something could hold you up that is not your fault (waiting on assets from designers is one of the ones I see a lot) and spell out what the impact will be. Most clients I had never listened to this, but it's better to say it than not.

Even if you elect to stop freelancing, this skill is invaluable even in an employee. My current employer constantly tells me that he appreciates that I can give him really accurate estimates for when things will be done.

2) Someone in the process doesn't "get" agile.

In each sprint, you should have a goal of something that is in some way functionally complete (it's not always realistic to say releasable, but that's the gold standard). At the begning of each sprint, you should have a sprint planning session where you essentially decide what tasks in your list (see above) you can commit to in the sprint. If that is not going to be acceptable to the other stakeholder(s), you need to negotiate a reduction in scope for that sprint so that you can have something that's more or less complete at the end of the sprint.

One thing that a good scrum master will know is that a new team can't determine its velocity accurately until several sprints have gone by, so your client should not have any particular expectations of what your velocity should be until you're 2 months or so into the project.

My own experience of Agile is that it tends to be very unforgiving of things like illness or even meetings, because the commitments we make at the beginning of the sprint don't usually take them into account. This might not be a weakness in you, but instead could just be "the way it is" with Agile projects. Good project managers should have a backup plan for if something happens to a team member, but clients who are good project managers are relatively rare.

The important thing about Agile is that you can give a good prediction of what you'll get done that week. Many if not most places that do Agile feel that Test Driven Development is integral to the process, since it can prevent many of the bugs that can take unpredictable amounts of time to track down and fix. In addition to this, if you have tests for all your code you probably won't feel that another developer couldn't come in and pick up the project if you can't continue.

Finally, more software projects fail than succeed, so expect that this will happen from time to time, even if you become better at managing your commitments.

In a nutshell, you know already that you can't do what you feel like you want to do to make this client happy. Probably the best thing you can do is to recommend another developer, as has already been suggested. Focus on making sure this never happens to another of your clients moving forward, and count it as part of your education. Chin up, your failures probably contribute more to your long-term maturation as a developer than your successes.

Answer 2

To some extent what you have suffered is a typical IT project management failure; its not unusual as some studies suggest that 70-80% of IT projects fail to deliver on some aspect of the "iron triangle" of cost/quality/time.

There's a company here locally (in NZ) that used to advertise that it was "the putting right that counts" - you are correct in that how you chose to resolve this issue will have a big impact on your reputation.

To me, the critical elements of a good "business" apology are :

• acknowledging where you have not performed well, and apologising for this.
• indicating what you are going to do to fix the issue
• indicating what you have changed procedurally to prevent this from happening again

Fixing the issue

Normally we try and fix things at our cost; but this is hard to do if you are a sole contractor. (I run a small team, but in a big organisation.)

I have deployed people to the client's site overseas at my cost, waived fees, offered "free" project time and even processed the client's data on the cloud at my cost. Exactly what you can offer here is down to your business model, but usually for the "fix" to be taken seriously you need to meet some of the costs that have been incurred.

Making sure it doesn't happen again

Firstly, anyone that employs you as a sole contractor is taking on significant "key person risk" - if you get hit by a bus, the project is dead in the water. Even small teams face this, and when running a services group I have lost contracts on the basis of key-person risk from the client side.

I'd suggest getting some (legal) advice on how to manage this effectively - you might need a combination of careful wording in your contracts and some form of business insurance.

Secondly, you make some comments on Agile - one of the key parts of that process is the "continuous improvement' loop of the retrospective; including the client in this process may help to keep the communication channels open.

Finally, if you are using Sprints, keeping these short can help in situations where there is either a lot of risk, communication issues, or a lot of uncertainty. There's only so far wrong a project can go in a fortnight!

I would add that it is well worth investigating and understanding why IT projects fail; there's a lot of research online into this field, and it can really help you de-risk your work.

Answer 3

Sounds like the big issue is the client with the difficult project, that's significantly far along, who can't easily find a replacement.

From the list of limitations it sounds like:

• You can't spend much more time on this project (regardless of money offered)
• They can't easily get a replacement
• The project is quite a ways from being done
• Some money has been spent- it's hard to tell whether the money spent and the progress thus far are at all comparable.

Something's got to give here. Either you need to back out of the project as honestly, cleanly and quickly as you can make the communication happen, or you need to figure out what you can do in your own life to see it to completion. But doing this halfway - saying you'll do it, and not doing it, is the one thing that will lead to ever greater frustration on the customer's part.

My list of to dos would be:

• Be honest and clear - absolute, number one - if you haven't been clear about the progress and the time to complete the project thus far, it's time for a big, unpleasant meeting where you lay it all out. If have been clear already, this is easier, but it's time for an honest talk about the project's future. You need to be clear with yourself on what you can reasonably do and what it takes for you to do it - if you can't work for free, you can't work for free. If you simply don't have time, you don't have time - and you need to be able to forecast this.

• Have a recommendation - chances are, your clients are not skilled at what you do. Have a recommendation ready - what will it take to finish the work? Who can finish it? Can you recommend a collegue? Can you help them find someone new? Can you be there for the transition to help the new person come up to speed? If so, how much time in a week can you really spare and what are the limitations?

• Stick to a schedule - Thus far, it sounds like work has been spotty. Make sure you have a schedule, make sure there's something reliable and repeatable booked for keeping in touch with the client, so they know when they'll hear from you and be able to give you feedback and get a fast response.

• Consider a refund - if you honestly feel you've taken money for work that hasn't been performed, offer a refund if you can't make good for free.

There's the inevitable iron triangle of time, money and quality - if you've taken money over time and produced quality, you can offer to return money, or take more time and get it done, but that's about what you do to change the fact that quality product hasn't been provided. You can move around the three factors, but if you want to do something more those are really the three things you have and something's got to give.

As a side arm, though, there's quality product, and quality communication. If you think that the real barrier is that you've been unreliable and hard to communicate with, you can change this by changing your behavior. If you have reached a point where you can continue on the project, make sure that you change the pattern of communication so the customer feels confident they can reach you, get a fast response, and know that progress is now being made.