As a firm that builds things online, we often talk to potential clients that are unhappy with their current development partner.  Usually the break ups are amicable and there is a logical explanation for the change.  Fresh ideas are needed.  Requirements have evolved.  Personalities just don’t fit.  But sometimes the client is angry and feels let down.  Timelines weren’t met.  Budgets skyrocketed without explanation.  The work product was buggy.

Having worked in digital for 10+ years now, I’ve been on both sides of the situation.  I’ve been the guy poaching the work and I’ve been the guy that let the client down.

The truth is building things is hard and it is inexact.  No matter how talented or hard working or well intentioned you are, you are going to screw up sometimes and piss off a client.  It will happen.  To shed some light on the client-consultant dynamic and how things can go wrong, following is a list of the five most common complaints I hear people make about their web development partners and the steps we are taking at the Brick Factory to avoid having these complaints made about us.

(1) Lack of responsiveness

I can’t tell you how often people come to me complaining that their client representatives simply don’t return their calls or emails in a timely manner.  This just baffles me.

Consultants are in the customer service business.  When a customer calls or emails you, you need to get back to them as quickly as you can.  If a request is simple, just do it right away and be done with it.  If it will take time, acknowledge the request and let the client know you’ll get back to them.  People want to be acknowledged.  Silence is often interpreted as apathy, or even an act of aggression.  Being responsive will preempt a lot of problems.  It is amazing how many firms/people don’t get this.

(2) Lack of quality control

This is probably the second most common complaint I hear after the responsiveness one.  Clients hate receiving work that hasn’t been fully tested.

I think the most common reason web development firms put out buggy work is that they are rushing to meet a deadline and simply don’t have time for adequate front end testing.

I also think there is a divide between developers and clients as to how things actually get built.  In web development, the front end is usually the last thing that comes together.  A site could be 95% complete, but only appear 60% done if you look at it solely as a front end user.   Think about how houses get built.  You put up the foundation and install the plumbing and wiring before you paint the walls and hang the pictures.   But no one notices the foundation.  They notice the paint.  As a developer it can sting to slave over a project only to send it off and have it picked apart because you haven’t had time to test in IE 7 adequately.

There is no silver bullet here.  You just have to make time to thoroughly test everything before to send it out.  If you don’t have time for testing, you are probably better off buying yourself more time than shipping something to the client that is buggy.

(3) Giving the client what they want

It is sort of counter intuitive, but if you give the client exactly what they ask for you probably aren’t going to be a very successful consultant.

Most of our clients are not web developers or designers.  Working on websites is usually only a part of their job.  They hire us because they want expert help.  If a client comes to us with a new idea they don’t want us to just narrowly do what they have asked for.  They want us to improve upon it.  They want us to help them come up with an even better solution.

Web development professionals are busy folks with a lot of competition for their time.  Sometimes the path of least resistance is to put your head down and just do exactly what the client asks for, without truly thinking things through.  This is a huge mistake.  Taking this kind of short cut will ruin a client relation just as quickly as ignoring emails or putting out shoddy work.

(4) Blowing budget estimates

When you put together estimates for development work, you are asked to assign a precise number to an imprecise activity.  The truth is that estimates are essentially educated guesses.  Unless a task is super tiny it is impossible to really know how long something is going to take until you start doing it.  To improve our estimate process, we try to take 37 Signals’ advice from Rework and break all projects into small pieces that we then estimate individually.  The total is a combination of all the small estimates we put together.  If something is particularly tricky, we provide a range that we firm up as we are part of the way into the project.

We also try to use historical data to predict how much time a new project will take.  After we complete a project, we do a debrief where we analyze how much time and effort was required.  This data is kept in a spreadsheet that we can use as a reference when estimating new work.  This helps.

But no matter how careful we are, we are still going to to blow estimates from time to time.  When this happens the key is to take responsibility for it and not make it the client’s problem.  If I say something is going to take precisely 20 hours and it takes 50 due to a miscalculation on my part, I’m not charging the client for a full 50 hours of work.  I’m going to eat some hours, explain the situation to the client and try to dig my way out of the hole.   A lot of firms will charge for every hour even if they were responsible for the bad estimate.  I think this is a mistake.  Your relationship with the client and reputation are worth more than the money.

(5) Missing deadlines

Blown timelines are often a ramification of blown estimates.  If a project you allotted 20 hours for takes 50, chances are it won’t be done on time.  And if your project for Client A takes 50 hours instead of 20, that’s probably going to impact the resources you have for Client B’s work.  Timelines can also get blown for more mundane reasons like illness or computer problems or simple miscommunication.  We’re human.  Stuff happens.

The super simple solution here is to give realistic estimates that give you some leeway should things go wrong.  If your internal team expects to have the project done on Tuesday, commit to give it to the client on Thursday.  If you tell the client a job will be done Tuesday and you don’t deliver until Wednesday, you’ve failed.  If you say it will be done Thursday and you finish Wednesday, you’ve exceeded expectations.  This isn’t rocket science.

If you know you are going to miss a deadline, tell the client right away, explain what happened and apologize.  People are fundamentally forgiving, particularly if you are straight with them.  When you push a deadline, you should provide a revised deadline and commit 100% to meeting it.  Continually missing deadlines is the surest way I know to poison a relationship.  After awhile the client is going to lose faith.