CTLR 2010 Issue 7 Waterfall Contract

Why the TraditionalContract for SoftwareDevelopment isFlawedSusan Atkinson*

Director, Corporate&Commercial Groups,gallenalliance

Computer contracts; Project management; Softwaredevelopment

IntroductionAgile has entered the mainstream. In a recent survey,more than 50 per cent of the respondents said that at leasthalf their organisation’s software projects used an Agilemethodology. Large companies such as IBM, BSkyB,BT and British Airways are now converts. Even the USDefense Department has been mandated to deliver ITsystems incorporating Agile principles.1

Organisations are increasingly looking to developsoftware in short-term projects with low capitalexpenditure and visibility throughout the process, enablingthem to assess their return on investment at regularintervals.But, by and large, the legal profession has failed to

catch up with the change in approach for the developmentof software. The vast majority of contracts for thedevelopment of software are still based on the traditionalwaterfall technique.As far back as 2003 Mary and Tom Poppendieck2 had

this to say of the waterfall contract:

“The contract-inspiredmodel of project managementgenerally favors a sequential development processwith specifications fixed at the start of the project,customer sign-off on the specifications, and a changeauthorisation process intended to minimize changes.There is a perception that these processes givegreater control and predictability, althoughsequential development processes with low feedbackhave a dismal record in this regard …The conventional wisdom in project management

values managing scope, cost and schedule to theoriginal plan… This mental model is so entrenchedin project management thinking that its underlying

assumptions are rarely questioned. This mightexplain why the waterfall model of softwaredevelopment is so difficult to abandon.”

An analysis of the assumptions underlying the waterfallcontract is long overdue. This article re-examines the keyfeatures of the waterfall contract, and explains why it isfundamentally flawed.

Agile methodsThe essence of Agile software development methodologyis best encapsulated by the Agile Manifesto3:

processes and tools;overindividuals and interactions

comprehensive documentation;overworking software

contract negotiation;overcustomer collaboration

following a plan.overresponding to change

That is, while there is value in the items on the right,the Agile Alliance values the items on the left more. Thereare a number of different types of Agile developmentmethods, and often, several are used in conjunction. Themost popular versions are probably Scrum, XtremeProgramming (XP), DSDM and Crystal. Central to eachof these methods is a common objective of minimisingrisk by delivering value in the form of working softwareearly and often.Agile divides a software development project into small

cycles—often referred to as “iterations”, which are eachtypically one to four weeks in duration. During eachiteration a team works through a full softwaredevelopment cycle including planning, requirementsanalysis, design, coding, testing and review. Fully tested,working software that is capable of being deployed isdelivered at the end of each iteration. Subsequentiterations result in additional software that builds uponor complements the software that has already beendelivered.The benefits of this approach to software development

are numerous. Frequent and regular development cyclespromote and facilitate a speed of implementation, regularfeedback leads to a continuous improvement in terms ofboth learning and understanding, and the customer hasthe opportunity to prioritise those features which are ofmost value at regular intervals.

The waterfall modelHowever, as highlighted by the Poppendiecks, the typicalcontract for the development of software is based on thetraditional waterfall method.

* satkinson@gallenalliance.com.1 2010 National Defense Authorization Act, under which President Obama gave Defense Department officials a deadline of July 2010 to create new acquisition processesthat can deliver IT systems in no more than 18 months by incorporating certain Agile principles.2Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit (Addison-Wesley Professional, 2003). The Poppendiecks have been very influential in thelean software movement, which has arguably been the inspiration for, and formed the basis of many of the principles of the Agile approach.3The Agile Manifesto was developed by the Agile Alliance in 2001. Please refer to http://agilemanifesto.org/ [Accessed August 11, 2010].

Why the Traditional Contract for Software Development is Flawed 179

[2010] C.T.L.R., Issue 7 © 2010 Thomson Reuters (Legal) Limited and Contributors

The waterfall model enshrines a sequentialdevelopment process, in which development is seen asflowing steadily downwards—like a waterfall—throughthe phases of conception, initiation, analysis, design,construction and testing. The output of each phaseprovides the input for the next stage. All of therequirements of the customer need to be specified beforeany design or development can begin.The essence of the waterfall contract is that the

customer tests whether the software meets itsrequirements, and if it does so by a certain date thesoftware is accepted. All of the contractual rights andremedies of the customer, together with its paymentobligations, revolve around the software meeting therequirements by a certain date.

Flaws in the waterfall contractThe waterfall contract is fundamentally flawed in fivekey respects:

1. The requirements are fixed at the start ofthe project.

