INSIGHTS ON INFRASTRUCTURE CO- DEVELOPMENT: The case of the T5 Programme © Nuno Gil MBS 2006 © Nuno Gil, MBS 2009 Nuno Gil Manchester Business School,

INSIGHTS ON INFRASTRUCTURE CO-DEVELOPMENT: The case of the T5

Programme

© Nuno Gil MBS 2006© Nuno Gil, MBS 2009

Nuno GilManchester Business School, The University of Manchester

© Nuno Gil MBS 2006

•Aims to give customers share of voice in development process

•Customer signs off design brief before work progresses into detailed design and physical execution

Infrastructure co-development problem

© Nuno Gil, MBS 2009

T5 project team

BAA Retail Business Unit, Heathrow Security Unit,

Heathrow Operations Unit (…)

Statutory Authorities: Home Office, Police,

Customs & Immigration, (…)

BA

ManufacturersConstruction Contractors

Architectural & Engineering Consultants

Supplier base

Systems Integrator

ProjectTeam

Customers(Internal/external)

Suppliers

End-users (internal/external)

BAA – 72,000 staff

Infrastructure Owner

PassengersHeathrow 4,500 staff

Immigration staff

Retail & Catering staff

BA staff

End-user base

(…)

Customers

Inst

itutio

nal F

ram

ing

BA

A b

ylaw

s, d

esig

n st

anda

rds

Cod

es o

f Pra

ctic

e, L

aws,

Sta

tute

s, H

SS

E R

egul

atio

ns, (

…)

Inst

itutio

ns (

inte

rnal

/ ext

erna

l)


Relevant New Product Development literature…• concurrent engineering, set-based design, design

postponement (Clark and Fujimoto, Loch, Terwiesch, Ulrich, etc.)

Starvation

Duplication

Rework

Problem-solving cycle atinformation sender (upstream)

Preliminary Informationrelease (only one interaction iscaptured for illustrative reasons)

Final Informationrelease

Expected solution concept forproblem-solving

Common denominator between thepossible solution concepts

Alternative solution conceptfor problem-solving

Iterative Strategy Set-based Strategy



but infrastructure co-development is different problem with different timescales (Gil et al. 2007)

ReworkDesign buffer out if early enough

Buffered solution to accommodatethe worst-case scenario

Leave buffer if too late

Iterative Strategy (P1a,b) Buffering Strategy P(2a,b)

Problem-solving cycle atinformation sender (downstream)

First release of preliminary Information

Subsequent release of preliminary information(only one interaction is captured for illustrative reasons)

Expected solution concept for problem-solving

Alternative solution concept for problem-solving

Upstream release of Information (only one interaction is captured for illustrative reasons)



From Complex Products & Systems literature:

• Co-development is core process in developing CoPS (Hobday 1999, 2000; CoPS literature in general)

• ‘System integrators’ use co-development to develop customer-focused solutions (Brady et al.)

• Co-development can lead to conflict when (IT) projects are complex because of incompatible goals (Robey and Farrow 1982)

• Desirable situation: constructive conflict resolution where both parties openly raise problems and search for their solutions, cooperate, and engage in teamwork

• Failure to reach constructive conflict gives room to domination and stagnation, project failure



Research method and base

• Building Theory from Multiple Case Study Research

• Sample of Co-development Processes

BA retail British Airways (BA) National Air Traffic Services (NATS)

• Data collection from April 2005 to June 2007


Empirical setting•£4.2bn (2005 prices) Heathrow expansion (T5)

•Testing ‘Rethinking Construction’ proposition


CA

R P

AR

K

PHASE 1 PHASE 2

Baggage System

Train System

- Aircraft StandsT

ER

MIN

AL

4

EX

IST

ING

TE

RM

INA

L

TE

RM

INA

L 3

TE

RM

INA

L 2

TE

RM

INA

L 1

?

Implementation includes detailed design and physical execution

Salient features of co-development process

(Co-handling of public inquiry)

2002 2003 2004 2005 2006 2007

Implementation

Developer-led design development (base building )

2008

Definition of hospitality/check-in/retail functions Airline/retail fit-out

ImplementationDesign definition

Definition of air traffic control function fit-out

ImplementationDesign definition

Definition of flight schedule function/configuration of aircraft fleet

Start roof erection

Design definition

Move cab to siteEnd mast erection

End of roof erection

Enabling works on site

2001200019991998199719961995

Design definition & Implementation phases(implementation includes design detail & physical execution)

Co-Development of the planning application

Customer-led design development (building infill)

Developer-led design development (aircraft stands )

Customer-led design development

Developer-led design development (base building )

Customer-led design development (building infill)

Evaluation of the planning application

• Extremely long• Intra- and inter-firm relationships• Overlap design-execution limits flexibility to accommodate late

changes at low risk to budget, schedule, asset performance


d/s – designers/suppliers

Units of analysis

Customer

Unit of Analysis ProjectCustomer Relation to Developer

Formal discussions

Archival documents examples D/

S (*)

