What lessons can you learn from these horror stories?

Anyone who has spent any length of time as a computer consultant (either as an individual or as part of a programming team) has at least one sad tale of woe. Sometimes it's a clueless client; other times it's a dumb technical mistake you made yourself. But all too often, the developer's error is in the legal contract she signs. With the help of several people who painfully admit to a "learning experience," (with names omitted) today I'll share several ways a contract can go wrong. I'll also point out what could have been done differently — so that you, o best beloved reader, do not suffer the same ugly fate.

These anecdotes are related primarily for developers who are also computer consultants (or wondering if they dare to hang up their own shingle), but they are equally relevant to programmers who write code for their company's internal use. Every time you read "contract," you can just substitute "agreement with your user."

1. No graceful exit strategy. The first story is my own. Once, my two-person company had a contract with a then-major minicomputer company to write a custom QA application for a new hardware line. (This is before I became a computer industry journalist, obviously. It's long enough ago that I could write "major minicomputer company.") The contract was split into several phases, and was slated to last for seven or eight months. After a long contract negotiation in which the client got picky about a few dumb items (one of which would have had us working for free), we finally got to work. The first phase went fine. But during phase 2, suddenly things went awry. Literally, over the weekend, the client went from "This is great!" to "This isn't intuitive. Fix it." To make a long story short, we walked away, mystified and broke, since we'd budgeted for a solid six months of work from this job.

In my case, the universe was kind; years later, I found out the rest of the story. An ex-employee of the (now defunct) microcomputer company told us that the hardware line for which we were writing the app was canceled. The contract didn't give the company any way out except to reject the prototype in Phase 2. Otherwise, by the letter of the contract, they would have had to pay us for the entire six months of work. The client might have been honest with us (and we'd likely have negotiated with compassion) but I suppose they didn't think they could take the chance. To this day, I can't believe that we spent so much time on the contract without any other kind of exit clause. I learned to look for a clause that lets either party walk away in the case of unforeseen circumstances, with options that are fair to each party.

2. Beware scope creep. Scott had a time and materials (T&M) contract with a client who was a referral from a colleague. Before work began, they agreed on rates and the scope of the work, and he provided an estimate. Scott stayed within the estimate and scope and delivered on time. "When I presented the bill (which was actually 15% below the estimate), they offered a partial payment that was less than half," he says. "Being a one man shop, I accepted the payment, though advised them that that was not how I did business with small projects and that the balance would need to be paid off within 60 days. Then they expanded the scope, claiming they did not understand that they would not get all of these features that were never discussed at any level, and would not pay what they owed until they got it."

Scott's position got a lot uglier and finances headed south. At the end of the tale, he accepted a salaried position six months later at a 30% reduction in income.

Many woes are wrapped into the label "scope creep" but this particular horror story exhibits several. Most consultants I know expect some kind of down payment from a new-to-them client. At the very least, there should be a phased approach with interim releases, and payment made at the acceptance of each release. By requiring payments to be made at fixed stages, a consultant can limit the financial damage if something blows up. (If nothing else, you learn whether their idea of "Net 15" is measured in weeks rather than days. But getting paid is a different subject; I'll save that for another time, assuming you exhibit interest.)

Scott's situation also implies that the "scope of the work" was not adequately documented; the client may very well innocently but wrongly assumed features to be included because gosh, he thought of them. The phased delivery also gives the client an opportunity to make changes — to which the answer is always, "Why certainly we can do that. And here's how much extra it will cost you."

3. Fixed price gone wrong, terribly terribly wrong. Bob was once co-owner in a small Bay Area custom software development firm. Initially, they made good money doing fixed-price contracts because their clients were all reasonable folks. "Then we got a client who wanted a Windows-to-Mac port of a GUI front-end for a CD-ROM-based database," he writes. "They claimed they couldn't provide a complete functional specification for the software, but they had a marketing feature list, and we had the Windows version to play with. So we agreed to match the functionality of the Windows version." Boy, was that a mistake. The Windows software had crazy, non-obvious features which they'd only discover when the client reported a test version didn't work. They lost their shirts on that project, and soon learned that any project with squishy scopes was a bad idea. "I decided to never do anything but T&M again. Life is too short to argue about things like that," says Bob.

You can't blame a client for wanting a fixed price; none of us wants a big surprise, especially when budget approvals are part of the client's business process. But by my observation, fixed price contracts only work when you-the-consultant have a lot of control over the entire process. Ideally you know the client, the real scope of the project (don't depend on client assurances), and the project priorities (if the fixed price project takes longer than the time you budgeted, how will it impact your other commitments? by which I mean, the other clients who do pay on time and are waiting for you to serve them?).

It's hard to resist accusing the client of mal-intent (if not reproductive acts that are physically impossible), but what's funny-or-scary is that most of them simply operate out of computing and business innocence. As Bob says, "That client kept coming back off and on for almost a decade, wanting us to work the same way: no specs, fixed price, yadda yadda. And they just couldn't understand why we didn't want to do that again."

4. Protect yourself from those who would steal from you. Mark, the practice VP for a small regional consulting firm in the midwest, negotiated a contract with a health care services firm to provide applications enhancements, security and related project management. "We had a rock-solid contract with the client and our consultants, including to not discuss rates, and mutual protections against hiring each others' staff," Mark tells me. But after a few months, his project too went from "Awesome job!" to "What's happening?!" over one weekend. In Mark's case, the problem was caused when the client attempted to hire two of his consultants directly (clearly a breach of contract), and one consultant divulged rates and costs. "We got paid for our work to that point, but the project was canceled when we refused to totally ignore their little indiscretion," Mark says.

There are, alas, endless variations on this theme. Bob, from the previous scenario, says that on two occasions people gave their confidential bids to competitors, who then undercut them. "From the first, I learned that a software design should never go into a bid, and if the client wants a design, it's a deliverable to be paid for at a very, very high rate," Bob says.

Howard, a consultant I've known online since the beginning of my consulting career 25 years ago, learned to look at his contracts for time limits, with a default action taken if nothing is done. For example, he was handed a contract that said all billing needed to be for approved timesheets. "I added a clause that said that if timesheet was not approved or rejected (with explanation) within 7 work days, then it was to be considered automatically approved." That clause would prevent someone from stonewalling the approval process to prevent Howard from getting paid; it also (in a more common and benign situation, but no less financially painful) covered the possibility of the approvers being on vacation or otherwise unavailable.

You can't think of everything. But one wonderful bit of advice I was given, around the time I met Howard, was to view the contract as "What to do when everybody wants to screw each other." Sweet new consultants blanch at such a thing; after all, we like the client, we would never want to hurt him! But my advisor from long ago pointed out that project problems never arise from what's in the contract; they come from what isn't there. A contract clause that says, "Client will pay for..." might be irritating but it won't make anybody angry (except at themselves for agreeing to such a stupid thing). It's the items that nobody agreed to in writing that cause angst. If the contract doesn't say who'll pay for the such-and-so, that's when the shouting starts — and the lawyers lick their lips.

There's four horror stories — and their lessons — to begin with. Feel free to add from your own experiences, to save some poor soul the pain you went through.

This story, "Four Ways to Get Burned by a Computer Consulting Contract" was originally published by JavaWorld .