2. Managing Project InterfacesKey Points for Project Success
Peter W. G. Morris'
One of the most impodlnt qualities of a project manager is a mature
understanding of the way projects develop. This allows the nature of
project activities to be better understood, problems to be seen in perspective, and needs to be assessed ahead of time.
To somc cxtcnt this understanding of project development is intuitive,
thorigh i t clcarly also depends upon specialist knowledge of the project's
tech:~ologpand industry. It can, houlcver, also be acquired in large part
from formal study of the development process of projects, since all projects, regardless of size or type, follow a broadly similar pattern of development.
The organizational frametvork underlying a project's development is
the subject of this chapter. The intent of the chapter is to illustrate the
types of issues that are normally encountcred as a project develops and to
suggest ways in which these issues should be handled. The extent to
which these issues can be related to project success is then discussed.
THE SYSTEMS PERSPECTIVE AND PROJECT MANAGEMENT
The most pervasive intellectual traditiorl to project management, whether
in organization, planning, control, o r other aspects, is without doubt the
systems approach.
Dr. Peter Moms ic Director of the Major Projects Association, a member of Oxford
University's Faculty of Physical Sciences and an Associate Fellow c l Templeton College,
he Oxford Centre for Management Studies, Oxford, England. He undertook research into
project management at Manchester University, England, in the late I%&, gaining his Ph.D.
in 1972. llc has worked both as a manager and as a consult~nton a variety of projects around
the world ranging from telecommunications and petrochemicaJ projects in the Mideast,
N o r ~ hAfrica, and Europe; steel projects in Latin America; and construction, MIS, and
aerospace projects in North America and Europe. Prior to returning to England in 1934, he
was responsible for the international business of the Anhur D. Lit~leProgram Systems
Management Company, Cambridge, Massachusetts. He is the co-author of The Annfo~riyo
Major Projects, published by John Wiley & Sons Ltd.; 15%7.
A system is an assen~blageof people, things, information, or other
attributes, grouped together according to a particular system "objective." Thus, one has an electrical system, the digestive system, a highpressure \veatlicr system, an air conditioning system, a \ileapons system,
a system for winning at cards.
A systcrn may be logically broken down into a number of subsystems,
that is, asse~nblagesof people, things, information, or organizations required to nchie\*e a defined system srrbobjecti\)e, like the switching, outside plant, building, transniission, and subscriber subsystems in a tclephone system. The subsets of each subsystem may then be
identified-cables, poles, microwa\re, and transmission and distribution
equipment for the transmission subsystem-thereby creating sub-subsystems. Subsets of these subsets may then be idptified, and so on.
Propcrly organized and managed, the overall system acts in a way that
is greater than the sum of its parts. The systcrns approach emphasizes
treating the system as a \\)hole.
The systems approach has its origin in the late 1920s and 1930s. Biologists noticed similarities in the way that living organisms interacted with
and controlled their environments. At the same time, similar p3tterns
were observed by Gcstalt psychologists in the \\lay the human tnind organized sensory data. Both tlie mind and living organisms have to adapt to
changes in their environment. Systcms of his type arc known as "open"
systems. Before long it was sccn that all social systems operate as open
systems.'
During the 1950s, work in economics, psychology, sociology, atithropology, and other disciplines de\teloped these open-system ideas by elaborating such concepts as self-organization, purposive systcrns, the importance of goals and objectives, the hierarchical classification of systems
and subsystems, and the importance of systems' boundaries and interfaces (2)*. At the same timc, this "systemic" view of the world was
enriched by a parallel (but initially separate) set of disciplines which had
their origin in ,the induslrial and military applications of the scientific
method during and immediately after World \Var 11. This was the essentially numeric set of disciplines, such as cybernetics, control theory, operOpen systcrns are "open" to the cflects of their environment. On the other hnnd, closed
systems. which are the other major system type (including, for example. much of physical
chemistry and many types o f machines). operate independently o f their environment. In
open systems, events rather than things are strucfured; there is a constant energy and
information exchange between the system and its environment; the syslem organizes to
minimize entropic decay; equilibrium with the environment is achieved through a process
known as homtostasiS; and there is a tendency towards difrerentiation. Closed systems
operate in almost exactly the opposite manner (I).'
Numbered references are given at the end of this chapter.
ations research, systems analysis, and systcms engineering, concerned
with modeling real-life situations so that complex behavior could be more
accurately described and forecast. Slowly both streams merged, encour-'
aged greatly by the enormous growlh in the ability of the computer to
apply these systems ideas with powerful effectiveness, s o that the systems approach is now an established and vigorous influence on managemen; and research.
The systems perspective has contributed substantially to the development of project management. Firstly, the systems emphasis on viewing a
system a s a whole has frequently becn behind the recognition of the nccd
for an acrosr -the-board integrating role-that is, for
managcrnent
itself (3).2
Secondly, systems thinking has shown how projects should \ircrk as
successfully regulated organizations, for example, the need for clcarly
defined ~ S j e c t i v e sthe
, recognition that projects are organizations in constant change, and the need to define and manage major subsystems and
their interfaces. A third important contribution is that the dynamic control
nceds o f projects a&' now bctter undcrstood-the importance of feedback, Ihc progressive devclopmcnt of information and multilevel projcct
control. And a fourth contribution is the widespread use of systems lechrliques-s,ystems analysis, systems engineering, work breakdown structures, and simulation models.
Interface Management, as i t is used in project manngcmcnt today,] is an
outgr0~~1.h
of the first two of these influences of systems thinking on
project management. Interface Management identifies the follo~ving:
The subsystems 10 be managed on a project,
The principal sobsystcm interfaces requiring managcnlent atlcntion
The development ofproject management by the U . S . military i s an ill~strittion:the systems
ideas developed initially for technical purposes were adapted to grnerate the organizational
flexibility and control missing in the existing military bureaucracy. This can be seen in each
ofthe steps in the U.S.military's development o f project management-the dcvelopmcnt of
!.be U S A F and Navy program management practices (4). particularly for the I C B M programs ( 5 ) and for Polaris (6) around 1952-1955; Peck and Schcrer's study of the U.S. and
Soviet \\.capons procurement processes in the I;+te 1950s (7); the dcvclopmcnt o f PERT on
Polaris in I Y 5 R ; the i n t r o t l ~ ~ c t i oofn projcct organizations in the Navy, Air Force. and Arm).
in the late 1950s/early 1960s; hfcblamara's extensive s ~ u d yand implementation o f program
rn:inagement and project control ~echniquesin the early 1960s; and I-sird's and Packard's
process-oriented focus on the needs ofthe total projec~life cycle in the late 1960s~carl~~1970s
(8).
' Interface hlanagement i s ~ c n c r a l l yused now in a broader sense t h a i i t war ten or tu,cnly
years ago. I n the 1960s and early 1970s Interface Management generally refcncd simply l o
ensuring that system interfaces matched (i.e.,had the same specifications, w'erc not missing
any equipment, data, etc.). Today'it is used i n the sense of defining syslems-orpanizalional, managerial, and ~echnical-and of ~ c t i v e l ymanaging their intcrrcbtion~hip:. The
term " i n l c h c c management" i s relatively common in high-technology projects, such as
information systems and aerospace; i t i s much.rarer on conrtruction projEcts.
T h e ways in which these interactions should be managed successfully.
The emphasis on identifying key interfaces and on focusing on interface
performance has grown a s it has been irrcreasingly realized that all projects share a common pattern of interfaces derived from a common pattern of subsystem interaction. This is true no matter \\that the type of
project, be it'a theater production, an aid program, an clection or a major
capital investment program.
There a r c three sets of subsystems on any project: those deriving from
the project's life cycle, its management levels, and its operational charactcristics.
PROJECT LIFE CYCLE4'
Projcct manngcmcnt teaches that to achieve the decircd project objective
one must go throl~gha specific process. There is no cxccption to this rule.
'I'he process is kno\rfn as thc projcct "life cycle."
Projccts (like pcople) have a lifc cycle that involves 3 gradual buildup a s
definitions are cstnblishcd id \{,orking characteristics developed, a fullbodicd irnplcmcntation as thc \vork is ;lcconiplishcd, and a phasing out a s
thc work is completed and the project winds do\vn. While thcre are various definitions of the project (or program) life cycle. (Figure 2-1). the
csscntial scqucncing is invariant, althotrgh (as with pcople) sometimes not
f~lllyrccogni7cd or rc<pcctcd.
A project <tarts ;is an incipicrit idea which is cxplor-cd for fin;\ncinl and.
1echnic;il fcasibilit y in t I,e Prcfinsibi1ir~~lI;'cn
~ i h i l i r y~ f n i e ~
. A p i t c i tis~
dccidcd, locations chosen, fin~ncingarranged, overall schedule a n d
budgct ngrcctl, and prcliminary organizations set up. At t h e end c ' this
phase therc shoi~ldbe a formal "gotno-go" decision. I n the next phase,
Dcsigtt, the \vork is organizationally and managerially similar to the first
phssc only it is n1ol.c comprehensive and detailed. T h e technic;?l definition of thc projcct is expanded (;~lbeilgenerally still at a fairly strategic
lcvel); schedule, budget, and financing are ~.cappraiscd;contracting strategy is defined; pcrmits are sought, and infrastruct~rrcand logistics systems arc dcfincd.
.
Note that an interface i s tcchnicnlly defined as the space httwcen interacting subsystc ..
Even though there might be a commoll set of subs).stems on all projects. this does not
neccszrrrily mean there will be a common sct of interfaces. The extent that thcre is de?- ids
on the commonality of subsystem intcrac~ion.This chapter will show that s~~bsystcm
interaction docs in fact follow a common p;trtcrn on most projects.
'
. Thc impticalions of the life cycle are Ircared in r,rcalcr detail in Char lcr 9.
,
.
Kettey'r model 191 is essent~altythat o f a program life cycle. He dtfferentiales product control from prolect
control. prDduct control being concerned wilh the definitions of the end product parameters and project control
being concerned wtth the process of making that product.
~ e e d
Economics
Concept
-
Feasibility
-
Definition
-
Implementation
Procurement
-
Turnover
L
L
Project
Control
-
*
Product
Control
/--~l~~~i~~-~~s~tion+
operation
-1
Wearne'a model (101 is typical of industroal projecls. "The nature and scale of activities change a! each stage but
the &!ages usually overlap." Of pnrl~cul'drtnterest are the Demand and the Use. Ma~ntenance.and Records h
Experience stages. stnce these a r e often overlooked i n project management lterat~onw ~ t h ~and
n between the
early stages is not unllkety.
Demand
\
experience
f
I
Evaluation
Research
Maintenance
A
Development
-
Design
Contracts
\
Commirrioning
/
/
Manufacture
& construction
Figure 2-1. Views of !he projecdprogram life cycle.
In phase three, Mnnrrfactrtre, Corrstrrrction, arrd Irrstnll(~tion(or Prodrrcriort), equipmept is procured, civil work is undertaken, and equipment
and facililies are installed. This phase diners dramatically from the previous two. First, whercas the Design and Fensibilify phases wcrc organic
and evolutionary in character,-the Prodrrction phase is highly mechanistic
Morris: 111) concentrated o n the lersibility-design-implemenlationphases lo make ~ r apbints
l
about the
nature-of work within and between phases. The design phase i? brsically "organistic." for errmplr, wh~iethe
producl~onphase is more "mechanistic." Crossing the design-production inlerfacr, wilh the Ielt~ngof
~mplcmenlationcontracts, is a major transition point in tne project life cycle.
F u l l Operations
Installation
Substantially
Percent
Complete
Companies
100%
I
Ill
Stage I
FEASIBILITY
Project Formulation
Fearability Studies
Strategy Design &
Appraisal
Staye I1
P L A N N I N G & DESIGN
Base Design
Cost & Schedule
Contract Terms &
Conditions
Detailed Planning
Stage Ill
PRODUCTION
Manufacturing
Delivery
Civil Works
Installation
Testing
IV
*
Stage I V
TURNOVE A
& START-UP
Final Testing
Maintenance
Kenner's d~agram(121 illustrates the f~nanciatIlfe ot a product devclopment program (me) Kerzner comments
on the w r y the l ~ f e
cycle varies between systtms, projects and producls; apart from d~tferencesin terrntnotogy. 8
major d~lfcrenceis In the overlapping of phases.
Pure I
basic I
rtrearch i
E
C
U
a
I
1
I
Applied research
I
I
I
I
I
I
I
Definition
1
I
-Operational
Figure 2- 1. (cottr;t~rrcd)
L
I
Divestment
I
(13). The aim is not to develop new technical options but .d build as
efficiently a s possible the thing which has been defined in the Design
phase. Second, there is a large-sometimes vast-expansion in organization (whereas thcre may have bcen only dozens o r hundreds of persons
active in the first two phases, there may be thousands or even tens of
thousands involved in this third phase.) And third; the characteristic
mode of control changes from one of "estimating" costs and durations to
one of tight "monitoring" of quality, schedule, and cost to keep actual
performance within the target estimates.
The fourth and final phase, Tiirn-Over ur~dSfarf-Up, oxferlapsthe third
phase and involves planning all the a ~ l i * ~ ; t i qeccssary
cs
for acceptance
and operation of the project. Successfully sy-chronizing phases three and
four can prove a major management exercise. The cost of capital locked
up in the yet urlcommissioned plant, and the opportunity costs of both
underutilized operating systems such a s sales, operating plant, personnel,
etc., and a possible diminishing strategic advantage while con~petitors
develop rival products, can prove enormous.
Between each of these life-cycle phascs there are distinct "change
points" (\+!hat shall later be called "dynamic project interfaces"):
to D ~ s i g t ~the
: "go" decision.
From Prefe./pasiDilirylFca.~ibilify
From Design to Prod~rction.
From Prod~rcfiot~
to Tirrn-Over & Sfrrrf- Up.
The project or? either side of thcse change points is dramnticnlly different-in mission, size, technology, scale, and rate of change-and these
differences create their own particular different characteristics of work,
personal behavior, and direction and control needs. Thus, importantly,
the manngcmcnt style of each of the four main life-cycle phases is significantly diffcrct~t.
PROJECT MANAGEMENT LEVELS
The four phases have a set and important managerial relation to each
stage is 'highly "inst ituother. The work of the Prefiasibilif~~lFea~ibiIify
tional" (top management) in kind-decisions taken in this phase will later
havc an overriding Impact on the health of the invzsting entcl-prises. In
Design, the work is of a "strategic" nature, laying the axes upon which
the detailed, "tactical" work, of the third, Prodrrcfion phase will rest.
,Interestingly, the fourth phase, Trrrn-Ooer & Sfurr-Up, exhibits a nlixture
of all three managerial levels of work: institutional, stratcgic, and tactical.
These three levels of management activity have bcen. recognized as
distinct levels of management since at least the t i n e of Talcott Parsons,
the eminent American sociologist. Parsonsmade the point that each of the
three levels has an essential role to play in any successfully regulated
enterprise: the technical/tactical level (111) manufactures the product;
middle management (11) coordinates the manufacturing effort; at the institutional level-(I) top management connects the enterprise to the wider
social system (14). Each of these three management levels has a iundamental role to play in the rnanagcment of every project (although it is true
that the levels tend to become more blurred on the smaller projects). Yet
surprisingly, most project management literature deals only with Lcvels
II and 111. There is little in the literature that treats such Level I issues as:
the role of the owner and his financer; relations with the media, local and
fedcral government, regulatory agencies, lobbyists, and community
groups; the sizing and timing of the project in relation to product demand
and the cost of finance-all issues that became crucially important during
the 1970s and are particularly so in the 1 9 8 0 ~ . ~
The distinction between Levels I1 and I is quite critical since it is
csscntially the distinction between the project and its outside \vorld (Figure 2-2). Levcls 11 and 111 deal almost exclusivcly with such familiar
project activities as engineering, procurement, installation, testing, and
start-up-Level 111 providing the tcchnical input, Levcl I1 providing both
a buffer from the outside world arid guidance in how to avoid external
pitfalls. But no.project erists in isolation from outside events. Level I
provides the coordination of the project with outside events and institutions. Level I actors typically include the project owner and his finance
team, government agencies, commwqity groups, very senior project management, and one or two special project executives specificnliy charged
with external affairs, such as Public Relations and Legal Counsel:
The involvement of cach of these Levcls is different during each of the
major phases of the projcct life cycle. During [he Prefii7sibi!irylFeasibility
stage, the owner and his learn (Levels I and 11) have to make crucial
decisions about the technical performance and business advantages they
are to get for thcir investment-and indeed, whether the project should
"go" at all. Once the decision to go ahead is taken the weight of the \(pork
moves to the design leam (Levels I1 a'nd 111). During Prodlrctiort engineering reaches a detailed level. Both project management (Lcvel 11) and
technical staff (Levcl 111) arc now at full stretch, while top management
(1,cvel I) takes a more rcduccd "monitoring" role. Finally, during TurnOver a n d Srnrr-Up, all three Levels are typically highly active as ehgi'Such "institutional" project management issues are preeminently the concern of thk UK
hl;~jorProjects Alsoci:~lion(15). They are treirled in this handbook in Chapters R. 13, 18. and
22.
Figure 2-2. T h e three lcvcls of projcct management.
nee1 ing work gets completed (Level I I I ) , often under intense management
pressure (Level II), while high-level coordination is required at the owner
level in coordinating the initiation of Start-Up activities.
The responsibilities of thcsc 1,cvels thus focus on two main nrcas of
activity: Levels 11 and 111 on the tecl~nicaland middle management work
within the project, and Level I on the senior nlanqgemcnt work at the
project/outsidc world interface.
PROJECT OPEPJTIONAL SUBSYSTEMS
T h c work of these two essentially dislinct lcvcls of project managcmcnt
activity tcnds to follow a pallern which is similar on nlitny projects.
A1 the project/outsidc world level, the concern is to ensure that the
project is commercially viable and, a s far a s possible, is provided with the
conditions and resources neccssnry to sl~ccccd.The principal arcns of
work at tliis lcvcl arc
8
Ensuring satisfactory Project DcJirtiliotr (which includes both technical content, cost and sche.dule requirements)
Preparing for Oprrations & b h i ~ t r e n a n c e
Preparing for Sales & Murkelir~g
Ensuring appropriate 0.-ganizrtriort structur'es and systcms, both for
the project and for operations
Facilitating relations with important Orrsidc Grorrps such a s povernmen! and community groups, financial institutions, and the media
Ensuring appropriately skilled A4nnpo\vcr for both the project and
future operations
Ensuring that thc total enterprise is Cor~intcrc~iall~~
Sorrrid and "adequately financed."
Work within the project, on the other hand, focuses morc on nccomplishing the tasks within the strategic parameters develqped and managed
by senior management. At the intra-project level, the principal sulisystems are
Realizing the desired Projccl DeJ~~irion-i.e., assuring that the project is produced to technical specification, on time, and in' budget
Creating the Org~niznrionneeded to execute the project-this includes both the fot-ma1 organization structures, contractual rclationships, systems of information flow and control procedures, and also
informal patterns of working relationships and communication
Minimizing external disruptions from the E11virort11rcr11-by, for euample, acquiring adequate materials inventory to provide buffer
stocks against delivery disruptions, I~andlingupion negotiations, ob-'
taining necessary regulatory approvals, or warning top management
of future financing needs6
Providing adequate Infrasfrr~cr~rrea n d Logisrics to accomplish the
project (facilities, transportation, communication, utilities).
The cfTects of environrncnt on a project can be profound, and continue to provoke keen
theoretical analysis and discussion. Of padicular interest is the problem of how organizations behave in a constantly and rapidly changing environment. Theorists d e s c n i such
environments as turbulent and call the type ofsystems that operate in such environments
"multistable" (16). Large or complex projects in parlicular s ~ ~ f r mnny
er
ofthe conscqucnces
predicted for mullistable systems, such as large subsystem interaction, continuous objectives redefinition, rich internal fecdbnck processes. high impact o f exlemrl factors (onen
causing [,he subsystems to have to act i n an npparcnrly kss-than-rotionul wry), and rubsrrntin1 o~.gsnizationalchange, onen of r sreplunction size. These chamcten'stics can be found
an major projects such as the Concordc and Norlh Sea Oil projects, nuclear power projects,
and many dcfcnse projects (17).
STATIC AND DYNAMIC INTERFACES
The likcly existcnceof these subsystems in a project, no matter how it
unfolds, enables us to categorize certain interfaces as on-going or
"staticv-they
are not a function of the way the project bcvelops but
reprcscnt relationships between on-going subsystems (like engineering
and procurement, o r Level I and Level 11). There is another group of
interfaces, however, which arise only as a function of the pattern of
activity interdependencies generated by the way the project develops.
Thcsc we may identify as life-cycle or "dynamic" interfaces.
Dynamic intcrfaces between life-cycle (or activity) subsystems are of
thc utmost importance in project managcment, first becausc of the continuous in~portanceof thc clock in all projects, and second because early
subsystems (like Dcsigrt) have a managerially dominant role on subsequent ones (like Aln~irr/acrrrrir~g).Dynamic interrelationships require
careful handling if minor mistakes in early systems are not to pass unnoticed and snowball into larger ones latcr in the project.
Boundaries should be positioned where there are major discontinuities
in technology, territory, time, or organization (1 8). Major breakpoints in
'the project life cycle-as, for instance, between each of the four major
phases, and also between activity subsystems within each phase (for example between manufacture, inspection, delivery, warehousing, installation, and testing)-provide important dynamic interfaces. These serve as
"natural" check points at which management can monitor performance.
Most major dynamic interfaces are in fact used in this way: for example, the Project Feasibility Report, the initial Project Technical Design,
thc formulation and negotiation of the "Prsduction" contracts, and Testing and Hand-Over. Review points such as design-freeze points, estimates-to-complete, and monthly progress reports may also bc introduced
for purely control purposes without there being any "natural" discontinuity. Each in its own way reprr*.cntsa response by project management to
control the project's momentum across its dynamic interfaces.
Whereas the important dynamic interfaces are relatively sharply,defined for Level I1 and 111 management, at Level I they are less distinct.
Level I management is certainly partly driven by the anatomy of the
project's internal development, but it also has its own dynamic intcrfaces
for each of its own principal subs'ystems. Operation, Sales, many of the
Outside Groups, Manpower, and Finance and Commercial issues each
have their own often distinct life cycles. (For example: the process of
recruiting and training manpower; preparing annual financial plans.) Thus
at Lcvel 1, dynamic interfaces do not become less impartant; rather they
become more varied and less clearly dcfined. They are still crucial to the
project's success.
.
Static interfaces too are less clearly defined at Levcl I than at Levels I1
and 111, partly due to the wider scope ofconcera of Level I (which gives
rise to much mullifacted subsystem interaction, as, for cxample, between
Operations, Salcs, Manpower, and Finance) and partly due to the disruptive effect of the outside environment.
Figure 2-3 sketches thc three principal sets of project subsystems which
have now been identified: the three levels of management, static subsystems, and dynamic subsystems.
PROJECT INTEGRATION
Some .interfaces are clearly larger and more important than others. Organization theorists describe the size of an interface not in terms of, for
instance, a small change point or a major one, but in terms of the degree of
difleretlrinrion between subsystcms. Typical measures of differentiption
include differences in
"STATIC" S U B S Y S T C M S
Project
definition
Saln
snd
marketing
Operalions
a rd
mainrenance
Organization
Manpower
proups
CommerI~l
and financial
conditions
-
P
"Project"
. , ... .
Time
LEVEL!
'
. . .
Fessibilit'y
.,.
B.
PROJECT
LEVEL'II .
MANAGEMENT
,;:
LEVELS
8
"
.
"0perat;ons and
maintenance''
.:;
urnover an
:
:
Production
.
,
L E V E L 111
'
.
,I
,.;... .. ':
C. " D Y N A M I C SUBSYSTEMS
A121.
INTRA-PROJECT
"STATIC"
SUBSYSTEMS
.-
1.:
.
. :,
.
\a:..
. . ..
.
.
.
.
.
.
- . . ~&ironkntlnf,ncructurr
. c k~'f?~i,*n ~ t m norganization
; .... ... .,....;: . . .. . . .. . . . . .. .
'
1
Figure 2-3. The three sets of projecl
subsysrcms.
.
Organization structure
Interpersonal orientations
Time horizons
Goals and objectives (19).
Thus, a mechanized infantry brigade c a n be differentiated clearly from a
local community opposition group on all dimensions. The R&D wing of a
conlpany can be similarly differentiated from the marketing wing. The
architect on a building project can be differentiated from the building
contractor.
A mechanized infantry brigade will go to some lengths to avoid having
to integrate with a local opposition group but R&D has to integrate with
marketing quite frequently, and it is inevitable that architects must integrate with contractors. Why? Because the activities of the groups create
ceflain technical, organizational, and environmental intcrdependeticies.
These interdependencies may be almost accidental or may be deliberately
organized. Ititegr(~fiotrbeco~ncsimportant whcn the tlcgrce of or-ganizritional intcrdcpcndcnce becomes significant. Research has shown that
tightcr organizational integration is necessary when
The goals and objcctives of an cntcrprisc bring a need for difrcicnt
groups to work closcly together
The environment is complex or changing rapidly
The technology is uncertain or complex
The en~el-pi-iseis changing quickly
The enterpl-isc is organiza~ionallycomplcx (20).
The amount of integration actually required at an interface depends
both on the size of differentiation across the interface and on how much
"pulling together" the interfacing subsystems need.
Certain project subsystems can be differentiated from one another quite
markedly. For example, the projectloutside groups interface is marked by
very strong differences in time horizons, goals and objcctives, interpersonal orientations, and structure--this is why the conflict over many
envIronmenta1 and regulatory issues is so drastic on many large projects:
the aims and mores of the cr~vironmentalistsare far, far removed from
those who are trying to build the project. The design group often functions
quite differently from rhc construction group-the former's intercst might
be elegant enginccring, time might not be money, and quality might be
paramount; the construction crew might be of less elitist thinking, have
strong incentivcs'l~otto waste time, and might often work in a tourher
organizational milieu. Similarly, there are majcr differences in perspective between operations and project personnel, bctweep the project fi-
nance team and project engineering, between a construction manager and
project management, and so on. It is, in short, possible to"establish the
degree of differentiation between esch one of the project's interacting
subsystcms, and. in so doing thereby establish which are the principal
projcct intelfaces (21):
Despite the insights of managcmtnt theorists, choosing the degree of
integration-the amount of "pulling together1'-required across an interface still calls for considerable judgment. This is inevitable. There is no
easy answer to the question, "How much management is enough?" There
arc some pointers, howevcr. James D. Thompson, in a classic book (22),
observed that there are three klnds of interdeperidency, each requirihg its
own type of integration. The simplest,"'poo~ed," only requires that people obey certain rules or standards. The second form, "sequential," rcquires that interdependencies be xchcdrrled. "Reciprocal" interdependence, the moqt complex kind, requires nlrrtrral odjrrsrt~tcntbetween
parties (Figure 2-4). I n project terms, subsystems which are in continuous
1. POOI.ED I N T E R D E F E N D E N C E
Participants pool rmourccs etc..
c.9.. membership of r club
Coordination by standards. rules
2. SEOUE'NTIAL I N T E R D E P E N D E i K E
Participrcts follow each other
3. RECIPROCAL INTERDEPENDENCE
Prnicipants intcrrd
Coordination by committee or otha
such liriwn devise. I.*., by mufurl
rdjustment
Figure 2-4. The three lypes of interdependence.
.
interaction require liaison in order to achieve the necessary integration,
whcrens those that just follow on from one another can follow plans and
schedules.
There is a range of devices which can be used to achieve liaison (23):
Liaison positions
Task forces
Special teams
Coordinators (or per1:lanent integr'ators)
Full project management
Matrix organizations.
Each of these options provides stronger integration than the last.
The primary function of iiaisort poiitioris is to facilitate communication
bct\veen groups. Other than this, the liaison position carries no real aurhority and little responsibility. Task forrcs are much stronger. Task
forccs provide mission-oriented integration: a group is formed specifically
for a particular task and upon completi~nof the task the group disbands.
Special tentns are like task forces but httend to regularly recurring types '
of problems raiher than specific issues. A coordirrntor, or permanent
integrator, provides a similar service a s a liaison position but has some
formal authority. Iqe exercises this authority over the decision-making
processes, however, not over the actual decision makers thcmselves.
This is a subtle point, but an important one, and it often causes difficulties
in projects. The coordinator cannot command the persons he is coordinating l o take specific actions. That authority rests with their functional
manager. IJe can, however, influence their behavior and decisions, either
through formal means such as managing the project's budget and schedule, approving scope changes, ctc., or through informal means such as his
persuasive and negotiating skills. The full prqiecf ninnoger role upgrades
the authority and responsibility of the integration function to allow crossfunctional coordination. The integrator-the project manager-now has
authority to order groups directly to take certain actions o r decisions.
Matrix organizations are, by general consenf, considered about the most
complex form of organization structb~re.h4atrix structures provide for
maximum information exchange, man~gemcntcoordination, and resource
sharing (24). Matrixes achieve this by having staff Sccount simultaneously to borh the integrating (project) managers and the functional managers whose work is being integrated. Both project managcrs and functional managcrs have authority and responsibility over the work, albeit
there is a divisioil of responsibility: the functional manager is responsible
for the "what" and "by whom"; the project manager decidcs the
lor program1
manager
Figure 2-5. Typical use of the project management and matrix organizations simulraneously.
"when" and "for how much." Unfortunately the person \\tho often
comes off the \\lorst in the matrix is the poor soul (at Level 111) \vho is
actually doing the work. He reports to t\vo bosses-his project manager
and his functional manager-which is not in itself necessarily a proble~n
except when, as often happens, the project manager and functional manager are themselves in conflict (for instance, over how much should be
spent on the project). Matrix structures generate considerable conflict and
sufTer frcm constantly changing boundaries and interfaces (25).
The rclative mcrits of the matrix organization vis-a-vis the full-fledged
project organization is one of those hardy perennials of project management. Various writers 3t various times have offered all kinds of reasons
why one or other form is better. Three points seem to stand out, however.
First, the full project management role-with a project manager in overall
command of the project-does offer stronger leadership and better unity
. ~ is better for achieving the big challenge. Second, the
of c o n ~ m a n d It
matrix organization is more economical on- resources. For this reason
alonc it is offen almost unavoidable on large or complex projects. Third, it
is qbite common to find a full-fledged project manager sitting on top of a
matrix structure (Figure 2-5)-the two forms are not incompatible but in
fact fit rather well together: the top project manager (Level I) providing
'
Note, then. that if one were to list the integrating devices in terms o f ascending project
management authority. the last three forms would change order to become "project coordinator, matrix organization. full project fonn" (26).
the leadership and ultimate decision-making authority, the matrix providing maximum middle management (Levels I1 and Ill) integration.
The challenge in moving through this range of liaison devices is very
clear. Achieving greater integration requires increased attention to interfacing parties. Interfaces tend to become increasingly difficult to manage
as one moves through the continuum. Let us look now at somc experience
of managing project interfaces.
MANAGING PROJECT INTERFACES
Interface Management is not, it must be admitted, a well-developed theory of management well supported by a tight body of research and experience. It is more a way of looking at project management which is particularly useful especially on large, complex, or urgent projects. The insights
which are offered below are therefore illustrative rather than comprehensive in their exposition of Interface Management.
Keep Static Inferfaces Clearly Defined
On pr,ojects, problems require solutions within short : ; ~ n frames,
e
organizational conflicts abound, and compromises are inevitable. In such an
environment, boundaries can blur. It is therefore a fundamental principle
of Interface Management to maintain the static interfaces clearly defined.
In the Apollo program there was a constant need to reinforce organizational boundaries. When General Phillips was appointed director of the
Apollo program in 1963, he found that the program was organized entirely
nlong project grounds: one group for the Lunar Excursion Module, one
for the rocket, and so on. This created a number of problems, particularly
with the wide geographic dispersion of the program. The program was
therefore reorganized to stress its functional and geographic needs as well
as its project requirements. Five functional divisions wcre created-systcms erigineering, checkout and test, flight operations, reliability and
quality assurance, and program control-with project officcs in Houston,
I-Iuntsville, and Cape Canaveral. A matrix organization was thus created
which rcported to a strong but small program office in Wasl~ington,D.C.
(Figure 2-6). This oflice, of only about 120 persons, managed a program
which consisted at times of upwards of 300,000 pcrsons. It did so by very
clc;rrly dcfining lines of responsibility and a u t h o ~ity and program interface
relationships, and by insisting that work bc dclcgated and accounted for
strictly in accordance with these lines and procedures (27).
Organizational khecks and balances also help kecp organization interfaces clearly dcrnarcated. There are four groups which must always be
I
Apollo proqrm office
Wxhinqron. D.C.
I
Figure 2-6. Apollo program organization.
organizationally distinct on projects: project management, project control, the functional groups, and subprojects. Project management should
be separate since its role as an integrator requires it to maintain an independent viewpoint and power base. The Project Control Ofice should be
independent since its job is to report accurate and objective data on
project progress. If positioned as pad of another group, say project management or construction, there will be a tendency to downplay poor performance because management will inc\sitably hope that things will irn-
provc. Functional groups-engineering, contracting, production, testing,
rclinbility, contracts, etc.-represent the "cnsine room" of he project:
the place wherc technical progress is accomplished. On a large project or
program which is divided into subprojects there is usually a number of
in~portantschedule interlinkages and competition for scarce resources
between t h e subprojects. Often budget and personnel are swapped between the subprojects. Subproject boundaries should be clearly defined
and their intcrfaccs closely monitored by senior management if subproject
performance is to be properly controlled.
T h e organization structure used for the $3.5 billion Aqominas steel nlill
project shows these four PI-incipalgroups very clearly (Figure 2-7), a s
does the Apollo organization shown in Figure 2-6. (The Aqominas case is
described in more detail below.)
Early Firm Control of Technical Definition Is ESSENTIAL to Project
Success.
Research has. shown that time and again projects fail because the technical content of the program is not controlled strictly enough or early
enough (28).
Software devclopmcnt projects (parlicularly large, complcx ones) are
extremely difficult to manage at the best of timcs since their work content
(residing for most of the project in the project team's heads) is not as
tangible as in other projects. Unless the system design is very carefully
dcfined and communicated, the system often ends up technically inadequate, late, and very costly. The software devclopmcnt life cycle consists
of five basic phases: concept definition, design, development, evaluation.
and operation. The first phase involves problem definition and feasibility
study; t hc second, specification of user functions and technical syslcm
design; the third, coding, integration testing, user documentation, etc.'
Many software projects rush the first two phases and move too quickly
into coding. Subsystem interfaces are then wrongly designed and code is
inappropriately written. Project managemenl techniques are now being
incrcasingly applied to software projects. Configuration managemeqt is
being used to help specify the technical content of the system a s it devclops and t o control all changes as they arise. Software developnlent
techniques a r e also now emphasizing the careful, top-down evolution of
the system's design and programming.
Figure 2-8 shows a model of the building process life cycle (29). Interestingly, in most building projects there is in practice no obvious checkpoint a t t h e interface bc~wccnSketch Design and Detailed Design. Thcre
' An "exp:~ntied" vdrsion of !he inform;rlion syslems devclnpmcn! life c),clc i s trcii~edin
Chaplcr 12.
--
-0 .Y,
B
r o t
Ukz
r
r
c.
Kk
"I"
1
Z & -E
.$ff g5.g
L
a
cl
m z f
1
7-
'
b
L
1
."e~
-g
a 5 .z
2 ~9 s
2"
I
V
I
1
E-2
.Eri
g
-.
22: a:t;<
'
r
.-
I
L
/
Sketch design
-
Time
Detail design
Figure 2-8. Model o f the "oflicial" British building process.
are no clearly recognized discontinuilics in either technology, territory, o r
, ~ are there any major organizational changes.
time at this i n t e ~ f a c e nor
Yet the outline design developed in the Sketch Design phase determines
the character of the building, and thus lays the iollndations for many of
the technical problems uthich may subsequently arise during the project.
If this dynamic interface is not properly controlled-and sadly, often it is
not-the danger of design errors cropping up unexpectedly later in the
project is high (31).
Churchill Falls is often lauded as an example of a successful project.
The praise invariably centers on its tiglit control of design. An ambitious
project in northern Canada, the project consisted of retaining the flow of
the Chltrchill River through a series of vast reservoirs and dams over a
250-square-mile basin in Upper Labrador. The project was begun in
carnest in 1966 for a budget of $550 million and was completed eight and a
half years later on budget and ahead of schedule. Thc project was marked
by an early and very intense coordination bctween project management,
engineering, construction management, and finance (including insur-
' Miller has shown that.boundan'es should be formed where there are discorrtinui~icsin lime,
technology, or territory (30).
ance)-each of which was conducted by quite separate companies. At the
time of arranging project financing the state of project documentation was
such that there were "virtually no questions unanswered" (32). Following
this exhaustive initial design there was continuous close review by construction management of the engineering design as it developed, and intensive engineering t o achieve cost savings wherever possible.
One way of achieving firm control of design is through configuration
management. Configuration rnanagcment documcnts the fechnical design
of the project. cnsures regular dcsign reviews, rigorously checks the technical cost and schcdule impact of all changes bcfore approving them, and
ensures that all parties working on the project arc using cp-to-date documentation. Configuration rnanagcment has bccn used oriniarily in the
U.S. aerospace and information systems scctors; i t is only slowly being
applied to other types of projccts. It is not used in the building and ci\lil
enginecring industries, for example, though its potential applicability on
the larger and more complex of such projects is quite strong.
The Skills Required in M a n a g i n g D y n a r ~ l i cInterfaces V a r y Depending on
the M a n a g e m e n t Level a n d S t a g e of t h e Project
The Trans Alaskan Pipcline (TAPS) r.cmains onc of the largest and most
ambitiol~sof recent major projccts. Although constructed in the thrce
years bct\vccn 1974 and 1976 (at a cost of approxirnatcly $8 billion). the
project had in fact bccn on and off since 1968. Scnior manngcmcnt was
requircd to concentrate on a' series of stratcgic issucs of startling variation: firstly, on enginccring (how to prcvcnt hot oil d;ininging 111: Alaskan
permafrost and how to dcsign for scismic dani;lgc), and thcn moving
through political support (the projcct managcr actt~;tllymoved to Washly
in the
ington, D.C. to advise the political cffort tliat c v c n t ~ ~ a l rcsultcd
1973 TAPS Act), ir-lfr.astrtrcturc dc\~cIopnlcnt (trnnsportation, camps,
cquipmcnt slrpply, and union n c g o t i n ~ i o n ~organi7;rtion
),
issues (the devclopmcnt of a higlily dcccntralizcd m a ~ r i xo~.gnniz;ltiononce construction began), cnvironmcnt~lregulations, and firinlly, cnginccring and construction aghin. Thc scquence 01' issucs is intcl-csting: firstly, achicvc
agrecnicnt on the technical conccpt and political support for thc project;
secondly, assllrc adequate infrastructure and organization; thirdly, resolve environmcntnl, construction, and cnginccring issues as the projcct
is built. This is csscntially the institutional, stratcgic, and tactical sequence already noted a s typical for all projects. At the middle managemcnt le\~el,howcvcr (where managers were responsible for anything up to
$4 billion of work!), activity cerltcrcd either on resolving enginccring and
construction problen~so r on issues of organization and Icadcrship. No-
where was the organizational concern more clearly evident than in the
change at about 15% offhe way through construction from a 9-tiered,
centralized, functional organization to a 4-tiered, decentralized, matrix
organization (Figure 2-9). The result was a. highly flexible construction
organization relying, like Apollo, on a small cadre of senior managers
(33). Emphasis was on leadership, horizontal and informal communication, simple structures, and tight reporting relationships-and getting the
job done.
The TAPS pipeline matrix organizatio'n tells of an experience very simi-
President
'-7-J
Figure 2-9. The TAPS matrix.
to the project management teams: a s the project moved from its design
phase to production, there was a "swing" of thematrix towards a greater
"project orientation (34).
The TAPSIAcominas organization development leads to three important observations about the development of projects.
. Typically, Large Projects Require a Decentralized Organization During
Production with Centralization Before and After. Both projects 'exhibited the same pattern of centralization-dccentralization-centr;llization. (The final centralized phase during Tlrrn-Over rrrid SfnrtUp has not been discussed here.) The initial, design pl~aserequires
unified strategic decision making. During production the volume of
work becomes s o great that responsibility must be delegated: the
organizi9tion becomes decentralize J under the project and functional
matrix control. Finally, at rut-11-Over,the volume of \vork decreases
whilc ~ h need
c
for unified inlegration \vilh Operations' Stclr.t-Up creates the nced for cenlr~lizationonce again.
2. The Project Organization Must Change According to the Needs of t h e
Project's Size, Speed, and Complexity. The Acorninas matrix was
pln~~ned
to change at !he onset of production-about one and a half
years after it was set up, \vhich fits with the time it usually takes to
" g 1 . 0 ~ "a matrix (35). Research suggests that wthile the timing of the
organization change is a function of the project's schedule, the severity of the change depends on the project's size, speed, and complcsit y (36).
Once Decentralized, Projects Require a Substantial Management Superstructure t o Effect the Necessary Coordination. Projects decentralize, essentially, to ease the pressure on decision making. Once
decentralized, informal controls and comnlunication tend to proliferate and there is a rapid growth in the number of meclings and committees. With this growth in informal decision making there is more
need than ever for careful configuration management and budgelary
and schedule control. Formal reporting will clearly Ing actual cvcnts
considerably, but in an informal org:~nization there is a danger of
zissuming that things are happening when in fact they may not be.
(Also, informal reponing will tend to concentrale on strategically
in~portnntitems only; formal reports should provide a regular update
on all :rspcct~of project progress.) I t is, thcrefore, vital to ensure
full, regular reporting during this decentralized phase.
The c;nracter of a project rhus varies both at different stages of its
developnient and at different levels of management. The skills which are
required in managing the project's evolution vary depending on the'level
of management and stage of the project.
Each Major Project Change Point Requires Its Own Distinctive Total
Management
Changing from one major life-cycle phase to another-from PrcfitrsibilifylFi*n.ribilityto Design, Design to Prodrrcfion, and Prodrrcriorr to TrrrrrOver ( ~ n dSfnrf-Up-is a major event. The Prefeasi6ilit)tlFeasibilify-Dcrigrr transfer is econonrically the most important step in the project's life.
Major federal acquisitions have long placed great importance on the need
for very thoroirgh feasibility studies. Thorough agency needs-analysis and
exploration of alternative systems is now mandatory federal practice. Yet
while the importance of a thorough feasibility study is now generally
recognized, it is surprising how many proJ'ects do become conrmitted to
and move into Dcsigrl on the basis of a totally inadequate feasibility
study. Two of the most notorious of recent projects exhibit this clearly.
Concorde was conceived almost entirely by the British aircraft establishment, largely on the wings of technological fascination \vith only Ihe
minimum of financial analysis (37). The proposal was championed ardently by one 01 two senior British ministers who effectively resisted
Treasury pressure to review the financial assumptions. Once the French
government joined the project the political momentum became virtually
unstoppable. Final commitment to thc project was made on the basis of a
twenty-page report which was "little more than a sketch" (38). At this
stage the research and development was estimated to cost f 150 million to
f 170 nrillion; the final cost is some f 2 billion. Likewise, the Sydney Opera
House was committed to on the basis of a totally sketchy design backed
by strong political support. New South Wales* prime minister, John Cahill, saw the Opera House as an imaginative political act (39). A design
competition was held and Utzon's design was selected as winner. The
design was, however, little more than diagrammatic. There was little
evidence of strt~cturalfeasibility and no cost estimate. A quantity sur\!eyor was therefore asked to prcparc one, which hc did "undcr tlurcss in
a few hours" (40) arriving at a figure of $A 7 million. The final cost, after
drastic redesign (resulting in so reducing the scencry spacc that opera
cannot be fully staged in the building) was $A 102 million.
The transition from Design to Prodrrcfion is less clear-cut than that
from P~~cfcasibilifylF~asibili~y
to Design. It is also much broader in scope
and involves much fullcr management attention. At this interface, management must be fully active in all the major project subsystems: project
definition, organization, environment, and infrastructure. The overriding
preocct~pationshould be that the strategic parameters are properly set as
the interface is crossed, since once Prodrrctiort begins the scale and pace
of events increase dramatically. So important is this interface to project
implementation success that it requires "total" management attention:
planning, organizing, directing, and controlling. Contracting-the key interface activity in fact-offers a good example. The contracting process
must be supported by project management through integrated planning,
thorough negotiating, and through close monitoring. Often contracting is
not managed but just happens, thus swamping the project with \vork and
delaying it considerably. (A~ominashad to sign 400 contracts during an
18-24-month period. Accomplishing this was a major management
achievement in its own right.)
Trrrn-Over aud Sfart-Up probably receives considerable non-project
planning and control but generally from places other than within the project team. The meshing of the two imporlant phases of project construction and operations is complex and has large cost implications. All 1,evel I
subsystcrns must be complete and activated as soon as Turn-Over occurs.
Despite the obvious importance of smoothly transitioning from Prodrrction to Turn-Over, it appears rare, especially in the construction industries, that a project planning group prepares and monitors integral..-;Iplans
for crossing this interface. This might be partly because of the subsfantial
differences in Stc~rt-Upbetween aerospace programs and large ncvf .:,qpital expansion facilities (factories, telecommunication systems, ports, sic.)
which may havc dcpressed the e\tolulion of dcfense/aerospace program
management ideas on this important area of \vork.
Pljnning Must Be Phased to the Stage of the Project Life Cycle
The differing nature and requirements of the various project life-cycle
phases require that different issues be addressed as the project unfolds.
Project planning cannot be done comprchensi\~ely,once and for all, ng !he
beginning of the project. The uncertainty during the early stal;c.:. (IC a
project is too great. Instead, planning must be incremental (41). !rl,tral
planning must concentrate on building viable planning bases for each
principal subsystcm, detail being added later in phase with the project
schedule (Figure 2-1 1).
The Apollo Mission's "Phased Project Planning" explicitly recognized
this (42)-major life-cycle phases bcing identified and planning rc a#;..-.v
checkpoints positioned along the life cyclc (Figure 2-12)-as have subse-
Time
A.2.1
A. 1
1
C
Project 8
A.1.1
Time
;A.1.2
___C
,
0.1.Parcels
0 2.Parcels
BJParcelr
fr
0.2
1
B.4.Parcels
1
C
1
1
I
1
Figure 2- 1 1. Project planning development.
quent U.S. aerospace manuals (c.g., DOD 3200.9, DOD 5000.1, AFSC
800-3, to mcntion just three).
Apollo was fortunate in that it had nearly a decade for N A S A to develop its systems and program planning. Many projects are less fortunate.
Early North Sea oil projects, for example, were i n ~ ~ l c m c n t cwith
d great
urgency, and made worse by the short summer weather window for towing and positioning platforms in the North Sea. Oil companies found
is wonh while o r how it i s to be achieved. Ifyou choobc a sc~lurior:, ~ i t h c ~ u t
-
8
PROJECT
MNNIW)
M
RASIBIUW
Y
SMTECY
NRHOVER
DUlGN
PRODUCTION
&
SfART-UP
ECONOMIC
EVALUATION
Benefits
Risk
Continue Appraisal
with View lo Changing Project Specifiulions i f Necuury
Impact on other Dusinclrs Functions Auused
Adjustments Made as Necessary
Auur Project Cost
for Product Pricing
"
PROJECT
DEFINITION
System Spea
Ease Technology
S blimate
Project Schedule
Outline Design
Configuration Dcfinition
Budget by Major
Arcas
Milestone Schedule
Detailed "Planning"
Schedule
Futher development
or Outline Design.
Schedule and Budget
Detailed Contract Specs
and Drawings
Ovcnll Schedule
Requirements
Dctrilcd Budge~/Contnct Bids
Operating Manuals
Training
Primay Malerials
Preparation
HandovrSchedule
Test 'Schedules
Mmc
FINANCE
Potential Sources
Principl SourMajor Payments
Schedule
~etailcdSdureclr
hforc Dc~ailedCjsh
Requirements
Dcleilcd Pnymcnts
Schcdule by Crcditon B
Currency
Annual financial
Operating Plan
Initial Impact
Assessment
Definition of Environmcntal Impact
Statement
National & Larl
Govcrnment Suppon
Schcdulc of Approvalr Required
Government or Community Supporl
Groups Identified
Permit ExpeditingSystem
Expediting Schcdulu
Pubic Relations
Markctina
Personnel
Invcn~oryPlanning
Safety Procedures
Ou~tandingLegal
luues
ENVIRONMENT
1
Attitude Autucd
Supplier Situation
Assased'
'I"p?y3S
sru~isAg
Urld J 2 ~ o d l J r ~
xulr).y
n!i!(!q!suodux
~ w u o u a di s r o r d
P "-W"!fi
lm%d
uqia!ur%o
Ix!OJd •
dn-uns
pur i u m d o l u ~
UO!la!u~8~0
~qtu+do
\O
rr)
d
PJaPJ0
PO u q WoS klq!md •
suo!an3s!a uo!un
paua!p ~ X J I
-ug) ~ o r ar u~q
Urld
8 u ! l ~ ! l 0 8 3i~~ ~ l u o 3
SIV"~~W
w r l d s u y l . 1 ~PaI!Vl¶Q
~=l!rlaa
uo!la!utho r a u ~
suo!l!p
4103pur S U J ~l ~~ ~ l u o 3
P=Y!1
-uapl [ a ~ u w a dLax
p ? y ! ~ l p lSUJ¶I~(S
UO!lWJOJUI 1 0 f 1 ~
pw!uuaaw n!i!l!q
-!suodnn 1 t d 1 3 u ~ d
m ~ n - rlru
-airw q ~ o q q U O ! ~ ~ ~ J ~ S L'~011
IO~
-mug y ua!aasa!O
-¶lrJlS J O l 3 ~ J l U O 3 - :JOJ ndmuo-~l l r ~ a r o
¶U!Ilno
133r0~dlr!1!ul
thcmselves having to develop a new generation of rigs, which involved
the use of new technology, working in a harsh and poorly documented
environment, without adequate codes of practice or regulations-all
within a very tight schedule. A slippage ofjust a few weeks could result in
the delay of the whole program for nearly a year. To speed up the program, projects were often sanctioned on the basis of preliminary designdata and manufacturing was overlapped with design as much as possible.
While these early projects could probably have been managed more efficiently if there had been a longer start-up time to acquire environmental
design data, develop codes, and put project management systems and
procedures in place (as has been suggested (43)), the economic pressure
on distributing North Sea oil as soon a s possible effectively precluded this
option. In these projects, the project life cycle not only determined the
sequence and dcgrce of planning appropriate at a given stage, it set an
absolute limit on the time available for planning.
Ensure Full Working o u t of the Static Subsystems a t Each Stage of the
Project Life Cycle
"Static" project subsystems (technical definition, organization, environment, and infrastructure) must be fully worked out at each phase of the
project's life cycle. Unfortunately this does not always happen, often
because the habits of an industry o r organization have institutionalized a
culture of neglecting certain "essential" subsystem considerations.
Movie pr.oductions are notorious, for example, for overrunning budget.
The most common reason for their doing so is that there is a culture of
allowing the director to work out how thc film will develop as he shoots
it-there is neither "design" nor "schedule." (No one on the set, including the director, knew how Cnsablar~cawas going to end until the cnd of
shooting; Francis Ford Coppola did not have the ending of Apocalypse
Now worked out even as he entered the editing room.)
Sometimes, the effects of urgency are so great that it is not possible to
\{pork out fully the static subsystems before moving on to the next phase.
Many defense projccts cannot avoid modifying their performance requirements (because of a changed Threat Analysis) yet must still keep to
schedule (44). This is the situation known as concurrency (45): there is
a substantial body of knowledge available showing that concurrency is
invariably associated \vith difficulties and overruns (46). Concurrency
has proved unavoidable on several occasions in the nuclear power industry, basically when changes have been required at an advanced stage of
construction- o r during commissioning because of rcgulalory changes o r
technical PI-oblcms(47).
The.tendency for architectural design to dominate the building proccss
has already been commented upon. Figure 2-U compares two basically
well managed, large, complex building projects (48). Thc first (A) was
managed by architects working under the RlBA1s Plan of Work (49).
Since the Plan of Work assumes compcritive bidding by the main contractor, it does not mention the use of any form of construction management
advice prior to construction bidding. Thus the architects did not schedule
the project or seek any form of production advice during the early design
phases. Project B, however, used a large U.S. AIE firm which was familiar with project management practice and employed both systems design
techniques and a management contractor. As a result there was early
project scheduling and production advice so that the technical definition
subsystem was fully worked out early in the project.
Control Needs Vary Depending o n t h e Level of Control and Stage of t h e
Project
As the tasks of the different levels of project management vary, so do
their control needs. Level 111 management uses frequent, often daily,
control of key performance factors such as earih moved, concrete
poured, pipe laid, vessels installed, tests completed, together \(lit h basic
cost data. At Level I1 further data are required in addition to the Level 111
"key drivers": for example, inventories, drawing approvals, transportaPreliminary
Design
Review
(PDR)
-
First A n i c l e
Customer
Design
Certification
Configuration
Acceptance
Inspection
Revim Rcadinm
Review
critical
(FACI)
(CARR)
(DCR)
Fliaht
Readiness
~erign
Rwiew
Rwim
Phase I Phaw II P h r w Ill
(FRR)
CARR
CARR
CARR
(CDR)
-
-
r.
Requirement
def initi o n
-
Oesiw
Manufacluring
d ~ v t l o p ~ t
hign
s t ~ t
-
Design
requirements
bawlin
established
-
V a i f i c r t i o n of
manufacturing n des*
specilication and assessment
of t a t rcsult~
P~oduct
c o n f i i r a t ion
Drawing
b a u l i ~
established
bulb
mablishcd.
Certify
Determine
f lipht
readinem
0'
flight a d ~ . ~ u ~ a f t
rele.~
. Orou,,d and
for launch
f w manned
flight
figure 2-13. Comparison of two British building projects. (For Subsystem Coding refer to
Figure 2-8.)
tion, camp capacity, security, accidents, contract management, changes
pending and approved, contingency reserves, These are d d a not needed
on such a frequent basis as the "key drivers" data. Level I interests are
broader still: exception reporting on progress (i-e., report problems and
poor trends only), interface relationships with other subsystems (e.g.,
between subprojects, between operations planning and project progress),
training, cash flows, etc. (50).
"Control" has a meaning which is greater than merely monitoring. It is
used in the broader context of setting standards, monitoring, and correcting for deviations between actual and planned performance. This more
complete interpretation of control is the one used in cybtrnefics. (The
word "cybernetics*' itself derives from the Greek "to steer".) The nature
of control during PrefeasiBili~lFeasibilityand Design is different from
that during Prohrcfion and Turn-Over. As has been already noted, the
need during the early stages of a project to plan, design, and estimate
correctly is very large. The costs during these early phases are small
compared with the total project cost, and so the need to monitor them (at
least from a project as opposed to design point of view) is correspondingly
S'mall. Later, during Production, the crucial cgntrol need is the monitoring
of performance to ensure that quality is being achieved and resources are
being deployed on schedule and in budget. Hence the nature of control
changes during the project life cycle from predicting to monitoring.
"Control" in this broader sense also varies depending upon the interests and objectives of the persons doing the cofi~rolling.Different groups,
with their different interests, will have different control needs. A project
owner, for example, will want to monitor the economic worth of the
project as much as its technical, cost, and schedule performance. A contractor might be particularly concerned with cash flow control.
Personnel Issues Will Vary, Again Depending on the Level of Control and
the Stage of the Project
Conflict is .inherent in every project, not least since the primary project
objectives-quality,
cost, and 'schedule-are themselves in conflict.
Quality costs money and requires time; working more quickly costs
money. Also, projects often engender contractual and community conflict.
Studies in 1he mid-1970s (51) have shown that the pattern of conflict
varies during the project life cycle (Figure 2-14): schedule and priorities
dominate thc carlx phases, with technical issues coming to the fore later
(and with cost as a consistently low-conflict item). One should not a.ssumc
that this pattern applies for all projects, however-one would normally
V
At tt,e
project f o r m t i o n
Stan
At the early
During the
main project
project phase8
Proicct life
Toward the end
of the project
* F inid
Figure 2-14. Relative intensity of conflict over the project life cycle.
expect greater conflict over technical issues earlier in the project; the
conflict pattern might -vary by type of project (and contract type); cost
pressures may be generally more domipant than they were on the projects
studied; and personal issues are probably stronger on matrix and overseas
projects. Dczpite such necessary cavcats, the findings arc extremely valuable: they provide solid evidence that the type of conflict varies according
to the stage of the project life cycle.
Similar rescarch ( 5 2 ) has also studied how the factors which are (a)
most important and (b) most inhibiting to project success vary with the
life-cycle stage (Figure 2-15). I t too has shown that personal issues vary
with the stage of project life cycle.
The nature of conflict also differs according to the level of management.
All ~ h rcscarch
c
on project conflict undcrlcrkcn to datc cither concentrates
on Level IIIIII management o r has h e n in the aerospace industries,
which have typically been more sheltered fronr cxtcrnal pressures. Conflict n t Levcl I is usually totally different, requiring other modes of resolution. Most of (he bchaviorial work in projects to date assumes a normative, mechanistic view of the world: a world where people make rational
% significant
0
0
U
0
I
I
I
-0
H1
I
TI
5
Unmotivated tram
I
Poor
1
W
.
0
1
Penonrl ambition/rnotivation
Financial limits
Technologcul advantage
-
1
Team motivation and coowration
5.
- I Personal ability and motivation
Poar smiw mrnwJemmt
Technical problems J
P a n financial sum&
1
-
7I
"
m
Senlor manaaement s u ~ w n
Technical ex~ertise
I
I
1
Team motivation
E
gg
Lnd.nhip probirms
--
Technical p o b l m
c.
Poor financial wpport
Clirnt
Poor finrncirl support
Objeclivn
Scntor management support
F~nancialsuomn I
I
decisions based on trade-offs of costs and' benefits, and where open dialogue between men of goodwill leads to amicable solutions. While this
approach is largely valid for most ir~t~a-project conflict and behavioral
issues, it is often inappropriate for dealing with outside-world issues. The
Level I manager ill as often as not find himself having to deal with
people having cgmpletely different \lalue systems from those of the project's. Hence, while the more mechanistic approach to personal issues is
appropriate to 1,evcls I1 and 111, Level I often requires a more political
approach.
Many practitioners conlment on the importance of leadership to project
success. Strangely, however, the research evidence on !.his is at best
skimpy (53). There would appear to be little doubt, Ilowever, that leaders'
abilities are associated with success or failure, although it is generally
difficult to isolate the effect of leadership from other factors such as top
management support and authority.
Leaders have a particularly important role to play in creating the context for success. Leaders create climates: their personality can sway the
ability to ev;tluate a project objectively; they can often negotiete or communicate things which otherwise ulould not be agreed. These abilities are
particuhrly important at Level I in working with outside parties.
RELATION TO PROJECT SUCCESS
To what extent are thes; findings relevant to that most important issue,
the question of project success? The first point to note in addressing this
question is that the notion of project success is, as has already been
observed, relative. In recent research on this question, I used four distinct
measures: functionality-does the project function in the.way the sponsors expected?; project management-was the project completed on
schedule, in budget, to technical specification?; contractors' long-term
commercial success; and, where appropriate, termination efficiency (54).
This said, there would seem to he considerable evidence that several of.
the issues raised in this chapter bear strongly on the chances of success.
Firstly, the discipline of Interface Management itself was seen to be
important whcre there is significant interdependence on projects (55).
Organizational issues have been shown to relate to project success (56).
Issues of design management, concurrency, and planning have a polentially enormous impact on projects if not nccomplished effectively. The
evidence on the relationship between human factors and project success
is, by comparison, considerably softer, as was just noted (57).
Insofar as Interface Management relates to clear planning and the orderly management of relevant project systems and dimensions, it is almost self-evident that it must contribute to project success. The insights
related in this chapter are, almost without exception, proved through
quoted experience or academic research to have an effect o n the final
outcome o f a project. The twist, however, is that the definition of success
varies from individual company to individual company; and that as one
moves from Level 111 to Level 1, the diversities and uncertainties o f the
many groups operating in the project's environment are likely to make
judgments about the causes and effects of project success increasingly
difficult to make.
REFERENCES
I. Katz, D. and Kohn. R.-L. 71re Sociijl Psyclrolog~Of Orgonizatiotrs (Wiley. New York.
1966), pp. 14-29.
2. Kast. F. E. and Rosenzweig. J. E. 0rgtrtri:trtinn n r ~ dAfotrtlgetrrrtrr. A Systctrrs A p proach (McGraw-Hill. New York. 1970).
3. Lorsch, J. W. and Lawrei-re, P. R. Srtrdies In 0rgtltri:rrrion Drsign (Itwin Dorsey.
Homewood, Ill., 1970).
4. Putnam W. D. "The Evolution of Air Force System Acquisition hfanagement." RAND.
R-868-PR, .Santn hfonica, Calif., 1972.
5. Beard, E. Dcvrlopitrg rlre ICBM (Columbia University Press. New York. 1976).
6. Sapolsky, H. Tlrr Poluris System Devrlopmmr: Blrreurrcrnric nnd Progrr~trrtnnricSlrccrss in Govertrt~rttrr(Harvard University Press. Cambridge. Mass., 1972).
7. Peck, M. J. and Scherer, F. M. 7/rc Wrripotts Acqrri~itionProcrss; A n Econottric Analysis (Harvard University Press. Cambridge, Mass., 1%2).
8. Acker, D. D. "The Maturing of the DOD Acquisition Process." Defrtrsr S ~ s r e m s
Vol.
Mnt~ngettrcnrR E V ~ C I O
, 3(3) (Summer. 1980).
9. Kelley, A. J. "The New Project'Environment" in N e w Ditrrtttsions of Projrcr Afntroget n m ? (Lexington Books. Lexington, Mass., 1982).
10.- Wearne, S. H. Principlrs of E~rginfcringOrgnttizurion (Ed\vard Arnold. London. 1973).
I I. Morris, P. W. G. "Interface Manage-An Organization Theory Approach to Project
Management." Project A4unngrmctr1 Q~rarrrrly.Val. lW2) (June, 1979).
12. Kerzner, H. Projrcr A4unngrttrm!: A Sys~rmsApproaclr t o Plntrtring. Schrdrrling orrd
Cotrrrollitig (Van Nostrand Reinhold. New York, 1982).
13. The organistic/mechanistic classification of organization types was developed by Bums,
T. and Stalker, G. M. in Tlre Afanogrnrenr of ltrnovn~ion(Tavistock. London, 1961).
14. Parsons, T. Srrticrure and Procrss in Modern Socittics (Free Press. Glencoe, Ill., 1960).
15. Morris, P. W. G. and Hodgson, P. "The Major Projects Association and Olher MacroEngineering Societies: Their Activities and Potenrial Contribution to the Development
of Project Management," in 81lr H'orld Congress on Projcct Mntrngrtrrrnt (Internct.
Rotterdam, 1985).
16. See, for example: Metcalf, J. L. "Systems Models. Economic Models and the Causal
Texture of Organizational En*:ironments: An Approach to Macro-Organizational Theory." Hlttrron Rrlrrions, Vol. 27 (1974). pp. 639-663. Also;Emery, F. E. and Trist, E.
L. "Sociotechnical Systems," in Systrtns T/rinking, ed. Emery. F. E. (Penguin. Harmondsworlh, 1969). pp. 24 1-257.
17. hforris. P. W. G. and Hough, G. Ji. Preconditions of Success and Failure in Afajor
P r o j r c ~ s(Major Projects Association, Templeton College. Oxford, September, 1986).
16. Miller. E. J. "Technology, Territory and TTme: The Internal Differentiation of Complex
Production Systems." Htrnian Relations. Vol. 12(3) (1959). pp. 270-304. Also. Miller.
E. J. and Rice, A. K. Sysrcms of Organizarion. Tlie Corirrol of Tnsk arid Scnrienf
Borrndnrics (Tavistock. London, 1%7).
19. Lawrence, P. R. and Lorsch, J. W . 0rgarti:arion and Enuirontricn~;Ifnrragirrg Differcnriarion and Jnrrgrclrion (Harvard University Press. Camhridge, Mass.. 1967).
20. Morris, P. W. G. "Organizational Analysis of Project Managemen't in the Building
Industry." Brrild Jrrtcraorio~rnl.Vol. 6(6) (1973), pp. 595-616.
21. Ibid.
22. Thompson, J. D. Org;atii:n~iovsit; Action (h!cGraw-Hill. New York, 1967).
23. This list is based on Ga!braith, J. !?. 0rgnni:nrion Drsilpn (Addison-\\'csley. Reading,
Mass.. 1973). .
24. Davis, P. and Lawrence, P. R. Mmrrix (Addison-Wesley. Reading, hfass., 1977).
25. Ibid.
26. Youker, R. "Organizational Alternatives for Prgject Management." Projrcr Afrlnagernrnr Qrmrrerl~,Vo!. 6(1) (1977), pp. 18-24.
27. See for instance Baumgartner, J. S. "A Discussion with the Apollo Program Director.
General Sam Phillips." in Sysrtnis .!ftrnngmtmr, ed. Baumgartner. J . S. (The Bureau of
National Affairs. \Vashington. D.C.. 1979).
28. Alexander, A. J. and Nelson, J. R. "Measuring Technological Change: Aircraft Turbine
Engines" Rand Corporalion, R-IOI?-ARPNPR, Santa Monica. Ca (June 1972); Cochran, E. G., Pat). A. L. and Rowe, A. J. "Concurrency and Disruption in Hew Product
Development" Cnli/ornia Manogrnicnt Rruie~c*(Fall. 1978); Department of Energy.
"North Sea C rsts Escalation Study" (Her hfajesty's Stationery Oflice, London, 1976);
General Accsunting Office, "Why Some \\'capons Systems Encounter Production
Problems \Vlile Others Do Not: Six Case Studies" GAOISSIAD-85-34, \Vashinglon
DC,24 MaY 1985; Harman A. J. assisted by Henrichsen S "A Methodology for Cost
Factor Comparison and Prediction" Rand Corporation, R-6269-ARPA, Santa Monica,
Ca (August 1970); Marshall, A. W. and Meckling. W. H. "Prediclability of the Costs.
Time add Success of Development" Rand Corporation. P-1821. Santa Monica, Ca
(December, 1959); Merrow. E., Chapel. S. W. and Woflhing. C. A. "A Review of Cost
Estimation in New Technologies: Implications for Energy Process Plants" Rand Corporation, R-2481-DOE, Santa Monica, Ca (July, 1979); National Audit Onice "hfinistry of
Lkfence: Control and Management of the Development.of hfajor Equipment". report by
L'te Comptroller and Auditor General (Her Majesty's Slationery Office, London. I2
August 1986); Murphey, D. C.. Baker. B. N. and Fisher, D. "Dctermin3nts of Project
Success." National Technical Information Services, Springfield. Va.; Myers. C. W. and
Devey, M. R., "How Management Can Affect Project Outcomes: An Exploration o f t h e
PPS Data Base." RAND, N-2106, Santa Monica, Calif., 1984; Perry, R. L. el at.
"System Acquisition Experience" Rand Corporation, Rhf-6072-PR. Santa Monica, Ca
(November, 1969); Pugh, P. G. '"Who Can Tell What Might Happen? Risks and Contingency A l l ~ \ ~ ~ a n c e sRoyal
."
Aeronautic Society Management Studies Group. 1985.
29. Royal Inrtitule of British Architects, Plori of Work. Hundbook of Arclrirrcrrrrnl Prncricr
and Afatia~tmcnt(RI BA. London. 1963).
30. Miller, E. J., op. cit. (18).
31. Morris, P. W. G. "Syslems Study of Project Management." Buildini. Val. CCXXVl(6816 and 6817) (1974). pp. 75-80 and 83-88.
32. Warnock, J. G. "A Giant Project Accomplished-Design Risk and Engineering Management," in Successf~rllyAccotnplislting Giant P r j r r r s . ed. Sykes. A. (Willis F a k r .
London. 1979). pp. 31-61.
33. Moolin. F. P. and hfccoy, F. "The Organization and Management of the Trans Alaskan
Pipe!ine: The Significance o f Orgenizational Structure and Organization Changes." Proc.errlirrgs of rlrc Projeer Alntrngcr~rrrrrIr~srirrrrrCorr/i~rcrrcr.Arlur~rrr.1980 (Project Managenirnt Institute. Drexel Hill. Pa.. 1960).
34. Reis de Carvalho, E. and Moms. P. W. G. "Project Matrix Organizations, Or How To
D o The Matrix Swing." Procrdirrgs of rlrr Projrcr Alrrtrrrger~rrtrrIn~rirrtrrCot?/croice.
1-05 Arrgrlcs, 1979 (Project Managenlent Institute. Drcxel Hill, Pa., 1979).
35. See, for instance Davis, P. and Lawrence. P. R. h.ftrrri.r, op. cit. (24) Also, Whitmore. K.
R. hfo1ri.v O i ~ g ~ ~ r r i ~ oi ft ri oC~IIU~III~~II~I~
~is
h f r r ~ ~ ~ r f i r ~ ~ ~ ~ r r i r ~ g - hCor~rp(rnirs,
f t ~ r L e ~ ; n gM.S.
Thesis (Sloan School o f hfanngement, MIT. Cambridge, htass., 1975).
36. See Rcis de Carvalho. E. and Morris. P. W. G., op. cit. (34).
37. Ifall. P. Grcnr Plu~rrtitrgDisnsrcrs (H'eidenfeld and Nicolson. London, 1980). pp. 87108; Morns.
36. See Hall, P., op. cit. (37); and Edwards. C. E. Co~rcorde: Trn Yrtrrs c ~ r r da Billion
c r
Press. London. 1972).
f'orrrrds L ~ r ~ (PIUIO
39. Ko~rzmin,A. "Building the New Parliament House: A n Opera House Revisited?"
1~1111run
Fr'r,trrrcs, \'ol. 31 1) (Spring 1960). pp. 5 1-74.
40. Ilall. P.. op. cit. (37). p. 141.
41. lionr.itch, M. "Designing and hfanaping Large-Sci~le,
I'uhlic-Pri\*a~e
Tcchnolopical Enirr Sorirry. Vol. 1 (1979). pp. 179tcrpri-es: A State of the Art Revie\r+." Trclrrrolo~)~
192.
42. Scamans. R. and Ord\t,ay, F. I."The Apollo Tr;jdi~ion: An Object Lesson for he
htanngcrncnt of Large Scvlc Technological Endenvors." I r r r r r d i ~ r i p l i ~ t t rSiirrrce
~ - ) ~ Reui~bcl.\'01. 2 (1977). pp. 270-304.
43. Depnnmcnt o f Energy, op. cit. (28).
44. htorris, P. W. G. and Hough. G . H.. op, cit. (17).
45. Acker. D. D..op. cit. (8); also Iiarvcy. T. E. "Concu~rcncy Today in Acquisition
hlanagcmcnt." Drfrrtsr S~srerrrsAfnnri~r~trcrr~
Rcuict18. \'ol. 3 ( 1 ) (\Vin~cr.1980). pp.
14- IR.
46. C o c t ~ r ~ n
E.. G..Patz. A . L. and Ro~ve.A . J. op, cit. ( 2 8 ) ;Gcnerlrl :\ccounring Office.
ibid; Patz, A . L . . Irrrroutrrio~rPirfolls crrrd Aftrtrtrgc~r~rorr
S ~ ~ l r r ~ i ior r~Iiiglr
r c Trrlrtrolog)~
Irrdrrrrrirs (University o f Southern California. I.os Angclcs. Calif.. 1984).
47. Kutr~er,S. "The Impact of Rcgula~oryAgencies on Supcrprc<ccts." in f l ~ r ~ t ~ r i Enging.
rrccrirrg rrnd Corr,c~rrrcrirrgrltr Slrprrprojrcrs, American Socic~yof Civrl Engineers' Conference, P;~cihcGrove. 1970 (ASCE. New York, 1978); hfonopolics and Mcrgcrs Commission, Ccnrral Elccrricity Gerrcrnri~rg~ h o r d A. Rcporr 011 rltc Opcrrr~iotrofrhe Dourd
of 11s Sysrrrn for rlrc Gorrr-trrio~rrrnd Srrpply of EIPCII ,c ;I). i r r RrrlA ( l j e r Stajcsty's
Stationery Office. London. 1981).
48. Morris, P. W. G. op. cit. (20. 31).
49. Royal Instit~rteo f British Archittcts, op. cit. (29).
c
50. Morris, P. W. G. "The Use and hfnnagcment o f Projccr Control Sys~cmsin ~ h 60's."
f'rojrcr Afrrnngrrtrrrrr Qrrurrrrly, Vol. XI(4) (Deccmhcr. 1980). pp. 25-28.
51. Thanihain, 13. J. and Wilcmon, D. I-.
"Conflict hf;tn;~g~.mcntin Projcct Life-Cycles."
Slootr dfnrrrrgt~rrr~~rrr
Rcuic,tv (Summer, 1975).
52. Dugnn, 11. S., Thilmhain, H. J . and \\'ilemon, D . I-.
"hfi~nngingChange Through Project
hfanagcment." Pr.occrdingr of rlre h o j r c r Af~rtrrr~crtrc~rrr
I ~ r \ r i r r tCorrfcrcrrcc.
r~
Arlarrro.
1980 (Projcct M;~nngcment Insti~utc.Drcxel tiill. Pa.. 1980.
53. Gcnrniil, C . and Thamhnin, H. J. "Project Pcrfo~mnnceas a Fi~nctionof the Leadership
Sl).les of Project hfnnagcrs." Projrcr hloirogr~ttrirrlrrsrirrrre Conferrtrcc. 1972 (Project
Sfanagemcnt Institute. Drcxel 11111,Pa.); lionvdle. G . and \'an Snnt, J . I~trplc~nr~rrnrion
for Sus~rrinabiliry.Lcssotisfionr Itircgrn~cdR~rrulDcvelopnirtir (Kumarian Press. West
Hartford, Conn., 1985); Murphy, D. C. et at., op. cit. (28); Myers, C. W. and Devey, M.
R.. ibid; Rubin. I. M. and Sellig, W. "Experience as a Factor in the Selection and
Performance of Project Managers." IEEE Transucrions otr Etipiriccririg A/unrrptr?icnr,
Vol. EM-131(35) (September, 1967). pp. 131-135; Ruskin, A. M. and Lerner, R: "Fore-
54.
55,
56.
57.
casting Costs and Completion Dates for Defense Research and Development Contracts" IEEE Trt~nsctctiorison Ertgitrtcring AI~~tinpcnient,
Vol. Ehi-19(4) (November,
1972), pp. 128-133.
Morris. P. W. G. and Hough, G. H., op. cit. (17).
Ibid.
Pnulson, B. C., Fondahl, J. W. and Parker, H. W. "Dc\*clopment of Research in the
Constr~~ction
of Transportation Facilities." 'Technical Report NO. 223. The Conslruction Institute, Department i,f Civil Engineering, Stanford University, Slanford. Ca..
1977.
Gcmmil, G. and Thamhain, H. J.. op. cit. (53).