Available online at www.sciencedirect.com

International Journal of Project Management 28 (2010) 256–264

www.elsevier.com/locate/ijproman

A project contingency framework based on uncertaintyand its consequences

David Howell a,*, Charlotta Windahl b, Rainer Seidel a

a Department of Mechanical Engineering, The University of Auckland, 20 Symonds Street, Auckland 1010, New Zealandb Department of Management and International Business, The University of Auckland, New Zealand

Received 30 August 2008; received in revised form 6 June 2009; accepted 9 June 2009

Abstract

There is an increasing diversity both of project types and PM approaches, but decision tools and theory connecting the two are lim-ited. To address this shortcoming, this paper reviews literature on alternative PM approaches, in the context of project contingency the-ory. Firstly, the paper identifies five selection factors seen within this literature: uncertainty, complexity, urgency, team empowermentand criticality. Secondly, the paper adapts project contingency theory to encompass these factors. Thirdly, these factors are used todevelop a contingency framework based on project uncertainty and its consequences. Finally, the paper discusses the practical applica-tions of the framework, such as its use for project process selection, tuning of processes, and project risk assessment.� 2009 Elsevier Ltd and IPMA. All rights reserved.

Keywords: Managing projects; Processes; Procedures; Risk; Configuration

1. Introduction

The growing diversity of projects is being reflected in agrowing diversity of ways to manage them. The dominantapproach to project management remains the ‘‘plan-driven” model, as exemplified by the Bodies of Knowledge(BOKs) of the various PM professional associations (e.g.Project Management Institute, 2004). However alternativeor complementary approaches such as lean, agile, and softsystems methods have gained acceptance in some fields,and are beginning to spread beyond their areas of origin(e.g. Poppendieck and Poppendieck, 2003; Yeo, 1993).Even within the plan-driven model, increasingly diversemethods are being advocated.

Despite this increasing range of available managementchoices, project managers frequently fail to seriously con-sider their alternatives (Brown et al., 2000; Shenhar,2001). This may be partly because they do not consider thisto be within the scope of ‘‘project management”, (although

0263-7863/$36.00 � 2009 Elsevier Ltd and IPMA. All rights reserved.

doi:10.1016/j.ijproman.2009.06.002

* Corresponding author. Tel.: +64 9 414 9255.E-mail address: dhow010@ec.auckland.ac.nz (D. Howell).

it is clearly part of the wider concept of ‘‘management ofprojects” (Morris et al., 2006)). But the lack of decisionsupport tools also discourages such consideration.Although project categorisation systems are commonwithin organisations, these are generally narrowly tailoredand categorisation criteria often are not logically linkedwith objectives (Crawford et al., 2005). Hence there is aneed for enhanced methods for relating PM approachesto projects.

One path to such methods is via project contingencytheory (PCT). PCT argues that the best approach to man-aging a project depends on context: different conditionsrequire different project organisational characteristics,and the effectiveness of the project is related to how wellorganisation and conditions fit each other. PCT has devel-oped from general organisational contingency theory,building upon innovation (e.g. Shenhar and Dvir, 2007)and preceding works and organisational (e.g. van Donkand Molloy, 2008) perspectives of the project. Howeverthe theory remains relatively narrowly based, and doesnot yet allow for the full range of projects or PMapproaches.

D. Howell et al. / International Journal of Project Management 28 (2010) 256–264 257

The objective of this paper is to develop a generic con-tingency framework that will facilitate the choice of man-agement method for a specific project or project stage.To achieve this, we review the literature relating projectcharacteristics to PM approaches, and consider the resultsfrom the perspective of PCT. Our findings show that exist-ing theory largely considers contingency factors related toproject uncertainty. Our analysis leads to the conclusionthat factors related to the consequences of this uncertaintyare also relevant, and we extend PCT to allow for this. Onthe basis of this extension we present a two dimensionalproject contingency framework, and show how this mayassist in selecting and tailoring a PM approach.

The paper is structured as follows: Section 2 discussesthe theoretical background and reviews existing literature.In Section 3 we analyse the literature, discuss validity andrelevance of the contingency factors identified, and buildthese into a two dimensional framework. In Section 5 wedefine several PM ‘‘process models” (groups of similarmethods), and show how these fit to the framework. Sec-tion 4 suggests some practical applications. We concludeby discussing limitations and opportunities for furtherdevelopment.

2. Theoretical background

Classical organisational contingency theory proposesthat the effectiveness of an organisation is related to its‘‘fit” to its environment (Burns and Stalker, 1961; Law-rence and Lorsch, 1967; Perrow, 1967). An optimal fitmay require different organisational characteristics to suitdifferent external conditions. Those external conditionswhich impact the organisational characteristic under con-sideration are known as contingency factors.

Initial developments of contingency theory focussedupon organisational structure as the characteristic underconsideration, and change, particularly technologicalchange, as the contingency factor. It was hypothesised that‘‘organic” organisations would cope better with rapidchange than ‘‘mechanistic” ones, but that mechanisticorganisations would outperform in stable environments(Burns and Stalker, 1961).

Scholars, particularly in the innovation managementfield, have extended the theory to focus upon the organisa-tion’s goals rather than explicitly its environment as thecontingency factor, suggesting that optimal organisationfor radical innovation differs from that for incremental(e.g. Brown and Eisenhardt, 1997; Damanpour, 1996;Wheelwright and Clark, 1992).

