Steel, Silver and Platinum: Quality and Consulting

Often, the same is true when a marketing manager or CEO is selecting a vendor to develop their website. Seldom do they have a deep understanding of what makes a good application (or developer), so they'll typically pick the second least expensive vendor within their budget range (cheapest is risky, but don't want to waste too much money) that they felt comfortable with and go from there.

The immediate responses to this are that (i) website developers would probably be more successful by investing in their rapport skills than investing in their technology skills and (ii) ability to elicit budget is one of the biggest predicators of success in a quotation process (two things I've found over the years to be pretty accurate). But let's dig deeper . . .

In my experience the trick to selling "quality" web applications (as opposed to selling price or affability) is to set the terms of the bid process. If you're responding to a fixed, formal RFP it is extremely difficult to shine. However, if you can get in with the client early on and educate them about a couple of key elements (whether it's SEO, multi-variate testing, unit tests or automated build processes) you can often use those as the differentiators to create an informal checklist in the clients mind that you're the most likely to meet. The trick is that you can only educate any given client effectively on two to three points per project, so you either need to pitch clients with similar levels of web development experience or vary the quality of your projects depending on the sophistication of your clients. It is not that you can't mention ten new concepts (although good luck getting them to stick), but I'd bet money that if you attached a non-trivial additional cost to each of the ten items, even if the client bought from you they'd be unlikely to pick more than a couple to be included in the project even if they conceptually agreed with all of the ideas in the abstract.

In practice, clients will only buy "good enough" web applications (they're a business - not a guild for promoting software development best practices). Most clients are open to learning more about what makes an application good enough every time they do a project, but if you try to educate them on too many new concepts, you're unlikely to get the business. (This is not to say you shouldn't use best practices behind the scenes, just don't expect the client to pay for them if there is any chance they'll increase the total project budget given a fixed functional scope and timeframe.)

How do you calibrate the sophistication of your clients? How do you pick the clients you're most likely to be successful with? What processes do you use to decide what points to educate any given client on given their beliefs, preferences, and business drivers?

Any input appreciated!