DEGREE PROJECT IN INDUSTRIAL MANAGEMENT, SECOND CYCLE, 30 CREDITS
STOCKHOLM, SWEDEN 2020
Agile Contracts Implementation for
Companies Purchasing Embedded
Systems
A transition from the traditional waterfall model
within industrial organisations
ALBIN ARNELO
NICOLE FOGELGREN BROBERG
Agile Contracts Implementation for
Companies Purchasing Embedded Systems
A transition from the traditional waterfall model within
industrial organisations
by
Albin Arnelo
Nicole Fogelgren Broberg
Master of Science Thesis TRITA-ITM-EX 2020:361 KTH Industrial Engineering and Management
Industrial Management SE-100 44 STOCKHOLM
Implementering av Agila Kontrakt för
företag som köper in Inbyggda System
Övergången från den traditionella vattenfallsmodellen
inom industriella organisationer.
Albin Arnelo
Nicole Fogelgren Broberg
Examensarbete TRITA-ITM-EX 2020:361 KTH Industriell teknik och management
Industriell ekonomi och organisation SE-100 44 STOCKHOLM
Master of Science Thesis TRITA-ITM-EX 2020:361
Agile Contracts Implementation for Industrial Companies Purchasing Embedded Systems
Albin Arnelo
Nicole Fogelgren Broberg
Approved 2020-06-08 Examiner Hans Lööf Supervisor Per Thulin Commissioner Scania Contact person Lasse Osbahr Abstract
The continuous advances and prevalence of embedded systems, being systems consisting of both hardware and software put together, provides a great challenge for industrial companies. Due to the increasing need of complex products to meet the demands of customers, companies more often need to source software from external suppliers. Software has the characteristic of being a product which is difficult to specify as it has the ability to iteratively update itself according to the changing environment, making it hard to determine precisely what it will look like at the beginning of its development. As a result, traditional waterfall contracts, for which the intention is to set clear specifications early on, are often not suitable for developing systems including software. Therefore, the need for flexible contracts, called agile contracts, among industrial companies is emerging to support new technological applications.
The purpose of this thesis was to examine what the main challenges are when implementing agile contracts in industrial companies who are purchasing embedded systems, and how these challenges can be mitigated or rectified. This was done by an empirical study in the form of interviews with various relevant actors. Firstly, employees from an industrial company looking to implement agile contracts within its procurement processes to support its embedded system purchases were interviewed. The respondents expressed their concerns and perceived
challenges with introducing agile contracts to their business. Then, to answer the challenges interviews were conducted with people who were knowledgeable within the topic of agile contracts. Also, a benchmark, a literature review and a theoretical framework have been performed to analyse previous findings within this research area.
This thesis identified nine main challenges being Risk Management, Payment Model, Time
Aspect, Communication, Embedded Systems, IP-Rights, Supplier Management, Mindset & Knowledge and Future. Each of these challenges was answered separately, but it was found that
some answers overlapped between different challenges. The most prevalent challenge was regarding communication, as a successful relationship built on sufficient collaboration and trust lays a foundation for all the other challenges to be managed more easily. Another recurrent theme was that all involved parties must understand precisely what an agile contract implies in order to make beneficial decisions to manage all the challenges.
Key-words: Agile Contract, Buyer, Embedded Systems, Intellectual Property Rights, Partnership, Payment Model, Procurement, Supplier, Transparency, Trust
Examensarbete TRITA-ITM-EX 2020:361
Implementering av Agila Kontrakt för företag som köper in Inbyggda System
Albin Arnelo
Nicole Fogelgren Broberg
Godkänt 2020-06-08 Examinator Hans Lööf Handledare Per Thulin Uppdragsgivare Scania Kontaktperson Lasse Osbahr Sammanfattning
De kontinuerliga framstegen för inbyggda system, som består av både hårdvara och mjukvara sammansatt innebär en stor utmaning för industriella företag. På grund av det ökade behovet av mjukvara för att möta kundernas efterfrågan behöver företag köpa in mjukvara från externa leverantörer. Mjukvara är svårt att specificera eftersom det har förmågan att iterativt uppdatera sig själv i enighet med den förändrade miljön. Detta gör det svårt att i ett tidigt skede av ett projekt fastställa exakt hur produkten ska vara utformad. På grund av detta är traditionella kontrakt, som ofta följer vattenfallsmodellen för vilken avsikten är att tidigt sätta tydliga kravspecifikationer, sällan lämpade för att köpa in inbyggda system. Därav uppstår behovet av
agila kontrakt bland industriföretag för att stödja nya tekniska tillämpningar.
Syftet med denna avhandling var att undersöka vilka de huvudsakliga utmaningarna är gällande att implementera agila kontrakt på ett industriföretag som köper in och utvecklar inbyggda system samt hur dessa utmaningar kan bemötas. Detta gjordes i form av en empirisk studie med relevanta aktörer, främst inom ett industriföretag som avser att implementera agila kontrakt i sin inköpsprocess för att effektivisera inköp av inbyggda system. Först intervjuades medarbetare som idag köper in inbyggda system. Dessa fick uttrycka sina tveksamheter och utmaningar kring att implementera agila kontrakt i sin inköpsprocess. Efter det utfördes mer strukturerade
intervjuer med kunniga personer inom agila kontrakt med målet att hitta lösningar till de tidigare identifierade utmaningarna. Dessa intervjuer i kombination med en litteraturstudie, ett teoretiskt ramverk och en benchmark användes för att analysera och besvara de identifierade
utmaningarna.
Denna avhandling identifierade nio huvudsakliga utmaningar från de explorativa intervjuerna;
Riskhantering, Betalningsmodell, Tidsaspekt, Kommunikation, Inbyggda System, IP-Rättigheter, Mentalitet & Kunskap samt Framtid. Dessa utmaningar har alla blivit besvarade separat men det
fastställdes tidigt att de finns tydliga överlappningar mellan utmaningarna. Den vanligaste överlappningen var angående kommunikation då en framgångsrik relation byggd på samarbete och förtroende lägger grunden för att alla andra utmaningar lättare ska kunna bemötas och lösas. Ytterligare ett återkommande tema var att alla parter måste förstå exakt vad ett agilt kontrakt innebär och hur det fungerar för att kunna fatta rätt beslut och hantera övriga utmaningar.
Nyckelord: Agila Kontrakt, Betalningsmodell, Förtroende, Immateriella Rättigheter, Inbyggda System, Köpare, Leverantörer, Partnerskap, Riskhantering, Transparens, Upphandling
Acknowledgement
To begin with, we as the authors would like to show our greatest appreciations to all people involved who have provided valuable input for the thesis and made it possible to come up with plausible findings.
Foremost, we would like to express our gratitude for our supervisors from the case company and the university KTH Royal Institute of Technology, as well as our seminar leader from the same university. These people have provided continuous feedback during the course of the thesis and contributed with guidance for us to move this thesis towards the right direction. Their assistance and support have been sincerely appreciated.
Additionally, we want to thank the other thesis groups within the seminars who have given us assessments of our work which have been highly valuable. The assessments helped us to see new perspectives and overall assisted with beneficial input.
We would also like to thank all the interview participants whose insights and perceptions within the area of agile contract have strongly contributed with finding solutions to all the identified challenges within this thesis. This thesis would never have been a possibility without your offered time and knowledge.
Abbreviations
Extreme Programming - XP Fixed-Price - FP
Incremental delivery contracts - IDC Intellectual Property - IP
Intellectual Property Rights - IPR Project Risk Management - PRM Request For Information - RFI Request For Proposal - RFP Request For Quotation - RFQ Target-cost - TC
Table of Contents
1.0 INTRODUCTION ... 1
1.1 BACKGROUND ... 1
1.2 PROBLEM FORMULATION ... 3
1.3 PURPOSE & RESEARCH QUESTIONS ... 4
1.4 PROJECT DESCRIPTION ... 4
1.5 RESEARCH APPROACH AND DELIMITATIONS ... 5
1.6 DISPOSITION ... 6
2.0 LITERATURE REVIEW ... 7
2.1 THE TRADITIONAL WATERFALL MODEL ... 7
2.2 THE CONCEPT OF WORKING AGILE ... 10
2.3 THE PROCUREMENT PROCESS IN GENERAL TERMS ... 13
2.4 CONTRACT MANAGEMENT ... 14 3.0 THEORETICAL FRAMEWORK ... 15 3.1 AGILE CONTRACTS ... 15 3.1.1 Time-And-Material Contracts ... 17 3.1.2 Agile Fixed-Price Contracts ... 18 3.1.3 Target-Cost Contracts ... 19 3.1.4 Incremental Delivery Contracts ... 21 3.2 RISK MANAGEMENT ... 21
3.3 SUPPLIER RELATIONSHIP MANAGEMENT ... 23
3.4 CHANGE MANAGEMENT ... 24
3.5 GOVERNANCE MODEL ... 26
3.6 EMBEDDED SYSTEMS WITHIN AGILE DEVELOPMENT ... 27
3.7 INTELLECTUAL PROPERTY RIGHTS IN CONTRACTING ... 28
4.0 METHOD ... 30 4.1 RESEARCH DESIGN ... 30 4.1.2 Structure & Planning ... 31 4.2 DATA COLLECTION ... 31 4.2.1 Literature Review ... 32 4.2.2 Interviews ... 33 4.2.3 Benchmark ... 36 4.2.4 Observations of Supplier-Buyer Meetings ... 36 4.2.5 Internal documents ... 36 4.3 DATA ANALYSIS ... 37 4.4 LIMITATIONS ... 37 4.5 ETHICAL CONSIDERATIONS ... 38 4.6 QUALITATIVE CONSIDERATIONS ... 39 5.0 EMPIRICAL FINDINGS AND ANALYSIS ... 41
5.1 EMPIRICAL FINDINGS FROM EXPLORATORY INTERVIEWS ... 41
5.2 EMPIRICAL ANALYSES FROM SEMI-STRUCTURED INTERVIEWS ... 43
5.2.1 Managing Risk within Agile Contracts ... 43
5.2.2 Construct a Payment model for Agile Contracts ... 46
5.2.3 The Time Aspect of Agile Contracts ... 49
5.2.4 Relationship & Communication within Agile Contracts ... 50
5.2.6 Intellectual Property Rights within Agile Contracts. ... 55 5.2.7 Choosing and Managing Suppliers for Agile Contracts ... 57 5.2.8 The Change of Mindset and Knowledge ... 58 5.2.9 If Agile Contracts are the Future of Contracting ... 61 6.0 DISCUSSION ... 62 7.0 CONCLUSION ... 76 7.1 FUTURE RECOMMENDATIONS ... 77 REFERENCES ... 78 APPENDICES ... 83
APPENDIX A: SEMI STRUCTURED INTERVIEW QUESTIONS (SWEDISH) ... 83
List of Figures
Figure 1: The waterfall model and its appurtenant phases ... 7Figure 2: Loops within agile development ... 11
Figure 3: Overall procurement process for goods & works. ... 13
Figure 4: The contracting process in project organisations, and the idea of renegotiating requirements during an agile development process. ... 16
Figure 5: The change process according to Bhave’s model. ... 26
List of Tables
Table 1: A visualisation of the exploratory interviews conducted for this thesis. ... 34Table 2: A visualisation of all semi-structured interviews conducted for this thesis. ... 34
Table 3: Perceived challenges and uncertainties regarding agile contracts from the exploratory interviews. ... 41
1.0 Introduction
In this chapter, sufficient information will be provided to understand what this thesis has aimed to address and why. To do so, crucial background information regarding the topic will be presented to give enough knowledge to comprehend the context for the thesis and why this thesis is important for building upon previous research regarding the subject. Furthermore, delimitations which have been made for this thesis will be presented, as well as a thorough outline of this thesis.
1.1 Background
Unparalleled progress within hardware technology previously used to be a driving force for new development within computer technology. It has dramatically improved the performance and reliability, enhanced the level of complexity and shaped numerous new applications for computer systems. With time, computing has undergone a rapid technological change and without the birth and growth of software development, the hardware upgrades would no longer make a substantial impact regarding development of technological systems. Software compiles the system behind the physical hardware while enabling interaction between humans and machines. It consists of programming instructions and data which tell the computer how to execute various tasks (Hikita et al. 2014).
Software is different to develop from hardware in the terms of it often being more flexible and open for modifications. Furthermore, software has the ability to upgrade itself so that it is consistent with the changing environment, making it even more complicated to predetermine its specifications and features. Usually, it is not possible to immediately specify what the software should look like and all the specifications it should include to fulfil its function, increasing the need for flexibility to adjust it continuously after development when being purchased from an external party. (Shen and Ren, 2006)
Traditionally, it has been told that mainly two choices exist for contract options in
negotiations between two or more parties; either an irresponsible time and material (T&M) arrangement where the supplier, being the party within a contractual agreement who is selling a product or service for a buyer within the same agreement, get paid according to the time and material put into the delivered product, or a tyrannical fixed-price arrangement where a price is set which is not subject to any adjustments (Fewell, 2010). The latter option is usually applied when definite specifications are available, and cost can be estimated with reasonable accuracy (Opelt et al. 2013). However, such is not always the case. During many projects requests for change are often necessary, though due to the inflexible nature of fixed-price contracts these change requests are known for being time consuming and expensive for the buyers to carry through, as well as an opportunity for the supplier to earn extra money off the project (Atkinson and Benefield, 2013). Which type of contract the buyer chooses to apply is one of the most essential parts of a procurement process, which refers to the identification of
and negotiation with a supplier who can provide the buyer with necessary functions to fulfil its strategic objectives (CIPS, 2006).
As technology goes further the request for software is increasing, resulting in that companies do not always have the time and resources to develop the software required themselves but instead have to source it externally. New digital technologies need to be deployed in shorter time frames to respond to the rapidly changing market environments. In order to accomplish higher speed and effectiveness, more and more companies adopt agile practises (Gerster and Dremel, 2019). Therefore, a necessity for industrial companies has emerged to reformulate their traditional contracts with regard to procurement of software as well as software connected to hardware, so-called embedded systems. This demands for a more flexible contract, so-called agile contract, which allows for changes during the development process while still ensuring that both parties will be satisfied with the outcome, both regarding the product itself and the price for the product. For IT-companies, of which software
development is pivotal to carry out their businesses, the concept of agile contract has made headway in recent times as many IT-companies have tried to implement it and often with great success (Eckfeldt et al. 2005). Originally, the concept of agile work ways and
contracting came from the software engineering industry due to their activities involving a large amount of software development and implementation (Nuottila et al. 2015).
An important precondition to make use of agile contracts is to understand the meaning and concept of agile. Agile is a collective name for numerous different software development methods such as SCRUM, Extreme programming (XP), Dynamic Systems Development Method (DSDM) and Crystal Family of technologies (CM). They all have one feature in common being that they are iterative, which means that they promote short developments cycles, also called loops or sprints, with incremental deliveries of software at the end of each cycle (Mohammed and Abushama, 2013). A key principle regarding working agile is that request for change should be welcomed, even late in the development process. Software should be delivered frequently and close interaction should be hold between developers and business teams (Phalnikar et al. 2009).
Companies who previously have been using traditional contracts and are now looking to implement agile ones may find it difficult to get a comprehensive picture of all important factors which need to be considered. It was found that extant literature within the area either focuses on reducing contractual risks while missing to look at project success or missed business opportunities (Arbogast et al. 2012), primarily handles sourcing and contracting of IT services within IT projects (Gewald and Schäfer, 2017), reviews specific business areas for agile contract implementation (Vanderleest and Buter, 2009) (McHugh et al. 2014), or reviews specific aspects of agile contracting such as payment model and IP licensing. This thesis will aim to address these shortcomings in earlier studies to provide further insight for a wide range of factors to consider in relation to agile contracts.
1.2 Problem Formulation
In recent times, industrial companies are noticing an increasing demand for software in their effort of developing more complex systems. Consequently, such companies find themselves in a difficult position to produce sufficient software on their own and are instead required to purchase software from external suppliers to satisfy their needs when developing embedded systems. In comparison to developing hardware, development of software is a more iterative process with shorter loops, making it more recipient for change and flexibility.
Additionally, software should be possible to update continuously after its initial
implementation to diminish the necessity of constantly repurchasing products in order to get the latest version. Also, the hardware has to continue to stay compatible with the updated software. All of these factors entails the requirement of high versatility and alterations to the embedded system during the development of it.
A distinct challenge which has arisen with the enhanced need of purchasing embedded
systems from suppliers is to formulate agile contracts that allows for modifications during the development of the product. For hardware products, the specifications are often more defined from the beginning and agreed on by both parties when signing the contract, though an option for added flexibility is still sometimes desired. For software, it is more seldom determined exactly what the buyer want to acquire but simply what functions the software should be able to fulfil. The ability to adjust the software during development is obstructed by traditional contracts, where such changes are not planned for and hence becomes costly and time-consuming to perform.
Furthermore, in a perpetually changing environment it is difficult to forecast what
technologies that will be successful and demanded in the future in order to stay competitive. As a result, what is developed today might not be as prominent in a few years. Thus,
industrial companies wish for the developed software or embedded system to be adaptable and to have the possibility to request changes to their initial specifications if desired. For hardware, changes to the initial scope is not as commonly demanded and the entire
developing process can generally be set earlier on. If the buyers demand for changes during the development process it is today difficult to manage and foremost, the supplier therefore has the opportunity to charge a large amount of money due to late amendments. There are also social and environmental sustainability issues connected to purchasing of embedded systems with traditional contracts, as the time-consuming bureaucratic change requests entails an extensive amount of unnecessary effort from the workforce as well as paperwork. Thus, the current traditional contracts are not economically sustainable for the buyer when the iterations and modifications increases in amount. For software or embedded systems, which are often more flexible to develop and harder to specify, change request has to be less expensive and more effective than it is today in order to make it plausible for the buyer. It is important to have a contract where it is elucidated that changes will be allowed, and most likely recurrent during the whole development process.
1.3 Purpose & Research Questions
The purpose of this thesis is to investigate the challenges and possibilities for industrial companies to implement and use agile contracts for their businesses as emphasised from a supplier-buyer relationship perspective in terms of purchasing software and embedded systems.As agile contracts have mainly been established in the IT sector and since a gap in the literature has been identified regarding implementation of agile contracts for other business areas, a motivation for this thesis is to come up with suggestions regarding how to implement and use agile contracts effectively for industrial companies. More specifically for this thesis, industrial companies will be investigated who are managing embedded systems within their businesses.
Furthermore, the intention for this thesis is to contribute to and enable future research within the management of agile contracts outside of the written agreement. As noticed in the
background for this thesis, numerous articles discuss how the contractual risks and other specific aspects related to contracting can be reduced, but neglects to provide industrial companies a comprehensive view of all the factors related to agile contract implementation which needs to be taken into consideration. This will be performed by an empirical study combined with findings from earlier literature to investigate how a transition towards agile contracts can be successfully achieved.
The following research question has been conducted for this thesis in order to address the research problem and purpose:
Research Question:
What are the main challenges to consider when implementing agile contracts for industrial companies who are managing both hardware and software and how can these challenges be mitigated or addressed for the contracts to be used effectively?
1.4 Project Description
This thesis has been performed in collaboration with a company incumbent within the original equipment manufacturing industry, more specifically within the company’s procurement department. Previously, the company has relied on traditional contracts and procurement processes primarily intended for hardware. However, due to an increased demand for software within their products, the company has identified a need of a transition towards more flexible contracts to support its future procurements of software and embedded systems. This thesis has taken a viewpoint at the challenge for this company specifically while also investigating how implementation of agile contracts could generally function for all industrial companies.
The company has provided this thesis with valuable information about their current procurement and development processes, their knowledge of agile contracts and the challenges they perceive regarding implementation of agile contracts. Additionally, the company has given an insight towards their operations and current contract situation. This has greatly facilitated the task of understanding the complexity with introducing agile contracts to an organisation of which the concept is still fairly new and unfamiliar.
The information which the company has offered for this thesis came in the form of
introduction meetings, interviews with employees and overall support consisting of feedback, guidance and contacts to relevant actors. Due to identity preservation, this company will henceforth be referred to as the case company when mentioned in this thesis.
Furthermore, benchmarking with two different organisations has been performed to obtain a broader knowledge of how implementation of such contracts could work. The organisations chosen for this thesis were one which is mostly IT-based and one which is more closely related to embedded systems.
1.5 Research Approach and Delimitations
As the case company has perceived a need for agile contracts due to the increased demand of software and embedded systems, this thesis has mainly focused on gathering information regarding implementation of agile contracts for purchasing and development of these specific products. Consequently, the collected literature and the interviews have primarily been conducted from sources which are concerned with software or embedded systems development and procurement. In other circumstances where a different product is developed, the outline of the contract could therefore potentially be different. Furthermore, this thesis will be examining the challenges and opportunities with implementing agile contacts in the short future. A reason for this is to come up with suggestions which are compatible and valid with the current operations, and therefore possible and pertinent to introduce immediately.
Finally, while this thesis has aimed at receiving input from a wide range of relevant actors to obtain various views and opinions regarding agile contracts, the majority of the information and interviews have been gathered from the case company and more specifically, the
company's procurement department. Due to the restricted time frame this thesis was compiled under as well as to find the best solution for the intended target industry, this thesis has put emphasis on finding suggestions for the best way to implement agile contracts for the case company. Although the gathered results are intended to be applicable for other industrial companies in similar positions, some practices of how the optimal way of implementing agile contract would look like may vary due to this delimitation.
1.6 Disposition
Following the introduction, a literature review and a theoretical framework will be presented that showcases previous findings and information concerning agile contracts. The findings have been collected from articles and books covering the concept of agile contract and other related subjects. The literature review will go through the overall concepts of procurement and contracting and will feature the following areas; Traditional Waterfall Model, The
Concept of Working Agile, The Procurement Process in General Terms and Contract
Management. The theoretical framework will present additional concepts which are important
to grasp to understand the concept of agile contracts in a wider context, and will feature the following areas; Agile Contracts, Risk Management, Supplier Relationship Management,
Change Management, Governance Model, Embedded Systems within Agile Development and Intellectual Property Rights in Contracting. The concept of agile contracts is further divided
into four subsections being Time-And-Material Contracts, Agile Fixed-Price Contracts,
Target-Cost Contracts and Incremental Delivery Contracts.
After the literature review and theoretical framework, the methodology used in this thesis will be presented and analysed. This section includes the setup and nature of the research, how this thesis was structured and prepared, how the data was obtained from the various sources and how the collected data was coded and interpreted. Additionally, limitations for the used research methods will be discussed as well as ethical and qualitative considerations which were followed throughout this thesis to ensure a reliable, valid and regardful result. Following the methodology section, the empirical findings received from the conducted interviews in this thesis will be presented. Firstly, findings will be presented from the first interviews performed with employees from the procurement department within the case company. These interviews were of an exploratory nature where the respondents expressed their concerns with implementing agile contracts in the case company's organisation. Then, findings from interviews with experienced people, lawyers and benchmark companies within this thesis will be presented, as well as own observations of supplier meetings from the case company which answers the concerns of the respondents from the exploratory interviews. The intention of the findings was to find out generally perceived problems by industrial
companies and how they can be addressed from the viewpoint of knowledgeable people within the area of agile contracts. All in all, this empirical method was used to contribute towards finding an outline of an agile contract suited for industrial companies. Finally, the findings from both the literature review and the empirical interviews simultaneously will be discussed and conclusions will be drawn regarding how a successful agile contract for
industrial companies should be set up. Additionally, future recommendations will be provided to support future research within this area.
2.0 Literature Review
In this chapter earlier findings with regard to agile contracts and other related areas from scientific articles and books will be presented to give a clear foundation of what is already known within this research topic. Also, the findings from previous literature will be used in addition to the empirical findings from this thesis to give valid answers to the research question which are based on a wide range of knowledge regarding the topic. The concepts covered in this chapter are the Traditional Waterfall Model, The Concept of Working Agile, The Procurement Process in General Terms and Contract Management.
2.1 The Traditional Waterfall Model
The waterfall model is an old and well-known model which is widely used in projects and by many major companies (Alshamrani and Bahattab, 2015). The waterfall model originated from production and construction industries, where the physical and standardised
environment made the design of the product less adaptable to change the further the
development process had proceeded (Benington, 1983). The model was however first defined in the 1950s when it was used in software development but with more undefined steps
included compared to today (Hartson and Pyla, 2019), and was later established as an explicit model by American computer scientist Winston C. Royce in 1970 who introduced it as a linear sequential software development life cycle (Mishra and Dubey, 2013; McCormick, 2012). It comprises five phases to be completed in a sequential order, namely Requirements,
Design, Implementation (coding), Verification (testing) and Maintenance. These phases and
their specific order within the development process are showcased in Figure 1.
Figure 1: The waterfall model and its appurtenant phases
Reqiurements Design Testing Implementation Coding Verification Maintenance
The five phases, as adopted for a software developing business, are briefly explained by Alshamrani and Bahattab (2015) as following:
1. Requirements: In terms of software development, this is referred to as a description of the system behaviour to be developed. Usually, this is provided from buyer to supplier as a wishlist of the features the software should be able to fulfil. The requirements are gathered, analysed and later documented.
2. Design: The gathered information is evaluated and formulated into a proper
implementation. For software development, this phase includes the activities of choosing the appropriate algorithm design, software architecture design, database conceptual scheme, logical diagram design and data structure definition.
3. Coding: The whole requirements are converted to the production environment. 4. Testing: The software solutions are tested and checked to meet the original
requirements. Eventual defects are found, fixed up and refined.
5. Maintenance: After the software is launched, it may need some further modifications,
improvements, errors corrections and refinements. This phase refers to the handling of such concerns.
The stages which the waterfall model constitutes of are not overlapping stages, meaning that before a new stage can start the previous stage has to end. This entails some complications for companies, as they can not return to a previous stage if something goes wrong during the development process to rectify it. In the large-scale company Ericsson who has been known for using this model for several years, the developed product has to run through a quality check in between each stage. This is to ensure that the software artefact developed in a specific development phase is ready to be passed onto the adjacent phase. This specific approach to the waterfall model is called a stage-gate model. (Petersen et al. 2009)
Currently, most purchasing and sales processes are managed with traditional waterfall contracts. However, as exploited by IT services in their business models the waterfall model has plenty of shortcomings, of which some have been known for decades within the software industry (Opelt et al. 2013). The waterfall model was the first systematic and sequential approach to software development, but unfortunately it was later realised that it is often ineffective and inflexible (Nuottila et al. 2015). The change management is slow and
bureaucratic since there is a lot of documentation involved, as the specifications are perceived to be clearly defined from the beginning (Nuottila et al. 2015).
Practical project management implementation problems were also apparent. For example, when errors were found during the test phase code changes were needed to rectify them.
ineffective and expensive loops which delayed the project (Liu and Horowitz, 1989). A reason for the emergence of these complications is probably that the waterfall model for software was originally developed from construction of hardware, with standardised and clearly defined procedures (Benington, 1983), and not as suitable for development of software.
Opelt et al. (2013) gives a few examples of other disadvantageous facts regarding the waterfall model, as brought up by other sources:
● New products are not developed and effective projects are not organised based on the traditional waterfall method.
● The creator of the waterfall method, Winston Royce, has stated that this model does not work entirely the first time and has to be carried out twice
● Previous studies carried out at the beginning of a project life cycle showcase an uncertainty factor of 4, meaning that the actual time it takes to perform a project varies between a fourth of and four times of what was initially predicted, implying large uncertainty.
Another prerequisite for the waterfall model brought up by Opelt et al. (2013) which can have a negative impact on the productivity of software development processes is that the budget for the project is set and needed to be allocated early, often a year before the project is scheduled to begin. This entails that the development department has to decide how much money that will be spent before knowing all the details about what the project will result in, as software is generally difficult to fully specify early on. Even if the requirements for the product are broadly defined in order to allow for later changes and all involved actors are trying to ensure that the project costs does not get out of control, more than 60% of all IT projects fail due to them exceeding their budget and not being able to fully deliver their desired functionality (Opelt et al. 2013).
Alshamrani and Bahattab (2015) supports the standpoint of that the waterfall model has its flaws, while simultaneously highlighting the strength of the waterfall model in projects where quality is essential due to detailed documentation and planning. The downsides of the waterfall model according to Alshamrani and Bahattab (2015) are, among others, that:
● The model is inflexible. If a mistake is revealed that was made in a previous stage it is not possible to go back and rectify it.
● A non-documentation deliverable is only presented at the final stage.
● All requirements must be known upfront to perform it effectively, which is a problem if the buyer does not have an explicit specification of what they need.
● Buyers are not always much involved in the project and thus do not get to evaluate the product before it is too late.
Additionally, Alshamrani and Bahattab (2015) backs up the earlier statement that the waterfall model involves a high risk of uncertainty, and therefore should only be used when the requirements are well-known, clear and fixed. This issue is further explicated by Kramer (2018), who argue that if an earlier prototype of the application being produced is not available, there exist a much higher risk of error when using the waterfall model then if it is available. Kramer (2018) also points out the issues of the stages being strict and the impossibility to go back and fix an issue derived from a previous stage by giving an example of the testing phase being conducted so late in the process. As the testing phase discloses challenges and risks of the developed application, it makes risk mitigation strategies difficult to predict and implement. Changes can also be costly, as a change in one stage entails that all stages have to change accordingly.
Kramer (2018) does however, like Alshamrani and Bahattab (2015), emphasise that the waterfall model still maintain value in certain situations. It gives a clear structure which is great for organising and controlling a project and works effectively for smaller projects or if the requirements are one-way and testable. Yet, for bigger and more complex projects the need for a movement towards more agile methods is notable (Kramer, 2018).
Likewise, Rastogi (2015) accentuate both the positive and negative aspects of the waterfall model. According to Rastogi (2015), the waterfall model is a superior model in projects where quality control is a major concern due to intensive documentation and planning at an early stage. Moreover, Rastogi (2015) embraces the rigidity of the waterfall model and how simple and easy it is to use. However, as brought up by other researchers the extensive time frame, inability to adjust the scope during the project as well as high risk and uncertainty are factors that can make alternative strategies more lucrative, especially for complex and object-oriented projects of which the requirements are at a moderate to high risk of changing (Rastogi, 2015).
2.2 The Concept of Working Agile
During the 1990s frustration emerged concerning the long lead times between business requirements, being the addressed needs from buyers regarding applications and features, and the technology deliveries that met those needs. This led to cancellation of various projects since the buyers desired continuous changes to their business, requirements and requisites, and consequently the final products ended up not meeting the new demands set by the buyers. When developing software at the time, the Waterfall Model explained in Section 2.1 was the leading method. However, it did not meet the new demand for flexibility and did not take full advantage of the possibilities that came with software development and its altered speed. (Fowler and Highsmith, 2001)
Because of this, a formation called the Agile Alliance was made by seventeen people who were the leaders of various development methodologies at the time. They wanted to uncover better ways of developing software and agreed upon one method which was finalised into 4 values and 12 principles signed as the Manifesto for Agile Software Development. The four values are presented below:
● Individuals and interactions over processes and tools.
● Working software over comprehensive documentation.
● Buyer collaboration over contract negotiation.
● Responding to change over following a plan.
The waterfall method emphasises procedures, timelines and documentation, while the agile manifesto promotes factors such as people, product, communication and responsiveness. A key principle of working agile is that requirements for change should be welcomed, even if entered late in the development process. Close interaction between developers and business teams should be introduced and deliveries of software should be frequent. (Fowler and Highsmith, 2001)
The term agile stands for moving quickly. The requirements and solutions for working agile are a product of collaboration between self-organising and cross-functional teams
(McCormick, 2012). This is supported by breaking down the overall project into shorter development cycles also called loops or sprints which last around two to four weeks during which intensive communication are hold, see Figure 2 below. Each of these cycles is about the development team performing largely the same stages as in the traditional waterfall model, though under agile development practices (McCormick, 2012). By using this method, each part of the waterfall model is developed iteratively with every sprint, which enables flexibility throughout the process as well as minimises the risk for making unchangeable decisions early. (Nuottila et al. 2015) (McCormick, 2012)
According to McCormick (2012), an agile model is a lightweight software development model developed in the 1990s. The most essential principle of this model is buyer
satisfaction, which is accomplished by rapid and continuous delivery of desired software. Since the software is developed in shorter cycles, changes can easily be introduced to the development process. It promotes room for cooperation between the buyers and the suppliers as well as opportunities for the buyers to come up with suggestions of adjustments.
The agile model invites the perspective of the end user. Instead of putting major emphasis on the rigid testing procedures, the focus is rather put on performing the tests iteratively
(McCormick, 2012). The iterative approach is useful to keep pace with dynamic development environments (Ahmed et al. 2010). In agile software testing, the aim is to test from the
perspective of the buyers as early as possible in the development process. Compared to the traditional waterfall process, the testers can give necessary feedback and suggestions far before the development process has come to the final stages (McCormick, 2012). According to Ahmed et al. (2010), traditional software development methods are not efficient enough to convene with the rapid change in requirements and short iterations which are required for efficient product delivery, thus advocating the agile model which provides more flexibility and opportunities for changes.
The agile model of software development has many advantages, such as granting the ability to respond to the changing requirements of the project, encouraging increased communication between the buyer and the development team and contributing to continuously updated documentations which leaves no space for ambiguity (McCormick, 2012). Sharma et al. (2012) adds that the agile model also requires less documentation than the traditional one, which makes it less time consuming. This is because documentation of the internal design of the software rarely needs to be fully stated, since it is determined throughout the course of the development process.
Additionally, Sharma et al. (2012) points out that the agile model minimises risks since the incremental software is delivered to the buyer after every short development cycle and feedback are taken into account from the buyers for the next sprint. However, the model is not without drawbacks. In large projects, it can be difficult to judge the effort and the time required to be put into the project since the model promotes ever-changing requirements, leading to emergence of risk for extensive time consumption and resource wastage (Sharma et al. 2012). Additionally, the requirements set by the buyer can be vague if the buyer is unsure of what the exact end-result should be. Therefore, the risk is higher that the project can go off-track if not enough monitoring is carried out. Agile types of development are also more demanding on the suppliers, as they need to make crucial decisions throughout the development process. Therefore, the suppliers are required to have senior experience in order to feel comfortable to make such decisions (McCormick, 2012).
2.3 The Procurement Process in General Terms
Procurement is a term which refers to activities and events before and after signing a contract as well as the general management activities associated with contracts. It covers a range of events from the identification of a product or service to its disposal or cessation. Procurement can be described as a business management function that ensures identification, sourcing, access and management of the external resources that an organisation needs or might need to fulfil its strategic objectives. As the definition implies, procurement is fundamental for companies looking to purchase its non-core activities from suppliers who can provide the buyer with such tasks. (Kidd, 2006) A schedule of the overall procurement process can be found in Figure 3 below:
Figure 3: Overall procurement process for goods & works.
Following are brief explanations of some of the most important steps within the procurement process from a buyer's perspective, as provided by OAS (2013):
Conduct market research
It is required to keep eyes and ears open to find suitable business opportunities. Buyers should be analysing the available suppliers within the business area of interest and investigate what their preferred type of procurement is as well as what their current suppliers/buyers are. The buyer may send an announcement where they request information from the suppliers which they want to discuss a potential procurement with, also called Request For Information (RFI).
Apply bidding document
A bidding document is elaborated by the buyer and standardised for all suppliers within the procurement. An appropriate form of a bidding document is drafted by the buyer from a set of standardised bidding packages templates, which should then be submitted to the Board of Condemnation, for vetting and approval. Each document has sections which are to be
unamended, and sections and data sheets where specific details need to be input. The bidding document is also often called a Request For Proposal (RFP).
Implement procurement procedure
The buyer should select a procedure to apply for the tendering. Some examples of procedures are an open tendering procedure where it is open for any interested supplier to submit a tender in response to the contract notice advertised, as well as a selective tendering procedure
where only pre-selected suppliers will be invited to tender. Though even in the open
tendering procedure, the interested suppliers have to meet minimum requirements regarding their financial or technical capacity. The process when the buyer requests a price tag for the product to be developed is called Request For Quotation (RFQ).
2.4 Contract Management
As organisations tend to focus on their core competencies while outsourcing non-core yet crucial functions, they are relying on contract management processes as a key to achieve and maintain a competitive advantage. Contract Management Maturity is a term which refers to organisational capabilities that can consistently create successful business results for buyers and suppliers of products, services and integrated solutions. Hence, contract management refers to the buyer’s procurement process as well as the supplier's business development and sales processes (Rendon, 2009).
Mohammed and Abushama (2013) discusses how well the four most popular agile
methodologies, namely Extreme Programming Development Process (XP), SCRUM, Crystal Family of Methodologies (CM) and Dynamic System Development Method (DSDM), can manage certain important criteria for agile development. The named criteria were Project
Set-up, Project Complexity and Contract Management. While all four methods are deemed as
successful for some of these criteria, XP was deemed as the most suitable for Contract Management. XP deals with frequently changed requirements through an iterative life-cycle with small releases. Requirements are divided into several iterations and each iteration ends with a buyer acceptance testing. This method allows for recurrent negotiation of the scope and avoids long scope contracts by splitting them into smaller ones. Additionally, XP rewards the suppliers with a fee each time they deliver new working features for the buyer, giving them an incentive to work hard while making the buyers satisfied. (Mohammed and Abushama, 2013)
3.0 Theoretical Framework
This chapter will present important theories to get a comprehensive understanding of
concepts related to implementation of agile contracts. The presented theories with be used in addition to the empirical findings made in this thesis in order to propose credible results to answer the research question. The theories were identified from the exploratory interviews to be the most important ones for addressing the research purpose for this thesis. The theories which will be gone through are Agile Contracts, Risk Management, Supplier Relationship Management, Change Management, Governance Model, Embedded Systems within Agile Development and Intellectual Property Rights in Contracting
3.1 Agile Contracts
A contract is defined by the Merriam-Webster's Dictionary of Law as (Webster, 1996, p. 102):
"An agreement between two or more parties that creates in each party a duty to do or not do something and a right to performance of the other's duty or a remedy for the breach of the other's duty"
Traditionally, it was seen from project management research that a contract defines
agreements and actions for safeguarding and adaptation during a project lifecycle. Therefore, there lies a fundamental rigidity in both project contracting processes and project contracts. To adjust the determined specifications stated in the contracts, formal change management is required to adapt to necessary changes during the project implementation phase. However, this type of formal, legal-centric contract and bureaucratic approach to project change management is more suited to less complex projects where the targeted outcome can be precisely defined from the beginning. (Argyres & Mayer, 2007)
For more complex projects, such as agile software development, the aspired result might not always be settled on beforehand but decided on during the implementation process, in which case enhanced flexibility is needed to maximise the created value. For such situations, a new type of contract is required which embraces and encourages these changes. As contracts have traditionally been treated as complete agreements which includes all possible solutions for potential contingencies, the need for developing comprehensive, well-functioning and profitable contracts has been apparent. Agile software development focuses on cooperation between supplier and buyer, constant redefining of requirements and approval of continuous changes in the project. Hence, agile projects need flexibility to handle uncertainties,
especially in the early parts of the project when exact details of the project scope and implementation are lacking. (Nuottila et al. 2015)
Traditional industrial purchasing transactions can be seen as routine procurements compared to transactions and contracts in a more complex project business environment (Artto and Wikström, 2005). In a project business environment, it is important to have a mutual climate of trust in a cooperative relationship between the parties. If the involved parties have
confidence in each other it is easier, faster and cheaper to maintain a more rudimentary contract. Furthermore, as follows from the principal of the Nordic Contract Law, building trust between the parties can prevent opportunistic behaviour and invite parties to dare entering more flexible contracts (Sund-Norrgård et al. 2015). Earlier, when legal
disagreements between the parties happen, one party is always right and the other is always wrong according to the contract law. In long-term relationships this kind of mentality is not beneficial, and instead the parties aim towards win-win situations where both parties are satisfied, and are equally responsible for managing conflicts (Pohjonen, 2006).
As stated by Kajala (2015) the linear view of the contracting process in project organisations have changed due to agile methods in the software industry. For example, the specifications are not fully set from the start of the project and are instead continuously modified during the project development process. Additionally, the involved parties in the project constantly seek for better contract practices, leading to adjustments in the originally agreed conventions. Hence, the agile approach entails that the contracting process contains room for refinement and re-evaluation. Moreover, the agile approach allows for the contract to be renegotiated even during the implementation phase. The dynamic renegotiation in the contracting process of agile projects is illustrated in Figure 4 (Kajala, 2015):
Figure 4: The contracting process in project organisations, and the idea of renegotiating requirements during an agile development process.
An important consequence of agile development is to settle on details during the course of a project and define the scope on a per-iteration basis. The purpose of this approach is to minimise risks as the project can be redefined when more knowledge is available, but also to allow for reception of feedback during development. The benefits of agile development will yield a product with more likeliness to fulfil its purpose and satisfy the users (Thorup and Jensen, 2009).
3.1.1 Time-And-Material Contracts
The contracts that are governing software development has generally been classified as either
Time-and Material (T&M) or Fixed-Price (FP). For FP contracts the cost of completing the
project is predetermined, while for T&M contracts the price is not set from the beginning. Instead, T&M contracts are designed to reimburse the supplier of the money put into the project plus an extra profit. In T&M contracts, the suppliers get paid proportionally for the time and money which they invest in the project which makes them profit from extended effort aimed at developing, enhancing or fixing each software feature. The supplier is not under as much pressure to finalise the project on time and under a restraining budget as compared to a FP contract, allowing room for extensive designing, programming and testing when necessary, and thereby create opportunities for a higher quality software (Slaughter et al. 2012). T&M contracts is a way to protect the supplier from most of the risk while
transferring the cost of overruns to the buyers (Gopal and Koka, 2010). A common practice for companies is to keep specifications loosened for T&M contract, while they are required to be much more defined for FP contracts. The purpose of the loosened specifications is to leave room for functionality changes during the development process, making a T&M contract preferable as the supplier gets rewarded for the time and resources they put into the development of the product. (Fink et al. 2013).
The downsides of using T&M contracts instead of FP contracts could be that they provide weaker incentives for the suppliers to efficiently (low costs) and effectively (meet
requirements in short time) produce the software, as added costs are passed onto the buyers (Gopal and Koka, 2010). Consequently, T&M contracts has been perceived to be difficult to sell in for the buyers since they fear an open ended agreement and the potential for additional costs (Eckfeldt et al. 2005). Capped T&M contracts is an extension to the traditional T&M contracts in order to mitigate this issue. In a capped T&M contract the buyer sets a price which, regardless of the effort put into the development of the software from the supplier, will not be exceeded. This of course is not advantageous for the supplier as the supplier suddenly bears most of the risk. Should the project take longer than estimated, the supplier will be punished as the fees are capped (Classen, 2007). The intention of inserting a cap to the T&M contract is, however, to provide benefits for both the buyer and supplier. As stated in a citation presented by Messai (2019, p. 9):
“Capped T&M contracts provide benefit to the supplier early on by fully covering their expense; but also provide benefits to the customer towards the end of the project by providing a limit to the total exposure. It’s in both parties interest to deliver high-value functionality as early as possible and to avoid cost overruns.”
3.1.2 Agile Fixed-Price Contracts
Similar to the capped T&M contract, the agile fixed-price contract is a hybrid of the traditional models to find ways of rewarding both the buyer and the supplier for larger, complex deliveries. As mentioned in Section 3.1, Fixed-Price (FP) contracts are contracts where the buyer makes a payment for a specified product and later obtains it on an agreed date. Unfortunately, software projects are seldom this uncomplicated and thus, this method is not popular among the agile practitioners. For rather stable tasks the likeliness of problems is minor, therefore FP contracts works well for the suppliers, though they can be a little more expensive for the buyers since the set price is estimated with some margin to the actual production cost. However, in many software development projects the task is uncertain and changing, hence the project risk is high for the supplier within FP contracts and should therefore be avoided (Poppendieck and Poppendieck, 2003).
Yet, FP contracts does have some beneficial terms that make them attractive for buyers. Some which are mentioned by Van Cauwenberghe (2004):
● If projects are ranked on a multi provider bidding process, the buyer needs to know scope, timing and price to choose between the bids.
● Buyers perceive that they take no functional risk. If the supplier fails to deliver the project on the decided time and with the determined specifications, the buyers always has the option to sue the supplier.
● As the price is known on beforehand, the buyer takes little financial risks with a FP contract.
● More control and a clearer structure and overview of the project is apparent.
To try and capture these benefits while making the contracts more applicable for agile projects and for agile organisations to use, variants of the FP contracts have been introduced, so-called Agile FP contracts. At large, Agile FP contracts simply require a broad description of the project instead of a detailed one. The supplier and the buyer together define common assumptions in terms of business value, implementation risks, expenses and costs. Based on these assumptions, a not yet contractually binding agreement is arranged where an indicative fixed price scope is formulated. Subsequently, a test phase of the project is carried out from which the empirical findings are compared with the initial assumptions and the outline of the entire project can be set, including a finalised price. Additionally, conditions which are enabled to change later are decided upon. (Opelt et al. 2013)
3.1.3 Target-Cost Contracts
The Institution of Chemical Engineers (2007, p. 2) provided a definition of target-cost contract being as following:
“A particular type of cost reimbursement contract in which the contractor is reimbursed his or her costs subject to the application of a formula, which allows the contractor to share in savings made, often called “gain share,” or to contribute towards additional costs incurred, called “pain share,” according to how well the parties are able to manage the cost of the work.”
As the previous contract frameworks suggest, setting up a contractual agreement that supports an agile approach and fosters productive supplier-buyer relationships can be a substantial challenge. As motivated by Eckfeldt et al. (2005), FP contracts are not beneficial for the suppliers from an agile standpoint since they take on all the scope risk, but they can also be negative for the buyers as they commit themselves to a scope very early in the project and later suffers in cost and difficulty if they wish to make any changes to the scope. As for T&M contracts, a large amount of the risk is shifted over to the buyer and unless the buyer have great confidence in the supplier’s work, T&M contracts are usually dismissed by the buyers as an option. However, when a higher degree of confidence has been developed between the parties, a T&M contract is the contractual model of these two to strive after. Eckfeldt et al. (2005) argues that both of these approaches reinforces the traditional adversarial supplier-buyer angle and limit potential for greater success for both parties. Consequently, an alternative approach has arisen where the risk is more evenly distributed between both parties, namely Target-Cost (TC) contracts. (Eckfeldt et al. 2005)
Eckfeldt et al. (2005) explicitly advocates the TC contracts in front of both T&M and FP contracts. Regarding T&M contracts, the authors do highlight that the model has favourable attributes as it allows for more equal risk sharing than FP, though they have found the model difficult to promote as the buyers are afraid of open-ended agreements with potential for unchecked costs. (Eckfeldt et al. 2005) TC contracts are typically used to share the monetary outcome of work or a project. The intention is to establish cooperative behaviour between the parties by sharing any project gains, losses, reward, risk, as well as motivate the parties to work towards a mutual goal (Hosseinian and Carmichael, 2014).
In TC contracts, the supplier and the buyer together agree on a target cost. The target cost is determined on the basis of three elements (Naughter, 2017):
● Base fees - The standard cost of the labour, material and other necessary resources to perform the project.
● Contractor fees - The buyer’s general overhead, insurance costs and desired profit margin.
● Risk - Accommodation of the risks identified by the supplier and the buyer, e.g. changes to the scope or one party’s withdrawal.
The target cost amount represents the expected cost of the supplier for the provided services or goods. If in the end the final cost of the project is below the target cost both parties split the savings, whereas if the final cost exceeds the target cost both parties are responsible for paying the extra money (Eckfeldt et al. 2005).
Just as with any other contractual method, TC contracts bears its own benefits in comparison to alternatives. As the supplier gets rewarded for the cost savings incurred compared to the set target cost, but is penalised for budget overruns, it entails strong incentives for the supplier to perform the project efficiently. This can also enhance collaborations between the supplier and its buyer, since it lies in both parties’ interests to minimise the costs and avoid additional expenses. It can also allow higher quality control compared to other agile contracts as the buyer gets involved early in the process to advise on construction costs, building design, project programming, construction materials, alternative construction techniques and other constructability issues, while for other contract types such as T&M the suppliers usually have more free rein (Chan et al. 2012). The same benefits are advocated by Eckfeldt et al. (2005), who further emphasises the contract’s ability to align the interests of the supplier and the buyer, leading to augmented collaboration.
There are not many researches to be found who points out any disadvantages with TC contracts. Trench (1991) stated that the only real disadvantage with TC contracts is that they are difficult to use in projects where many changes are expected since they do not possess the same flexibility as other contracts. This drawback was also supported by Eckfeldt et al. (2005), who however answered it by highlighting that as long as the communication between the parties is satisfactory, changes to the scope can be managed rather early by calculating a new price estimation. This further increases the collaborative nature of the projects and entails a more evenly shared risk. As expressed by Eckfeldt (2005, p. 7):
“Target-cost contracts offer a unique and promising alternative that allows developers to share risk with clients and for clients to feel like developers are working with them to make the project successful”.
According to Messai (2019), it is important to not only put focus on the financial incentives when deciding on the target cost as this system can be resolutely virtuous if the motivations are not simply financial but a bit more diversified. Messai (2019) does emphasise that the challenging part of TC contracts is for both parties to find and agree on the final price.
3.1.4 Incremental Delivery Contracts
Incremental delivery contracts (IDC) are organised in an iterative fashion with several review points between the buyer and supplier. This invites opportunities for the buyers to evaluate the performance of the project, to make the perimeter evolve and to decide on whether to continue with or to terminate the development of the project (Messai, 2019). This type of contract is particularly developed and adapted for agile project management due to its iterative nature. Messai (2019, p. 10) has highlighted IDC as it “incorporates a great deal of
flexibility and allows for ongoing improvements rather than a fixed timeline with concrete requirements”. Overall, it appears that the amount of articles which discusses IDC contracts
are fairly limited and that it is not recognised by all researchers to be one of the main types of agile contracts.
3.2 Risk Management
A description of risk management is provided by Merna and Al-Thani as following (2005, p. 8):
“All projects involve risk - the zero risk project is not worth pursuing. Organisations which better understand the nature of these risks and can manage them more effectively can not only avoid unforeseen disasters but can work with tighter margins and less contingency, freeing resources for other endeavors, and seizing opportunities for advantageous investment which might otherwise be rejected as too risky”
Additionally, Merna and Al-Thani (2005, p. 14) provides a broad definition of project risk as follows:
“Project risk is the implications of the existence of significant uncertainty about the level of project performance achievable”.
Although each project is different and involves some degree of uncertainty, many organisations still tend to assume that all of their projects will succeed, neglecting the possibility of them failing as well as analysing the project risks and are therefore unprepared when something goes wrong (Raz et al. 2002). Companies faces a very wide range of risks which can affect the outcome of their operations. Raz et al. (2002) defines project risks as undesired events which may cause delays, excessive spending, unsatisfactory project results, safety or environmental hazards and even total failure.
Today’s businesses possess a wide range of contract related and risk management oriented skills and capabilities. Contract risk management solutions can in many cases be built in into activities, systems and processes that businesses already have in place. While many business,