More recently, other scholars have begun to apply con-tingency theory to project management, arguing that the‘‘one size fits all” approach is suboptimal, and that a pro-ject’s structure and management practices should be tai-lored to suit its context. The most notable advocates ofthis thesis have been Shenhar and Dvir, who have shownthe innovation theorists’ focus upon contingency factorsrelated to the goal or purpose to be valid in a project con-

text. They have further refined these factors, evolving acontingency framework using 4 contingency factors: Nov-elty, Technology, Complexity, and Pace (NTCP) (Shenharand Dvir, 2007). Although this framework is based on con-siderable empirical and theoretical work, it is limited inthat it is oriented around engineering based projects, andoffers little to projects – or PM approaches – far outsidethe engineering norm.

A contrasting approach based on organisational designperspective is taken by authors such as van Donk and Mol-loy (2008), who relate Mintzberg’s (1979) organisationalcontingency framework to project management. Theyfocus primarily upon a typology of project structures, pay-ing only passing attention to contingency factors.

Apart from the examples above, explicit application ofcontingency theory to project management remains rare.However the idea that not all projects are the same, andthat this may impact upon how they are best managed, isan increasingly common one. There is a significant andincreasing body of work relating to ‘‘different” approachesto projects of various types. Contingency theory providesan implicit basis for much of this work: provided that pro-jects can be differentiated in terms of contingency factors,contingency theory allows for the possibility that differentapproaches may provide better performance and providesa framework for investigating why.

One example of this is the call for greater attention tothe ‘‘soft” aspect of projects, and for use of tools such asthe Soft Systems Methodology (e.g. Winter and Check-land, 2003; Yeo, 1993). Authors espousing this approachoften cite project parameters which can be seen as contin-gency factors: these parameters are perhaps best summa-rised in Crawford and Pollack’s (2004) ‘‘softness”

framework.Another example is decision science based papers which

have investigated PM strategy payoffs under differing levelsof external variables: increasing the level of uncertainty isshown to favour emergent or learning-based approachesto PM (Pich et al., 2002).

A further example comes from the IT industry. Therecent rise in popularity of Agile Software Development(ASD) has led to discussion of the factors which determinewhen such an approach is appropriate. Description of ASDis beyond the scope of this paper (those interested mayrefer to (Boehm and Turner, 2004) or (Highsmith, 2002)),however it is sufficient to know that ASD is an exampleof an ‘‘emergent” approach to the organisation and man-agement of software development projects, or one in whichscope and methods ‘‘emerge” during the course of the pro-ject. Models for choosing between ASD and ‘‘conven-tional” methods have come from developers of variousASD methods (e.g. Beck, 2000; Cockburn, 2000), practitio-ners (e.g. Little, 2005), and academics (e.g. Boehm andTurner, 2003), although as yet no model has emerged asgenerally accepted.

A common thread in many of these IT industry modelsis a focus upon factors relating to the project’s relationship

258 D. Howell et al. / International Journal of Project Management 28 (2010) 256–264

with the parent organisation. This focus, which has not yetbeen seen in general or project contingency literature, is alogical extension of existing PCT. Projects can be seen as‘‘temporary organisations within organisations” (Shenhar,2001, p. 395). Existing project contingency work hasaddressed the ‘‘temporary” aspect of this view, but hasnot yet considered the ‘‘within” aspect. The parent organi-sation is frequently a dominant part of the project’s envi-ronment, and it is reasonable to hypothesise both thatdifferent projects will face different parent-imposed con-straints, and that that this might yield different optimalproject characteristics.

3. Contingency factors identified in prior work

3.1. Methodology

As a basis for the development of a project contingencyframework, we reviewed the literature and categorised con-tingency factors identified within it. The review began byidentifying an initial group of publications relating toapproaches to the management of high-novelty NPD pro-jects. This group was expanded by searching Scopus, Pro-quest, and IEEE Xplore for keywords related tocontingency theory, project management methodologies,and previously identified approaches, and then by citationtracing from relevant work.

We then filtered the database for publications whichlinked approaches to managing projects with differencesin aspects of the projects’ environments. These were filteredfurther by:

� Reducing any author’s train of thought or group ofauthors’ school of thought to the most developed ormost obviously contingency-linked publication (e.g.(Shenhar and Dvir, 2007) for work leading to the NTCPframework, (Cockburn, 2000) for work around CrystalASD methods, (Crawford and Pollack, 2004) for ‘‘soft”projects and associated methods).� Excluding non-refereed sources except where these were

best representative of arguments developed in refereedsources (e.g. Shenhar and Dvir, 2007) or accepted defin-itive sources for particular methods (e.g. Beck, 2000).� Excluding publications based on single project cases,

and those not providing supporting arguments for thefactors cited.� Excluding publications which added nothing in this area

to prior work.

Twenty-one publications remained (Ahituv and Neu-mann, 1984; Beck, 2000; Boehm and Turner, 2003; Cock-burn, 2000; Crawford and Pollack, 2004; Highsmith,2000; Howell and Ballard, 1997; Jordan et al., 2005; Lindv-all et al., 2002; Little, 2005; Liu and Yetton, 2007; Milling-ton and Stapleton, 1995; Pearson, 1990; Pich et al., 2002;Ratbe et al., 1999; Rice et al., 2008; Shenhar and Dvir,2007; Turner and Cochrane, 1993; van Donk and Molloy,

2008; Wadeson, 2005; Williams, 2005). These included thir-teen theoretical or conceptual works, five combining empir-ical and theoretical work, and three purely empiricallybased. Seventeen are academically based, with the remain-der from consultants or practitioners.

We then analysed these publications and identified envi-ronmental factors associated with a selection of a differentapproach to project management. The factors were tabu-lated and grouped into those relating to similar themes.Five themes were identified, as discussed below.

