Full Terms & Conditions of access and use can be found athttp://www.tandfonline.com/action/journalInformation?journalCode=tepo20

Download by: [94.255.148.236] Date: 03 October 2015, At: 01:22

Engineering Project Organization Journal

ISSN: 2157-3727 (Print) 2157-3735 (Online) Journal homepage: http://www.tandfonline.com/loi/tepo20

Exploring the front-end of project management

Andrew Edkins , Joana Geraldi , Peter Morris & Alan Smith

To cite this article: Andrew Edkins , Joana Geraldi , Peter Morris & Alan Smith (2013) Exploringthe front-end of project management, Engineering Project Organization Journal, 3:2, 71-85,DOI: 10.1080/21573727.2013.775942

To link to this article: http://dx.doi.org/10.1080/21573727.2013.775942

2013 The Author(s). Published by Taylor &Francis.

Published online: 03 Apr 2013.

Submit your article to this journal

Article views: 697

View related articles

Citing articles: 1 View citing articles

Exploring the front-end of project management

ANDREW EDKINS1, JOANA GERALDI1, PETER MORRIS1 and ALAN SMITH2

1Bartlett School of Construction & Project Management, UCL, 1-19 Torrington Place site, Gower Street, LondonWC1E 6BT, UK2Space and Climatic Physics, UCL, Gower Street, London WC1E 6BT, UK

Received 17 September 2012; accepted 6 February 2013

This paper is a multi-case study exploratory investigation into the earliest stages of projects and their manage-ment. We refer to this throughout the paper as the front-end. We provide a definition of this phase of theproject life cycle and conduct a literature review of the various topics that would suggest themselves to be appo-site to the front-end. This includes governance and strategy; requirements and technology; estimating; risk andvalue; people and learning and development. Following this review of literature, we set out the approach taken inthe empirical study. The context for the study was the UK, although many of the organizations investigated had aglobal presence and some of their projects were multinational in nature. We detail the research methods, themulti-case study route taken and the nature of the in-depth interviews with senior project management represen-tatives from nine extremely credible organizations experienced in managing projects. Our findings are presentedso as to identify the key set of findings determined after multiple passes of the interview details. These findingsreflect both what comprises the front-end of projects and what management does in the front-end. Some of thiswould be expected of project management, but we found aspects of the front-end management that are notwithin the normal remit of what is considered to be traditional project management. These findings bothreinforce the literature and offer new insights, for example, showing the strong influence of the commercialand economic non-project players in leading or influencing the front-end of projects. A considered set of con-clusions are presented together with recommendations for further research.

Keywords: Critical success factors, front-end, governance and strategy, leaders and teams, project management.

Introduction

For many people, project management is about accom-plishing an undertaking on time, in budget, to scope.As such it is pre-eminently an execution-orientateddiscipline. Thus, for example, the PMBOK Guide,the body of knowledge that the largest of the projectmanagement professional association uses to definethe discipline, describes project management as theapplication of knowledge, skills, tools, and techniquesto project activities to meet project requirements(Project Management Institute, 2013, p. 5). But thisperspective omits the issue of who manages the workthat establishes these requirements? Who manages theiterations and the trade-offs that lie between the idealrequirements and the fully worked-up project proposal?Who defines the budget, who determines the scheduletargets, who develops the project strategy and who

manages the preparation of the project documentationneeded for execution approval (sanction)? How is inno-vation in and around the project considered andmanaged? Who identifies the strategic risks in theproject? How is value enhanced as the project prop-osition is developed? Who manages the project stake-holders, when, and how? Are suppliers involved? Whomanages their involvement, when and on what basis?How is the project team selected and formed?Such questions can be wrapped into a broader, bigger

question: what really is, and should be, the role of projectmanagement in the early formative front-end stages of aproject? How is the role of project management differentwhen it comes to the front-end definitional stages com-pared with the down-stream execution stages?This paper addresses these questions in the belief that

our understanding of the role of such front-end projectmanagement is not well documented in the literature,

Author for correspondence. E-mail: andrew.edkins@ucl.ac.uk

The Engineering Project Organization Journal, 2013Vol. 3, No. 2, 7185, http://dx.doi.org/10.1080/21573727.2013.775942

2013 The Author(s). Published by Taylor & Francis.This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. The moral rightsof the named author(s) have been asserted.

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

despite evidence of the importance of the front-endthatmany of the things that cause projects not to succeedhave their origins in decisions made in the projectsfront-end and that the front-end is the part of theproject that has the greatest opportunity for creatingvalueand that, despite its importance, front-endman-agement issues, responsibilities, roles and actions are toooften ignored by official project management guidance.In short, this paper proposes that front-end project

management practice is poorly understood and isoften inconsistent from project to project and betweensectors. It is consequently often confused and there isa lack of clear, effective guidance on it. The researchreported here, aimed at describing, understanding andevaluating managements roles in the front-end, wouldseem therefore, prima facie, to be potentially very useful.

What can we say about managing thefront-end?

What do wemean by the front-end? There is not a singledefinition. For the purposes of this research, we considerthe front-end to be the preliminary emergence phase[s]of the project (Morris, 2011). In practice, there wouldseem to be two common usages of the term. The sim-plest is the gathering of user, system, business andother requirements ending in the formal acceptanceby the sponsor and the project team of these require-ments. In reality, however, the front-end of most pro-jects involves a lot more work than this implies.The front-end, in this second broader view, is often

considered as fuzzy (Kim and Wilemon, 2002), andit begins with the authorization by management of theexpenditure of time, money and effort in order todevelop the project definition. To be precise, it is thesponsor directly or the sponsors management whichprovides this authorization as the sponsor is the holderof the business case as clearly implied in the followingquote from a highly influential UK governmental body:

The SRO [Senior Responsible Owner] is the individ-ual responsible for ensuring that a programme ofchange or a project meets its objectives and deliversthe projected benefits. The SRO should be theowner of the overall business change that is being sup-ported by the project and should ensure that thechange maintains its business focus, has clear auth-ority and that the context, including risks, is activelymanaged. This individual must be senior and musttake personal responsibility for successful delivery ofthe project. They should be recognised as the ownerthroughout the organisation. (OGC, 2007, p. 5)

This is premised with the expectation that at somepoint later in the projects development, a risk analysed,

value optimized proposal will be submitted to thesponsor for the approval (sanction) of its full develop-ment and delivery (Morris, 1994; ICE, 1998). Thefront-end in this conception is anticipated as finishingwith acceptance by the sponsor of the project definitiondocumentation. It can also, of course, end with eitherthe termination or the shelving of the undertaking.Upon receiving sanction approval, the remainder ofthe project life-cycle stages would then commenceincluding resourcing/contracting and procurement;design; build/create; handover; commence in-usephases (consideration of these subsequent projectphases are out of scope of this paper).In principle, one might suppose that most of the func-

