By Andrew Neitlich

Is a web site ever done (and what does that mean for selling web services)?

By Andrew Neitlich

I’m about to launch a new subscription-based web service (to be announced soon with special offer to Sitepoint readers to beta test it).

In creating this site, one thing has become abundantly clear: A site is NEVER, EVER done. Every time we fix a bug or make a functionality improvement, we see the opportunity to continue to improve. It’s like upgrading one room in a house, and then seeing how every other room suddenly needs upgrading, too.

This is true on complex and simple sites. Every Web design/development customer has constant need for updates and upgrades.

This presents an opportunity and a challenge for you:

The opportunity is clear enough: If you do a good job up front with a client, you should have a long stream of follow up work with that client.

The challenge is one that my vendors are facing: How do you define “done” when a web site is never done? What milestones can you set with a client so that you are both on the same page about when a deliverable is met.

For instance, my business partner and I have constant back and forth with our developers. They think something is done even if it is not ready for prime time. We think something is done when it is ready for prime time, by our standards. And neither of us is able to precisely define “done.” As a result, neither party is ever fully satisfied.

I don’t have an easy answer for this one. A fixed price contract is tricky for you without clearly defined deliverables. And a time and materials contract gets very annoying to your customer, who gets tired of paying for additional time to meet their “obvious” market-driven standards. I’ve tried a bonus arrangement, withholding portions until we are satisfied. That doesn’t work either.

So what I would do is focus on the opportunity, and look long term at the overall opportunity in the relationship.

  • myrdhrin

    Hi Andrew,

    In my day job’s fuild of business we’re never done either (we sell software and specialized hardware)… The way we’ve been doing it (and there must be something to it since we’ve been in business for quite some times) is this:

    our agreement with the customer defines 3 portions in the lifetime of a project… a design/developement phase, installation/acceptance and maintenance phase. It also defines the products we’ll be installing and customizing (ok… the project might not really apply here but if you have a standard package you could see that as a product). The agreement also defines the events that will cause the transition from one portion to another… so :

    – To move from the design/developement phase to the installation phase we have to meet with our own internal factory acceptance tests (an exhaustive list of tests we do on our software and products; that list includes all the test and functionality points we’ve agree to the customer)

    -To move from the installation/acceptance to the maintenance portion… simple, the customer can accept the application has it is OR they use it in a production kindof mode (so for a e-business, the moment the first widget is sold would be the transition point).

    The design/development phase has a fixed cost based on the requirements (and we usually revise it after a preliminary review with the customer). The installation/acceptance is factored in that price.

    The maintenance is a fixed cost paid every month that covers for us: the time spent answering the phone for their problems/request; a certain number of hours every month to do improvements on their installation; FREE upgrades of their software and hardware (that does not cover the cost to customize the upgraded features if they don’t meet their need)… anything that is not covered in the maintenance fee is processed as a new project/agreement/contract with the customer…

    It seems to be working for us… maybe there is something to learn there.

  • aneitlich

    Excellent post myrdhrin, thanks!

  • Thirteenva

    Part of the determination of ‘done’ is accomplished at the outset of the project when scope is determined.

    For example:
    If a client decides at the outset of his project that he requires an admin backend to email all users of his site at once then the scope is all users. Once he decides that he needs a list where he can choose select users or sort them into groups to send separate emails, he’s no increased scope. If the project proposal attached to the contract states ability to email all users at once then that is what the revision 1 product will do. Revision 2 will incorporate that feature under a separate project proposal and contract.

  • For complex sites its more of an issue, as the list of “features” you can build into a system are endless. The best method I’ve found is to develop a technical or functional specification for the system in question before work starts. The key is to make sure there is as much detail in that document as possible, then the classification of “done” becomes very specific and hard to dispute when both parties sign off on that document. If the client wants more, it becomes a seperate project handled with its own documents, contracts and pricing.

  • I would love to beta test the site. What kind of site is it?

  • Justin

    Sounds to me like you have a classic problem of scope creep. Where I work our development processes are finely tuned and regulated by the FDA because I work for a software development house that created medical application. One of the steps in the development process is created a life cycle document that outlines specifically all changes in a release. This life cycle document then links to all the Product Change Documents where someone defines the requirements for each feature or new functionality, a developer creates a design, we have a design approval meeting, development takes place, and then we have QA verification.

    Rinse wash, repeat! Basically my point is that we have such a structured process that there is little room for features to suddenly appear and have scope creep. We fully know when we have a finished product.

    You need to ensure your Design Input equals your Design Output. Meaning your requirements document should closely resemble your finished product. Developing in an ad-hoc manner can be good for small projects but for anything larger you need some structure.

    – Justin

Get the latest in Entrepreneur, once a week, for free.