Web design business mistakes: Setting client expectations

Part 4 in a 5 part series

Know when to say no—set client expectations

We all want to make our clients happy, build a good reputation, and land more work, but occasionally the best way to manage a project that is running amok is to know when to cut it off. When a client has expectations that are beyond the ordinary or the reasonable, you can accommodate to a point, but ultimately you will need to draw the line. The sooner you make that clear to a client, the less likely it is that your project will become bogged down with extra deliverables and go over time and budget. Some ways to avoid this:

• Build a cushion into your timeline and budget. A reasonable margin of error is typically between 10% to 15% of the total budget. This will allow you to give the client some freedom for last-minute changes or additions within their expectations. At Pelago, we only sign Time and Materials contracts, but it doesn’t hurt to point out that work requiring the cushion is in addition to the original estimate. Keep the client apprised they are starting to add to the budget and you will avoid handing them an unexpected invoice at the end of the project.
• If the client has additional requirements that will change the scope of the work, but does not have the additional funds, suggest re-prioritizing the project features. For example, “We can implement X, but since it entails a great deal more work than covered under the original estimate and your budget, we need to take feature Y off the list.” It is also important to track these items separately from the original deliverables. This way, you group the work you did within the original estimate of work separately from additional work —extremely valuable not only to you but to the client as well. When the client is wondering why the project went over budget, it’s easy to justify, especially if you are tracking your time on the project.
• Working with a client sometimes means fielding work requests from multiple people inside the organization. If possible, require that all of the client requests and communication to be handled through one point person. This will save you a lot of headache and help avoid doing the same work twice. By tying work requests back to specific individuals you create an environment of accountability. Clients will be more likely to get their act together and get more organized after seeing an invoice that reflects the effect of their multiplicity on the bottom line.
• In our experience, flat bidding on custom web-based software projects is nearly impossible. The client usually only has a minimal understanding or vision for what they are trying to create. And in most cases, they don’t understand the web as a medium enough to realize how much of an undertaking these projects can be. Once they see the project starting to take shape and their vision become tangible the requirements start to change. We’ve embraced this as a natural part of the web development process and handle it with Time and Materials contracts. They are far better for you and the client, enabling both sides a way out and a way to surpass unforeseen or miscommunicated expectations.

You can be accommodating to clients while still running your business at a profit, as long as you set clear expectations from the beginning, let clients know when they are adding to those expectations, and renegotiate expectations (and price tags) to ensure that everyone will be happy with the final product.

How Pelago learned this the hard way

Several years ago, when Pelago was just getting its start, we signed a big client with a big name. We were starry-eyed and said ‘yes’ to everything they put in front of us. And we delivered the work immediately. We had set a precedent with this client, telling them, without words, that they would get what they wanted. When we were informed that our final invoice wouldn’t be paid because the client didn’t deem the work ‘billable,’ we were crushed. Being the ‘little guy,’ we had no options really to recoup the money. If we had practiced saying ‘no’ there would have been an established protocol and we may have avoided this scenario.