3.2. Themes from the literature

The first theme identified is uncertainty. We use thisterm in its widest form, as ‘‘lack of certainty”. It thereforeencompasses not only probabilistic or undefined outcomesbut also ambiguity and lack of clarity over situationalparameters. Factors associated with uncertainty are identi-fied by over three quarters of publications considered; it iseasily the dominant theme identified in the literature.Uncertainty is seen referred to either as a generality(Howell and Ballard, 1997; Liu and Yetton, 2007; Pichet al., 2002; Ratbe et al., 1999; Wadeson, 2005; Williams,2005), or associated with goals or methods (Crawfordand Pollack, 2004; Millington and Stapleton, 1995; Pear-son, 1990; Turner and Cochrane, 1993), market or technol-ogy (Ahituv and Neumann, 1984; Jordan et al., 2005; Riceet al., 2008; Shenhar and Dvir, 2007), change (Boehm andTurner, 2003; Little, 2005), or external influences (Craw-ford and Pollack, 2004; Little, 2005; Ratbe et al., 1999;Rice et al., 2008). It is noticeable that all of the factorsassociated with the ‘‘soft” side of project management aremeasures of some form of uncertainty.

The next most common theme is complexity. About halfof the publications consider project complexity, taken hereas the degree of differentiation and interdependence of pro-ject elements. As well as use of the general term (Howelland Ballard, 1997; Jordan et al., 2005; Ratbe et al., 1999;Shenhar and Dvir, 2007; Williams, 2005), authors use com-plexity in terms of organisations (Ahituv and Neumann,1984; Little, 2005), environment (van Donk and Molloy,2008), scope (Ahituv and Neumann, 1984), sophisticationand diversity (van Donk and Molloy, 2008), and the sizeof either the project itself or the team (Beck, 2000; Boehmand Turner, 2003; Cockburn, 2000; Jordan et al., 2005; Lit-tle, 2005; van Donk and Molloy, 2008).

The third theme we observe is that of team empower-

ment. We use this term in a broader sense than the normalorganisational usage, to designate not only the discretion-ary power formally assigned to the team, but also exter-nally imposed factors which may limit their ability to usethis power effectively. These include factors such as corpo-rate and national culture, team composition, and commu-nication capability. Eight of the publications,predominantly those from the IT field, discuss factors asso-ciated with team empowerment. These factors includeorganisational culture and power (Beck, 2000; Boehm

D. Howell et al. / International Journal of Project Management 28 (2010) 256–264 259

and Turner, 2003; Millington and Stapleton, 1995; vanDonk and Molloy, 2008), team size and dispersal (Ahituvand Neumann, 1984; Beck, 2000; Boehm and Turner,2003; Cockburn, 2000; Lindvall et al., 2002; Little, 2005),and skill and experience (Ahituv and Neumann, 1984;Boehm and Turner, 2003; Lindvall et al., 2002; Millingtonand Stapleton, 1995). Some of these factors (e.g. team size)are also associated with complexity; however we argue thattheir dominant effect is in modifying the team’s ability toprocess and act effectively upon information received.

The fourth theme is criticality. That is, how much is ‘‘atstake” in the project; the effects upon organisation or indi-viduals of project failures. Among the papers analysedhere, only IT related sources cite criticality as a contin-gency factor. However it is cited by the majority (five) ofthese sources (Ahituv and Neumann, 1984; Boehm andTurner, 2003; Cockburn, 2000; Lindvall et al., 2002; Little,2005).

The final theme is urgency; that is, the extent to whichtime constraints are a factor in project activities and deci-sion-making. Only five publications (Ahituv and Neu-mann, 1984; Highsmith, 2000; Pearson, 1990; Shenharand Dvir, 2007; Williams, 2005) cite urgency, defining itin terms of either absolute speed or time pressure.

These five themes of uncertainty, complexity, teamempowerment, criticality and urgency cover almost allthe factors discussed in the selected publications. Only afew factors, such as technical and regulatory constraints(Beck, 2000; van Donk and Molloy, 2008) and priorities(Cockburn, 2000) do not readily fit within them.

3.3. Relating the identified themes to contingency theory

Three of our themes (uncertainty, complexity andurgency) are consistent with existing developments of con-tingency theory. Uncertainty, the strongest theme seen, ispossibly the dominant contingency factor in organisationalcontingency theory and innovation literature, and is alsocommon in prior project contingency work. Complexityis seen as a contingency factor in prior project contingencywork, and through its association with the project’s goals isconsistent with the approach of wider organisational con-tingency theory. Urgency is also seen as a contingency fac-tor in existing project contingency literature (c.f. ‘‘Pace” inShenhar and Dvir’s NTCP framework), although not ingeneral organisational contingency theory. Its validity asa contingency factor rests on the relationship between theproject and the parent organisation(s): for organisationsin general, urgency may be seen as a behavioural ratherthan external factor. However in the case of projects it isoften largely externally imposed, either through inheritedorganisational culture, explicit imposition of deadlines, orpressure by higher-ranking organisation members outsidethe project.

The other two themes (team empowerment and critical-ity) have not previously been discussed within contingencytheory. For them to be considered as contingency factors,

they must (a) be variables which are primarily environmen-tal (i.e. external to the project), and (b) potentially requiredifferent project characteristics for optimal performance.The latter requirement is demonstrated by the literaturereview process itself: the themes were identified because asignificant number of authors associate them with changesto project characteristics. However the former requireselaboration.

