Link to thesis - Concept - NTNU

2. RESULTSThe arguments against and in favour of project flexibility are summarised in the following. Differentstakeholders in a project have different perspectives on flexibility. Flexibility is also seen differentlydepending upon the different phases of a project. The context and type of a project also influence theattitudes toward and benefits of flexibility.The case against project flexibilityA wide range of studies and authors (including Morris & Hough, 1984; Eikeland, 2001 and Love et al.2003) have pointed to changes in specifications as a key driver in cost overruns of projects. Changeorders are widely seen as undesirable, even if contractors do see them a possibility to improve the profitfrom the projects (Christensen & Gordon, 1998). Once a project has been decided upon and theplanning and execution has begun, changes will often reduce the efficiency of the project. Changeorders are also a source of major disagreements between different actors in projects.Morris & Hough (1991) specifically argue against concurrency between development and production.Miller & Lessard (2000) point out the irreversibility of large engineering projects and the importance ofbold commitment from key stakeholders, arguing against flexibility once the front-end phase is over.Flexibility commonly is seen as undesirable in the execution phases of projects. The high andunpredictable cost of change orders is the key argument against flexibility. The negative consequencesof the use of flexibility in projects are also emphasised by project stakeholders that are responsible forthe execution of projects, such as contractors. The potential for utilising flexibility in civil engineeringprojects is seen as limited, due to their indivisibility and irreversibility. Arguments such as “we do notbuild half a bridge” are used. There is also the possibility that visualising flexibility in a project, such asthe openings for later adjustments or even cancellation, will reduce the likelihood that the project willbe approved and carried out as planned. In such a perspective, commitments, not adjustability, arerequired to communicate credibility to affected parties.The case in favour of project flexibilityKreiner (1995) points out that the traditional focus on stability in project management becomeschallenged under uncertainty, which creates what he calls “drifting environments”. A number ofscholars, including Mintzberg (1994) and Bettis & Hitt (1995), argue that flexibility is necessary inorder to face the changes, uncertainty and turbulence in the business environment.The real options paradigm (for example Amram & Kulatlaka, 1999) illustrates that uncertainty canincrease the owner’s value of a project, as long as flexibility is preserved and resources are notirreversibly committed.Miller & Lessard (2001) lists "late locking" as a key success criterion for large engineering projects,along with an exploring, iterative front-end process. Hall (1980) suggests a risk-avoiding strategy,based on minimal commitments at each stage where decisions are necessary. He argues for anincremental or adaptive approach, rather than creating new projects. He suggests enlargements andadaptation of existing projects rather than building new ones, whenever possible.Modern approaches to development of IT-systems include functional specifications and iterativedevelopment. This is described by authors such as Poppendieck & Poppendieck (2003) and Boehm &Turner (2003).Most authors agree on the value of flexibility in the front-end phase of projects. Flexibility is alsogenerally seen as an advantage in industrial development project (Verganti, 1999). Clark & Fujimoto(1991) and Midler (1995) illustrate this based on the automotive industry. The benefits of flexibility areeasier to visualise and implement in industrial development projects than in more standardised civilengineering projects. Flexibility is more valued by the stakeholders that have a responsibility for theoverall profitability or societal benefit of a project, compared to those who are only responsible for thecost side of the project.3