Introduction
Agile has entered the mainstream. In a recent survey,
more than 50 per cent of the respondents said that at least
half their organisation’s software projects used an Agile
methodology. Large companies such as IBM, BSkyB,
BT and British Airways are now converts. Even the US
Defense Department has been mandated to deliver IT
systems incorporating Agile principles.1
Organisations are increasingly looking to develop
software in short-term projects with low capital
expenditure andvisibilitythroughout theprocess, enabling
them to assess their return on investment at regular
intervals.
But, by and large, the legal profession has failed to
catch up with the change in approach for the development
of software. The vast majority of contracts for the
development of software are still based on the traditional
waterfall technique.
As far back as 2003 Mary and Tom Poppendieck2
had
this to say of the waterfall contract:
“The contract-inspired modelofproject management
generally favors a sequential development process
with specifications fixed at the start of the project,
customersign-offonthe specifications, anda change
authorisation processintended to minimize changes.
There is a perception that these processes give
greater control and predictability, although
sequentialdevelopmentprocesses withlow feedback
have a dismal record in this regard …
The conventional wisdom in project management
values managing scope, cost and schedule to the
original plan … This mental model is so entrenched
in project management thinking that its underlying
assumptions are rarely questioned. This might
explain why the waterfall model of software
development is so difficult to abandon.”
An analysis of the assumptions underlying the waterfall
contract is long overdue. This article re-examines the key
features of the waterfall contract, and explains why it is
fundamentally flawed.