"One last round" of revisions comes through. Then another. And another. Nobody wants to push back the launch date, so everyone starts running around in a big rush. All the sensible procedures and conventions that the team adhered to so strictly during the project are now abandoned, and everything starts to become disorganized.

The change requests keep coming in. The contractor has already gone over on the number of hours he budgeted for this project, but he doesn't want to nickel and dime, he wants to be a nice guy, so he just says "sure," and makes the changes. After all, the client assured him that these really would be the last.

But they aren't. Whether for legitimate business reasons, or just out of fiddle-itis, the client keeps tinkering. Every time the client asks for another change, the contractor becomes less cooperative, until a mutually hostile atmosphere develops. The client can't understand why the contractor, who gave such prompt service before, is now grumbling about getting these little finishing touches done. The contractor thinks the client has a lot of gall to keep demanding major revisions without mentioning any additional bread.

Bad situations like this are all too common, but they are usually the result of a poorly thought-out billing policy. The more specific you can be early in the game about what a bid does and does not include, and how additional work will be billed, the less likely you are to get into bad scenes of this kind. However, as every contractor know, it's easier said than done.

This problem is faced by every company that does work on a contract basis, from a lawn maintenance outfit to a builder of jet fighters. It's a famously widespread problem in the Internet industry, however, for several reasons.

Most companies have little knowledge of the Web, and no past experience to guide them, so they can't make decent estimates of how much various Internet-related things should cost. This ignorance leads them into various errors, such as wasting money on expensive kewl doodads instead of on core site features. Sometimes companies have ideas for their sites that seem simple enough to them, but cost a lot to do on the Web. Their under-estimation of what the price should be leads them to choose a low bidder who promises the Moon, with disastrous results. (See How to Write an RFP). Many companies, in a naïve desire for a "user-friendly" system that doesn't require any geeks, buy into proprietary development environments that end up causing big compatibility problems later on (See To Microsoft or Not to Microsoft).

Another culprit is simply the incredible pace of change in today's business world. Sometimes by the time a Web site is getting close to completion, business conditions have changed so much that major revisions are necessary.

Traditionally, project completion is measured in terms of deliverables. For a printing project, the finished printed matter is the deliverable, and once that stack of paper has been delivered, the project is done and it's invoice time. The nature of Web work makes it a lot harder to define a deliverable. Since a Web site need never really be finished, any date that one sets as a completion point is merely arbitrary. Is the project done when the site launches? When the client has tested the live site, and signed off on it? In fact, there's often quite a bit of work still to do at this point, namely promoting the site.

These factors all conspire to ensure that any Internet-related project will have its share of change requests, during and after site build. Avoiding the nightmare situation described above is a matter of good project management skills (See our review of Information Systems Project Management).

The first step is planning for change requests at the earliest stage of a project. The proposal should include a procedure for dealing with change requests, and the final contract should spell this procedure out in detail. These procedures can be quite complex, but they are generally based on one of three possible billing arrangements.

1 - Fixed Bid with hourly billing for change orders. This is perhaps the most common arrangement. The drawback is that it is often hard to be precise about what work is included in the main project, and when the additional hours should start ticking away.

2 - Fixed bid with maintenance contract. Under this arrangement, the client pays a fixed monthly fee for whatever needs to be done after project completion. This is a good system for sites that will require a moderate amount of ongoing maintenance after launch. The drawback is that it's hard to estimate the amount of time that will be needed, so it's tempting to leave the price negotiations until "later," by which time you may end up in exactly the situation we want to avoid.

3 - Estimate with cost-plus or hourly billing for entire project. Only an estimate is submitted with the proposal. As soon as the work begins, the clock starts ticking (on either an hourly or a cost-plus-percentage basis), and it ticks as long as work continues. This arrangement shifts the burden of uncertainty to the client, and few are likely to agree to it unless it includes some safeguards for them, such as a commitment that certain milestones will be reached by certain dates.

These different arrangements are appropriate for different types of projects, and any of them can work well. The real key to managing change requests is defining milestones and deliverables as precisely as you can. Struggling against changes themselves is futile. Client and contractor need to agree up front that there will be changes, they will be billed at an agreed rate, and they will be handled in an organized way.

Defining milestones and deliverables is easier when the contractor keeps careful track of the materials received from the client. Every item of collateral material received from the client should have an official Final Version. For all of the various text files, images, video clips, PDF files, or whatever, someone on the client side must at some point certify that the latest version you have is the final version. Any change they wish to make to that document after that point is officially a Change Request - it goes on the request form and will be billed at the agreed rate. Of course, in a perfect world a client wouldn't send you anything other than a final version, but human nature being what it is, it's best to define such things precisely.

Sizable projects are often broken up into sections, with management signing off on each section as it's completed. The nature of Web sites means that they often can't be built in convenient sections, but it's good to divvy up the deliverables when you can. Often it's a good idea to get the basic graphic design done, and have the client sign off on the look of the graphics before proceeding with building the pages. Changes to graphic objects after you've already designed pages around them are often one of the most time-consuming pains in the butt of all.

Educating clients is crucial to managing their expectations. They need to understand that changes that would be easy in their word processor are not so easy with HTML. The difference between HTML text and graphic text should be explained, as should the tradeoffs between nifty graphics and download times. Most importantly, they need to understand that HTML has some serious limitations, and that they simply cannot have pages that look exactly the way they want on every system. "Surely it can't be that hard just to make these things line up!" When you explain that it simply ain't possible with HTML, you must be able to convince them that you aren't just shining them on.