The use of team empowerment as a contingency factor isnot a complete departure from existing theory: powerissues have been previously cited (van Donk and Molloy,2008). However it is a significant extension, and in a gen-eral organisational sense team empowerment could be con-sidered an internal variable. Projects’ ‘‘temporaryorganisation within organisation” status renders them aspecial case though. Factors such as authority levels, teamsize, membership, and geographic distribution are fre-quently dictated by the parent organisation, and thebroader corporate culture is inherited from it. Particularlyfor smaller or shorter projects, changing such parametersmay be infeasible, and in any case the ability to make suchchanges is itself an empowerment issue, as it may or maynot be permitted by the parent.

Our final theme, criticality, has not been addressed pre-viously in contingency literature. This may be in partbecause of its limited visibility in many fields, as discussedbelow. However like complexity, criticality is in large partdictated by the project’s goals: project design can modifythe risk of the worst case happening, but what that worstcase is relates to what the project is trying to achieve.Use of criticality as a contingency factor is thus consistentwith the general thrust of existing theory.

3.4. General relevance of the identified themes

Combining contingency factors from several disciplinesinto a single framework raises the question of the transfer-ability of these factors. Most of the themes identified aboveare cited in one form or another by authors from a range offields. The incidence varies across fields, but given the sam-ple size and the different priorities of different fields, that isnot surprising.

The exception is criticality. Criticality is cited only by ITrelated sources, but it is cited by almost all of them. Thisraises the questions of why criticality is noticeable as a con-tingency factor in IT and not elsewhere, and whetherdespite this it has general relevance.

One possible reason is that the IT industry covers a verybroad range of criticality. Clearly there is a vast differencein criticality between a project enabling web access to gov-ernment statistics and one developing an air traffic controlsystem. In other industries, the range tends to be narrower.For example in construction, projects large enough to beinteresting to project management researchers tend to behighly critical. They frequently involve sums of moneylarge enough to bankrupt the players, and usually havethe potential to cause multiple deaths in the event of a

Fig. 1. Process models and the UC Framework.

260 D. Howell et al. / International Journal of Project Management 28 (2010) 256–264

severe technical failure. On the other hand organisationalchange projects tend to have relatively low criticality (interms of directly measurable outcomes at least); theymainly affect organisational efficiency or effectiveness.

In addition to this, in many fields criticality, particularlyin financial terms, tends to be proportional to project size.This is less the case for software. In IT, small and simpleprojects can have considerable monetary or safety conse-quences, as for example in financial trading or machinecontrol applications. It is therefore likely that to research-ers working within single industries or fields outside IT, theeffects of differences in criticality are less apparent. How-ever looking across a range of fields, criticality is undoubt-edly highly variable. This can be seen to have an effect onhow projects are organised and managed. The level ofinformality acceptable in an internal project to implementa learning initiative, for example, would leave a paper trailinadequate to defend the organisation against the potentiallegal outcomes of a disastrously failed infrastructure pro-ject. Criticality is therefore not a factor which can be dis-missed in the search for a generic contingency framework.

3.5. Building a framework

To develop a useful framework it is desirable to mini-mise the number of dimensions. In the following section,we reduce the above themes to two, which we label uncer-tainty (U) and consequences (C). These can be representedby the questions ‘‘What is the likelihood that something

unexpected will happen in the project?” and ‘‘How much willit matter if it does?” The U dimension includes not onlyuncertainty as identified in the literature above, but alsocomplexity and urgency. The C dimension includes critical-ity and team empowerment.

Complexity and uncertainty are often regarded as inde-pendent (e.g. Ratbe et al., 1999; Shenhar and Dvir, 2007).However authors such as Pich et al. (2002) and Williams(1999) consider complexity and uncertainty to be aspectsof the same variable. As Williams (2005) points out, theproject management issues surrounding complexity centreupon ability to comprehend what is going on, and thereforepredict the relationship between inputs and outputs. Lackof predictability is synonymous with uncertainty, and thuscomplexity becomes a factor in uncertainty.

Urgency drives uncertainty in a similar fashion to com-plexity, by limiting the resource (in this case time) availablefor comprehension. Decisions are made on more limitedinformation. Managers under time pressure also tend totake more active, and often more short-sighted, measuresto ‘‘control” the situation (Lyneis and Ford, 2007; Perlowet al., 2002; Williams, 2005). These effects again increasethe probability of unexpected project behaviour.

Unlike complexity and urgency, criticality is indepen-dent of uncertainty. Uncertainty can be thought of as theprobability of unexpected events occurring. At the extremeof uncertainty (chaos) nothing can be predicted: the prob-ability of unexpected events occurring is 100%. Criticality,

on the other hand, measures the effect, or ‘‘consequences”,of these unexpected events – what can be lost if somethingunforeseen and unmanageable happens. Criticality is thusan aspect of the C dimension.

The final identified theme, team empowerment, alsoaffects C. The consequences of unexpected events dependheavily on the extent to which they are manageable. Teamsize, dispersal, and organisational boundaries all affect theteam’s ability to communicate, and communication, skill,experience, and authority dictate a team’s ability to quicklycomprehend and respond to the unexpected, improving thechances that an unexpected event will be dealt with withouthaving a major impact on the project.

The U and C dimensions are orthogonal: the likelihoodof something happening is not affected by the magnitude ofits effects, or vice versa. The dimensions can thus be plottedas a Cartesian graph. We refer to this graph as the UCFramework. Plotting a project’s instantaneous positionon this graph gives not only an indication of the mostappropriate management approach (as will be discussedbelow), but a measure of overall risk.

4. Fitting process models to the framework