tions associated with project management generallyapply whatever stage of the project/product life cycleone was at. This is essentially the premise on whichthe PMBOK Guide works, for example (PMI, 2004,2008). But given the absence at this stage of hardproject targets (budgets, schedules, etc.) and the devel-opmental nature of the front-end, onemight legitimatelyexpect management to be qualitatively significantlydifferent here from that of down-stream execution,which is fromwhere ourmodels for project managementare typically derived. There is not a big literature expli-citly exploring the extent to which this might or mightnot be the case, however, although Williams et al.(2009), Williams and Samset (2010), and Edkins andSmith (2012) explore the distinctive nature of thework to be done in the projects front-end. There havealso been other studies looking at factors which havebeen seen to be associated with project success orproject failure. Many of them suggest factors that arelinked to the front-end as being important. Collectively,they show that the management of the front-end (a) isoften critical to the overall success of the project and(b) involves a lot more than merely the establishmentof requirements (Morris, 2013). A brief review of thesepapers now follows.Meier (2008), reporting on 30 major Central Intelli-

gence Agency (CIA)/Department of Defense (DoD)projects, concluded that

most unsuccessful programs fail at the beginning.The principal causes of growth on these large-scaleprograms can be traced to several causes related tooverzealous advocacy, immature technology, lack ofcorporate technology roadmaps, requirementsinstability, ineffective acquisition strategy, unrealisticprogram baselines, inadequate systems engineering,and workforce issues. (p. 59)

Meiers summary echoes that of Morris and Hough(1987) 20 years earlier. Indeed, NASA had reached notdissimilar conclusions in its 1992 review of its programme

72 Edkins et al.

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

and project management performance: inadequaterequirements definition; unrealistic dependenceonunpro-ven technology; annual funding instability; complexorgan-izational structures; misapplied cost estimates; scopeadditionsdue to requirements creepandacquisition strat-egy not promoting cost containment (NASA, 2007).On many projects, particularly the larger ones, several

subject areas will need to be drawn upon in shaping theproject definition, be they from the strategic, social or pol-itical level, to those that direct and interpret policy, such aspublic sector regional or local planners, aswell, obviously,as the enterprises internal expert functions. The way thesponsor engages and manages all these parties is particu-larly, and not surprisingly, critical. Miller and Lessard(2000), looking at 60 $1bn+ projects, for example,found that the owners competencies in managingexogenous factors such as stakeholders and governmentalor regulatory matters, and endogenous factors such assuppliers, were keya view repeated by Grn (2004) retechnology and design, and emphasized by Khuranaand Rosenthal (1998), Crawford and Cooke-Davies(2005), Helm and Remington (2005), Crawford et al.(2008) andThomson (2011). Flyvbjerg et al. (2003) simi-larly identified the critical role played by the sponsor, par-ticularly in estimating and addressing risk.The owners approach to project governance is par-

ticularly important. Governance provides the structurethrough which the objectives of the company are set,and the means of attaining those objectives and moni-toring performance (OECD, 2004, p. 11). The Associ-ation for Project Management (APM) (APM, 2004)goes usefully further, proposing 11 principles ofproject governance, including one arguing for a coher-ent linkage between the owners strategy (Mintzberg,1987) and the project strategy, or at the very least,between the owners strategy and an approved projectplan containing authorization points at which thebusiness case is reviewed and approved.APM, like several other project management bodies,

talks about the project plan, rather than strategy. This,however, misses the dynamic nature of much of thefront-end planning. Artto et al. (2001) concluded afteran exhaustive study of project strategy that project strat-egy is a direction in a project that contributes to thesuccess of the project in its environment. It is surprising,therefore, that there is so little research that looks at theinterplay of sponsor business strategy with the associ-ated project(s) it may generate.Requirements are meant to be solution free (Stevens

et al., 1998), but in fact the objectives, or indeed thecharacter of the project, will shape the way requirementsare defined. Many, though by no means all, require-ments reflect stakeholdersparticularly the sponsorsstrategy. For example, where an organizations end-game is to introduce innovation and its chosen route

is via a highly innovative project, then the project willprobably be at the leading edge of many areas, such astechnology, management approach and form of con-tracting. The nature of the requirementswhetherthey are routine or ambitious, standard or innovativewill be highly significant to the project strategy asthe risk profile for the project will be heavily swayed bythe nature of the requirements. Hence, though require-ments definition may sometimes be left largely to thesystems engineering function (Hood et al., 2010),more often it needs melding and integrating with otheractors wishes and abilities. In short, it needs managing.Managing stakeholders interests vis--vis require-

ments and the project definition is, consequently, avery important front-end task (and in fact has justbeen recognized as such by being established as a newknowledge area in the 2013 Fifth Edition of thePMBOK Guide). A stakeholder is a person or partythat has a stakean interestin the projects realiz-ation. This may be pro or it may be anti. The stake-holder may be internal to the core organizationsinvolved in shaping the project, such as the sponsor,financiers, etc., or it may be quite exogenous to theproject (Littau et al., 2010). Local community opposi-tion or environmentalist opposition are examples ofthe latter. Stakeholder management comprises princi-pally (1) identifying them; (2) assessing their power andposition the project and (3) elaborating a managementinfluencing or coping would be a better wordsstrategy for leveraging the pros and blunting theantis. Of these, the first is the most significant. Toooften a stakeholder appears out of nowhere and cancause major disruption. Many projects suffer substantialscope expansion in an effort to accommodate stake-holder interests and concerns.Interaction between stakeholders can sway the objec-

tivity needed for planning, particularly for estimatingtargets. Estimating is prima facie a key front-endactivity: it has a highly significant role in determiningwhether the project will be judged successful inmeeting its goals; yet, it rarely receives much attentionin the literature. Flyvbjerg et al. (2002), drawing onbehavioural economics, in particular the work ofLavallo and Kahneman (2003), has emphasized deliber-ate low-ball estimating habits for major projects as adeliberate ploy to achieve sanction/approval.Thus, the front-end is where both value and risk get

inherently built in. Their presence, for good or ill,needs managing. The risks being built into the project,via its definition, should be evaluated from the outsetof the project: they will directly affect the confidenceallocated to the schedule, cost budget and the wholeconduct of the project.The Oxford English Dictionary defines risk as the

possibility of loss, injury, or other adverse or unwelcome

Exploring the front-end of project management 73

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

circumstance (OED online accessed August 2012).Modern project or programme risk management,however, distinguishes between such negative possibili-ties and unknowns. Chapman and Ward go further,proposing that gate reviews become opportunities forvalue and risks to be formally addressed as part of aclearly defined performance uncertainty managementprocess (Chapman and Ward, 2011).Value Management (VM), as a term, covers Value

Analysis, Value Planning and Value Engineering (CEN,2000; Kelly et al., 2004). Though often administeredquite formally, it can usefully be considered as a state ofminda disposition to seek out value at all times. Andmany project people believe that the early optioneeringphase of a projects front-end development is essentiallya form of fundamental VM (Archibald et al., 2012).Benefits Management, a newer technique originating

in the IT/IS sector (Ward and Daniel, 2012), is differentfrom VM. It is concerned with the realization of benefitsduring project and programme implementation and inoperations. Benefits are what the project or programmeis done for. They can be measured quantitatively, suchas financially, market share, output capacity, etc., andqualitatively, such as improving security or brand pos-ition or social cohesion. Managing benefits involvesinter alia ensuring that they are harvested effectivelyand that lessons learned from so doing are fed back sothat future projects are changed and shaped (strategy,configuration, plans, etc.) accordingly. As such BenefitsManagement feeds into the front-end of forthcomingprojects. Establishing benefits clearly and building theproject measures around a set of benefit-orientated per-formance measures is a new and potentially powerfulmeans of improving project effectiveness.Project staffing is an absolutely critical management