2. It mandates that analysis, design,development and testing occur sequentially.

3. Scope, resources and schedule are fixed atthe start of the project.

4. Testing is used as a contractual tool.5. The contract is based upon a contract for

the supply of goods.

These flaws are so fundamental to the operation and effectof the waterfall contract that it is not possible to “tweak”it to accommodate an Agile approach to softwaredevelopment. It is only by examining each of these flawsin turn that an understanding of the true nature of acontract based on an Agile approach can be ascertained.

The big requirements up frontThe practice of specifying the requirements of thecustomer in a schedule to the contract—sometimesreferred to as the big requirements up front (the BRUF)doesn’t work on several counts.By definition, the contract is written before the project

starts and at a time when the customer’s knowledge andunderstanding of the ultimate solution is at its least wellformed. Over the course of the project the customer’sknowledge and understanding will inevitably increase. Ittherefore seems completely counter-intuitive that thecustomer should be asked to make a decision on what itwants at a time when it is least well equipped to do so.Since customers generally don’t know exactly what

they want at the beginning of a project they tend to askfor everything they think they might need, especially ifthey think they will only get one shot at it. This inevitablyleads to an unintended increase in the scope of the project.In 2002 the Standish Group found that 45 per cent of thefeatures in a typical system are never used and 19 per

cent are rarely used. The simplest way to cut costs andspeed up development is to stop cutting code that servesno purpose!The practice of the customer producing a written list

of its requirements is a fairly blunt and crude tool fordetermining what the customer actually needs. Althoughthe customer can generally articulate its existing problemvery well, it is less good at describing a possible solution.To make matters worse, the customer struggles in its useof language, often alternating between the generic andthe specific. Generic language gives the supplier freedomto innovate but is often too vague to be contractuallyenforceable. Specific language is contractuallyenforceable but often does not fit well within the overallsolution that the supplier has to offer.Further exacerbating the problem, the developers often

can’t understand the customer’s requirements. Butbecause the requirements assume a contractualsignificance and the fees may have agreed on the basisof those requirements, instead of the parties workingtogether to ascertain the meaning of the requirements, theparties are driven to adopt a defensive approach inresolving any ambiguity in the requirements.It is inevitable that the customer’s requirements as set

out in the contract will evolve over the life of the project.Business requirements change, the regulatory environmentchanges, the IT infrastructure changes. But the waterfallmethod does not accommodate change within thedevelopment process. As a result, the parties have to fallback on change control mechanisms for changing therequirements as set out in the contract. Instead offacilitating change, contractual change controlmechanisms actually serve to restrict change. The wholeprocess of documenting changes consumes valuableresources, can be expensive to implement, does not addvalue to the development process and generally serves topolarise the interests of the parties.Finally, these days, an evaluation of the software

simply in terms of whether it meets the customer’srequirements as set out in the contract is not terriblysophisticated. There is much more to good design thanwhether it incorporates a specified set of features. Itshould be intuitive to use. It should deal with theidiosyncrasies of the customer’s activities. It should workas a smooth cohesive whole; and it should maintain itsusefulness over time and evolve gracefully as it adaptsto the future. But there is no recognition of these otheraspects to good design in the waterfall contract.

Sequential developmentA traditional waterfall contract mandates a chain ofseveral layers through which the requirements shouldflow before they reach the programmers. The customerprovides the requirements for inclusion in a schedule tothe contract. These are then handed to the analysts whoperform an analysis and hand the results to the designers.The designers design the software and then hand theresults to the programmers. It is the programmers who

180 Computer and Telecommunications Law Review

[2010] C.T.L.R., Issue 7 © 2010 Thomson Reuters (Legal) Limited and Contributors

will make the day-to-day decisions on exactly how towrite the code. But the programmers are two or threedocuments away from an understanding of what thecustomer wants. At each document hand-off, aconsiderable amount of information has been lost ormisinterpreted, not to mention key details and futureperspectives that were not obtained in the first place.A process of sequential development forces the

designers to take a depth-first approach to design. In otherwords, the designers are forced to make low-leveldependent decisions before experiencing the consequencesof the high-level decisions. The most costly mistakes aremade by forgetting to consider something important atthe beginning. The easiest way tomake such a bigmistakeis to drill down to detail too fast.A further consequence of sequential development is

that the production of working software does not takeplace until the end of the development chain. This meansthat it can be many months, or even years, before thecustomer has sight of working software. The design paperdoes not give any real indication of what the workingsoftware will look like, and often it is only when thecustomer sees the working software that it can sensiblycomment on the design. By this stage it is often tooexpensive to accommodate many of the changes that thecustomer may request.Testing happens even later in the chain. If there is any