In the information systems view of business processmodelling, a process model describes ‘‘the common proper-ties of a class of processes having the same nature” (Rol-land, 1998, p. 5). Project management methodologies(‘‘bodies of methods” (Simpson and Weiner, 1989)) havingsimilar characteristics can be grouped into process models.

As described in Section 5.1 below, the UC Frameworkcan be used to identify which process models are appropri-ate for managing a particular project, or stage of a project.In this section we describe three examples of project man-agement process models, and show how they fit into theUC Framework, as shown in Fig. 1. We term these models‘‘plan-driven”, ‘‘problem structuring”, and ‘‘emergent”.

D. Howell et al. / International Journal of Project Management 28 (2010) 256–264 261

While other models exist, many commonly used projectmanagement methods fit within one of these examples.

The first process model we consider is the plan-drivenmodel. We define this model as the group of methodologieswhich broadly consist of:

� Identifying project goals and the necessary steps toachieve them.� Organising the steps into an optimal sequence given

resource and other constraints to form a project plan.� Following the plan, with the objective of management

being to administer the activities, to deal with deviationsfrom the plan, and where deviations cannot be dealtwith, to manage revision of the plan.

This process model includes methodologies advocatedby, among others, PMI (2004), IPMA (Caupin et al.,2006), the US Department of Defence (1994, 2003), andthe UK’s Office of Government Commerce (2005).

In the idealised case, the effectiveness of the plan-drivenmodel is independent of C. As the objective of planning isto anticipate and avoid surprises, their Consequences areirrelevant. However, the effectiveness of the plan-drivenprocess model will vary along the U axis, as shown inFig. 1. The plan is inevitably based upon assumptionsabout the goal, methods, required effort and resource con-straints among other things. As uncertainty increases, theseassumptions will be less valid. This can be compensated forto some extent by increased planning effort, however thereare cost and practicality limitations to this, and in any casenot all events can be anticipated – eventually the‘‘unknown unknowns” (Pich et al., 2002) become signifi-cant factors. Increasing U thus results in increasing devia-tions from plan, and increasing incidence of replanning,improvisation and ad-hoc responses to surprises, with con-sequent increased probability of further surprises (Lyneisand Ford, 2007; Taylor and Ford, 2006; Williams, 2005).

Second, consider the problem structuring model. Wedefine this model as the group of methodologies which:

� Presume that the dominant issue to be dealt with in theproject is the understanding of its objectives andenvironment.� Attempt to elicit this information by modelling of cause-

effect relationships.

The model includes, among others, the various method-ologies described by Rosenhead (1989) such as hypergameor metagame analysis and the Soft Systems Method.

The effectiveness of this process model is again indepen-dent of the C axis. Absent an adequate definition of theproblem, its consequences remain undefined. But effective-ness again varies along the U axis. As noted above, the rel-ative importance of problem definition compared withimplementation changes with changing uncertainty. Atlow uncertainty levels, where the situation is relativelyclear, the process of understanding the problematic

situation becomes a trivial one. In this situation, problemstructuring methods become irrelevant. The problem struc-turing process model is thus also uncertainty limited, butthe limit is at the lower bound, as shown in Fig. 1.

The third model, the emergent model, we define as thegroup of methodologies which involve:

� A presumption that the project goals will be ill-definedat the initial stages.� A highly iterative process involving partial implementa-

tion of the goals, followed by redefinition of those goalsbased on feedback from this implementation.

This process model includes the Learning Plan approach(Rice et al., 2008), ASD methodologies such as XP andScrum, and a range of less clearly defined approaches suchas those in the product development field described byEisenhardt and Tabrizi (1995).

In the ideal case, the emergent model’s effectiveness isindependent of U. The approach assumes high uncertainty;if in practice it is lower, this has no effect on effectiveness.However the model’s effectiveness is limited in the Cdimension. Lack of a robust overall project plan meansthat any event which the team is unable to handle mayrun away to disaster, and that it will not necessarily beknown whether the event has been handled satisfactorilyuntil too late. Further, the model is not demonstrably con-vergent – there is no guarantee that the process will con-verge to a solution. This is unacceptable in situations ofhigh criticality. Finally, as the model relies on the team’sability to react to events, it is less effective where the teamis less empowered to do so. These factors mean that theprocess model is restricted to situations where the team’sability to handle unexpected events is high (meaning smalland expert teams), and ‘‘failures” cannot be overly serious:the model is consequence limited.

Fig. 1 shows clearly the respective ‘‘comfort zones” ofthe process models discussed. Although the limiting valuesshown are arbitrary, and a more realistic presentationwould show effectiveness tapering off rather than endingsuddenly, general areas of overlap and lack of coveragecan be seen.

Fig. 1 shows a gap in the area of medium U and high C

in which no process model is ideal. Although projects fall-ing in this area can be successful, the high incidence of fail-ure in large, complex capital projects, particularly in the ITand construction fields (Eden et al., 2005; The StandishGroup, 2003), suggests that this combination is not easilymanageable using existing process models.

Efforts have been made to close this gap. Variations onthe plan-driven process model such as the Last Plannermethod (Ballard, 1994) and milestone-based or rollingwave planning aim to increase its ability to cope withuncertainty, while revisions and refinements to some emer-gent methods are improving their ability to cope with C

increasing factors such as large or distributed teams (e.g.Bowers et al., 2002; Elshamy and Elssamadisy, 2007; Suth-

262 D. Howell et al. / International Journal of Project Management 28 (2010) 256–264

erland et al., 2007). Similarly, efforts have been made toimprove merging of or transition between process modelsin areas of overlap (e.g. Keenan and Bustard, 2006; Lycettet al., 2003; Yeo, 1993). For projects which fall into the gaparea on the framework, some of these techniques warrantconsideration.