action, and is a vitally important front-end managementfunction. Yet, in practice, getting the most appropriatestaff in post is often extremely difficult, especially inthe front-end where not only is the work often techni-cally difficult but also the probability of the project notgoing ahead may be high, or there may be competitionfrom other projects. Part of the trouble is that in theearly stages of a project much of what is happening istypically complex, intangible and uncertain: manage-ment here is a lot less easy to explicate than in themore mechanistic world (in the Burns and Stalker,1961, sense) of build and down-stream implemen-tation. Front-end management entails work on a trulywide range of subjects, as we have noted: needs andrequirements of various stakeholders, technologyand design, policy and strategy, finance/economicsand commercial arrangements, all of which need to beplanned (scheduled and budgeted), risk-assessed andorganized appropriately. The work is intellectual; therisks and opportunities can be substantial. None of

these fields are easy to work in, and the personalitiesinvolved will often be powerful. The style of manage-ment is often therefore altogether different from theexecution-orientated project managerranging fromthe bold and encouraging, as, for example, in lettingdesigners have the freedom to conjure up innovativeand, where relevant, aesthetically pleasing designs; tothe hard-nosed, as in negotiating fundamental financialterms and key commercial conditions. Williams andSamset (2010) rightly point to the psychological andsocial pressures and uncertainties which work of thisnature often brings. Many project managers who areused exclusively to managing down-stream executionwill be, and will feel, out of their depth here. One ofthe very first tasks in project initiation is clarifyingpurpose and team member selection. If the teamspurpose is not clear, it is unlikely to be successful(Buchanan and Huczynski, 1985).Certainly, there will be an elevated role for leadership

by senior project management personnel in forming,shaping and giving voice to goalsestablishing andselling a vision; and motivating and influencingothers to follow in the realization of that visiondoingwhat needs to be done to fill out that vision anddeliver. Articulating goals and helping to shape strat-egies, whether through bold transformational assertionor inveigling through sheer cunning.Project chartering is a popular form of helping the

team buy-in to the project purpose. The ProjectStart-Up concept has promoted the idea of combiningbehavioural team-building activities with project plan-ning. Some companies have extended this idea toproduce intense VM-driven, motivational team-building workshops, the goal being to work out how toachieve exceptional performance. The key to so muchof project management performance is how playersbehave and time spent on making clear the expectationsof team behaviour will be time well spent. These pointsstart to build the project culture, which can itself be apowerful element in the projects latter development,as demonstrated on the project to create all that wasthe London 2012 Olympics (NAO, 2012).

Learning and Development

NASA has put a significant amount of work through itsProject Academy1 into capturing lessons and getting theorganization to learn better how to manage projects andprogrammes. The UK has been trying hard too, and forsome time. For example, in the defence sector, the 1966Downey Report had argued for more time (around15%) and resource to be spent on front-end work (Min-istry of Technology, 1966), a view reiterated by Jordanet al. (1988) in their well-regarded Learning fromExperience report, and embodied in the Ministry of

74 Edkins et al.

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

Defences SMART procurement protocols in 1997(House of Commons, 2003). But merely spendingtime at the front-end is not a guarantee of success ofcourse: the UK and US defense projects have continuedto be late and over budget long after Downey (andSMART). Criticism was being levelled at the Ministryof Defence (MOD) for the same things that Meiersummarized for Department of Defense/CentralIntelligence Agency, but also due to bureaucratic pro-curement processes, ineffective decision-making andpoor scrutiny of projectsin effect, failures of govern-ance (Kincaid, 1997 p. 14). Thirteen years afterSMART acquisition was introduced, MoD projectsare still coming in late and over budget (NAO, 2013),largely, as recent analysis contends, because of insuffi-cient de-risking in the front-end leading to a disconnectbetween risks and estimates (Kirkpatrick, 2009).Why do not we improve? Part of the reason must be

the genuine difficulty of achieving organizational learn-ing. But part of it also is that we do not know genericallywhat managing the front-end really comprises.The aim of this study, therefore, was to investigate the

nature of management in developing the front-end, and tosee to what extent this relates to a broader discipline ofproject management.

Methodology

This research used qualitative multi-case methodology.The methodology is appropriate for our study as, first,each case functions as an independent experiment thatcan be compared and contrasted and sowith we can ident-ify the differences and similarities between front-endactivities in different sectors and types of projects (Yin,2003). The comparisons confirmed or disconfirmedemerging insights and concepts (Eisenhardt, 1989; Eisen-hardt and Graebner, 2007), leading towards the develop-ment of theoretical prepositions as to how the front-endworks in projects, what is common andwhat is contingent.The research focused at the level of the firm in all but

case. In the one exception, it was a specific new organiz-ational approach taken by a larger companyeffectivelyempowering a trading division to trial working in a newproject-based market. We choose cases from a deliber-ately wide range of industrial sectors to provide a widerorganizational landscape to research. The organizationsranged across a variety of markets and activities, fromadvanced manufacturing, through information technol-ogy, to traditional and multimedia creative productions.Table 1 summarizes the organizations involved in thisresearch. In total, nine organizations were represented

Table 1 Summary of the case study organizations

Case Sector/product/serviceGeographical

FocusSupplier/client

Front-enddelivery

Approach to projectmanagement

No ofinterviews

1 ITwide range frominfrastructure tosoftware development

Mainly UK withglobal presence

Supplier Combined in-house andoutsourced

Commercial perspectivedominates PM

3

2 Oil and Gasexplorationand delivery

Global Client Combined in-house andoutsourced

Overall PM advanced,less so for front-end

2

3 Complex/advancedmanufacturing

global Supplier In-house Sophisticated and maturePM

3

4 IT in-house softwaredevelopment

UK centred, butglobal

Client In-house Adopts agile PM, butnotes that it lacks fullappreciation of agile

2

5 Aerospace R&D European Client Outsourced Science and systemsdominated PM

1

6 Aerospace R&D Global Supplier In-house Systems Engineering andPM combined

1

7 Broadcast Media Mainly UK Supplier In-house Intuitive PM. Few formalPM processes orprocedures

1

8 Pharmaceuticals Global Client In-house Immature PM stronglydominated by clinicalscience

2

9 Development/construction

UK Client In-house Historically rigorous PMnot deployed in thiscase

1

Exploring the front-end of project management 75

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

in the data collection and one-to-one interviews wereheld with more than one organizational representativewhere this was possible (range was 13 people). All indi-viduals interviewed were senior or very senior in theirorganizations, typically being the heads of the projectmanagement function or above. Interviews took placebetween April 2011 and April 2012.The organizations selected were all leading players

and well practised in what they did and were well estab-lished and highly regarded in their fields. All are interna-tionally renowned. Yet, as given in Table 1, they haddifferent levels of project management maturity, for-mality and project management processes, providingpolar cases for the comparison (Eisenhardt and Graeb-ner, 2007). The organizations will not be named forconfidentiality reasons.The analytic focus was the set of activities executed at

