Download Can there be a theory of project management

ICE James Forrest Lecture
“Science, objective knowledge, and the theory of project management”
Peter W.G. Morris
Professor of Project Management, UCL
Executive Director, INDECO (International Management Consultants) Ltd.
Abstract
Though there is now reasonable agreement on most of the formal tools used for
managing projects, there is still a spread of views on what constitutes the
discipline of project management. This paper examines the nature of the
knowledge we have on the discipline and in particular, how testable and public
this knowledge is, in the sense that scientific based knowledge is, and how
predictive a theory, or theories, of project management we have. It examines the
success of systems thinking in introducing the scientific approach, both in
management generally and in project management specifically. It suggests that
while the ‘hard systems’ approaches of systems engineering and decision
support have had a seminal impact on the development of project management,
‘soft systems’ thinking also has an important role, particularly at the front-end of
projects. The human side of our actions in project management, and knowledge
of them, is also extremely important. One implication is that predictability
therefore becomes much harder. Another is that much of our knowledge about
how to manage is tacit, that is, private and non-scientific. There are limits
therefore to how much we can explicitly formalise the knowledge required to
manage projects effectively. Nevertheless, there is increasing activity to try to do
so, and to use this as a component of project management competency
development. Though understandable, we should be wary of thinking that we will
be able to identify causal relationships between knowledge of project
management actions and predictability of project outcomes. We can certainly
identify good project management practice, and knowledge of various aspects of
project management, that if applied is more likely to result in successful project
outcomes. But there will never be an overall theory of project management.
Indeed, the very notion is mistaken.
Introduction
It would be fatuous to contend that the scientific method has been applied to the
management of projects only relatively recently. There are countless examples of
engineering and science being applied to the management of projects right back
to ancient times, most very well known to members of the Institution of Civil
Engineers, not least because so many of them were major construction projects.
It is a popularly held view that project management originated in construction. If
we are talking about modern project management, as now generally understood,
Peter Morris
Page 1
16/01/2004
ICE James Forrest Lecture
this is not strictly true. Virtually all the practices, concepts and language of project
management can be shown to have had their origins largely in the US aerospace
agencies in the mid-1950s, though with antecedents pre World War II1. They
were developed primarily on programs2 such as Atlas, Polaris, Minuteman, and
Apollo, in response to the need to develop new ballistic missile capability on a
highly urgent basis to counter perceived Soviet threats; and thereafter via
Department of Defense (DOD) initiatives that capitalised on these, not least
those following the arrival of Robert McNamara as US Secretary of Defense in
1960 [Morris, 1997].
Apollo was hugely influential in promoting modern project and program
management practices3. The objectives were clear: classic project ones: in
President Kennedy’s words of 25 May 1961, “to achieve the goal, before this
decade is out, of landing a man on the moon and returning him safely to earth”.
(The budget was less publicised: $20 million, of which $7 million was
contingency.) The resulting effort by NASA and its contractors was a heroic
example of engineering ‘systems’ management. A strategy of how to get to the
moon, and back, had to be developed (the initial idea was first to build an orbiting
space station and to depart from there), engineering of the rockets, landing
modules and support infrastructure had to be developed, and astronaut
biobehaviour in space understood and designed to; and all within highly
determined schedule and cost constraints. The program objectives were
substantively achieved; (the cost was $21billion) [Morris, 1997].
The resulting project management approach was hailed as the new management
paradigm: the answer to how to tackle many of mankind’s problems. “The first
1
It is true that the Critical Path Method was developed by DuPont in 1957, almost at exactly the
same time as PERT was developed on Polaris, but the engineering project management
practices developed in the DOD and NASA were far in advance of construction management
practices at this time. By the mid 60s much of construction in the broadest sense – civil and
building as well as process engineering – was using some of the new project management
techniques, most notably network scheduling. The process engineering industries however were
organisationally more aligned to project management than building and civil engineering. They
had a much more ‘through-project’ integrated approach to engineering project management, with
engineering [design], procurement and construction typically being performed by the same
management team. As is now well recognised, the building and civil engineering industries, with
their effective split of management responsibility between the Engineer (or Architect) and the
Contractor, had no single person actively managing the shaping and delivery of the project from
its earliest phases through design into construction and operation. The new US defense/
aerospace approach to project management presented a much more integrated approach to the
definition and delivery of engineering systems.
2
The so-called American spelling of program is in fact the one given first in, and recommended
by, the Oxford English Dictionary.
3
A program is used here in accordance with normal, contemporary project management
terminology, namely as a collection of projects related to a common aim, and often using shared
resources. Projects are single shot undertakings, in the sense of having a single project life-cycle.
Subprojects may exist within projects. In reality of course the relationship between subprojects
and projects is similar to that between projects and programs and the distinctions should not be
taken too literally.
Peter Morris
Page 2
16/01/2004
ICE James Forrest Lecture
management approach born of the nuclear age and the electronics age” [Sayles
& Chandler, 1971]. Yet in reality, the NASA approach was fundamentally limited,
for Apollo had been a ‘closed’ systems program in the sense that the program
was substantially shielded from external changes such as funding cutbacks or
environmentalist opposition, such as was to kill the US SST4 in 1968 and cause
such interruption to so many major projects in the 70s [Morris, 1998; Horwitch,
1982].
This ‘systems approach’ to the management of projects was one that hailed
directly from the application of modern scientific methods to management. The
history of the limitations of this application, and the efforts we have been making
to adapt and enlarge upon it to better deliver projects successfully, is the theme
of this paper.
The paper explores the nature of our knowledge of project management, and in
particular the role of the scientific approach to the discipline, and asks whether,
ultimately, we can envisage a theory of project management. It does so in four
parts, addressing:
a) what project management really comprises: is it primarily about delivering
something ‘on schedule, in budget, to scope’ or is it a much broader discipline
concerned with the whole business of defining, promoting, and executing
projects;
b) how objective and scientific our knowledge of project management is;
c) what the role of systems thinking is, as an example of the scientific method
applied to project management;
d) how useful formal knowledge of project management is in achieving
successful project outcomes.
These questions are asked partly in response to the terms of reference of the
2001 James Forrest lecture for which this paper has been prepared, namely to
explore the contribution of science to civil engineering, and partly because the
question of the theory of project management is one to which the project
management community is now itself increasingly addressing. (The US
headquartered Project Management Institute organised a conference on
research in project management in June 2000. A major theme running through
the conference was, indeed, whether we could define project management as a
coherent discipline, and, in corollary, what is ‘the theory’ of project management
[Hunt, A, 2000; Slevin, DP, Cleland, D I, & Pinto J K, 2001].)
What is project management?
An obvious place to start is to understand what we mean by, first, a project, and
second, management.
4
SuperSonic Transport – the US competitor to Concorde.
Peter Morris
Page 3
16/01/2004
ICE James Forrest Lecture
There is a surprising diversity of views on what a project is. Kerzner, one of the
gurus of project management, characterises a project as having “ a specific
objective to be completed within certain specifications, with defined start and end
dates, funding limits (if applicable), and which consume resources (i.e. money,
people, equipment)” [Kerzner, 1998]. BS 6079, A Guide to Project Management,
defines a project as “a unique set of coordinated activities, with definite starting
and finishing points, undertaken by an individual or organisation to meet specific
objectives within defined schedule, cost and performance parameters” [British
Standards Institute, 1996]. The Gower Handbook of Project Management states
that “a project is a cycle of activities with the purpose of supplying, within definite
start and completion dates, a unique product, service or set of information to a
specified quality and cost” [Locke, 2001]. PMI’s Guide to the Project
Management Body of Knowledge – PMBOK® – defines a project as “a temporary
endeavour undertaken to create a unique product or service” [Project
Management Institute, 2000].
Though one could argue, for reasons that will become evident during this paper,
with the “definite start and finish” idea, the gist is probably clear. A project can be
characterised as a ‘unique’ endeavour – in the sense of a one-off – undertaken to
accomplish a defined objective. Yet in reality the most fundamental characteristic
of a project is something which is a direct result of this uniqueness and yet which
is hardly mentioned in these definitions (pace Gower), namely the life cycle.
The one single thing which distinguishes projects from non-projects is that all
projects, no matter how complex or trivial, go through a common life cycle
development sequence. Whole organisations can be set up to achieve specific
objectives within given time and cost constraints and that will consume
resources. (The Apollo program office was not a project.) But it is the act of going
from Concept through Definition, Development, Build, and Hand-over – or words
to such effect: several different life cycle models exist [Project Management
Institute, 2000; British Standards Institute, 1996; Dixon, 2000; Forsberg et al.,
1996] – that truly distinguishes projects from non-projects. This sequence is
invariant5. (See Figure 1)
Figure 1: the project life cycle.
Stage gate
review point
Concept
Stage gate
review point
Feasibility
Stage gate
review point
Definition
Stage gate
review point
Execution
Operation
and Review
5
It is useful to note that the same life cycle sequence can be nested within each stage of the
overall life cycle, just as subprojects nest within projects which can nest within programs
Peter Morris
Page 4
16/01/2004
ICE James Forrest Lecture
Management is an activity. It is the activity of planning, organising, directing and
controlling (Fayol etc). It is about communicating; about deciding; about using
resources. In the words of the leading management thinker, Peter Drucker, “it is
a practice not a science. It is not knowledge but performance” [Drucker, 1974] –
words which we shall come back to later in this paper.
If the only thing that really distinguishes projects from non-projects is the life
cycle, arguably the only thing that distinguishes project management from other
forms of management therefore are the management skills and actions involved
in going successfully through that life cycle. This surely is the case, though the
word “successfully” is crucially important here. There is no point in progressing
through the life cycle is the result is not successful. But the issue is, how does
one define (and measure) success?
What in fact precisely comprises the discipline of project management varies
depending on the nature of the project, the role of the project manager, and the
stage of the project life cycle at which the project manager is operating. Thus
managing say the landscape contract for a power station will involve fewer issues
than being the owner’s project manager of the station’s overall definition,
construction, and commissioning.
Most definitions of project management would agree that, at a minimum, there is
(a) integration of the work of others needed to assure project success – the
“single point of integrative responsibility” [Archibald, 1997] – (b) the application of
certain project management practices. It is the extent of application of these
practices, and the nature of the integration, that leads to differences in definition.
At its most basic, project management involves some combination of scope
management6, activity scheduling (time management), and cost and resource
management. This is in effect basic project control. Managing people is generally
an important aspect of most management; adding people management, including
communications, leadership and teamworking, probably gives the basic set of
project management skill requirements.
Before long though, technical and commercial issues will probably be seen to be
affecting the chances of a successful project outcome and these too will need
addressing. Risk, and probably value7, will need managing on a systematic basis
too.
6
The term ‘scope’ seems to be less comfortable in the UK than the US where, in its project
management context, it originated. The PMBOK® defines scope as “product scope – the features
and functions that are to be included in a product or service – and project scope – the work that
must be done in order to deliver a product with the specified features and functions” [Project
Management Institute, 2000].
7
Value (as in Value Management or Value Engineering) can often be treated integrally with Risk,
something that is not well covered in RAMP [ICE et al., 1998]
Peter Morris
Page 5
16/01/2004
ICE James Forrest Lecture
In general, the nearer to the definition stage of the project (the nearer to the
‘Front End’), and the higher the organizational level, one gets, the broader the
range of issues that one will find oneself dealing with: issues of strategy, finance,
organisation, technology, control, people and culture, commerce and contracts,
community and environment, process and timing, and so on.
Such a broad view of the discipline is actually rather daunting in its implications.
For what we are saying is that project management, at anything other than the
basic level, might have to deal with an enormously broad range of issues – all the
issues that present themselves as one moves from concept to completion, and
that vary from one context to another.
There can be no doubt that many of the people who are employed to manage
projects do indeed find themselves having to address just such a broad range of
issues. Critically, of course, they will generally not see themselves as expert
enough, nor as having sufficient time, to work alone in all these different areas.
Instead they will act as integrators of the work of functional specialists. Their core
competence, as project managers, will be knowing how to integrate the work of
others, as the project evolves through its life cycle, in order to meet the project’s
objectives.
This view of the domain – the discipline – of project management is certainly
more than that normally put out by most of the basic textbooks on project
management, many of the business schools, and even the Project Management
Institute itself. Here the normal view is one which aligns project management with
‘execution management’: the accomplishment of stated objectives, most
classically defined as accomplishing the project ‘ on time, in budget, to scope’:
here is the objective, go do it. Here project management is not seen as covering
project definition, and typically does not treat with technology, environmental or
even commercial issues. PMI’s PMBOK®, for example – seen by many as one of
the most authoritative guides to what a project manager should know – identifies
nine ‘knowledge areas’: integration, scope, time, cost, risk, quality, human
resources, communication, and procurement. These align well with this view of
project management as primarily execution management [Project Management
Institute, 2000] – Figure 2.
Deploying these project management areas alone is almost certainly no
guarantee however of ensuring the accomplishment of the project ‘on time, in
budget, to scope’. For example, research that carried out at Oxford and in the
USA in the 1980s showed that many of the factors that cause projects not to
meet their schedule or cost targets are not covered by the PMBOK® type model
[Morris & Hough, 1987]. Among the factors which this data showed typically
cause projects to fail to meet their baseline targets are things like client driven
changed specifications or order quantities, technology problems, poor design
Peter Morris
Page 6
16/01/2004
ICE James Forrest Lecture
Figure 2: the Project Management Institute’s nine major knowledge areas
Project
Management
Project Integration
Management
• Project Plan Development
•Project Plan Execution
•Overall Change Control
Project Cost
Management
•Resource Management
•Cost Estimating
•Cost Budgeting
•Cost Control
Project Scope Management
•Initiation
•Scope Planning
•Scope Definition
•Scope Verification
•Scope Change Control
Project Quality
Management
•Quality Management
•Quality Assurance
Project Time Management
•Activity Definition
•Activity Sequencing
•Activity Duration Estimating
•Schedule Development
•Schedule Control
Project Human Resource
Management
•OrganiztionalPlanning
•Staff Acquisition
•Team Development
•Quality Control
Project Communications
Management
•Communications Planning
•Information Distribution
•Performance Reporting
•Administrative Closure
Project Risk Management
•Risk Identification
•Risk Quantification
•Risk Response Development
•Risk Response Control
Project Procurement
Management
•Procurement Planning
•Solicitation Planning
•Solicitation
•Source Selection
•Contract Administration
•Contract Close-out
management, external price changes, environmentalist and/or community or
political difficulties, geotechnical problems, weather, and labour problems8. Few if
any of these factors are even today addressed in much of the project
management literature. Much of the PMBOK® material is helpful in managing
projects, but is not sufficient to managing them successfully (and may not always
even be necessary9). This should be no surprise: focussing on execution alone,
without due consideration to context and strategy, will invariably lead either to
inappropriately selected objectives or inoptimal strategies for accomplishing
them. History is littered with examples.
It was this insight that led to the enlarged view of project management that led to
the term ‘the management of projects’ as a broader way of representing the
discipline: managing projects within their business or social context [Morris,
1987, 1997]: managing them to achieve business success: managing – or at
least influencing – the project’s environment, or context, that can so affect
outcome success, as well as the intra-project processes and practices of
definition and delivery. And it was this broader view of the domain of project
management that informed the research at UMIST undertaken in developing the
4th edition of the Association for Project Management’s Body of Knowledge in
8
Other research of the time produced similar findings [Lim et al., 1998; Pinto & Slevin, 1988,
1989]. NAO and GAO reports on government procurement projects illustrate a similar pattern
[GAO; NAO]. The research needs updating however.
9
For example, many do not like the section on ‘Quality’; others do not deploy ‘Procurement’.
Peter Morris
Page 7
16/01/2004
ICE James Forrest Lecture
1998-99 [Dixon, 2000; Morris, 2001,a]. The APM’s view of project management
(Figure 3) is thus considerably broader than PMI’s [Morris, 2001a]. (Figure 4
compares the PMBOK® and APM BOK)
Figure 3: The APM BOK (4th Edition)
1.0 G en eral:
1.3 Portfolio Man agem ent:
1.4 Project C onte xt:
1.1 Project Mana gem ent
1.2 Program m e M anagem ent
2.0 Strateg ic
2.1 Project Succ ess C riteria:
2.4 R isk Ma nagem ent:
2.2 Strate g y/ Projec t Manag em ent Plan
:
2.5 Q uality Ma nagem ent:
2.3 Value M anag em ent
2.6 Safety, H ealth & En vironm ent
2.7 Ethics
3.0 C o n tro l:
3.1 W ork C ontent &
Scop e Man agem ent:
3.2 T im e Scheduling/
Ph asing:
3.3 R esource
Ma nagem ent:
3.4 Bu dgeting &
C os t Ma nagem ent:
3.5 C han ge C ontrol:
3.6 Perform ance
Ma nagem ent:
3.7 Inform ation
Ma nagem ent:
Op p o rtu n ity
Id en tificatio n
C oncept/
M arketing
Feasibility/
B id
4.0 T ech n ical
4.1 D es ign, Production
& H and -O ver
Ma nagem ent:
4.2 R equirem ents
Ma nagem ent
4.3 T ec hnology
Ma nagem ent:
4.4 Estim ating:
4.5 Value Engineering:
4.6 Mod elling &
T esting
4.7 C onfiguration
Ma nagem ent:
D esig n &
D ev elo p m en t
D esign,
M odelling
& P rocurem ent
5.0
5.1
5.2
5.3
5.4
5.5
5.6
5.7
C o m m ercia l
6.0 O rg an isatio n al
Business C ase
6.1 Life C ycle D esign &
Marketing & Sales:
Ma nagem ent
F inanc ial
6.1.1 O pportunity
Ma nagem ent:
6.1.2 D esign &
Procurem ent:
D e velopm ent
Bidding:
6.1.3 Pro duction
C ontract Ma nagem ent: 6.1.4 H an d-o ver
Leg al Aw areness
6.1.5 (Post) Project
E valuation R e view
[O & M/ILS ] :
6.2 O rganisation
Structure:
6.3 O rganisational R oles
Pro d u ctio n
H an d -o v er
Tes t,
C om m iss ion,
S tart-up
M ake, B uild
& Test
7.0 Peo p le:
7.1C om m unication:
7.2 T eam w ork:
7.3 Lea dership:
7.4 D ecision Ma king:
7.5 N egotiating &
Influe ncing:
7.6 C onflict
Ma nagem ent
7.7 Project Mana gem ent
C om petenc y
D e velopm ent:
7.8 Personnel
Ma nagem ent:
Po st-Pro ject
Ev alu atio n
O peration & M aintenance /
Integrated Logis tics;
P roject R eview s / Learning
From E xperienc e
Figure 4: Comparison of the PMI and APM BOKs
PMI PMBOK®
1. The Project Management Framework
1. Project Management Framework
4. Project Integration
None
2. Project Management Context
10.3. Performance Reporting
Included in 4. Project Integration Management
None
11. Project Risk Management
8. Project Quality Management
None
5. Project Scope Management
6. Project Time Management
9. Project Human Resource Management
7. Project Cost Management
4. Project Integration Management
10.3. Performance Reporting
Small section in 10.2 Tools and Techniques for
Information Distribution
None
Peter Morris
APM BOK
1. General
10. Project Management
11. Program Management
12. Project Context
20. Project Success Criteria
21. Strategy / Project Management Plan
22. Value Management
23. Risk Management
24. Quality Management
25. Health, Safety & Environment
30. Work Content & Scope Management
31. Time Scheduling/ Phasing
32. Resource Management
33. Budgeting & Cost Management
34. Change Management
35. Earned Value Management
36. Information Management
40. Design, Implementation and Hand-over
Management
Page 8
16/01/2004
ICE James Forrest Lecture
None
7.2 Cost Estimating
None
None
None
None
None
None
None
12. Procurement
None
2. Project Management Context
9.1. Organizational Planning
2. Project Management Context
9.1. Organizational Planning
2. Project Management Context
9.1. Organizational Planning
10. Communications Management
9.3 Team Development
2.4 General Management skills
2.4 General Management skills - Influencing
2.4 General Management skills - Problem
Solving
None
Glossary
41. Requirements Management
42. Estimating
43. Technology Management
44. Value Engineering
45. Modeling and Testing
46. Configuration Management
50. Business Case
51. Marketing & Sales
52. Financial Management
53. Procurement
54. Legal Awareness
60. Life Cycle Design & Management
66. Organization Structure
67. Organization Roles
70. Communication
71. Teamwork
72. Leadership
73. Negotiation
None
75. Personnel Management
None
Not only is this management-of-projects view of project management broader, it
has an almost revolutionary impact on the way one thinks about the relationship
between performance and the project objectives. It is in fact much more closely
aligned with the project sponsors’10, or owners’, perspective. Here the issue is
not so much simply whether the project will be accomplished on time, within
budget, and to scope, but whether the business success – the success in
meeting the project’s key performance indicators (KPIs) – justifies the effort, and
the risk, expended in undertaking the project. Indeed, it could be that the original
baseline targets are no longer relevant: that it is in the sponsor’s business
interests for the project to exceed its baseline cost, schedule or scope targets.
(The idea of improving performance rather than just achieving the initial baseline
targets is now being captured in new ‘Maturity’ models of project management11.)
10
To some, the perspective is closer to that of Program Management or Portfolio Management,
where project priorities are being managed in a sponsor’s business environment. Ericsson, for
example, uses the term ‘the management of projects’ to refer to what is a primarily Program view
in its PROPS project management methodology.
11
The Maturity idea is both simplistic and powerful: dangerous if naïvely used; important in its
implications. The initial idea of Maturity Models arose from work at the Systems Engineering
Institute (SEI) at Carnegie Mellon University in the software industry. SEI proposed that an
organisation’s ability to manage software could be categorised into five levels: the lowest is where
there are no stable practices; then one moves to having repeatable practices; then to defined
practices which can be taught; fourth, these practices are then managed to achieve balanced and
consistent performance; at the final, fifth level, optimum performance is continuously improved
[Paulk et al., 1993; www.sei.cmu.edu]. These ideas are now being adopted and applied in project
management more widely [Hartman, 1998; Fincher & Levin, 1997; www.pmi.org/opm]. The point
Peter Morris
Page 9
16/01/2004
ICE James Forrest Lecture
Establishing these targets at the front-end and managing the evolution of the
project to achieve optimal business success is increasingly a theme of
contemporary project management practice. There is much interest, and work, in
melding traditional project management knowledge, of defining and delivering a
successful outcome as it evolves through the project life cycle, with the
knowledge of the sponsor’s business objectives and operating characteristics.
Not only does this new, broader view take project management further into the
front-end (Concept) – and indeed the back-end (Operations and even
Decommissioning) – of the life cycle. With contemporary moves towards much
more integrated supply chain (partnering, framework contracts, etc.), it brings the
whole project organisation into a more sophisticated view of what successful
project accomplishment means12.
Exciting though such an opening-up of project management might be, it adds
further urgency to the question of what the discipline really comprises. Is the
discipline now becoming so broad that it is still really tenable? Can any one
person understand the features of managing projects at such a strategic breadth,
in so many different situations, so that we can truly expect to discern and
articulate generic best practice for the discipline as a whole? Should the scholar
of the discipline be expected to understand the whole range of its application?
Should the practitioner be expected to be competent in all of its aspects?
If the answer is, in practice, almost certainly ‘not entirely’, then how far do we go?
If the need to understand how to manage projects successfully is genuine – and
there is ample evidence to suggest that it is13 – what are the elements of the
subject? How is it to be codified and learnt? Can we be predictive in the usual
way that knowledge enables us to be?
What is the theory of project management?
Scientific Knowledge and Project Management
Engineering applies knowledge of mathematics and the sciences to develop
ways to use economically the materials and forces of nature for the well-being of
society. Engineering is more than just developing design concepts: it entails also
the efficient realisation of designs. A professional engineer must understand and
really is that at the upper levels project organisations consciously and continually aim to improve
their performance.
12
We can see this trend clearly in much of the attention now in the oil and gas industry. It is also
critical in New Product Development and in Information Systems projects (focussing on
Requirements Management). And in building and civil engineering not only do we see it in
partnering and alliancing (as in retailing or manufacturing facilities), it is also mirrored in BOT,
PFI, etc.
13
UMIST is experiencing a strong rising demand for education in project management. The APM
and PMI continue to grow exceptionally fast: APM grew at between 7 and 15% in the 1990s.
Demand for project management training from commercial consultants continues to grow.
Peter Morris
Page 10
16/01/2004
ICE James Forrest Lecture
apply the basic laws of mathematics, physics, chemistry and other ‘hard’
sciences, and also the ‘soft’ sciences such as economics, sociology and
management, for the planning, designing, management and operation of
engineering works. Some of the laws, particularly the ‘hard science’ ones are
very familiar to us. But what about the softer ones? What indeed are the ‘laws’ of
management? How objective and scientific is our knowledge of project
management?
Comte, the founder of modern sociology, proposed that sciences could be placed
in a natural order in which each science presupposes the less complex sciences
which precede it, but shows its own irreducible laws. For Comte, this order was
mathematics, astronomy, physics, chemistry, the biological sciences, and
sociology. The problem for the later sciences in this sequence is that the number
of variables – the complexity of the issue being treated – increases dramatically
so that it becomes harder to apply the classical means of scientific enquiry.
These are those of acquiring publicly testable knowledge of the world through the
processes of reductionism, repeatability, and refutation. We reduce the
complexity of the world into experiments; these may be validated in that they are
repeatable; and we build knowledge through refutation of our theories [Popper,
1972, a, b].
The challenges in applying the scientific approach to sociology are several.
There are many viewpoints by which the real world can be reduced to
experimental form. Repeatability is often very difficult or even impossible.
Predictions may be extremely tenuous, not least because of the vagaries of
human beings and their propensity to act differently [Popper, 1957].
If sociology has these difficulties, what of management? No one claims there to
be a science of management. There is a branch of management called
‘Management Science’ but this is about the application of scientific method to
management – hypothesis building, modelling, measuring and evaluating, with
the aim of improving the model, and hence the performance of the thing being
modelled. Critical Path Scheduling and Work-Study are examples of
management science applications that help us on a day-to-day basis in the
management of engineering works.
Management can also be aided by science through the applications of
technology (computers, telecommunications); psychological tools
(psychometrics, team building); organisation ‘theory’ (the contingency theory of
organisation structure being correlated with its core tasks and its environment, for
example); etc. Some of the aids and insights into the practice of management
can indeed be reduced to a repeatable and refutable form. But management
itself is far from being a robust body of scientific knowledge, in the way say that
physics or chemistry is, in the sense that there can be reducible, repeatable and
refutable laws of management. Indeed we do not necessarily even have
agreement on what would constitute management.
Peter Morris
Page 11
16/01/2004
ICE James Forrest Lecture
So, the breadth of application of management in general makes any claim to a
general scientific basis particularly difficult. But projects are in many ways quite
specific, structured forms of organisation, and project management is generally
highly ‘goal orientated’ and deterministic. Given the much more restricted
intellectual scope of projects and project management compared with
management in general [sic], might there not be a greater possibility of a theory,
or theories, of project management?
There are certainly examples of project management benefiting from scientific
knowledge. Network scheduling is a classic example. We can model a sequence
of activities and predict when the whole set, the work package, will be complete.
We can even add risk (as of course Polaris did in 1957 with PERT [Sapolsky,
1972; Morris, 1997]) and develop contingencies, using probability theory to
estimate the total contingency that should be put on the overall network.
Goldratt’s Theory of Constraints is an extension of this thinking [Goldratt, 1997,
1999; Dettmer, 1997]. There are sociological, or at any rate organisational,
insights too. Organisation theorists have shown, for example, that projects tend
to meet their baseline targets more frequently if organised on a full project rather
than a matrix or functional basis [Gobeli & Larson, 1987; Might & Fisher, 1985]14.
Significant parts of project management can therefore be developed along
‘theory’ lines with reasonable scientific rigour – if you do this, the result is likely to
be better than if you do not. (We can also identify good/best practice principles –
for example it is helpful to break the project into its component ‘work packages’
(WBS) when planning it – though there is little that is scientific or even theoretical
about such statements. We shall discuss the nature, and importance, of this
knowledge later in this paper.)
So, to what extent can we develop a reliable public knowledge of project
management; and how useful might such knowledge be? Consider first the
history of the application of the systems approach to management. We can see
clearly how over the last 30 to 50 years the hard science approach has
accommodated the needs of the soft sciences in dealing both with the
uncertainties that people bring in predicting outcomes, and in agreeing what
objectively reality is.
The systems approach to the management of projects
Of all the approaches that have consciously sought to bring the rigour of the
scientific method to management, that of ‘systems thinking’ has probably been
14
This is not to say however that projects should always be organised on a full project basis.
Doing so can be expensive on resources and inefficient at the portfolio level. But this comment
itself is an example of the argument. Firstly, care needs to be taken in interpreting any
‘theoretical’ assertion. Second, the comment on resource cost and portfolio optimisation can be
tested using scientific principles [Davis & Lawrence, 1977; McCollum & Sherman, 1991].
Peter Morris
Page 12
16/01/2004
ICE James Forrest Lecture
the widest and arguably the most influential [Boulding, 1956; Checkland, 1999;
Jordan, 1968; Bertalanffy, 1968]. Its impact on project management has been
enormous, and illustrates both the possibilities and the limitations of the scientific
method.
A system may be defined as any entity, conceptual or physical, which consists of
interrelated parts. Systems thinking stems from several routes. Two particularly
strong ones are those:
• from the study of complex organisational entities (systems), as in biology,
economics, sociology and organisation theory where new and important
characteristics emerge the higher the level of analysis – so called emergence
and hierarchy15;
• from engineering, particularly from work to do with control and communication
(cybernetics).
It is understanding the way that systems behave – particularly ‘open’ ones (those
that purposefully interact with their ‘environment’ as opposed to ‘closed’ ones,
those that do not) – which has led to several revealing insights into the way
systems organise and manage themselves (for example, the importance of
feedback [Ashby, 1956; Beer, 1972], differentiation [Katz & Kahn, 1966] and
boundary management [Miller & Rice, 1967]).
We can see the impact of systems thinking on project management both in ‘hard’
systems engineering and decision analysis ways (Systems Engineering and
Systems Analysis), and in ‘softer’ areas of organisation development and
organisational learning.
In organisation theory, for example, the systems approach underlies the work of
the ‘socio-technic’ school based at the Tavistock Institute in London, many of
whose ideas can be – and have been [Morris, 1988; Walker, 1984] – imported
directly into our thinking of project management16. (The work of Lawrence &
Lorsch on the role of the integrator – widely perceived, along with Galbraith’s
work on types of integrating mechanisms [Galbraith, 1970, 1977] – to be an
important theoretical explanation of the role of the project manager – uses the
15
As for example one moves from studying lower organisisms, through animals, to man, then on
to socio-cultural systems [Boulding, 1956].
16
Examples include:
• contingency theory of organisation design (one of the most important of schools of
organisation theory)16 which shows how organisations need to reflect the needs of their
technical work and their environment in meeting their goals [Emery 1969; & Trist, 1965];
• the characteristics of system boundaries, and of interfaces (abutting boundaries) and their
management [Miller & Rice, 1967]
• the contrasting of ‘mechanistic’ and ‘organistic’ systems – the latter being more appropriate to
programmable type production, the former to more creative work (like front-end design)
[Burns & Stalker, 1961].
Many will also remember the work of Higgin and Jessop on communications in the construction
industry in the 1960s [Higgin & Jessop, 1965; Tavistock, 1966].
Peter Morris
Page 13
16/01/2004
ICE James Forrest Lecture
same paradigm, though without explicitly using Tavistock’s systems framework
[Lawrence & Lorsch, 1967, a, b].)
The ‘hard systems’ approach is essentially an engineering one about how to
perceive, design, evaluate and implement a system to meet a defined need [Hall,
1962]. It is highly congruent with the ‘execution’ view of project management – or
the ‘closed’ project world of Apollo etc. Its influence on the formulation of modern
project management terms, practices and approaches has been seminal, as we
saw earlier, not just because of what NASA, the USAF and USN did with it, but in
that it was then so heavily promoted by Robert McNamara at the Department of
Defense, along with the management science type decision support tools that
McNamara brought with him from Ford17. By the mid 60s, the (hard and decision
support) systems approach had given rise to almost the entire vocabulary of
modern project management [Morris, 1997]18.
The interesting point however is that, as we have seen, the ‘execution’ view of
project management is increasingly being recognised as not being the full view,
and not always even the appropriate view, of the discipline. At the front end of
project definition, for example, we often have quite messy, poorly structured
situations, where objectives are not clear, where different constituencies have
conflicting aims, and where the way forward requires vision and leadership as
well as hard analysis and design. Not only this, but the organisational context
within which projects are conceived and delivered is increasingly decentralised
and fluid (‘transformational’ [Banner and Gagné, 1995]). While the hard,
engineering driven approach to systems management previously advocated for
project management [Johnson, Kast, and Rosenzweig, 1963; Cleland & King,
1968; Forsberg et al., 1996 ], is still generally appropriate, we need to augment it
with a subtler, more emergent view for these fuzzier aspects of projects and their
management.
Soft Systems Methodology (SSM) was developed for such situations. SSM
actually grew out of the frustration of trying to model the management of the
Concorde project within the shifting political context of de Gaulle and Britain’s
application to join the Common Market [Checkland, 1999]. SSM builds and trials
– tests – a number of potential models of ‘purposeful activity’ that appear relevant
to making progress in a given situation. The testing is iterative. In essence SSM
becomes a learning system19.
17
The failure of the hard systems approach in the Vietnam theatre illustrates the point that is
going to be made shortly regarding the limits of the Hard Systems approach in less determinate
situations.
18
Examples include Work Breakdown Structures, interface management, configuration
management, Value Engineering and Value Management, Earned Value and Performance
Management, PPBS (Program Planning & Budgeting System), Integrated Logistics Support,
Reliability Management (and the other –‘ilities’: maintainability, operability, etc.), and so on.
19
In projects, the trick is to conduct this testing and learning within a timeframe that fits with the
expectations of the sponsor and other stakeholders. There is not much direct evidence of the
Peter Morris
Page 14
16/01/2004
ICE James Forrest Lecture
Senge and his colleagues have built on these insights but added greatly, not
least by recognising the active role that people play, particularly in generating
vision[s] of the way forward (the emergent system). Senge is concerned with how
organisations build effective long-term change. Organisational learning is the
only viable, self-sustaining means of achieving this, he believes. Senge uses five
‘disciplines’ for conceiving and effecting sustainable change: personal mastery,
mental models, building shared vision, team based learning, and systems
thinking. Systems thinking is the ‘Fifth Discipline’: the integrator of the other four
disciplines [Senge, 1990].
What both Senge and the Soft Systems school insist upon is that where the
system is not yet well defined, perceptual tools can be employed to help elicit
viable visions and build consensus. The organisational psychologist, Karl Weick,
had already argued that we tend not to construct reality out of theory but out of
experience: much of ‘organisational realities’ have a subjective origin [Weick,
1969]20. Senge goes further, using Argyris’ insights to show how teams, and
leaders21, can shape and add to a vision and powerfully create the means for its
realisation [Senge et al., 1999; Argyris, 1985]. (A practice that is increasingly
familiar in the way that behavioural expectations and performance targets are set
in alliance and partnering based projects [Browne, 1997].)
It is not that there is no place for hard systems and management science type
tools at the front-end of projects – far from it – but that care needs to be taken in
these early, fuzzier stages in developing visions and models of the project.
Iteration is probably necessary. There is a need for inclusivity. The project
manager needs to use these ‘softer’ tools, but do so within a ‘hard’ framework of
decision point milestones, integration with corporate plans, requirements capture,
modelling (financial, engineering, supply chain, scheduling, etc.), benchmarking,
and value optimisation (Value Management), and so forth.
This broader view of project management, then, is creating a broader systems
approach to project management. In doing so it is making Comte’s point that
sociology (and management) can never generate the same reducible,
repeatable, and refutable public knowledge as the ‘hard’ sciences can. The role
of people in management puts limits on our ability to develop predictable
outcomes. And, to some extent at least, we see the managerial world, and shape
our perception of it, through mental models.
Project management, like management itself, is thus not a science, in the full or
proper sense of the word. Our knowledge will always be, to some extent at least,
application of SSM in the management of projects to date though research by UMIST with a
leading energy company is exploring its applicability.
20
Senge notes how leaders shape perception and helps create motivation and commitment.
(Leadership is not restricted: there doesn’t need to be just one leader on a project/ organisation.)
Peter Morris
Page 15
16/01/2004
ICE James Forrest Lecture
personal and experiential. The best we can do is to offer guidance in the form of
tools, aids, heuristics, approaches, insights – and some scientifically objective
theory.
How useful then is our knowledge to the practice of project management? What
role does knowledge have in the discipline?
Knowledge and the theory, and practice, of project management
Knowledge Management is a vogue subject22. Spurred significantly by the need
to ‘continuously improve’ it is increasingly being recognised as an important
though often under-managed organisational asset [Davenport & Prusack, 1998].
Once said, this seems obvious.
But what is knowledge? How does it differ from information? Work we have been
doing at UMIST on the use of IT in knowledge management in construction – the
KLICON project [Morris et al., 2001] – has shown the difficulty of pinning down
such a ubiquitous and slippery concept.
Information is data interpreted in a given context; knowledge is the cognitive
ability to generate insight based on information and data. In practice the
distinction between information and knowledge is a lot less clear than that
between both of these and data23. For what is information to one person may be
knowledge to another; and what was knowledge in one context may only be
information in another. It is a common mistake to assume that one understands
the context when in fact one doesn’t properly, and thus what was taken to be
predictive knowledge in fact is not.
Knowledge is tacit as well as explicit [Polyani, 1966; Nonaka and Takeuchi,
1995]. Tacit knowledge is personal knowledge embedded in individual
experience; it involves intangible factors such as personal belief, perspectives,
and values. Explicit knowledge is 'readily available'; it can be codified and
structured in a way that makes the knowledge easily transmissible. Much that is
really useful in project knowledge however is in people’s heads: it is tacit. Many
argue that its value diminishes substantially when it is ‘downloaded’ and made
explicit.
22
Research at UMIST however shows that it is still in its early days in construction. Of 10 leading
construction companies recently surveyed only two had any really developed form of knowledge
management system, though all were beginning to create one.
23
KLICON distinguished between data, information and knowledge as follows.
• Data is un-interpreted material on which a decision may be based.
• Information is data interpreted in a given context. Different information may be gleaned from
a single data source if the context is different.
• Knowledge is a body of information, coupled with the understanding and reasoning about
why it is correct. Knowledge is thus the cognitive ability to generate insight based on
information and data.
Peter Morris
Page 16
16/01/2004
ICE James Forrest Lecture
Scientific knowledge – publicly refutable knowledge [Popper, 1972b] – is explicit
knowledge. Tacit knowledge is private knowledge; private knowledge, by
definition, is not scientifically testable. (For scientific knowledge is public
knowledge.) Much of what is valuable knowledge about management, and
project management, is thus inherently not scientific, unless and until it becomes
explicit and can be addressed according to scientific practice.
Schon has examined the way that managers, and particularly professionals,
develop knowledge and learn. If there is no authority figure to turn to then,
according to Schon, professionals work in continuous cycles of hypothesis
development, action, and reflection. (The classic scientific approach to
knowledge generation [Popper, 1972a].) Schon calls this “reflection in action”
[Schon, 1983]. The point is that managers, like other professionals, learn through
practice [Drucker, 1974].
The insight is telling. In management, formal knowledge – ‘authority’ – is
important but is not the only means of learning. In practice-orientated jobs or
domains, most people learn most effectively by doing (particularly when they get
into their twenties and beyond), though off a base of more formal knowledge.
Weick’s point comes in again: in organisations people create their version of
reality often more out of experience than from theory [Weick, 1969]24. There are
thus limits to how far scientifically objective knowledge can illuminate our
understanding of how to manage.
Most professional, or ‘competency-based’, jobs, like management, or
engineering, recognise in fact that to be competent one needs a mixture of
appropriate formal knowledge, skills and behaviours. And this is the route that
the project management societies such as PMI, APM, AIPM and IPMA25 have
gone down in establishing project management certification schemes. (It is
analogous of course to the engineering institutions’ qualifications structures.)
There are many who will always question the effectiveness of certification
programs in assuring competency, particularly where, as we have seen, so much
of valuable knowledge is not likely to be explicit. Indeed, the ‘Bodies of
Knowledge’ produced by PMI, APM and IPMA (AIPM uses PMI’s PMBOK®) are
in reality no more than frameworks outlining the ‘knowledge areas’ that the
associations believe project management practitioners should be knowledgeable
in. They are ‘guides’ to other knowledge, be that knowledge in books, or out in
the larger world of experience.
24
‘Externalism’ is a view in contemporary philosophy that is analogous. It proposes that mental
states depend on their environment; that minds hook on to the world and cannot be thought of as
confined to our brains. Knowledge is seen as a special kind of mental state, dependant on our
relationship with the external world [Williamson, 2001].
25
AIPM is the Australian Institute of Project Management. IPMA is the International Project
Management Association, a federal association comprising the various national project
management societies.
Peter Morris
Page 17
16/01/2004
ICE James Forrest Lecture
Competency is generally defined as the ability to perform in an effective and
consistent manner. As one of the components of project management
competence, knowledge should be important. But is there any evidence that
having formal project management knowledge helps managers to perform
effectively? Many believe so [Crawford, 2001]. But is there any objective
evidence that formal project management knowledge correlates with the ability to
manage projects better? Hardly any in fact. (Though the professional societies
believe that their examinations of experience, where this happens, does test
accomplishment.)
What many practitioners are now looking for, particularly those charged with
developing project management competencies within companies, is at least
some evidence to show that the application of formal project management
knowledge and practices produces better project outcomes. The current data on
this is only slight [Pinto & Slevin, 1988, 1989; Morris, 1987, 2001a; Ibbs & Kwak,
1997; Crawford, 2001]. There is none yet that demonstrates a causal relationship
between the application of formal project management and project outcomes26.
Conclusion
Is there then a discipline of project management? What part does knowledge
play in the discipline? Is there a theory?
There is a discipline in the sense that:
• there is a substantial, and in places significant, literature on it;
• there are defined ‘Bodies of Knowledge’ on it (and there are also many
dozens of universities that research and teach it);
• there are many people who believe that they practice it;
• there are professional societies who promote it and who examine and qualify
people in it.
Knowledge, both explicit and tacit, is central to our understanding of this
discipline. We know the characteristics of projects and project management
(pretty well); we have some general lessons on what kinds of actions lead to
projects having successful outcomes; we know what tools are helpful in the
management of projects.
Projects vary hugely however, and so do people’s roles on them. The overall
scope of the discipline is thus quite dauntingly large, particularly if trying to
understand how ‘Best Practice’ should be best applied – that is, ‘Best
Appropriate Practice’.
26
Some research is underway, though not enough. The University of California at Berkeley and
UMIST, together with INDECO, are collaborating on a study of “the Return on Investment of
project management” sponsored by PMI [www.berkeley.edu/pmroi]
Peter Morris
Page 18
16/01/2004
ICE James Forrest Lecture
So, is there a theory of project management? No: as we have seen, there cannot
be a single theory: project management, like management itself, is too broad a
subject for there to be a single theory. Indeed, even the hard scientific subjects
do not have a single theory. They have theories of particular things – the laws of
Newton, Faraday and Einstein for example – but not one overall theory.
Project management, like management itself, is similar: some areas are
susceptible to the methods of scientific enquiry to generate testable ‘public
knowledge’; some are much less so and will always have a large element of
unpredictability.
Not, then, a theory of project management – indeed the very notion is mistaken –
but some theories. And knowledge, both tacit and explicit, of Best Appropriate
Practice that, if applied, should lead to improved chances of successful project
outcomes.
References
Archibald, R, Managing High-Technology Programs and Projects, Wiley, 1997.
Argyris, C, Strategy, Change, and Defensive Routines, Pitman, 1985
Ashby, W R, An Introduction to Cybernetics, Chapman & Hall, 1956
Baker, N R, Green, S G, & Bean, A S, “Why R&D projects succeed or fail”
Research Management Nov-Dec 1986, pp. 29-34.
Baker N R, Murphy, D C, & Fisher, D, Determinants of Project Success, National
Technical Information Services N-74-30392, 1974 – see also “Factors affecting
Project Success” in Project Management Handbook Cleland, D I and King, W R
(eds.), Van Nostrand Reinhold 1988.
Banner, D K, & Gagné, T E, Designing Effective Organizations, Sage, 1995.
Beer, S, The Brain of the Firm, Allen Lane Press, 1972.
Bertalanffy, L von, General Systems Theory, Braziller, 1968.
Boulding, K E, “General Systems Theory – the outline of a discipline”
Management Science,Vol.2(3), 1956.
British Standards Institute, A Guide to Project Management, BS: 6079, 1996.
Browne, J “Unleashing the Power of Learning”, Harvard Business Review,
September-October, 1997
Burns, T, & Stalker, G M, The Management of Innovation, Tavistock, 1961
Checkland, P, Systems Thinking, Systems Practice, Wiley, 1999.
Cleland, D I & King, W R, Systems analysis and project management, McGrawHill, 1968
Cooper, R G, Winning at New Products, Addison Wesley, 1993.
Crawford, L, Profiling the Competent Project Manager in Project Management
Research at the turn of the Millennium, Slevin, DP, Cleland, D I, & Pinto J K,
(eds.) Proceedings of PMI Research Conference 2000, Project Management
Institute, 2001
Davenport, T H, & Prusack, L, Working Knowledge, Harvard Business School
Press, 1998.
Peter Morris
Page 19
16/01/2004
ICE James Forrest Lecture
Davis, S M, & Lawrence, P R, Matrix organizations, Addison Wesley, 1977
Dettmer, W H, Goldratt’s Theory of Constraints: A Systems Approach to
Continuous Improvement, ASQ Quality Press, 1997
Dixon, M (ed.), Project Management Body of Knowledge, 4th Edition, Association
for Project Management, 2000.
Drucker, P, Management, Heinemann, 1974.
Emery, F E, Systems Thinking, Penguin, 1969.
Emery, F E & Trist, E L, “The Causal Texture of Organizational Environments”
Human Relations Vol. 18(1) 1965, pp. 21-32; reprinted in Emery, F E, Systems
Thinking, Penguin, 1969.
Fincher, A & Levin, G “Project Management Maturity Model” Proceedings of the
28th Annual Project Management Institute 1997 Seminars & Symposium, Project
Management Institute, 1997.
Forsberg, K, Mooz, H, & Cotterman, H, Visualizing Project Management, Wiley,
1996.
Galbraith, J R, Environmental and technological determinants of organizational
design in Lorsch, JR, & Lawrence PR, Studies in organization design IrwinDorsey, 1970.
Galbraith, J R, Organization Design, Addison-Wesley, 1977
General Accounting Office: various reports on US defense projects’ performance.
Gobeli, D, & Larson, E W, “Relative Effectiveness of Different Project Structures”,
Project Management Journal, 18(2), pp. 81-85, 1987.
Goldratt, E, Critical Chain, North River Press, 1997
Goldratt, E, Theory of Constraints, North River Press, 1999
Hall, A D, A Methodology for Systems Engineering, van Norstrand, 1962.
Hartmann, F R, “Absolute performance – a Maturity Model for Projects” Project
Management, Vol. 4(1), 1998
Higgon, G, & Jessop, N, Communications in the Building Industry, Tavistock,
1965.
Horwitch, M, Clipped Wings: the American SST. MIT Press, 1982.
Hunt, A, “Perfect Ingredients for Paris Conference”, Project Management Today,
October, p.26, 1996.
Ibbs, C W, & Kwak, Y-H, The benefits of project management – financial and
organizational rewards to corporations, Project Management Institute, 1997.
Institution of Civil Engineers and Faculty and Institute of Actuaries RAMP: Risk
Analysis and Management for Projects Thomas Telford, 1998
Kerzner, H, Project Management: A Systems Approach to Planning, Scheduling
and Controlling, Van Norstrand Rheinhold, 1997.
Johnson, R A, Kast, F E, and Rosenzweig, J E, The Theory and Management of
Systems, McGraw Hill, 1963.
Jordan, N, Themes in Speculative Psychology, Tavistock, 1968.
Katz, D, & Kahn, R L, The Social Psychology of Organizations, Wiley, 1966
Lawrence, P R & Lorsch, J R, Organization and environment: managing
differentiation and integration, Harvard University Press, 1967[a].
Lawrence, P R & Lorsch, J R, “The new management job: the integrator” Harvard
Business Review 1967[b].
Peter Morris
Page 20
16/01/2004
ICE James Forrest Lecture
Lim, C S, and Mohamed, M Z, “Criteria of project success: an exploratory reexamination” International Journal of Project Management 16(4), 1998, pp. 243248.
Locke, D, The Gower Handbook of Project Management, Gower, 2001.
McCollum, J K & Sherman, J D, “The role effects of matrix organization size and
number of project assignments on performance”, IEEE Transactions on
Engineering Management, EM-32 (2), 1991
Meredith, J R, & Mantel, S J, Project Management: A Managerial Approach,
Wiley, 1995.
Might, R J, & Fischer, W A, “The role of structural factors in determining project
management success, IEEE Transactions on Engineering Management, EM-32
(2) 1985, pp. 71-77.
Miller, E J, Task and Organisation, Wiley, 1976.
Miller, E J, & Rice, A K, Systems of Organization. The control of task and
sentient boundaries. Tavistock, 1967
Morris P W G Managing project interfaces – key points for project success in
Project Management Handbook, Cleland, D I, and King, W R, (eds.) Van
Nostrand Reinhold, 1988, pp. 16-55.
Morris, P W G, & Hough, G H, The Anatomy of Major Projects, Wiley, 1987.
Morris, P W G, The Management of Projects, Thomas Telford, London, 1997.
Morris, P W G “Updating the project management Bodies of Knowledge” Project
Management Journal Vol 32(3), Sept 2001 [a].
Morris, P W G Research trends in the 1990s and the need to focus on the
business benefit of project management in Project Management Research at the
turn of the Millennium Proceedings of PMI Research Conference 2000, Slevin,
DP, Cleland, D I, & Pinto J K, (eds.) Project Management Institute, 2001. [b]
Morris, P W G, Deason, P M, Ehal, T M S, Milburn, R, and Patel, M B “The Role
of IT in Capturing and Managing Knowledge in Designer and Contractor
Briefing”, International Journal of Computer Integrated Design and Construction,
forthcoming, 2001.
National Audit Office: various reports on UK defence projects’ performance
Nonaka, I & Takeuchi, H, The Knowledge-Creating Company, Oxford University
Press, 1995.
Paulk, M, Curtis, B, Chrissis, M, Weber, C, Capability Maturity Model for
Software (Version 1.1), CMU/SEI-93-TR-024 ADA263403, Systems Engineering
Institute, Carnegie Mellon University, 1993.
Pinto, J K, & Slevin, D P, “Project success: definitions and measurement
techniques” Project Management Journal 19(1) 1989, pp. 67- 75.
Pinto, J K, & Slevin, D P, “Critical success factors across the project life cycle,”
Project Management Journal, 19 (3), 1988, pp.67 – 75.
Project Management Institute, Guide to the Project Management Body of
Knowledge, Project Management Institute, 2000.
Project Management Institute, Measuring Success, Proceedings of the 1986
Project Management Institute Seminar/Symposium, Montreal, Project
Management Institute, 1986.
Polanyi, M, The Tacit Dimension. Routledge & Kegan Paul, 1966.
Peter Morris
Page 21
16/01/2004
ICE James Forrest Lecture
Popper, K R, The Poverty of Historicism, Routledge and Kegan Paul, 1957.
Popper, K R, Conjectures and Refutations, The Growth of Scientific Knowledge
Routledge and Kegan Paul, 1972 [a].
Popper, K R, Objective Knowledge, Oxford, 1972 [b].
Sapolsky, H, The Polaris system development: bureaucratic and programmatic
success in government, Harvard University Press, 1972
Sayles, L R & Chandler, M K Managing large systems: organizations for the
future, Harper & Rowe, 1971.
Schon, D, The Reflective Practitioner: How Professionals Think in Action, Basic
Books, 1983.
Senge, P M, The Fifth Discipline, Doubleday, 1990.
Senge, P M, Kleiner, A, Roberts, C, Ross, R, Roth, G, & Smith, B, The Dance of
Change, Doubleday/Currency, 1999.
Slevin, DP, Cleland, D I, & Pinto J K, (eds.), Project Management Research at
the turn of the Millennium Proceedings of PMI Research Conference 2000,
Project Management Institute, 2001
The Tavistock Institute Interdependence and Uncertainty, Tavistock, 1966
Walker, A, Project Management in Construction, Granada, 1984
Weick, K E, The Social Psychology of Organizing, Addison-Wesley, 1969.
Williamson, T, Knowledge and its Limits, Oxford University Press, 2001
World Bank Operations Evaluation Department: various reports on World Bank
project performance.
Peter Morris
Page 22
16/01/2004