Pay when it works

A COLLEAGUE OF mine managed an outsourced development project for a major distributor. After three years, the distributor decided that it was never going to meet specifications and pulled the plug. The company said it had done everything right by the terms of the contract, so it wouldn't give back the money paid (several million dollars).

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

So, of course, they're going to court, and millions of dollars will depend on a judge's interpretation of a very dense specifications document. People with more important jobs are going to waste many hours sitting in depositions and compiling evidence. It will drag on for years and in the end, the distributor will be lucky to recover 30 cents on the dollar after fees and lost time. And the original project still won't be finished.

If you look back at a failed project's history, there is usually no single misstep that, if corrected, would have created a positive conclusion. A detailed postmortem on a failed outsourcing deal yields worthwhile procedural changes, but the cost of that lesson is unacceptably high. Plan for the worst-case outcome before the project is signed; take a frank look at the cost of failure and the likelihood of recovery. Those facts are as important to a project plan as the ROI.

If the cost and effort required to terminate a project are known in advance, the "point of no return" is pushed out. That makes it easier to pull the plug when the time comes.

Plus, the criteria for failure must be as plain as the criteria for success: Both should be expressed in shirtsleeve English and as free of geek speak as possible so a judge or juror will be able to follow it. Success or failure cannot be determined solely at the end of the project. Each of the interim milestones must express unambiguous conditions that define success to that point.

The ideal project contract spells out realistic remedies that don't require a trip to court. The best situation in a project-based contract is for the contractor to forego the bulk of the fee until all of the success criteria are checked off. A contract that delays or escrows payments will have a higher price tag; you're buying failure insurance. It's usually worth it.

If you can't pay for the project when it works, do your best to pay as you go. Set up the contract so that each milestone has a fee payment attached to it -- if the milestone isn't met on schedule, the contractor can keep working on its own dime to meet it. Failing to meet any milestone is a decision point for you: Kill the project and accept the losses to date, give them more time, or relax the criteria. Make sure the person with the power to decide whether the project lives or dies has the nerve to pull the plug. Neither side should be winking or waffling over the termination clauses.

Failure can't be a squirmy subject that isn't discussed until it happens. It's appropriate for everyone involved to be excited and hopeful when they draw up a new project. But be mindful of the lessons of the past two years. Promises are not always kept.