I was in a meeting regarding a possible and the inevitable question came up regarding how estimates work. As I've mentioned in the past, we are a custom development firm and don't perform project work on a fixed bid because application development, especially redesigning existing applications, always comes with a surprise or two - usually small, but sometimes not so small. The response I received was eye-opening: "I don't like surprises."
I found this particularly interesting and it forced me to ponder it a bit more after the meeting. In the development world, we don't like surprises either - it means more time and sometimes more than a little scrambling, particularly if it's over lack of clarity. They seem to be an inevitable fact when it comes to creating custom applications, regardless of how much time and planning we put into a proposal. If, like most business owners commissioning custom development projects, you don't like surprises, here's a few things you can do stop them before they crop up.
Certainly, as developers we need to set expectations, but in the 1-2 hour meetings that tend to precede the request for a proposal, very subjective terms are often thrown around rather than clear definitions of the expected results. Which statement paints a better picture of expectations:
It's difficult to keep something like this generic, but you get the idea. Without adding much in the way of time, I've just explained exactly what I expect to see on each page and what my definition of a "clean" look is. Here's a few other subjective terms and phrases that lead to surprises because they don't clearly define the expectation: "seamlessly integrate" (explain exactly what you want to connect and the information that should go back and forth), artsy (are we talking about abstract art or contemporary art?), pretty standard (is that your standard, my standard, another company's standard, copy the look of all the other sites in your industry standard, etc).
Maybe it's the boy scout in me, but I go in prepared (sometimes overly prepared) to any situation. This is especially important when you're building a Web site. While your Web team can often provide copy writing services to craft your message, they still need a place to start and nobody knows your business and your products or services better than you. It's best to spell out that copy writing should be provided, but make sure you have an outline of what you're looking to say for your Web team to work from.
If you're building an ecommerce site, it's a good idea to have a list of your product SKUs (these should match the manufacturer's SKU) so that, even if you don't have your product descriptions completely written out, your Web team can use the SKU to find the product information they can use to craft your ecommerce marketing materials. If the SKU doesn't match the manufacturer, it's subjective and your Web team might not find the right products.
There really is a great deal of planning that goes into a site and being honest with your Web team will help them understand what you need and how they can best help. Spelling something out for someone isn't going to make them think you believe them incompetent, but it will let them know what's important to you and avoid misunderstanding.