1. Introduction
This article emanates from a cooperation between the Legal Adviser to the Danish Government (Kammeradvokaten) and the Danish Agency for Digitisation (Digitaliseringsstyrelsen) in drafting the ‘K03 – standard contract for long-term IT projects based on an agile method’.
The K03, with appendices and guide, was published in a final version at the end of 2012.[1] This article is a brief introduction to the contract.
2. The Agility of the K03
The K03 is a new standard contract envisaged for use in long-term, large-scale IT projects where the development is mainly based on the use of an agile method.
The idea behind the contract was not to make a one-size-fits-all contract but rather to provide a contract to start from for those wishing to engage in an agile project. The contract is therefore to be seen as a supplement to the existing Danish waterfall model contracts.[2]
The intention is for the contract to be neutral in the sense that the contract can be used for any agile method. The contract therefore contains no predetermined requirements in terms of project management and delivery and engineering method/practices, see Appendix 7 of the contract. The contract is thus envisaged to accommodate projects of different degrees of agility and different methodologies and combinations thereof. A supplier might for instance offer eXtreme Programming as the engineering practice combined with Scrum as the team management method supplemented by the more traditional Prince 2 project management.
A prerequisite for agile development, regardless of the methodology chosen, is that flexibility is introduced in the project. Flexibility is provided by ‘keeping open’ one or more cornerstones (scope, time, and cost) of the project, as opposed to traditional project contracts where scope, time, and cost are fixed in ‘the iron triangle’.
The K03 has been drafted within the auspices of the Danish State for use by public authorities. The contract therefore takes account of the budget security considerations of the State in laying out the financial framework of the project. As, moreover, it will often be necessary for the public authority customer to complete the project within a predetermined deadline, eg due to certain legislative requirements, time and cost are as a general rule fixed in the K03. This leaves any flexibility to lie in the scope.
The flexibility of the K03 is notably reflected in the customer’s requirements: the requirements are prioritised in Mandatory and Other Requirements (clause 2.1 below), and at the time of conclusion of the contract the requirements are formulated general and needs-oriented. The requirements are then broken down and specified on an ongoing basis (clause 2.2). The evolving requirements and prioritisations are at all times related to the customer’s business objectives and needs.[3]
The flexible framework of the K03 is continuously drawn upon. Thus, the development process is broken down into a series of ‘mini projects’ (iterations) typically consisting of the following phases: Analysis and design, development, agile demonstrations and evaluation, and planning of the next iteration. The development work progresses in a close cooperation between the parties where the customer is assumed to play an active part, in particular in connection with the elaboration of the business objectives and needs and the specification of the requirements, but also in connection with the continuous prioritisation of the development activities.
2.1 Mandatory and Other Requirements
The contract is based on an essential distinction between Mandatory and Other Requirements. The distinction is the reflection of a prioritisation made by the customer when drawing up the prioritised requirements list. Mandatory Requirements are requirements which the customer has indicated to be indispensable to the fulfilment of the customer’s business objectives and needs. Other Requirements are requirements which are not mandatory and thus, by definition, dispensable. For example, the customer may state as a Mandatory Requirement in a website development project that it must be possible for the business to create and edit a news list on the site. A news list will often be an essential part of the external marketing of a business. An Other Requirement in this connection might be that the users of the website, ie the customers of the business, must be able to see – and sort – the news by subject, publication date, etc. The Mandatory Requirement in the example thus ensures that it is at all times possible to create and display the news. The Other Requirement, however, relates to the added refinement of the display, which may increase the commercial value, but which is not essential to the commercial value being realised.
In order to promote the flexibility of the project, the contract only imposes on the supplier an obligation of result as concerns the Mandatory Requirements. As concerns the Other Requirements, the supplier has an obligation of effort and must endeavour to fulfil as many requirements as possible (see clause 3.2.2).
By prioritising the requirements in Mandatory and Other Requirements it is ensured that the parties in the joint planning of the individual iterations focus on the areas of most business value to the customer. The distinction enables the parties to postpone or entirely give up Other Requirements which are not indispensable to the customer’s business objectives and requirements if this is necessary for the progress and profitability of the project (see clause 6.2.1).
2.2 Breakdown and specification of the requirements
In the agile standard contract, the customer’s requirements specification is replaced by the customer’s statement of needs. The customer’s statement of needs is a dynamic document which contains the customer’s business objectives and needs and the customer’s prioritised requirements list. The inclusion of the customer’s business objectives and needs in the statement of needs emphasises that the deliverables must not only meet a number of specified functional and non-functional requirements, but they must also be suitable for supporting the customer’s business objectives and needs (see clause 3.2.2).
At the time of conclusion of the contract, the requirements to the solution are worded in general and needs-oriented terms. The requirements are subsequently broken down and specified on an ongoing basis – and always related to the business objectives and needs (see clause 3.2.2 and appendices 3a.i and 3a.ii). The general and needs-oriented wording of the requirements is an essential element of the flexibility of the K03, as the customer thereby avoids the constraints of specific and detailed requirements at the time of drawing up the prioritised requirements list, and the supplier avoids the constraints of a fully described final solution at the time of conclusion of the contract. In this connection, it is important that, when wording the requirements, the customer takes into account whether the wording allows the supplier to work on different solutions and to benefit from the experience gained by both parties throughout the project. When specifying the requirements of a website development project, for example, there is a lot of difference between a detailed dialogue between user and system for the creation and display of a news list and a simple requirement specification to the effect that it must be possible to create and display news in a list. In the first example, the solution will be constrained to the customer’s notion of how a news list should work and how it is technically realisable. The customer is thereby precluded from drawing on the supplier’s (often considerably more extensive) knowledge in the field, and the parties are precluded from designing the solution during the project while including both the customer’s and the supplier’s insight regarding the customer’s actual needs and the corresponding technical possibilities.
The overall and needs-oriented requirements drawn up at the time of conclusion of the contract are first broken down in the clarification and planning phase where the parties go through the customer’s statement of needs in order to clarify the technical possibilities and limitations of the deliverables (see clause 5.1.1). On this basis, the customer adjusts the statement of needs and adds/clarifies or changes the priority of the requirements in the prioritised requirements list. The review of the customer’s statement of needs carried out by the parties is thus assumed to lead to a breakdown of the customer’s requirements into more specific requirements. The specific requirements are furthermore prioritised by the customer into Mandatory and Other Requirements (see clause 2.1).
The development team, in which the customer participates, will work in each iteration on the requirements and specify them in more detail in order to determine how to fulfil the requirements in the iteration in question.
3. Governance Processes of the K03
Agility does not mean that there should be no governance and no close control of the project, but the driving force behind the project should not be contractual obligations and the related remedies of breach. The project should be run in a close cooperation between customer and supplier with a view to achieving the business objectives and needs, in particular through the achievement of the customer’s mandatory requirements. The K03 was designed with this in mind.
One of the most significant tools in the control processes of the K03 is to ensure that the parties have insight into the progress of the project. The K03 contains a number of traditional remedies of breach and dispute settlement mechanisms at different levels (see clauses 25-29 and 37), but these remedies and mechanisms are assumed to remain in the background.
3.1 Insight
The contract seeks to give the parties insight into the progress of the project in various respects. The circumstances and contractual mechanisms set out below are primarily directed at the customer and thereby provide the customer with more insight into the project as compared to the insight offered by a traditional development process. But the supplier is given a more profound insight as well. Through the cooperation requirement (clause 3.1.1) the supplier gains a greater understanding of the customer’s business objectives, needs, and priorities. Furthermore, the agile demonstrations (clause 3.1.2) will be valuable to the supplier by providing insight into whether the development proceeds as planned – and valuable insight into whether the customer’s business objectives and needs are achieved.
3.1.1 Close cooperation between the parties
Insight is first and foremost gained from the way in which the parties cooperate. An agile development project requires the parties to cooperate on the development.
Where, in a traditional project, the customer is not expected to participate in the development process after having drawn up the requirements, the customer’s ongoing participation during an agile development project is essential to the continuous breakdown and prioritising of requirements, participation in agile demonstrations, etc. Thus, in the K03, requirements as to the customer’s participation are laid down, see for instance clause 10 of the contract, and both parties are made responsible for the implementation of the project, see clause 3.2.1 of the contract. The supplier holds the overall delivery responsibility whereas the customer shares in the responsibility for the implementation of the project.
There is no set formula for a good cooperation, and the provisions of the contract regarding the cooperation of the parties are therefore set in overall terms. It is assumed that the parties are in frequent contact, but also that the parties cooperate at different levels across their respective organisations. The contract thus assumes that representatives of the customer are involved in the continuous development (see clause 3.2.1.3 of appendix 7 to the contract). In this connection, the individuals involved will often be representatives from the customer’s business. Often, specific knowledge of the customer’s business processes, problems of common occurrence, usual handling thereof, etc, will be required in the daily cooperation. In a website development project, for instance, it may be necessary to involve the staff of the business who are editors of the website. In other words, the staff who actually use and ‘feed’ the site actively. The directors of the business will be able to focus on the management decisions relating to the business objectives and needs, the organisation of the project, financing and time schedules.
As the requirements are worded in general and needs-oriented terms, their continuous breakdown will require several decisions regarding the design of the solution. These decisions are important to – and must be made by – both the customer and the supplier, and the contract therefore requires that both parties are organisationally supported to continuously and at short notice make decisions of relevance to the implementation of the project.
3.1.2 Agile demonstrations
The contract states that so-called agile demonstrations are to be carried out at the end of each iteration (see clause 5.2.2).
The contract does not regulate the specific contents of the agile demonstrations, but their purpose is the supplier’s demonstration to the customer of what has been developed in the iteration in question. There are no remedies of breach in relation to the agile demonstrations, as their purpose is to detect and handle faults as quickly as possible (the ‘fast to failure’ principle) and to ensure that the deliverable fulfils the customer’s business objectives and needs. For example, the supplier may have developed a solution which is effective and appropriate in relation to the establishment and display of a news list, but which does not support the customer’s organisational setting. If the supplier’s solution requires that the editors have special skills and the customer’s staff do not possess such skills, the solution will not work in practice in the customer’s organisation. This will be ‘detected’ in an agile demonstration and the solution can be adjusted accordingly.
3.1.3 Insight as a management tool
The principle of agile development is to enable the parties to learn from past mistakes, if any, but also to use and benefit from the experience gained in the course of the project. The ongoing breakdown of requirements thus reflects the parties’ increased insight into the customer’s needs and the specific options available. As the parties go through the iterations with analysis and design, development, agile demonstrations, and evaluation, the parties will learn more about the customer’s needs as well as the technical challenges and possibilities posed by these needs. The insight in terms of lessons learned is utilised in the ongoing breakdown of the requirements. It is therefore of vital importance to the project that the parties continuously – and at an early stage – accumulate insight into the project. This is in contrast to a more traditional project process where, until the acceptance test, the supplier and the customer have to rely on the customer’s requirements specification and the supplier’s status reporting, respectively. The continuous insight into an agile project thus becomes a separate and important management tool – both to the customer and to the supplier.
The customer, in particular, must use the insight into the progress of the project for the evaluation of whether value for money is achieved. Lack of return on investment in a project may be due to the cooperation having gone off track, but may also indicate that the remaining work does not measure up to the costs involved. The customer is therefore assumed to evaluate the profitability of the project on an ongoing basis. In order to ensure that the customer is able to act on any such profitability evaluation, the contract contains a right for the customer to withdraw at any time in the process against payment for the work already carried out as well as additional compensation, if relevant (see clause 34.1).
4. Practical Experience
The contract is starting to gain ground among Danish public authorities, both in its original form and in various hybrid versions. One such hybrid version, which is currently running its course, is one that distinguishes between partial deliveries within a project in terms of methodological approach: some partial deliveries are agile and regulated by the K03 and other partial deliveries take a traditional waterfall approach. Agile development requires much of the customer, and it will often require a paradigm shift for public authorities that traditionally work with quite hierarchical, top-down governance structures. The pragmatic approach to agile development represented by the hybrid version makes it more feasible for many authorities.
In addition to its use by Danish public authorities, the contract is being considered with interest by the private sector and across the Danish borders, primarily in Scandinavia, Iceland and the UK. Most recently, the contract was presented – and received well – at the 2013 Agile Business Conference in London. The contract will be presented at the ‘Agilia Conference 2014’ in Brno, Czech Republic, 25-28 March.
As hoped, the contract has contributed to establishing a fresh approach to Danish public IT projects by enabling agile development in large-scale IT projects. The extent to which this fresh approach will succeed in shifting focus from talk about budget and delay into development of solutions which meet the agreed time and price and correspond to the actual needs of the customers remains to be seen.
Tom Holsøe is a partner and certified IT lawyer with the Legal Adviser to the Danish Government.
Mia Thulstrup Gedbjerg is a lawyer and certified Agile Project Manager, practitioner, also with the Legal Adviser to the Danish Government.
This article is a translated and revised version of the article ‘K03 – ny dansk standardkontrakt’ which was published in the Nordic journal Lov&Data in March 2013, issue no. 113. Translation provided by Ingrid Møller Nielsen, translator with the Legal Adviser to the Danish Government.
[1] Contract and appendices are available in English at http://kammeradvokaten.dk/forretningsomraader/kontrakter-og-udbud/k-kontrakter.aspx. An English version of the guide to the contract is not yet available.
[2] The K01 and the K02 which are also available at http://kammeradvokaten.dk/forretningsomraader/kontrakter-og-udbud/k-kontrakter.aspx.
[3] The contract uses the terminology ‘business objectives and needs’ in lieu of ‘business case’.
