Jan 16, 2004 - ICE James Forrest Lecture. âScience, objective knowledge, and the theory of project managementâ. Peter W.G. Morris. Professor of Project ...
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