Develop

er

Customer

BAA Retail

Layout of airside retail area

Main TerminalBuilding

Internal Stakeholder

Different business

unit

11 15 2

Briefs, drawings, requirements, press clips, schedule of facilities, supplier presentations

BA

Layout of the Commercially Important Passengers (CIP) departures lounge

Main Terminal Building

ExternalStakeholder

Different Blue Chip Company

10 14 5

Functional and operational briefs, drawings, specs, project requirements, schedule of facilities, customer interviews in press, customer presentations

Layout of the check-in area 10 15 5

Layout of the aircraft stands around main terminal building

Airfield 7 7 5

NATSConfiguration of air traffic control tower cab

Air Traffic Control Tower

External Stakeholder

Statutory authority

3 5 2

Drawings, specs, project requirements, user presentations



Customer interests, information exchange

Unit of Analys

is

Customer Interests Characteristics of preliminary information exchanges

Flexibility to postpone design

decisions

Flexibility to make late design changes Precision Stability

Retail

Business-critical“In the world of retail, I have earliest responsible moments: dates before which I should not responsibly make decisions” (retail director)

Business-critical“I fixed subdivision and detail use of 140 units in 03/05; chances are someone decides not to occupy, and others request bigger units” (retail director)

High “The actual locations of retail units are to be confirmed; the areas in the schedule are placeholders only” (facility schedule 03/04)

Moderate for boundaries, low for interior layout: ~ 2002, fix circulation vs. retail space for ~15,000 m2 ~2004, fix user allocation (shops, catering, toilettes, etc)~2005, fix 150 retail units



Developer interests

Unit of

Analysis

Developer interests in co-development

Meet customer needs Meet project budget and timescale, make sure it works

Retail units area

Recognize business criticality

“Retail is a valuable source of revenue. It is essential that the optimum amount of retail space is provided in the right locations” (design brief)

Gradually freeze design

“The only way to manage this [retail layout] is about being clear and say ‘what is fluid is within this box, you cannot move it all together or add a lot of new functions’” (development head)

Control for late changes

“I think that if they [retail] would like to change things now (04/05), we would say ‘Ok, let’s complete and see what we can adapt at the end’” (development manager)



Design architecture: integral, modular?

Function

Customer-led design

Developer-led design

Design interfaces Exemplar

Retail

Infill systems:

lighting, raised floors, partitions, ceilings, kitchen, sprinklers, flight display, etc.

Base-building systems:

perimeter walls, floor plate, data/telecom, utilities (fresh air, drainage, power, water, etc.)

CoupledInterfaces:

(1) Expected loads must be agreed upfront;

(2) retail areas integral to floor plate and capacity of backbone utilities

“Even if you’re just changing the location of a toilette block, you have to resolve a problem.. we had big problems with moves of catering units because ducts need to be fully accessible ” (design manager)



Core conflict: who pays for downside risks stemming from design fluidity? shall risks be

incurred at all?

Unit of

analysis

Co-development leads to conflict Resolving conflicts where they emerge

ExamplesMechanisms

to reduce conflict

ExamplesMechanisms

to resolve conflict

Retail Units “It is easier for them [retail] to go

into irresponsible moment, and to always want explanations why decisions need to be made” (developer project leader)

“They tend to ignore when I say ‘I can only give you an assumption by that date.’ They say ‘fine,’ but when it changes, they say ‘you cannot do that’” (retail director)

1, Change management process

2, Design postponement

3, Decouple systems (over design, modular design)

“They wanted decisions by this date, I said I could deliver by this date, we end up with a compromised date in between” (retail director)

1, Co-locate design teams

2, Prototype

3, Decentralize programme governance



Cross-case comparison

•BAA retail case: Disappointed with lack of flexibility to cope with very late changes, but understood need to draw the line at some point

•Agreed to fund business-critical late changes•Bought notion of priority list for late change requests

•BA case: frustrated with lack of flexibility to accommodate very late changes

• ‘terminal building is not fit for purpose’• ‘we and BAA are not ‘good bedfellows’

•NATS case: modular design approach decoupled base-building system from internal layout

• over 22 changes to internal layout of the control tower cab• ‘we had positive interaction between 2 teams’



Contributions

• Conflict in infrastructure co-development inevitable due to conflicting interests, externalities

• Conflict rise can be moderated by managing customer expectations• Manage expectations: agree timescales for design decisions

BUT DON’T PLAY GAMES• Implement change management procedure to dissuade non-

business critical change• Incorporating flexibility in design definition (modularity, buffers) • Co-locate team, prototype

• Conflict resolution• Decentralize programme governance, placing capability to

resolve conflicts where they emerge, so as to reduce conflict escalation

• Customer funds very late changes, priority lists© Nuno Gil, MBS 2009

Documents

INSIGHTS ON INFRASTRUCTURE CO- DEVELOPMENT: The case of the T5 Programme © Nuno Gil MBS 2006 © Nuno Gil, MBS 2009 Nuno Gil Manchester Business School,