over-run in a software development project, it is typicallythe testing process, which is at the end of the sequentialchain, that is squeezed. This means that there is even lessopportunity for checking that the software operates in theway intended and meets the needs of the customer.The customer cannot use any aspect of the code until

the software as a whole has passed the relevant tests. Inproject management terms non-working code representswaste: it may never be put into production. And the longerthe wait until the software is put into production, thegreater the waste, and the lower the return on investment.

Figure 1: The “iron triangle”.Typically, under a waterfall contract the customer pays

the supplier a fixed fee for the development of softwarethat meets the customer’s requirements by a certain keydate. In other words, the parties have agreed to a fixedprice, a fixed set of requirements and a fixed timetable.According to Scott Ambler, a leading advocate of

Agile, there are three main variables in a softwaredevelopment project, which together combine to affect

quality: scope (features and functionality), resources (costand budget) and schedule (time).4 Ambler argues that itis unrealistic to fix or lock in all three of these. If thereare any uncertainty or unforeseen events in the softwaredevelopment process, there is no room for give. In theend, if the project team delivers at all, the quality of thedelivered product suffers, and the project is almost alwayslate and over budget anyway. Ambler’s solution is thatat least one of the three variables of the iron triangleshould not be fixed up front, so that there is flexibility toaccommodate any unknowns in the project.

Contractual acceptance testsA key feature of the waterfall contract is that if thesoftware successfully passes the acceptance tests by acertain key date, the software is accepted, and if it failsthe customer is entitled to contractual remedies. In otherwords, testing in the waterfall contract is used as acontractual tool, resulting in contractual rights for thecustomer if the software does not meet its requirements.This has a very damaging and destructive impact on whatthe true nature of testing should be. It should not be acombative exercise resulting in the parties takingpositions.Instead, testing should be an integral part of the process

for improving the design. It should happen at all stagesthroughout the process to provide valuable checks andfeedback. It is by means of testing that the developerscan make changes throughout the development process.One of the measures of well-written code is the extent

to which it has been tested. Interestingly, for awell-written software system, there may be as many linesof test code as there are of product code. The test codecontinues with the product code, and is used in makingongoing updates to the product code once it has beendeployed.

A contract for the supply of goodsAn analysis of the waterfall contract would suggest thatit is based on a contract for the supply of goods. Theessence of the waterfall contract is that the customer testswhether the software meets its requirements, and if it doesso by a certain date the software is accepted. All of thecontractual rights and remedies of the customer revolvearound the software meeting the requirements by a certaindate. There is a certain element of services in the waterfallcontract in the form of the software development, butarguably this is slotted into a contractual structure for thesupply of goods.However, an analysis of what is involved in software

development would suggest that it is a service. It is aproblem-solving exercise that involves discoveringsolutions through short, repeated cycles of investigation,experimentation and checking the results. This has beenreferred to as the “try it, test it, fix it” approach. Forcomplex problems it is wholly inappropriate to use a

4 Scott Ambler is the chief methodologist for Agile and Lean within IBM Rationale, and is a leading proponent of the Agile movement.

Why the Traditional Contract for Software Development is Flawed 181

[2010] C.T.L.R., Issue 7 © 2010 Thomson Reuters (Legal) Limited and Contributors

“right first time approach”. So there need to be multipleiterations of “try it, test it, fix it”. Actual softwaredevelopment as embraced by Agile is very definitely acontract for the supply of services.Agile suppliers are typically offering customers a

technique or a capability, not an outcome. They committo bring a certain rigour or standard to the process, butthey are not willing to commit in advance to what theeventual outcome of the software will be. A key featureand benefit of the Agile method is that the outcome willevolve over the course of the project. Agile suppliersexpect, and even welcome, changing requirements duringthe project, even at a late stage.

ConclusionThe waterfall contract is fundamentally flawed. It isinappropriate for use with Agile ways of working as theformalised specifications, processes and deadlinesmandated for a project often conflict with the informal,complex and constantly evolving business requirementsthey seek to implement. But more importantly, thewaterfall contract imposes contractual constraints thatare damaging to the success of any software developmentproject. This is because the waterfall contract reinforcessome of the worst practices of the waterfall method. It isimperative that the legal profession revisits the contractualbasis for the procurement of software development.

182 Computer and Telecommunications Law Review

[2010] C.T.L.R., Issue 7 © 2010 Thomson Reuters (Legal) Limited and Contributors