Web design business mistakes: Establishing clear practices

| May 28th, 2009 | , ,

Part 1 in a 5 part series

Establish clear practices from the start with your clients and your internal team

A well-developed specification from a client often sets the stage for a smoothly executed project. It should include a comprehensive scope of work and ideal timelines. However, a clearly defined spec is hardly the norm, especially with the web as your medium. And it’s the usual lack of clearly defined scope that makes flat bidding on web site projects very difficult. If your client can only provide you with an incomplete scope of work, offer to put one together for them—for a fee. This should be part of your discovery or planning process, not a freebie. And strongly consider doing the project under a time and materials contract. A flat bid may only get you into trouble further down the road.

Once the discovery process is complete, the scope will likely change several times during the project. It is quite difficult to visualize or specify a complete interactive web site. Once the web site starts taking shape you and the client will want to change things up. It’s inevitable. Make it clear to the client that you have processes and goals in place they will need to respect. Outline contingencies such as how to handle time and materials charges for overages. It may also save you a lot of time and frustration if you realize from the start that this project and your team are simply not a good match.

A clearly worded legal contract should identify: the scope of work, timelines for deliverables, who is responsible/accountable for the work on the client end, as well as “worst-case scenarios”—charges for overages, extra work and a well-worded exit clause for both you and the client. If the timeline is too short it may be worthwhile to skip the planning process and dive in with a time and materials contract, especially when working with a client with good history.

The prerequisite for any client project should be to have a clear and open line of communication and established guidelines. There is no such thing as being too articulate or verbose. The web is a medium in a constant state of flux. It is likely the online landscape will change and have some indirect effects on your project. A good client relationship should always be backed up with a contract, regardless of how well you “know” the client. Not only will it make you appear more professional, it will protect you from bumps in the road to project completion. And there are always bumps.

How Pelago learned this the hard way:

When working with new clients, or clients with a history of not paying their bills on time, handing over final deliverables before receiving payment is not a good idea. It strips you of your bargaining power, regardless of how ironclad your contract—legal action is a hassle and should always be a last resort. We learned this after launching a web site without final payment from a new client. The client assured us we’d be paid as soon as they were able. The next communications from them was a form letter informing us their startup was being absolved. We’ll never see that money. Had we made getting paid a higher priority for them it would have turned out differently.

Lear

11 Responses to “Web design business mistakes: Establishing clear practices”

  1. h3 says:

    1) Host your projects, so if they don’t pay you can always pull the plug.
    2) Ask to be paid in two or three payments, one *before* starting the project, one at mid-project and a last *before* deploying the project. So even if they disappear, you wont lose everything.
    3) You shouldn’t don’t sell a software or website, you sell your time. You make a proposition that fits their needs and budget, you say that’s around Y hours, which means around Y price. Inform them that any changes to the initial specification directly impact the final price. Keep your client updated continuously on how much hours there’s left. That’s great for shutting up micro-managers because they see the budget sinking as their delirium kicks in.

    The last thing you want is to sell a website/software because as the project progress the client will always try to redefine what that website/software is supposed to be.

    Your worst enemies are micro-managers and committees. They will suck the profitability out of your business faster than crackhore in need for a fix.

  2. John Reeve says:

    Very good points. But I would advise against hosting your own projects. The responsibility of maintaining servers and/or hosting payment plans for your clients can be overwhelming and distract you from doing the actual work of web design and development.

  3. David Brunelle says:

    Timely post. I’ve found myself having a really hard time dealing with client delays lately. Luckily, I haven’t had any clients withhold payment. However, if a client delays a project it’s almost a as good as withholding payment. I’m trying to find a good way of dealing with this.

    Do you have any intention of releasing templates during this series? I’m always interested in seeing what other people’s SOW’s look like. Sometimes I feel as though I’m giving too much detail. Sometimes not enough. Looking for that sweet spot.

  4. John Reeve says:

    David,

    Take a look at our maintenance contract template that we released a few weeks ago. There should be some good legalese you can use.


    http://www.myintervals.com/blog/2009/02/10/steal-this-web-design-and-development-time-and-materials-maintenance-contract-template/

  5. David Brunelle says:

    Thanks John – I’ve actually downloaded the maintenance contract. It’s good stuff. I think what I’m looking for are better examples of scope documents. I’ve run in to problems in the following areas:

    – If I indicate “search” capabilities in a scope document, some clients can have expectations about how search should function and perform that may not be realistic. How much detail do you go in to about specific features? How do you find the balance between too much detail vs being too vague.

    – How do you define, in your scope documents, when a project is “complete” and how do you balance being assertive vs. being adversarial when it comes to handling items that are “out of scope”?

    – How do you protect yourself from delays caused by the client or, even worse, an incorrect assumption being made in the estimation process?

    All pretty bit questions I’ve been struggling with lately. All the more reason to work on a time and materials basis I guess!

Leave a Reply

The Intervals Blog
A collection of useful tips, tales and opinions based on decades of collective experience designing and developing web sites and web-based applications.

What is Intervals?

Intervals is online time, task and project management software built by and for web designers, developers and creatives.
Learn more…

Contributor Profile
John Reeve

John is a co-founder, web designer and developer at Pelago. His blog posts are inspired by everyday encounters with designers, developers, creatives and small businesses in general. John is an avid reader and road cyclist.
» More about John Reeve
» Archived posts by John Reeve

Contributor Profile
Michael Payne

Michael is a co-founder and product architect at Pelago. His contributions stem from experiences managing the development process behind web sites and web-based applications such as Intervals. Michael drives a 1990 Volkswagen Carat with a rebuilt 2.4 liter engine from GoWesty.
» More about Michael Payne
» Archived posts by Michael Payne

help.myintervals.com
Videos, tips & tricks