Most projects nowadays will include at least some element of RAD in theirdevelopment cycle. This is all the more so when considering Web-relateddevelopment contracts: many such projects are based around RAD, and in many wayssome of the aspects of Web-related developments lend themselves to RAD. I amgoing to consider DSDM (Dynamic System Development Method).
Firstly, what is RAD and what distinguishes it from what came before? RAD hasbeen around for a long time, but took off in the 1980s. An influential book waswritten by Tom Gilb, Principles of Software Engineering Management, published in1981. Gilb advocated a concerted change to a prototyping approach in developmentprojects wherever possible. Some of the examples he gave of success storieswhere RAD was employed clearly came from ‘rescuing’ projects that had gonewrong using a more old-fashioned, waterfall method. Indeed, RAD is stillsometimes used in that way – although it would be more likely to be usednowadays as the method of choice in conducting whole projects, or at leastdiscrete parts of projects.
The Background: Waterfall Methods
RAD can be contrasted with the methods that arose in the 1970s and 1980swhich aimed to perfect a ‘waterfall’ approach to system design anddevelopment. Indeed, the waterfall approach appeals to common sense – firstyou establish what the requirements are, then you build a system to the agreedrequirements.
Waterfall methods have a number of separate phases, each feeding into thenext, in the sense that a later phase builds on the phases that have precededit. Like a waterfall, water does not flow uphill, and therein lies one of theproblems with such methods. An exhaustive phase of requirements analysis mightwell produce volumes of detailed (and hopefully accurate) descriptions of thebusiness, but they can nevertheless only hope to be a snapshot of therequirements at the time they were captured. As we all know, businesses aredynamic, they change – subsidiaries are sold, other businesses acquired,strategies change. Over the time a full waterfall method takes, quite often theresults are unacceptable to the business not because they do not conform to anyagreed specification, but simply because the requirements themselves had subtlychanged in the time the project has taken.
Other problems with waterfall methods relate to the output of the methods.Waterfall methods (SSADM is a good example of such methods) concentrate to avery large degree on producing highly accurate and stylised representations ofthe requirements as captured. However, while the diagrammatic output of such aprocess of requirements analysis may have meaning and significance to a trainedanalyst, it is highly likely that the same material will be meaningless to theaverage user. Such an individual will likely be highly bemused by the mass ofdata flow diagrams, entity life histories and the rest, especially when the useris asked to sign off such documents as a complete and accurate statement ofrequirements. While in theory such a waterfall approach is capable of capturingrequirements accurately, in practice such methods are capable of creatingambiguity and uncertainty because of the very detail of resulting documentation.
Still more problems have emerged with the sort of system which is supposed toproduce something where usability is high on the user’s agenda. Interviewsessions with individual users aimed at capturing the detail of functionalrequirements so that they can be represented in a functional specification areunlikely to be able to capture the detail of how that individual wants to beable to work. If it is left to the supplier to design a good interface for theuser, the risk is that the user will not like the result – with difficultieson acceptance.
Any statement of the problems with waterfall methods has to be understood inits proper context. They are not inherently wrong or dangerous to use.Sometimes, they may be the only viable approach in a given situation. However,it has to be understood that they were very much a creature of developmenttechniques and available technology going back to the very earliest days ofsystems development.
Advantages of RAD
This article concentrates on DSDM, which has emerged as the principal form ofRAD in the UK and is rapidly gaining acceptance in other countries too.
Why use the prototyping techniques that are such an integral part of RAD?Such techniques lend themselves to the situation where there is a large elementof usability required in the finished system. An obvious example would be Webdevelopment: users would be concerned in the aspects of the design that had animpact on the visual appearance of the finished product. However, they would beless interested in the networking technology underlying the Web design. Thesetechnical elements would be far less susceptible to a RAD method like DSDM.
The result in a case like this is that the visual part of the project mightwell be conducted under something like DSDM, leaving the technical elements tosome more traditional method. It can be seen that e-commerce in all its guiseslends itself to some such method as DSDM, at least in part. With so muchdevelopment now being done in this arena, it is again crucial to understand whatDSDM means and the contractual implications of that choice.
However, modern Web-related developments are by no means the only possibleapplications where RAD (including DSDM) is to be seen. Many types ofapplications where usability is at the fore are ready for RAD, such as thefront-office system for a foreign exchange trading system, a billing system fora utility, a practice management system in a law firm – really, thepossibilities are almost endless.
DSDM means that the supplier and user will be working together, inprototyping sessions, jointly developing a system that fits the user’s actualrequirements at the time the system is being developed, rather than at the timethe work of requirements analysis is done. The parties will work together at JAD(Joint Application Development) workshops where there will be a number of peoplefrom both parties, with a range of skills, working together on developing asystem that meets the user’s requirements. Analysts will work up the statementof requirements for a small part of the system, and the programmers will beable, within a very short space of time, to develop a trial version of thesystem to be reviewed and further worked up. Prototyping might be evolutionary(the parties will use what is developed for further development into thefinished system) or throwaway (often mock-up screens with no functionalitybehind them, developed just to show how a part of the system would look).
Potential Contractual Problems
However, having stated some of the disadvantages of waterfall and some of theadvantages of RAD, it does not mean that the contractual apparatus exists toallow the use of RAD with ease by either suppliers or users. Even the briefstatement above of how RAD works shows some of the problems straightaway.However, DSDM has (possibly) the unique distinction of being a method with acontract written especially for it. The initiative for this came as much fromsome suppliers who had found it difficult to run DSDM, in the absence of anacceptable contractual framework as from users who wanted the benefits of DSDMwithout contracting on a straight time and materials basis. More details on thisinitiative for a new contract will be given below. First, some of thecontractual problems will be discussed.
Scope
Perhaps the most surprising feature of DSDM is understanding what the scopeof the project exactly is. Most systems contracts would go about defining thescope as the initial specification, or refer to some ITT including aspecification of work to be done. This would not work in DSDM because there isno initial specification as such. On the other hand, a DSDM project is certainlynot some open-ended services contract either.
DSDM starts with a Feasibility Study (which is normally conducted by the useron its own) and which sets out, at a very high level, what it is the intendedproject is intended to accomplish. This might be a description of a new systemfor a trading room, a new accounting system, or whatever. However, the projectonly really starts to take shape when the Business Study is performed. This willconsiderably flesh out the results of the Feasibility Study, and the products ofthis stage will describe the ‘scope’ of what the parties want to achieve.
The finalisation of the Business Study marks an important stage in thelife-cycle of a DSDM project. It is only at this point, typically some weeksinto the project, that the parties will have a fairly clear idea of what will beinvolved, who is going to be doing it and an outline plan of what in detail willbe done. The parties may decide not to proceed; one or other parties may decidethat DSDM is not appropriate (DSDM has something called the ‘SuitabilityFilter’ which will be used for this purpose). So the project may come to aswift end at this point, at least the use of DSDM may stop even if the partiesdecide to proceed using some other method.
If it proceeds, or proceeds using DSDM, development will start according toDSDM principles. The technical detail of the Functional Model Iteration, Designand Build Iteration and Implementation stage need not detain us here, but someof the principles used by DSDM are important for an appreciation of the propercommercial principles that should apply to a contract for DSDM.
Development in DSDM
DSDM boasts nine general ‘Principles’ that should guide proper use of themethod, but it is not necessary to look at all of them. The following paragraphslook at the essential elements from a commercial standpoint. One principle hasbeen looked at already: Principle Seven, which provides that requirements arebaselined at a high level, meaning that the output of the Business Study muststand as the (initial) statement of scope.
Cooperative working
Principle One states that active user involvement is imperative and PrincipleTwo states that DSDM teams must be empowered to make decisions. There are twoobvious ramifications for a contract deriving from these Principles. Users workin JAD (Joint Application Development) workshops, and they work cooperativelywith the supplier in developing the system. Such users need to be authorised todo their work, and the supplier needs to be able to rely on what it is told bysuch users. For a lawyer, this means there are agency principles and questionsof authority that must be dealt with.
The other implication is that the users have to be actively involved,possibly for the lifetime of the project. This means that the user organisationmay not be able to guarantee their full availability. What happens contractuallywhen users have to hauled off a project because they are needed elsewhere – isthis an automatic breach of contract or is it simply an event which entitles thesupplier to compensation for the wasted time and effort, but which is not reallya breach at all? What happens if the users cannot be returned to the project forsome considerable time: should the supplier have to stand its team down and keepthem idle for however long it takes? A contract would need to deal with theseissues.
“Fitness for Business Purpose”
Principle Four states that fitness for business purpose is the essentialcriterion for acceptance of deliverables. This is where the law parts companywith the method, since the meaning of this expression for a DSDM projects personis probably the complete opposite of how a lawyer would understand it. In fact,the meaning the law gives to ‘fitness for purpose’ is one which manyprojects people would find curious, and it needs to be explained.
Projects look forward, to the way a system is actually going to be used in alive environment. A DSDM project would propose to produce something useful thatcould be delivered to the relevant business unit at the time of delivery. Theoverall aim of the DSDM project is certainly that the system as delivered shouldbe fit for the business purpose as at and from the time of delivery.
This should be compared with the meaning the law gives to ‘fitness forpurpose’. The law looks back, to initial contractual statements ofspecification, pre-contractual representations of requirements (by the user) orof capability (by the supplier). It may be that there is a perfectcorrespondence between these contractual and pre-contractual statements on theone hand and with actual requirements on the other, but it is not guaranteed,and gaps may well be likely. Businesses change with time, and the realisationmay grow with users that what they thought was essential is now not soimportant, that other things are more important and so on. Looking back tostatements of requirements agreed some months previously may not be the bestguarantee that the delivered system is actually what the user needs for itsbusiness. This constant move away from what was the contractual baseline isoften called ‘scope creep’
It not just in DSDM projects that the real criterion for acceptance is basedon looking forward – the same is probably true for many ‘waterfall’projects too. This sits ill with how standard implied terms (especially fitnessfor purpose) apply to major projects, and also how many contracts deal with thesame issue. While the adoption of ‘fitness for business purpose’ is perhapsunfortunate when viewed by lawyers, however, it is entrenched in DSDM usage, andso needs to be understood in its proper context.
Timeboxing
DSDM uses the concept of the Timebox, which is a fixed period for completingan agreed parcel of work. The time is fixed, so are the resources from eachparty, so there is only one other variable which could change – the work to bedone within each Timebox. DSDM does not guarantee the completion of all the workallocated for a particular Timebox, but does guarantee that each Timebox willcomplete on time (and therefore that the system – fit for business purpose –will also finish on time). This again sits in stark contrast to most developmentcontracts. Logically, there are three variables, time, resources and scope, andmost contracts seek to have 100% of the scope within time and budget. It onlytakes a little scope creep to put the pressure on this model. DSDM seeks to getaround this by fixing two of the variables and allowing the third, the scope, tochange.
Prioritisation
Most people would react by saying that this must work to the detriment of theuser, but this is not in fact so, and an explanation of how DSDM deals withscope is also necessary. The parties proceed by prioritising the work to beaccomplished by the project and therefore prioritising the work to be donewithin each Timebox. Part of the Business Study is agreeing a scheme forprioritising work. This might sound chaotic, but it is not; the parties willhave agreed as part of the Business Study what is known as the Minimum UsableSubset (that set of requirements that is indispensable to a system beingconsidered fit for business purpose)
In other words, the user is guaranteed a fully working (and workable) system,and the only question is how the parties, using the three variables of time,resources and scope, proceed in the way that is likeliest to produce a system ofmost use to the user. The parties will work on prioritisation jointly but,ultimately, the user must decide where its priorities lie. It is thesupplier’s job to advise on this, and to implement what the user decides.
A Contract for DSDM
This description probably sounds like something between a fixed pricedevelopment contract (as timeboxing means that the effort of both parties isfixed) and an open-ended services contract (as the supplier implements theprioritised scheme of work agreed with the user). In reality, a contract for RADis a true hybrid.
Some of the important points have been considered above, but even aconsideration of the basic principles of DSDM shows that ordinary types ofcontracts for systems development (or procurement) will not be adequate, as theywill not reflect what the parties actually do. Such contracts also will notreflect the realistic expectations of either users or suppliers. DSDM is at thecutting edge of system development at the moment, and it is important that thereshould be a contract that enables the parties to use the method. Such a contractshould deal with the eventualities that might actually arise and accuratelydescribe the parties’ respective duties and obligations
An attempt has been made at this by the DSDM Consortium. Working parties ofthose interested from both sides of industry were set up to examine the sorts ofobligations that a proper contract would contain. A draft of an outline contractwith explanatory notes has been circulated and is currently in beta form,available from the DSDM Consortium’s Web site (www.dsdm.org).The licence for its use (akin to open source) is there to be viewed. The‘price’ for downloading is that you should read it and pass any feedbackback to the e-mail address given at that Web site. If you want more information,please e-mail me direct.
Perhaps I should have mentioned another principle of DSDSM – PrincipleFive, that iterative and incremental development is necessary to converge on anaccurate business solution. While this is part and parcel of DSDM, perhaps thelaw could learn a thing or two here as well.
Richard Stephens is a partner working in the I & T Group at Masons.Contact richard.stephens@masons.com