5. Managerial implications of the framework

There are several practical applications for the frame-work. These relate to three areas: project process selection,tuning of processes, and project risk assessment.

5.1. Process selection

The framework can be used to help select an appropriateprocess model for the project (or stage of the project).

Much of the literature from which the axes are derivedfocuses upon selection of an appropriate process modelfor managing particular projects. Analysis of this litera-ture, and the underlying strengths and limitations of themodels advocated, in the light of the framework hasallowed ‘‘comfort zones” for particular process models tobe plotted, as discussed in Section 4 above. Roughly posi-tioning a project on the framework makes it immediatelyobvious which models are potentially well suited to theproject. For example project A in Fig. 2 is an obvious con-tender for a plan-driven approach, whereas project Bwould suit either plan-driven or emergent approaches.Although project and company specific issues may ulti-mately dominate in the selection of a model, use of theframework in the early stages can stimulate the consciousconsideration of alternatives.

There are areas of the framework where more than onemodel is appropriate. In areas of overlap between models,the issue for process model selection is not effectiveness, butefficiency and practicality. For example for project B,

Fig. 2. Management uses of the UC Framework.

which has both U and C relatively low, both emergentand plan-driven process models may be effective. However,the cost drivers of each are different. Plan-driven methodsimpose significant overhead costs in documentation andcontrol, although these can be minimised by ‘‘lightweight”implementations (see for example (Office of GovernmentCommerce, 2002)). On the other hand, emergentapproaches have a lower ideal efficiency than plan-drivenones (Pich et al., 2002), imposing risks of wasted workand suboptimal sequencing. Further, emergent approachesmay also carry learning costs associated with customisingthe process model, as outside the IT industry, emergentapproaches are less well defined and understood thanplan-driven ones. Which cost dominates will depend onthe particular circumstances of the project in question.

5.2. Project tuning

Once a process model has been selected, the frameworkcan be used to identify ways to customise it to fit the pro-ject. Variations of particular process models are more orless suited to greater U or to greater C.

For example if a project which is to be managed using aplan-driven model is identified as having particularly highC, it may be desirable to discourage behaviour typical ofemergent models, such as dynamic specifications, sinceemergent models are typically less effective as C rises (asdiscussed in Section 4). A ‘‘heavyweight”, or highly formal,implementation of the plan-driven model would beappropriate.

Another process selection application involves trackingprojects over time. Over the course of a project, both U

and C will change. Typically, this change is towards lowerU and higher C as information is acquired and commit-ments made through the project. By tracking or predictingthe movement of a project on the UC Framework, anyneed to adjust the process model – or even to switch pro-cess models entirely - can be identified. For example in pro-ject C in Fig. 2, it may be appropriate to start in anemergent mode (point C1) but by the latter stages of theproject (C3–C4) a plan-driven approach is probably moreeffective. This tracking may also allow possible problemswith future process model selection to be identified. Forexample, if the trend is generally towards lower U andhigher C, a project D which starts with high uncertaintyand consequences may progress acceptably while in a prob-lem structuring mode (D1–D3). However, if it becomesnecessary to leave this mode (D4), the project will possiblybe difficult to manage, since the likely exit point will be intoan area where no effective process model is available.

5.3. Risk management

The UC Framework can be used for the assessment ofoverall project risk. Risk in projects is largely related tothe unexpected: that which is expected can be plannedfor. Further, it is commonly understood that risk is the

D. Howell et al. / International Journal of Project Management 28 (2010) 256–264 263

product of probability and effect. As the framework’s axesare effectively the probability and effect of the unexpected,constant risk curves (R = U � C) can be plotted on theframework, as seen in Fig. 2.

Plotting projects’ position on the framework and com-paring against constant risk lines gives a simple visual indi-cator of the comparative risk of projects. For exampleproject C can be seen to reduce slightly in risk throughits duration, but to be riskier than project A throughout.This visualisation facilitates risk/benefit assessment andother inter-project tradeoffs, and the planning of appropri-ate levels of management attention. For projects of similarnature within a single business, a coarse assessment such asa 5 � 5 matrix is sufficient for this purpose. This avoids theneed for a precise and discipline-independent method ofquantifying the axes. Given such a method, however, enter-prise-wide or even cross-industry comparisons would alsobe possible.

6. Conclusions

In this paper we have reviewed a body of work whichargues that not all projects are the same, and therefore theyshould not all be structured and managed the same way.We find that while explicitly contingency-linked literaturelargely cites uncertainty related issues as the key contin-gency factor, the remaining work, in particular that fromthe IT field, also addresses external limitations on the pro-ject team’s ability to process information and act effectivelyupon it. IT related work also frequently considers the crit-icality of the project as a factor in deciding how it shouldbe structured and managed.

In general organisational contingency terms these couldbe seen as internal rather than external factors. Howeveralthough internal to the parent organisation, they are oftenexternal to the project, and therefore can be considered asvalid project contingency factors. The factors are related tothe effects rather than the probability of the unexpected: tothe consequences of uncertainty rather than to uncertaintyitself. We have therefore combined them with directlyuncertainty related factors to form a two dimensionalframework, the UC framework.

