Project Management

What to do when your solution doesn't work

If you roll out a solution that doesn't work, your payment and your reputation could take a hit. Here's how to show the client you're on their side.

Market-based economies typically only reward success. The practice is brutal, though efficient. If you try really hard and get 90 percent of the way to the goal, that's progress, but it usually won't get you paid. That's why the second-most frustrating experience technology consultants experience is deploying a solution only to find it doesn't work as advertised. (The most frustrating experience is rolling out a successful solution and failing to get paid by the client.)

Technology's complicated

Here's the scariest part: Technology consultants can properly audit a client's network and systems, thoroughly research potential solutions with third-party hardware and software providers, and even receive written guarantees, but it's the consultant who must make it all work. And, sometimes, it just doesn't.

Routers and switches sometimes ship with failed or corrupt firmware; software applications occasionally don't do what manufacturers promise; equipment may be dead on arrival; hard disks fail; motherboards flake out; network cables go bad in the wall -- I've seen it all. Honest consultants who've been practicing for at least a couple of years will have such stories.

What should you do?

The client is hot, and your reputation is on the line, and what you do at such a critical juncture is one of those moments when you'll learn whether you can make it as a consultant. Surprisingly, judging from failed projects my office inherited, some consultants shrug their shoulders, insist they've met requirements, and wash their hands of the project. Others blame the vendor, hardware supplier, software programmer, or other party. Those actions don't solve the problem.

Consultants should follow these steps, instead:

  1. Admit the problem. If something's not working right, tell the client and explain that your office can replicate the failure. There isn't much that infuriates a client more than encountering failures and being told the system is working properly.
  2. Come up with a plan. Determine the next steps. Try to isolate potential causes, document what you know, and then determine who can help fix it.
  3. Share the plan. Clients may only see that their big investment is failing to work. If you tell them what you've done and what you're doing and why, that should provide the client with some peace of mind. If nothing else, it lets the client know you're working on the issue and aren't abandoning them or the project.
  4. Partner with the responsible vendor. Rain all over the apparently responsible vendor, and it's unlikely the company will call you back. For better or worse, you're married now, and you need to make the relationship work. Try to position yourself as the boots on the ground working to make the vendor's product work for the client.
  5. Document everything. No, this isn't CYA documentation (although that mindset doesn't hurt). Document who you talk to and what steps are taken and when, and then share that information with the client. Occasionally the process helps to highlight something that was overlooked. Other times forcing documentation helps isolate or trace a failure in ways that weren't previously evident.

Success is borne of commitment

Technology solutions are too interconnected, too interdependent, and simultaneously incompatible to not expect failures and strange errors no one has ever seen before. While you can't plan for all contingencies, you can prove your mettle by sticking with the client and proving tenacious when projects threaten to go off the rails. Failures are going to occur, but the way your office reacts will determine whether you find success.


Erik Eckel owns and operates two technology companies. As a managing partner with Louisville Geek, he works daily as an IT consultant to assist small businesses in overcoming technology challenges and maximizing IT investments. He is also president o...


I had a project that required a 3-d video card. I did the research, and selected a card that looked perfect - but did not have a chance to try it out first. I get to the customer site, install it, and the available drivers will not put the card into 3-d. I used my prior research, and selected another card, called the vendor, and got a verification that it would work (the first vendor claimed the same until I was actually on-site - sigh). I went to the client and explained the situation, and how I was going to fix it with another card. He bought the second card, it worked, and was happy. I gave him my invoice, and explicitly comp'd him the 3 hours it took for the second card. He was very happy. So - be prepared to eat some time, but note it on the invoice to educate the client. It also can make you look very good - you are willing to take responsibility for your errors, even though you did your best.

Englebert should not be at roll-out time. The client should be kept abreast of the solution throughout it's evolution. There should be no surprises at roll-out time. There are a few exceptions to this, but generally it is imperative that the IT Consultant keep the Client close to the solution before roll-out.


Nice article. I, too, am amazed at how many consultants will walk away leaving a clients system in disarray. I really don't know how they can do it... I could never show my face near them again due to embarrasment. I agree with the steps outlined in this article, but I would always make "Come up with a plan" step #1. Step #2 then becomes "Admit the problem" and "Share the plan" combined. Honestly is important in these situations, but just telling the client "there's a problem" isn't going to help much. Saying "There's a problem, and here are the steps I propose we follow to rectify the situation" is much better. I'm totally with DWPNS - setting expectations upfront is key. I'm nowhere near as formal as he is (but that's probably due to the nature of the work I do - I generally do desktop and small server rollouts). The intent is the same though. Thinking about it now, I actually do this more than I realised... I'm constantly doing it. Even on the rare occassions when a job goes smoothly I joke with the client about how I must be overlooking something because it's never this easy. I agree too with reisen55's observations. Client views are warped. As techs we know it is normal for things not to work first go. The client doesn't know that though. Pretty much every other industry is far more predictable than IT. If you build skyscrapers you can take the same formula you used for the last ten you built, apply it for the next one and you can expect the result to be the same. In IT you could apply the same software in the same way ten times and get ten different results, due to differences in their environment. Is this ignorance on the part of the client? Well, maybe, but I think it's reasonable ignorance. Even if you don't agree, you will need to deal with it in order to keep clients as happy as possible. In the case of the laptop hard drive replacement giving an indication of likely cost or labour involved up front may have helped, and calling the client with an update once you realised the HDD was bad and giving them a price to replace it (plus an updated estimate for labour) would have helped a lot too. That way the client can decide if they are happy with the price before being committed to it. A lot of people will say no and buy a replacement laptop in this scenario.


The view of the client can often be warped too. I have solved a few troubles for clients over the years that I SEE is fixed but they don't, usually due to technical limitations which is to read: ignorance. You have to be good, very good, and down talking tech to a common audience. Just rebuilt a laptop for a neighbor yesterday, the drive was dead so put in a new one, new OS and got all their data back. OK, good job? The laptop itself, it is a Toshiba, may be flaky ITSELF which equals a bad laptop. They made one protest about payment but paid any way. Still, ignorance. Hey, you got your OS, software and data back!!!!


I find that managing expectations up-front goes a long way with clients. I start every project with this, "Unlike what you've seen in the movies and TV, I can't quickly punch some keys and have your system flawlessly implemented in 5 minutes. Many forms of technology must interact with one another flawlessly to create a perfect system. Be advised, the first implementation will need to be tweaked. This is not a failure, this is the normal process." Then when I roll it out and the inevitable happens, no matter how major or minor, the client just repeats what I say, "This is normal, huh?" Always maintain your cool and don't blame anyone. It's all about managing expectations.


I have faced some of the same promblems in my time. Many of the points you make should be coverd in any contract you sign with a client.

Editor's Picks