While contracts always have a legal dimension, it has been noted that on average, nearly 80 percent of the terms in business-to-business contracts are not really areas of significant legal concern. Instead, most terms are business and financial, including statements of work, specifications and service-level agreements.[1]

The contract needs to provide clarity as to the roles and responsibilities of the parties, scope of the delivery, implementation, and pricing. The contract should specify details regarding what, where, when and how. It also needs to clarify what happens if either party cannot or does not perform.

Experience and research show that the same issues repeat themselves and create problems in similar contracting situations. Focusing business, technical and legal resources on such issues and developing contractual and business solutions to resolve them is well worth the effort. For instance, if technical specifications, work scope definition, or task allocation are unclear, problems will follow. in the words of Mark Grossman,

taking time at the beginning to work out detailed design specs is equally important to both sides of the development deal. It's the only way to be sure everyone's on the same page, that there's been a meeting of the minds as to what the software should do and how.

And that's also the only way both sides will ever be able to walk away from a development project looking forward to doing another one together.[2]

even a simple from of visualization, a "hand tool” (Figure 6.5), can prevent unnecessary problems. it lists the trivial-sounding but crucial questions that must be answered when creating or reviewing obligations: who/which party shall do—what— where—when—how—and, last but not least, what if/what if not. This simple hand tool has proven to work in practice, both on the sell-side and on the buy-side. if the parties remember to go through the questions and address them when creating, amending, or passing on contractual obligations, a number of potential pitfalls can be avoided and contract reviews and risk control measures can be improved. Much more sophisticated tools and checklists exist—yet few are as easy to remember and carry around.

The hand tool

Figure 6.5 The hand tool

  • [1] Cummins, T. (2003) Contracting as a Strategic Competence. InternationalAssociation for Contract and Commercial Management IACCM, available at
  • [2] For instance, in software development contracts, design specifications, flexiblepricing, and performance standards tend to become frequent points of contention. SeeGrossman, M. (2012) Software Development Contracts. Tannenbaum Helpern Syracuse& Hirschtritt LLP, available at
< Prev   CONTENTS   Source   Next >