Build Time vs. Contact Time

Code generation, code re-use, domain specific languages and software product lines. These are all amazing tools for decreasing the time required to specify and fabricate custom web application. I find that I can create rich custom applications now very quickly indeed. The problem/question/issue is how to handle contact time.

If it takes you 300 hours to code a custom web app, it doesn't matter all that matter whether you spend 12 or 20 hours discussing the application with the client and answering their questions during the build phase. But what happens if you can generate such an application in 5 hours? The difference between 12 and 20 hours of time explaining the project and answering questions is an almost doubling of your project costs. What's a developer to do?

One approach is to try to head off common questions by raising them in advance. Clients often ask about security, scalability, authentication, cookies, browser support, email deliverability and a bunch of other issues. Of course, the problem is that because most clients only ask a few such questions, preemptively answering all of them would (a) bore most clients and (b) take longer than just answering the questions that they have.

Another approach is to have FAQs or learning resources online so that you can answer questions once and then just provide the same answers to future clients. I think the trick to this is in the delivery of the response. I'm tempted by a system that would allow clients to find answers if they wanted but that also allowed you to send out a somewhat personalized email so you could send them pre-prepared content without it so obviously seeming like a RTFM response.

Another approach that I'm playing with is to fixed bid the development but just estimate the contact time. I think it is a good idea in theory, the challenge is finding a benefit focused way of selling it to clients who really don't want to be taking that risk. Thoughts are to position it as "rather than paying for project management you don't need, you'll only pay for the time it takes". In theory that sounds pretty good. I find the concern is often along with lines of "what if you do a bad job?" The concern is that the more bug reports there are, the more the project will cost which obviously doesn't appear attractive to clients. Maybe the trick is to only charge for time explaining and training so they can purchase as much support/hand holding as they want and not to charge for time discussing bugs. It isn't perfect as some clients file lots of inaccurate bug reports, but it'd be a step in the right direction.

Of course, another approach is to pre-select clients that WON'T need too much hand holding. Still trying to craft just the right questions to ask that might elicit such a distinction . . . Thoughts always appreciated!

Another approach would be to have a really formal process, taking the idea of time boxing which is someone a little easier to sell than a completely agile approach. The position is that we'll work with you for X hours to elicit your requirements and they there will be Y hours of training and support.

Then there is the automation and/or deskilling of specific touch points. Web based intake questionnaires, bug tracking systems and knowledge bases are all ways of cutting the cost of support. (anyone using these? Experiences? Suggestions?)

Yet another approach is just to accept that some clients will be more profitable than others and just to set a price point that covers the variability. It's not ideal, but it works as a measure of last resort.

How do you estimate contact time? How do you maximize the value of the contact you provide and minimize either contact time or the variability in contact time? Any input appreciated!