the front-end of projects, regardless of the organizationwhere these were hosted. Interviews were conductedwith both client/sponsor organizations and suppliers.Five project client/sponsors (cases 2, 4, 5, 8 and 9)were interviewed and four suppliers (cases 1, 3, 6 and7). Table 1 provides an overview and includes in thecolumn headed Approach to Project Managementand this is the observational assessment of the researchteam derived from both background information andreflective results from the interviews.The research instrument was a set of 30 questions

designated into 3 broad areas and was developed bythe research team using both the literature and theresearch teams substantial practical project manage-ment experience (combined research teams prac-titioner experience circa 60 years). The three areascovered by the questions were as follows:

. What happens at the front-end? (18 questions).

. What do managers do at the front-end? (10questions).

. How can management of the front-end beimproved? (two questions).

The questions were reviewed by other academics andpractitioners as part of the piloting exercise and adjust-ment to the instrument was made based on feedbackgiven. The data included both information referring tothe time period and retrospective data about the devel-opment of processes, activities and roles within thefront-end, so that the front-end can be understoodwithin its context and history. Corporate documentsabout the front-end and its process were also analysedwhen available.Prior to the interviews, the questions were sent to the

interviewee so they would be familiar with the areascovered. Each interview lasted between 1.5 and 2hours and two researchers were present for all but two

interviews. Notes were taken during the interview andinterviews were recorded when the interviewee felt com-fortable. Each interview was written up in accord with aprotocol agreed by the research team to provide consist-ency. Individual notes were compared and firstimpressions were exchanged amongst the interviewteam. A report structured around the interview guidewas generated for each interview, and checked againstnotes and records, when applicable.The data were analysed in three steps. The first step

involved an in-depth understanding of the cases. Eachcase was analysed separately by the researchers person-ally involved in the interview and then the cases werepresented to the rest of the research team. In thesecond step, each researcher compared and contrastedthe accumulated case data individually, and sharedtheir findings and concerns with the team. The teamthen compared the cases, and insights were derivedand organized collectively. All answers were broughttogether into a single large spreadsheet and then eachquestion was provided with a summary answer thatalso noted the level of consensus or difference. Aseries of research team workshops were then organizedthat involved challenging conversations and multipleiterations to articulate the specific and emergentpoints revealed through several rounds of data-sifting.The product of this significant set of analytic exerciseswas set of results derived initially from a range ofsubject matter expert practitioners that had an auditabletrail from initial interview to final summary finding.

Findings

Front-end process

As noted earlier the nine organizations were divided intofive clients and four suppliers. Considering the clientset: in three cases, the project execution was eithermainly (case 5) outsourced to other organizations withrelatively little engagement of the client, or the projectsexecution was achieved jointly through in-house andoutsourced (cases 1 and 2).In all nine organizations, it was found that a form of

front-end process existed and that this was managed.In all cases, leadership of the front-end was evidenteither by an individual or through an appointed or con-stituted Board. However, each specific approach wasmanifest as a general process for controlling andwhich developed the emergent concepts to a pointwhere sanction was justified. Two organizations (cases7 and 9) declared that they had no real process, but indiscussion it was clear that there was an agreed andeffective convention regarding an implicit process.These two organizations, one relatively small in terms

76 Edkins et al.

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

of overall staff numbers, the other a new type of projectinitiative effectively quarantined from the much largerparent organization, were found therefore to have aprocess which was managed, but neither organizationhad the process written and formally articulated.Instead, the process was implicit. At the otherextreme, one organization (case 3) was quite explicitin making it clear where the front-end sat within itsoverall formal project life-cycle approach. This is notsurprising as large and mature organizations that routi-nely engage in projects would be expected to have pro-cesses and methodologies so that its staff are clear onwhat is expected, so communications are not ambigu-ous, and so project performance is consistent andacceptable.

Presence of stage-gates

The research found that stage-gates of one form oranother, where formal review takes place and per-mission is sought to proceed to the next stage of theproject, were present in all cases and that the generalissues under consideration at stage-gates were similar.Leading up to the critical stage gate of sanction the con-sensus view of the interviewees confirmed that explora-tion of alternatives was the norm, either within thecontext of potential solutions to a market opportunity(such as a TV or radio programme) or through techno-logical alternatives (such as choices between engineer-ing design concepts). Progress of the concept or ideawas, however, measured in different ways. For organiz-ations that are creating high-end engineering deliver-ables, Technology-Readiness Levels (TRLs) are used(cases 3, 5 and 6). For companies in which TRLs areinappropriate, context relevant alternatives are usedthat either measured the maturity/level of developmentof a product (e.g. popular media production) or the pro-gress towards official certification for general use (suchas a new drug).The ultimate stage-gate of the front-end, the final

sanction, varied in its precise manifestation. In somecases, it appeared as an absolute transition at which asignificant commitment of resources was made (e.g.cases 2, 3 and 8). In other cases (1 and 7) further evalua-tive events were held to provide the sponsors with con-fidence to further invest resources. It was evident that aclear purpose of the front-end was to reduce both stra-tegic organizational uncertainty and specific keyproject risks to levels which the sponsor was able toaccept and to allow endorsement of the approachtaken to that point.In all cases, we found that after the sanction gate that

concluded the front-end there was a significantincrease in formality and a transition to more conven-tional project management. This can be considered in

terms similar to that used in both new product devel-opment and innovations (Anthony and McKay,1992; Chesbrough et al., 2006) of a developmentalfunnel where at commencement projects are con-sidered strategically and with significant degrees offreedom to alter (Figure 1). As the evolving project/product is defined so it moves through the funnel,with increasing levels of consideration, scrutiny and,where appropriate, formality. Finally, the sanctionstage-gate which represents the end of the front-endwas always found to be the most formal and in all thecases considered was a multi-party event, in somecases also being a multi-day event and involving exter-nal scrutiny (cases 2, 3 and 8).

Competencies, leadership and staff

It was accepted in all nine cases that the front-end wasessentially a strategically driven activity in which theengagement and consideration of both internal andexternal stakeholders was a critical requirement. Thestrategic imperative of successfully dealing with arange of stakeholders meant that the competenciesneeded in managing the front-end extended beyondthose conventionally considered for the traditionalproject manager. Interviewees described the competen-cies required under a range of headings: politics (intra-and inter-organizational politics), strategic visioning,technological and market awareness, and ability toengage with both economic (both finance and profitrelated) and commercial (legal contract) issues. Inaddition, the specific competencies identified fromthis research that appear to encapsulate best practicein managing the front-end are as follows:

. Leadership and decision-making (experience, jud-gement and interpersonal skills).

. Selecting individuals and forming teams (judge-ment and interpersonal skills).

. Technical and technology assessment (technicaldomain knowledge).

. Project scoping and estimating (project manage-ment skills).

. Risk and value assessment (technical domainknowledge and experience).

. Establishing and instilling an appropriate oversightand governance system (leadership, judgement andexperience).

This last competency is interesting as it is really aresponsibility above and beyond the project manager:it is really a responsibility of the sponsoring organiz-ation, but supported by project management.A key finding was that in all cases financial/economic