The contribution of this paper has been the extension ofproject contingency theory to allow for these factors, andthe development of a framework which relates them toPM approaches. This framework is limited in that it ispurely conceptual, being based upon analysis of prior liter-ature. Further, the literature base itself is limited, ‘‘different”approaches to PM being something of a minority interest.Both theory and framework are also open to debate aboutthe externality of the contingency factors developed, andtheir orthogonal placement: in common with most socialscience research, little is black and white, and variablescan at best be assessed as ‘‘primarily” this or that.

The best test of any model is whether it is useful. Todemonstrate this in the case of the UC framework, the nextstep is the development of metrics for the contingency fac-

tors cited: most of the management applications citeddepend upon comparison of several items (multiple pro-jects, one project across time, or project vs model), andfor this a repeatable scale for the axes is required. Casestudies of practical use are also required, and will likelylead to further development of the framework. Work onboth of these is in progress.

The paper has also highlighted an opportunity for fur-ther expansion of project contingency theory. We havetouched upon how the relationship between the parentorganisation and the project impacts PM approach, andshown that this can be considered in terms of contingencyfactors. However this is an area of considerable complexityand warrants further exploration.

Finally, we bring to the attention of the general PMresearch community the extent to which developments inthe IT community parallel PM trains of thought re uncer-tainty and emergence. ASD methods appear to be both bet-ter defined and more broadly practiced than any emergentapproach documented in the more general PM literature,and there are many similarities in the underlying theory.However there has been very little crossover. There is scopeboth for integration of these theoretical strands and forinvestigation of the applicability of ASD to the moreuncertain end of PM in general.

References

Ahituv, N., Neumann, S., 1984. A flexible approach to information systemdevelopment. MIS Quart. 8 (2), 69–78.

Ballard, G., 1994. The last planner. In: Northern California ConstructionInstitute Spring Conference, Monterey, 1994.

Beck, K., 2000. Extreme Programming Explained: Embrace Change.Addison-Wesley, Reading, MA.

Boehm, B., Turner, R., 2003. Using risk to balance agile and plan-drivenmethods. IEEE Comput. 36 (6), 57–66.

Boehm, B.W., Turner, R., 2004. Balancing Agility and Discipline: AGuide for the Perplexed. Addison-Wesley, Boston.

Bowers, J., May, J., Melander, E., Baarman, M., Ayoob, A., 2002.Tailoring XP for large system mission critical software development,in: Goos, G., Hartmanis, J., van Leeuwin, J. (Eds.), Proceedings of theExtreme Programming and Agile Methods, Chicago, pp. 269–301.

Brown, S.L., Eisenhardt, K.M., 1997. The art of continuous change:linking complexity theory and time-paced evolution in relentlesslyshifting organizations. Admin. Sci. Quart. 42 (1), 1–34.

Brown, W.J., McCormick, H.W., Thomas, S.W., 2000. AntiPatterns inProject Management. John Wiley, New York.

Burns, T., Stalker, G., 1961. The Management of Innovation. Tavistock,London.

Caupin G., Knoepfel, H., Koch, G., Pannenbacker, K., Perez-Polo F.,Seabury C., 2006. ICB–IPMA Competence Baseline, Version 3.0.International Project Management Association.

Cockburn, A., 2000. Selecting a project’s methodology. IEEE Software 17(4), 64–71.

Crawford, L., Hobbs, J.B., Turner, J.R., 2005. Project CategorizationSystems: Aligning Capability with Strategy for Better Results. ProjectManagement Institute, Newtown Square, PA.

Crawford, L., Pollack, J., 2004. Hard and soft projects: a framework foranalysis. Int. J. Project Manage. 22 (8), 645–653.

Damanpour, F., 1996. Organizational complexity and innovation: devel-oping and testing multiple contingency models. Manage. Sci. 42 (5),693–716.

264 D. Howell et al. / International Journal of Project Management 28 (2010) 256–264

Eden, C., Ackermann, F., Williams, T., 2005. The amoebic growth ofproject costs. Project Manage. J. 36 (2), 15.

Eisenhardt, K.M., Tabrizi, B.N., 1995. Accelerating adaptive processes:product innovation in the global computer industry. Admin. Sci.Quart. 40 (1), 84.

Elshamy, A., Elssamadisy, A., 2007. Applying agile to large projects: newagile software development practices for large projects. In: Goos, G.,Hartmanis, J., Van Leeuwin, J. (Eds.), Proceedings of the AgileProcesses in Software Engineering and Extreme Programming, Como,pp. 46–53.

Highsmith, J.A., 2000. Adaptive Software Development: A CollaborativeApproach to Managing Complex Systems. Dorset House, New York.

Highsmith, J.A., 2002. Agile Software Development Ecosystems. Addi-son-Wesley, Boston.

Howell, G.A., Ballard, G., 1997. Lean production theory: moving beyond‘‘Can-Do”. In: Alarcon, L. (Ed.), Lean Construction. AA Balkema,Rotterdam, pp. 17–23.

Jordan, G.B., Hage, J., Mote, J., Hepler, B., 2005. Investigating differencesamong research projects and implications for managers. R&DManage. 35 (5), 501–512.

Keenan, F., Bustard, D.W., 2006. Aligning computing systems with theirenvironment: an agile perspective. In: Bustard, D.W. (Ed.), Proceed-ings of the 13th Annual IEEE International Symposium and Work-shop on Engineering of Computer Based Systems, Potsdam, pp. 9–22.

Lawrence, P.R., Lorsch, J.W., 1967. Organization and environment;managing differentiation and integration. Graduate School of BusinessAdministration. Harvard University, Boston.

Lindvall, M., Basili, V., Boehm, B., Costa, P., Dangle, K., Shull, F.,Tesoriero, R., Williams, L., Zelkowitz, M., 2002. Empirical findings inagile methods, extreme programming and agile methods. XP/AgileUniverse 2002, 81–92.

