You've Got to Be KIDDING ME: How to Handle Mistakes in Your Web Project

sorry spelled out in alphabet noodlesIn every single web site project I've ever done for a client, something has gone at least a little bit wrong. Sometimes I am the culprit, and sometimes my client is the culprit, and sometimes neither of us is at fault, but a hosting company or a vendor has created the issue, and we all have to deal with it. How my client and I pick ourselves up and move forward from the hiccup is a great indication of the likelihood of us coming out of the project as a team who will work together again.

Today, I'll be discussed some common break-points of projects and how to move past them to finish what still needs to be done. Most important is to treat issues that come up without using the word "no," on either side. Replace "no" with "yes, and...," and you'll see that there's always a way.

A Major Section of Content Was Forgotten Entirely

The Culprit: This depends. It could be the web consultant, who didn't do a good job in guiding her client through the process of developing an information architecture. More likely, this falls on the client, who knows his business better than anyone else, and just plain forgot about this section of the site. It happens.

The Impact: This section of content, if large, probably can't be left off the site without creating a hole in the client's marketing of his business. If saved for later, he is running the risk of his own customers not knowing about a part of his business.

Can It Be Fixed? Yes! And... It will take more time and likely add to the cost of the project. How much time and cost depends on when in the development process this problem is discovered, how flexible the navigation is, and how much more content needs to be created.

Who Should Absorb This Cost?: Probably the client should pay for this. If the developer feels that she forgot to ask some key questions as they developed the information architecture, she might offer a discount on the price, but at some point, the client had to have agreed to the site's architecture without this section, so the onus really is on the client.

5 white eggs in a nest with one grey oneThe Site Looks Different (or Terrible) on a Specific Browser

The Culprit: The developer is probably at fault here, especially if she promised cross-browser functionality. It's important to know that modern users of all four major browsers (Firefox, Chrome, Safari, and --ugh-- Internet Explorer) can use the finished product equally well. Unless the original contract specified that this site was only going to be tested on specific browsers, this is the developer's issue.

The Impact: Customers will call and say that they can't use the web site. That's something the client can't fix him or herself.

Can This Be Fixed? Yes! And... It's going to take time and effort. It's going to require the developer to take several steps back, spend a lot of time adjusting style sheets and hitting refresh on every browser, over and over. It's tedius and sometimes infuriating work.

Who Should Absorb This Cost? The developer, no question about it. This should be part of every project. If there are hours left in the development budget, they can be used for this because this would have needed to be done anyway, but if fixing problems goes over the original project cost, it's the responsibility of the developer to cover that cost.

The Name of that Page/Menu Item/Button Needs to Change. Again.

The Culprit: This all depends on whether you had sign-off points in your development schedule. If there was a point at which the developer said, "Sign-off here on navigation," then this is the responsibility of the client. If not, then it gets murkier. After all, did it say anywhere in the contract that the client could not request an infinite number of changes to things the developer thought were final?

The Impact: In the end, the impact is probably minimal. If it doesn't get fixed, the client will probably be irritated by it forever, and if it does get fixed, there may a worry from the developer that the changes will never end.

Can This Be Fixed? Yes! And... It takes time. Depending on the content management system and whether the text is rendered as an image or not, this can take anywhere from a few minutes to a few hours.

Who Should Absorb This Cost? This depends on the contract. If it does not specify anything about when these things are finalized, then technically, the client can keep changing things forever without any effect on the cost. However, if that's the case, it's best for the two of you to discuss how many times are reasonable, for the developer to explain what is involved in each change, and for both parties to have mercy on each other. Developer: accept that sometimes people change their minds, and do this first one for free. Client: accept that just because the contract says you can have as many changes for free as you want, it doesn't mean that you should. Now, if the contract is clear on this, then the onus is solidly on the client to pay additionally for any changes beyond what the contract allows.

broken link in bike chainThe Site Is Launched and Something Is Broken!

The Culprit: The developer, hands down. Even if you both went through the site with a fine-toothed comb and thought you'd found any snarls, you obviously missed one. In the end, it is the developer's responsibility to deliver a fully-functioning site to the client.

The Impact: It just plain looks bad. Brand new site with a visible error? No good for either of you.

Can This Be Fixed? Yes! And... It should be done right this minute!

Who Should Absorb This Cost? The developer should absorb this, no question. Unless the developer can absolutely prove that this was caused by something the client did, it's her responsibility.

The Hosting Company Doesn't Support Something The Site Needs

The Culprit: This is a tough one. Who chose the host company? If it was the choice of the developer, this is her fault. If it was the choice of the client, then that's a little harder. It depends on whether the developer was in favor of, ambivalent to, or opposed to this particular host.

The Impact: Either the recommended software will have to change -- which affects nearly every piece of any project -- or the client will need to choose a new hosting company. This can affect the project timeline quite a bit. While it's important that the developer review the host before the project to be sure that all the software she recommends is supported by the hosting company, some things are difficult to predict until the project is underway and something doesn't work as expected. It can be something as basic as the content management system or something smaller, like a widget or extension added on to the site.

Can This Be Fixed? Yes! And... It could be a heartbreaking amount of work. Either the developer will have to start much of the project over on a new server (even transporting the site from one place to another can "break" a lot of things), or the developer will have to research other options for the functionality the current hosting company doesn't support. It may be necessary to spend time on the phone with either the hosting company, software or extension developers, or both. It's always doable, though.

Who Should Absorb This Cost? If the developer chose the hosting company, then the developer should take a deep breath, put on her bravest smile, and absorb the cost of this issue. There is no one to blame but herself. If the client chose the hosting company, then it is time for the two of you to get together and talk through it in person, face-to-face, and decide how to handle it. Depending on how far you've gotten into the project, it may be better to re-think that piece of functionality entirely, going with a new extension. The developer will need to spend some non-billable time on research so that she can present all options and their prices, and the client may need to accept that having insisted on a specific host had a hidden cost.


guilty looking manMistakes happen. Problems come up. Ludwig von Beethoven said "Nothing is more intolerable than to have admit to yourself your own errors," and that is true. When hard-earned money and too-precious time are involved and at risk, it's even more difficult to admit that you are at fault. Still, to move forward in any business arrangement with integrity, we have to be honest with ourselves, our clients, and our vendors. Say "oops," say "I'm sorry," and soldier on.

Have you been forced to admit a mistake in a client-vendor relationship? Tell us your story! You can This email address is being protected from spambots. You need JavaScript enabled to view it. , or tell us on Facebook or Twitter. We'd love to add to our list of solutions.

tell someone about this:
FaceBook  Twitter