68 N.O.E. Olsson / International Journal of Project Management 24 (2006) 66–74are not designed for adjustments within the project timeframe. A strategy characterised by high flexibility in theproduct and low in the process is termed ‘‘robust concept’’in Fig. 1. This project situation assumes that thedecision process related <strong>to</strong> the project can be fairlystraight forward because the result of the project is preparedfor alternative use. An argument against such astrategy is that flexibility in the product can be costly.It is also challenging <strong>to</strong> target the flexibility <strong>to</strong> where itis needed. Flexibility in the product that turns out <strong>to</strong>not be used, can be seen as a waste of resources.A basic principle in the situation with low flexibilityin the product, and high flexibility in the process is thatfinal decisions can be postponed (for example, the freezingof specifications) in order <strong>to</strong> gain as much knowledgeas possible. A low flexibility in the product isdesirable when flexibility in the product is costly. A potentialdrawback of this strategy is that it might causefrustration among project stakeholders, due <strong>to</strong> a lackof commitment and perceived uncertainty.Fig. 1 also includes the situation with high flexibilityis both the product and the process. ‘‘Flow’’ has beenused as a description of this situation. It contains manyof the aspects related <strong>to</strong> the other two strategies withhigh flexibility in either the process or the product.2.3. ModularityFlexibility can be related <strong>to</strong> the degree of modularityin the projects. Modularity refers <strong>to</strong> the possibility <strong>to</strong> dividethe project in<strong>to</strong> more or less independent sub-units.According <strong>to</strong> Miller and Lessard [5], modularity can enableprojects <strong>to</strong> cope with uncertainty because individualcomponents do not have a critical role. Major ‘‘onepiece’’projects such as bridges and tunnels have a lowlevel of modularity, based on the ‘‘we do not build halfa bridge’’-approach. Projects that are assumed <strong>to</strong> havehigher levels of modularity include IT-system developmentand road improvement projects.2.4. Flexibility in different project phasesThis paper makes a distinction between three differentproject phases: front-end, planning and execution.The front-end phase covers the activities prior <strong>to</strong> the finaldecision <strong>to</strong> go ahead with the project. Even thoughplanning is a part of the front-end phase, most projectsalso have a planning phase for more detailed preparationafter the project has been decided upon. Projectsare implemented in an execution phase, which endswhen the project outputs are realised.Most authors agree on the value of flexibility in thefront-end phase of projects while flexibility is commonlyseen as undesirable in the execution phases of projects.Lundin and Söderholm [19] describe how a projectmoves from relative openness in the beginning of theproject, <strong>to</strong> relative closeness in the execution phase. Inthe execution phase, the predetermined action is supposed<strong>to</strong> be carried out according <strong>to</strong> the plans, in a‘‘planned isolation’’. The concept of project flexibilityin the execution phase disturbs this planned isolation.In a similar way, Mahmoud-Jouini et al. [20] characterisesproject management by the speed of three projectphases: preparation, freezing and implementation.Many authors on project management, includingMorris and Hough [4], warn against changes in projectsonce specifications have been established. Miller andLessard [5] point out the irreversibility of large engineeringprojects and the importance of bold commitmentfrom key stakeholders. They argue against flexibilityonce the front-end phase is over.2.5. Efficiency and effectivenessEfficiency is linked <strong>to</strong> the immediate outcome of aproject. It is a question of doing things right and producingproject outputs in terms of the agreed scope,quality, cost and time. It is an internal measure. Effectiveness,on the other hand, is linked <strong>to</strong> the longer-termeffects of the project, or <strong>to</strong> do the right things. Effectivenessis an external measure. Eikeland [11] relates effectiveness<strong>to</strong> how the results of a project contribute <strong>to</strong>value added for owners and users. According <strong>to</strong> Samset[21], effectiveness concerns the extent <strong>to</strong> which the projectÕstactical objective, or the goal, can be achieved.The literature review [22] found that flexibility is primarilyan approach <strong>to</strong> improve effectiveness of projectsrather than efficiency. Major drawbacks of flexibility arerelated <strong>to</strong> reductions in efficiency. Flexibility was seen asa threat <strong>to</strong> delivering the project on time and withinbudget. In order <strong>to</strong> maximise efficiency, projects needs<strong>to</strong> be clearly defined in the front-end phase and executedaccording <strong>to</strong> the plans. Adjustments or remaining decisionsshall be minimised. Flexibility promoters emphasisethe possibility for increased effectiveness. A projectwith sufficient flexibility <strong>to</strong> utilise opportunities <strong>to</strong> increasethe value for owners and users might in the endprove <strong>to</strong> be more effective, as discussed in [2] and quantifiedby the real options approach [8].2.6. Project stakeholdersKey stakeholders who are directly linked <strong>to</strong> most projectsare; project owners, users, project management andcontrac<strong>to</strong>rs. Olsson [22] analysed the expected opinionon project flexibility. That project owners and usersare likely <strong>to</strong> be more positive <strong>to</strong>wards changes aimedat increased effectiveness. Stakeholders those mainresponsibility lie on the cost side of the project, suchas project management and contrac<strong>to</strong>rs, are less likely<strong>to</strong> embrace changes. According <strong>to</strong> Kreiner [2], the projec<strong>to</strong>wner is made the guardian of relevance and there-
N.O.E. Olsson / International Journal of Project Management 24 (2006) 66–74 69by the projectÕs effectiveness. The project manager ismade the guardian of efficiency.2.7. Changes and extensionsChanges and extensions are a source of major disagreementsbetween different ac<strong>to</strong>rs in projects. PMI[23] defines the management of both changes and extensionsas scope change control.Many authors, including [1,4,24], have pointed <strong>to</strong>scope changes as a key driver <strong>to</strong> cost overruns of projects.From a project management and contrac<strong>to</strong>r perspective,scope changes are generally seen asundesirables, even though contrac<strong>to</strong>rs can see changesas a possibility <strong>to</strong> improve the profit from the projects[25]. Scope changes are key issues when discussing flexibility,but project flexibility as discussed in this paper isa wider concept than scope change management.A typical scope change is proposed because the usersor project owner wants <strong>to</strong> increase the effectiveness ofthe project. As shown by Ibbs et al. [26] using benefit<strong>to</strong>-costratio, the reduction in efficiency might be compensatedby a higher increase in effectiveness, dependingon the timing and type of change. Two sources of conflictsrelated <strong>to</strong> scope changes can be identified. Conflictsmay arise regarding: (a) the quantification of the increasein effectiveness and reduction in efficiency; (b)the responsibility for the reduction in efficiency.Based on a study of 448 projects, Dvir and Lechler[27] showed that changes in both plans and goals of projectstypically reduce both the efficiency and cus<strong>to</strong>mersatisfaction of engineering projects.Many textbooks on project management, including[3,28], include explanations and illustrations that illustratethat the scope change cost is typically low in thefront-end phase of projects, and getting higher and higheras time goes by. This increase in scope change cos<strong>to</strong>ver time is widely accepted as a rule of thumb, and isa major challenge <strong>to</strong> project flexibility. Once a projecthas been decided upon and the planning or executionhas begun, changes are likely <strong>to</strong> reduce the efficiencyof the project, as shown by Hanna et al. [30]. However,Poppendieck and Poppendieck [29] argue that the almostexponential increase in scope change cost over timein a project is not always applicable <strong>to</strong> IT-projects.Some types of changes are less damaging <strong>to</strong> efficiencythan others. An alternative approach <strong>to</strong> project flexibilityis <strong>to</strong> identify areas or types of changes that are lesschallenging <strong>to</strong> accommodate in projects than otherchanges. Thus, at least two different strategies can bechosen <strong>to</strong> manage scope changes: (a) <strong>to</strong> avoid them or(b) <strong>to</strong> reduce the negative impact from changes that docome. A change requires that something already hasbeen decided. One key purpose of the flexibility strategiesidentified in Fig. 1 is <strong>to</strong> achieve flexibility withoutcreating scope changes in the project. In this way, scopechanges might be avoided or reduced by the use of latelocking of projects and by not taking decisions until onereally have <strong>to</strong>. Scope changes may also be avoided bythe use of flexibility in the product.2.8. Contracting and incentivesIncentives for different project stakeholders arestrongly related <strong>to</strong> the contracting structure of a projectand other financial obligations. A common <strong>to</strong>ol forachieving flexibility in projects is the use of option basedcontracts, which enables a continuous locking of theprojects. Mahmoud-Jouini et al. [20] discusses timemanagement in projects. Their discussion also includesflexibility aspects. They point out that a key fac<strong>to</strong>r increating win–win situations between the stakeholdersin Engineering, Procurement and Construction (EPS)contracts lies in flexibility of contracts and the implicitrelations that are created by the contracts. Garel andMidler [31] studied contractual structures that enablefront-loading and coherent incentives for manufacturersand suppliers in the au<strong>to</strong>motive industry. Their analysisis based on a game theory approach, where dealing withflexibility can be a win–win or zero-sum game betweenthe stakeholders. In co-development of au<strong>to</strong>motiveparts, the supplier gets no additional payments for lateidentification of need for modifications in the designphase. The supplier therefore has strong incentives <strong>to</strong>provide engineering expertise <strong>to</strong> work closely with themanufacturer in order <strong>to</strong> understand the needs and theproduction process [31].The users are a group of stakeholders that often donot have direct contracts related <strong>to</strong> the projects. Theirincentives are therefore less connected <strong>to</strong> the direct cos<strong>to</strong>f the project, and more often connected <strong>to</strong> the qualityand usability of the final result.3. Empirical indicationsA study was carried out <strong>to</strong> investigate <strong>to</strong> what extentthe results from the theoretical review of project flexibilitycorresponds with observations from a number ofprojects. This section of the paper describes the datamaterial, discusses the applied methodology and presentsthe results from the study.3.1. Data collection and analysisA qualitative case study research approach has beenused in this study. In the terminology of Yin [32], theanalysis is a multi-case study. The study is based on ananalysis of 18 Norwegian projects. Information related<strong>to</strong> the projects has been obtained from two main sources:third party evaluation reports and personal experiencefrom consulting and applied research engagements. The
- Page 1 and 2:
ISBN 82-471-8121-5 (printed ver.)IS
- Page 3:
Preface and AcknowledgementsThe wor
- Page 7 and 8:
Table of ContentsPreface and Acknow
- Page 9 and 10:
Paper OverviewThe following papers
- Page 11 and 12:
AbstractTraditionally, projects ten
- Page 13 and 14:
alternative use. There are indicati
- Page 15 and 16:
1. Introduction1. IntroductionThis
- Page 17 and 18:
1. IntroductionFlexible projects ar
- Page 19 and 20:
1. IntroductionA literature review
- Page 21 and 22: 2. Study design2. Study designThe r
- Page 23 and 24: 2. Study designInformation Content
- Page 25 and 26: 3. Flexibility in different project
- Page 27 and 28: 3. Flexibility in different project
- Page 29 and 30: 3. Flexibility in different project
- Page 31 and 32: 4. Project stakeholders4. Project s
- Page 33 and 34: 4. Project stakeholdersmandatory qu
- Page 35 and 36: 4. Project stakeholdersBased on res
- Page 37 and 38: 5. Effectiveness and efficiency5. E
- Page 39 and 40: 5. Effectiveness and efficiencyconf
- Page 41 and 42: 5. Effectiveness and efficiencyDegr
- Page 43 and 44: 6. Project flexibility categorisati
- Page 45 and 46: 6. Project flexibility categorisati
- Page 47 and 48: 6. Project flexibility categorisati
- Page 49 and 50: 7. Conclusions7. ConclusionsThis th
- Page 51 and 52: 7. ConclusionsProject phasesFlexibi
- Page 53 and 54: 7. ConclusionsEnablersThis thesis r
- Page 55 and 56: 7. Conclusions16, Figure 17, and Fi
- Page 57 and 58: 7. Conclusions4. AbsorptionAbsorpti
- Page 59 and 60: 7. ConclusionsThere appears to be a
- Page 61 and 62: ReferencesAbbot, A. & Banerji, K. 2
- Page 63 and 64: Gareis, R. 2004. Maturity of the Pr
- Page 65 and 66: Miller, R. & Lessard, D. 2000. The
- Page 67 and 68: Part 2.
- Page 69 and 70: Paper 1.Olsson, N.O.E. 2006. Manage
- Page 71: N.O.E. Olsson / International Journ
- Page 75 and 76: N.O.E. Olsson / International Journ
- Page 77 and 78: N.O.E. Olsson / International Journ
- Page 79 and 80: Paper 2.Magnussen, O.M. & Olsson, N
- Page 81 and 82: 282 O.M. Magnussen, N.O.E. Olsson /
- Page 83 and 84: 284 O.M. Magnussen, N.O.E. Olsson /
- Page 85 and 86: 286 O.M. Magnussen, N.O.E. Olsson /
- Page 87 and 88: 288 O.M. Magnussen, N.O.E. Olsson /
- Page 89 and 90: Projects trapped in their freedom:
- Page 91 and 92: 1. IntroductionThe purpose of this
- Page 93 and 94: project phases: preparation, freezi
- Page 95 and 96: establish realistic cost and time f
- Page 97 and 98: 4. ResultsIn the following, the emp
- Page 99 and 100: lowered the quality but the volume
- Page 101 and 102: Percent ofproject onSize of remaini
- Page 103 and 104: flexibility is introduced by the us
- Page 105 and 106: 100 %First official estimateApprova
- Page 107 and 108: ReferencesAndersen, B., Fagerhaug,
- Page 109 and 110: Paper 4.Olsson, N.O.E. 2004. ‘Fle
- Page 111 and 112: The concept of project flexibilityF
- Page 113 and 114: 3. CONCLUSIONSWhat seems to be impl
- Page 115 and 116: Paper 5.Olsson, N.O.E. 2006. ‘Imp
- Page 117 and 118: 558 N. O. E. Olsson et al.ex-post s
- Page 119 and 120: 560 N. O. E. Olsson et al.Table 1.O
- Page 121 and 122: 562 N. O. E. Olsson et al.and actua
- Page 123 and 124:
564 N. O. E. Olsson et al.Table 3.
- Page 125 and 126:
566 N. O. E. Olsson et al.Table 7.S
- Page 127 and 128:
568 N. O. E. Olsson et al.with a wi
- Page 129 and 130:
Paper 6.Henriksen, B., Olsson, N. &
- Page 131 and 132:
In this paper we use the process an
- Page 133 and 134:
PROCESS ANALYSIS IN THE PLANNING OF
- Page 135 and 136:
final framework for expected patien
- Page 137 and 138:
User involvement also generated exp
- Page 139:
Paper 7.Olsson, N.O.E. & Samset, K.
- Page 155 and 156:
Project flexibility and front-end m
- Page 157 and 158:
uncertainty. External flexibility c
- Page 159 and 160:
5.2. Flexibility in decision proces
- Page 161 and 162:
Degree of redundancySlackPrecisionC