Customer collaboration over contract negotiation

Don wrote:
“a requirement specification was supposed to detail the problem space: business context, business goals, business data, business rules, and business constraints: but usually the problem was insufficiently well described for an adequate product to be developed to reliably resolve it. As a result, lots of time was wasted designing and building inappropriate products, which failed to incorporate or correctly implement fundamental business rules regarding data control, transformation, and information generation (roughly, input-process-output). These requirements were nothing to do with software, but everything to do with achieving business success.”

As a law student, I heard story after story from commercial law specialists of lawyers who insisted that their contracts lock down all the details. It was an interesting controversy:

· On the one hand, there was the risk of inadequacy of the contract, because unanticipated details would cause later disputes.
· On the other hand, negotiation after negotiation failed because the legal costs were so high and the negotiating delays were so long.

Later, as a lawyer, I got to see some of these disasters myself and, through my work on computer-related legislation, I got to discuss contracting with people who had negotiated Big Deals and participated in Big Expensive Failures. It was a second education.

In my own negotiations as a lawyer, I adopted two key heuristics:

1. In deals of any complexity, there will always be holes in the understanding of the parties. Even if a problem has been solved by many other people, this problem probably hasn’t been solved this way before by these people in this deal. Their education will come to some degree as they negotiate the deal, but to a larger degree as they work through the project (do the work together) and gain life experience.
2. A contract is a symbol of an underlying agreement. No amount of paper will compensate for bad faith or protect the parties against it. Between parties of good faith, it is more valuable to specify a dispute resolution process that helps the project move forward when unexpected things happen than to try to anticipate all of the future contingencies.

I heard lots of preaching in favor of locking down every last detail. And we certainly studied lots of horror stories (that is, after all, what lawsuits are all about). But if our client didn’t have infinite time and an infinite budget for “transaction costs,” and if the other party(s) didn’t just agree to whatever we asked for, then negotiations had to stop and life had to go on long, long before all the details (what you are calling the project requirements) could be specified.

Rather than locking all of those requirements down—or blaming people for not being willing to achieve this impossibly expensive task—I saw my task as helping people find the smallest set of things that had to be locked down and finding a process for resolving the rest later.

I was delighted when the agile methods started gaining traction because they finally took seriously and constructively the same issue, presenting a technical-process solution to the need for ongoing requirements evolution, rather than legal-process (mid-project mediation, mid-project arbitration and other structures for supervising negotiation of the evolving deal).

Let me suggest a different pair of interpretations of what you are writing. When you say that lots of time was wasted creating the wrong things in the wrong ways, I suspect that:

· Lots of time was wasted because the vendor had no incentive to meet regularly with the client to steer the project to success, and the client was locked into a contracting process that gave them little authority to steer without driving their costs through the roof. The contract replaced the requirement of ongoing mutual-satisfaction-oriented communication. That is the essential difference between BUFD (big up front design) and iterative development (read Tom Gilb on evolutionary development—he wrote about using it with the air force long before XP was a formalized methodology).
· Lots of time was wasted because the vendors who play in this space are the ones who have learned how to profit from a grossly inefficient development process. There was lots to dislike about Donald Rumsfeld (our previous Secretary of Defense), but this was one of the issues he raised time and again. Rather than failing more expensively with larger warehouses full of paper, Rumsfeld wanted a more agile contracting and development process. I’m not sure how successful this has been, but I am sure that a big part of the problem has been inertia on the part of the vendors.

During my legislative work, I spent a lot of time working with lawyers who represented (or worked for) insurance companies, banks, and other big non-government institutions. One of the most striking things was the extent to which they mistrusted (sometimes, hated) software vendors (especially custom software development companies) compared to their attitudes toward other vendors in other industries they dealt with. I think BFUD (oops, I mean BUFD) has played a big role in the evolution of that profound dissatisfaction.

- Cem Kaner