and commercial considerations, and indeed expertstaff from these areas (in two cases led by the Chief

Exploring the front-end of project management 77

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

Financial Officer), dominated project governance.While not unreasonable, neither of these two fieldscome from a project management discipline: essen-tially commercial expertise is governing the emergingproject.

Teams

Integrating the diversity of skills required within thefront-end presents a management challenge (Thamhainand Wilemon, 1987) and this was reflected in the rangeof front-end team structures encountered. The compo-sition of front-end teams ranged from dedicated internalgroups of staff through to ad hoc arrangements thatincluded external members (experts and/or potentialpartner organizations) and could be short-lived and/ordynamic in composition.In the majority of cases no specific financial incentive

(e.g. salary bonus) was given to the front-end teams asreward for successfully completing the activities thatcomprised the front-end (the exception was onlyoccasionally in the past in one case). Rather, reliancewas placed either upon normal staff appraisal processesand/or the kudos of being associated with a successfulinitiative.The above findings can be contrasted with the set of

topics identified from the literature earlier. This isgiven in Table 2.

Project managements role in the front-end

The project managers (or directors) role in developingthe strategic level goals for the project was typically asmaller part of a more complex goal-setting systemcomprising both other players and a strategic process.As noted above, in some organizations the use of astage-gate approach mandated a structured processwith clearly allocated roles and responsibilities. Inother cases, notably cases 7 and 9, the broad principlesof a stage-gated approach were followed, but informallyand implicitly with individuals taking more of a leader-ship role. In the main, the data showed that projectmanagers were typically most involved in reportingand reviewing exercises within the front-end, withothers in the project and organizational governance(dominated by economic/finance, commercial andtechnical) taking predominant positions of project goalsetting. In some of the cases (e.g. major projects arecases 2 and 3), there was a clear role for a Project Direc-tor. This person interfaced or buffered between the stra-tegic operational sponsor and the project delivery team.In smaller organizations (cases 7 and 9), the projectdirector and project manager roles were combined.In contrast to the typically lesser involvement that a

project manager has in developing the strategic goalsfor a project, as most notably in case 8, the researchrevealed instances where the project manager had amore substantive role in setting the project sub-targets

Figure 1 The front-end funnel

78 Edkins et al.

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

Table 2 Contrast of the research findings with the literature

Front-end topics from the literature Summary findings from the research State of knowledge

The governance and strategy of the front-end ofthe project

Governance of front-end was found to be critical and driven by a clear combination of leadersallocated to own the front-end and an oversight function provided by others outside theproject. A noteworthy finding was the very clear role that the Finance Director or equivalenttook as sponsor in the front-end

KnownNew

The requirements of the project and the relevanttechnology

The universal presence of a stage-gated process meant (if only implicitly) that the clarity ofrequirements and related technology were dealt with as part of the review process. It was notobvious from the cases that this was the responsibility of any single individual or role. In thethree engineering dominated case studies the use of Technology-Readiness Level assessmentswere found to be routine

Clarification ofknownNew

The engagement with the stakeholders of theproject

The identification and engagement of stakeholders, both internal and external, was seen as one ofthe most vital functions of those managing the front-end. It was clear that the successfulinvolvement of the many stakeholders whose views will need to be considered as part of theshaping and evaluation process was a vital aspect of the front-end and required a clear skill-setfrom the front-end project managers

Known

The establishment of project targets and estimates Clearly defined aims and objectives were set as part of the front-end. In some cases these would bestandard investment appraisal metrics such as net present value (NPV) or internal rate of return(IRR), but in others the targets for the project could be to enhance reputation or establish newmarkets

Known

The principal risks involved and value to beachieved

In many ways, the front-end is predominantly about the identification and subsequentmanagement of principal risks and uncertainties to levels that the sponsor organization wascontent to proceed with. The clarity of understanding of these risks was not mirrored with theconsideration of value. This reinforces the view that value is more esoteric and less capable ofmore scientific and rigorous evaluation. Yet, the value proposition articulated is what drives theproject during the front-end

New

The people involved in the front-end There is a diverse range of individuals and teams involved in the front-end as options andalternatives are considered. Dealing with this diversity of input whilst managing a fluid processand answering to the situational governance led to the appointment of project managers whohad a clearly defined set of skills, often involving excellent interpersonal skills and breadth ofknowledge that spanned not only project management, but also the sponsors business and thekey players and factors impacting from the external environment

Development ofknown

(Continued)

Exploring

thefront-end

ofprojectmanagem

ent79

D

o

w

n

l

o

a

d

e

d

b

y

[

9

4

.

2

5

5

.

1

4

8

.

2

3

6

]

a

t

0

1

:

2

2

0

3

O

c

t

o

b

e

r

2

0

1

5

(cases 2, 3 and 6). The data divide into three categories:first those organizations where the project manager wassignificantly involved in setting the targets which werethen approved by whomever (individual or collectively)was taking responsibility for the project. Second, therewere cases where the project manager set the targets inconjunction with another respected individual (forexample, the head of engineering in a new productdevelopment in a complex manufacturing environ-ment). Third, the project manager was not involved insetting the targets, leaving it to others such as dedicatedestimators.

The role of the sponsor in the front-end

The sponsor of the project took on critical roles aimed atachieving the best possible result for the sponsoringorganization. This led to occasional significant involve-ment with aspects of the front-end process. In terms ofachieving success, the sponsors interest was in ensuringthe viability of the business case. The sponsors involve-ment with the process was through engagement withinternal and external stakeholders, and being respon-sible for not allowing expectation creep to occur.Across the cases, the sponsor made sure that theproject goals and shareholder (or owner) expectationswere set in alignment with each other and that any note-worthy changes were reported via governance arrange-ments, and as noted above, drawing on the projectmanagement function, to keep critically interestedparties informed.In all but one of the cases, there was no formal con-

sideration of establishing contingency sums or timebuffers as part of the front-end project management.What was noted was that where projects are consideredtoo risky, for example, where the technology involved orsales market is still uncertain (e.g. cases 3 and 7), thenprojects were stopped from progressing to the nextstage of the front-end. It is clear that the sponsorsview in formulating such a decision is decisive.

Management of the front-end

The review of the cases made it clear that the front-endwas about both strategic project shaping, but also aboutreserving the option to stall or cancel (see Figure 1,project A c/w project B), an option long accepted innew product development (Balanchandra and Raelin,1984; Bedell, 1983; Buell, 1967). In cases 7 and 8most initiatives do not develop successfully to thereach the stage-gate that authorizes full sanction toproceed beyond the front-end stages, whilst in othercases (2 and 3) most do. However, in all the cases the

fact that an initiative did not become a sanctionedproject/acquisition was not seen as a failure but rathera result of an effective and rigorous due diligence exer-cise. In cases 7 and 8, i.e. drug discovery and the devel-opment of entertainment products, a large attrition rateis the norm and is accepted as such. A useful compari-son can then be made with a panning for gold processwhere items or potential projects are subject to succes-sive tests and comparisons until only sanctionableones remain. The operation of the pan requires theinterplay of strategic consideration coupled with oper-ational or production-line skills. Balanced against thisis the advocating of the individual project conceptsand these remain with project-orientated domainexperts.For those projects that are sanctioned the value

