The process of software development is changing.
The days will soon be over when the client puts lots of time and effort into pre-contract planning (particularly deciding what their requirements are), signs the contract and waits for it to be developed and demonstrated (often several years after contract signature). Now clients have daily face-to-face meetings with the developers, deciding more and accepting more responsibility for the software, and paying for and accepting software products/solutions they can use in their business, thereby adding value. Do current IT contracts reflect the new methodology of software development, including risk, delivery, acceptance and payment?
In my view, many IT contracts are outdated as they follow the ‘Waterfall’ and not the agile methodology (eg ‘Scrum’) for software development today. This matters because, if the contract does not reflect the process or methodology as to how software is developed, built, accepted and paid for, the contract is failing the customer and, in some cases, the contract itself becomes detrimental to the software project. If contracts properly reflected agile methodology, more projects would be successful and clients would have software they could use.
“So instead of contracting a result, you contract a process that leads to this result. The process must provide just enough formality to make agreements safe for both sides.”[1]
I hope this article will encourage IT lawyers to look at the methodology used in software development with a view to reconsidering what the contract is for and whether their standard contracts need to change.
I am a solicitor/litigator who has ‘gone over to the dark side’ of the techies’ world, providing technical investigation in IT disputes. I will be explaining the way new methodology is used for software build and development, giving a lawyer’s interpretation of the technical side. The methodology affects everything – gathering the business requirements, development, design, testing, payment, acceptance and most importantly, communication. My views are based on my experience of working in IT, both in litigation and investigation.
The Waterfall Methodology
Traditionally, software has been developed using the ‘Waterfall’ methodology. It is called ‘Waterfall’ because, once the project starts (once the water starts moving), you can’t roll the project back.
“It typically begins with a detailed planning phase, where the end product is carefully thought through, designed, and documented in great detail. The waterfall approach also places a great emphasis on writing things down as a primary method for communicating critical information.”[2]
Whole forests have been cut down to provide the vast amount of paper required for project documentation. Think of the number of schedules attached to most contracts and these in turn refer to the various specifications , functional, design, requirements etc. How many of these vast tomes are actually read? When they are read through and followed, misunderstandings occur on interpretation of what the document is trying to capture.
So after many months talking, and writing everything down, the contract is signed with the developers going off to their ‘ivory towers’ to start work. The date for the software to be ‘live’ is often years ahead. This raises a number of important points:
· Software is changing so quickly (almost being out of date on its release), who wants old software? How will it be maintained?
· It is only when the client gets ‘hands on’ that they see what features they really need. It’s often too late and too expensive to make changes at this stage.
· A business does not remain static. It will change over time, so some requirements will be out of date or the client will need new requirements, for example if the client wants to start pricing in dollars or legislation has meant the client now needs new accounting methods for recovering VAT.
· Many of the functions that have been written into the design will never be used. These are the ‘nice to haves or we might need one of these’.
· Milestones that trigger a payment will often result in a released version of the software but it is of no use to the client who still has to wait years for the ‘system’ to go live. So the supplier is getting paid for something that may never be of use.
· Delivery dates slip. Project plans are quickly out of date. The agreed end delivery date is usually an estimate at best by the supplier. With dates slipping, the knock-on effect is that the longer it takes to deliver a project the more irrelevant it becomes.
As the project develops and the client begins to realise what they really want and need, they have to go through change control. Change control can only do so much. There are suppliers who use change control to make up on a low tender bid on the basis ‘it’s a new requirement’ and therefore new cost to the client.
Even if the supplier agrees to a new requirement or modifies an existing one, there are problems. Often the supplier’s representative (who the client meets in the regular committee, group, team meetings) will agree to these changes without knowing technically if the changes are possible. Agreement is often driven by the need to try and keep to timescales in project plans. Developers know they will have to play ‘catch up’ on these agreed changes. We see this in our investigative work when checking development history against milestones and what the supplier has promised clients in meetings.
There will also come a point when the design no longer reflects what has been agreed and no one can say if the end development will work until the whole system is tested.
Essentially the waterfall methodology is about having certainty:
· fixed price
· fixed design
· fixed time.
The waterfall measures of success:
· was the project on budget?
· do all the features work?
· was the project on time?[3]
The waterfall approach works well in manufacturing processes but not software development “where constantly improving technology demands high flexibility and imposes rapid changes of direction”.[4]
Who takes the ‘risk’ if the project fails? Should the supplier, who has been paid a large proportion of the price, repay where the evidence suggests it is the client’s endless changes that have changed the project into a totally different one to the one the supplier signed up for? There are numerous variations on this theme, as we have discovered over the years, and all of them take time to unravel.
Looking for comment from the legal world, I came across a very good article in February on outlaw.com[5], which discussed the problems: “There are two approaches to software development which can be known as conventional and prototype approaches” (I take this to be the waterfall and agile approaches in my terminology). What struck me about the article was the comments on the conventional method, ‘the software will rarely be implemented as originally specified’ and ‘The user has to be sure that before final payment, the system or software is performing according to its requirements’.
If the requirements have changed since the requirements document was written and everybody knows they are going to change from day one, what is the point of that document and the other vast amounts of documentation? They are all out of date virtually from the day the contract is signed.
The downfall of the waterfall methodology is that the supplier signed up to supply a particular system. The client now wants another (different) one.
Agile Methodology: ‘ Scrum’
In 2001, the Agile Manifesto presented the principles of a new approach:
· Humans and interactions instead of processes and tools.
· Workable software instead of extensive documentation.
· Cooperation with the customer instead of contract negotiations.
· Reactions to changes instead of following a rigid plan.[6]
“Agile is an iterative and incremental ( evolutionary) process approach to software development which is performed in a highly collaborative manner with just enough ceremony that produces high quality software which meets the changing needs of stakeholders”.[7]
Agile includes several popular methods such as Scrum, CRUD (create, retrieve, update and delete), XP, and Feature driven development, DSDM.
Scrum is the most popular and gets its name from the game of rugby, in that the scrum reflects ‘the sense’ in which meetings are held, in a group huddle almost (this is what English techies say, although Scrum comes from the
Scrum provides the processes and visibility needed to manage and control complex software and product development.[8]
Using Scrum, the client is part of ‘the Scrum team’ which is ‘cross functional’ (ie it includes developers and testers), 5 to 15 in number, facilitated by ‘the ‘Scrum Master’.
The Scrum Master has a very important role. The Master does not manage as such, but does whatever is in his or her power to help make the team successful.
Scrum works in cycles called ‘Sprints’ which are time-boxed, usually a month long overall, with daily 15-minute team meetings. The number of monthly ‘Sprints’ are estimated at the start of a project. At the beginning of each Sprint, there is a Sprint planning meeting. The team looks at what each other did the day before and what each is planning to do on that day. The key is to maximise the chances of delivering what they have committed to for that Sprint. At the beginning of the Sprint, the list of requirements is agreed, the product backlog is reviewed and goals are set. This is followed by a discussion of the Product Owner’s vision (ie what the client wants).
The deliverables don’t change during a sprint.
At the end of the Sprint the team demonstrates what it has built and has fully tested code.
The client is usually (but not always) in charge of the ’product backlog’ (this is a list of desired functionality in the system) as the ‘Product Owner’ and gives priority to the list of requirements through the product backlog. The goal is to turn ‘the product backlog into the increment of potentially shippable product functionality’.[9]
Sprints continue until the Product Owner decides the product is ready for release. There is a Release Sprint, when final integration and testing in preparation for launch takes place. It is the launch of a product a client can use and add value to their business. In some cases the product can be the delivering of the solution. A solution may be the end goal (iewhat the team wants to achieve overall) but this is a fluid process. The important point is to establish what deliverables the client can use and accept.
Therefore, in small steps, the client has far more responsibility. The client can use the regular deliverables and, most importantly, can decide what requirements are important allowing a system to grow organically rather than trying to build historically.
How does the agile methodology translate in terms of contracts? “In XP, the whole project consists of a service contract followed by a series of fixed price contracts as long as working on the software pays for the benefit. These contracts are called ‘negotiated scope contracts’, standard contracts that capture the essence of how agile projects run”.[10]
There is no ‘standard’ agile contract. An agile contract will have schedules attached, but they will be of a more practical nature (eg testing, training, deployment, project management).
Clients who want certainty on price will now have to balance this with taking a new role and new responsibilities. A budget has to be set, whether this is for each Sprint or each release. Milestone payments can be linked into releases. The acceptance of any release has to be clear, with agreed testing procedures (in the schedules). It is no longer a case of having to wait for ‘the complete system/solution’ before accepting some functionality of the system that the client can use and add value. Delivery is not years ahead, but every month or so.
I looked at some recent case law to see if Scrum would have made any difference. In Peregrine Systems Limited v Steria Limited, in the Court of Appeal in 2005, would a contract drafted to reflect a Scrum approach have prevented Steria from losing the right to rescind/terminate the contract because it had affirmed the contract or waived the breaches? The client would have known a lot earlier in its daily Scrum meetings that the supplier was not able to make the software work and that delivery was not going to happen. The additional responsibility the client has in a Scrum team, the knowledge it has on development, would have meant the problems would not have gone so far.
The question of the fixed price of 200k implementation, would also, I suggest, have been a lot clearer under a Scrum contract. You are not contracting for implementation of a system as such but for a product/solution at a price that contains flexible functionality.
Conclusion
Scrum is not the ‘silver bullet’ of software development, there will be failures mainly down to the human factor. It does however give clients and suppliers a much better opportunity to have a product or solution that works and the client can use. IT contracts need to embrace these new processes by using framework agreements more and be clear as to acceptance, payment, delivery and completion criteria. These criteria, set out in clear terms and conditions, can be used for every software release thereby providing certainty.
Above all, contracts should be drafted to reflect a practical, working relationship and support this rather than being drafted to protect the client in ‘what if it all goes wrong’ situations.
Maggi Healey is Director and Head of Legal at Vincent, which specialises in technical investigation and resolution of IT disputes: www.vincent.ltd.uk. She would like to thank her business partner Nigel Aitchison and Chris Wilson of