Little, T., 2005. Context-adaptive agility: managing complexity anduncertainty. IEEE Software 22 (3), 28–35.

Liu, L., Yetton, P., 2007. The contingent effects on project performance ofconducting project reviews and deploying project management offices.IEEE Trans. Eng. Manage. 54 (4), 789–799.

Lycett, M., Macredie, R., Patel, C., Paul, R., 2003. Migrating agilemethods to standardized development practice. IEEE Comput. 36 (6),79–85.

Lyneis, J.M., Ford, D.N., 2007. System dynamics applied to projectmanagement: a survey, assessment, and directions for future research.Syst. Dyn. Rev. 23 (2–3), 157–189.

Millington, D., Stapleton, J., 1995. Developing a RAD standard. IEEESoftware 12 (5), 54–55.

Mintzberg, H., 1979. The Structuring of Organizations: A Synthesis of theResearch. Prentice-Hall, Englewood Cliffs, NJ.

Morris, P.W.G., Crawford, L., Hodgson, D., Shepherd, M.M., Thomas,J., 2006. Exploring the role of formal bodies of knowledge in defining aprofession – The case of project management. Int. J. Project Manage.24 (8), 710–721.

Office of Government Commerce, 2002. Tailoring PRINCE2, TheStationary Office, London.

Office of Government Commerce, 2005. Managing Successful Projectswith PRINCE2, The Stationary Office, London.

Pearson, A.W., 1990. Innovation strategy. Technovation 10 (3), 185–192.Perlow, L.A., Okhuysen, G.A., Repenning, N.P., 2002. The speed trap:

exploring the relationship between decision making and temporalcontext. Acad. Manage. J. 45 (5), 931–955.

Perrow, C., 1967. A framework for the comparative analysis of organi-zations. Am. Soc. Rev. 23 (2), 15.

Pich, M.T., Loch, C.H., De Meyer, A., 2002. On uncertainty, ambiguity,and complexity in project management. Manage. Sci. 48 (8), 1008–1023.

Poppendieck, M., Poppendieck, T., 2003. Lean Software Development:An Agile Toolkit. Addison-Wesley, Boston.

Project Management Institute, 2004. A Guide to the Project ManagementBody of Knowledge: PMBOK Guide, third ed. Project ManagementInstitute, Newtown Square, PA.

Ratbe, D., King, W.R., Kim, Y.-G., 1999. The fit between projectcharacteristics and application development methodologies: a contin-gency approach. J. Comput. Info. Syst. 40 (2), 26.

Rice, M.P., Colarelli O’Connor, G., Pierantozzi, R., 2008. Implementing alearning plan to counter project uncertainty. MIT Sloan Manage Rev.49 (2), 54–62.

Rolland, C., 1998. A Comprehensive View of Process Engineering.Advanced Information Systems Engineering, Berlin. pp. 1–28.

Rosenhead, J., 1989. Rational Analysis for a Problematic World:Problems Structuring Methods for Complexity, Uncertainty, andConflict. Wiley, Chichester.

Shenhar, A., 2001. One size does not fit all projects: exploring classicalcontingency domains. Manage Sci. 47 (3), 394–414.

Shenhar, A., Dvir, D., 2007. Reinventing Project Management: TheDiamond Approach to Successful Growth and Innovation. HarvardBusiness School Press, Boston.

Simpson, J., Weiner, E., 1989. The Oxford English Dictionary, second ed.Oxford University Press, Oxford.

Sutherland, J., Viktorov, A., Blount, J., Nikolai Puntikov, A., 2007.Distributed scrum: agile project management with outsourced devel-opment teams. In: Viktorov, A. (Ed.), Proceedings of the HICSS 2007.40th Annual International Conference on System Sciences, Hawaii, pp.274a.

Taylor, T., Ford, D.N., 2006. Tipping point failure and robustness insingle development projects. Syst. Dyn. Rev. 22 (1), 51–71.

The Standish Group, 2003. Chaos Chronicles Version 3.0. The StandishGroup, West Yarmouth, MA, 2003.

Turner, J.R., Cochrane, R.A., 1993. Goals-and-methods matrix: copingwith projects with ill defined goals and/or methods of achieving them.Int. J. Project Manage. 11 (2), 93–102.

US Department of Defence, 1994. MIL-STD-498: Software Developmentand Documentation.

US Department of Defence, 2003. US DoD Extension to PMBoK Guide.Defence Acquisition University Press, Fort Belvoir, VA.

van Donk, D.P., Molloy, E., 2008. From organising as projects toprojects as organizations. Int. J. Project Manage. 26 (2), 129–137.

Wadeson, N., 2005. Projects as search processes. Int. J. Project Manage.23 (6), 421–427.

Wheelwright, S.C., Clark, K.B., 1992. Revolutionizing product develop-ment: quantum leaps in speed, efficiency, and quality. MaxwellMacmillan International, New York.

Williams, T., 1999. The need for new paradigms for complex projects. Int.J. Project Manage. 17 (5), 269–273.

Williams, T., 2005. Assessing and moving on from the dominant projectmanagement discourse in the light of project overruns. IEEE Trans.Eng. Manage. 52 (4), 497–508.

Winter, M., Checkland, P., 2003. Soft systems: a fresh perspectivefor project management. Proc. ICE: Civil Eng. 156 (4), 187–192.

Yeo, K.T., 1993. Systems thinking and project management – time toreunite. Int. J. Project Manage. 11 (2), 111–117.