created by the activities within the front-end is evidentin the identification of sets of benefits to be produced,the quality of a project management plan, the presenceof formal project appraisal evaluation using standardmetrics such as internal rate of return/net presentvalue (IRR/NPV), the satisfaction of reduced risk toacceptable levels, and the positioning of the project inits external environment including any relevant politicalconsiderations.The managed processes adopted in the front-end

varied in the following areas:

. Amount of detail (most detail case 3; least detailcase 7).

. Amount of flexibility/discretion afforded to the par-ticipants (most = cases 7 and 9; least = 3 and 8).

. Whether the implementation was procedural/mechanistic (cases 2 and 3) or instinctive/organic(cases 7 and 9).

While elaborate life-cycle process models have theadvantage of thoroughness their implementation canseem time-consuming and resource heavy. Whereemployed at the front-end these highly formalized pro-cesses tended to be in situations where speed was notthe essence (since they were operating alongsideequally rigorous processes in other key stakeholder(sub)-organizations, as would be the case, forexample, in certified engineering products in aerospaceand pharmaceuticals). Where speed was the essencedetailed definition of a highly prescribed front-endprocess was substituted by requiring key individuals totake responsibility for decision-making using theirexpert judgement.Related but not synonymous is the level of discretion

afforded to the actors in the front-end. Lower levels ofdetail typically meant greater levels of overt discretion.In the dataset, those organizations acting as suppliersto prime contractors, the front-end processes mirrored

80 Edkins et al.

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

in general terms those of the prime. This ensured com-patibility and timeliness as the prime contractors needsevolved and became more focussed.The case study organizations undertook a range of

project types and it was evident that the nature of theproject was at the core of the project managementapproach taken. From the interview data collected it isproposed that this took two forms:

. First were those projects run from a mechanisticparadigm. In such projects, there were well-estab-lished protocols and systems with individualsholding defined positions and completing a rangeof duties as set out by the enterprise.

. Second were those projects run under a moreinstinctive/organic paradigm. Here, there wasless formality, practice being dictated by anestablished and well-understood set of protocolsand procedures, with a great reliance on keyindividuals to act responsibly and to implement theimplicit practices prevalent within the organization.

Where the implications of poor judgement anddecisions were likely to be significant, the processestended to be more mechanistic and so therefore moretransparent and defendable. The interpretation ofBurns and Stalker (Burns and Stalker, 1961) thatmechanistic approaches tended to be associated withpredictive technology and a stable environment is alsolargely consistent with our observations although it isnot clear whether the predictiveness and stability arenot just results of a more formal, analytical and mechan-istic approach. With the type of organizations and pro-jects that formed the empirical data for this researchbeing as noted, it is not possible to comment on howthe front-end of major unpredictable projects such asdisaster recovery are managed. Where an instinctiveapproach was seen our observations are consistentwith the findings of Dreyfus and Dreyfus in that theapproach was largely delivered by experts who took arelatively free hand and were less concerned with fol-lowing a script (Dreyfus and Dreyfus, 2005).However, even where a mechanistic approach wasseen there was plenty of evidence of a very high levelof individual competence.Few interviewees felt that lessons from experience

(lessons learned) were well handled and it was acommon view that more could be done, but that thiswas largely dependent on the individuals and organiz-ational culture. There was no argument presented forfurther investment in information and communicationtechnologies to resolve this area. It is notable that inone case (case 7), it was felt that in a very creativeenvironment lessons from the past may be counter-pro-ductive in stifling new ideas.

In general, projects were sanctioned when criticalfactors aligned. Three principal factors emerged:

. market readiness,

. technological/concept readiness and

. programmatic readiness including resource/capacity availability.

During the front-end all of these aspects are beingexplored and progressed. In some cases, all of theseare effectively concurrent and ongoing, with projectscondensing out of the mix rather than being instigatedat a specific time.Two extremes were seen in terms of drivers:

. Either to have a technology ready for when a needin the market arose (cases 2 and 3).

. Or to create market need through innovation (cases7 and 9).

Finally, in the majority of cases we found that:

. In only one case (case 4) was any sense of agileproject management established (Cobb, 2011),and even here it was accepted that it was not fullydeployed.

. The term VM was not well understood. However,when explained most of those interviewed felt thatwhile specific VM exercises were not undertaken,a background of continual and pervasive VMexisted. Some felt that this was so ingrained thatadditional VM initiatives would provide littleadditional benefit.

Conclusions

This paper has examined what the management of theproject front-end entails from within the context ofproject management. It did so from examination ofnine organizations, some very large, none unsophisti-cated: all can be considered as either world-class orotherwise highly successful in their area. The justifica-tion for such an enquiry is that the empirical evidenceof project performance has consistently demonstratedthat ultimate project success and failure can often betraced back to what happens at the early part of theproject life cycle but that our knowledge of how tomanage this stage of a projects development cycle isoften poor.The research yielded data that has been considered

and refined by a research team that comprises academicstaff who have significant project practitioner experi-ence. Building upon these results and reflecting over

Exploring the front-end of project management 81

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

the research data a series of conclusions and recommen-dations can be drawn.As a general finding, it is imperative for organizations

that deal with projects as a core or a substantive part oftheir operations to appreciate the importance of thefront-end and the potential contribution that its con-sidered management can make to performance. Theyshould be particularly sensitive to opportunities tobetter shape the project, to assess its viability, and toreview the quality of its development, not least its man-agement. Many studies have confirmed that the front-end is where there is the greatest chance of errors andfaults becoming built-in, or value being enhanced.Within this context, we have a series of findings, first

related to process, second to actors.First, the research confirms that, across a wide spec-

trum of industry sectors, there is evidence of a manage-ment processin effect a project managementmethodologythat is applied to the front-end, albeitthat that process is individual to the sector, possibly tothe parent organization, and potentially even to theproject. We see this in all cases. This may be anobvious finding to many but is extremely important tothose who follow the Project Management Institutesview of project management, as espoused in its Guideto the Project Management Body of Knowledge that, aucontraire, project management begins after the identifi-cation and collection of the project requirements. Thisresearch proves categorically that project managementhas an important role prior to that point.We also observed differing degrees of formalizing this

process. We shall discuss this further below.We noted the potentially quite large differences in

definition of the front-end and were surprised that thequestion what does one mean by the front-end? doesnot yet appear to have been discussed in the literature.Sanction approval may occur significantly later thanthe elicitation of the projects requirements.Second, the ethos of management is seen to be differ-

ent in the front-end compared with Execution. InExecution, the ethos is typically very much about com-pletion on time and budget to a given set of specifica-tions and scope. In the front-end, however, we maynot even be sure we have a viable project. Seen fromthe perspective of those, such as people working inR&D, who are the parents so to speak of the project(the originator of the proposition), the aim may be notso much to champion the putative project as to servicethe professional needs of the sponsor, and other stake-holders. Project management in the front-end is notnecessarily about hurrying the project along withinbudget. It may well be more about providing advicefrom a management of projects perspective, even tothe point of recommending that the project may needto be aborted.

