Contracting for success or failure?

Gareth Morgan has written an interesting article (a follow up to this one) discussing the “systemic failure to be more successful in using IT to capture material productivity improvements”:

By focusing on the technical weakness inherent within the job specification that the client has signed off on, and forcing variation to contracts as they work their way through, even though the supplier knew at the start that they could not meet timeframes and delivery targets, the multinational easily arm-wrestles the hapless customer to fund excess profitability. These projects follow the same pattern over and over again, they become five to six times over budget – a $20 million project can turn into a $120 million one. The supplier knows that walking away is not an option for these clients.

While Gareth addresses a broader issue, many of the problems he discusses arise from poor contacting. There are a number of problems endemic in IT project contracting:

  • The project is simply contracted far too large.
  • The contract relies on the often faulty assumption of Big Design Up Front.
  • The contract is prepared as if it were a construction contract.
  • The contract is only seen as “safe” if it nails down every last detail, and only allows changes through variations, which as Gareth says usually produce poor results.
  • The contract imposes completely unrealistic and ineffective “project management and control procedures”, that are either never used or are simply “caught up” on from time-to-time.
  • The contract is usually in conflict with the “agile intention” of the project (whether or not an agile methodology is actually going to be adopted).

I have written about some of these problems (and overcoming them) here: Contracting in an agile world (part 2 here). The solutions are not complicated, but when contracting is seen as a contest (which party can tie the other up the most?) the result can be a contract that’s more useful when the project actually fails, than facilitating the project’s success.

When the cost of IT failure in New Zealand is $5.4 billion a year, it pays to get the comparatively small matter of contracting right.

Contracting in an agile world, part 2

For part 1 of this post, click here

The emergence of agile development

Agile development emerged during the mid 1990’s and early 2000’s as a grass-roots reaction to the problems of traditional development experienced in many projects. There is no official definition but rather a set of principles, the most authoritative text being the Agile Manifesto.

Continue reading

Contracting in an agile world, part 1

Are your contracts agile? If you are involved in contracting software development it is worth asking that question.

Agile development is a relatively new methodology for software development which has rapidly gained popularity. Much has been written on agile development in the technology media, however there is little mention at present in legal circles. Perhaps this is due to the subject being regarded as a technical issue best left to the IT crowd.

Lawyers involved in contracting for software development need to be aware of this now common methodology. This article outlines agile development and some of the contractual issues it raises.

Continue reading