Discussion on:

What to do when your solution doesn't work

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.

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.

http://dangerousintersection.org/wp-content/uploads/2008/05/problem-solving-flow-chart.jpg

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!!!!

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.

...it 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.

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.