We found that the job of the project manager at thefront-end appears to be, de minimus, to provide pro-fessional support to the sponsor, advising on potentialtechnical solutions, schedules, risks, estimates, contin-gencies, organization, procurement, people (staffing)and so on. Rather than to be slavishly progressing theproject, the project manager needs to be constantlychallenging its proposed viability. And in so doing tobe building up value in the scheme being worked up.In general, the range of differentiation between the

groups found working in the front-end, and the type,scope and nature of the work to be performed, is muchgreater, in intellectual terms, time horizons, types of per-sonalities involved, surety of data and so on, than thattypically found down-stream. Thus, therefore, so is theintegration similarly broader than what is typicallybrought to bear in the execution phases of the project.This means almost certainly that the types of personalityand behaviours of project personnel will be different inthe front-end from those typically associated withexecution-orientated project management. (Though aninteresting research opportunity might be to comparefront-end project management competencies, as heredescribed, with the attributes of programme managerswho are usually painted as being more strategic).Third, the research emphasizes the absolute centrality

of the sponsor and of other key stakeholders, at least inthe front-end, and particularly in large, complex, urgentones. In all cases, economic and commercial consider-ations dominated project governance. While not unrea-sonable, neither of these two fields come from a projectmanagement discipline. We might hope therefore thatas and when project management develops into arobust discipline for managing projects, these functionswill be embodied into it.Fourth, most project management functions are seen

to apply to front-end management.

. The more formally organized companies hadwhole-life project strategies, that is, covering thefront-end and execution. A few only reallyworked in any detail on an Execution strategy. Afew had no explicit strategies.

. Requirements were managed with a range of for-malization. Some organizations/projects employedTechnology-Readiness Reviews.

. Most projectsbut not allperformed some formof implicit VM. The international oil company didthis very systematically; the international R&Dorganization did it instinctively; the complex/advanced manufacturing supplier claimed not todo at all.

. Formal risk management was used in most cases.Contingencies were not allocated to budgets in aproportional or algorithmic way, however.

82 Edkins et al.

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

. Learning and Knowledge Management is widelyacknowledged as important, not least in the front-end learning from others; its effectiveness is ques-tionable, however, and there is considerable poten-tial for improvement.

Following these four areas that provide comments onprocesses and functions, some findings relating toActors can be made:Fifth, following the observations about the increased

breadth of integration that is required in the front-end, we should note that the competencies formallyrequired for managers of the front-end will be differ-entessentially a bigger set: broader and more challen-ging than for down-stream execution. (One intervieweesaid that this was not a role for project managers becausetheir horizons are short termmaybe, but this is a caseof the tail wagging the dog: the person should fit thecompetency and should fit the project role.)Sixth, we saw how the articulation of management

methodology may be quite formal and explicit, or infor-mal and implied. Similarly, we saw how some actors pre-ferred to apply such methodology bureaucratically andmechanistically while others preferred a more instinctiveapproach. When this is mapped we found that the caseorganizations sat broadly along a linear relationship thatlinked the informal to intuitive and the explicit to themechanistic as shown in Figure 2. The suggested confor-mity to a linear relationship between the type of projectmanagement methodology in play and its applicationmakes intuitive sense and this can be hypothesized as

demonstrating the relationship between the approachtaken to project management and the organizationsculture. In extremis, we observed organizations thatwere part of the creative industries where fluidity andinformality were key considerations both of the approachto project management and the way that the organizationoperated more generally. Size may be an importantlimiter on this freedom as the organization was also rela-tively small. In much larger organizations, there is likelyto be less freedom for individuals to do their ownthing and so compliance with more formal sets of rulesand procedures is to be expected, but there is also theissue of the dominant paradigm where, for example,those from traditional engineering backgrounds wouldbe expected to follow clearly set out protocols and, simi-larly, in public sector organizations there would be expec-tations of multiple layering of both process andapprovals. Thus, the observed tendency to follow a linefrom implicit project management methodologiesapplied informally to explicit methodologies appliedrigidly is rational. An interesting question that arisesfrom this static observation is the question of how fixedorganizations are over time as they both reflect internalalterations such as change in size and as to the individualsholding key roles, as well as how external influences suchas the role of new project management approaches affectthe way that project management of the front end ishandled.Seventh, in general we saw that the application of

project management processes, the articulation of pre-ferred methodology, and the definition of desired

Figure 2 Relationship between the type of front-end project management methodology and its application

Exploring the front-end of project management 83

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

competencies was contingent on: (a) the characteristics ofthe project; (b) the characteristics of the environment theproject is to operate in and (c) to some extent, the charac-teristics of the parent organization and the sponsor.

Recommendations

The exploratory nature of this research has revealedseven conclusions as noted above. The project manage-ment research community is encouraged to pursue thevarious topics identified to both broaden the datasetand deepen the enquiry. Of the many possible areasthat can be taken forward the following are suggestedas being examples of tractable research enquiries tofurther our understanding of the front-end:

. The nature of front-end management for majorprojects that are unpredictable such as disasterrecovery following both natural and manmadeevents.

. The roles, attributes and competencies of projectsponsors.

. The attributes and competencies of the front-endproject director and project manager.

. The particular tools and techniques used tomanage both internal and external stakeholders.

. How estimates are developed and the degree ofinherent contingency that is taken into accountwhen proposing both the benefits to be deliveredand the classic project metrics of project schedule,project budget and scope and quality-relatedspecifications.

. How management of the front-end changes withinorganizations over time.

In conclusion, this research has suggested variousopportunities for understanding better, and for improv-ing, the management of the front-end of projects. Giventhe significance of the front-end, anything which makesits management more effective should be consideredimportant.

Note

1. The NASA project academy is formally known as APPELAcademy of Program/Project and Engineering Leadership:http://www.nasa.gov/offices/oce/appel/home/index.html

References

Anthony, M.T. and McKay, J. (1992) From experience: bal-ancing the product development process: achievingproduct and cycle time excellence in high technology

industries. Journal of Product Innovation Management, 9(2),14047.

Archibald, R., Di Filippo, I. and Di Filippo, D. (2012) Thesix-phase comprehensive project life cycle model includingthe project incubation/feasibility phase and the post-projectevaluation phase. PM World Journal, 1(5), 140.

Artto, K.A., Lehtonen, J.M. and Saranen, J. (2001) Managingprojects front-end: incorporating a strategic early view toproject management with simulation. International Journalof Project Management, 5, 25564.

Association for Project Management (APM) (2004) DirectingChange: A Guide to Governance of Project Management,APM, High Wycombe.

Balanchandra, R. and Raelin, J.A. (1984) When to kill thatR&D project. Research Management, 25(6), 303.

Bedell, R.J. (1983) Terminating R&D projects prematurely.Research Management, 26(4), 325.

Buchanan, D.A. and Huczynski, A.A. (1985) OrganizationalBehaviour, Prentice Hall International, London.

Buell, C.K. (1967) When to terminate a research project.Research Management, 10(4), 27584.

Burns, T. and Stalker, G.M. (1961) The Management ofInnovation, Tavistock, London.

Chapman, C. and Ward, S. (2011) How to Manage ProjectOpportunity and Risk: Why Uncertainty Management Can bea Much Better Approach than Risk Management, 3rd edn,Wiley, Chichester.

Chesbrough, H., Vanhaverbeke, W. andWest, J. (eds.) (2006)Open Innovation: Researching a New Paradigm, OxfordUniversity Press, Oxford.

Cobb, C.G. (2011) Making Sense of Agile ProjectManagement: Balancing Control and Agility, John Wiley& Sons, Inc, Hoboken, NJ.

Crawford, L.H. and Cooke-Davies, T.J. (2005) Project gov-ernance: the pivotal role of the executive sponsor, Paperpresented at PMI North America, Toronto.

Crawford, L., Cooke-Davies, T., Hobbs, B., Labuschagne, L.,Remington, K. and Chen, P. (2008) Governance andsupport in the sponsoring of projects and programs.Project Management Journal, 39(1), 4355.

Dreyfus, H.L. and Dreyfus, S.E. (2005) Expertise in realworld contexts. Organization Studies, 26(5), 77992.

Edkins, A. and Smith, A. (2012) Designing the project, inWilliams, T. and Knut, S. (eds.) Project Governance:Getting Investments Right, Palgrave Macmillan,Basingstoke, pp. 135174.

Eisenhardt, K.M. (1989) Building theories from case studyresearch. The Academy of Management Review, 14(4),53250.

Eisenhardt, K.M. and Graebner, M.E. (2007) Theory build-ing from cases: opportunities and challenges. Academy ofManagement Journal, 50(1), 2532.

European Committee for Standardization (CEN) TechnicalCommittee CEN/TC (2000) Value Management.European Committee for Standardization (CEN)Technical Committee CEN/TC, BSI: London.

Flyvbjerg, B., Holm, M.S.K. and Buhl, S. (2002)Underestimating costs in public works projects: error or lie?.Journal of the American Planning Association, 68(3), 27995.

84 Edkins et al.

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5

Flyvbjerg, B., Bruzelius, N. and Rothengatter, W. (2003)Megaprojects and Risk: An Anatomy of Ambition,Cambridge University Press, Cambridge.

Grn, O. (2004) Taming Giant Projects: Management of Multi-Organization Enterprises, Springer, Berlin.

Helm, J. and Remington, K. (2005) Effective project sponsor-ship: an evaluation of the role of the executive sponsor incomplex infrastructure projects by senior project managers.Project Management Journal, 36(3), 5161.

Hood, C., Widemann, S., Fichtinger, S. and Urte, P. (2010)Requirements Management: The Interface BetweenRequirements Development and All Other Systems EngineeringProcesses, Springer-Verlag, Berlin, Heidelberg.

House of Commons (2003) UK Defence Procurement Policy,Research Paper 03/78, 20 October 2003, London.

Institution of Civil Engineers (ICE) (1998) Risk Analysis andManagement for Projects, Thomas Telford, London.

Jordan, G., Lee, I. and Cawsey, G. (1988) Learning fromExperience. A Report on the Arrangements for ManagingMajor Projects in the Procurement Executive, HMSO, London.

Kelly, J.J., Male, S. and Graham, D. (2004) Value Managementof Construction Projects, Blackwell Science, Oxford.

Khurana, A. and Rosenthal, S.R. (1998) Towards holisticfront-ends in new product development. Journal ofProduct Innovation Management, 15(1), 5774.

Kim, J. and Wilemon, D. (2002) Focusing the fuzzy front-endin new product development. R&D Management, 32(4),26979.

Kincaid, B. (1997) Smart Procurement for Jurassic Park.Royal United Services Institute Journal, 142(6), 147.

Kirkpatrick, D. (2009) Lessons from the report on MODmajor projects. Royal United Services Institute JournalDefence Systems, Summer, 1026.

Lavallo, D. and Kahneman, D. (2003) Delusions of success:how optimism undermines executives decisions, HarvardBusiness Review, July, 5663.

Littau, P., Jujagiri, N.J. and Adlbrecht, G. (2010) 25 years ofstakeholder theory in project management literature (19842009). Project Management Journal, 41(4), 1729.

Meier, S.R. (2008) Best project management and systemsengineering practices in pre-acquisition practices in thefederal intelligence and defense agencies. ProjectManagement Journal, 39(1), 5971.

Miller, R. and Lessard, D.R. (2000) The Strategic Managementof Large Engineering Projects, MIT Press, Cambridge.

Ministry of Technology (1966) Report of the Steering Group onDevelopment Cost Estimating, HMSO, London.

Mintzberg, H. (1987) Crafting Strategy, Harvard BusinessReview, JulyAugust, 6675.

Morris, P.W.G. (1994) The Management of Projects, ThomasTelford, London.

Morris, P.W.G. (2011) Managing the front-end: back to thebeginning. Project Perspectives, 33, 48.

Morris, P.W.G. (2013) Project Management Reconstructed,Wiley Blackwell, Chicester.

Morris, P.W.G. and Hough, G.H. (1987) The Anatomy ofMajor Projects, John Wiley and Sons, Chichester.

NAO (2012) The London 2012 Olympic Games and ParalympicGames: Post-Games Review, HC 794, session 201213, 5December, National Audit Office, London.

NAO (2013) The Major Projects Report 2012: Ministry ofDefence, HC684-1, session 201213, 10 January, NationalAudit Office, London.

NASA (2007) Program and Project ManagementImprovement Initiatives, Academy Sharing KnowledgeMagazine, Spring 2007, 504.

Office of Government Commerce (OGC) (2007) Review 4:Readiness for Service, OGCGateway Process, OPSI, Norwich.

Organization for Economic Co-operation and Development(OECD) (2004) OECD Principles of Corporate Governance,OECD Publications, France.

Project Management Institute (PMI) (2004) A Guide to theProject Management Body of Knowledge (PMBOK Guide),3rd edn. Project Management Institute, Hoboken, NJ.

Project Management Institute (PMI) (2008) A Guide to theProject Management Body of Knowledge (PMBOK Guide),4th edn, Project Management Institute, Newtown Square,Pennsylvania.

Project Management Institute (PMI) (2013) A Guide to theProject Management Body of Knowledge (PMBOK Guide),5th edn. Project Management Institute, Hoboken, NJ.

Stevens, R., Brook, P., Jackson, K. and Arnold, S. (1998)Systems Engineering: Coping with Complexity, Prentice-Hall,Upper Saddle River, NJ.

Thamhain, H.J. andWilemon, D.L. (1987) Building high per-forming project teams. IEEE Transactions on EngineeringManagement, 34(2), 13042.

Thomson, D. (2011) A pilot study of client complexity, emer-gent requirements and stakeholder perceptions of projectsuccess. Construction Management and Economics, 29(1),6982.

Ward, J.L. and Daniel, E. (2012) Benefits Management, 2ndedn, Wiley, Chichester.

Williams, T. and Samset, K. (2010) Issues in front-enddecision making on projects. Project management Journal,41(2), 3849.

Williams, T.M., Samset, K. and Sunnevg, K.J. (2009)Making Essential Choices with Scant Information: Front-EndDecision-Making in Major Projects, Palgrave Macmillan,Basingstoke.

Yin, R.K. (2003) Case Study Research, 3rd edn, SagePublications, Thousand Oaks, CA.

Exploring the front-end of project management 85

Dow

nloa

ded

by [9

4.255

.148.2

36] a

t 01:2

2 03 O

ctobe

r 201

5