MARTIN 1 Dikompresi

H. Reschke· H. Schelle (Eds.
Dimensions of
Project Management
Fundamentals, Techniques,
Organization, Applications
Publication in Honour of Roland W Gutsch
Springer-Verlag
Berlin Heidelberg NewYork
London Paris Tokyo Hong Kong Barcelona
Prof. Dr. Hasso Reschke
Professor of Business Administration
Fachhochschule Munich
Prof. Dr. Heinz Schelle
Professor of Business Administration and Project Management
University of the German Federal Armed Forces, Munich
ISB'i 978-3-540-53157-9 ISB'i 978-3-642-49344-7 (eBook)

DOl 10.10071978-3-642-49344-7
This work is subject to copyright. All rights are reserved, whether the whole or part of the material is
concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broad-
casting, reproduction on microfilms or in other ways, and storage in data banks. Duplication of this
publication or parts thereof is only permitted under the provisions of the German Copyright Law of
September 9, 1965, in its current version and a copyright fee must always be paid. Violations fall under
the prosecution act of the German Copyright Law.
© Springer-Verlag Berlin, Heidelberg 1990
The use of registered names, trademarks, etc. in this publiclation does not imply, even in the absence of
a specific statement, that such names are exempt from the relevant protective laws and regulations and
therefore free for general use.
2362/3020:-543210 - Printed on acid-free paper

FOREWORD
The project "publication in honour of Roland W. Gutsch" has been completed. It was a truly
international project to which 29 authors from 16 countries have contributed. We hope to have
reached the goal of the project: to publish a book covering the whole spectrum of project management
and giving a general account of the present state of the art.
We would like to express our gratitude to all colleagues and friends of Roland W. Gutsch and the
representatives of the Internet-Societies who have made a contribution in spite of their workload.
Many thanks go to the publisher, Springer-Verlag, for their cooperation and obligingness, and to the
Gesellschaft flir Projektmanagement for sponsoring the project. Last but not least we would like to
thank Michael Flirnrohr and Angelika Novy for doing the tedious processing and proof reading.
Our hope is that this volume brings about a small contribution to the promotion of the idea of project
management and joy to Roland W. Gutsch celebrating his jubilee.
Munich, August 1990 Hasso Reschke Heinz Schelle

Roland W. Gutsch
DEDICATED TO ROLAND W. GUTSCH
This book is dedicated to Roland W.Gutsch on the occasion of his 65th birthday. As the founder and
long-time leader of the International Project Management Association he has made a great impact on
project management in Germany, Europe and all over the world.
Roland W.Gutsch was born in 1925 in Karlsruhe/West Germany as son of a physician. His education
was influenced by the 2nd World War in which he had to take an active part suffering severe wounds.
After the war he studied business administration and started his industry career in 1950 what was then
the beginning of the reconstruction of Germany.
His entry to Dornier, a major aerospace enterprise in Germany, was very important. There he began
his intensive occupation with project management, at that time primarily with network technique. A
method which was developed under his leadership is still being used today.
He was internationally oriented in the same way as his enterprise. In 1965, he brought together in
Vienna a group of interested people from Europe and from the USA, who were experts in project
management, at that time an almost unknown field. It is a special merit of Roland W. Gutsch that he
recognized the international dimension of project management and the idea of a boundless community
of interests and experiences, which led to the formation of INTERNET.
To develop understanding over linguistic and cultural boundaries, to respect and cultivate the
specialities and to integrate them into a common concept - that was the task he took up. Out pf the
loose circle of individuals, this led to the first INTERNET - WORLD CONGRESS for project
management in Vienna in 1967, which brought togetherere about 400 specialists from allover the
world.
Roland W. Gutsch nurtured the project management idea like a living plant from the time it was
identified only with network technique and aerospace and military uses to the point were it was
recognized as an internationally used management discipline. INTERNET, as an international
organisation of national project management groups realized under his leadership international
congresses for project management, seminars for specialists, exchange of expert knowledge and
technical literature. It was always important for Roland W. Gutsch to bring together people from
various branches, various projects and various cultures. His concern was to emphasize the common
interest without suppressing the individual. One summit of his creativity was the 6th INTERNET
World Congress for project management in Garmisch/West Germany in 1979 which was preceded by
a preparatory seminar for 25 participants from the Third World. The congress itself became essential
for the further development of project management: No more network technique but the management
of projects, the interdisciplinary character of the project-work, became very important. Project
management grew out of planning techniques into the dimensions of business action. This trend was
the essential basis for the following enormous progress of project management. For Germany 1979
was also a decisive year: The German Project Management Society (GPM) was founded and Roland
W. Gutsch was its first president.
The connections with the American PMI (Project Management Institute) led in 1981 to the flfStjoint
INTERNET/PMI meeting in Boston, Mass., USA. It was the beginning of a close transatlantic
cooperation.
Besides the integration of the developing countries, a special concern of Roland W. Gutsch was the
development of the relations with the countries of Eastern Europe. That was at a time when one did
not even dare to dream of the political developments at the end of the 80's. The farsightedness and
persistence he had at that time show their results today.
As we celebrate the 65th birthday of Roland W. Gutsch, we do not only think about his extraordinary
achievements for the structure and the further development of project management - nationally and
internationally - we also appreciate the extraordinary personality of this man. With never-ending
power and energy, idealist and realist at the same time, always his aim ahead, always engaging in
contact with friends and partners - and with opponents, he understood the need for relating friends
from many nations. This relation was the basis for many voluntarily initiated and realized projects. It
was the necessary basis to make project management a topic of international interest.
Many of his national and international friends, companions right from the beginning and those who
joined in the course of time, spontaneously agreed when we asked them to contribute to this
international book project. In this way we want to honour Roland W. Gutsch and express o~ thanks
for the manifold ideas and impulses, for many good discussions, for his worldwide relations of which
we all are part and which we all share with him.
We wish Roland W. Gutsch a long creative power and many more joint contacts and projects between
us. Together we want to continue to build project management.
In the name of all congratulators, the Editors
VIII
DET AILED CONTENTS
FUNDAMENTALS OF PROJECT MANAGEMENT
THE FUNDAMENTALS OF PROJECT MANAGEMENT

Martin Barnes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction.................................................. 3
2. A Definition of Project Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Basic Propositions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. But What Does a Project Manager Actually Do? . . . . . . . . . . . . . . . . . . . . . . ..... 5
5. How to Finish on Time Within Budget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6
6. Project Managers Ned Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Keep Changing the Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
8. How to Make the Right Decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Allowing for Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Leadership and Delegation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
CHANGE AND USEFULNESS OF PROJECT MANAGEMENT

Hans Knopfel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2. Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , .. 14
3. Priorities................................................... 16
4. Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
5. Usefulness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Associations................................................. 21
7. Conclusion................................................. .22
PROJECT MANAGEMENT PARADIGM" A SYSTEM ORIENTED MODEL OF PROJECT

MANAGEMENT
Gerold Patzak. . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction: Why Structuring Project Management? . .. . . . . . . . . . . . . . . . . . . . . 25
2. The System Approach to Project Management. . . . . . .. .. . . . . . . . . . . . . . . . . . 26
3. Why Is the Acting System "Project Organization" Working? . . . . . . . . . . . . . . . . . . 28
4. How Is the Acting System "Project Organization" Working? . . . . . . . . . . . . . . . . . . 29
5. How Is the Project Process Measured? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Who/What is Doing the Project Process? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7. Project Management Phases. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .33
8. Construction of a Model of Project Management. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9. Framework of Project Management Knowledge. . . . . . . . . . . . . . . . . . . . . . . . . . . .35
PROJECT MANAGEMENT WITHIN THE SYSTEMS CONTEXT

Ivars Avots ..................................................... 39
1. The Shortcomings of PMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .... .39
2. The Systems Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
3. An actual case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
4. COnclusion..................................................48
MANAGING THE PROJECT ENVIRONMENT

R. Max Wideman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
1. Introduction................................................. 51
2. What is the Project Environment? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3. Dimensions for the Project Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.1 The Project Time Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
3.2 The Internal Project Culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
3.3 The COIpOrate Culture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4 The Project's External Surroundings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5 Some Practical Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
THE CULTURAL DIMENSION OF PROJECT MANAGEMENT

Eric Gabriel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction................................................. 71
1.1 Systems to Persons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
1.2 Recognition of Cultural Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .'. . . . 72
1.3 National Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2. Attitude to Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3. Organisational Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4. Small is Manageable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5. The Myth of the Developing Country . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6. Future Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
THE VIKING APPROACH TO PROJECT MANAGEMENT

Morten Fangel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
1. Introduction................................................. 79
2. The Viking Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3. The Nordic Approach Today. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4. Trends in the Nordic Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
x
PROJECT MANAGEMENT AND CORPORATE STRATEGY
Hasso Reschke. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
1. Introduction................................................. 85
2. Interrelations between Corporate Strategy and Project Management. . . . . . . . . . . . . . . . 86
2.1 Strategy Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.2 Projects as Strategy Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.3 Management by Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
3. The Impact of Corporate Strategy on Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
PROJECT MANAGEMENT TECHNIQUES

AND PM-SOFfW ARE
PROJECT OBJECTIVES IDENTIFICATION AND PROPER FORMULATION FOR

PROJECT SUCCESS
Riccardo Albonetti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
1. General.................................................... 93
2. Explicit Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3. Implicit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4. Instrumental Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5. Internal and External Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6. Project Objectives and Company's Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7. Objectives and Programs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
THE EVOLUTION OF MANAGEMENT TOOLS AND THE EFFICIENCY OF PRODUKT

DEVELOPMENT & ENGINEERING
Pieter Jan Blankevoort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 99
1. Introduction................................................. 99
2. Some Efficiency Tools Developed and Tried Out. . . . . . . . . . . . . . . . . . . . . . . . . . 100
3. Probable Reasons for Rejection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4. 'Tools'for Quality Improvement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101
5. Risk Assesment and Contingency Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6. The Development of Institutes, Societies and Associations. . . . . . . . . . . . . . . . . . . . .102
7. The Evolution of the Societies. . . . . . . . . . . . . . . . . . . . . . . . . . . . " . . . . . . . . .1 03
8. Societies Moving to the First Phase of the Product Life-Cycle. . . . . . . . '.' . . . . . . . . .104
9. Resistance to Change 'Habits' ofR.D.&E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
10. The Tree of Development Management and the Product Life-Cycle. . . . . . . . . . . . . . . 106
11. The Estimation of 'COST a Problem of the Future? . . . . . . . . . . . . . . . . . . . . . . . . . 108
XI
OPERATIONS RESEARCH AND PROJECT MANAGEMENT: PAST, PRESENT AND
FUTURE
Heinz Schelle. . . . • . . . . . . . . . . . . . . . . • . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
1. Introduction: Operations Research and Project Management. . . . . . . . . . . . . . . . . . . .111

2. Spread of Operations Research Theories in Project Management Practice. . . . . . . . . ... 112
3. Reasons for the Small Number of OR-method Application to Project Management. . . . . . 113
3.1 Are OR Methods Suited Better for Bulk or Series Production than for Projects? . . . . . . . . 113
3.2 Inadequate Models . • . . . . . . . . . . . . . . . . . . . . . . . • . . . . . . . . . . . . . . . . . . 113
3.3 Little Acquaintance of the Developers with the Real Problem . . . . . . . . . . . . . . . . . . . 113
3.4 Necessary Data are not Available . . . . . . . . . . . . . . . • . . . . . . . . . . . . . . . . . . . .114
3.5 Institutional Conditions are not Taken into Consideration . . . . . . . . . . . . . . . . . . . . . 114
3.6 The Models and Procedures Offered are too Complicated . . . . . . . . . . . . . . . . . . . . . 115
4. Possibilities of a More Intensive Application of Operations Research Methods to Project
Management . . . . . . . . . . . . . . . . . . . . . . • . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.1 The Necessity of More Intensive User Research . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.2 Coopemtion between Software Developers, OR Experts and Users . . . . . . . . . . . . . . . . 116
4.3 New Methodical Approaches are Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
DEVELOPMENT OF METHODS IN PROJECT MANAGEMENT - A SUBJECT FOR

THEORISTS ONLY?
Dietrich Miiller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . '.' . . . . . . . . . . 121
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
2. How Exactly is the Project Process Known in Advance? . . . . . . . . . . . . . . . . . . . . . . 122
3. Which Planned Schedule is Reliable? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4. Resources - Always Scarce in Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.1 Introduction: The (Dis)Interest in Resource Analysis -
an Attemptto Find ounhe Reasons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
4.2 Problems Encountered in Developing Methods for Resource Analysis . . . . . . . . . . . . . . 126
4.3 Resource Analysis as a Subaspect of Production Planning and
Project Planning - a Comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.4 EDP Support for Resource Analysis: The Way to Good Software . . . . . . . . . . . . . . . . . 127
5. Costs and Finances - ofImportance or not? . . . . . . . . . . . . . . . . . . . . . . . . . . "'. . . 128
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.2 Cost Forecasts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.3 Cost Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.4 Cost Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.5 Cost and Progress Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.6 Project Financing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6. Final Commentary and Outlook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
EXPERIENCES FROM A NEW LOGIC IN PROJECT MANAGEMENT

Steen Lichtenberg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
1. Synopsis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
2. Mangement Changes with the World . . . . ", . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
2.1 Project Management is Ancient as Mankind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
2.2 The Present Conventional "Genemtion" of Project Management . . . . . . . . . . . . . . . . . .139
2.3 Today's Conventional Project Management is not Perfect. . . . . . . . . . . . . . . . . . . . . .139
2.4 Alternative Concepts of Project Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
3. Contributions from the Old Cultures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3.1 Old Experiences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3.2 Specific Potentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
XII
4. Management and Project Management Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
4.1 What is Project Management? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
4.2 Mutual Respect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4.3 Differences and Alternatives in PM-Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
5. A New Logic in Planning Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.1 Dominance of Exactness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.2 The Prestige of Detailing in Itself. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144
5.3 Priority to the Easy Matters instead of the Important Ones. . . . . . . . . . . . . . . . . . . . . 145
5.4 Interrelated Areas are Kept Separated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
6. The Succesive Principle: An Example of the New Logic . . . . . . . . . . . . . . . . . . . . . . 147
6.1 The Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
6.2 The Need for a New Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .147
6.3 The Effects of the Basic Principle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .147
6.4 The Basic Procedure (simplified) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7. Experiences and Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8. A Case Story: Integrated Planning and Start-Up Sessions . . . . . . . . . . . . . . . . . . . . . .150
8.1 Basic Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150
8.2 Preparations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
8.3 Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
8.4 Purposes of the Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
8.5 Content of the Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152
8.6 Replanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
THE APPLICATION OF KNOWLEDGE IN PROJECT-MANAGEMENT

Jiirg Brandenberger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
1. The Development of Project-Management and its Application . . . . . . . . . . . . . . . . . . .155
2 Application Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
CONTROL PERSPECTIVES ON PROJECT MANAGEMENT

Per Willy Hetland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
1. From Planning Experts to Project Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

2. The Nature of Project Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
3. Physical Progress and Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
4. Perfonnance Standards and Consistency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
5. The Ultimate Challenge - Project Controllability . . . . . . . . . . . . . . . . . . . . . . . . . . .164
DEVELOPING KNOWLEDGE BASED SYSTEMS IN CONSTRUCTION MANAGEMENT

Adolf Schub. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
1. Preliminary Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

2. Problem Solving Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170
3. Tools for Problem Solving. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 170
4. Expert Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5. Classification and Examples in Construction Management. . . . . . . . . . . . . . . . . . ... 172
5.1 Systems with Pure Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172
5.2 Systems with Pure Numeric. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.3 Hybrid Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
6. Summary and Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
XIII
SPONTANEITY OR PLANNING DEFICITS IN SYSTEMS SELECTION AND
APPLICATION OF PROJECT SOFTWARE
Sebastian Dworatschek . . . . . . . . . . . . . . . . . . . . . • . . . . . . . . . . . . . . . . . . . . . . 183
1. Introduction • . . • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . • . . . . . . . . . . . . . . 183
2. Application of Infonnation Technology • • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
3. Spontaneity and Planning . . . . • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
4. Symptoms of Spontaneity and Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
5. Factors of User Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
6. Project-like Implementations Strategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
MANAGEMENT BY PROJECTS - A TURN AWAY FROM OR TOWARDS HIERARCHY

Wolfgang Schallehn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
1. "Management by Projects" - a Phantastic Idea! . . . . . . . . . . . . . . . . . . . . . . . . . . .. 201

2. "Management by Projects" and HIERARCHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
2.1 What is Speaking for a Hierarchical "Management by Projects"? . . . . . . . . . . . . . . . . . 202
2.2 Problems and Limitations of the Hierarchical Principle. . . . . . . . . . . . . . . . . . . . . . .202
3. The MESA Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
3.1 MESA Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
3.2 MESA Cycles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 207
3.3 Corresponding Horizons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
3.4 Residual Quantities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
3.5 Control by Selection of Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
4. MESA Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
5. MESA and "Management by Projects" in the GDR . . . . . . . . . . . . . . . . . . . . . . . . . 214
PROJECT MANAGEMENT ORGANIZATION

AND HUMAN FACTORS
PROJECT TEAM PLANNING: THE NEED, METHODS AND BENEFITS

Russell D. Archibald . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
1. The Need for Project Team Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219

1.1 Traditional Project Planning Approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
1.2 Weaknesses in the Traditional Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
2. The Project Team Planning Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
2.1 Project Start-Up Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
2.2 Elements of the Team Planning Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
3. An Example of Team Planning in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
3.1 The Planning Deliverables Produced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
3.2 Conduct of the Planning Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
3.3 Results Achieved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... 229
3.4 Hidden Agenda Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
4. Benefits and Limitations of Project Team Planning. . . . . . . . . . . . . . . . . . . . . . . . . 230
4.1 Benefits of Project Team Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
4.2 Limitations of Project Team Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
XIV
TRAINING
David Mathie . . • . • . . . . . . . . . . . • . . . . . . . . . . . . . • . . . . . . . . . . . . . . . . . . . 233
1. Introduction......... • . . . . . . . . • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
2. Why Training is Necessary • . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
3. Training Programme. . . . • . . . . . . . . . • . . • . . . . . . . . . . . . . . . . . . . . ..... 234
4. Training Programme Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..235
MANAGEMENT OF INTERSTED PARTIES

Juhani Silvasti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
1. Introduction........ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
2. Interested Parties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
3. Objectives and Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
4. SWOT-Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
5. Strategy for Managing Interested Parties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
6. Management Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... 244
7. Conclusions................................................ 245
CO-DEVELOPMENT - A FUTURE FOR INTER-ORGANIZATIONAL PRODUCT AND

PROJECT DEVELOPMENT
Alex van den Honert, Rieks Broersma. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..... 247
1. Definition and Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
2. Why Comaking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 248
3. Managing Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
3.2 Phasing................................................. .. 249
3.3 Product Development Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
4. Organisational and Cultural Consequences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
5. Pros and Cons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
6. Trends................................................. '. . .255
7. Concluding Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... 255
THE KEY ROLE OF THE CLIENT OR OWNER IN THE MANAGEMENT OF

CONSTRUCTION PROJECTS
E. Geoffrey Trimble. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
1. Introduction................................................ 257
2. Areas of Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
2.1 Economic Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
2.2 Procurement Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
2.3 Management of Design and Quality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
2.4 Use of New Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
2.5 Control of Cost and Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
2.6 COnstructability.............................................. 260
2.7 Mutual Understanding and Involvement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
3. The European Construction Institute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 260
4. The Way Ahead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
xv
ROLE OF SENIOR MANAGEMENT IN DEVELOPMENTAL PROJECTS
Bob Gillis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
1. Introduction................................................ 265
2. The Steering Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
2.1 When Required. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
2.2 Make Up of the Steering Group. . . . . . . . . . ... . . . . . . . . . . . . . . . . . . . . . . . . .266
3. Planning Tasks of the Steering Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 267
3.1 Define the Owner's Overall Goals (purpose) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
3.2 Identify the Major Constraints and Business Risks. . . . . . . . . . . . . . . . . . . . . . ....268
3.3 Develop the Funding Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268
3.4 Develop the Project Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
3.5 Administration and Control Procedures and Policies. . . . . . . . . . . . . . . . . . . . . . . . 269
4. Implementation Tasks of the Steering Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
4.1 Select the Project Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
4.2 Provide Access to Power and Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
4.3 Monitor the Progress of the Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270
4.4 Monitor the External Environment and the Business Risk. . . . . . . . . . . . . . . . . . . . . 270
4.5 Resolve Major Conflicts and Crises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
5.1 Steering Group Establishes Direction and Control . . . . . . . . . . . . . . . . . . . . . . . . . . 271
5.2 Building Teamwork is Essential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
5.3 Teamwork Requires an Open, Participative Planning Process. . . . . . . . . . . . . . . . . . . 271
5.4 Leadership Style is a Key to Effectiveness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
5.5 Management Preparation Pays Off in Better Results. . . . . . . . . . . . . . . . . . . . . . . . 272
APPLICATION OF PROJECT -MANAGEMENT

IN SELECTED COUNTRIES
PROJECT MANAGEMENT AS PERCEIVED FROM ANCIENT EGYPTIAN PROJECTS

Abdel-Fattah EI-Marashly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
1. The Start of Pyramid Building Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

2. The Great Pyramid "King Khufu's Pyramid" Project - 2650 BC. . . . . . . . . . . . . . . . . .279
3. Setting Methodology for Perceing the Pyramid Project Management . . . . . . . . . . . . . . . 282
3.1 Pyramid Project Building Objectives & Religion Effectiveness . . . . . . . . . . . . . . . . . . 282
3.2 Pyramid Design Complexity & Construction Activities Management. . . . . . . . . . . . . . 283
3.3 Stones Transport Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
3.4 Time & Labour Force Estimate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
PROJECT MANAGEMENT IN CZECHOSLOVAKIA

Vladimira Machova . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
1. Project Management Development in Czechoslovakia . . . . . . . . . . . . . . . . . . . . . . . 291

1.1 Technical Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
1.2 First International Management Congress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
1.3 Czechoslovak Scientific Management Committee. . . . . . . . . . . . . . . . . . . . . . . . .. 295
2. Project Management Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .296
3. Stagnation................................................. 297
4. Training of Managers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
XVI
PROJECT MANAGEMENT IN DEVELOPING COUNTRIES
Abdel-Wahab S. EI-Bishry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
1. Initiation of Idea. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299
2. The Management Engineering Society MES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
3. Differentiation between Project Management and Operation Management. . . . . . . . . . . 303
4. Role of MES Activities in Developing Project Management. . . . . . . . . . . . . . . . . . . . 305
4.1 Education & Training Groups of Engineers in Project Management. . . . . . . . . . . . . . . 305
4.2 National Seminars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306
4.3 International Symposiums. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
4.4 Other Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
5. Future Actvities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 308
THE PROJECT AS A MODE OF WORK IN SWEDEN - FROM TECHNICAL THEINKING

TO MANAGEMENT THINKING
Sten Nordstrom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
1. From Then to Now. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
2. Development Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
2.1 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .310
2.2 Trends in Swedish Trade and Industry and Public Administration. . . . . . . . . . . . . . . . .311
2.3 Training.................................................. .311
2.4 Methods and Aids. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311
3. Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
4. Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
THE AUTORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321
INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ., . .331
XVII
Funda:mentals of Project
Manage:ment
CONTENTS OF THIS CHAPTER

Martin Barnes

Hans Knopfel
PROJECT MANAGEMENT PARADIGM - A SYSTEM ORIENTED MODEL OF PROJECT

MANAGEMENT
Gerold Patzak

IvarsAvots

R. Max Wideman

Eric Gabriel

Morten Fangel

Hasso Reschke
Martin Barnes
Abstract
The separate techniques of project management are well known, particularly the "hard" techniques of
infonnation based time, cost and quality control. The "soft" techniques, centring on management of
people and their decisions are less well known. In this paper, Martin Barnes offers a fundamental
approach to project management which draws all the techniques together.
1. Introduction
In the twenty years since IN1ERNET was set up by a small group of far-sighted people including
Roland Gutsch, project management has developed rapidly and comprehensively. By accident,
network analysis was the new technique whose introduction frrst showed us that projects needed their
own techniques. Only when networking had gained its uncertain hold did it become clear that there
could be other numerate (hard) techniques peculiar to projects which could help people to manage
them. Later, recognition of the importance of the human factors (the soft techniques) hit the world of
project management.
Only recently has it been possible to look objectively at the range of hard and soft tech~ques of
project management and fit them into a framework. Such a framework, if accepted, would be a major
crystallizing force for project management technique as known to this time and a foundation for
further development of technique for the future. In this paper, I offer a simple statement of such a
framework which shows how the principal techniques can contribute to the totality of project
management and strengthen it.
This paper about the fundamentals of project management is written to introduce the fundamentals to
people new to project management. It does not mention the main hard techniques in time, cost and
quality control. It does attempt to show people why they need these techniques by describing the basis
of effective project control. It uses simple images to make the main points. I hope that experienced
project managers reading it will identify with the framework it outlines and agree with the
representation of the fundamentals which I seek to put across.
2. A Definition of Project Management
Project Management is the science of identifying the objectives for a task and organizing the activities
of a group of people so that the objectives are achieved by completing the task.
The objectives usually comprise a performance objective, which is the most important, and cost and
time objectives.
We want to bring a new computer centre into use
- by 1st January 1991
- without spending more than 26 million pounds.
We want to make the changes to the method of awarding contracts throughout the European
Community set out in the Directive
- by the end of 1993
- without spending more than 200 million pounds.
We want to have prepared the material for the Roland Gutsch commemorative book
- by 21 April 1990.
Meeting the PERFORMANCE objective is always the most important because it is the beneficial
change which the project is intended to achieve. c
Project managers need a clear, homogeneous and connecting set of techniques which, when applied,
will ensure that the objectives for every project are first properly identified and ultimately achieved.
Project management is not an exact science because its building blocks are the decisions taken by
ordinary imperfect people in uncertainty. However, project management science can dramatically
increase the probability of getting projects finished on time, within budget and so that the finished
thing does what it was supposed to do. It can make achievement of any two out of the three objectives
of a project virtually certain.
3. The Basic Propositions
(a) The task which is the project is made up of separate activities.

(b) Each activity absorbs money and time and contributes to the ultimate performance of the
completed project.
4
It follows that:
(c) The project manager must divide the task up into activities and allocate some of the available
money and time to each.
(d) Activities are done by people using things. The people and the things are resources. Costs are
incurred by using resources, not by doing activities. In construction and engineering, for
example, the people resources include designers, managers, skilled operators and unskilled
operators. The other resources include materials, plant, equipment and fuel. Resources absorb
costs according to how they are paid for. People have a cost per time period. Other resources
usually have a cost per item or per unit of quantity.
(e) Project managers make the major decisions about how the objectives for the project are likely to
be achieved and supervise other people making all the other similar minor decisions. They plan
the activities, appoint people to do them and supervise them doing them.
(f) Several activities can be going on in parallel, all using the same time. Activities can not use the
same money, you can only spend it once. A programme showing when all the activities are
intended to be done must show the sequence in which they will have to be done, a budget or
cost forecast can just be a list of the activities with the forecast cost of each listed and totalled.
4. But What Does a Project Manager Actually Do?
He or she makes sure that the project actually does meet its objectives. The main tool for doing this is
the decision making technique used.
This is based on the two laws of project management:
The First Law

All decisions are directed towards achieving the project objectives.
The Second Law

Only the remaining work in the project can be managed.
It follows that the objectives for the project must be clear and must be accepted by everybody whose
decisions will affect the outcome of the project. It also follows that decisions must concentrate on the
remaining work.
5
5. How to Finish on Time and Within Budget
The deadline for finishing the project is tomorrow. We know what is left to be done, who is going to
do it and how it will be done. We know that, if we do it, the completed project will perform alright.
We know that we have enough money left to do the work we have yet to do and we know that it can
be done in the time we have left. If these statements are true, the project will meet all its objectives.
It follows that, the only things to be done to make sure of meeting the project objectives are to make
sure that, at any point in time:
- there is a good plan for doing the remaining work
- people know what it is and are working to it
- there is enough money and time left.
The difficulty is that the future is uncertain. It may be possible to finish on time if you have only one
day to go and there is enough time left to finish off. But if there are three months or three years left,
many unexpected things have yet to happen. Each one of them will be unexpected, but we can be
quite certain that we shall get some unexpected problems.
6. Project Managers Need Space
Project managers must make space in the plan for the unexpected. They must keep enough money
back to pay for the unexpected which is certain to happen. They must keep time back for the
unexpected. They must carve spare money out of the budget (contingency) and spare time out of the
programme (float).
The unexpected usually needs more activity to be added to the project, not less. This activity will
absorb money and time.
The more work there is yet to do, the more unexpected problems have yet to happen. If enough space
has been left (contingency, float), the project will meet its objectives.
If you leave too much space, you will finish early and within budget. This may not be a good thing.
People will say that, if you had managed the project better, you could have used the time and money
you came over to produce a better performance - more building, a better quality new product or
whatever.
It follows that:
Project management technique must centre on making decisions which contribute to development of a
plan for the work which, if followed, will converge on achievement of the project objectives.
The plan for the remaining work should be changed whenever a better plan for the remaining work
can be found. Always be prepared to make a decision which improves the plan.
6
7. Keep Changing the Plan
The plan we are working to now is based on

better knowledge of
what the remaining work actually is
than we ever had before
better knowledge of
what things are actually going to cost us
better knowledge of
what the people in the team can actually do
better knowledge of
what the client actually wants
better knowledge of
what work would still be left to do by now
better knowledge of
how much money we would have left by now
better knowledge of
lots of things about the remaining work
than we ever had before.
So we have to be prepared to change the plan whenever a new one would be better. If you are half
way through the project and you are still working to the original programme or to the original budget,
something is very wrong. You could be working to a much better plan which would have a very
different programme and a very different budget The end date and the total spend limit will remain
inviolate.
It is not c1ever/masculine/foresighted/respectable to be still on the original programme. It is

boring/unimaginative/unperceptive/old fashioned and you will probably not finish on time.
Of course you should not change the plan just for the sake of it, because doing so absorbs
management effort and can demoralize the team. But you must always be working to a plan which the
team is confident and you will get the job done well.
7
8. How to Make the Right Decisions
The plan is the aggregation of all the decisions made so far. We have decided what is to be done, who
will do it and how they will do it. We have decided which resources will be used on each activity.
From this we have forecast what each activity will cost and how long it will take. We have worked out
a sequence of activites and, from it, have worked out when each one should be done.
In reality the plan is never made in its entirety at the beginning of the project. Throughout the project
the plan is being elaborated ready for the next stage and modified to take account of new knowledge
about the work ahead. All decisions either elaborate or modify the plan.
To be sure that the current plan will lead to achievement of the objectives for the project, the decisions
have to be taken in a particular way. There are five stages in this process.
STAGE ONE - Recognize the need for a decision:

Does the plan need to be elaborated? Is it time to decide how to build it now that we have designed it?
Is there anything about what we have achieved so far which should prompt us to modify the plan for
the remaining work? Do we now know something about future problems which should make us
modify the plan?
Do not sit in the office waiting for a crisis to develop. Think ahead and make decisions which improve
the plan before the crisis strikes.
Do not wait for the cost report to show that we have a "negative variance" or the progress report that
we have a "slippage". Both these traditional decision triggers assume that the the original budget and
programme are right and that you are still working to them. Often one or both of these assqmptions
are wrong.
STAGE TWO - List the options:

We could do this, this or this. Put the imaginative options on the list, not just the obvious ones based
on experience. Think laterally. Other people in the team will know the technology of the task being
considered better than you - involve them. Get them to think laterally. At this stage, reject nothing.
STAGE THREE - Forecast the outcome of adopting each of the options:

Option one will have this effect on performance of the completed project, will have this effect on the
cost of the completed project and will have this effect on the timing of the remaining work. Repeat for
each of the options. As before, involve the people who know, but test that they are not shooting lines
before you accept their forecasts.
8
STAGE FOUR - Choose the best option:
First reject those options for which your forecast outcome goes outside the project objectives. Choose
between the remaining options on the basis of which has the best outcome in relation to the project
objectives.
If finishing early or on time is the dominant objective, pick the one with the best time forecast. If
saving money or finishing within budget is the dominant objective, pick the one with the best cost
forecast. If maximizing performance or hitting the performance target is the dominant objective, pick
the one with the best performance forecast.
STAGE FIVE - Implement the chosen option:

Modify the plan to reflect the new decision. Communicate the new plan to everybody who needs to
know - tell them in terms of performance, cost and time. Tell them the results of Stage Four if it is an
important decision so that they understand why the the decision was made.
Even this way of making decisions is not always straight-forward.
Sometimes, none of the options on the list at Stage Four satisfy the project objectives.
If this happens, go back to Stage Two and think harder. You really need to come up with some more
options.
Sometimes, the last two options do not separate themselves in Stage Four - it is not clear which will
be best, bearing in mind the inevitable uncertainty about the forecast outcomes.
If this happens, go back to Stage Three, get some more data about the forecasts. You either need to
improve their scope or accuracy. If doing this still does not separate the options, choose between them
by tossing a coin, the two options probably would have the same outcome.
Sometimes, none of the three objectives for the project is dominant and the best option is not clear.
This happens much less frequently than you might expect as the relative importance of the three is
usually clear. For example, if the decision has been prompted by an unexpected delay, the time
objective dominates, if by an unexpected increase in a future cost, cost dominates.
9
9. Allowing for Space
In conducting the decision making process, the project manager is the person who must make sure
that enough space is left to allow for future unexpected problems. He or she must control how much
of the money contingency or time float is released to help with the current problem. He or she must
have the authority to keep enough of both in reserve and have the experience to know how much we
should still have in reserve at this stage of the project.
Although you are not the technical expert, only the project manager, you can develop a feel for the
accuracy of the data you are being given by the experts and, consequently, the uncertainty about the
future against which you must protect the space you have created.
If the project manager uses this technique effectively and stimulates its use by the others in the team
who are making the more detailed decisions, there is only one hazard which can prevent the project
meeting its objectives at completion. This is the dreaded "big problem near the end". If a problem
which cannot be solved without spending 3X pounds comes up when you have 4X pounds left in the
contingency, you have a chance. If it comes up much later when you have only 2X pounds in the
contingency, you are in rehl trouble.
There is no panacea for coping with this hazard but there are three mitigating policies.
Firstly -- Think ahead.

The project manager will often be the only person who is thinking ahead. He or she must do this so
that the problem is identified when there still is 4X pounds in the contingency, not when it is,down to
2Xpounds.
Secondly -- Keep more space than the other people think you need.
Make sure that the time and cost forecasts for the activities at the end are more generous than for
those at the beginning. You need a greater likelihood of having enough of both when you have not
many options left.
Thirdly -- Be flexible.
Be prepared to switch money and time around in the plan to relieve foreseen pressure points.
10
10. Leadership and Delegation
To make project management work in this way requires a particular type of leadership. It is not the
mach%fficer quality/first into the firing line/good in a crisis style, although to be able to turn this on
sometimes is essential. It is much more the good communicator/forward and clear thinker/good
listener/good delegator style.
But one very strong characteristic is required. Do not concede when you know you are right You
have the project management skills which they do not. Do not concede on such things as the need to
make a plan and to change it when you decide, the need to set up space and release it when you
decide, the need to have project management meetings when you decide and to make decisions when
you decide.
Everybody else in the team will think that their technical skill as expert on what has to go into this
project is what is important, not your technical skill as project manager. You know different.
Delegation is a key skill. Do it as much as you can. Help people make their decisions when they are
making their plans and, when you are happy with their plans, let them get on with implementing them.
To keep control, ask not what they have done since the last meeting, discuss with them how they are
going to modify their plans to reflect what we now know about the remaining work.
Make sure their plans mesh properly with all the others. Help them to make their decisions by guiding
them through the decision making process, but do not make their decisions for them. Check regularly
that they are keeping the objectives of the project in mind and are still directing their de«isions
towards achieving them. Encourage the other people in the team to delegate effectively as well.
Finally, follow the second law of project management slavishly. You can only manage what has not
yet happened. Make sure that all the paper work which is generated helps people to make better
decisions about the remaining work. We do not need to be a detailed chronicle of what we have
already done and can no longer influence. Confine meetings to discussion about the remaining work,
unless something about the past helps to make better decisions about the future. Cost to date is worth
knowing mainly because it tells us how much money we have left. An explanation of why we are late
is no help. What we need is an explanation of a plan which will still finish the work in time.
11
Hans Knoepfel
1. Introduction
Projects should improve unsatisfying situations, contributing thereby to the quality of life. The
differences between the initial and end states of the systems that are changed by a project are
evaluated with a set of ethical principles and values. In addition, the activities and the process from
initiation to completion are evaluated with a set of principles of conduct governing the individuals and
groups that are involved in the project.
Our projects change the world. Project management is the management of change. Intentional changes
in the world are best managed by projects. The intention of projects is to add a net value to the non-
project situation. The value adding process through projects is shown in Figure 1.
Our projects are parts of our culture. Culture is realized, built, intentional, evaluated qUality. Qualities
are described by attributes. Culture adds a value system, a perception of benefits as a scale for
assessment, to these attributes.
Systems Values
unsatisfying mutual understanding,

initial situation, code of ethics,
need for project laws and regulations
I
~
Project requirements
and values,
client preferences
I
_t
systems design,
contents and attributes,
activities
I
t
quality and cost of
end product,
procedures and conduct
I
~
more satisfying
project
final situation,
success
end of project
Figure 1: Adding Value with Projects
2. Change
In the Nineties, more emphasis than in the past is expected to be put on:
technical innovation
medium-sized and small projects including renovation and maintenance projects
interaction with the project environment
and computer-supported systems.
Changes are taking place less and less in independent fields. They are realized within the complex
environment of
a competitive world market
social groups asking many questions
many existing organizations, facilities and parts of nature.
14
When we consider the facts that projects keep changing the world and that all the above altemtions in
project types and conditions may determine our future work, Glasnost and Perestroika are just the
normal climate for undertaking projects. But are we really changing project management, our
professional field? Figure 2 tries to show the change in the past decade.
?•
o 0
o 0
D 0
o 0
Figure 2: Perestroika of Project Management
Shortening history extremely, we could state that our fathers used to take the traditional networking
techniques for solving every project management problem. In the seventies, problem solving, team
building and decision making methods were on stage. Cost planning and control became a normal part
of the project manager's responsibility, in addition to time scheduling (and cost control). Both
successes related to time and cost performance and doubts about setting the right goals for project
management came up. In the eighties, concepts for new areas like project organization and project
scope, technical coordination, cost and risk management were introduced, computer support became
much more efficient, and the economical and political frontiers in Europe began to break up
dramatically.
15
fu the nineties, it seems, that our clients will expect us to do our job more completely, with no
excuses. We are becoming responsible for defining, delimiting and coordinating the systems we are
working on, and for governing their interaction with the project environment Our duties include much
more than time and cost management, we get involved in:
the control and planning of the operations that are done with and around our systems
the coordination of the technical concepts and drawings
qUality management on several levels of detail and in all phases of the project
the analysis of permanent organizations, the design of project organizations, and contract
management
setting project goals and the benefit and cost management under multi-user and multi-system
conditions.
From recent projects in the range of the author's experience, some more specific trends emerged:
the opportunity to use (multi)-project management for product development and marketing
the great interest in Eastern Europe for project management methods
many unsolved semantic and conceptual problems of data base systems and computer-network-
supported communication for project management
open questions concerning the cooperation in design teams
the importance and lack of professional methods for defining multi-dimensional project
objectives.
New chances evolve from conditions that changed in the past years.
3. Priorities
Change is not an end in itself, and stability is an important opponent factor of successful project
management. Before setting priorities for developing new project management fields, methods and
skills,
the existing tool-kit items of project management should be reviewed
the new opportunities should be explored and qualified.
Entities of these two types are shown in Figure 3. On the basis of such lists and their goals and profile,
organizations can select development projects carefully.
16
Existing tool-kit New Opportunities
project organization project objectives and assessment

time scheduling quality management
cost planning and control change of existing facilities
contract administration multi-clisciplinary coordination
handbooks and guidelines computer-supported systems
documentation product selection and development
dealing with project environment
data bases and communication
Figure 3: Existing Tool-kit and New Opportunities
Conclusions from analyzing the actual situation of project management in Europe are:
there is a remarkable need for training, education and young professionals in project management
research work in an international context should be undertaken in our field.
The frrst conclusion leads to the idea of producing standards, course material and certification
programmes for project management. On the other hand, definitions, standards and course material
tend to benumb professional knowledge.
Therefore, two outstanding chances are in our reach at this moment
1. to develop a systematic framework and modules of project management standards and

recommendations
2. to limit their extent and to design them for future changes and extensions.
This would allow future developers of our field to use their inherent ability of chosing and managing
changes of our standards and recommendations successfully.
17
4. Systems
A project can be directed effectively and efficiently by a systematic and objective driven management
approach [3] using
several systems
each having a number of levels as its vertical dimension
various disciplines in the horizontal dimension
and its development phases as the lateral dimension.
The vertical, horizontal and lateral dimensions in this model (Figure 4) are tuned by intention to the
corresponding basic dimensions of corporate management and product development for making the
integration of all three types of management easier.
multi - system
------- ._-----_.-..- ~
CD~
> -
Q)(ij
.;:e
- 0
,
:-- ~ ' -l .
.....-...
; " .".',
, , : :
- Q) , ,'
::J;> ~ : i
E"-
T2 T2
.~~'lJ.t;,0
T1 '" T1
•
~'lJ.t;,0
---~~:s.~' 0i.-§...... ~.-----.-.- . -.~ -
../
~
.. ~
multi - discipline ~ \.\~ multi. discipline ~:v
("horizontal")
Figure 4: Hierarchical System Structure
18
A key approach for managing complex projects is "structure". Figure 5 shows how the respondents of
the questionnaire of a study commissioned by APM [4] listed competencies required for project
management. Understanding the anatomy of a project was thought to be most important, whereas
when looking for qualities in a project manager the respondents put communication skills top of the
list.
%
Understanding the anatomy of a project ........... 88
Communication ................................................. 81
Decision making ................................................ 69
Control of change .............................................. 62
Planning & scheduling ....................................... 60
Cost-planning & control ..................................... 55
Managements of contracts................................ 36
Figure 5: Competencies of Project Management Ranking
The basis of many real world operations are man-made and natural physical systems. Finding,
analyzing and delimiting the structure of physical systems, subsystems and components is an essential
ability for a project manager. This ability is becoming more relevant today for several reasons
the technological and engineering background of the projects is recognized better than in thy past
decades when management attention concentrated on time and cost aspects
the project manager is depending more on existing systems, subsystems and components of
different ages and life cycles; project cycles and operation periods are dovetailed
object-oriented methods of design, fabrication, operation and control are becoming more popular
in information technology.
Thinking in terms of systems is structured, relational and dynamic thinking. Systematic project
management allows us to concentrate our attention on a certain subsystem for a limited time in order
to drive it to a certain state of study, investigation, design, fabrication, implementation, acceptance or
operation, to supervise the operations concept and layouts of facilities that are renovated and extended
in order to coordinate the overall configuration to be established in a certain phase, and to check
physical interfaces.
19
5. Usefulness
Project management is related to culture in two principle ways:

Culture through project management. Projects produce new states of systems that are our future
environment and conditions of life. Project management can thus be used to create new culture or
to maintain old culture by producing or renovating buildings, civil works, art, organizations, etc ..
It can help to step out of old-fashioned, ossified cultures. Project management can drive the
project team to find and assess alternatives for optimizing the quality of systems created.
Project management culture. Projects are done by a project organization that has a culture of its
own. This culture is both environment and condition of work for those involved in the project.
Some projects are much determined by the cultures of the permanent organizations engaged in the
project.
Project management tends to become responsible for the total project success in addition to fulfilling
specific functions like overall time and cost control. Deviations from project target values of 5-10 %
are quite usual. In unsuccessful projects, deviations of 20-200 % happen. The expense for project
management may be roughly estimated as 2-5 % of the project expense. If we assume as an order of
magnitude that 1'000.- to 10'000.- SFr. per inhabitant and year are spent for projects in Europe, this is
roughly 400-4000 billion SFr. per year. If the management risk is 5-10% of the project expense,
Europe has 20-400 billion SFr. at stake in project management, annually.
In the sixties and early seventies, an advanced state-of-the-art in project assessment was developed,
for example for water power, irrigation and flood control projects. Design alternatives, their benefits
based on criteria and preferences, and their costs were used for evaluation. Generally, the client wants
answers to three questions, for each alternative,
what is it?
what is it worth?
what does it cost?
With the broader or total responsibility for project success the evaluation of the many and many types
of alternatives in the project cycle is becoming more important for project management.
20
1.
.9
.8
.7 .C EDB
.6 +0
EBA
Benefit .5
.4
.3
.2
.1
0
5500 6000 6500 7000 7500 8000 8500
Cost (1000 sFr)
Figure 6: Benefit and Cost of Alternatives
In Figure 6, a judgement on four bridge alternatives is depicted. Alternative B shows a slightly higher
total benefit, but also a remarkably higher cost. Alternative C is the best one. The cost of alternative A
is estimated to be low, but so are the benefits. Without knowing the preferences of the clients,
alternatives cannot be assessed. Project management should assure that the feasiblity and optimality
of the project is found and maintained throughout the project cycle.
6. Associations
The evident development and dissemination of project management in the past decades would not
have happened to this extent without the international and national associations and the teaching and
research institutes.
In Europe, INTERNET, the International Association of Project Management, has played its role, and
Roland Gutsch's enonneous and continuing efforts since 25 years are one of the main reasons for its
contribution to this discipline. Ten World Congresses in mayor cities of Europe, many symposia
between Cairo (Egypt) and Atlanta (U.S.A.), and fourteen International Expert Seminars at the
Gottlieb Duttweiler Institute in Ruschlikon (Switzerland) have allowed project management
professionals to ask questions, present practical experience and research results, and discuss answers.
All this would not have been possible without the strength of the National Organizations.
21
Proceedings
of the
6th INTERNET
Congress
1979
Editors: Roland W. Gutsch

Hasso Reschke
Heinz Schelle
VOl-Verlag GmbH
----~--------------------~~
Verlag des Verems Deutsdler Ingenl€ure Dusseldorf
Figure 7: Example of Development and Dissemination
In Figure 7, a milestone contribution to this remarkable performance is shown.
7. Conclusion
The systems that are established and changes by projects are related more and more to a complex and
extended environment. Project management is the art and science of planning, directing and
controlling actions with limited time and efforts. Such actions always will be undertaken and
important for the welfare of people. Project management has become a part of our science and culture
like biology, physics, languagues and civil engineering. A reasonable balance of change and stability
has been found in the past decades in this discipline.
A large amount of future investments can be realized more effectively (purpose- and usefully) and
economically in Europe and elsewhere with good project management. Education, training, standards,
recommendations, and certification are expected to become an important task in the next years.
Research work in an international context should grow.
22
References
[1] Gutsch, R. W., Reschke, H. and Schelle H. (Editors): Proceedings of the 6th INTERNET
Congress, 1979.
[2] Archibald, R.: In Search of New Frontiers in Project Management, Proc. 6th INTERNET
Congress, Garmisch-Partenkirchen 1979.
[3] Knoepfel, H.: A Concept for Project Management in the Nineties, Proc. PMl/lNTERNET
Symposium, Atlanta, GA. 1989.
[4] APM: Where we've got to, Project, Apri11990.
23
PROJECT MANAGEMENT PARADIGM
A SYSTEM ORIENTED MODEL OF PROJECf PLANNING
Gerold Patzak
1. Introduction: Why Structuring Project Management?
Project Management has gone through a dramatic evolution during the last three decades. Today
Project Management embodies a whole complex of methods and techniques covering topics far
beyond basic planning and scheduling, although many people involved in project activities still think
of CPMjPERT primarily when Project Management is mentioned. There are many reasons for an
urgent need of delimiting and structuring the whole field of Project Management which finally
cumulate in an increase of insight and a better understanding of the Project Management knOWledge.
There have been many endeavors to establish frameworks, breakdown structures and diagrams to get
to grips with this complex material which is considered to make up a unique discipline called
PROJECT MANAGEMENT.
Generally speaking, the breakdown of any complex entity (system) into its parts is the main approach
to gain insight into content and properties of it. But in doing this we must keep track of the
interdependencies between the components! (Therefore, the above statement is no plea for the so
called Ontological Reductionism.)
Thus, structuring is the main instrument in dealing with complexity on a rational basis, it is the
prerequisite for making complexity visible, understandable and is the tool for its stepwise reduction.
Looking at the "overall picture" as well as breaking up the black box and looking at the internal
relations and the system context in its specific environment - is mandatory to understand any system.
The task of structuring a complex object (like the Project Management-body of knowledge) can be
performed
* by applying the deductive technique (top-down procedure): This is done by branching and
subdividing the complex object under consideration by starting from the overall entity (The
Systems Approach emphasizes this procedure).
* by applying the inductive technique (bottom-up procedure): this is done by gathering and
collecting items (elements or subunits) and composing them according to their interrelations in a
tree-structure that finally ends with the overall entity.
The latter technique has an obvious disadvantage: One easily can overlook and forget items or, on the
other hand, overemphasize components since the analysis process is not gnided by the overall object
as a holistic entity.
This paper tries to develop an up-to-date framework model of the Project Management Knowledge
following the Systems Approach - as opposed to most of the structures and frameworks to be found in
Project Management-literature.
The framework suggested can be considered as an explanatory model since it also shows the
interrelations of the subtopics of Project Management Knowledge within the systems and with its
environment, and thus goes beyond a mere listing and description of the components Project
Management is made up.
2. The System Approach to Project Management
The starting point for the analysis of the phenomenon PROJECT is to look at a process - the process
of transferring an intitial state I (problem) into a desired final state 0 (problem solution).
o PROJECT EXECUTION
Figure 1: Project Execution as an Input/Output Model

-.~ 0
In state 0 all more or less intended outcomes of the process "project execution" are available having
been produced during the whole process.
These outcomes are concrete (products, organizations, a.s.o.) or abstract (plans, knowledge,
experiences, emotional states, a.s.o.) or both.
They may be distingnished into
- outputs during the process (e.g. satisfaction of personnel, gain of experience)
- outputs at the end of process (final products, state of knowledge)
So, it is obvious that the total process output is much more than the product, that is the object system
to be produced in the project under Consideration Management has to be concerned with Jill
dimensions of process output
26
The problem solving process - the project execution - shows a typical cycle of prQject life. which is
structured into the following pattern of phases:
- Objectives Definition Phase (what is to be accomplished?)
- Design Phase (what/how to do it)
- Realization Phase (doing it)
- Implementation Phase (hand-over of it)
These phases can be observed in any problem solving process, they do not change with different
project definitions.
From the manaID'ment point of view in every phase there exists a management function as opposed to
the execution function.
These process-oriented phases of projects are not identical with the different states in the "journey of
life" of object systems, starting from the state of "not yet existing" and ending with the state of "no
more existing".
The phases of system life cycle are:
Conceptual Phase System needs identification
System Definition Phase System design/engineering
Production/Acquisition Phase System materialization
Integration Phase System installation
Operation Phase System use, maintainance
Removal Phase System phasing out
Restitution Phase System destruction, recycling, or
System modification
This life cycle concept is a very useful pattern of structuring the overall process of a project. B)Jt it is
not an efficient framework for the breakdown of the Project Management Discipline.
Since any phase of the life cycle of an object system has an impact on all the succeeding phases of it,
we must always mind the whole life cycle of objects, if we act in a system oriented holistic manner.
A project may cover one or several connected phases of the object system life cycle.
Examples:
* Develoment and implementation of an application software = phase 2,3,4
* Feasibility analysis for a plant in a developing country =phase 1
* Destruction and deposition of a nuclear power station = phase 6 and 7
But everyone of the above projects, regardless of the life cycle phases concerned, shows the typical
four project phases listed before.
So it proves to be essential which system within a project is to be looked at. We have to distinguish
the following systems:
27
The Actin!: System: The Project Organization
a social (socio-technical) system showing the following important properties:
- open (exchanges with its environment)
- dynamic, evolutionary
- selforganizing.
The Activity System: The Project Process

an abstract system of planned and/or observed actions describing the behaviour of the organization,
with the following properties:
- goal-oriented
- mainly rational
- complex and innovative/nonrepetitive
The Object System: The Expectations/Project Outputs

the planned and/or actual results throughout the whole project process and at the end of the project.
This object system is in the state of objectives at the outset of a project and is transferred more and
more into actual outputs including the product, which is the main goal of the project.
These three systems are mutually related as follows:

If we look at the Acting System by considering Q!lly what is done in the system (what actions
should be or are performed), we are dealing with the Activity System.
If we look at the Acting System by regarding Q!lly the different flows (input, throughput, output)
in the form of information (goals, expectations) and/or material (results like products, situations
a.s.o.), we are dealing with the Object System.
That means, Activity System as well as Object System are so called aspect systems of the overall
system, the Acting System - the Project Organization - which performs actions based on a consensus
upon its objectives, which organizes itself, which produces outputs throughout the whole process and
which is evaluated by its environment. The Project Organization is the focus of our considerations.
3. Why is the Acting System "Project Organization" Working?
Any system only can be understood and only can be optimized by looking at the interrelations and
dependencies with the systems environment: Optimizing a system means designing an optimal fit of
the system into the relevant environment of this system.
28
The Project Organization is acting based on a trade-off between the expectations of the social
components of the system - the Project Team - and, on the other hand, the expectations of the whole
system's environment relative to the Project Organization considered.
Which environments do we encounter?
In a so called stakeholder analysis the following enyironments can be isolated:
- Mother Company (if existing) top management, functional departments, other
projects, professionals, a.s.o.
- Client, Customer product buyer, user, operator investor, sponsor
- Money Supplier company owners, stockholders, investors
- Subcontractors, Partners suppliers, consultants
- Socio-Cultural-Political Environment: authorities, media, public
- Economical-Technical Environment competitors, markets, technologies
Natural Environment activist groups, intervenors
The outcome of this trade-off process between the different expectations, depending on influence and
power, is the Project Objective System already mentioned. This objective system is the orientation
for the performed project activities.
Since we are dealing with dynamic systems in a dynamic environment, this trade-off process never
stops, expectations change and restrictions alter, a permanent control-loop process is going on.
The management of this process is crucial for the survival of the project organization and is essential
for the project success.
The whole complex of activities related to the project environment and to the management of project
objectives will be called Strategic Project Management. It covers tasks like Project PR-Work,
Configuration Management, Project Risk Management, Contracting, Reporting, Claim Management,
Environmental Impact Analysis/Social Impact Analysis, Objectives Finding Process, and much'more.
4. How is the Acting System "Project Organization" Working?
The Project Process performed by the Project Organizations is a goal-oriented, rational process in
transforming an original situation (state I) into a desired situation (state 0), where 0 is defined by the
Strategic Project Managment. To ensure an optimal, goal-oriented process the function of managing
this process has to be provided: This part of project management will be called Operational Project
Manawnent.
29
OBJECTIVES
~
OPERATIONAL
PROJECT MANAGEMENT
~ t
0 • PROJECT EXECUTION
• 0
DISTURBANCES
Figure 2: Project Execution and the supplementary Operational Project Management
The function of managing the process is existing in any case, but there is not always a separate
organizational unit established to take care of it.
Management within an or,ganization will be defined as getting things done with and through others to
reach certain given goals. Following the well known listing of management functions the Operational
Project Management shows an emphasis on
- planning the process
- directing the process
- monitoring the process
while the functions staffing and organizing are rather related to the management of the Operating
System, discussed later on under Instrumental Project Management.
Going into details, a control loop model of the Operational Project Management is shown in figure 3.
30
STRATEGIC PROJECT MANAGEMENT
PROJECT
OBJECTIVES
1
PROJECT _ - - - - EXTERNAL
CONSTRAINTS
PLAN N I NG/REPLAN NING
(project environme~
PROJET
GOALS
plans,criteria 1 I DEVIATIONS
from project goals
PROJECT
CONTROLLING
•
RESOURCES
CONSTRAINTS
DIRECTING MONITORING
feed 10.... ~ oontrol feed ... k oonlroll
DECISIONS INFORMATION
PIS
INTERFACE
MGT/EXECUTION
..
PROJECT
INPUT OUTPUT
EXECUTION
GOALDEFIN. IMPLEMENT.
PHASE PHASE
,,,
DISTURBANCES
Figure 3: Model of Operational Project Management
31
5. How is the Project Progress Measured?
Generally speaking, the project process has to be evaluated by measuring to what extent the
expectations of the stakeholders are satisfied throughout the whole process. But this has to be done in
taking into account all changes of these expectations, i.e. their dynamic developments.
Measuring units for the evaluation of the process are the following parameters:
- PERFORMANCE (quantity, quality)
-TIME
-COST
which are strongly interdependent, so that there exists a trade-off relation between any t.vo of them
(see FigA).
In the project planning process these parameters are treated in a rather consecutive way, one after the
other, but the optimizing and controlling step is only possible if we treat them in an integrative way.
This existing interrelation of the three parameters is especially obvious in the step of estimating
activity durations: one can not estimate time withthout considering performance and cost
simultaneously.
So, a main breakdown of project management following the three parameters performance/scope,
time, and cost is a strong simplification and often proves to be misleading.
EXPECTATIONS OF
rnOJECT ENVInONMENT
rnOJECT
I OOJECIIVES
Figure 4: The Parameter Tripod

Measuring project outputs for the stakeholder satisfaction
32
6. WholWhat is doing the Project Process?
As already mentioned, an Acting System (organization) is required to perform the project process
including the management functions discussed. In running this socio-technical system called Project
Acting System further management functions are necessary: The main objective of managing the
acting system has to be the optimal use of the potentials available, that are capacities in the field of
human resources the project team members, personnel
- technical resources the project equipment
(hardware, software, information)
- financial resources the budgets
Since projects are rather unique, nonrepetetive, complex tasks, the Project Acting System has to be
built and tailored for this purpose. We are observing a typical life cycle of organizations showing the
following phases:
- Demand Identification (quantity, quality, time, location)
- Acquisitionffake-in
- Capacity Planning, Allocation, Optimization
- Assignment/Use
- Motivation, Training/Maintenance
- Personal DevelopmentIModification
- RetirementlLay-off,
where the terms used are relevant to human/technical system components.
These tasks of Project Management are mainly inside-oriented, and rather have a mediate,
instrumental character in respect to the project objectives.
Therefore this part of Project Management may be called INSTRUMENTAL PROJECT
MANAGEMENT.
7. Project Management Phases
If we put together the different sections or parts of Project Management, which are:
Strategic Project Management managing the Objective System
(expectations/outputs)
Operational Project Management managing the Activity System
(process)
- Instrumental Project Management managing the Acting System
(organization)
33
We may realize, that there exist typical phases - probably better to say: typical Project Management
situations, that require different emphasis in skills, tools and methods to be used.
These Project Management phases may be called:
* Project start-up and rebuilding phase
* Project administering and coordination phase
* Project crisis phase
* Project close-down phase
The above framework is a very useful additional pattern in structuring the Project Management
Knowledge.
This breakdown into phases/aspects of project management follows a very useful management model
developed by H.A. Kurstedt, where the management task is categorized according to the following
three aspects:
A... Administering the management process
B... Building the business, improving performance
c... Catering to crisis
8. Construction of a Model of Project Management
Based on the different breakdown structures and the interrelations of the components developed so
far, we can construct a model of Project Management, a framework of components of Project
Management Knowledge.
This overall picture of Project Management is structured in a system-oriented view, it shows
interfaces with neighbouring disciplines and is helpful in designing a modularized educ~tion and
training program.
The model of Project Management Knowledge suggested is structured in the form of a three-
dimensional framework:
Dimension 1: A breakdown according to the typical Project Mana~ment Phases, which are:
* Project Start-up and Rebuilding Phase
* Project Administering and Coordination Phase
* Project Crisis Phase
* Project Close-down Phase
Dimension 2: A breakdown according to the different Systems to deal with:
* Strategic Project Management: The management of project environment relations
* Operational Project Management: The management of the project process
* Instrumental Project Management: The management of the project organization
* Technical Management: The management of the technical problem solving
process
34
Dimension 3: A breakdown according to the different Manawnem Functions:
* Planning
* Controlling (Directing, Monitoring)
* Organizing and Staffing
differatin" between the Parameters of the Tripod:
performance, time, cost (Operational PM)
Q[ between the different System Components:
personal, hardware, information (Instrumental PM)
Q[ between the different System Environments:
client, company, contractors, project team a.s.o. (Strategic PM).
9. A Framework of Project Mangement Knowledge
According to the developed model of Project Management we can derive the following outline of
project management topics and relevant methods:
1. The Systems Ap.woach in PrQject Manawnent. Basics

System thinking, System models in project management, systems
methodology, project environment, project cybernetics, Project
Information System PIS.
2. The Prqject Start-Up Phase
2.1 Strategic PM Project environment analysis, stakeholder analysis, goal finding,
restrictions/constraints, system specification/defmition of obj~tiives,
project success definition, project selection/risk analysis, bidding,
contracting.
2.2 Operational PM Project definition, feasibility analysis, work breakdown, statement of
work SOW, cost estimating in early phases.
2.3 Instrumental PM Project organizations, roles, responsibilites, skills/properties, selection of
project managers, team building, forms of communication, meetings, job
description, acquisition of resources, project financing, project
handbook, rules and regulations.
35
3. PrQject Administerinf: Phase
3.1 Strategic PM Reporting, public relations management, product specifications,
configuration management, contract management, project status report,
project auditing, stakeholder management
3.2 Operational PM Project planning and controlling
3.2.1 Project Planning and Optimization
- project scope and structure, coding
- project process logic
- project time management
- project resource management: loading, smoothing, availability
- project cost management, risk management
3.2.2 Project Controlling: The feedback control loop
Monitoring: data-information-decision chain, data collection measuring
techniques, evaluation (variance analysis, cause/impact analysis)project
appraisal
Directing: development of corrective actions, productivity(efficiency
improvements, performance-time-cost trade-offs.
- quality controlling, quality assurance/programs
- work progress controlling, measuring, milestones
- cost controlling, earned value concepts
- integrated controlling, Performance Management Systems PMS
Project approval
3.2.3. Computer Integrated Project Management - CIPM
3.3 Instrumental PM Phase-oriented project organization
Leading in projects, team work techniques, conference techniques,
career planning, performance appraisal, recruiting, incentives,
organizational learning, training, project corporate identity, project
culture, project ethics, project communication system, meetings
Maintainance systems
Documentation systems, filing, retrieval, standardization, Logistics in
projects
4. PrQject Crisis Phase
4.1 Strategic PM changing objectives evaluation, force majeure pacts, claim management,
management of change.
4.2 Operational PM project improvement (performance - time - cost trade-offs)
4.3 Instrumental PM Consensus/conflict management, labour turn-over/replacement of
personnel
36
5. Project Close-down Phase
5.1 Strategic PM Failing of projects, hand-over, warranty, claim management, follow-up
projects, after sales management
5.2 Operational PM Project evaluation, project fmal documentation, transfer of experience.
5.3 Instrumental PM Reentry management, close-down barriers, lay-off measures, personnel
evaluation.
6. The Technical Management
Product/System management
The problem solving process, methods of modelling, methods of
synthesis, creativity enhancement, analysis & optimization methods,
alternatives evaluation and selection methods.
References:
Patzak, G.: Systemtechnik-Planung komplexer innovativer Systeme, Berlin-Heidelberg-New York

1982.
Patzak, G.: Systemtheorie und Systerntechnik im Projektmangement. In: Reschke, H., Schelle, H.,
Schnopp, R. (Hrsg.): Handbuch Projekt-Management, KOln 1989, S.27-58.
Ropohl, G.: Bine Systemtheorie der Technik, Miinchen Wien 1979.
Blanchard, B., Fabrycky , W.: Systems Engineering and Analysis, Englewood Cliffs 1981.
37
IvarsAvots
Abstract
Project management systems (PMS) are designed to successfully manage a variety of project
activities. However, despite decades of improvements, including ever more powerful computer
applications, these systems still fall short of being effective and dependable tools. Despite the fact that
project owners try to forestall problems by weighing the contractor's PMS capabilities as much as his
technical qualifications, serious schedule delays and cost overruns continue.
This chapter is based on the premise that, while the PMS systems address scheduling, resource
allocation and budgeting, they do not respond to the underlying issues that are behind most of the
large delays and overruns. Considering that the PMS has not fulfilled its promise, the case is made
that improvements can be achieved by treating the project as a component of a complex system and
focusing on the constraints and dynamics imposed by the system's environment. An actual example
will be provided to illustrate this improved approach.
1. The Shortcomings of PMS
The beginnings of project management systems (PMS) are usually identified with the introdu<:tion of
PERT and CPM in the early sixties. The improvements, which these techniques provided over
traditional bar chart scheduling gave the impetus to the entire project management discipline. While
the initial focus was on scheduling and resource allocation, budgeting and cost control were added a
few years later.
A significant increase in PMS effectiveness came in the seventies with the introduction of relational
data bases and presentation quality graphics. User-friendly interfaces eliminated the communications
gap between the manager's desk and the point where the action took place. While all this helped to
gain more control over project activities, it did not get at the root of the most significant problems
which arise at the interfaces between the project and outside entities. This shortcoming has become
the stumbling block for many well-known projects.
The big headlines of the past twenty years include such names as the Trans-Alaska Pipeline, the North
Sea Oil Development, the Concorde, and a long list of nuclear plants. All of these projects were
managed by highly qualified companies using state-of-the-art PMS. Yet, they experienced large
delays and cost overruns triggered by factors that escaped the PMS. These factors included labor
contracting practices, environmental impact, regulatory changes, financing problems, political
maneuvering, and various others. The common aspect of all these projects was the fact, that the
techniques used to control them addressed only a part of a larger system. These other components of
the system behaved in their own way. No existing PMS could have alerted management to the
problems, that arose at the interfaces between the project and the other system components.
2. The Systems Approach One More Time
Looking at a project in a systems context is nothing new. Long before work breakdown structures and
network planning became household words, many complex projects were successfully executed using
the systems approach. Starting with the Manhattan project which produced the atomic bomb, the
systems approach was evident in many military and electronics projects. Although the Trident nuclear
submarine project is said to have been the first successful application of PERT, many believe that it
owes its success to the systems approach and not to PERT which was introduced too late to be of
anything more than a public relations value. Moreover, one does not need to look at the big projects to
find the impact of systems. In many small project organizations, the work is more productive when
the marketing people, designers and producers are integrated into a cohesive system.
In the systems context, a project can be viewed as one of many entities that interact with several
overlapping environments, as shown in Figure 1. The nature of these environments can be physical,
political, social, economical or even philosophical. For example, imagine setting up a commercial
project in a country that for the last forty-five years has been under a planned economy. Such a project
could be affected by inadequate infrastructure (physical environment), bureaucratic challenges (social
environment), and interested third parties (political environment). In such an environment, the day-to-
day scheduling and cost control problems, handled by the PMS by itself, would be of minor
consequence. To manage the project effectively, we would need to put the PMS in a realistic context
by identifying various system entities, evaluating their potential impact, and setting up measures for
dealing with them.
40
PHYSICIIL POLITICIIL
ENVIRONMENT ENVIRONMENT
SOCIIIL
ENVIRONMENT
Figure 1: The project system and its environments.
In designing an effective total project management system, we need a conceptual model that
adequately defines the project and its interfaces with other significant components of the system. Such
a model can be based on advanced principles of systems analysis, where a distinction is made between
the structural, dynamic and informational aspects of the system. A method for doing this was
developed in the late eighties by INFOLOGISTIK GmbH in Munich and is known as INFOLOG
(INFOLOG is trademark of INFOLOGISTIK GmbH and Trans-Global Management Systems, Inc.).
While applications of this method are not limited to project management and have covered marketing
operations, banking and logistics systems, they include the following basic steps:
1. Identification of system entities

a. Diagram the structure of the total system by identifying all major entities which interact with the
project. This would include owners, suppliers, regulatory agencies, and others. As shown in
Figure 2, the project will be represented by a single structure element and the environment as one
or more structure elements, each representing a physical entity or a physically boundable
collection of entities. These entities can be presently existing or expected to arise during the
project. For example, one could expect that the construction of a new nuclear power plant would
give rise to the formation of local anti-nuclear groups.
41
Figure 2: Total system view of project
b. List the results, which the project gets from the environment and the results the project produces
for the environment.
Figure 3: System entities at the project level
c. After the total systems overview, break down the project into a results-producing structure at a
lower level. This could include design, procurement, construction subcontractors, and the
management group or PMS itself. The lines linking the elements of the structure denote interfaces
with a flow of results, as shown in Figure 3. The satellites along the edges refer to the
environmental elements from the top level structure diagram which interface with the project.
42
2. Analysis of potential impact
a. Mter the system entities and the top-level results flows have been identified, one can analyze the
interactions at a lower level. First, list the results that each structure element receives from other
structure elements in some detail. This is done in an information table as shown in Table 1. The
underlying premise is that each element acts upon the results deterministically and produces other
results for other structure elements. For example, if the Building Inspector disapproves a proposed
design, it needs to be revised (A to 1), at the same time resulting in a schedule delay (1 to 4). This
process leads to a better understanding of the interactions between system entities and the
potential points of conflict. The information table also makes it possible to formalize a system
specification step-by-step to any desired level of detail.
# RESULT FROM TO ACTIONS TAKEN MOllE FREQ

=============================================================================================================
Building permits A Revise release schedule Doc AR
Z Fund availabi lity schedule C 5 Reflect in cash flow budget Doc AR
3 Design release dates 1 Z Initiate procurement actions Doc AR
4 Design release dates 1 4 Include in schedule Doc AR
5 Cost estimates 5 Prepare budget Doc AR
6 Progress of work report 6 Use in progress report Doc 11K
Table 1: Information table (partial example)
b. If the analysis were to be carried to the level where computer code can be developed, it would be
necessary to prepare a process diagram for those structural elements which represent EDP and
which interact with the EDP. But even if the analysis is not to go that far, it is useful to list the
processes involved in each element, such as preparing design specifications, obtaining customer
approval, etc .. This helps to understand the elements and assure that all interfaces have been
considered.
c. The final task is to analyze the structure models and the interfaces detailed in the information
tables. For example, a cluster of results flowing through a structure element may indicate a
potential bottleneck. Interfaces with important outside entities may need to be directed through a
single contact at a higher level of management. Also, it may be found that some internal interfaces
or results are superfluous and can be eliminated.
3. DevelQPment of solutions
The final step involves design of the organizational features and procedures that will facilitate
effective management of the project and anticipate operational problems. This includes the potential
selection of a PMS computer program which, obviously addresses only a small portion of the
management issues identified in this approach.
43
3. An Actual Case
The usefulness of the INFOLOG approach is illustrated by the experience of a company which
designs and manufactures customized electronic measurement instruments. Although individual
orders are not large and usually require only selection and integration of previously designed modules,
the differences are sufficient to treat each order as a separate project. At any given time, as many as
thirty projects may be in process for an avernge dumtion of three months. The projects are broken
down into severnl tasks each requiring the services on highly specialized engineers. The assignment of
the engineers to particular projects is made each week by the engineering manager.
As the business has grown over the past few years, the company has not been able to keep up with
promised delivery dates. This has required the hiring of consultants which substantially increase cost.
As a result of increasingly deteriornting fmancial situation and customer complaints, the company's
board asked that a better system for managing the projects be instituted. The INFOLOG method was
used to analyze the system requirements and implement changes.
At this point, it is useful to distinguish between application of the INFOLOG method to a new system
design and the improvement of an existing system. Any opemting organization has established
channels of communication and other systems which would be imprnctical if not impossible to
change. In this case, the analysis must recognize the existing constraints and work towards a
compromise to which all interested parties can agree. In a new system, on the other hand, such
constraints are few and the analysis can work towards an optimum solution.
In the first step in the analysis of the electronic instrument company, it was determined that six
entities had a direct effect on a project. The Company president was the most important of them since
he often bypassed the organization channels to give instructions for projects being designed for
important customers. Field services were concerned with delivery dates since they were responsible
for installation and site testing of the products. The Production department was often complaining
about missed design release dates since this upset production schedules. The Finance department
controlled the use of consultants who were needed to support in-house engineers. The Marketing
department made delivery commitments to customers that often could not be met because of shortage
of engineering resources. Some customers were in the habit of calling the project engineers in order to
facilitate deliveries. These structure elements, identified with letters A to F, were depicted in Figure 4
which can be compared to the example shown in Figure 2.
44
Figure 4: Total system level structure of engineering project
In the next step, a team of engineering project leaders broke down the project into several
management subsystems shown in Figure 5 which can be compared to the example in Figure 3. They
identified resource scheduling as the key entity, with planning, budgeting and status measurement as
the other structure elements. However, their work in breaking down the structure into more detail was
not as clean as implied by the example. When they started the analysis phase and proceeded to
describe the flow of results between these elements, they realized that their model was not adequate.
For example, because of the interfaces with the Production department, projects needed to be
scheduled before the assignment of engineering resources. Also, a role had to be provided for the
engineering project leaders who represented the principal link to Marketing and the customers. Since
a Planning department, as such, did not currently exist, its role needed to be defined more rigorously.
Figure 5: Initial project level structure diagram
45
This realization led to backtracking where the structure design had to be revised. After discussing
several scenarios describing how the project management system would work, the team agreed on the
revised structure shown in Figure 6. Because of the need to coordinate the schedules set in Marketing,
Engineering, Production and Field services, Planning was reinforced making it the focal point for all
schedule development and revisions. Scheduling was conceptualized as a "black box" the computer
system that calculates the schedules and issues reports according to rules set by Planning. Budgeting
was recognized as a separate process that involved contributions from Planning, Scheduling and
Project Management.
Figure 6: Revised project level structure diagram
Unlike the example which went through three successive steps, the real case showed much overlap in
system identification, analysis and even development of organizational solutions. However, by'using
the graphs and the tables as the basis for all discussion, the team maintained a distinction between the
structural entities, the dynamics represented by their interactions, and the information flows. Most
importantly, the team worked at a conceptual level without regard to the specifics of any given PMS
program.
The revision of the project level structure diagram emphasized to the team that the most important
role in the structure belonged to Resource allocation. Presently carried out almost entirely by the
engineering manager, it was affected not only by project schedules and the availability of resources,
but also by influences from the Company president, Field services, Marketing and the customers.
When an information table was prepared for this structure diagram, it showed many important
interfaces going to or coming from Resource allocation. Because of the importance of this element to
the success of the project management system, the team decided to study it further by preparing a
process diagram shown in Figure 7.
46
The symbols used in this chart distinguish between inputs to Resource allocation «) and output from
Resource allocation (». The connecting lines may denote data flow, but more explicitly, they
represent control flow. For example, available resources cannot be displayed until the required results
from the top level boxes (Existing projects, Status information, and Resource pool) are available. This
"wait" gate is represented by the heavy dot Another type of control flow is shown between the
completion of resource assignment and display of available resources. It indicates that since resources
are assigned one at a time, the assignment function may need a new input from the availability display
before it can assign the next resource.
Figure 7: Process diagram for Resource allocation
When new projects are set up, their schedules are integrated into the existing project workload and
their staffing requirements are determined. The progress status of on-going projects is compared to the
resource pool to determine the available resources. These two types of information, which can be in
extensive detail, are the basis for Resource allocation decisions. After the resources are assigned to
project activities, detail schedules are adjusted accordingly.
When the analysis team viewed the information table and process diagram together, they noted a
potential information flow bottleneck at the point of Resource assignment. The team determined, that
a key component of the improved project management system would have to be a tool to facilitate the
evaluation of data coming into Resource assignment. Consequently, a specific solution was designed
whereby a PMS program was specified that would permit interactive on-screen comparison of
schedules and resources. Among other features, this solution provided the capabilities to do the
following:
47
Match selected project activities with resources of applicable skills;
Examine scheduled activities for any given resource or group of resources;
Perfonn what-if evaluation of alternate resource assignments;
Evaluate the effects of priority changes;
Assign specific resources to activities.
The analysis perfonned by the team also led to recommendations regarding organization and
procedures. A formal Planning group was established directly under the President. The Resource
assignment function was expanded into a weekly Resource Management meeting where the
engineering manager was joined by the planning manager and key engineering discipline managers.
No schedule changes for an individual project were permitted until Planning and Resource
Management had reviewed the potential effects on other projects and resources. The new interactive
PMS tool made this readily possible.
4. Conclusion
The above experience showed that a systems analysis tool, such as INFOLOG, can be used to identify
the key elements of a complex project management situation and help design a successful solution.
This approach changed the focus from the mechanistic aspects of a PMS package to the real-life
factors that detennine the eventual success of the project Instead of a simple selection of a PMS on
the basis of various advertised features, the analysis resulted in a thorough organizational and
procedural redesign of the overall project management system. The role of the PMS program was
dermed only after this overall framework was established. It was applied to a critical aspect of the
management cycle for which it was well suited: the resource allocation task.
We can expect that during the nineties, projects will be more difficult to manage than before. This is
because new technologies from the West will need to be merged with practices in the East in a
framework of changing physical, social and political environments. The systems analysis approach,
when applied early in project life, should become an important adjunct to the PMS techniques in
making management of such projects more effective.
48
References
Avots, L: Project Management system Specification (client report), Cambridge MA 1990.

Broks, A.: Sistemas ap mums un mes sistemas, Riga 1988.
Morris, P.W.G.: The First Fifty Years of Modern Project Management: A Didactic History,
(unpublished draft), Oxford 1989.
Ziemelis, U., Gobins, J.: Developing Large Systems Succesfully: A Global Methodology, Munich
1987.
49
R. Max Wideman
Abstract
Today's technological disciplines responsible for new facility and infrastructural projets are now be-
coming seriously attuned to the idea of concern for the physical environment. Certainly, the projects
managers of such projects need to be similarly aware or these concerns and manage their projects
accordingly. This applies to both the project's long term impacts arising out of the project's conceptual
formulation, as well as its shorter term construction impacts arising during execution.
However, today's project manager also needs to be attuned to the cultural, organizational and social
environments surrounding the project. Understanding this environment includes identifying the pro-
ject stakeholders and their ability to affect its succesful outcome. This leads to the possibility of
influencing this environment in a positive way, for the better reception of the change with the project
is designed to intoduce.
Thus, the influencable risks involved may be significantly reduced, and failure to take such an
approach will inevitably lead to a less than satisfactory outcome. This chapter discusses various
aspects of the project environment, and suggests ways in which it may be influenced in order to
increase the probability of a succesful outcome.
1. Introduction
Why worry about the project environment, when the objective of project management is to get the
project completed within scope, cost and schedule? The truth is that if the real objective is to end up
with a successful project, then important though these criteria are, they are not the ultimate determi-
nants of success. Heresy? Perhaps. But success, a very elusive notion at best, is dependent upon satis-
fying the customers.
In the last analysis, the test of effective project management is the degree to which the project objecti-
ves have been accomplished on time and within budget to the satisfaction of the customers.
The Project Management Institute, a non-profit organization based in North America, has broadened
this concept by defining project management as:
"The art of directing and coordinating human and material resources throughout the life of a project
by using modern management techniques to achieve predetermined objectives of scope, quality, time,
cost and participant satisfaction."
Note the reference to participant satisfaction. Thus, the degree of success of a project may be said to
reflect the combined degree of satisfaction of all the participants, customers or stakeholders. Where
construction projects are concerned, the stakeholders are usually many and various, frequently with
opposing interests. Indeed, the cynic might say that the most successful project is one in which all the
stakeholders are about equally dissatisfied!
These stakeholders may participate in the project directly or indirectly, closely or remotely, and
collectively their attitudes, understandings, or particular vested interests, all contribute to the envi-
ronment in which a project is created. This environment can and needs to be managed just as surely as
every other aspect of the project can be managed towards success.
2. What is the Project Environment?
Today, there is a growing awareness and concern for the impact of infrastructure and facility con-
struction on the physical environment. Fortunately, today's technological disciplines responsible for
such work are becoming attuned to the idea of mitigating the adverse impacts of their projects. Cer-
tainly the project manager needs to be similarly concerned about the project's technology, and manage
accordingly. This applies to both the implementation and shorter term practical construction impacts
of the project as well as its conceptual development and consequent long term impacts.
However, today's project manager also needs to be attuned to the cultural, organizational and social
environments of the project. Understanding this envi,-onment includes identifying the project stake-
holders and their ability to affect its successful outcome. This means working with people to achieve
the best results, especially in the highly technical and complex environments such as those involving
modern day construction projects. Therefore, it is essential that the project manager and his or her
project team are comfortable with, and sympathetic towards, their cultural, organizational and social
surroundings. This leads to the possibility of influencing the project environment in a positive way,
for the better reception of the change which the project is designed to introduce. For example, peoples'
typical resistance to change will no doubt be evident amongst some of the stakeholders. Others may
have vested interests or personal or group agendas which are only indirectly related to the project. If
these can be identified in good time, they may be dealt with proactively and in such a way that the
corresponding risks, which are otherwise likely to undermine the success of the project, can be signifi-
cantly reduced. Failure to take such an approach will inevitably lead to a less than optimum project
outcome.
52
3. Dimensions of the Project Environment
For convenience, and working outwards, the project environment may be thought of in terms of the
project time environment, the internal project culture, the original corporate culture, and the external
social surroundings.
3.1. The Project Time Environment
For those who have not had experience of a construction project "in the trenches" so to speak, it is
sometimes diffIcult to capture the feeling of pressure, stress and ultimate satisfaction of a project well
accomplished, which the construction project management process offers. For the first time, many
experience a bewilderment as to what is really happening to them. Yet, most projects, if they are well
run, exhibit some very typical but distinguishing features as they run their course.
3.1.1 Four Distinct Project Phases
A typical construction project life cycle is shown in figure 1. From the figure it will be seen that there
are, or should be, four distinct project phases which make up the typical life cycle of a well run
project. These phases are shown as
o Concept
o Planning
o Execution
o Termination.
As an aid to memory, these phases may be more readily referred to by the letters C-D-E-F. In this
case, C-D-E-F stand for:
Conceive
Develop
Execute, and
Finish.
Figure 1 also shows typical activities which are required within each phase for building, say, a process
plant. Of course, within each phase a number of sub-phases or stages can be identified, which relate to
the typical construction project. But for our purposes, the four phases shown are generic to any type of
project, and serve to underline the vital importance of progressive project concept development and
planning, for the project to be successfully implemented.
53
2 3 4
CONCEPT PLANNING EXECUTION TERMINATION
C D E F
(Concaivl) (Develop) (Execute) (Finish)
""a:
........o
W
....
o
...J
W
>
W
...J
Identify Neild Ow,lop: s.t Up Orvonizltion Train Operators

Estoblish Fusibility, · plln Working Draw-in;. & T,..nrf.r Matlrials
pr09tlm. procallChlmlties block diagrlms SpecificatioN Document Rasults
sk.tK;hn & outline drawings 0 ..;;0 Rwiew Transfer Responsibility
"'etcl>..
buic budget 8c IChKiu11 rtlndltdl Procure Equipment R,I . . . RI1IOUrcH
Conduct Studi.. ProCUrtl Construction S.rvic .. Ruaign ProlKt Team
project telm
s.loct Equipmmt Produc. Phyolcal Entity
financing
Identify Altlm.trv .. Reconflrm Ec:anom ie. Qu.lty Assurance
CIY.lop, Vlrify Performance
Present Proposal
Obtlin Approvll Modify .. Roquirod
to Procood • bud!/lt
• ochlClul.
• cosh flow
Prop •• & Submit ProjlCt
Brief
Obtain Approval to
Implement
Figure 1: Project Life Cycle: Four Phases
54
Thus, the first two phases, often referred to as the feasibility and engineering phases, are the
opportunity to "build the project on paper", while the third and fourth phases, which include detailed
drawings and specifications, encompass the physical implementation of the projecL Note particularly
that submission approvals are called for at the end of each of the first two phases, and commissioning
and completion approvals are typically required towards the ends of the latter two phases. Thus, each
phase is like a mini-project with its own objectives and constraints, and so it should be seen to be, and
conducted accordingly.
The successful conclusion of each of the phases are milestones, which are really like "gates" between
the phases, and which perform the function of major "Executive Control Points". Some projects
somehow manage to slip through these gates without being in full compliance with project
requirements to that point. Inevitably, such projects find themselves being re-cycled back to the
earlier phase - to the detriment of the final project cost and schedule, and everyone's satisfaction.
3.1.2 The Level-of-Effort Curve
Also of special significance is the variation in the level-of-effort (LOE), which is associated with
these project phases, and which is required to conduct a project through its life cycle. The LOE curve
represents the number of people dedicated to the project on a full or part time basis. It will be seen
from figure 1 that, typically, the number of people involved rises steadily through the first two phases,
but increases dramatically in the execution phase.
It is at this time that difficulties of communication and coordination are experienced, with consequent
high levels of stress, and/or shortages of materials and equipment, or other unnecessary delays. The
success of the execution phase is highly dependent upon the quality of the planning in the prior
development phase.
The finishing phase is equally dramatic - some might say traumatic. At the peak, there must be a
careful balancing act between maintaining full steam ahead to accomplish all the work required, and
being ready to cut the throttle as soon as sufficient work is no longer accessible to maintain the
productivity of those on the project. A major lag in this decision frequently accounts for serious cost
overruns. Again, if the original planning has been in anyway inadequate, changes at this point can
have serious impacts on cost, schedule and the satisfaction of the participants.
Failure to follow these simple steps, is a failure in managing the project time environment.
3.2 The Internal Project Culture
The culture which develops within a project is often a reflection of the leadership style and
organizational structure which is adopted for the project. This can vary considerably according to the
55
size and nature of the project. but in any case has been dealt with extensively in the project
management literature, and will not be elaborated here.
However, to the extent that the melting pot of participation and coordination represents the project's
internal cultural environment. which needs to be managed, it is worth considering. A typical situation
is shown in figure 2, in which the project group to be managed will eventually consist of consultants,
contractors and specialists, as well as the owner's staff of advisors and the project control team itself.
Corporale Policy Sp.cial Lighting
User
Coordination CORPORATION
FacilitY Planning Acounic,/Noi'lII
&. Standards
Finance/
Accounting/Payments
Process, Environmental, &
Other Specialists
CONTRACTOR
Figure 2: Project Management in a Corporate Environment
56
From this it can be seen that each group or person involved in the project has two allegiances or
"bosses". That is to say, project reponsibilities ultimately to the project manager, and "professional"
responsibilities to his or her "home" department or firm. This dual reporting relationship is often
referred to as a "matrix" structure and accounts for much of the complexity and difficulties of
managing a project, particularly a large one.
Similarly, the project manager will also have a dual responsibility. On the one hand under the "project
mandate", he or she will be responsible for the project to the project's "Executive", i.e. the party that
has the authority to approve further project funding. On the other hand, the project manager will be
responsible for personal and professional performance to his or her own home department.
Of course, the project mandate should be to direct all operational activities including planning, design,
procurement, construction and commissioning. Typically, this will include such direct project support
activities as estimating, forecasting, scheduling, procurement, project accounting, and progress
reporting.
In addition, on a larger project, the project manager may require other more specialized services of an
indirect nature. These may include financial accounting, legal, payroll, personnel, property
acquisition, systems development, government and public relations, and so on. However, because they
do not nonnally affect project control decisions directly, these activities are often carried out by
independent departments or companies, which are not under the project manager's direct supervision.
A major duty of the project manager will be to report on a regular basis to the Executive, whose
interest will tend to focus on expenditure to date, forecast final cost, and the scheduled
commencement of the facility. For this he must render a succinct digest of the required infonnation on
progress, forecast, resource requirements, target dates and actions required. If he is to get the quality
of infonnation and service that he needs, then he must maintain good relations and communication.
That is to say, he must maintain a favourable and positive environment involving all parties serving
the project.
As many practicing project managers will attest, this is frequently more easily said than done. In no
small part, this is due to the nature of a project in the context of its time environment, and the
variation in level-of-effort as described earlier.
3.3 The Corporate Culture
Traditionally, corporate management has not been concerned with projects but with conducting and
maintaining an on-going enterprise. Even though management is concerned with planning
coordinating and controlling resources, a culture exists in which work is accomplished by functional
units, and time is not an immediate concern. Change is often minimal and protracted; ,and can be
thoroughly programmed and progressively integrated. The work places of such enterprises are
57
typically bounded by classic organizational hierarchies, established policies, procedures and lines of
authority, by centralized control and by repetitive, assembly-line-like jobs.
Unfortunately, this traditional corporate management approach breaks down where urgent or
significant change needs to be instituted. The correct response is to establish one or more projects to
implement the change. However, new management relationships are then required, which tend to cut
across the normal functional authority and flow of responsibility and radiate beyond the functional
units.
Happily, project management is seen by many as a much more challenging and exciting work
environment, even though a clear understanding of its concepts and application is relatively new. This
is because project management is indeed a different style of management as applied to project-type
work. However, where capital construction projects are concerned, there are almost always many
people associated with them, who only have but a limited understanding of the process of bringing a
capital project on stream. Without embarrassment, I include politicians, owners, sponsors, financiers,
bankers, operators, lawyers, accountants and, I regret to say, even engineers.
Consequently, it is essential to establish a competent project management capability for a potential
construction project even before putting in place appropriate design, engineering or construction
capability.
3.3.1 Influencing the Projects Cultural Environment
The project manager of the successful project will recognize the need to spend some effort in
influencing the project's cultural environment for the benefit of the project stakeholders. Every project
team member, indeed every member of the workforce, needs to be persuaded to convey the attitude
that, just as they are stakeholders, every other project stakeholder is also important. It means
inculcating a universal attitude which says We care!, and a commitment to service, even if it
sometimes hurts.
It also means creating a project management environment in which every decision and action is
designed to make the stakeholder's experience better than it would have been had the project not been
implemented. It requires a focus 011 the quality of the stakeholder's experience at every stage of the
project, rather than an overriding preoccupation with computer printouts and weekly progress reports.
Since this relationship mirrors the project manager/team relationship, it is clear where the process
must begin. For in both the short and long term runs, it is through good team relationships that good
project management practices can be achieved. By attending to what the team members need in order
to perform their respective contributions, the project manager can establish effective relationships
with them. These characteristics of help and support as a cohesive team are, in time, passed on to the
project's stakeholders. This positive environment seldom goes unnoticed.
58
In developing project management strategies at the outset of the project, the project's executive should
recognize the important contribution that the role of human resources development and, specifically,
project management training can make towards improving the project's cultural environment. Such
training provides a powerful tool in developing competency and commitment to the project, in
improving team performance, and ultimately, in final project quality.
3.3.2 Effective Internal Project Management Strategies
Projects fail for many internal reasons, some of them technical, some of them managerial. However,
even the technical failures can often be traced back to a failure on the part of the project's executive
management to recognize and deal with these inherent technical risks. On the other hand, probably the
majority of apparently successful projects do not reflect their optimum potential either.
As a matter of project experience, a number of prerequisites have been identified with the successful
project. While these prerequisites do not necessarily guarantee success of future projects, their
absence may well lead to sub-optimal success, if not outright failure. The Project's Executive has a
vital role to play in achieving project success and should therefore insist on the following:
Executive SUlW0rt - The Executive must clearly demonstrate support for the project management
concept by active sponsorship and control.
External Authority - The project manager must be seen as the authoritative agent in dealing with all
parties, and be the responsible and single formal contact with them.
Internal Authority - The project manager must have the necessary managerial authority within his
organization to ensure response to his requirements.
Commitment Authority - The project manager must have the responsibility and authority to Control
the commitment of resources, including funds, within prescribed limits. The results of these decisions
must be both accountable and visible.
Project Mana~er Inyolyed in All Major Decisions - No major technical, cost, schedule, or
performance decisions should be made without the project manager's participation.
Competence - The project manager 'and his team members must be competent. Other functional
personell assigned to the project must also be competent.
Project Team - The project manager should have a say in the assembly of his project team, which will
help him to obtain their personal commitment, support and required quality of service.
Mana~ment Information Systems - Effective project management information and control systems
must be in place.
59
3.4 The Project's External Surroundings
On some projects, events external to the project sometimes come as a surprise to the project manager
and his team and are therefore seen as obstacles to progress. However, as noted earlier, projects
generally exist only because of that external environment and so it is essential for the project team to
recognize that they must also be responsive to it.
3.4.1 What is this Project External Environment?
It includes the established and latest state-of-the-art technology in which the project is based, its
customers and competitors, its geographical, climatic, social, economic and political settings, in fact,
virtually everything that can impact its success. These factors can affect the planning, organizing,
staffing and directing which constitute the project manager's main responsibilities.
This external environment represents a complex set of inter-dependent relationships, which constantly
react with the project as it is brought into reality. Conversely, most projects are intended to impact the
environment in one way or another, and this is particularly true of infrastructure projects. Therefore,
for the project to be ultimately successful, these inter-dependencies must be taken into account.
Even more important, the factors noted above have a habit of changing during the life of the project,
especially if the project takes a number of years to complete, and is brought on-stream in phases. This
translates into a high degree of uncertainty or risk surrounding the project, as a result of its external
environment. In fact, the greater the degree of interdependence, the greater the degree of uncertainty,
and the greater the challenge for the project manager and his team.
3.4.2 Not the Same for Every Project
Clearly, the environment will not be the same for every project. In fact, it is likely to be determined
principally by three considerntions, namely:
o the product or service resulting from the project,
o the technology and the manner of its application, and
o its physical location.
To identify potential difficulties stemming from the project's stakeholders, assess their probability of
occurrence, and to try to head them off in advance, the project team must learn to internct frequently
with those individuals and institutions which constitute the most important elements of the project's
external environment. Together with the project's sponsors, owners and users, these people constitute
the project's direct and indirect stakeholders.
60
3.4.3 Effective External Project Management Strategies
Prerequisites for avoiding internal project failure, or at least sub-optimal results, were discussed
earlier. However, it has also been noted earlier that external conditions and events also represent
uncertainty and risk to the successful accomplishment of the project. These conditions have been
linked to the external stakeholders of the project. Therefore, it is essential to develop a sound
stakeholder environment.
Developin" a Sound Stakeholder Enyironment
Just as the means of influencing the project's cultural environment, as described above, was one of
developing the right attitude, so it is with developing a sound stakeholder environment. Perhaps this
attitude is best reflected by adopting a mind set that reverses the traditional organization chart
hierarchy. In other words, place the project stakeholders at the top of the chart, followed by the front-
line project team members, and on down to the project manager at the bottom. Perhaps the project
team will then be better visualized as a truly service organization, designed to serve the best interests
of a successful project outcome, both perceived and in reality.
Suggested steps in this process include:

o Learn how to understand the role of the various stakeholders, and how this information may be
used as an opportunity to improve both the perception and reception of the project
o Identify the real nature of each stakeholder group's business and their consequent interest in the
project
o Understand their behaviour and motivation
o Assess how they may react to various approaches
o Pinpoint the characteristics of the stakeholders' environment and develop appropriate responses to
facilitate a good relationship
o Learn project management's role in responding to the stakeholders drive behind the project
o Determine the key areas which will have the most impact on the successful reception of the
project
o Remember always that even a minor stakeholder group may discover the "fatal flaw" in the
project which could bring it to a standstill!
61
3.4.4 Identifying the Project Stakeholders
One technique for dealing effectively with the project's external environment is to prioritize the
required stakeholder linkages by conducting a stakeholder analysis. Such an analysis would be
designed first to identify all the potential stakeholders who might have an impact on the project, and
then to determine their relative ability to influence it.
3.4.4.1 Stakeholder Groupings
Project stakeholders may be recognized in any of the following groupings:

o those who are directly related to the project, for example suppliers of inputs, consumers of
outputs, and managers of the project process
o those who have influence over the physical, infrastructural, technological, commercial/financial/
socioeconomic, or political/legal conditions
o those who have a hierarchical relationship to the project such as government authorities at local,
regional and nationalleve1s, and
o those individuals, groups and associations, who have vested interests, sometimes quite unrelated
to the project, but who see it as an opportunity to pursue their own ends.
3.4.4.2 Stakeholder Categories
Having identified the various stakeholders, each may be assigned to a category according to their
relative ability to influence the project. Three categories are envisaged, namely:
o those who are controllable
o those who are influenceable, and
o those who need to be appreciated.
Within each category, each stakeholder may then be further rated by degree of importance according
to their ability to influence the project. Appropriate members of the project team can then prioritize
their efforts accordingly to maintain the necessary stakeholder linkages, to give rise to the best
chances of ultimate project success. If the project is large enough, or the stakeholder linkages are
sufficiently intense, the project team's efforts may be assigned to a specific group within the project
team. Enter Project Public Relations.
62
3.4.5 Project Public Relations .
Traditional management has long since recognized the classic Input-Process-Output model with its
management feedback loop for controlling output, see figure 3. Dynamic managers also recognize that
opening communication channels in both directions constitutes a powerful motivator at the operative
level. Whether quality information is presented in verbal, written or graphical form, improvement in
performance can be quite remarkable. Indeed, many knowledge workers demand it, and the Japanese
have built their industrial reputation on the "quality circle", which uses this principal.
Management Process
Input Output
- .....@ [process)@ ..
, :\:
Control~ ~Monitor
~"""""'~"""""'::::
Management Feedback
Figure 3: Traditional Management Feedback
The principal is just as true in the field of projects, though regretfully much less evident on
construction projects. Nevertheless, on a major project, especially if it is publicly funded, providing a
general information centre is quite normal. A more proactive stance, or positive feed forward, is
usually known as Public Relations, or just PR, and becomes a vital part of the control of the
environment of a complex project. To a surprisingly large extent, the project team's ability to exercise
this positive feed forward will determine their ability to control the project in terms of its filial cost
and schedule.
This public relations feed forward concept is shown in figure 4.
Positive Feed Forward
Project Public
Public Feedback
Figure 4: Public Relations Concept
63
The Public Relations Plan
Good public relations requires a strong identity, a planned program and concrete goals, and
commences with appointing someone to be responsible. That person must be outgoing and positive,
yet able and willing to listen. He or she must be capable of preparing carefully constructed text and
presentations, and be able to work through a program systematically. Like every other major function
of the project management process, the PR function should be conducted like a sub-project.
In developing a PR plan, the following eight steps are recommended. It will be noted that many of the
recommendations made earlier are incorporated.
o Know the project organization and its objectives thoroughly
o Determine who the interested publics will be and the characteristics of each
o Establish the relative importance of each to the project, and in particular, identify the "high risk"
areas
o Assess the current reputation of the sponsoring organization as it is perceived by each of the
interested groups
o Determine appropriate action in each case
o Develop strategy, resource requirements, priorities and schedule which are in sympathy with the
project itself
o Implement the PR program
o Continuously monitor the effectiveness of the program during its execution, and adjust as
necessary for optimum results
Ensurin& the Effectiveness of the PR Plan
What are the hallmarks of successful PR? Here is a top ten check list of a good public relations
program:
o Care and concern genuinely expressed for the project's stakeholders
o Timely (rapid) response provided to information requests
o Information requirements anticipated and provided ahead of time
o Genuinely sincere appreciation expressed to a stakeholder for their inquiry
o Flexible personal responses provided, where special issues dictate
o Recovery from inevitable lapses of services during implementation, in ways that impress
o Project team members empowered to make decisions to solve urgent and obvious problems
o Stakeholder-friendly policies and procedures established
o Stakeholder-friendly facilities available both during project implementation, as well as
subsequently
64
3.5 Some Practical Examples
3.5.1 Advanced Rapid Transit System
A local government authority conceived an ambitious project to design and build 22 km of light,
intermediate capacity, rapid transit system through densely populated areas. Innovative features
included light driverless cars, magnetic traction, steerable wheels, and fibre optic based
communication and control systems. The cost of the project in 1986 was about $800 million.
With such a high profile project, a decision to establish a public relations function was taken at an
early stage. At the outset, the cost of the system was thought to be exorbitant. However, figures were
developed and shown graphically in the display centre to show that the estimated cost was realistic
when compared with similar systems built with similar capacities elsewhere.
Safety of the automatic driverless trains was another major concern. A major strategy in the project
implementation plan was to fast-track a one kilometer test section of the permanent elevated part of
the line through to complete temporary operation, at a very early stage. This section provided
invaluable design and construction experience. In addition, it was used for five months to give free
rides to more than 300.000 visitors from allover the world, while construction of the rest of the
system continued.
During construction, the alignment community was recognized as the most important stakeholder. All
homes within each area were kept informed of progress by a local news letter. In addition, a
construction "hot line" was established to receive complaints day or night, with someone available to
visit the scene at the earliest opportunity. The practice worked well and paid dividends. Perhaps the
most satisfying evidence was to be seen in the shift of attitude on the part of the local newspapers.
These strategies undoubtedly did much to build confidence, assuage stakeholder concern~, and
enabled the project to be completed early, within budget, and to a high performance level. The cost of
the PR effort amounted to approximately 0.6% of the total project budget.
3.5.2 Proposed Liquid Natural Gas Facility
A private company planned to build a facility to export liquid natural gas. The project would include
800 km of pipeline, a liquefaction plant, a marine terminal and a fleet of ships to deliver the product to
the company's customers. Planning approval required environmental impact and socio-economic
benefit studies, and to succeed would require the majority support of all those impacted by the project.
Assistance with public relations was obviously required, and a local public relations firm was hired.
Their major asset was in knowing local dignitaries and media representatives and in being able to
provide quick and favourable access to them. Very positive relationships were established with local
authorities and the local populations.
65
3.5.3 World Class Fair
The Provincial Government conceived the idea of a five-and-a-half month long transportation fair to
commemorate the 100th anniversary of the founding of the city of Vancouver. The site, which is
within walking distance of downtown, had to be expanded several times to the fmal size of 70
hectares to accommodate the 41 countries that finally took part.
The financial success of the project was heavily dependent upon exhibitor participation on the one
hand and attendance on the other. A major promotional effort was therefore obviously a necessary
part of the project. However, to be successful, the project also needed the support of the local
communities, who initially viewed the whole enterprise with considerable scepticism.
Therefore, a public relations effort was established quite separate from the hard-sell marketing effort.
The basic philosophy of the program was to create public interest, awareness and excitement,
establish a sense of ownership and thereby increase the number of local visitors. Particularly with
publicly funded projects, it is worth bearing in mind that the stakeholders who stand to gain the most
are not necessarily those who are impacted the most. In practice, they are likely to be the "vocal
minority", while the former sit on the side lines as the silent majority.
In the early stages of the project, the construction site became embroiled in a major labour dispute. It
became a test case for retaining closed union shop conditions on government work. The government,
on the other hand was determined that every company should have an opportunity to participate. The
project organization tried to negotiate a compromise with the unions and the government threatened to
cancel the fair.
Fortunately, the public relations communication with the media had been steady, open and honest.
Through the media, the issues were taken back to the public, and the majority public opinion
eventually prevailed. Except for the original four or five days lost, there were no subseque~t labour
interruptions. In due course, the fair was opened on time, within its prescribed budget, was very well
attended and highly successful. The cost of the PR effort was of the order of 0.4% of the project cost.
3.5.4 Water Storage Barrage Construction
Further afield, and some years ago, a well known national construction company secured the first
major water retention barrage construction project in Bihar, India. At the time it was the longest
barrage in the country. However, the entire area was known for its local labour problems.
The local village heads and leaders were invited to meetings in which the project, and particularly the
arrangements for employment were explained. Even though by law the company must employ its own
men first, the local elders were pleased to be consulted, and work was found for their people by
subcontracting. Certain tribes expected special recognition and treatment, if peace on the site was to
be maintained. This too was carefully nurtured.
66
The company also gave great attention to the facilities needed by its employees and their families.
Necessary schools, shops, tailors, hair dressers, a butcher, dhobi, atta grinding shop, and so on, were
all provided. Similarly, necessary buildings and facilities for messes for vegetarians and non-
vegetarians sections, South Indian and North Indian and Punjabi were also provided. Transportation
was provided to the local school, and outsiders were admitted to the project hospital facilities, which
provided free medical attention. An activity club was established where all levels of the project staff
could play and relax together.
As a result of these and many similar considerations, the project was completed on time and in peace,
including the periods of seasonal retrenchment and at the end of the project. This was a considerable
achievement given the time and place. Even though the project was built some years ago, the need for
cultivating a favourable impression amongst the native tribal groups was well recognized.
Clearly, the project management of the day understood the importance of managing the project
environment
3.5.5 Two Recent Hydro Projects
It seems that water storage schemes are becoming increasingly vulnerable to environmental concerns.
As if to emphasize the points made earlier, the following newspaper articles are perhaps worth
quoting.
The Indian Express. Bombay. Januruy. 1990:

"The controversial Tehri hydel power project in Uttar Pradesh is likely to go through, perhaps with
some changes to satisfy agitating environmentalists...After a marathon five hours of talks...chaifed by
the Minister of State for Environment and Forests, Mrs Maneka Gandhi, the environmentalists lost
some ground as it was decided to resume work which was suspended earlier this month....
"The meeting highlighted the clear divide between the groups for and against the project, and the
technical data and arguments presented by both sides confused even Mrs. Gandhi ... "
The Sunday Spectrum. Cal&ruy. Alberta. March 1990:

"Activity continues at Oldman Dam site...There is... a hub of frantic construction, even though nearly a
week ago three Federal Court of Appeal justices jerked the province's building licence and ordered
neglected environmental studies."
Clearly, there is still trouble ahead!
67
3.5.6 Consultants in Constructive Citizen Participation
Today, project sponsors and administrators are finding themselves spending more and more of their
time and resources simply reacting to conflict and crisis. To the surprise of many, they are discovering
that much of this is coming from the community around them, because now people have very
different values, goals and assumptions. As we have seen, this trend is likely to accelerate.
In fact many project delays and postponements and cancellations are unnecessary. Mistrust stems
from uncertainty, poor communication, inadequate information exchange, basic philosophical
differences, and general lack of credibility. Mistrust leads to confrontation, polarized positions,
inflexibility, and entrenched adversarial roles. Each party needs to at least understand, if not entirely
accept, the legitimate and differing interests, roles and expectations of the other.
Very often, the issue in the public's mind is not so much how to stop the project altogether, but how to
have their concerns integrated into its strategic planning. However, once conflict has developed,
special dedication and skill is required in its resolution. Better still is the constructive participation of
the citizenship at the outset.
Consequently, consultants are now to be found who have developed various techniques for working
constructively with stakeholder conflict, or who specialize in acting as independent mediators through
communication, education, analysis and soliciting alternative courses of action.
4. Summary
Clearly, the project manager's job is no longer confined to controlling events within his or her own
project organization. It is no longer sufficient to think of project management as siPJply the
monitoring of time and cost by planning, scheduling and resource leveling, as many software
programs might have us believe. Nor even is it sufficient to include the many other organizational
tasks of the project manager, as leader of the project team.
Vitally important as all these things are, these are not sufficient for effective and successful project
management in today's dynamic world. What is equally important - often more so to achieve a
successful project outcome - is the need to track the project's linkages to the external environment
This is especially true of infra-structure projects which place emphasis on development and
innovation and must respond to increasingly rapid change.
The reason is simple. Every construction project exists for a purpose relating to, and within, its
surrounding environment. Therefore, its creation and implementation must be responsive to its
environment by maximizing the benefits, as far as possible, to all the stakeholders, and minimizing
the adverse impacts by deliberate mitigation. Clearly, how the project manager works within the
project environment can make all the difference between the success of the project and its failure.
68
References
Asian Development Bank: Analyzing the Project Environment. 13th ADB Regional Seminar MS,
Manila, Philippines 1987
Connor, D. M.: Promotional Literature. Victoria, B.C. 1989
Nagabhushana Rau A.: A Case Study of Human Management at a Construction Project Paper
presented in Bangalore, India: Association of Consulting Civil Engineers, New Delhi 1990
Wideman, R. M.: Cost Control of Capital Projects. Vancouver, B.C.: AEW Services, 1983.
Wideman, R. M.: Good Public Relations, an Essential Part of Successful Project Management.
Denver, Colorado: Project Management Institute, Seminar/Symposium Proceedings, 1985
Wideman, R. M.: Successful Project Control and Execution Keynote paper, INTERNET 88
Proceedings: London 1989
Wideman, R. M.: Total Project Management of Complex Projects, Improving Performance with
Modem Techniques Presentations in five cities in India: The Consultancy Development Centre, New
Delhi, India, 1990
69
Eric Gabriel
Abstract
The cultural and behavioural aspects of Project Management have replaced the systematic and
procedural approach. The large projects in "third world" countries left little in place but a plant, and
dissatisfaction. Project Management methods must reflect the culture of the country and the industry
involved. In these days of rapid and continous social and industrial change, Project Management has
emerged as a suitable tool for control, because a Project is by definition a social grouping for
achieving objectives through a complete cycle of change. INTERNET since ist inception has been
highly succesful in achieving co-operation between nations, forgetting cultural differences, yet at the
same time accepting them. It has an important contribution to make, showing how an understanding
of Project Management principles can help societies to evolve with the 21st Century.
1. Introduction
1.1 Systems to Persons
The transition from a systems based approach to Project Management to an interpersonal approach
has been well noted in recent years. Project Management in its earliest days of development was
synonymous with network analysis, and indeed in some countries it remains so. I will refer to this
interesting phenomenon again later. For the majority of countries, however, the preoccupation with
systems was related directly to the explosive growth of the computer, and electronic data processing.
Drunk with the excitement, power and novelty of the new machine, the practitioniers began to use its
capability because it was there, and not because it was needed. As a result, by 1980, the headlong
flight to computer based project management systems was in progress, and gaps began to open up
between these systems and the project managers with the responsibility to manage and deliver.
About this time, A.P.M., the U.K. national organization of INTERNET, set up a working group which
produced a paper entitled 'Closing the Gaps in Project Management Systems'. Clearly the problem
was widely recognized, because the theme of the INTERNET World Congress in Birmingham,
England in 1976 was 'Bridging the Gap'.
This was the critical time in the early 1980's when the whole approach of Project Management in
Europe changed in emphasis and in direction. We became aware of needs in place of the hitherto
mechanistic ideas that Project Management was easy if one obeyed some simple rules and used a
particular make of computerized system. This self appraisal and self criticism by the whole
INTERNET family was the precursor to rapid change, as indeed it always is in any grouping of
society.
1.2. Recognition of Cultural Problems
In the 60's when very large Projects became the nonn particularly in the power- and petrochemical
industries, great strides were made in the development of Project Management methods, and in the
training of Project Managers. However, a re-reading of papers around that time gave the unmistakable
impression that there was a method or a system of universal application. This crock of gold was
hidden inside the words of a large proportion of the papers. Perhaps for this reason, some of the very
large projects in third world countries were executed using largely expatriate staff with a minimum
involvement of indigenous people. Even the local companies in the countries were managed by
expatriates. Inevitably, this led to dissatisfaction in those countries. Technology transfer came to mean
the building of a high-tech facility in a developing country by expatriates, who on completion left
only the plant behind them. Managerial skills were not transferred for the reason that, as it became
clear, no allowance was made for cultural differences, and methods and techniques and organizations
were simply imposed in accordance with some pre-conceived ideas and structures.
Cultural problems and needs came to be recognized, and initially the action was confined to educating
the Project Managers in the culture, traditions, and sometimes the language of the country. This was a
welcome move, but only limited in success, because the basic approach was not modified, only the
means of implementing it. Only in recent years, i.e. the late 80's, developing countries have become
aware of the need to develop and train their own Managers, and they have come to realize that this is
not simply a matter of managing Projects better, but it is fundamental to the succesful economical
development of their country in the 90's.
72
1.3. National Characteristics
It is possible to identify certain broad characteristics in the approach to Project Management in

different countries. In the U.S.A., for example, the emphasis is on large scale and attention to detail;
the German approach tends to be systematic and highly structured; the U.K. approach was based
strongly on software development and utilization; the Japanese on rigorous planning and consensus.
These admittedly superficial characteristics nevertheless mean that a pooling of the approach of the
various countries will be a powerful tool for the future. This does not mean copying one country's
approach in another, for this almost inevitably fails. It fails precisely because the approach is based on
the culture, and one cannot import or change a culture very easily or quickly. From the integration of
these approaches, a common basis for Project Management is emerging.
I propose in the rest of this paper to discuss this and look at the developments which are likely to
emerge.
2. Attitude to Change
Project Management is all about change. The unique characteristic of a Project is that it possesses a
life cycle with a start and a predictable and controllable finish. Two aspects are current the
characteristic of the change and its timescale.
Telecommunications and computers have brought about a very rapid transfer of infonnation and
knowledge worldwide, in a way that was never hitherto possible. Without these methods it was
necessary to rely on words spoken and written, and highly technical learned papers. Now with the
transfer of infonnation by computers and software and telecommunications, knowledge and
experience is transferred in a much more fundamental way. The speed of change is now very'rapid
indeed, change of a magnitude hitherto only achieved by extreme violence.
The two types of change are in technology and facilities, e.g. bridges, refineries, roads etc., and in true
technology transfer in which people share in the change. There is a limit to the rate at which change in
lifestyle and attitude can be achieved. This is why Project Management is assuming ever greater
importance, because it addresses this very problem. To execute a Project, an environment of people,
materials must be invented and developed until on completion it ultimately disappears. In applying
Project Management to problems of change the same sequence is applied to the problem until
ultimately the problem disappears.
The important aspect of Project Management is to emphasize the 'what' instead of the 'how'. As
discussed earlier, the large projects were obsessed with the 'how', without due regard to cultural
problems. The correct approach and the successful one is to be concerned with the art of the possible
and not the how of implementation. The emphasis is on objectives and not on methodology. We are
more concerned with arriving than with the actual journey itself. I recall a fascinating conversation
73
with a very good Egyptian friend at the Expert Seminar in Cairo in February, 1990. In essence, what
he said was this: - It's all very well for AngloSaxons to say we need to do this and this in this way and
that way so let's go. In Egypt it is necessary to say we need to do this and this and my father is so and
so, and this particular time is not possible, and this person will require those conditions to be satisfied.
This is not a bad feature, simply different Any attempt to impose procedures in either direction which
are at variance with these precepts will fail.
3. Organizational Differences
A very important research project carried out by Professor Gray amongst PM! and INTERNET
members, analyzed the different forms of PM organization structures in the five stages from a pure
matrix to a unified task force.
There were distinct differences between different countries and also between different technologies.
Size of project was also a critical feature in deciding which method to use. It is not appropriate to
repeat the findings and the general discussions here. They have been well documented and discussed.
What I will do is to point to a trend which appears to be changing the emphasis of Project
Management towards the client.
I believe that the early moves to the establishment of task forces arose from a failure to make the pure
matrix method work. In the modem organization, however, where functional hierarchical
organisations are giving way to matrix forms anyway, I believe that the task force approach will
decline in importance. One could say, in fact, that the task force is an escape from matrix, in that one
sets up a project culture which is to some extent isolated from outside. The approach certainly
concentrates attention on the Project very successfully but at the expense of strains on other
,
relationships in different ways.
With the advent of microcomputer based information systems and the fax machine, information can
be exchanged and collected very rapidly worldwide. This makes possible the direct control of the
Project by the client or the owner, using a very small team of two or three people. This was difficult or
even impossible in the past.
An interesting example of the different organizational approaches was given in a paper by Anton de
Wit. It concerned two oil rigs of similar design for two different clients, one maintaining a large client
organization and the other a small client organization. Both projects were rather successful by the
respective companies, and both finished on time. One cost 30% less in Project Management cost than
the other. The company which utilized a large client team produced a culture within the Project which
inevitably produced higher costs because there was less delegation and more interference in detail
with the people doing the work.
74
If we combine direct hands-on control by client, with the use of a small team, 2-3 people at most, we
have a form which is able to take into account the culture of the participants yet not heavy enough to
produce a client culture which could conflict with the Project requirements.
4. Small is Manageable
Much is written on the subject of the control of large Projects. In considering them, I am forced to the
conclusion that there are few lessons to be learnt which are transportable from one large Project to
another. Everyone is fundamentally different, not at least in its culture and type of organization.
The Channel Tunnel Project is huge, with high risk, but not complex, compared say with a large
nuclear power station. Nevertheless, there appear to be fundamental problems despite the great
experience and abilities of everyone involved.
The problem comes back to organization and size. Particularly in the U.K., the environmental and
logistics problems are immense and impact directly on social and political issues. These are social and
cultural features which cause all the problems. Well, not all of them, the other problem is one of sheer
size of Project and size of organization. Then the Project team becomes so large that itself is required
to be managed; who is managing the Project then?
A medium sized Project up to say £30 million is manageable. A medium sized Project which is
completed in under three years is manageable. Any cost or time exceeding these figures produces a
problem of organization and change which may be insoluble. Freeman Dyson in his book 'Infinite in
all Directions' challenges the benefits of economies of scale and goes so far as to say that any Project
which takes 10 years to bring it to fruition will be very expensive, and when completed will be out of
date. He cites this as a reason for the abandonment of the nuclear power programmes and the space
programmes.
I believe that these arguments also apply to Project Management. Large Projects should be planned as
a number of small projects with autonomous Project Managers. For example, a twin tunnel system
should have two separate Projects for each of the tunnels which can compete. The economy of scale is
a myth. It is a paper economy only and a very short term. What is gained in scaling up is more than
lost in inefficient performance.
Another factor is that over three years people involved in the Project will leave and be replaced,
which leads to a lack of commitment and continuity and career problems. The very long term Project
becomes institutionalized. It is impossible in practice to obtain individuals commitment to distant
objectives over such long periods. The Project Manager than becomes to all intents and purposes a
General Manager and what should be the management of change becomes the management of a fairly
static enterprise, thus increasing delay and cost yet more.
75
5. The Myth of the Developing Country
The idea of the "developing country" goes back to the early days of Project Management, when it was
thought that all one had to do was to build large facilities, developed-country style in third world
countries. This did not take into account either the shortcomings of the methods used in the developed
countries nor did it consider the long term needs and wellbeing of the receiver countries.
Industrialized and developed countries have their own cultural problems. In the U.K. for example
there is a culture gap between private and public sectors. Project Management works quite well in the
private sector, but it works badly or not at all in the public sector. The reason for this failure in the
public sector is precisly because of the culture in those institutions, bureaucratic, with blurred
responsibilities, annual budgets not carried over from year to year, etc. These problems are quite as
difficult as the cultural problems in so called developing countries. The management style depends on
the culture.
Czechoslovakia has been a valued participant in INTERNET activities for many years and holds a
very important international symposium in network analysis every year which is always supported by
INTERNET. It is interesting that the emphasis on network analysis remains whereas it has long gone
in most other cou~tries. This is surely a cultural effect, the network being theoretically an instrument
to achieve central planning and control. With the recent changes I would not be surprised to see the
topic of this annual symposium change away from the network and towards the organizational and
interpersonal aspects.
The U.K. moved very fast to the interpersonal skills approach, largely because of its unstructured
economy and its inherent class structure in society. This contrasts with the Czech structured economy
and unstructured social system. All countries are developing countries.
The problems of each country are unique, and what Project Management and INTERNET must do is
to bring to bear the basic skills and know-how of Project Management to work within the cultural and
political framework: of the country concerned.
6. Future Development
There is a basic core of the Project Management approach which must be teased out and identified so
that flexibility can be retained in implementing Project Management in any society or organization.
The country itself can then build on the basics.
This is quite different from the body of knowledge approach, which seems to identify a total
expression of principles and skills. This body of knowledge is important but it is not the core of
Project Management. Who is to write a section on quality in Project Management which would be
equally applicable to Japan and the U.K.? Attempts to import quality circles, just-in-time and other
Japanese based approaches have not in general been successful. However, it is significant that the
76
Japanese themselves have succeeded in applying both of these methods in companies set up in the
U.K. This has been done not by the application of techniques as usually approached by academics and
others but by fust setting the culture within the company.
There are two possibilities to change the culture in order to achieve Project results or to achieve
results within the existing culture. Both are possible. Both can be seen in progress around us in
Europe and in the world.
INTERNET is a valuable test mechanism for future development of Project Management on the lines
I have indicated. It knows how to achieve co-operation, how to forget the cultural differences yet
allow for them in our relationships. Most of all, it understands and respects these cultural aspects in
applying Project Management It provides a forum for mutual help and interest.
My own enjoyment in membership of the INTERNET family is precisely because of these
relationships which are unique in my experience. It is a privilege to be associated with INTERNET, it
is a privilege to have had the opportunity to work with and co-operate in some small way with Roland
Gutsch who has been a tower of strength in the organization from the very beginning. I am sure that
INTERNET and Roland will continue to prosper for a long time to come.
References
Closing the Gaps in Project Management Systems, APM/Butterworth.

Fifth INTERNET Congress - Project Implementation and Management - Bridging the Gap,
Birmingham 1976.
MES/INTERNET third International Symposium Cairo, February 1990.
De Wit, A.: Cost Effective Owner Project Management. The Challenge for the Future. In:
Proceedings of the 8th INTERNET World Congress, Rotterdam 1985.
Dyson, J.F.: Infinite in all Directions, 1989.
77
Morten Fangel
1. Introduction
To deal with the viking approach to project management may sound like a bit of a joke: What has the
viking approach to do with today's project management in the Nordic countries and elsewhere?
In spite of the risk of not being taken seriously, this paper tries to clarify the viking approach and to
indicate how today's Nordic project management reflects this approach. Inspired by the viking
approach, this paper also describes some trends in Nordic project management.
The simple idea of the paper ist that the viking approach and Nordic project" management are rather
similar for two reasons. Firstly, the vikings really seemed to make successful management wherefore
their approach also may be found in today's project management. Secondly, project management in
any context reflects some culture conditions which do not change that much - even during a period of
a thousand years [2].
The paper may therefore also be seen as a modest contribution to the coping with cross culture
differences which is essential for any international interaction on the advancement of project
management.
Valuable impulses for the analysis of Nordic project management and the attempt to draw lines to the
vikings have been received from all the Nordic associations which join the NORDNET cooperation.
2. The Viking Approach
The purpose of investigating the viking approach is to draw lessons from an epoch with lots of
successful projects which created welfare and wealth as well as "landnam" i.e. incorporation of new
land at for example the Farce Island, Iceland, and Greenland.
With the word from an ancient history book "the Nordic people proved for more than two hundred
years, from before 800 up until approx. 1050, a remarkable capability to spread over new countries.
The Nordic hosts established themselves westwards in England and eastwards in Russia, they occured
in thousands in France, they harried the Mediterranian coast and they settled down in Constantinople,
in the Emperor's court. It is a Nordic time of expansion like the English one in the 18th and 19th
century which lead the English in large crowds to all the coasts of the world". [3]
There seem to be several determining factors by the viking period and their success in making
projects:
o Settlement in the Nordic home countries has reached a point where many young men, in
consideration of the continuous increase of population, found it much too heart-breaking and
ungrateful to clear new land and maybe get involved in feuds. The projects allowed them to
escape from this routinelike task.
o The development of unified kingdoms in both Denmark, Norway, and Sweden during the viking
period did, on one hand, limit the activities of the regional earl including mutual fights which
might have been the purpose of the unified kingdoms. This left a potential of managers consisting
of the sons and relatives of the regional earls. By joining the viking projects these managers more
or less got rid of a tightening line organization.
o On the other hand the unified kingdoms also proved to be useful as a coordinating body for major
raids.
o The shipbuilding technology had been developped during several hundred years so the vikings
were capable of building long and light ships mostly pushed forward by cars.
Let us now focus on the specific viking projects and try to draft some characteristics without having
made major research and well knowing that the characteristics might have changed during the viking
period:
o A viking raid seems to be initiated with a realvision far beyond what was going on at home: If
they succeeded, the participants would improve their living conditions considerable.
o A raid was also connected with great risks and threats. It took courage of the vikings to sail
westwards and make a landfall.
o The vikings did not only impose their way of life to the new countries. They were sensitive to
what they experienced and seemed to be proud of bringing home new impulses.
o Each raid had a limited duration of one or a few seasons which allowed them to mobilize extra
effort while the project was going on.
o The initiatives to have a raid seemed to come both from local regions and from the kings but in
any case it was essential to get full acceptance from the parties in the raid, and the final decision
whether to go or not may even have been made by voting.
o Each raid must have been rather well prepared and planned, but the plans have presumably been
adjusted to new possibilities and new conditions. Who would plan to make a raid towards Paris
not knowing if Paris did exist? However, nature and weather gave respect for a certain milestone.
80
o A raid was often organized across the upcoming kingdoms. A raid towards southeast might have
consisted of Danes and Norwegians from the Oslo Fiord area (called "Viken" from where the
vikings got their name) and Swedes from the Vast Goten.
o A raid included a number of small manoeuvrable and autonomic units which also satisfied the
individualistic attitude of the vikings and their need for feeling equal.
o During the raid, the participants were working hard both by rowing the ships and by fighting.
When the winter came, they slept night and day.
o For the vikings, ceremonies were an essential part of a project. Once that a milestone had been
reached, they surely arranged a big party - and coming home from a successful project, the party
at the viking hall did take several days, perhaps weeks!
These characteristics of the viking approach lead to an idealized check-list. Of course, the viking raids
were not at all easy. They had internal problems and used rough methods - especially when the vision
of a project was threatened. But from a point of view of the Nordic people, they did make successful
project management - that is as long as they used their talents on raids.
During the 11th century, they turned out to be more ambitious and tried to develop institutions such as
to manage the entire kingdom of England and this lead to the collapse of the period of the vikings.
3. The Nordic Approach Today
Immediately Nordic project participants may identify themselves with the ten characteristics of the
viking approach. Spontaneously they may promote these characteristics to be criteria of successful
management or sign the thesis that Nordic project management implies use of the viking approach.
However, to be more serious, we shall now extract a few statements on project management in the
Nordic countries which definitely indicate state-of-the-art:
o It is quite normal to have a cooperation with project environment including the client and the
authorities. They are bas..... considered cooperation partners, not enemies ...
.. But their sensitivity towards the environment may cause that there will never be a result of the
project!
o A relatively long period is used for defining the mission and objectives of the project. It is
essential to listen to the participants and get their acceptance..
.. Otherwise you can be sure that they will mostly be sailing their own course throughout the
lifecycle of the project!
o A stepwise planning of the processes will be carried out with periodical evaluation of the strategy
of the project..
81
.. It is damned difficult to convince anybody to use standard methods and procedures!
o The project organization will mostly reflect a group structure and have a minimum of levels. The
participants must have a feeling of steering their own ship or sub-project. Then you can count on
their cooperation also concerning the project as a whole..
.. By not allowing much interaction the participants might feel uncomfortable and thus minimize
their involvement!
o The participants also like the feeling of participating in a raid. You can count on their contribution
of resources when it is really needed. In this case they might work night and day ..
.. But don't try to motivate them by saying that they have to do something because the result is
needed in two months. They will continue working on other projects or sleeping!
o It is rather easy to develop a good team work. The participants will on beforehand accept that it
pays off for everybody to cooperate and most of them will contribute to the balance of the
interests in the group. You can also mostly count on the loyality of the participants and the
achieved agreements ..
.. But by ignoring the group process you can also be sure that they will have no respect for your
decisions. They will find even sophisticated method to avoid the effects of these decisions!
The key-word of the whole story on Nordic project management is cooperation more than
management. This is also reflected in the use of terminology:
The parallel to the English or American label implementation of project management is, in today's
Nordic language, directly translated implementation of the project working methods or project
cooperation.
This seems to reflect some cross culture differences which we generally should not try to ignore but
on the contrary try to understand and ...... in a fruitful way.
4. Trends in the Nordic Approach
Let us complete this attempt to follow a specific approach to project management by indicating some
ongoing or future trends in which project management is or should be handled at least in the Nordic
countries:
o The projectworking methods will be broadened to new types of tasks and at all levels in the
corporations. The reason is a need for more effective development and delivery. But with
reference to the vikings the project working methods might also meet some basic desires.
82
o The increasing number of projects means that project participation will be life-style for more
people. An extreme vision is that we are approaching project organized societies and that general
management more and more is going to be like project management. [4]
o At the same time the importance of a real vision of a project seems to be more and more essential.
The success of the project will also be even more depending on the commitment of the project .
manager and other key-persons and their capability to keep this vision alive in the minds of the
participants and the environment
o Our projects are going to be more international. Here we can learn from the vikings in real
combining resources from severa1 countries - and even a more or less violent cooperation with the
"client" in the foreign countries. There is a major step to be taken going from making international
projects by a sum of national sub-projects into having a project with cross national representation
at all levels.
o Though, in the Nordic countries, we have a tradition for team work, we need an even better
utilization of the hidden forces and talents of each human being. This is not at all easy. It demands
courage from the project manager to be real open and to be in the boat together with the
participants contributing actively to the hard work of the group.
o We are going to be more realistic on the advantages and disadvantages on the project working
methods including the bulk of techniques for project planning and management We have to
accept that some projects can succeed without the use of sophisticated methods. The analysis of
ancient approaches may help us to reinvent the basics of project management The purpose should
be to change the image of project working methods from being a cooperation method for good and
well-meaning human beings - towards a fruitful method for fighting together.
o When managing a project we must be more aware of the use of ceremonies througout the life
cycle of the project Inspired by the vikings we should organize ceremonies more actively as a
management tool.
Following these trends the future of Nordic project management will even more be reflecting the
viking approach!
83
References
[1] The first presentation of the article at the NORDNET-INTERNET-PMI conference in

Reykjavik: '87 the author represented the NORDNET which is a cooperation forum for the
Nordic project management associations in Finland, Iceland, Norway, and Sweden - and with
contact to Denmark where the association was terminated by '85. The label NORDNET intends
to reflect the relationship to INTERNET, but we do not have any separate organization with its
own by-laws. According to our unwritten "by-law" we can have a fruitful cooperation if each
association, continuously contribute actively - and no association is trying to dominate the
others.
[2] In May'88 the article was first published in the International Journal of Project Management.
[3] At the closing of the seventh INTERNET World Congress'82, Geert Hofstede from the
Netherlands decribed consequences of culture differences in work-related values. A remarkable
conclusion of his Institute for Research on Intercultural Cooperation is that the values
determining work relations are changing very slowly.
[4] The quotation from the viking epoch is from "Vor historia" (Our History) by Johan Ottosen
published in Copenhagen in 1902. This book has been a major source of the introduction to The
Viking Approach wherefore it may not fully correspond to the latest wisdom from historical
scientists. Furthermore, the author of this paper has added some reflections on his own account
[5] The visions of the project organized society and the company management like project
management was presented at the frrst NORDNET symposiom which took place in Stockholm
1983 - and the latest development seems to prove a tendency in that direction. For instance, at a
Nordic symposium in 85 in Copenhagen, a seminar on "Corporate Management just like project
management" draw a larger audience than any other topic.
84
Hasso Reschke
Abstract
This article describes interrelation between project management and corporate strategy. Those can be
seen in the development of strategies, in projects as elements of strategies.-and in project management
itself as a strategy factor. This conclusion is that top management must become aware that strategy
managing means managing through projects.
1. Introduction
Project Management has been used throughout the world and in many different companies and
industries in order to run projects more efficiently and to better ensure achieving the preset goals.
Most Project Management techniques still aim at improving the planning and control functions for
single projects. Multi-projecting is often reduced on capacity planning and capacity (re-)allocation
and often still works insufficiently. So far Project Management has been a task which was to be
carried out mainly by lower and middle management in the various companies and organizations.
More and more, however, companies and other organizations now become aware that developing and
translating into action of any corporate strategies can also be understood as a project or better a
network of projects and that Project Management can itself be a strategic factor for the company. This
results in increased interest of top management for the philosophy, techniques and particularly the
benefit of Project Management
2. Interrelations Between Corporate Strategy and Project Management
2.1 Strategy Development
A first interrelation can be seen in developing a corporate strategy or major elements thereof. This
development process can be understood as a project leading to a result. a "product" which would be an
agreed strategy for the further development and behaviour of the company.
Some characteristics of this type of projects can be found in:
- high complexity because the project has very many implications inside and particularly outside
the company
- the goals of the project can only be very roughly dermed in the beginning of the project and
development of goals and of the project itself goes more or less in parallel
- Planning and control of the project is very difficult because of the so many uncertainties in the
project itself and mainly in the project (and company) environment.
- Mostly subjective opinions, forecasts, appraisals, evaluations by many persons of different
hierarchical positions, different knowledge, different intentions and personal goals have to be
merged in order to arrive at a generally accepted and generally understood corporate strategy.
- The Project Manager has to run the project and at the same time has to act permanently as a
moderator, sometimes even as a priest.
2.2 Projects as Strategy Elements
Another interrelation between projects and corporate strategy lies in the realization of stra~gic goals.
It is obvious that each taken strategy consists of a number of differentiable tasks which need to be
executed. These actions are usually treated as single projects each directed by a project manager. To
arrive at the various necessary projects the strategic goal has to be broken down into a set of subgoals,
in terms of content and time, each of them forming the specific set of goals of a specific project.
Breaking down of the goals requires the development of a system of consistent goals. Accordingly, a
system of projects is created (or better: should be created) with many interrelations between the
various projects. Who then, and where is the "Super-Project-Manager?". Is it top management and are
top managers aware of this?
Although it is necessary for a project to be clearly defined against all other projects this system
involves many interfaces. Therefore one project cannot be seen as standing alone although it should
from project planning and control philosophies but is linked with many other projects, their goals,
their results, any set-backs, changes, opinions. The project manager therefore has to drive his project
in order to reach his goals as well as to observe the "project environment" inside and outside the
company at the same time and permanently. Again we are in a very complex situation.
86
2.3 Management by Projects
One more interrelation between Project Management and corporate strategy results in what is
nowadays called "Management by Projects". More and more tasks in companies and other
organizations are of a project nature and are actually handled as projects. This change in the nature of
the tasks affects also the company's organizational structure. Flexibility is required, not long and very
formal decision procedures but short and direct communication and coordination. People's behaviour
in the organization has to change. Not strong and strictly limited organizational units (sometimes
called "kingdoms") but ad-hoc teams which form and dissolute as the project tasks require. In this
kind of an organization challenges can be faced, opportunities can be taken and critical situations can
be mastered. "Management by Projects" therefore means not only running projects successfully but
using the flexibility of project management as a basic philosophy for managing a complex
organization in a complex company environment. "Management by Projects" is therefore a mean also
for personnel development.
3. The Impact of Corporate Strategy on Projects
Corporate strategy defines the overall goals of a company for the future development, breaks the goals
down to several levels and to certain strategic fields like markets, technology, fmance, and expresses
the basic philosophy of the company i.e. setting rules how the company should behave and what
should be basically taken into account in decision making. Further in the strategy the basic and overall
steps necessary to achieve the strategic goals are set.
Translating the corporate strategy into actions creates projects. In this respect we can define Project
Management as the "Management of Change".
There are several crucial points within the strategically linked projects. First of all, company
management which is responsible for the effectivity of the strategic goals has therefore an important
role within the management of the projects derived from that strategy. Actually top management is the
project manager of the strategy and has therefore also the responsibility to select and define effective
projects. It has to communicate the strategy and the environmental situation of the strategy to those
who will be charged with a distinct project. Big efforts have been taken in defming and agreeing upon
the objectives of a project since this is the point where control on further actions at least partially slips
away from top management to others in the organization which are to execute the project.
As always, such interfaces can and often do create problems, in this case the risk of misunderstanding
the intentions with the consequences that the original goals which were in mind of top management
might not be reached.
87
Creating a project and appointing a project manager is delegation of certain tasks and successful
delegation requires intensive self-preparation by the person who delegates a task in order to avoid
failures.
Top management is not discharged from the project after having agreed on defined project objectives.
Top management has various additional roles during the course of the project. One is the umbrella
function for the project manager and the project team. Top management has to accompany the project
all the time and support it through the necessary decisions, through demonstrating the importance of
the project and creating and maintaining motivation in the project.
Since projects have to be executed in a dynamic environment it is also the role of top management to
review the strategic objectives whether or not they are still in correspondence with the strategic
environment and consequently whether or not the project goals are still in correspondence with the
strategy or whether any changes there affect the project process and execution.
With this we speak of another dimension of project control. Not a certain delayed date or a certain
more expensive purchase but the general direction of the project is of major importance. Down in the
project one can save 1000$ here and 5000$ there. Up in the project - strategy link: one can spend one
million $ here or save two million $ there.
Usually the best points in the project course for this kind of strategic reviews are the ends of the
various phases in which a project can be and often is devided. Further major milestones (i.e. critical
design review, start of purchase phase) can be such strategic review and decision points. The basic
question here is: "What will happen with the project? In which direction shall we lead the project?"
A strategy usually consists of a number of different projects. The project manager in charge of a
single project tries to achieve his project objectives. Top management must take care of the
interrelations between the many different projects so that they form a coordinated system with the
strategic goals as the overall result to be achieved. Thinking in project families rather than in single
projects seems to be required. This integrative function is extremely important from the very
beginning of the first deployed project and it calls for new forms of making the relations between the
projects visible. A map of the strategic project landscape (the network of projects) or family trees
might be an appropriate mean.
4. Conclusion
If we look at the recent (=30 years) development of Project Management the progress achieved seems
to be respectable. Everybody talks about projects and a lot of them have already grasped the meaning
of Project Management. Although we are often not aware of the fact that we handle more and more
complex projects and even families of projects in a more evidently becoming complex environment
with even shorter time and budget limitations we can say that the tools and methods and philosophy of
Project Management has had its part in this development. On the other hand the better we run big
88
projects from an internal point of view the more we affect our natural environment But we are in the
process of becoming aware of this development.
When we look into the future we see much more important responsibilities coming on us than we had
to bear in the past What a company does it doing through projects and what a company changes it
changes through projects? And all the actions and changes affect not only the company and its
position in national and international markets, it affects the personnel and their families it affects the
economies and the welfare in general.
These responsibilities are mainly with the top management and top management must become aware
that it strategically acts through projects with other people in the organization (Project Managers)
execute. In this sense Projet Management is not a luxury, well-run company can afford but Project
Management philosophy is the major edgestone in corporate strategies.
References
Cleland, D.: Project Management: Strategie Design and Implementation, New York 1989.
89
Project Manage:ment
Techniques
and
Project Manage:ment
Software
PROJECT OBJECTIVES IDENTIFICATION AND PROPER FORMULATION FOR

PROJECT SUCCESS
Riccardo Albonetti
THE EVOLUTION OF MANAGEMENT TOOLS AND THE EFFICIENCY OF PRODUKT

DEVELOPMENT & ENGINEERING
Pieter Jan Blankevoort
OPERATIONS RESEARCH AND PROJECT MANAGEMENT· PAST, PRESENT AND

FUTURE
Heinz Schelle
DEVELOPMENT OF METHODS IN PROJECT MANAGEMENT • A SUBJECT FOR

THEORISTS ONLY?
Dietrich Muller
EXPERIENCES FROM A NEW LOGIC IN PROJECT MANAGEMENT

Steen Lichtenberg
THE APPLICATION OF KNOWLEDGE IN PROJECT·MANAGEMENT

Jurg Brandenberger

Per Willy Hetland
SPONTANEITY OR PLANl'ilNG DEFICITS IN SYSTEMS SELECTION AND

APPLICATION OF PROJECT SOFTWARE
Sebastian Dworatschek
DEVELOPING KNOWLEDGE BASED SYSTEMS IN CONSTRUCTION MANAGEMENT

AdolfSchub
MANAGEMENT BY PROJECTS· A TURN AWAY FROM OR TOWARDS HIERARCHY

Wolfgang Schallehn
PROJECT OBJECTIVES IDENTIFICATION AND PROPER
FORMULATION FOR PROJECT SUCCESS
Ricardo Albonetti
Abstract
The paper discusses the different types of project objectives and their identification.
Some objectives are explicitly explained in project documents, others are not. Some objectives are
implicit in project conditions and constraints: they must be discovered, identified and properly
formulated. Other objectives may be instrumentally explained in order to increase effectiveness and
determination of project participants. The nature of internal objectives and conflicts between the
project objectives and company objectives are also discussed.
1. General
Identification of valid objectives to pursue has always been one of the most important factors for
achieving success in any human activity.
A man needs to focus his attention on the objectives to be reached, in order to properly direct and
concentrate his efforts and obtain the necessary satisfaction when such objectives are achieved. Lacks
of valid objectives leads to apathy, to disbandment and to disorientation which are followed by" a fall
of attention, loss of tension, reduction in efficiency and effectiveness.
The above is, of course, applicable to the members of any project team: they have to focus their
attention on objectives in order to ensure that they contribute the maximum effort in implementing the
project successfully .
2. Explicit Objectives
Of course, a project would not be a project if it had not at least one declared or main objective;
however, having identified such an objective is not sufficient to provide a sound basis for project
success.
More frequently, projects have a number of declared or explicit objectives which must be brought to
the attention of all the project participants.
The named objectives may have a different degree or level of importance and priority and this must be
also ascertained and made clear.
If, for instance, the project objectives are:
a) to build a factory which should be operative at a certain date
b) to build a residential center for the employees
c) to build a shortcut road connecting the factory and the residential center to facilitate employees'
transit.
It is clear that the priorities are in the order shown above.
However, the situation is not always so clear and, therefore, an in depth analysis is required in order to
establish priorities. In general two or three levels of priority may be identified.
Priority one is generally recognized to the objectives which should be absolutely achieved to ensure
project success: they are going to be the main indicators of project success; they must be achieved!
Priority two is generally recognized to the objectives which are important but could be, at least
partially, sacrlfied if necessary to favor or ensure achievement of objectives having priority one; !hey
have to be achieved!
Priority three is recognized to other objectives having, generally, a complementary nature; it would be
liood to achieve them if possible!
The explicit objectives are generally mentioned in the official project documents like contracts.
However, not all the explicit objectives are published or explained to all the parties involved; some of
them may remain confidential, being internal objectives of one of the parties involved (I refer, for
instance, to the budget objectives of the investor and of the contractors); the Project Manager should
know each part of them but they are not supposed to be disclosed to the counterpart (s).
This is all very clear and very well-known. However, Project Managers are, sometimes, less aware of
the fact that there are also other types of objectives.
The most important are those which I call Implicit Objectives.
They are not explained, not written in documents but, nevertheless, they are there, hidden but real and
sometimes very important.
94
3. Implicit Objectives
Let's consider project planning: its elements are explicit objectives, constraints, activities, their
sequences and durations. When you summerize all the above, you will find a number of fixed points,
of obligatory passes which must be reached at definite points of time. These are additional objectives
which had not been e)C.plained or which had not been evident or known at the beginning.
As a matter of fact such objectives did implicitly exist as a necessary consequence of the declared
objectives, of internal and external constraints et cetera, as said above. Therefore I call them Implicit
Objectiyes.
They are as important as the explicit ones and it is extremely important to bring them to surface: all of
them.
If the analysis is not accurate enough, there is a high risk that the project schedule is jeopardized and
that the final objectives are not met. Therefore this difficult task should be pursued with all the forces,
especially during initial planning, taking advantage of the knowledge and experience of all key
positions of the project team. A couple of examples may better illustrate the above:
a) We may suppose that we have a project in a tropical area, subject to monsoons. The rainy seasons
included in the construction period have, therefore, to be considered as constraints to the project.
Considering the final objective (explicit) and the construction schedule, it may happen that all or
part of the underground work has absolutely to be completed before the beginning of a particular
rainy season. This would mean that the project has an implicit objective (which now has been
recognized): to complete such work before that season. Should this implicit objective not be
recognized in time, it could happen that the work is stopped by rain and, as a consequence, the
project is delayed and the final objectives missed.
b) Take the case of a project to be built in a country with "planned economy".
Among the project constraints there may be the obligation to buy the necessary structural steel in
the same country (import forbidden). Following the project schedule it might happen that, in order
to achieve the final objectives, the purchase order for the structural steel has to be placed before
the fmal date of a certain annual forecast. In such a way a project objective has been identified
which was not evident at the beginning and which must be absolutely achieved in order to avoid
jeopardizing the final objectives.
In case a part of this type of objectives remains hidden, it means they are not identified and
recognized, there is a high risk that project success is jeopardized. The task is not easy but it is
extremely important; it is closely connected with the initial project planning or rather, it is part of it.
There are no specifc rules about how to carry it out; certainly a wide experience and a very detailed
analysis are the best tools. Such an analysis should take into consideration all the constraints imposed
to the project by the contract, by the environment and by tJ.te laws plus those deriving from logistics,
finance and so on.
95
4. Instrumental Objectives
The complete identification of all the explicit and implicit objectives may be a sufficient basis and
may provide an adequate reference system for ensuring project success. However, sometimes, it might
be useful to establish additional objectives in order to maintain the interest and determination of the
members of the project team or for other reasons. Of course, the validity of such a policy is bound to
the condition that the impact on the project is only positive or, at least, with the positive aspects
largely prevailing on the negative.
Generally the main reason for such Instrumental Objectives is to stimulate people to keep pace with
the requirements of the schedule, especially during phases and periods when there may not be
sufficient tension because other objectives are still very far and not yet enough visible. As a matter of
fact, the stimulating effect of objectives is bound to their visibility and, also, to the level of
explanation.
Namely, if an objective has been explained by the top management of the company, the effect will be
much greater than an explanation of the Project Manager. Therefore the latter has to consider from
time to time to make careful use of such an opportunity.
5. Internal and External Objectives
External objectives are those which are relevant to the relationship with parties outside the company,
internal objectives are those related to company's specific interests and do not involve directly other
parties. If the company is a contractor, undertaking a project for a client, the concept is clear: External
Objectives which are connected with the client, with vendors, with subcontractors and w~th public
entities; Internal Objectives are all those only regarding the contractor himself, like profit, motivation
and development of its personnel, acquisition of know-how, optimum use of resources, improvement
of company's image.
A similar classification could be done when the company under consideration is an investor or a
public entity or a research institution or a trading company. The above opens a new topic: relationship
between project objectives and company objectives.
6. Project Objectives and Company's Objectives
A Project Manager, while taking care of and pursuing project objectives, has always to be aware of
and recognize company's objectives, provided that he has been properly informed by the company
management. In any case he has to be aware of the permanent or long range objectives which are
strictly connected to the company's policy and strategies.
96
The problem which often arises is the conflict between some project objectives and some company's
objectives. This is one of the fields where the function of the Project Manager is to make any effort in
order to find possibilities of balance and compromise; however, any decision should be left to the
Company Management which is the only one having the adequate horizon for finding the best balance
and is the only one having sufficient authority to impose the relevant decisions.
In the same perspective one should see the conflict among the objectives of different projects in a
multi-project environment. In such circumstances, the duty of each Project Manager is to cooperate
with other Project Managers and with other functions in finding possible compromises and evaluating
the relevant impacts on his project.
7. Objectives and Programmes
Programmes should be worked out, of course, taking into account and aiming at all the project
objectives, of any kind, nature and level of priority as discussed above. They should also take care of
the company's objectives in order to maximize the benefit for the company, far beyond the pure profit.
The programmes include time schedules as well as economical and financial budgets, they represent
the routes which are chosen and have to be followed in order to reach intermediate and final
destinations (the objectives). Development and use of instruments for keeping projects on their routes
is a task of "project control".
8. Conclusion
While a project progresses, validity of its objectives should be frequently checked and costs vs.
benefits periodically re-evaluated. Sometimes it may happen that a change in project conditions has
occurred which made some objectives very expensive and not convenient any more. In other cases,
achievement of some objectives may have led to conflicts with achievement of others and a choice
has to be made. It is very important to keep the above always in mind and always under control:
objectives need careful consideration but should not be like fetishes and should neither be pursued
blindly nor at any cost.
97
THE EVOLUTION OF MANAGEMENT TOOLS AND THE
EFFICIENCY OF PRODUCT DEVELOPMENT & ENGINEERING
THE GROWING OF THE 'MANAGEMENT TREE' PLANTED AND CULTURED BY
MANAGEMENT ASSOCIATIONS
Abstract
The introduction of Management Tools to increase the efficiency of product development is being
discussed. Initially the new tools seemed to be rather ineffective. The new tools were more acceptable
in manufacturing environments. By integrating a number of tools in larger Management Systems the
application to earlier phases of the Product Life Cycle became more feasible. In order to promote
specific tools, various international associations have been founded. Looking at its evolution one may
see that their interests are changing. As the life cycle of the association is followed from Conception
to the final Maintenance Phase, their focus of interest is going from the Realization Phase to the
Development Phases of the Product Lifecycle. If this observation is right, the author expects that
different associations will meet each other in the field of R, D&E. This aspect will have consequences
on their policy, including that of the International Project Management Association.
1. Introduction
Having the chance of sitting back a while contemplating the last thirty years of working in the
environment of Product Development and Engineering of a large multinational electrotechnical
company, I asked myself what "tools" to increase efficiency and what management concepts have had
influence on the product development processes in that period.
After the Second World War the European industry was recovering fast thanks to the application of
manufacturing and organizational concepts mainly developed in the United States. Since the
beginning of the fifties a steady flow of new ideas on various knowledge centres has been published
and proved in practice.
Comparing today's industry with the one of the fifties you fmd that a revolution took place. However,
by examining parts of particular industries you may wonder whether in that part any fundamental
change came at all
Organization and procedures in the development of already known commodities have not changed
much although the products themselves have been changing nearly continuously (Compare a radio
receiver of 1950 with one of 1990).
In the development of professional products that's the case to a lesser extent (Products for business
purpose). The way costs are calculated has not changed at all.
2. Some Efficiency Tools Developed and Tested
Making a list of "new efficiency tools" (-ideas, -concepts) and looking at the period they were
introduced, tested and either became normal practice or were superceded by something else, you see
that the early efficiency tools mostly were oriented to manufacturing- and process (see table 1 on the
last page). Dividing the product-life-cycle into phases, e.g. Concept-, Development-, Engineering- and
Manufacturingphase (resp. C, D, E, M, see table 1) leads to the conclusion that the early tools meant
for the improvement of product development- and engineering processes have mostly been applied in
the latter two phases. [Simplifying product realization here is divided into four phases from idea to
start of operation. The phases 'Design' and 'Manufacturing Preparation' are combined and called
'Engineering'. They contain among others the making of detail drawings of the product, manufacturing
tools and equipment and the preparation of production (procedures, layout, test- procedures,
instruction etc.)].
Only during the last decade new concepts have become more successful in the first phases. In the
fifties and sixties the improvement of research-, development- and engineering-processes (R, D&E-
processes) by simple rational straight forward efficiency-tools seemed to be difficult. For example,
network-planning and value-analysis introduced in the sixties were soon discarded by development
people. The former was applied mostly in the engineering and manufacturing of complex professional
products, the latter often (successfully) in the engineering phase of consumer products.
3. Probable Reasons for Rejection
For many of the approaches it is required that the product to be created should be known in detail.
That may be one of the reasons why network-planning soon was accepted by organizations engaged in
engineering and production of well known (complex) products e.g. ships, houses, dikes, bridges etc ..
For their production a cooperation of many specialists is necessary. A plan made by those specialists
often is of good quality and understandable because they have already a fairly detailed idea on the
100
result of the combined activities. Only small parts may be really new. It helped to reduce waiting-
times and project-duration often with high cost-reductions as a consequence.
Value-analysis (VA) is a method to determine the relationship between the functions required by the
user and the realisation-costs. However, to execute a VA one should know the real costs. The output
of a development project is often (and should be) a new product. In order to get data about the real
costs one should manufacture a number of them. But in that situation reasonable cost-reductions could
be achieved by applying already well-known cost reduction methods (leaving the product unchanged).
In companies like Philips Industries a good precalculation-system already existed. The system has
been managed by an organization with the task of improving overall efficiency. A long time before
the VA-approach has been published, this organization achieved about the same results with 'old
fashioned tools'. In organizations having produced well-known (cosumer-)products for a long time a
VA can be effective [Designing variants of the same kind of products or 'product-families' is nearly a
standard production process. In my opinion it is an activity belonging to the Engineering-phase].
However, this tool is rather useless in the Development- or even the Engineering-phase of complex
hightech professional products to be made in a small number.
4. 'Tools' for Quality Improvement
Also 'Quality conservation- and improvement-tools' have been introduced: At fIrst in the sixties to
mass production processes, mainly for reasons of cost reduction, later on to small series production.
Reduction of rejects and waste material are the motives for the introduction of quality-testing
equipment, quality-control and -management systems. They were mainly operations research
specialists and a few others who developed and promoted the (often statistical) methods and 'to<?ls'.
In the decade when products were still scarce there was no need for competition for customers. The
product-quality (defIned by R, D&E) was accepted as being as good as possible. In Project
Management this topic seemed to be even less important compared with the management of Time,
(Recource-) Organisation and Information, all of them having a strong influence on project-costs.
It is easy to answer the question who is responsible for project-quality but it is difficult to fInd a
straightforward answer on the question of responsibility of the quality of the (one) project goal, that is
the product to be developed. Is it the Project Manager or the (specialist) Management of the various
specifIc resources-requirements? [Concerning new products, R, D&E people (Development and
Engineering specialists) often tend to make the requirements on behalf of the potential customer.]
101
5. Risk Assessment and Contingency Planning
Risk is an interesting aspect in the flfSt phases of a project Nothing really new can be developed if
one is not incurring the risk of failure. Accepting the responsibility of risk and its consequences is still
more difficult
A project-manager has to provide for contingency-plans, a very creating activity of visualizing the
risks to be taken. On the other hand precalculated risks might give people an unjustified security. If a
computer has calculated that something is very unlikely to happen, you cannot blame the machine or
the program for the project becoming a disaster due to the unprobable event.
Even if many possible reasons for failure are foreseen and plans to deal with are made, many
unrecognized elements in the environment will have the habit of trying to anihilate your project
[Friends of INTERNET may name them 'acts of Djosh']. For example, you are in a foreign country to
present a speech on the occasion of the opening of a world-congress and on sunday moming 7.30h
that day at breakfast a little pebble in the sandwich destroyes your second left upper molar. And if you
still have 200 km to travel, you would be very lucky to have a friend in the neighbourhood helping
you out of this situation. It is my opinion that the flfSt and the best activity of a Project Manager's
contingency plan is "Making Friends". That may be the reason of the longevity of INTERNET.
6. The Development of Institutes, Societies and Associations
If applications of new knowledge or new applications of that knowledge are discovered by

respectively research or development the specialists working in the new specific field often fonn a
society. The goal of the organization is mainly exchanging knowledge and experiences and pJ;Omoting
the newly developed items. Also education and training are supported by the societies by means of
publications of handbooks, setting standards and defining the 'profession'.
The latter activity is related to certification in order to earn money by the newly achieved knowledge
and skills, that's the case especially in the USA [licencing people to apply certain efficiency tools may
sometimes increase resistance on improving it and extending the application].
Today there are many international organizations developing specific efficiency tools. To name a few:
Operations Research (OR), PrOject Management, Quality Engineering, Industrial Engineering, Value
Engineering and Cost Engineering [as far as I know there is no Risk Management Association (yet)].
102
7. The Evolution of the Societies
Societies or associations starting with a certain management tool are inclined to enlarge the fields of
application and to adopt related tools. Simply sticking to a restricted application of a specific tool
means losing a society's necessity as soon as the tool becomes 'normal practice'.
This almost happened in the sixties to the INTERNET Assocation formed around network-planning
techniques (decendant of OR). An association for network-planning only could not exist very long. It
was a good act of foresighting by the members of the INTERNET Board of the still young European
Assocation of Networkplanning, the dedicated promoters and supporters of the new tool, to change
the name in International Project Management Association. People of "the first hour" of INTERNET
expected that an association based only on networkplanning techniques could not live very long (and
many agreed of that).
Project Management is dealing with more than time- and cost-control alone. In the seventies the
Integrated Project Management Approach had been developed and slowly adopted in development
and engineering fields. It was the same with the societies for the promotion of Value Analysis. The
Society of American Value Engineers (SAVE) didn't grow for a long time. Although the name was
changed in Value Engineering in practice only Value Analysis of a very formal type was often
applied(the effect of licencing?). This can be said also for several European VA-Associations. Late in
the seventies the extension of the application and introduction of several creativity techniques was
started like Synectics, Morphological box, Function-Relation- Analysis-System, (FAST-
Diagramming), Graphe de Produit and DFA (Design For Assembly). Also Methodical Product
Development (MPD), a system developed at the Technical University of Twente in the Netherlands, is
based on many of the mentioned 'tools'.
Especially accepting membership of organizations instead of only licenced persons and a ch~ge in
the mean of Value, revived the interests in Europe, [in contrast to the American VA-Association the
members of the very large VA-Association in Japan are mainly companies].
Last years many national VA-societies discussed Value Management instead of Value Analysis or
Value Engineering.
They are now becoming less isolated due to international cooperation [in the framework of the
SPRINT program of the European Economic Committee the European VA-Association is now
cooperating to promote Value Management].
Also Quality based groups are integrating various techniques from (K&T)-Problem Analysis [K&T
means Keppner & Tregoe they developed and licenced certain problem solving methods in the USA].
via Statistical Process Analysis, Reliability Improvement and Quality Circles to Concern Wide
Quality Improvement (CWQI) and aim at Quality Management.
Activities to prevent product or project failure and tools to assess probabilities and effects of failures
have been developed already in the early sixties. Since the last five years the interest on the aspect
'Risk' is increasing. Especially during Project Startup this aspect is of primary importance. Risk
103
Management probably started with tools like Failure Mode and Effect Analysis (FMEA) developed
for space systems, satelites, mooncars etc. Via Risk Engineering it is now promoted under the name of
Risk Management (See INTERNET joumall990 Vol.8 Nr.l).
8. Societies Moving to the First Phase of the Product Life-Cycle
By extending Management's application to a certain aspect, the societies are moving, so to speak, via
Engineering and Development to the first Phase of the (new) Product Life Cycle. Consequently the
various associations will meet each other in the Development Phase. There are at least two reasons
that this can be expected.
A. They meet because the various project aspects to be managed are connected with the aspect
'cost'. For instance, the motive for increasing (product-)quality and -value, for reducing duration
of development projects and manufacturing processes is cost-reduction. In its turn the motive to
reduce costs are increasing profits. Value (V) of a product or project is derived from the relation
between the required function (Fr) of the object, the quality of the function (Qt) and the costs
(C) to realize and use the product by the formula V =Fr x Qf/C. Due to this formula the tools
promoted by Quality-, Value- and Project Management are related to each other via the aspect
'Cost'(of the Intemational Cost Engineering Committee?).
B. They meet, because decisions made during the development phase are having a strong influence
on quality, value, reliability etc. of the future product, the project's aim. For example, if you
divide the average product-costs of many industrial products into costs 'made' by a certain orga-
nizational function e.g. Manufacturing, Preparation of Manufacturing, Purchasing etc. you often
may find that only 10% of the productcosts are caused by Development (for consumer
massproducts even less). However, if you look at the organizational function making decisions
with product costs as a concequence, 'fixing' costs so to speak, you may fmd quite another
situation. But more important it is often very difficult to turn back those decisions in a later
project-phase. Figure 1 is showing that about 60% of the product-costs are of developmental
origin.
104
PRODUCT- COSTS 'MADE' ( ) AN) 'FIXED' ( U )
:O J
75
Per Organisational Function
60 ~
45 -l
30 -i
15 ~
I
PUfchaa
(Total product - costs are 100%)
Figure 1: Product-costs
So gradually many people, members of many Associations promoting 'different' Management

techniques are so to speak 'pointing their threatening fmgers out at people developing new or
improved things'.
By integrating various tools to specific 'Managements' they are trying to influence development-
processes. Experts are absolutely recommending to start applying the tools earlier in the product-
lifecycle for a long time.
9. Resistance towards Changing the 'Habits' of R, D&E
People of R, D&E should be taught and trained in the application of the various efficiency tools
belonging to many different 'Managements' to create new products having a high value no matter how
the product is called, a railway-bridge, a cathedral, one hundred-thousand Mercedes X-De LUX or a
virus resistant mouse.
However, many of the tools can only be used effectively if the new idea formed in the concept phase
by a person or a small group can be communicated (shown) in detail. Therefore decisions resulting in
'unavoidable' costs have already been made. Even more important is that people in development
accepted the costs as worthwhile even if the original idea that is necessary to start a project comes
from somebody else. Somebody who wants to develop a product needs and also wants to pay the costs
of creation and the developer has to add many own ideas to transform the original idea into a feasible
product.
It takes self-restraint letting experts take away your brainchild established in some time. Then they
show that cost reductions can be achieved by applying their specialist tools of networkplanning, risk-,
cost- and value engineering (it takes some time to put one's trust in the tools).
105
A product is a part of the creator. Trying to improve a product can be trying to improve people that do
not want to be manipulated or fear to lose their freedom (or face). So it is understandable that
resistances towards changes in existing creative development processes have to be overcome.
Nevertheless today's development managers introduced many of the new concepts and make proper
use of them.
10. The 'Tree of Development Managemenf and the Product Life-cycle
The conclusion that I have in the introduction of this article may be wrong after all. Looking from the
outside you see that product development has not changed much. Also said today is: "Project duration
still takes too much time, product costs are too high and the quality could be higher".
Processes of development changed internally, because many concepts in management derived from
various efficiency tools were incorporated in the way of thinking and working of people in
development creating highly valued products, often starting with 'impossible' ideas.
People working in the early phases of the product-lifecycle acquired knowledge about simple down to
earth efficiency tools applicable in later phases. This knowledge can be compared with the knowledge
of a nut about leafs, twigs, branches, the trunk and the roots to grow out of it. Also the relations and
functions of the parts are known (I am aware of the possibility that this comparison might lead to the
inference of the reader that a developer is a nut. However, translation problems can cause this
association).
New ideas have started to grow in the minds of single people. In the beginning they need a small
group of dedicated supporters, a fertile environment for 'growing' new products.
Those groups are too small to apply all the neccessary specialist management tools. But they (should)
know the involved basic concepts, the conditions to apply them and what resources are to be
requested for support.
In my opinion important basic concepts among others are:
A. Function (Only two words a noun and a verb).
B. Value (The ratio offunction to costs).
C. Mission-oriented System (The set of related elements with the purpose to transform
input into output).
D. Visualization of a System (The drawing of the functional elements and the mutual
relations of a system).
The latter is of importance for communicating ideas about a product, process or project plan in a
standardized simple and understandable way.
The benefits of the concepts however are depending on the most important presupposed concepts of
E. Multi Disciplinary Teamwork and
F. Creativity.
106
The tree of efficiency tools in figure I should be rooted on human aspects for instance: motivation,
vision and cooperation.
It may prosper if environmental conditions are favourable. In my opinion some important conditions
to be provided by the environment are acceptance, protection and stimulation of creativity. People
should get the freedom to explore new ideas and not be blamed for failures. One may learn something
from success but far more from failure.
But most important is the development of a worldwide NETWORK of friends. This is a challenging
but not unpleasant task for the various associations.
1
E
V OPERATION
ol PHASE
¥I MANUFACTURING
o ~
N PHASE
o
F
T
~
T
ENGINEERING
PHASE
o D
o ~ DEVElOPMENT
l E
S
b
1
PHASE
p
~ CONCEPT
N PHASE
T
Figure 1: Tree of "tools"
107
11. The Estimation of 'COST'- a Problem of the Future?
For many years it has been granted that everybody knows what is meant by 'costs'. It has been
calculated in the same way for more than a century.
In the Western world, particularly in the United States the primary goal of new technology, product
improvement, automation, massproduction and so on has been, the reduction of costs. Even Value
Analysis has been understood to be a strong tool to reduce costs of products. Probably because most
Western people are nowadays educated in expressing anything in money units. The activity to reduce
the amount of money units you have to pay and to increase the amount of what you get for your
efforts at the same time seems to be the most important thing in people's life.
In the sixties and seventies attempts to reduce costs of R,D&E- Processes became more successful by
introducing more integrated management systems. However, many Europian people in R,D&E were
not very enthousiastic about the cost reduction techniques. Maybe a wrong definition of Value is the
reason.
If we regard Value today it may have changed compared to twenty years ago. Mostly the value of
products still is established by taking in account only the costs the user has to spend. This is strange as
for instance the German Society for Value Analysis has already defined the concept of social value
(Value taking in account the costs other people have to pay who are not using the product). It is very
probable that the Value of many products we are so happy with diminuishes, if we also add the things
(translated in costs) our environment, flora and founa are paying for it
A new approach on cost-calculation is only possible, if the mentality of people will change. The habit
of calculating only the costs you have to pay yourself is rather selfish. It is important to recognize that
others and nature around us have to make sacrifices too, if you want to have and use all the things that
make your life agreeable today. Maybe some of the non-calculated costs are sacrifices that will
deprive future generations of a good life. This idea of a new revolution forced upon us by our own
lifestyle needs a change in mentality. It will take time but if that change will become mandatory
because of a deteriorating environment we'll have to develop many new products and above all the
application of efficiency tools will be necessary more than ever. So that there will be a great task for
cooperating Management Associations.
In the future the attention may be aimed to the concept-phase of Development, the trunk of the
'Management Tree' near the bottom and the fertile ground. It could be called just plain 'Management',
beginning with 'MAN having ideas, coming of 'AGE' (no teenager anymore, a little bit wiser). Many
of them are called 'MEN'. Adding the 'T from Teamwork you get 'MENT, people with creative
minds, the good spirit or 'MENTALITY' of friendship.
108
Table 1:
C
Efficiency "Tool" Abbr. Product! Intro. D Man. Root?
Process- period E Prep.
Oriented M Dev.
Time & Motion Analysis TMA Process 1948-'55 M Man. I Eng.

Assembly Layout AL Process 1950-'55 E Prep OR
Goods Flow Management GFM Process 1955-'65 M Man. MatM.
Statist.Process Analysis SPA Process 1955-'65 M Man. ORQL
Make or Buy MOB Product 1960-'65 E Prep CostE
Statist. Stock Control SSC Process 1960-'65 M Man. ORMM
Value Analysis VA Product 1962-'68 E Dev. VA
Brainstorming BRST Both 1962-'68 E Prep VA
Ergonomics ERG Process 1962-'70 E Prep Ind.E.
NelwQr!& Pllillnin~ NP Process 1963-'68 E Man ORPlan
Statist.Reliability Test SRT Product 1965-'70 M Prep ORQual
FAST Diagramming FAST Product 1966-'70 E Dev. VA
Creativity Techniques CT Both 1968-'70 C Creat VA Cr.
Problem Analysis PA Both 1968-'73 M Man. Ind.E.
fr.Qj~I Mllnll~m~nI PM Process 1969-'70 E Man. ORPlan
Potential Problem Analysis PPA Both 1969-'74 D Prep Ind.E.
Failure Mode & Effect Anal. FMEA Product 1970-'80 E Dev. VA
Systems Management SM Both 1972-'75 C TOTAL ORPlan
Synectics SYN Both 1975-'77 C Dev. VA Cr.
V lllil~ En!p'n~~rin~ VE Product 1975-'85 E Dev. VA
CQsI En!p'neerin~ CE Both 1975-'9? E TOTAL ORPlan
M~IhodiQlll D~:!i~n MD Product 1975-'9? C Dev. ORPlan
Morphological Box (Zwicky) MBOX Both 1980-'85 C Dev. VA Cr.
Quality Circles QC Both 1980-'85 E Man. ORQual
Design For Flexibility DFF Product 1983-'88 E Dev. Ind.E.
ConQ. Wid~ Qilal.ImurQvemenI CWQI Both 1984-'9? C TOTAL ORQual
Design For Assembly DFA Product 1985-'9? D Dev. VA
Just In Time JIT Process 1985-'9? M Man. ORMatM
vllhl~ Mlillll~m~m VM Product 1985-'9? C TOTAL VA
Risk Engineering RE Both 1985-'9? E Dev. Qual.
Risk Management RM Both 1987-'9? C TOTAL Qual.
Variety Reduction VR Product 1988-'9? D Dev. Ind.E.
Projectphase
C=Concept, D=Development
E=Engineering, M=Manufacturing
109
OPERATIONS RESEARCH AND PROJECT MANAGEMENT PAST,
PRESENT AND FUTURE
Heinz Schelle
Abstract
In project management the large number of publications about operation research topics contrast to
the small number of real applications. The author analyzes the reasons of the poor acceptance and the
implementation gap and makes some suggestions to bridge this gap. A closer cooperation between
software developers, operations research experts and users and new methodical approaches are
demanded.
1. Introduction: Operations Research and Project Management
Between the science of business adminstration and the field of operations research there are close
relations mainly based on the common idea of optimization which is pursued by both disciplines.
Many publications on the subject "Project Management" which is considered by the author to be a
subsection of the science of business administration were edited by operations research experts, in
particular in the first years after development of network analysis. In this connection the multitude of
contributions to the topics "optimum time compression in project scheduling", "stochastic network
analysis" and "optimum resource constrained scheduling" should be cited. Particularly with respect to
the last topic, a flead of studies and articles was published [1].
Further problems which could be solved by means of operations research techniques are exemplarily
mentioned in the following:
o Project selection
o Project risk analysis
o Project simulation
If not the actual problem areas but the various categories of methods are to be examined, the modern
decision theory, for example, in its different fonns is expected to render support in the selection,
planning and monitoring of projects [2]. Once, high hopes were also placed on the theory of fuzzy sets
[3].
2. Spread of Operations Research Methods in Project Management Practice
The large number of publications which, however, in most cases do not include case studies with
reports on practical experience present a startling contrast to the small number of real applications.
Comprehensive empirical studies on the utilization of operations research procedures are not
available. One exception is the study by Liberatore and Titus [4], performed in the USA and related to
the management of R&D projects. The authors come to the result that OR methods, such as stochastic
network analysis, are virtually not applied to practical problems. Due to a lack of comprehensive
studies, indications of their propagation have to be found. Valuable information could be gathered in
the proceedings of the INTERNET world congresses, which have been regularly published since the
1960s, and in extensive project management handbooks. In the proceedings in which hundreds of
articles mainly on practical topics are summarized some individual contributions which can be
assigned to the field of operations research can be found. Reports on successful practical applications,
however, hardly exist. A search for reports on such applications among the contributions to the annual
meetings of the Gesellschaft flir Projektmanagement (GPM) and the congresses of the Deutsche
Gesellschaft flir Operations Research is also in vain. Additionally, the latest project management
handbooks hardly include any information on the application of OR methods [5]. In practice, only the
deterministic methods of network analysis are employed, sometimes supplemented witb heuristic
procedures with respect to optimum resource constraint scheduling and, finally, parametric cost
estimate procedures mainly used in the aerospace industry.
The discovery that methods of operations research have only been playing a minor role in project
management up to now could even be substantiated by further indications. This finding presents a
harsh contrast to the statement of Wagner a renowned OR expert from the USA: "My central thesis is
that during the past 40 years operations research has gained significance by being an international
language of business strategy - or rather, an international language for business strategy" [6].
112
3. Reasons for the Small Number of OR-method Application to Project Management
3.1 Are OR Methods Suited Better for Bulk or Series Production than for Projects?
A first reason for the rare application of OR methods could be that projects are less suitable than bulk
or series production due to the individual project character. Indeed, this opinion can sometimes be
found in literature. For example Kilger [7] expresses the opinion that OR methods can only
conditionally be applied to job production i.e. in plants with project-type manufacture. A reason for
this thesis which is hardly understandable to the author, however, is not given.
3.2 Inadequate Models
A considerable more plausible reason for this thesis is represented by the fact that the discipline
operations research does not offer any problem-adequate methods. This will be clarified by the
following example: the heuristic procedures for optimum resource constraint scheduling mostly
consider only one possibility of reducing the peaks of demand: the delay of activities with a
predetermined, constant duration of the activities. All other possibilities employed in practice, i.e.
project restructuring, activity splitting or the shortening and extension of activities are often not taken
into consideration. Another critical item is that cost consequences of resource levelling measures do
not become apparent.
In the past 30 years, the theoretical research in this field has advanced [8] but positive effects on
capacity planning practice, a problem that will be emphasized here, can hardly be recognized. In the
author's opinion, the gap between theoretical research and practical application must man;ly be
attributed to the academic side. As the book of Weglarz and Slowinski shows exemplarily, the
universities neither thoroughly criticize the basic assumptions nor really discuss the project planning
demands. From a slightly cynical point of view we could say: operations research experts are working
on a solution of problems which hardly ever exist in practice. A very similar judgement on the subject
"project selection" is pronounced by Souder [9], stating: "Other models (for project selection; author's
remark) are so simplistic, that their potential contributions are difficult to perceive." The lack of
problem-adequacy in many approaches of operations research could be further substantiated on a
basis of many more examples.
3.3 Little Acquaintance of the Developers with the Real Problem [10]
This reason is often not independent of the above-mentioned ones. According to the textbooks the
methods of operations research base on a real problem. Our science, however, does not guarantee that
113
this prerequisite is always fulfilled. Many authors do no longer make themselves familiar with the real
problem by direct confrontation. Since systematic user research has not yet been performed in the
discipline of project management, the user requirements in some cases are only unsatisfactorily
known. In many cases, a mathematical model established in a previous work is adopted and modified.
Often, variations are only performed, if this is relatively easy by means of the available instruments.
Permanent criticism of the assumptions in confrontation with reality is omitted. On the basis of many
examples it can be proved that the development of new models is rather method-oriented than
problem-oriented. In the beginning of the 1960s, for example, enumerative models of project-related
cost planning and control supported by network analysis were developed only because the instruments
required were already available. Other examples of fruitless, method-oriented further developments
are represented by the various approaches already mentioned concerning the determination of
optimum time compression in projects.
3.4 Necessary Data are not Available
The above example with respect to the determination of optimum time compression in projects is also
the proof of the cited lack of acceptance. Here, the models require the input of the costs caused by the
shortening of the activity durations. Conventional accounting, however, is still not capable of
supplying the required data.
This acceptance-related obstacle "data availability" can also be proved on the basis of another
example: some time ago the author, together with two colleagues, was requested to verify whether the
application of a "rapid prototype" contributes to the achievement of project targets within software
projects, compared to a procedure according to a phase model without any prototypes. Th~ question
was to be answered by means of a simulation model: upon thorough analysis of the problem, it
became clear that empirical data were almost not available so that the simulation model developed
could not be validated. The statement formulated by Souder et alii [11] with respect to the study on
the acceptance of OR models is still applicable: "But models that require generally unavailable data
would normally have low potentials".
3.5 Institutional Conditions are not Taken into Consideration
This category of reasons, among others, includes the high expenditure necessary for the application of
different OR approaches. For example, this holds true for stochastic network analysis. In this regard,
Muller [12] writes: upon preparation of process structures which imply uncertainties, the uncertain
stages of the process have to be clearly recognized and possible alternatives have to be exactly
elaborated and quantified by the indication of probabilities. This possibly leads to a considerably
114
higher expenditure for the acquisition of planning data and, above all, for their processing within the
scope of computations (also in case of EDP application), depending on the number of uncertain stages
and possible alternatives. As only very limited resources are made available for project planning and
control, this approach is normally not pursued. Another obstacle for the application of stochastic
networks is the low degree of result reliability when confronted with slightly modified probability
data.
Another example of the neglect of institutional facts is the failed attempt to introduce PERT/COST
and variants in the US American defense industry. Upon development and introduction of this
method, the fact was ignored that all companies concerned already operated a PERT/COST system
which was not compatible with the new method. As a consequence, the companies would have been
obliged to additionally apply the system imposed by the military customer.
3.6 The Models and Procedures Offered are too Complicated
A developer of OR models once expressed the following sentence: "A manager rather accepts
unsolved problems than models he does not understand." In the marketing field, adequate conclusions
have long been drawn from this finding, and models with a lower degree of complexity were
developed [13]. Despite the negative experience gained by applying stochastic network analysis in the
past years, operations research permanently develops new approaches [14] which, in all probability,
will be applied as rarely as the old models. The wide spread the methods of deterministic network
analysis experienced in practice can probably be attributed to the fact that these methods are easily
understandable and can be acquired by employing comparatively low effort.
4. Possibilities of a More Intensive Application of Operations Research Methods to Project

Management
Not all the problems with respect to project selection, planning and control can be solved by means of
operations research methods, as is the wishful thinking of some OR experts. The increasing number of
publications dealing with questions of project management from the view of organization psychology
and sociology [15] shows that the strongly technocracy-oriented idea of project management which
was valid between 1957 and the end of the 1980s is no longer dominant. However, that does not mean
that the field of operations research does no longer have the right to exist within the scope of the
discipline 'project management'.
Without any doubt, an important prerequisite for a more fruitful application of quantitative methods is
an intensive user research.
115
4.1 The Necessity of More Intensive User Research
As already stated above, systematic user research in project management up to now has been
neglected to a large extent, contrary to the field of office communications, for example.
With respect to the field of resource planning which will be considered exemplarily here, the author
dares to state that the user demand is hardly known, in spite of a series of publications on the practical
application of software packages for this purpose. The low degree of utilization of program
components for project resource planning, mentioned, among others, by Millier-Ettrich [16) and the
results of user interviews [17) are a proof of the existence of a considerable backlog demand. For
example, it is obvious that the possibilities of graphical output offered by modem computers are only
unsatisfactorily turned to account. Methods of successful practicians in resource planning have to be
thoroughly observed and described [18).
The characteristics of user-friendly software packages for project management must be identified
[19].
4.2 Cooperation between Software Developers, OR Experts and Users
In the author's opinion, as already emphasized, the little degree of OR-method application can be,
among other things, attributed to the OR-experts' lack of familiarity with the real problem. This
partially applies also to software developers - however, to a smaller extent. This can also be proved by
the often harsh user criticism. Communication between users and developers in recent years has
def'mitely been improved, mainly within the scope of user groups. But many OR experts are still
sitting in their ivory towers and only dare some rare excursions into the rough reality. A g~ proof of
this thesis is the book of Slowinski and Weglarz already cited. If someone is now still not convinced
of this example, he should only go through the last twenty annual sets of periodicals, such as
Operations Research Quarterly and Management Science.
4.3 New Methodical Approaches are Required
Improved communications alone can definitely not be sufficient when a certain progress in applying
quantitative methods to project management is to be achieved. New methodical approaches are
required. In recent time, this requirement mainly includes the systematic application of personal
knowledge and experience of managers. A pleading for the more intensive utilization of practical
experience is submitted, e.g. by H.L. and S.E. Dreyfus [20) who are dealing very critical with
approaches in the field of artificial intelligence: "A manager expert who is deeply involved in his
work and most closely familiar with his company recognizes and decides intuitively on a basis of
116
previous experience with successful and less successful measures. He does no longer take his
decisions by applying formulars to facts as he did as a newcomer or competent manager, and as is
offered by mathematic models." However, both authors do not at all reject the application of
quantitative methods, but they demand the integration of "scientific methods and computer tools in
our rather traditional and intuitive proceeding". In this regard, several approches have been existing
for a rather long time although it has already to be said here that personal knowledge, without any
doubt playing a leading role in project management, is very difficult to be formally represented in
expert systems.
A first possibility is offered by so-called decision support systems. The basic idea which is always
modified by supporters of this approach is not new. The computer will not take over the decisions-
making process from the manager but only support him in this process. As a very illustrative example
the game of chess is often mentioned. Here, the computer does not decide on the respective move but
supports the player in the opening phase by means of a data base which contains many opening moves
with respective comments [21]. If, for example, this conception was to be transferred to the problem
of resource planning, programs would have to be developed, which do not only offer planning
algorithms to the user and the possibility of their adaptation to particular situations, but also facilitate
"intelligent testing", and immediately display the consequences of the user's decisions. It has surely
not to be proved in detail that these requirements can not be fulfilled by existing programs, and that
the possibilities of graphic user interfaces today have only been exploited to a very small extent with
respect to such tasks.
In another approach - Decision Calculus developed by Little - the author tries to combine personal
knowledge of the planner with analytic proceeding. This is to be performed within a permanent
dialogue with the computer. Little himself has already applied his idea to a series of problems, such as
the task of determining the optimum marketing budget. For tasks in the field of project management,
however, such attempt, as far as the author knows, have not been made up to now. However, several
years ago, the author together with a colleague made the proposal to apply the 'Decision Calculus'-
concept to make a life-cycle cost prognosis within the scope of an expert system [22].
In the author's opinion, however, a rather great risk occurs with respect to expert systems: solution
approaches of operations research which already proved to be a practical failure could attain
unmerited honors - coming in again by the "back door" of expert systems [23]. That would be a great
pity, since no conclusions would habe been drawn from decades of setbacks and disappointments.
117
References
[1] A comprehensive bibliography can be found, e.g. in the following work: Slowinski, R.;
Weglarz, R. (Eds.): Advances in Project Scheduling. Studies in Production and Engn.eering
Economics 9, Amsterdam 1989.
[2] Particularly refer to Booker, J.M.; Bryson, M.C.: Decision Analysis in Project Management:
An Overview, IEEE Transactions on Engineering Management, Vol. EM-32, No.1, February
1985, pp. 3-9.
[3] Refer to Kaufmann, A.: Reseaux et Systemes dans L'Incertain Structure. Utilisation pratique et
efficace des concepts fIous, in: Gutsch, R.; Reschke, H.; Schelle, H. (Eels.): Proceedings of the
6th Internet Congress 1979, Vol. 5, Dusseldorf 1980, S. 59-101.
[4] Liberatore, M.J.; Titus, GJ.: The Practice of Management Science in R&D Project
Management. Management Science, Vol. 29, No.8, August 1983, p. 962-974.
[5] Refer to Cleland, D.I.; King, W.R. (Eds.): Project Management Handbook, sec. ed. New York
1988; Reschke, H.; Schelle, H.; Schnopp, R. (Eds.): Handbuch Projektmanagement, Vol. I
and n, Dusseldorf 1989 An exception is represented by the article of Souder in the manual of
Cleland and King: Souder, W.: Selection Projects that Maximize Profits, pp. 140-164. The
author, however, expresses a rather critical opinion about many models applicable to project
selection.
[6] Wagner, H.M.: Operations Research: A Global Language for Business Strategy, in: Operations
Research, Vol. 36, No.5, September-October 1988, pp. 797-803, p. 798. Contrary to the title of
the article, the essentially operational problems. After analysing Wagners examples, however,
the cited applications have to be assigned to bulk and series production.
[7] Kilger, W.: Optimale Produktions- und Absatzplanung (Optimal Production- and Marketing
Planning), Opladen 1973, p. 11
[8] Refer, e.g., to the following work, containing a lot of bibliographical references: Slowinski, R.;
Weglarz, J. (Eds.): Advances in Project Scheduling. Amsterdam 1989. A very astonishing fact
is that none of the authors seriously discusses questions of computer-assisted capacity planning
or problems of user surface design.
[9] Souder, W.E.; Maher, P.M.; Baker, N.R.; Shumway, C.R. and Rubenstein, A.H.: An
Organizational Intervention Approach to the Design and Implementation of R&D Project
Selection Models, in: Schultz, R.O.; Slevin, D.P. (Eds.): Implementing Operations
Research/Management Science. New York 1975, pp. 133-152, p. 133.
[10] Refer to Schelle, H.: Untemehmensleitung und Management-Informations-Systeme [Company
Management and Management Informations System], in Schelle, H.; Molzberger, P. (Eds.):
Psychologische Aspekte der Software-Entwicklung [Psychological aspects of software
development], Munich 1983, pp. 237-271, here p. 258.
[11] Souder et alii, I.c., p. 138.
118
[12] Muller, D.: Methoden der Ablauf- und Terminplanung von Projekten [Methods of Project
Process Planning and Scheduling] in: Reschke, H.; Schelle, H.; Schnopp, R. (Eds.):
Handbuch Projektroanagement [Project Management Manual], Vol. 1, Cologne 1990, pp. 263-
311, herep. 283.
[13] Refer to BOcker, etc., etc.
[14] Refer to the synoptic article by Whatley, N.M.: Cost/Schedule/ Technical Performance Risk
Analysis, in: Stewart, R.D.; Wyskida, R.M. (Eds.): Cost Estimators Reference Manual. New
York 1986, pp. 259-310.
[15] A typical example is represented by the book of Heintel, P.; Krainz, E.E.:
Projektmanagement. Eine Antwort auf die Hierarchiekrise? [Project Management. A reply to
the hierarchical crisis?]; Wiesbaden 1988. This book published by two psychologists contains
hardly any references to quantitative methods but only deals with organization-psychological
questions.
[16] Muller-Ettrich, R.: Einsatzmittelplanung. Stand und Probleme der projektbezogenen
Einsatzmittelplanung [Resource planning. Status and problems of project-related resource
planning] in: Reschke, H.; Schelle, H.; Schnopp, R. (Eds.): Handbuch Projektmanagement
[Project Management Manual], Vol. I, pp. 313-329, here p. 314.
[17] Dworatschek, S., Gutsch, R.: The Future of Project Management. Results of Theses Markets,
GPM Nachrichten Nr. 12, 1987, p.
[18] Concerning the neglect of description by business administration in general, referto Schelle, H.:
Unternehmensleitung und Management-Infonnations-System [Company Management and
Management Infonnation System], in: Schelle, H.; Molzberger, P. (Eds.)
[19] With respect to methodology refer to Schelle, H.; Schnopp, R.; Schwald, A.: Measurement of
the User Friendliness of Project Management Software: A New Approach, in: From Conception
to Completion, Proceedings of the 9th World Congress on Project Management, September 4th-
9th 1988, Glasgow, pp. 1021-1029.
[20] Dreyfus, H.L.; Dreyfus, S.E.: Ktinstliche Intelligenz. Von den Grenzen der Denkmaschine und
dem Wert der Intuition [Artificial Intelligence. Of the limits of the thinking machine and the
value of intuition]. Hamburg 1987, p. 217
[21] Morton, M.S.; Huff, S.: The Impact of Computers on Planning and Decision Making, in:
Smith, H.T.; Grenn, T.R.G. (Eds.): Human Interaction with Computers. London 1980, pp.
177-201.
[22] Schelle, H.; Voglmaier, E.: LCC-Modelle und Expertensysteme [LCC models and expert
systems] in: Schelle, H.; Voglmaier, E.; Madauss, B.: Symposium Life Cycle Cost, GPM-
Arbeitstexte zum Projektmanagement [GPM working texts on project management], Munich
1986, pp. 209-225.
119
[23] Refer to Schelle, H.; Seiler, R.: Expertensysteme im Projektmanagement. Versuch einer
Bestandsaufnahme, [Expert systems in project management. The attempt to make an inventory]
in Reschke, H.; Schelle, H. (Eds.): Projektroanagement. Beitriige zur GPM-Jahrestagung 1987
[Project management. Contributions to the GPM annual meeting 1987], pp. 331-340.
120
DEVELOPMENT OF METHODS IN PROJECT MANAGEMENT
A SUBJECf FOR TIIEORISTS ONLY?
Dietrich Miiller
Abstract
When the new management concept for "Project Management" (PM) was introduced at the beginning
of the sixties, reflections were focussed on methodology. For a time, network technique was
synonymous with PM. In the meantime, however, the situation has changed completely: PM
discussions now concentrate on EDP tools (which continue to focus heavily on network technique)
and on the job-related exchange of experience and know-how concerning positive results and
problems of PM. Yet, it is often ignored that there are still open questions concerning PM methods
which arise from concrete problems encountered in practice. These problems which have been
awaiting a solution for approximately twenty years stand a far better chance of solution today due to
substantially improved EDP capabilities. For this reason, this paper takes up some of these issues to
restart the search for possible solutions. One of these well-known problems is the evaluation of
uncertainties in project process and schedule. This paper, however, will be dedicated to the important
project parameters "cost and resources" which have been dreadfully neglected lately and require a lot
of practice-oriented and methodically substantiated help. At the end, numerous other important and
complex PM problems will be indicated.
1. Introduction
The focus of project management development has shifted from the development of methods to
questions of application. Observing the project management "scenario" in recent times, the impression
is gained that the problems encountered in practice can only be solved with effective, and primarily of
course EDP tools and appropriate measures above all in the personnel and organizational sector.
Have all the stops in project management methods really been pulled? Is it really pointless to look for
new methods which would help to reduce the amount of everyday problems encountered in practice?
Do these problems basically defy any methodical treatment? Or do the great difficulties encountered
in practice in solving everyday problems impede the clarification of issues, which are first of all
theoretical but not insignificant for practice, and also the further development of methodological
instruments which is desirable at least in some areas?
Empirical experience is still much too popular while systematic methods are currently not much in
demand. What is the reason? One reason definitely is that, especially for practitioners, no satisfactory
solutions were found to various issues addressed in the past. Have the solutions to these problems
become unnecessary and unimportant to both theorists and practitioners? I can hardly believe this!
Methodology is not the exclusive domain of theorists! It is true that it is a theorist's job to develop
approaches to solutions and methods, but the motive must come from practice. Only such methods are
of interest which - with the help of practitioners - can be translated into procedures (if possible EDP-
supported) in such a way that the latter is able to use such procedures in a concrete case of application
(project). This means that they must be simple and affordable, reduce his workload and provide
information of a quality superior to his intuitive "practical experience" and "rule-of-thumb" approach.
Following, a few issues will be addressed which are not new but, from the viewpoint of practice, still
remain unsolved. They will be approached against the background of factual and realistic problems so
that theorists are encouraged to tackle these "old" issues again to offer the support needed in project
practice. The chances for advancement in this field have definitely improved since EDP capabilities,
which are required to translate methods into procedures of practical use, have been increased by
several orders of magnitude in the last 15 years.
The term "methods" in project management generally denominates algorithms for the shaping and
study of project process models and the quantitative determination of schedules, resources and costs.
Even though unsolved theoretical and practical problems are still found in the field of process and
schedule planning, emphasis must be placed on the problems encountered in the important project
parameters "resources and costs". They urgently call for solution as they are closely correlated with
the organization and economic efficiency of a project
2. How Exactly is Project Process Known in Advance?
Project process planning means: Identification and presentation (graphics and tables) of all the
measures required to reach the project goal; sequence of all activities, their correlation; which activity
comes first - which is the last?
Irrespective of its form this plan naturally is the decisive basis for all further planning activities (and
all resulting information) and, last but not least, for the actual project realization. Any responsible and
systematically working project manager is therefore interested in obtaining this plan as early and
accurately as possible. However, there is also a broad spectrum of projects where this plan does not
122
and cannot provide the requested clarity. Two reasons for this:
* There are degrees of freedom determined by technology. The disadvantage of unclear project
process is offset at least in part by the flexibility in project realization.
* The situation differs with projects in which the content and scope of activities is dependent
upon interim project results which have been achieved. In some cases, individual activities may
be dropped or external decisions are required as a result of the interim results. Here, the
disadvantage of a high level of uncertainty is not offset by any benefit. This situation is typical
of many R&D projects, e.g. all types of tests.
Are these problems of major importance for project realization? What is the normal procedure today?
During project planning, the decisions at "uncertain" crossroads are taken in favor of the alternative
with the highest subjective probability and the further process plan is considered as a deterministic
project model. The result: Numerous and apparently unforeseeable, i.e. unplanned changes to the
process during project realization with an often considerable impact on the results, costs and date of
completion. The frequency of such ad hoc process changes in practice indicates a latent (or only
potential?) problem.
The problem has been known for a long time! At the end of the sixties until the mid-seventies,
H. Elsner ("Decision Box Method") [1], S.E. Elmaghraby ("Generalized Activity - Network
Methods") [2] and A.A.B Pritsker ("Gmphical Evaluation and Review Technique - GERT") [3],
amongst others, tried to introduce methods of stochastic process planning on the basis of activity-on-
arrow-networks. These methods which were also translated into EDP-procedures did not find
acceptance in practice. The reasons can only be pondered upon [4]. The argument of high efforts is
incorrect inasmuch as each planner is naturally tasked to identify "uncertainties" in a project, at an
early point in time and to indicate alternatives. All further steps would then be assigned to
methodology and procedures.
Is progress in this field conceivable by means of simple. affordable simulation techniques? Or will the
empirical databases and in this context, expert systems, offer approaches to future solutions? The
generally known and recurring problem of process changes is strong evidence that it is reasonable to
search again and further for solutions.
3. Which Planned Schedule is Reliable?
As repeatedly mentioned in this paper, planning uncertainties are once again the central topic: This
time it is not project process but the schedule for a determined process (which in many cases does not
correspond to project reality, see above!). A brief description of the problem: Project scheduling and,
thus, all project plannings are based on process planning and above all on time estimates, especially
123
for the duration of activities. The uncertainty of these estimates immediately gives rise to many
questions, such as:
* How high is the probability that the project will really run over the estimated time? What is the
most probable duration?
* How high is the probability that a specified or calculated (e.g. completion) date is not overrun?
* Which date for a defined event (project completion is usually of particular interest) will not be
overrun with a defined probability (e.g. 95 or 99 %)?
Almost all persons taking responsibility in a project require almost daily reliable answers to such or
similar questions. Nearly all projects are highly dependent upon these values! For the time being,
however, the impression is gained that these questions will remain unanswered. Two approaches to
solution which were discussed relatively often then and subjected to tests (first half of the sixties) will
be presented in the following. The corresponding algorithms were even translated into EDP programs
in spite of the heavily limited EDP capabilities at that time! The two basically different procedures
were:
1. Application of so-called approximation methods, e.g.: the Monte-Carlo-simulation. In the

computer era this is a relatively common procedure for treating stochastic problems. As the
number of random variables (in this case activity duration) is relatively high in projects of
practical relevance, the effort does not justify the attainable benefit. The values obtained with the
deterministic project calculation which are typically found in practice were not distinctly
improved or substantiated with a reasonable simulation effort.
2. Application of exact methods: The most widely known procedure is PERT. The method
developed for PERT is based on the idea that all intervals between the events in an event-on-node-
network (similar considerations are possible for activity-oriented network methods) are random
variables and, as a result, all derived parameters (event dates, project duration, total floats, etc.)
are statistically distributed. Applying the theorems of probability theory and statistics, efforts can
be made to answer the questions above.
The PERT method in particular has become widely known due to the 3-time estimate which is still in
use today. The probability portion of this method which is especially interesting here, however, was
discarded soon after its development,- maybe a little too early? - on mathematical WUnds (see [4]
and [5] and further literature references). According to the author's (mathematician!) opinion,
however, the applicability of this method to practice was studied only inadequately. Since minor
mathematical inaccuracies might be acceptable as practitioners tend to ignore them.
124
As the problem of schedule uncertainties is definitely relevant for many projects it is recommendable
to take up this subject again and treat it from the present-day point of view and with the EDP-tools
that are available today. A fundamentally new methodological approach is not expected; the empirical
databases indicated above "only" provide better statistical material. However, high-perfonnance
algorithms and EDP programs as well as a reasonable interpretation of results may be helpful to
practitioners who might not place such emphasis on exact mathematics and theory.
4. Resources - Always Scarce in Projects?
4.1 Introduction: The (Dis)interest in Resource Analysis. an Attempt to Find Out the Reasons
Studying the parameter "resources" which is of great importance for project realization, a peculiar
phenomenon becomes evident.
On the one hand: By the mid-seventies the latest (network technique at that time had rapidly lost
ground) planning experts became aware of the fact that project date scheduling without safeguarding
the plans with respect to the resources is futile, since "project realization" ftrst and foremost means
"utilization of resources". A project can only be carried out reasonably on the basis of a date schedule
which has resulted from resource analysis.
On the other hand: Practice shows little interest in resource analysis. At expert conferences, in
professional journals, textbooks, training courses and in the development of PM software, this subject
has occupied comparatively little space for many years.
Nevertheless: In the event of a project failure or problems encountered in executing a project, the
inadequate availability of appropriate resources (in most cases personnel) is often cited as a reason. A
decisive point of discussion in conjunction with project organization, especially when the 'proper
functioning of a matrix is at stake, refers to the access to personnel (who also are considered
resources).
Are resources an important subject? For theorists, for practitioners? For both or none of them? These
questions will not be answered for the present time. Instead a further question will be asked: Why is it
there lWparently so little interest?
This question, too, can only be pondered upon:
Maybe in the past, theorists did not consider this subject from the practitioners' point of view.
Theorists are advised to concentrate on issues of importance to practice!
A few key words in this context: Universality is not required. Restriction to a few but important
resources is sufftcient - fIrst and foremost: personnel. Optimizations are deftnitely interesting for a
theorist but the costlbeneftt ratio is unacceptable for a practitioner. What degree of precision is
reasonable and necessary in resource analysis and should, therefore, be aimed at? A high degree of
smoothing corresponds to practical reality. With resource analysis, a high level of EDP automation
125
requires a massive input effort and, often yields only few results of practical use.
Maybe the subject "resource analysis" is outdated because practice has been supported only
inadequately with procedures and tools, in other words: the developers of methods and procedures
have "offered" too little'?
4.2 Problems Encountered in Developing Methods for Resource Analysis
One reason for the inadequate support of practice by theory are the generally acknowledged major
problems involved in resource analysis. But which are the concrete problems that aggravate the
development of feasible procedures'? A few suggestions in this context:
Not only the number of required or available resources of a specific resource type (e.g. personnel)
is important for a practitioner but also the question: How has a specific resource webeen
defmed'? This addresses the problem of which resources are considered replaceable in the analysis
process, i.e. which have an approximately equivalent resource unit capacity'?
It has been known for a long time that various strate~es can be pursued in resource analysis:
Principal key words are: "resource levelling" and "resource smoothing". Restrictions to schedule
or resources or a combination of both have to be observed in this conjunction. Various
mathematical methods [6] are available to treat resource problems according to such strategies.
But not all strategies with all potential restrictions are equally important in practice. Mathematical
methods are primarily needed for the most important case: Adjusting resource aggregation to
resources of limited availability in consideration of project and activity priorities. For cases of a
practically relevant dimension, these methods have to lead to a uniform planning, of each
individual resource with an affordable effort in data provision and calculation. The analysis
process has to adhere to simple target functions (as a rule: cost valuation), but, for reasons of
effort, must not look for the optimum. Continuity in the handling of activities and the utilization of
resources is more important than a mathematical optimum and digits after the decimal point! The
algorithms for resource-limited schedulin~ which have been in use for some time, principally go
into the right direction.
A major problem in developing resource analysis methods is the computing effort for algorithms
in real life projects: Many activities, relationships and considered resource types (is this always
necessary'? - see above) stress even today's powerful computers beyond their limits. This problem
results from the fact that areasonable resource analysis is possible only within the frame of.amlli:.
project-plannin~.
126
4.3 Resource Analysis as a Subaspect of Production Planning and Project Planning'
a Comparison
Potential reasons for the apparently little interest in resource analysis have been indicated above.
However, quite a contrary consideration of the resource analysis problem is referred to here which
actually should in~se the interest in resource analysis:
Basically, multi-project-planning faces the same problem as order scheduling as part of production
p1annin~: Each order (activity) has to be assigned to an individual machining station (resource) in the
correct rhythm (process and date scheduling), and the throughput (resource unit capacity) of the
individual station including "unproductive" periods of conversion, service, etc. has to be taken into
account.
A comparable procedure for project management is not possible without more ado as two further
significant problems are frequently found in practice:
* Projects competing for the same recources are often based on different planning fundamentals
for their resource analysis: Bar charts or the like, networks or the like, or, in some cases, no
useful basis at all. Combining different types of planning documents under the terms of multi-
project-planning into a joint resource analysis apparently is quite difficult This condition is
even aggravated when there is a mixture between the realization of projects on the one hand and
business without project characteristics on the other.
* As opposed to production, changes during project realization often occur to activities which are
planned or already "in production" (e.g. higher effort due to technical problems). This results in
planning changes and calls the original resource analysis into question. Often adjustments are
necessary at short notice, which, however, for reasons of continuity must not involve, major
changes.
4.4 EDP Support for Resource Analysis: The Way to Good Software
Anyone who has attempted to develop a resource analysis for a conrete case of application knows that
this is practically unfeasible without EDP use. Therefore, network analysis and other project manage-
ment support software have been offering services for resource analysis for a long time and to an
increasing extent [7]. Even though the developers are usually very proud of their programs, the
software often leaves much to be desired in terms of handling (e.g. input) and performance (e.g.
flexibility and results) and its low degree of acceptance in practice evidences this statement. The
situation thus contrasts with the programs generating network graphics. Their advent and capabilities
substantially centributed to the renaissance of critical path planning. It is to be hoped that the develop-
ment will be similar for resource analysis.
127
As indicated above, an important ingredient to a good resource analysis software is still missing, viz:
the precise definition of requirements. This situation, too, was different in graphics software - maybe
that is the reason why it has advanced so well! It is definitely reasonable to start the requirements
analysis for resource analysis software with well prepared, dedicated inquiries of numerous project
planners.
Conceptional approaches to a solution are available by now. However, upon development start it must
be clear that the software to be generated has to be embedded in a self-contained semi-automatic
resource analysis process since full automation most probably will not provide satisfactory results.
Semi-automation involves man-machine-dialogue:
* The planner proposes commitments to be computed.
* The computer computes and provides information, upon request, in detailed form on resource
aggregation, availability and load, possibly with reference to individual activities, periods and
resources.
Present-day EDP potential (storage capacity, speed, graphics, operating systems and database
software) makes it possible to offer much more effective tools for the resource analysis of muIti-
project-planning of an order, which is much in practice, than former optimization or simple resource
requirements analysis programs. Appropriate resource analysis software, however, has to be strictly
designed to the new EDP possibilities and to user requirements.
In conclusion it can be stated that the relatively little interest in resource analysis is definitely not due
to the fact that this project management subject is theoretically and practically exhausted. Resource
analysis is still a problem both of theory and practice!
5. Costs and Finances - of Importance or not?
5.1 Introduction
Unlike the subject resource analysis, the project parameter "costs" continues to be a highly interesting
subject. The reason: The originally "published" project costs are often considerably overrun. The
spectrum of negative consequences is broad and well-known: Irritations/arguments ("what is the
reason for these overruns?"; "who is responsible?"; "who will pay the overruns and how?", etc.),
financing problems, project changes or even stop, personnel consequences, frustration of the project
team,.... Reasons abound to start with systematic research in the causes in order to identify problems
and search for possible solutions. Only minor contributions to solving these problems are expected
from the methodological field.
Which are the relevant subjects with respect to the project parameter "costs"? Which thereof merit
further and more detailed study in order to find procedures which may be ~enerally introduced into
128
practice to help ease "everyday problems" related to project costs?
5.2 Cost Forecasts
Problems as a rule start with the difficulty in providing without excessive effon, a relatively reliable
and acceptable cost forecast in a very early phase of the projecL The cost forecast issue is of particular
importance in development projects above all since the hardware and software effort involved is
difficult to assess. The rule-of-thumb method is usually applied to such forecasts. If they are felt to be
too high they are ignored. If the forecasts are intuitively correct, they might be too low and give rise to
wrong ideas which are hard to dismiss. Instead of this rule-of-thumb method a systematic and
substantiated procedure is recommendable. Numerous approaches are available, some matured to
operational computerized tools which help prepare useful cost forecasts early in the project
Practitioners, however, rarely discuss cost forecast models, for instance, by employing cost
assessment equations. Many detailed studies on this subject (see [8] and here numerous other papers)
are available but have hardly been translated into practical use. Two well-known exceptions are the
PRICE model (see [9]) designed, software-developed, and commercialized by RCA. This model is
primarily used for electronics system projects. The other is the COCOMO method from TRW (see
[10]) which is well-known in software engineering circles. A further investigation into the cost
forecast subject which would defmitely be interesting for practice, would have to start with analyzing
its little relevance for practice until now. Maybe the necessary mathematical apparatus is the reason.
Most probably, however, the considerable lack of statistical material plays a role.
5.3 Cost Planning
Cost forecasts primarily serve the purpose of a rather "global" check of the fmancial feasibility of a
project It supports the decision-making process on the feasibility of a project, at least as far as the
execution of extensive and detailed preliminary work is concerned. It is needed to clarify financing
issues and advise on the earmarking and appropriation of funds. It is thus the starting point for
defming an overall budget.
A cost forecast, however, does not replace detailed cost planning which is based on the individual
project activities to be perfonned. Quite the reverse: The cost forecast figures are compared with the
cost planning results. They are either confmned or an attempt is made to "harmonize" the figures.
In any case, the cost plannin~ results ultimately fonn the framework for project realization. This
proceeding, however, is no indicator of whether the cost planning or the cost forecast is closer to the
"truth" - this can only be determined after project completion. Practice has often shown that even
129
detailed project cost planning cannot be considered totally reliable as there are a number of "risk"
factors:
1. The so-called project definition is inadequate. Maybe the persons concerned do not even realize
that, for instance, a specification is incomplete. As a result, the exact scope of services for the
project is obscure.
2. On account of lacking experience the effort involved in providing the services is often
underestimated. There are many explanations of why cost estimates are often overly optimistic
(rarely pessimistic); but such explanations are of little practical avail.
3. Information as to what extent wrong cost estimates influence cost planning for "tactical" reasons
would be highly interesting. By the way, this subject is closely linked with the popular technique
(which rather is a catchword!) "design to cost" which, in practice, is often handled wrong since
ultimately the desire regarding project performance prevails.
The reason that these problems are so important for practice is that the large majority of them is
beyond methodic treatment. The only way to improve the support to practice would be to systematize
and expand the acquisition, evaluation and exploitation of empirical values and to ease their handling.
Further studies in this field seem worth wile, e.g. the structure and exploitation of "empirical
databases" [6].
5.4 Cost Optimization
With regard to time process, the subject "cost optimization" under discussion for many yelQ:"s also is
part of the project planning phase. In practice cost optimization naturally means: Minimizing costs
under defined constraints. First, four basically different problems will be presented without
commentary:
1. Looking for the possibility of performing a project at absolutely minimal costs regardless of
limited resources and specified dates.
The second case comes closer to reality:
2. Determination of cost-minimized alternatives for project realization in consideration of limited
resources but without specified time limits. This refers to the determination of project duration at
minimal costs.
Basically, the results from these two optimizations are the starting point for the two following options:
3. How can the project duration determined in 1 be reduced at minimal costs (but more expensive
than in I!) by a specified period without the need of observing limited resources? That means, one
or several specified dates have to be observed here.
The case most commonly found in practice is the following:
130
4. Looking for a cost-minimized project realization plan in consideration of specified dates and
limited resources. In spite of statements to the contrary from practice, this is only reasonable when
the specified dates stand a chance of being complied with in view of limited resources.
It should be mentioned in this context that the above itemization deliberately has been kept global and
simple and that the presentation of numerous optimization parameters and strategies has been dropped
for reasons of space and clarity.
Cases 2 and above all 3, mostly have been the subject of scientific investigation, some of them 20
years ago. Under such headlines as "cost-optimized shortening of project duration" or "calculation of
the cost-minimized project duration" many procedures were presented in theory and in some cases,
algorithms were developed ([6] and [11] and here numerous other references). Among theory experts
the (Ford-) Fulkerson-Algorithm is well-known. It is based on the mathematical graph theory and
determines the cost-minimized maximal flow by a graph ([12] and [13]).
The question now is: Is this subject still of any interest for practice? (for theory in any case!). If
negative: Why not? If positive: What must be done to make it operational for practical application?
As nearly always with optimizations the interesting point is: Is the costlbenefit ratio of such an
optimization, possibly by means of heuristic methods, assessable? Which are the determinant factors
for such an assessment?
The optimization problems indicated in 2 and, above all, 4 regularly surface in practice when
preparing a proposal for an invitation to tender!
Finally, under the headline "cost-optimal behavior in projects" one aspect should be mentioned which
is not treated in literature. The reason for this: When the corresponding problems surface in practice
they escape methodological treatment and require strategic decisions. In line with project reality,
project cost planning often has to consider price variations in the course of time. In some cases prices
(e.g. for material) drop and effect a tendency quite contrary to the normal project management
behavior of early project performance to create time reserves. There will hardly ever be an algorithm
supporting such a decision, but the problem has to be solved in each individual case (pragmatically,
i.e. not cost-optimized)!
5.5 Cost and Progress Control
Following the difficulties related to the cost estimate during the project's planning phase, cost control
is the second focal problem in many projects. Two largely different subjects are concerned here, one
of organizational the other of methodological nature.
131
5.5.1 Integration into Corporate Accounting
To ensure effective project control, project management is dependent upon excellent infonnation
supply with respect to quality, quantity and currency. The supply should be computer-assisted and
come from corporate accounting.'This requires, however, that this "classical" organization unit does
not only handle its "classical" tasks but also the function "project costs" which must have the same
significance as the other functions. The accounting department has to adjust its services for this
function to the project management's demands, e.g. regarding promptness and, compared with
accounting requirements, less itemization. This function has to satisfy the demands both of cost
planning and control. How really to integrate such a function as an important service for project
control into corporate accounting still appears to be an unsolved problem in many cases. In view of
the increasing importance of project-oriented business, this is a field of activity for administrators who
are equally interested in organization, EDP and cost accounting.
5.5.2 The Determination of Work Progress - an Important Factor in the Assessment of Project
Status
Project control primarily refers to the regular assessment of project status. Apart from the schedule,
the following variables playa crucial role:
* Accrued costs/commitments
* Expected costs
* Work performed
* Originally estimated costs for the work performed
* Work still to be performed.
Basically, this future-oriented status assessment which is performed at defined reporting dates
compares
the remainin~ prQject to be performed theoretically according to the original plan (remaining time,
available funds, work to be pefformed) with
the remainin~ project actually to be performed on account of the actual situation.
The second part of this comparison implies that the planning for the remaining project should be
updated. Apart from the fact that in practice for various reasons this planning update is not performed
or not seriously performed and, thus, the necessary comparison addressed above not possible, it is also
affected by the problems specified in 5.3 "Cost planning" even though to a lesser extent as the project
advances. The principal problem of this new planning is the definition of the "remaining project", Le.
132
the precise determination of the achieved technical project status. This is the central problem of any
project status assessment during project realization. The definition of the remaining project to be
performed theoretically (see above) also requires the precise determination of the interface between
the work performed and, accordingly, the work to be performed theoretically.
For project status assessment, project management, as indicated earlier, requires timely information
on accrued actual costs, possibly broken down according to a project's principal structuring aspects.
The exact determination of this data ultimately is an organizational and, consequently a solvable
problem from a theoretical viewpoint. The situation is different with work progress which is beyond
objective determination as it often escapes precise measurement.
5.5.3 Integration of Time, Costs and Performance - How to Measure Technical Performance?
The following statements are necessary in this context:
* Project assessment is impossible without an integrated study of time, costs and performance.
* Many authors (see [14]) have provided information on the procedures to use and the problems
encountered when translating these procedures into practical application.
* The problem of an integrated approach to time, costs, and performance for project assessment is of
fundamental importance for any project realization and still awaiting a satisfactory solution. A
minimum request is the definition of key figures for project status assessment, which are usable in
practice.
* A satisfactory solution will only be given when the problem of "performance rating" has been
solved in some degree. Branch-specific approaches should also be considered for this purpose.
This fundamental subject of project management still offers a broad, profitable and for practice
extremely interesting field of activity!
5.6 Project Financing
Towards the end, a few remarh on financing! Project costs are not the only important factor. For a
project to "survive" it has to be placed on a sound financial basis. Financial planning - provided it is
necessary at all for a specific project (as a rule only for major projects) - is based on the cost forecast
and, above all, on cost planning. Generally, it can be assumed that project financing on the basis of
cost forecast and planning is assured upon startup of a project. In the majority of cases, finances as
opposed to costs thus pose no problem which would determine a project. Rare exceptions may occur
with long-term and cost-intensive projects with uneven cost accrual and, in certain cases, with projects
performed abroad. Financing, however, may evolve into a major problem when, upon the execution of
133
extensive projects, cost accrual compared with cost planning changes substantially in tenns of time
and/or amount.
6. Final Commentary and Outlook
The author of this paper is aware that more questions have been asked than answers given. In
consideration of the numerous questions it was impossible and, in view of this book's objectives, not
intended to specify the issues in every detail. Exhaustive expert literature is available for this purpose
which has been referred to in part. The intention of this paper was to address a few problems which
can be traced to urgent questions arising in practice. The renewed treatment of this issues is combined
with the recommendation to the expert community to attempt after all developing such a
methodological basis for the corresponding project management fields in order to derive procedures
and tools of practical use and acceptable. In practice this probably would be realized by expanding the
numerous software tools. As far as standard products are concerned, these tools are still heavily
network-oriented. The network as such will be preserved, but the software programs gradually have to
be completed by project management functions like quality assurance, configuration management,
documentation, technical perfonnance/specification and - at least rudimentarily - project law.
This paper dealt almost exclusively with those methodological aspects of project management that
relate to process planning and date scheduling, resource analysis, cost and financial planning as well
as cost control of a project. But was this catalog of unsolved project management problems complete?
By far not! Even when from the current viewpoint the purely methodological field of project
management almost seems to be covered there is still a wide range of other problems and, thereby, of
possible fields of work.
At least some of them will be indicated in the following and characterized in one or two phrases.
* The so-called project "startup" phase has meanwhile been recognized as the critical phase with a
maximum impact on the entire project realization. This subject is currently being analyzed.
However, not the quantity of paper produced will offer clarity but the definition of the focal point
of the problem and the systematization of potential approaches to a solution.
* "Organization" and the "human factor" are extremely often the reason for problems encountered in
the realization of projects. Is a better approach.to these problems possible? First approaches have
been made. But the widely used keyword "matrix organization" by itself does not solve the
organizational problem. The basic idea of this organizational philosophy has to be imparted and
support provided for the concrete translation into everyday project routine.
* Someone who works in project management: Who is he - How do you get there? The questions
related to an officially recognized job description are still unanswered. Project management as a
subject of advanced trainin~ is very popular. But what about the professional trainin~? Is the
134
discipline "project management" a suitable objective of professional training? Could and should
project management be integrated into classical professional training courses? If positive, how?
* A much more intensive utilization of the experience accumulated in previous projects is an urgent
requirement. For this purpose, simple but regular systematic project analyses have to be
conducted. Which project key figures are important and how can they be collected? Only
rudimentary approaches are available. Tools definitely play. a crucial role in this context, for
instance, the installation and service of "empirical databases". Expert systems for project
management are closely linked with this subject, which also is not new. First attempts have been
made in practice, for instance in the construction sector (see paper from A. Schub). But these
systems are still miles away from the importance that a network has for a project.
* Configuration - is it really the stepchild? Experts rightfully complain about the lacking interest of
practice in this subject which is of paramount importance at least for some project types. Only
recently can a slightly rising interest be noticed. The reason for this situation is less the lacking
practical relevance but rather weak points in the area of methodology and, above all, the tools (e.g.
EDP support by small databases) and possibly, inadequate preparation of the subjects with respect
to practice.
* EDP projects apparently represent an inexhaustible subject as they are particularly liable to
problems. Do these projects really represent a special case? What are the principal reasons for
project failure in this young discipline? Is it the high degree of abstraction, the human factor or is
the project handling to engineering standards inadequate? More than other project management
problems, this field calls for exhaustive, systematic, detailed and quantified investigation into the
causes so that at least the prospects for improvements in project planning and realization are
given.
The above compilation does not claim to be complete. It contains, in part, fields of problems which
have become evident and increased in importance only recently. Although the subjects were only
compiled and not presented in detail, it clearly illustrates that there is still ample work for project
management theorists and practitioners a like, also outside the field of development of methods,
procedures and tools for project management.
135
References
[1] Elsner, D.: A Generalized Network Approach to the Planning and Scheduling of a Research
Project. In: Operations Research 10, No.1, 1962.
[2] Elmaghraby, S.-E.: Activity Networks, New York - London - Sydney - Toronto 1977.
[3] Pritsker, A.A.B.: User Manual for GERT Simulation Program Research Report.
[4] Miiller, D.: Methoden der Ablauf- und Terminplanung von Projekten. In: Reschke, H.,
Schelle, a, Schnopp, R. (eds.): Handbuch Projektmanagement, Bd. 1, Koln 1989.
[5] Miiller, D.: Betrachtungen uber Wahrscheinlichkeitsaussagen bei der PERT-Methode. In: Net-
work Methods (Congres INTERNET 1 - Vienne 1967), Dunod-Paris 1969.
[6] Gewald, K., Kasper, K., Schelle, D.: Netzplantechnik, Bd. 2: Kapazitlitsoptimierung, Mun-
chen-Wien 1972.
[7] Dworatschek, S., Hayek, A.: Marktspiegel Projektmanagement Software, Koln 1987.
[8] Schelle, D.: Kostenprognosen bei F+E-Projekten mit Hilfe von Schiitzgleichungen. In:
Huber, R.K., Schelle, H., Hofmann, H.W. (eds.): Waffensystemplanung - Systemtechnische
Ansiitze und Beitriige, Munchen-Wien 1977, S.239-277.
[9] Madauss, B.J.: Projektmanagement - Ein Handbuch rUr Industriebetriebe, Untemehmensbem-
ter und BehOrden, Stuttgart 1984.
[10] Boehm, B.W.: Software Engineering Economics, Englewood Cliffs 1981.
[11] Miiller-Merbach, D.: Opemtions Research - Methoden und Modelle der Optimalplanung,
Munchen 1971.
[12] Ford, L.R., Fulkerson, n.R.: Flows in Networks, Princeton 1962.
[13] Falkenhausen, H.v.: Prinzipien und Rechenverfahren der Netzplantechnik (2. Aufl.), Kie1
1968.
[14] Schelle, H.: Probleme der integrierten Zeit-, Kosten- und Leistungsplanung bei F+E-Proj'ekten
In: Huber, R.K., Schelle, a, Hofmann, aw. (eds.): Waffensystemplanung - Systemtechnische
Ansiitze und Beitriige, Oldenbourg, Munchen-Wien 1977, S.315-353.
136
EXPERIENCES FROM A NEW LOGIC IN PROJECT
MANAGEMENT
Steen Lichtenberg
Abstract
The profound changes in our world during these decades cause difficulties and failures when using the
conventional management and project management logic. A new management style has therefore
grown up, cut up to the modem turbulent world with its demanding people and many interested
parties. The group of new style managers, including project managers, however, has largely no
management aids or planning systems, which are cut up to their new logic. Among the very few
reported systems in this group, the Successive Principle is probably the most general and widespread.
It is taken here as an example for the large potentials of improvements when a manager, his situation
and his tools all fit together. This chapter presents an overview of these changes into a new logic and
the practical experiences of 15 years applications of this new management logic and related planning
systems.
1. Synopsis
The world and its societies today are subject to profound current changes and increasing tUrbulence.
Managers and decisionmakers, by and large, have been forced to give the concept of society, projects
and even nature as a "machine", which can be controlled in all detail.
Human motivation, interrelations, eco-systems and non-rational thinking have to be taken more
consciously into consideration. Consequently a new logic management (including project
management) has developed during the recent few decades, shifting from the discipline-oriented to
more cooperative and network-oriented; and shifting from early detailing and rather static planning to
a more approximate and dynamic planning.
This again has provoked a new logic in planning systems or management aids which should be
developed.
The conventional formalistic and detail-oriented procedures have failed more and more frequently,
with many planning and budget "catastrophies".
A more realistic philosophy in planning principles during the last 15-20 years demonstrated that
project "catastrophies" by and large can be avoided.
The basic conditions shown below, seem to be logical and even self-evident, but in fact, they deviate
drastically from conventionally procedures:
1. Uncertainty is handled correctly and as a matter of greatest importance.
2. All matters of potential impact are dealt with, also difficult and highly subjective matters.
3. Only matters of relevance are dealt with.
4. The project is seen as a whole (interlinked with its environment). Its various aspects (time, cost,
resources, risks, etc.) are also considered tightly interlinked.
The above basic logic has been further developed into operational procedures. They have been widely
applied up to two decades. The feed-back from the users is summarized:
1. It enables managers and decisionmakers to have a more realistic and more shaded preview on
the potential end-results of the plans even at a very early stage.
2. It supports the teambuilding process and the mutual creativity and understanding of goals etc.,
which are so important in a changeable world.
3. It links planning, estimating, timing, risk management, resources, profitability and
environmental considerations into a harmonic whole.
4. It works significantly faster and more flexible than conventional procedures do.
2. Management Changes With the World
2.1 Project Management is Ancient as Mankind
The profession of project management is as ancient as mankind. We know, that this profession has
been exercised for more than 6000 years. The many fabulous projects throughout the history bear
witness to that. Some of these projects, like the Egyptian pyramids, still exist while others have been
development projects. Some of these have been peaceful, others less peaceful, like ancient
Alexander's building of an empire from Greece to India.
Unfortunately, we have very little fonnal knowledge about the principles, concepts and techniques of
project management applied until the last century.
However, much knowledge is surely embedded in the heritage of the old cultures. It constitutes a deep
potential, from which project management surely can be radically improved.
138
2.2 The Present Conventional "Generation" of Project Management
From time to time a new "Generation" of project management is born. Naturally it takes the colour of
the culture and the period of time in which it is born.
Best known is the generation which grew up in Europe and not least in North America during the last
part of the 19'th century and which matured after the last World War. Some decades ago it adopted the
computer and many ideas from the Operation Analysis or the OR-field. This concept, basically quite
old, here denotes the conventional concept of project management.
No doubt, this generation was a tremendous step forward. It has been of significant benefit to the
societies during this century. No wonder that its prestige is large, and that we often hear the postulate
that this is good project management and the only way to achieve good results. But is it correct today?
2.3 Today's Conventional Project Management is not Perfect
We realize many good results of today's project management. And many aspects of its philosophy are
highly relevant today. An example is the concept of the critical path.
On the other hand we have witnessed many failures, and even a long row of planning catastrophes.
Serious deviations in budget, functional quality and time are so common, not least in international
projects, that everybody is surprised when the targets are met
Even in the Western countries and in the homeland of this concept of project management, the USA,
we see frequent and even serious failures. However, we are aware of this and seek for new ways.
2.4 Alternative Concepts of Project Management
We must not forget, that today's conventional concept of project management is born quite many
years ago in a world very different from ours, and that it was born in a very specific culture, namely
that of the United States of America.
As already described, the conventional concept has gained a worldwide prestige due to its many good
results and its age. Due to this prestige it is used far beyond its natural limits and its conditions.
One cannot shut one's eyes to the fact and continue to believe that there is only one right way.
Alternative forms or supplementary new "generations" of project management are needed. Such
alternatives have existed modestly in practice for decades, others have manifested themselves at
recent international congresses and seminars and many more should be possible.
Why do alternatives arise? Quite simple - because mankind is constantly learning. We have learned
that the world, its people, its nature, its wealth, its ecosystem cannot simply be considered as a
"machine", which can be constructed in detail to function perfectly and fully controllable. We have
139
learnt that people cannot always be considered as a resource ("labour") and that nature's resources
cannot freely be exploited without consequences.
We have learnt simply through the differences that exist in cultures, people and projects. In the same
way that we do not all accept the same life-style or the same car, we cannot all be suited to the same
form of project management
3. Contributions from the Old Cultures
3.1 Old Experiences
Cultures outside the central Western world have practised project management techniques for
thousands of years before the Western world began to use them. They are experienced in problem
solving in a turbulent and harsh environment with scarce resources; the West has only just begun to
meet and come to terms with such conditons.
With their background, these cultures are able to teach the West ways of solving many of its own
problems, not to mention those of international projects. There is an increasing tencdency for the West
to recognize its lack of perfection and to be prepared to leam form others.
Some new concepts may be of general value to all countries, while some may be of use to more
simplier conditions, such as dual-nationality projects. Other ideas may be mixed with Western
concepts and result in new and more international generations of project management.
Naturally, many elements of conventional project management will still be of value in many cases,
but such a dualleaming process must be considered a significant step forward.
3.2 Specific Potentials
The author does not feel competent to evolve and describe potential new generations of project
management arizing from the Far East- the Middle East- and other old cultures.
Only some aspects intuitively seem to make a large promise of improvements. That is the old art of
diplomacy as well as the art of negotiating and "consensus seeking" procedures. Add to this the
capabilities of viewing the world in more dimensions than the physical one.
Rather than evolving these potentials, this chapter intends to provoke project management people
from these old cultures to formulate alternatives, which hold improvements in this art of project
management
Also more remote parts of the central Western cultures, like the Scandinavian region, might hold
potentials for alternatives.
140
The author has had the privilege to follow particular Scandinavian trends, to contribute to their
development [1,2,3,4], and to experience how such concepts work in practice in Northern Europe
[5,6,7]. To exemplify such potentials of alternative approaches, one of them is outlined below. I hope,
the reader will find some coincidental concepts.
4. Management and Project Management Styles
Project management seems to have been a child of general management during the past periods.
Today, this is going to reverse. Mega projects are as large as companies and other permanent
institutions. And companies have to navigate more and more in periods of a few years in a turbulent
and demanding environment.
Shortly they now meet the same conditions as project managers have learnt to act with. No wonder
that the best general managers today are willing to learn from the PM profession.
Let us illustrate the subject through two different approaches to PM a well-known one and a new one
which have grown strong among others in recent years in a fairly remote part of the Western world:
Scandinavia.
But ftrst: What is project management?
4.1 What is Project Management?
A proper, formal deftnition will not be attempted here. As an informal attempt with relevance to large
governmental projects, we might see it as a "marriage" between (1) a governmental body (client) and
(2) a projectrnanaging body (project manager, PM). These two parties are - like husband and wife -
typically very different:
The client with a severe administrative responsibility for a large set of complex functions and related
traditions and attitudes.
The pmject mana"r, on the other hand, in his world of constant changes and more or less fuzzy;
problems must be more "entrepreneurlike" of attitude and habits.
The client prefers order and full and detailed control. He is responsible for severe administrative tasks,
which need fum routines. For obvious reasons he dislikes sudden changes, not to speak of disorder.
He is typically no friend of risks, which seldom leads to beneftts for him but more likely to
punishments.
The Project ManUer <PM) and many other project people may prefer order too. However, he will
never be able to live in the degree of order, which is possible in a more permanent organization.
His routines are few and must be changed from time to time. In spite of all planning efforts, he
frequently must handle unforeseeable events. His primary function is to recognize potential problems,
141
to coordinate many different (often non-rational) people and parties, each with their own attitudes,
habits and interests.
Both parties need estimates and planning, but the PM typically lives in a highly uncertain
environment with important "soft" or fuzzy factors, controllable only by using a strong element of
intuition and imagination.
4.2 Mutual Respect
It is well known that two parties working together and respecting each other, can be a much stronger
entity than each of the parties.
The client and the PM brought to a "marriage" via a project goal are very different, with each their
experience, traditions, and attitudes. There is no right or wrong attitude, both are equally natural, born
out of necessity, and both equally respectable.
Mutual respect
is probably the most essential
factor of success.
However, each party must also respect the limits of relevance of the two sets of attitudes.
A governmental body would not continue successfully very long, fulfilling its many functions by
acting like a PM. On the other hand a project, performed like a governmental body would most likely
be a failure.
4.3 Differences and Alternatives in PM-Work
Throughout the years PM-work has taken over traditions from many other areas, such as from
permanent governmental or other public administration, the natural sciences, the industry and not least
from the armed forces.
This of course has given some problems and inefficiencies because of other conditions in project
work.
The rapid changes in our world, towards a higher complexity, closer international connections,
scarcity of resources, financial troubles, radically changed public attitudes, etc., etc., are reflected in
project work.
Too many projects more or less fail to meet their objectives. It is always hard to fight modem
problems with old tools, not built for the problems. No wonder that alternative project attitudes grow
up in an attempt to improve PM. Some of these trends are illustrated in the figure below.
142
AREA and ATIITUDEI ATIITUDE2
ASPECTS (conventional) (more untraditional)
Order and from top to bottom yes, but most in goals

discipline and major aspects
Dele,ation limited widespread
Exacmess stressed overall to the necessary degree
Unforeseen try to avoid, early awareness and

events and through detail identification, ready
improyization planning, regulation to take advantage of
and keeping to the unforeseen possibilities
plan
("An unforeseen
mountain? Move it
away!")
Problems, are hidden or at are dealt with openly

~ least discretely and as early as possible
uncertainties treated
Perfonnance prefer going steadily boosting and going

and smooth or as through different phases
planned
Interested as few as possible many parties are often

~ involved
often "high" as "flat" as possible

hierarchical stressing "parmership-
mode"
AccountSY- taken from admini- only to the required

~ strative functions, degree,
and taken as planning are not used for planning
aids purposes
Estimate-and conventional, approximate and simple,

schedule sy- detailed systems if necessary with a
~ hierarchy of sub plans
Replations detailed (e.g. as few regulations, rather

a "project handbook", a "stakeholder" or
and formal) situational analysis
Estimatin, and bottom-up, summing The Successive Principle

plannin, prin- up from a complete or similar top-down
~ set of details principles
Figure 1: Various trends or attitudes in PM. In practice we often meet a mixture of attitudes.
143
5. A New Logic in Planning Procedures
Among the many traditions, which PM has taken over from others, some seem a bit outdated and less
relevant. To ease the following discussion, a few of such aspects will be shortly highlighted.
5.1 Dominance of Exactness
Exactness as a concept plays a dominant role. This concept has accomplished remarkable results in
the natural sciences and technology as well as in industry. No wonder that it has gained its own
worldwide prestige.
Projects deal with (nonrational) people, often also with nature and a long set of "never tried before"
activities.
Therefore, budgets, plans, schedules are away from being exact. Nevertheless everything must appear
exactly. For this reason many important, smooth, or fuzzy factors are neglected.
Conclusively we often
Prefer to do it definite
although definitly wrong
rather than to do it
approximately right.
The new logic is consistently to use the necessary degree of exactness.
5.2 The Prestige of Detailing in Itself
The prestige of detailing is a wellknown fact. We all know the heavy books with "bill of quantities"
and similar estimates holding thousands of items. We also know of people which are proud of their
schedule system being able to handle several thousands of activities.
Up to the contract phase and also in later stages, the total budget, total benefit, total duration, etc. are
the primary parameters.
However, to calculate such parameters you only need to specify about 100 separate items to reach
sufficiently close to the maximum exactness. This has been proved theroretically and practically [4].
Measuring efficiency as the necessary work for the performed work we find a low degree of planning
efficiency not accepted elsewhere:
100
- 5p.c.
2000
144
Paradoxically, we are in fact able to make more realistic estimates than most conventional ones with
about 100 items. ('This is under the condition that the fuzzy, so-called nonmeasurable cost factors are
systematically and correctly included).
The new logic requires to detail as long as it has a positive, measurable effect upon the quality of the
total result or in case other specific reasons exists.
5.3 Priority to the Easy Matters instead of the Important Ones
Most of us, as professionals and private people, accept the principle to give a higher priority to the
important aspects in a given matter and a lower priority to the less important ones.
But not in project worle! Here we generally give a high priority to the easily calculable matters (bricks
etc.) and a low priority to fuzzy matters of a far higher degree of influence and importance.
The Sydney Opera house is probably the most significant example: reported to end up with a cost of
16 times the original we have:
Work performed p.c. of Relative importance

the total for the quality of
work the total result
Thousands of 99p.c. 5-lOp.c.

specified physi-
cal items
Allowances for 1 p.c. 90-95 p.c.

"unforseen", etc.
Figure 2: Inefficiency in conventional planning work
The new logic is to give priority to items and factors according to their potential influence upon the
quality of the total result.
5.4 Interrelated Areas are Kept Separated
Cost estimates, quality, time; benefit or income, as well as resources are interlinked with each other as
we all know. Nevertheless these areas are kept separated in conventional systems. If you are a
scheduler, you are concerned with the schedule. An estimator works with the costs and influences
through his choices in all the other areas. In principle everybody should inform everybody else; but
145
this is not properly done. The fmal result, as we all know, is seldom consistant to the necessary
degree.
The new logic is to keep interrelated areas interrelated, not to disturb the whole. It can be done
through cycling around benefits, costs, time, etc. in groups of keypersons in still greater detail, as later
exemplified.
Area Conventional logic New logic
Uncertainty Should be avoided, or Is openly acknowledged as

hidden, treated as an part of the real world.
necessary evil, and Considered as a most
put aside as a separate exiting and important
speciality, like part of managing and
"Risk Management" planning. Dealt with
seriousness (i.e. according
to recognized natural
laws) and integrated into
the planning process.
Quantification All figures, which can Figures are in general

be quantified and evaluated in stochastic
calculated are calcu- terms. All factors of
lated in detail, while importance are included,
"non-measurable" fi- whether "calculable" or
gures are eliminated not. On the other hand,
using relevant pre- non-significant figures
conditions. are not specified before
necessary.
External and Assumptions are gene- Assumptions are dealt

and internal rally transformed into with in great detail.
assumptions firm preconditions Their most likely effort
(to allow a formal and the uncertainty
calculable fignre). attached are consiously
No fum requirement evaluated.
to the realism of these
preconditions.
Evaluation Hunch evaluation Evaluations, including

is used when absolutely hunch evaluations are
necessary. No formal performed, while using
requirements to the evaluation technique
quality of these to ensure against
evaluations. biasses.
Figure 3: Summary of old and new logic.
146
6. The Succesive Principle: An Example of the New Logic
6.1 The Background
The Successive Principle has in recent years proved to be the most remarkable aid to decision makers
and to project management. The most crucial project decisions and project management decisions
today are actually taken under severe uncertainty. At the same time the margin for wrong decisions
has decreased. both in public and in private business.
6.2 The Need for a New Principle
Conventional techniques and traditions do seldom cope with this situation. The well-known demand
in the court to a witness is to tell the truth, the whole truth, and nothing but the truth. An analogous
need has grown up for management: to tell the decisionmakers the essentials, all the essentials, and
nothing but the essentials.
Conventional techniques, like a cost budget, do not tell all the essentials. It primarily deals with
physical items, such as bricks, wires, etc., while major cost causes from human and organizational
imperfections, nature, changes, errors, delays, etc. do not appear in the budget to a relevant measure.
Also, conventional budgets hold much more specification than necessary. This often seriously delays
the estimating process and damages the overview. It has been proved that detailing further than about
100 items does not improve the exactness of the total result.
Finally, there is a strong need of dealing with the uncertainty both in a correct and operable manner.
6.3 The Effects of the Basic Principle
The Successive Principle and its basic procedure comply with the needs above. The results hold all
essentials. Budget surprises are therefore largely eliminated, even in the early phases of projects.
Further, the degree of detailing is systematically kept at a minimum level of 100-150 items. This
drastically shortens the work load of performing a budget or plan.
Specified information of areas of risk or areas having possibilities of an improved cost/effectiveness is
given to the decisionmaker.
Finally this procedure allows realistic budgets to be made at very early conceptual stages of a project
or project alternative. That's the matter because lack of information is properly transformed into
uncertainty and expected values.
147
6.4 The Basic Procedure (simplified)
The scope of practical applications is very wide. It covers among other things the total result of cost
estimates, investment budgets, costlbenefit analyses, profitability evaluations, market evaluations,
prognoses, energy balance calculations and not least schedules.
Below it is illustrated as a cost estimate or the like.
1. Historically based reference conditions are defined and related, actually expected conditons are
described verbally.
2. A short, but complete list of items (or factors) is established. This list includes not only physical
parts. Significant groups of contingency, potential savings, etc. are also explicitly stated as
items or factors.
3. A mean value and a conditional uncertainty margin are calculated using Bayesian Statistical
Concepts (analogue to the triple estimate in the original PERT method). The relative
importance of every item to the total result appears as a priority figure.
4. The items or factors of highest priority are specified into sub items, and treated in the same
manner as above. Finally they are inserted into the main estimate.
5. Repeating such cycles of detailing (or re-evaluation) successively a dozen times or so will result
in a realistic total value, a realistic margin of uncertainty and, not least, a set of priority figures
indicating the areas of primary interest for the decisionmaker and for the further management
process.
The principle was frrst initiated by the author [1] in the late 60's and early 70's. Since that time it has
been verified and further developed through a Scandinavian and international research effort. Since
the mid 70's it has been applied internationally in both public and private enterprises, however
primarily in Northern Europe.
7. Experiences and Applications
These new principles have been applied to several hundred projects with varying competence and not
always using all the above-mentioned basic elements. Also, many project managers have had a
learning period.
Let us consider a subset consisting of the 250-300 projects in which the author and his partners have
been involved and where all the above facets have been used. This bulk of projects includes all kinds,
from strategic marketing projects to large offshore projects, from biotechnical R&D to large
commercial software-heavy telecom projects. All public and private sectors, many countries and
148
project sizes up to the £ 1.000 M class, are represented. The total volume amounts to approx.
£ 40.000 M. The projects have been at various stages, including the conception stage.
The experiences fall in some categories outlined below.
7.1. The reaponsible ke.xPersons to a large degree share a common oyeryiew of the project and its
main aspects, having also made sure that requirements, possibilities and restrictions cope with each
other.
7.2. Surprises are lar&ely eliminated. This means that if you come up with an end result of $ 20 M as a
most likely result and have a standard deviation (= "mean error") of say 10%, the actual value will be
a little larger or a little smaller than $ 20 M at a 50-50% chance. The actual deviation from the 20 M
will at the same time potentially be around 10% i.e. from 0-20%.
7.3. The methodology yields information of specific risks as well as possibilities of improved
efficiency and competitive power. The information includes a priority figure indicating the
importance level of each specific source of uncertainty or risk.
7.4. It allows considerable reductions in the time nxwired for the analysis. Compared with other
comparable techniques it is generally performed faster by a ten factor, thus saving valuable time
before major decisions or before tenders are given. The reason behind this rapid performance is the
systematic procedure of dealing only with essentials which is embedded in the method.
7.5 Examples of Application
The method also allows a serious budget made already at the conceptual stage of a project. The severe
lack of information at this stage is systematically and visibly embedded in the estimate.
The results outlined above have caused during the later years a widespread application both in
construction, industry and government,
o A verification of the realism of budgets, schedules, etc.
o Bid estimates
o Calculate reasonable deadlines or budget frames
o Control of bids, budget proposals, etc. for biasses
o Early estimates of investment, profitability, etc.
o Serious budgets in cases of very imperfect data
o Analyses of untraditional solutions
o Risk analyses, incl. verifying contingency levels
o Prognoses
149
o Market evaluations
o Energy balances.
Being fairly untraditional and therefore difficult to describe, and still mainly described in the
Scandinavian languages, it has, so far, its largest application in Scandinavia.
An experience of larger potential importance, especially for third world countries, is the fact that the
procedure can handle imperfect data in a manner, which yields very appropriate total results. All
under the condition that the analyst has been trained in subjective evaluating technique ([8],[4]).
7.6 Difficulties
"You seldom get something for nothing" as an old proverb says. This is also true here.
The strength is that it deals with old taboos and utilizes capabilities of the analyst and manager which,
so far, have been unused. Experiences prove that judgement and common sense evaluations with this
principle are applied more consistently and in a quantitative form.
People are, in fact, generally surprisingly strong in this, but the difficulty is, that they are completely
untrained. Add to this, the problem that Westem education, including basic schools, counts entirely
with sharp-edged calculations to such a degree, that many people do not feel it advisable to make
"guestimates" , except in emergency situations.
The Successive Principle operates with subjective uncertainties, even those resulting from social
factors and other fuzzy factors. This is handled within the framework of the Bayesian statitistics,
people do not find it advisable to deal with subjective uncertainty. However, these difficulties fade
away after having applied the methodology for some time. Exactly like learning to drive an
automobile.
8. A Case Story: Integrated Planning and Start-Up Sessions
A project meets a few critical stages, typically before major milestones or when a new phase has to
start and new people enter the stage. At such occasions project managers and senior managers have
reported about the significant benefits of using these new procedures. An example of this application
is outlined below.
8.1 Basic Principle
The basic concept is to cycle through and back between (1) analysis of consequences and (2) a
replanning. This shifting is continued until the expected consequences or results are satisfactory.
150
Each of the steps of analysis mentioned above is a cycle in itself through a relevant number of the
following steps: schedule, profitability, cost resources, risks, etc .. Each cycle in still greater detail.
Every of the steps above, for example "cost", again consists of a set of subcycles, successively going
into increasing detailling.
8.2 Preparations
The project manager, with his specialist moderator, invites the key persons of the project to a series of
working sessions. The key persons should be competent representatives of the parties most involved
in the project, and those who share the real responsibility. The role of the moderator is to ensure that
the "technical" and computational parts of the procedure run without biasses. He is also supposed to
answer supplementary questions, according to his experience from earlier sessions.
8.3 Facilities
The meetings are preferably held in a pleasant location and in a room with the relevant equipment, i.e.
possibilities to put up plans on the walls dynamically, as well as PC facilities.
The first meeting will normally require a full day, while the following sessions can be of half or full
day duration. They can either be held immediately after the first or at intervals of, say, a few days to a
week.
The meetings are consciously informal and every attempt to facilitate an open and direct
communication among the participants as well as mutual respect should be done, so that they finally
will consider themselves as part of a team, which collectively attempts to achieve its goal.
8.4 Purposes of the Sessions
These meetings serve for several purposes. First of all, a common agreement should be reached
concerning goals and when the project can be finished. Secondly, they should highlight the problem
areas and positive possibilities which may exist for improving the end result. Thirdly, that the key
persons get to know each other well, which will make future communication far more efficient.
Fourthly, that every participant will finally feel more personally responsible to the master plan and
accomplish his particular part of the project. Finally, the plan and prognosis of the time and cost
requirements can be made highly realistic and competent through this methodology, on the condition
that the procedure below is competently followed.
151
8.5 Content of the Sessions
(1) The project objectives, restrictions, and planned organization are developed by the PM or a
representative of the client/project owner and discussed until understood and agreed upon to a
high degree.
(2) Then a brainstorm is performed to identify important items and activities and the external and
internal general factors which might be of importance. The result is listed on the wall (today
more and more on PC facilities). General factors are those sources of uncertainty which more or
less influence the project result as a whole, such as "project organization", "degree of new
technology", "clients change order policy", "local support", and the like.
(3) A masterplan, typically as a precedence diagram with 1025 major activities, is created on the
wall with active participation from the participants. When relevant, a preliminary discounted
cash flow diagram and a related net present value estimate, are made at this stage.
(4) The project environment (external as well as internal) is defmed in detail, using the above list of
general factors. Two sets of defmitions are made: one simplified and historical with reference to
well-known data, while the other has to be strictly honest, focusing upon the uncertainty
typically embedded in such factors.
(5) Activity durations (and time lag if any) are evaluated by the group as a triple estimate of
minimum/most likely/maximum values. The moderator ensures against biasses. (He should
therefore be educated and trained in "evaluation technique"; see [4,7]). All values must be under
condition of the above established "historical" set of definitions.
(6) The possible additional effect upon the total result of each general factor, in comparison with
the "historical" defined conditions, is then evalutated by the group. In some cases, the actual
conditions seem unusually favourable; for example, a new and more efficient project
organization, or a particularly competent client, who knows the importance of a' restrictive
change order policy. A reduction of the above "normal" project duration or cost is in such
occasions evaluated. However, in most cases the actual conditions include all sorts of potential
problems from nature, and not least from human imperfections, errors, lack of information,
changes, etc.. All such factors have to be evaluated, specifically and seriously, in order to end
up with a realistic additional allowance and thus a realistic prognosis of the total project result.
(7) The above procedure puts emphasis on the activities and factors, which are most critical to the
uncertainty of the result. These parts of the plan are now subjected to further specification into
more detail or further analyzed. This successive and systematic "intelligent" detailing process is
to be continued as long as necessary.
152
(8) The above part of the procedure is called successive scheduling, and it results in basically
correct stochastic time calculations, and not least a numerical priority figure indicating the
major problem areas and potentials of the plan. It might be an activity being both critical and
uncertain or some of the general conditions, e.g. "cooperation between contractors and client".
(9) The above procedure is also applied in a similar manner towards the net present value estimate
or the net income budget, the investment or resource demand.
8.6 Replanning
Typically, the plan is not acceptable after these first sessions. At a new session, a replanning is
performed. It may be a detailing of one or more activities in a similar manner as described above or
decisions to improve, say, the communication effort between some of the parties, or working in
parallel andlor with increased resource capacity.
A series of such successive improvements of the plan (each with an adjusted prognosis) is performed
until it is agreed to be the best possible and as exact as possible. The above mentioned priority figures
playa dominant role in these repetitive steps.
Two to four full or half day sessions will be sufficient in many cases. However, the group often
decides to repeat similar sessions, say monthly, as a most efficient high-level follow-up routine.
9. Conclusion
The critical changes in the societies during these decades have provoked a new style or logic in
management and in project management, and also a new dialogue between these two related areas.
Management and planning prodedures and aids, however, have fallen behind. The large and
widespread systems use the newest computer technology, but nevertheless seem to rest upon an
outdated logic, still trying to describe the real world as a perfect "machine" which can be perfectly
controlled, if you only specify it into exact details.
Among the few planning systems, which rest upon the new logic, the Successive Principle seems the
most widespread and broad.
This principle and some experiences from its users are therefore outlined to exemplify the potential of
project management improvements and to call for other related systems.
153
References:
[1] Lichtenberg, S.: Successiv Kalkulation (Successive Estimating), De~ 1970nl.

[2] Lichtenberg, S.: Project Planning a Third Generation Approach, Lyngby (Denmark) 1974. See
also: Lichtenberg, S.: Project Management Systems Monsters or Assistants to the Manager In
Proceedings of an International Symposium, Project Management Institute, Wash. DC. 1976,
pp.152-158.
[3] Lichtenberg, S.: The Successive Principle, Proceedings, Project Management Institute, Wash.
DC. 1974, pp. 570-578.
[4] Lichtenberg, S.: Projektplanlregning i en foranderlig verden (Project Planning in a Changeable
World), Lyngby (Denmark), 3rd ed. 1990
[5] Lichtenberg, S.: Real World Uncertainty in Project Budgets & Schedules. In: Proceedings
PMI/lNTERNET Joint Symposium, Boston, Sept. 81, pp. 179-193.
[6] Ogard, Leif: Experiences from new Planning Methods, Risk Estimation and Team Building
Concept in the Sydgas Project, the first Natural Gas Project in Sweden. In: Proceedings of the
7th INTERNET Congress, Copenhagen Sept 82.
[7] Lange, Nils: Subjektiv Vurdering (Subjective Evaluation) M.Sc. Thesis 1986.
[8] Glahn, J.E., Lichtenberg, S.: The Successive Principle: A Quality Assurance Technique for
Schedules and Budgets, Waterloo (Canada) July 1984.
154
THE APPLICATION OF KNOWLEDGE IN PROJECT
MANAGEMENT
Jurg Brandenberger
Abstract
Project management is one of the methods taught for years but not applied to the extent to which
practical needs would actually demand. What could be the reason for this?
1. The Development of Project Management and its Application
. If one considers on one hand the knowledge available as it is expressed in publications, congresses
and conferences and on the other hand practical project applications, one draws the conclusion that
there is a ~onsiderable difference between both. The process of application is inadequate so that great
differences arise between that what is possible and that what is actually carried out. This difference is
not always realized by the practician, however; he is restricted by the "intended" to do or what he
"believes" to be done.
In a widely supported analysis [1] the areas of knowledge were ascertained especially in the area of
project management in the last few years.
Figure 1 shows a rough summary of the results which clearly point out the change in the main themes
as they were developed at the international conferences INTERNET (Europe) and PM! (North
America).
It can be seen that-the processing and presentation of a new "area of knowledge" has a life span of a
few years. The scientists tried to seperate themselves from the actual trend.
Frequency
Network planning
RepresentaUon
of PM areas
PM confonn application
pratlcal
applications
1970 1975 1980 1985 1990 TIme
Figure 1
Considering these areas, it should be noted that they do not belong exclusively to the field of project
management. This leads, especially for line-managers, to the question of the degree of autonomy
which can be granted to the field of project management. It can be stated that the knowledge and
understanding of management are increasing and we can therefore assume that more and more
projects are carried out correctly. It must be taken into consideration, however, that project
management is not at the foreground but represents rather a supporting tool. Marketability is the most
important factor, especially for the management; a product must be able to be sold successfully.
There is mostly a time-lag betweel). practical project management applications and the appearance of
new ideas. The new knowledge is sometimes applied incorrectly and the resulting lack of success
leads to disappointment and temporary scepticism. Furthermore, there is a considerable reduction-
factor between possible useful applications and those actually applied.
156
2. Application Problems
What are the reasons for the limited application of project management in practice? The following are
some of the most important:
o Lack of knowled~
Situations, in which the effective knowledge of the participants of a project does not justify the
project's demands, are very common. A reason for this could be, that some areas of project
management are not perfectly understood or taught (for example, leading a team or dealing with
environmental influences).
o Inunuctical«x»s
An example to this is the present state of user-friendly EDP-programs. Programs that record the
development of a project well are relatively complicated. The necessary training is too intensive
with regard to the economical and laboural points of view. Therefore it has a deterrent effect.
o The effort IeQ.11ired for an ap.plication is underestimated

The knowledge available from various sources is not specific for a company. The effort required
to adapt an application for a particular company is often underestimated. Reviews, introduced to
avoid additional expenditure, lead to the fact that the system does not fulfill the set expectations,
and the danger arises, that the exercise is broken off, or maybe the energy, and will reach the
defined objective, despite increased efforts are simply lacked.
o The status of prgject mana~ement is not recowized sufficiently by mana&ement

It has been recognized since a long time, that a project management training should be adapted on
the management level. It is proved to be extremely difficult, however, to take over this topic into
management. Thus the knowledge necessary for the correct development and integration of
project management in a company is often lacking. The absence of a definition of the status of
project management leads to the fact that individual functions are not supported in view of the
whole framework but according to that what each manager thinks is best.
o The status of the function project leader

The position of the project leader is not attractive enough for many employees who have the
necessary qualifications for the job. The frequently justified idea that a career is to be made in line
function leads to a competitive advantage. An employee recognizes the continuity in line function
and poses himself whenever possible in line for a desired position. On the contrary - the less
clearly dermed chances for development as a project leader are underestimated. This leads to the
domination of line function, even in organizations which basically recognize the task of a project
157
leader, such as the public construction industry. The project leader acts as a "specialist" with the
corresponding restricted authority.
o Unwanted transParency
One of the rarely openly admitted reasons for the resistance against the introduction of project
management is the absolutely striven transparency. To say "knowledge is power" soon becomes
relevant. According to the company's dependence on individual information holders, the project
manager will have to eliminate a varying degree of problems in the development and operation of
a project management program.
The reasons cited above may be an incomplete list, but they help to explain why project management
has not developed in the last 25 years.
3. Solutions
With regard to the assessed situation, there is now a necessity of looking out for possibilites of
improvement. At the same time one must remember that project management is an extremely
practice-orientated field. In order to improve the transfer of knowledge between the sources of new
solutions (universities, research centres, etc.) and the users, a basis has to be found which allows
closer co-operation between the two groups. An example would be research projects that are mutually
defmed and applied in practice. Reciprocal feed-back could develop by intensive co-operation in the
different areas. The aim of this effon has to be that both groups reach a new standard. This standard
would be consolidated by the practitioners and used by researchers as a basis for far-reachin~ aims.
Contributions to this effon could also be made by INTERNET, the international project management
organization, and by the national project management societies. A prerequisite for such a contribution
is, however, suppon from the involved companies, and thus the circle in which project management
knowledge should flow, would be closed.
References;
[1] Dworatschek, S., Gutsch, R.; Wandel der Themenschwerpunkte der internationalen
Konferenzen von INTERNET und PMI. In: GPM Nachrichten, 1987, Heft 13, S.23-33.
158
Per Willy Hetland
Abstact
Over the years our interests have moved from rational tangible techniques of planning and control to
holistic intangible issues of project management However, recently goal oriented measurements of
manager's performance have triggered the need for normative decision support systems. Control- now
in the form or controllability - has again become a hot issue.
The article will take us through the major development steps of project control science. Although the
need for intelligent control philosophy has become crucial to most capitalintensive projects, the
control perspectives are general and as such could be applicable to most projects.
1. From Planning Experts to Project Managers
The fIrst associations of Project Management were a result of a major breakthrough in project
planning - the network schedule. Most associations even today have a logo derived from a network
structure. Soon we developed excellent skills in network planning - in fact project planning was
considered the key factor to successful project management.
Nowadays planning is out - management is in. We have even extended the use of project
management science far beyond the project itself. We talk about MbP - Management by Projects - as
the key approach to successful business management. General management is reduced to maintaining
status quo - MbP is designed to manage anything else but status quo.
MbP is not the only perspective competing with the traditional concept of general management.
Another perspective is related to quality. In the 50's the focus was on quality control, in the 70's on
qUality assurance and nowadays on quality management or, more specifIcally, Total Quality
Management (TQM). MbP and TQM are two different perspectives on general management, they
enlighten management through different pictures - metaphors.
When we meet on project management seminars we tend to focus on managerial aspects of projects.
For some reason network scheduling and project control seem to be excluded from the tasks of the
project manager - they are referred to as technics carried out by expert staff, not by managers. A
manager's role seems to be considered as dealing with people - selecting and motivating people,
building teams, directing people, resolving conflicts between people and so on. Maybe that is what
managers mostly do, but planning and controlling are defmitely managerial functions even if some
managers rely heavily on expert staff to carry out such work.
No matter, a clever project manger is with people; it is of little use if he fails to be in control of his
project. A second chance may not be given to him - his profession as a project manager could be
finished.
2. The Nature of Project Control
Control is simply the skill required to bring a project from the start to the end without jeopardizing
predefined goals while going along. Maybe the best analogy to project control is to manoever a ship
from one port to another. At sea you continuously track the ship's movements and estimate the likely
time of arrival in the next port. If you deviate from your plan, you take appropriate corrective
measures. To make the project analogy more real, think of a ship you are not familiar with, a crew
you do not know, headed by an uncertified captain bound for a port nobody has been to before.
"Controllability" simply means we are in control, we are confident that the project objectives will be
met and that we can handle different situations as we proceed. History [1] is filled with projects that
became uncontrollable for some reasons - just think of the Sydney Concert Hall, the Concorde, the
Space Shuttle, numerous process plants, offshore platforms and last but not least the Eurotunnel. In
addition we have all the "smaller disasters" not quoted in literature but we all know them so well from
our own experience. Whatever the reason for a failure would be, the consequences hurt all of us in
some way. Investors lose money or get bankrupt, project managers and members are fired. Whatever
our involvement in the project, we become losers - we don't have any control.
Control is not critical to all projects. However, the higher the risk and the higher the capital exposure,
the more crucial is the need for control. As a consequence construction projects (high capital
exposure), R&D projects (high risk) and venture projects (high risk and high capital exposure) are all
critical to control. What is left are projects of a typical trivial nature like surveys, studies, campaigns,
arrangements and similar unroutine tasks.
160
3. Physical Progress and Efficiency
In ancient times control was used to express that something was checked and found o.k. Items that did
not meet the preset specification were rejected or returned for improvement. Items that did pass the
control counted as a measure of physical progress achieved. Typical units of measure were tonne,
metre, square metre, number of pieces etc. As different items had been measured in different units the
need for a common yardstick soon appeared. Certain equivalence measures like a tonne equivalent
have been invented, but as projects used to be manpower intensive, manhours became the dominating
yardstick. Estimating norms were created which made it possible to compare tasks of different
workscope. Scope was measured in number of standard manhours which turned out to be very
convenient as it was easy to convert from scope size to the number of man needed.
As work progressed, physical progress was measured simply by recording the number of manhours
earned - the number of standard manhours estimated for work performed. If a piece of work was
estimated to take 50 manhours, 50 manhours were earned when complete independent of how many
manhours it actually took.
Physical progress was typically plotted and reported as s-curves; see figure 1.
VOLUME
TIME
EARNED MANHOURS
PROGRESS BASELINE
Figure I: Reporting of physical progress (Source: [3])
Manhours even turned out to be a convenient measure of efficiency as actual manhours consumed
were directly comparable to standard manhours estimated for completed work. The ratio actual to
estimated manhours expresses the productivity or efficiency factor. If greater than I, efficiency is
below the performance standard and additional resources are required.
A core issue is the question of who is going to pay for additional resources, the contractor or the
client. That depends on the contract form and on the extent the contract obligations are being adhered
to. Clients seem to favour lump sum contracts, then it is up to the contractor to work efficiently. As
161
payment is fixed, his profit is directly linked to his efficiency factor. A lump sum contract only works
if workscope is defined in detail. This became a big issue on North Sea Projects after the official
investigations of cost overruns in UK and Norway in the late 70's [2]. To prevent any surprise,
workscope was catalogued in CTR sheets - sheets describing cost, time and resource requirements
for each package of work for the' complete project. The CTR sheets were grouped in milestones. To
put a tight pressure on contractors, payments were linked to the accomplishment of milestones. If one
single CTR for a particular milestone was not performed, the milestone payment was. simply not
made. This put a tremendous pressure on contractors to do work in particular sequences regardless of
how efficient it was to work in that way. Some clients selected a professional project services
contractor (PSC) to administer project work. The concept certainly gave no surprises, but for what
costs?
A different approach is to let contractors work on reimbursable contracts but with incentives for cost
efficient work performance. The more efficient he works, the more profit he takes and the cheaper it
is for the client. The contractor and the client both benefit from efficient project work.
Cost efficiency is plotted and reported on s-curves; see figure 2.
NOK
! I
BUDGET
OVERRUN
DELAY IN
VOLUME
COST
OVERRUN
'-v--' t TIME
DELAY
IN TIME
BUDGET OVERRUN ACWP, - ECWS,
COST OVERRUN ACWP, - ECWP,
COST EFFICIENCY (ACWP, ) I (ECWP, )
Figure 2: Cost efficiency (Source: [3])
162
Actual cost (ACWP) is compared to eamed cost (ECWP) of work perfonned. If the cost efficiency
factor (ACWPIECWP) is greater than 1, the contractor perfonns below the perfonnance standard in
the contract. Note that the scheduled cost consumption (ECWS) has no impact on cost performance to
date. However, as eamed cost (ECWP) is a measure of physical progress in tenns of standard costs,
the graph could also be used to assess time performance by comparing ECWP to ECWS. A delay on
time may have an impact on future cost perfonnance as corrective measures to recover the current
delay in figur 2 may attract extra costs.
4. Performance Standards and Consistency
The official investigations of North Sea Projects cost overruns in the 70's explained the gap between
planned and final costs [2]. As we gradually became familiar with this kind of projects, the gap
vanished - projects were completed on time within budgets. The key question is, however, whether the
projects were carried out more efficiently. Studies on this subject indicate that the efficiency level
remained unchanged - what changed was the estimating standard applied ([3],[4],[5]). Gradually we
leamed how to set reasonable standards for North Sea projects. The perfonnance standards were set at
a 50% level of confidence which is equal to the expected final costs as seen at the time of project start
up. I.e. the project team should have an equal opportunity to face an overrun as well as an underrun
situation.
The use of standards for cost estimating has been common in capital cost projects for quite some time.
What the offshore projects added to the general industry practice was the need for a stochastical
analysis of the project costs before a control estimate could be set c set equal to the 50% mark on the
cumulative probability graph for total project costs. It was no longer up to the individual esti~ator or
manager to set a "subjective" cost estimate - tight or loose depending on the actual situation. From
now on control estimates were set equally tight with a 50% chance of being met.
This event produced a quantum leap in consistent perfonnance measurements as well as consistent
forecasting. The basic features of this principle are shown in figure 3.
163
llT---_r---;----r---T---_r--~-----
9i---_+--~~--t_--+_--_+--~-----
6~---+--~----+_--4_--~~~
5+----+--~--~~--~--_r--_i_
T +4
FC-O FC-l FC-2
T
FC-J
T T T
fC-4 FC-5 FC-6
Figure 3: Total cost perfonnance.
MCE-O (Master Control Estimate) represents the original Control Estimate at project start, given at a
50% level of confidence. As the project proceeds, changes to project scope may be agreed between
client and contractor. The agreed changes are incorporated in the updated Control Estimates
represented by MCE- 1, MCE-2 etc. in the diagram. The changes in scope are estimated according to
the estimating nonn agreed in the contract. As work progresses forecasts of fmal project costs
(inclusive of agreed work changes) are made. The forecasts are represented by CCE-1, CCE-2 etc. in
the diagram and represent expected values (for practical purposes equal to 50% level of confidence).
Both the MCE and the CCE rows are made consistently. The corresponding discrepancies MCE-1 -
CCE-1, MCE-2 - CCE-2 etc. represent forecasted total cost underruns as seen at time t1 and t2. By
comparing this to the cost efficiency graphs we see that the difference between MCE-n and CCE-n is
made up of two items, one already achieved cost underrun, IBR (ECWPn - ACWPn) and one
expected for remaining work, PRF.
s. The Ultimate Challenge - Project Controllability
The future is always uncertain. In coping with the future we try to reduce or avoid uncertainty in
different ways. It is useful to distinguish between what may happen and what might happen during
the life time of the project. The "might happen" group of events are not expected to happen.
164
Therefore, there is no need for the client to let contractors worry about such extremes. Extreme
conditions are the responsibility of the client. If such conditions should occur, "exit criteria" should
make the client aware of his need to intervene with the project execution and implement adequate
contingency measures.
The "may happen" group of events is expected to happen and must be considered in the risk analysis
of the project. Current practice is somewhat confusing in this respect. All risk models which I know
assume a static world i.e. the models assume projects progress randomly without paying intention to
the fact that project teams are selected to supervise project work and take corrective measures as
appropriate in order to meet preset objectives. Recognizing the world is dynamic we still model the
world as if it was static.
Let us try to illustrate the consequence of this mismatch. Think of a project consisting only of two
activities - engineering and construction. Assume further the activities are scheduled in sequence and
that we have a probability distribution for duration of each. A risk model works by the principle of a
value lottery, first you draw a duration for engineering, then you draw a duration for construction. The
sum is the duration of the project. If you repeat the lottery a large number of times, you get a large
number of possible duration times for the project. These numbers can be transformed into a
probability distribution for the project duration.
If we have scheduled the duration of engineering and construction to the expected value of each, the
expected duration of the project is simply the sum of the two. If we, however, for some reason require
the project to be finished by a certain date at a given level of confidence, say 70%, we have to
schedule a time buffer to make sure this requirement is fulfilled; see figure 4.
A
I ENGINEERING
I
CONSTRUCTION
Figure 4: Time buffer
165
In real life things turn out to be quite different The project team supervises the engineering
performance. Even if we assume the team cannot interfere with ongoing engineering work, measures
to speed. up construction work will be considered and implemented if required to achieve the project
end date. Several corrective strategies will be considered as overlapping construction and engineering
work, accelerating construction work and so forth. The effect of this is a significant reduction in the
need for a time buffer; see figure 5.
i'!NGINEERING CONSTRUCTION
I!EDUCES
BUFFER
REQUIREMENT
Figure 5: Effects of dynamic scheduling
If we generalize the point just made, we see that buffers can be broken down into two important
components, one which is directly related to the unreduceable uncertainty and one which is related to
the project teams degree of freedom to take corrective measures as appropriate [6]. The former we
cannot do much about, the latter is directly related to the degree of authority we delegate to the project
team. Of course the client can do what he likes, but he must be aware that the degree of authority
delegation has a major impact on project efficiency.
In figure 5 we fixed the level of confidence in meeting the project end date to 70%. From the project
owners' point of view an optimal level of confidence exists. For a venture project where the goal is
profitmaximation under certain constrains, an optimal project duration and an optimal project cost
exist.
As forecasts of total project costs made at different times have different degree of uncertainty, we
need a mechanism to adjust for variances in uncertainty or more precisely project risk (risk =
probability x consequences). One convenient way of doing this is to calculate the certainty
equivalent forecast - the certain value that is equivalent to the uncertain forecast. The certainty
equivalent is a risk adjusted forecast. This principle could be used to set the project budget, the
certain amount of money a client is prepared to pay for an uncertain outcome of a project.
Given the project owners' risk preference, the certainty equivalent project budget can be calculated.
The difference between budget and control estimate (50% level of confidence) is a risk butTer. This
buffer could be applied precisely in the same way as described for the time buffer. We can now
166
calculate certainty equivalent forecasts (CEF-n) of total costs as we progress and make comparisons to
our budget (MCB-n).
The difference is a measure of controllability. If MCB-n/CEF-n is equal to or greater than 1, we are
in control. If, however, the ratio is less than 1, the project objectives are no longer expected to be met.
The project team has no longer the corrective capability required to meet anticipated challenges for
the remaining project duration. There is, however, still some uncertainty present and the lottery of real
life may be favourable to the project team. As a consequence the team has to be lucky to bring the
project home on the stated objectives. We are, however, not equivalently certain to meet our
objectives any more. This is an exit situation which implies it is time for the client to excert
contingency measures.
References
[1] Kharbanda, Stallworthy: How to learn from project disasters.

[2] Cost Study - Norwegian Cpntinental Shelf.
[3] Granli, Hetland and Rolstadl'is: Applied Project Management. Experience from Exploitation
on the Norwegian Continental Shelf, 1986.
[4] Hsulid, J: Effektiv Prosjektstyring, Paper on NPF Conference, 1984.
[5] Hetland, P.W.: What did 20 years of North Sea activities add to our general understanding of
Project Management, Proceedings lNTERNETINORDNET, Rekjarvik 1987.
[6] Hetland, P.W.: Towards Excellence in Project Management, Proceedings of the 10th ICEC
congress, New York 1988.
167
DEVELOPING KNOWLEDGE BASED SYSTEMS IN
CONSTRUCTION MANAGEMENT
Adolf Schub
Abstract
The application of Expert Systems is the most modem tool to help solving problems in decision
making. In the technical-economical area not only numerical problems but logical problems too have
to be solved. This paper is a survey of Expert System Applications in construction management,
taking into consideration the possible combinations of numeric and logic, integrating examples of
programs which are already developed and showing the developing perspectives of an Expert System
for scheduling and controlling.
1. Preliminary Remarks
In the last 30 years the use of computers has been limited to numerical calculations. In construction
management we have applied computers for such areas as cost estimations of the owner, bidding
procedures or cost control of the contractor. Occasionally the calculation of the earliest and latest
dates for a schedule or the optimal transportation for an earth moving project was supported by a
computer.
Though these algorithms are an essential part of the Problem Solving Process and very often of a great
amount of computation, they are only one component of the whole area. The logical part of the
Problem Solving Process has been dealt, without the aid of a computer until now. But by developing
knowledge based systems this gap can be fIlled.
2. Problem Solving Process
In order to solve complex technical problems the methodology of "Systems Engineering" [1] can be
used. It consists of two seperate areas:
Systems designing: the essential, technical and structural engineering task based on determination
of requirements, description of functions, definition of goals, development of alternatives and the
search for the ultimate solution;
Project management: organizational and economical work such as allocation of tasks, dividing in
phases, use of creativity, methods of evaluations and techniques of decision-making.
The Systems Engineering uses certain procedures in system designing and project management, for
example:
techniques for analysis (risk and sensitivity analysis);
techniques for organization (work break down structure);
procedures for optimization (OR-methods);
procedures for prognosis (regression analysis);
methods for evaluation (value analysis).
Neither methodology nor expert knowledge alone solve problems. Only the combination of both
components gives the prerequisite for an efficient problem solution.
3. Tools for Problem Solving
The above mentioned procedures consist predominantly of numerical algorithms. These algorithms
require well defined input data. The algorithms then operate in a certain flow-scheme to find the
solution.
It is necessary to compare always the solutions of different alternatives. Input data must be set up for
each of the corresponding alternatives which is to a large extent the job of the engineer. In the same
way it is the task of the engineer, after running a numerical program, to interpret the results in order to
prepare the necessary decision.
The planning activity which is ahead of the numerical calculation, and the interpretational part which
follows, consists of logical operations worked out by the engineer. Today we are able to submit these
planning and interpreting activities to the computer, using knowledge based systems also known as
Expert Systems.
170
4. Expert Systems
An Expert System is one of the most progressive Problem Solving-tools today. Such a system does
not replace well known procedures, it simply provides an additional logical part to the numerical one
and does not interfere with the creativity of the engineer.
How does an Expert System work?
An Expert System [2] possesses a knowledge base which is comprised of the knowledge of a specific
problem domain of a human expert. This knowledge is represented in rules.
Example for a rule: IF: deviation is greater 10 000 OM,

THEN: undertake a cost analysis.
A conclusion can be drawn out of this rule in a specific case only if the element "deviation" is
evaluated by "X"; that must be known as a fact.
Example for a fact: The deviation X has an amount of 11 000 OM.
With the aid of the inference mechanism the truth of the rule is checked. In the case mentioned above,
the conclusion is recognized as true and a cost analysis has to be undertaken.
If more than one "IF-THEN-relationships" are connected together, the result is a chain or a tree. The
function of the inference mechanism is to search through these trees until the final goal is reached.
Besides the knowledge base and the inference mechanism, an Expert System has a dialogue facility,
an explanation facility and, in most cases, a trace facility which shows the drawn conclusions.
What are the objectives in using an expert system?
The most obvious answer is that we can use such systems for all types of logical operations, in the
same way that check-lists or break-down-structures are used. It is not surprising that therefore the first
Expert Systems were developed in the areas of medicine, geology and law.
But if we want to use Expert Systems in technical domains, we require in most cases a number of
numerical operations besides the pure logical operations for the Problem Solving Process (see section
1). The result of combining logic and numeric while programming creates Hybrid Systems [3]. The
demands here are essentially higher than those for writing pure logical or numerical algorithm.
In the area of planning and constuction [4] the applications of Expert Systems can be set out as
follows:
171
The owner: Decision making for investment,
Organization project,
Acceptance and guarantee;
The planner: Site-inspections,

Choice of structural system,
Technological innovation in construction,
Life-cycle-cost;
The engineer: Tender documents,

Time scheduling and monitoring,
Site supervision,
Site measuring and payment;
The contractor: Bidding procedure,

Choice of construction method,
Site installations,
Quality assurance,
Risk analysis,
Cost control,
Claims and procedures.
5. Classifications and Examples in Construction Management
Now we are able to classify Expert Systems into three basic catagories: Pure logic, pure numeric, and
the combination of logic and numeric.
5.1 Systems with Pure Logic
Procedures which are able to solve logical problems need a qualitative description of the problem.
With this description they can build alternative solutions, then evaluate these by restrictions and
criterias to choose the ultimate solution. The results of these procedures are decision trees, as shown
in figure 1. It is important here to emphasize that only one of the alternative solutions is the correct
and ultimate solution.
172
Qualitative description
Alternative solution
Ultimate solution
Figure 1: Decision tree in a logical procedure
The characteristics of a logical system are:

qualitative description of problems,
a starting tree with chained branches,
absence of numerical parts.
The program VOB (contract conditions) is an example in the field of construction. In the case of
change orders the program investigates whether it is a change in the quantity (§2.3), a change in the
quality (§2.5),or whether it is a new item (§2.6). The aim is to detect one of these three paragraphs.
5.2 Systems with Pure Numeric
Procedures, which solve numerical problems also need a general description. In this case the
description contains data and is quantitative. These data are processed in a algorithm in order to
achieve a result, as shown in figure 2.
General description
Algorithm
Result
Figure 2: Sequence in a numerical Procedure
The characteristics of a numerical system are:

quantative description of the problem,
a calculating sequence without any branches,
absence of logical parts.
173
The calculation part of the program KSP (cost control and monitoring) is an example in the field of
construction. This calculation part evaluates the actual data of all items of a building site and
compares them with the estimation data. Then the program determines reference numbers, which are
required for analysis, monitoring or prognosis. The results here are comparative and reference
numbers.
5.3 Hybrid Systems
IT a problem is described logically as well as numerically, a combination of knowledge- and data

processing will be needed.
The characteristics of a Hybrid System are:

qualitative and quantitative description of problems,
existent of at least one logical and one numerical part.
There are further possible subsystems, as described later dependent on the sequence in which the
numerical and the logical parts are used.
5.3.1 Hybrid System with the Sequence: Logic-Numeric
This particular combination considers the logical part of the problem solving in the frrst step. The
numerical part follows in the second step. Figure 3 shows such procedures, integrating, figures 1
and 2.
Logical part
Numerical part
Figure 3: Combination of Logic and Numeric
174
A typical example of this combination in constuction management is found in the program NT
(change order). The logical part in this program is the program VOB (contract conditions) mentioned
above. The chained program MEMI (deviation in costs) determines the deviation in costs basing on
the estimation numbers as planned. This system can be introduced with a very strong abstraction as
follows.
Example to the logical part:
IF PRODUCfION is described
AND UNIT PRICE is adequate
AND OWNER ordered changes
THEN CLAIM for additional reinbursement (§2.5).
In this rule, the "IF-AND-conditions" describe the qualitative situation, while the "THEN-relation"
shows the conclusion (in this case the claimed reinbursement according to §2.5), supposing that all
conditions are accomplished.
Example of the numerical analyses:
ESTIMATION CHANGEORDER
QUANTITY 1.000 m 3 1.000 m 3
PRODUCTIVITY 0,8 Lh/m3 1,0 Lh/m3
WAGE 40,00DM/Lh 40,00DM/Lh
UNIT PRICE CH.ORD. 1,0 Lh x 40,00 DM/Lh 40,ooDM/m3

UNIT PRICE ESTIM. 0,8 Lh x 40,00 DM/Lh 32,OODM/m3
ADDmONAL PRICE 8,OODM/m3
The figures of the estimation and the change order describe the qualitative situation in data form,
while the calculation result is established within the use of formulas (in this case the difference
between the unit prices as additional price, according to §2.5).
The Expert System NT was developed in the Expert System Shell INSIGHT2+. The logical
knowledge was obtained from the VOB-experts Dr. Hofmann and Mr. Frikell. The numerical
procedures were developed in our department. This system will be used mainly for teaching purposes,
but with the help of the construction industry it will be extended to also cover practical application.
175
5.3.2 Hybrid System with the Sequence: Numeric.Logic
With this combination a problem can be analyzed and evaluated after a pure quantitative solution.
This leads to a formation as shown in figure 4.
Numerical part
Logical part
Figure 4: Combination: Numeric-Logic
The system KSP (cost control and monitoring) represents an example from the area of constuction
management. The comparative- and reference numbers of this system were mentioned in section 4.2.
Herein after some details of the numerical and logical part of the second control of the item
"formwork" will be shown later.
Numerical part:
Data as planned actual

QUANTITY 30.000m2 8.500m2
DURATION 130d 45d
AMOUNT OF WORK 24.000Lh 6.260Lh
Calculation as planned actual

PROGRESS = 30.000/130 231 m2/d
=8.500/45 189 rd-/d
DURATION = 8.500/231 37d
WORKER = 24.000/13Ox8 23L

= 6.260/45x8 17L
176
PRODUCfIVITY =24.000/30.000 = 0,80Lh/m2
=6.200/ 8.500 = 0,74Lh/m2
Reference numbers
PROO = 189/231 0,82
WORK = 17/23 = 0,74
PROD = 0,74/0,80 = 0,93
Lop part:
Assessment of the actual progress rate

IF PROO < 1
AND WORK < 1
AND PROD < 1
AND WORK < PROD
THEN the reason for the lower actual progress rate is the shortage of worker.
Of course other conclusions would be reached in the logical part, if any of the reference numbers was
greater then 1. This means that there has to be a corresponding rule in the program for each admissible
restriction.
The calculation part of the expert system KSP was developed in FORTRAN, while the analysis part
was written in FORTRAN as well as in PROLOG.
The advantage of PROLOG is that less work is required, considering programming the analysis part,
because of the aid of the inference mechanism. The basis of this program is derived from professor
Dr. Burkhard, the founder of the Munich Construction Management department. Since 1980 the
program has been used for controling several sites with success.
5.3.3 Hybrid System with. the Sequence: Logic-Numeric-Logic
Other combinations of logic and numeric are possible. Two examples, which have a hybrid character
are shown in figure 5.
177
Logical part 1
Numerical part
Logical part 2
Figure 5: Combination: Logic-Numeric-Logic
The fIrst example is the expert system TERKON (schedule control) where only a simple section out of
the complex system is presented.
Lo&ical Part 1 Project Analysis
IF PROJECf has changed

AND CONTRACTOR is delayed
OR SHOP DRAWINGS are missing
OR WEATIffiR CONDITIONS are bad
OR LAST CONTROL> 1 month
TIffiN execute SCHEDULE CONTROL
Numerical Part
Data Schedule Control
TOTAL FLOAT -lOd

DURATION as planned 80 d
REMAINING DURATION = 55 d
ACCEPTANCE for delay 3%
178
Calculation Reference numbers
FLOAT 10/55 = 0,18

COMPL = (80-55)/80 0,31
ACCEP = 0,Q3
Loeical Part 2
IF COMPL < 0,80

AND FLOAT > ACCEP
THEN MODIFICATION possible
The expert system TERKON has been developed as a prototype with the support of the late Dr.
Meyran over the last 4 years. The logical part 2 was written in PROLOG first of all; later all the three
parts were connected to a whole system in the shell INSIGHT 2+. This system can only be effective if
it is extended through an analytical and a monitoring part
The second example of a Hybrid System with the combination logic-numeric-Iogic is the expert
system DAM [5]. This is the flrst knowledge based system which has been developed on the basis of a
hierarchical stucture. Figure 6 shows the important elements of the system structure which is to be
used to prepare the construction planning for a dam project. Though the system has been theoretically
approved there has been no practical assignment to date.
Knowledge Base 1 Knowledge Base 5

1. Om off dam materials, excava- 1. Rules for combining the results
tion and transportation. of tasks to uniform the Investi-
gated and economical units.
2. Cost estimation and choice of
locations for excavation. 2. Problem solution of an effective
construction method.
3. Rules for echedullng of opera-
tions and deffnition of tasks.
Knowledge Base 2 Knowledge Base 3 Knowledge Base 4

1. Rules for consideration of equip- 1. Rules for possible combinations 1. Rules for preparation of data for
ment of machinery in general. detailed calculation of final cost
estimation and progress rates.
2. Rules for minimum requirements 2. Rules for possible combination
of necessary equipment of machinery in a specific case. 2. Special programm for detailed
calculation.
3. Estimated capacity for machinery.
3. Investigation for the required
equipment
Figure 6: Structure of the system for Constuction of Dam Projects
179
6. Summary and Outlook
The system which has been described is a demonstration of the possibility of Problem Solving totally
with the aid of an Expert System, instead of handling each part in isolation. The data and information
transfer to find the ultimate solution is a part of the Hybrid System and it is no longer necessary to
have other programs to organize this transfer or to manipulate the input manually.
Based on these facts, research assistants at this department are currently developing an universal
planning and control system for scheduling and resource allocation. The theoretical and practical
ideas and the necessary steps will be shown here.
As for any scheduling program needed, the building project has to be described with drawings (e.g. in
CAD). Using these drawings, essential activities are to be defined and the qualitative attributes and
the quantitative amount of production have to be determined. Using production functions and
considering approved and reasonable figures of recourses, realistic durations can be calculated
through numerical procedures. Simple logic is to be considered again if the relations between the
activities have to be laid down. Finally, time distances have to be determined, by the restrictions of
technology, organization and other conditions.
These steps, which until today have been the task of the scheduler, have led to the whole structure of
the activity flow. The calculation of the activity dates in the next part of the system is the numerical
part where a lot of algorithms and programs have already been developed. If the numerical result is
present, the terminated schedule has to be analyzed, not only concerning the target data, but also
concerning the required recourses. Therefore research concerning realistic project duration and
possible equipment for personell and machinery on site, still has to be carried out. With this
knowledge, continuous modifications in the schedule in order to fullfil the required restrictions would
be possible. Otherwise the conclusion could be drawn that the fixed data does not meet the
requirements.
With this planning system the actual datas as well as the actual reference numbers (e.g.total floats)
can be compared with the datas and reference numbers as planned in the monitoring system. The
system then offers modifications "as planned new" by comparing the deviations. The knowledge of
how to develop a realistic schedule and how to organize an informative monitoring report is at hand
and provided by experts.
180
References
[1] Daenzer, W.F.: Systems Engineering, ZUrich 1982/83.

[2] Schnupp, P., Leibrand, U.: Expertensysteme; Berlin Heidelberg New York Tokio 1986.
[3] Allen, R.H., et al.: Using Hybrid Expert System Approaches for Engineering Applications. In:
Engineering with Computers, Vol.2, New York 1987.
[4] Adeli, H.: Expert System in Construction and Structural Engineering, London, New York 1988.
[5] Madlaji EI, M.: Rechnergestiitzte Produktionsplanung im Baubetrieb, Heft 3 der Schriftenreihe
des Lehrstuhls flir Tunnelbau und Baubetriebslehre, TU Miinchen, 1989.
181
SPONTANEITY OR PLANNING DEFICITS IN SYSTEMS
SELECTION AND APPLICATION OF PROJECT SOFTWARE
Sebastian Dworatscbek
1. Introduction
Many project groups in industry and administration are confronted with the question how Infonnation
technologies are to be selected, introduced, and applied. Between spontaneous decision and
systematic planning, a wide range of habits can be found among the persons involved. The relation
between spontaneous users in the special departments and the planning expert who mainly is in a
central position, often turns out to be very complicated. Before a final recommendation for a certain
system can be given after thorough analysis, the user, fond of experimenting, has already begun to test
'his' system.
The following examples shall represent the basic pattern of such a decision-making situation. In a
large-scale research organization, the decentralized project groups have access to the host computer
via terminal. Now, personal computers (PCs) are to be procured to increase the capacity. The head of
the computer centre orders a cost-benefit analysis of two dozens of PC models which takes a lot of
time. In the course of this procedure, some of these models even become unavailable on today's fast-
changing PC market. In the meantime, two project groups make use of remaining funds of the
investment budget to procure the first personal computers at short notice. First, the groups test the
computers of their choice, and then these computers are permanently applied to research projec~s and
secretariat work. Mter a relatively short period, these groups assume a consulting role with respect to
PC equipment - practically in place of the head of the computer centre supporting the project groups
in other departments.
As a subcontractor, a medium-sized, order-oriented company supplies high-technology components
for the shipbuilding industry. For many years, software has heen applied in the accounting
department. In regard to a current project, a consultant convincingly presents the advantages of PC
support by means of two network planning packages. However, methodical system introduction can
only be initiated three years after this pilot application.
In a camera-manufacturing plant, the development engineers are not convinced of the benefit derived
from project software. The head of the development department spontaneously procures some copies
of a network: planning package with a highly graphics-oriented user interface in order to meet with
broad acceptance. Parallel to the continuous application of the network planning packages, the
demand for software performance is steadily increasing. After a thorough requirements analysis, the
"throw-away" package is replaced by more efficient project software.
Does spontaneity represent only a planning deficit or a necessary complement to planning
methodology? This question arises, if
hardware and software are to be selected for special departments or project groups, and
systems are to be practically applied by project teams.
The following is intended to present the overall situation rather than to give a final answer to the
problem of implementation of information technology. For this purpose, the general application
situation will first be outlined and then the question about the .dualism between spontaneity and
planning will be considered with respect to the implementation of systems. Exemplarily mentioned
symptoms are intended to illustrate this dualism in particular decision-making situations. These
symptoms refer to a number of factors which influence or even determine the behaviour of users of
information technology whether to decide spontaneously or after thorough planning and analysis.
Literature and practical experience together offer a wide variety of strategies by means of which the
implementation of information technology is to be facilitated. These different strategies offered
contain both: elements of spontaneous problem solution and elements of systematic planning.
2. Application ofInformation Technology
In the past two decades, information has been developing to an increasingly independent production
factor. This means that information is a complement to the auxiliary factors material, energy, and
financial resources, supporting 'man' as the primary factor. In the past, information was only
considered to be an integral part of the human factor. Today, however, it is increasingly separated and
materialized, and thus "dehumanized" in a certain sense. This process is accompanied by problems
with respect to changes in information technology, examined within the scope of impact research
(Dworatschek 1989, pp. 452). As a counterbalance, different approaches are made, including
consideration of interactive computer application, software ergonomics, task integration, holistic
thinking, organization development, and participation of the persons concerned.
For communication in industry and administration, the production factor information is used in such
forms as data, text, image (graphics, video), and language. The processing functions applied to these
forms of information are always the same: gathering, storage, processing, output, and transfer.
In order to reduce the complexity of the technological change, history is often classified according to
different stages of development. In the field of data processing, technological milestones similarly led
184
to great qualitative advances (Dworatschek 1989,pp. 21-23, Reinermann 1989). Manual data
processing, which is a very spontaneous process, has for centuries been supported by mobile
mechanical (calculating) equipment. After 1890, the electro-mechanical Hollerith machines produced
a considerable rationalization effect. This conventional punched-card technology required systematic
preparation and an immobile form of data processing. In the beginning, the data processing units were
located in the user environment, e.g. in the accounting department (invoicing), later, data processing
was centralized.
Beginning in the 50's, the development of electronic data processing (EDP) led to the implementation
of computer centres with a steadily increasing performance capacity. These computer centres dealt
with the distributed departments as more or less dependent customers. Furthermore, the centre also
advised and supported the different company sectors in performing information demand and task
analyses. Spontaneous and impatient requests for information did not always comply with the experts
of DP planning and often led to misunderstanding and tension.
With the stage of 'distributed data processing' a decentralizing countermovement was initiated. This
particular form of data processing comprises the application of time-sharing terminals, individual data
processing (IDP) and the actual distributed data processing (DDP). Today, experts predict and expect
a stage of networked, digital telecommunications. This stage will probably involve a dualism between
central communication computers with special data banks in the background and multifunctional,
intelligent terminals. Then, the user may still make his 'spontaneous' choice between controlled user
mode and offline operation.
With respect to these stages of DP development, two utopian models have to be mentioned. About
1970, the so-called 'Total MIS' was expected to offer outstanding advantages; these management
information systems mainly based on decision-optimizing models (operations research). The 'only'
systems to be achievable, however, included special information systems, such as persl:mnel,
marketing, or project information systems. Accomplishment of MIS planning miscarried because of
various secondary conditions and particularly on account of the communication behaviour of the
management executives.
In the beginning of the 80' s, the concept of autonomous microcomputer users was developed. What
did the user determine autonomously? His tasks, data, schedules, or DP techniques? Probably, this
utopia will also be doomed to failure for practical reasons. Autonomy is limited in various ways.
There are only some insular tasks. Even project groups depend on data provided by other departments.
Flexible w?rking times are also subject to the absolute demand for meeting the schedule. Life cycles
of information technology products are steadily decreasing so that a transition to higher levels of
automation always seems increasingly necessary. At hybrid workstations, the user also 'discloses' his
knowledge to the DP system which finally takes his place. The decreasing half-time of DP know-how
leads to an increasing advantage of know-how of the central experts over the distributed users. In turn,
without special DP know-how, no DP expert will be able to develop a software concept that is close to
practice - thus, prototyping will not be possible.
185
Under the particular practical conditions, sevenil types of user organization should probably develop,
rendering the users more or less partially autonomous. In general, user organization can rely on four
groups of information technologies the functions of which are increasingly overlapping and being
integrated:
Computers (jumbo, universal, mini, super PC, PC)
Office automation systems (word processing systems, video display terminals)
Telecommunications (telex, teletex, telefax, videotex, LAN)
Information technologies combined with production technologies (CNC, robots, process plant
periphery, production data acquisition, CIM) as well as the corresponding software.
On account of the variety of systems offered, the margin for spontaneous configuration of
experiments is steadily expanding. On the other hand, short life cycles and special market
characteristics such as companyspecific and industrial standards, lead to a certain technological
dominance with respect to user organization concepts. Does strategic DP planning - most recently
known as 'information management' - offer security in the environment of changing DP markets?
3. Spontaneity and Planning
In practice, the dualism between spontaneity and planned action concerns all decision-making
processes in a company. This is particularly applicable to projects for the introduction of information
technologies. Spontaneity is mainly based on an urgent demand, intended to directly or
experimentally achieve specific, partially contradictory objectives derived from this demand. It is
characterized by the willingness to act at short notice and without comprehensive information
acquisition. Potential influencing factors are not systematically anticipated and evaluated. The people
involved rely on the success of creative ideas and want direct results. New situations and innovations
are a motivation for spontaneously acting persons. They meet with risks and a certain lack of
orientation, but they also experience resounding success.
After a visit to a systems company, the management board spontaneously decides on the introduction
of project software. Within two months a small project group has to submit a proposal which is ready
for judgment.
On the other hand: Together with an external consultant, the owner of a small systems consulting
company thoroughly prepares the selection, adaptation and implementation of software-supported
project controlling system for schedule, capacity, and liquidity planning. This systematic procedure in
the currently sound economic situation is intended to provide anti-cyclically for the future of the
company.
In a planning process, possible future situations, activities, disturbances, and their consequences will
theoretically be anticipated, analyzed, and simulated. Systematic information acquisition is followed
186
by appropriate assessment making use of theories. models, and calculations. A person acting
according to this scheme soon requires certain rules, safety and guidance, and the demand for systems
control and risk limitation arises. In this respect, three different forms of planning can be
recommended:
Objective planning (e.g. task criticism, management by objectives, project definition, performance
specifications)
Alternative planning (e.g. cost-benefit analysis with respect to PC selection, comparison of
different configurations)
Process planning (e.g. network plans for PC installation, training, curricula, programme schedules
for task description).
Practice shows that these planning phases cannot be perfectly adhered to like clearly defined
interfaces. For example, only by working on the proposals for computer or software alternatives
systems purchasers often acquire the know-how required to subsequently operationalize the demand
objectives. In the course of this process, they make several spontaneous assumptions and various
intermediate decisions. Furthermore, the distributed DP user is definitely capable of adequately
equipping his workplace with DP support that absolutely meets his demand, before the overall
organization has developed a specific implementation strategy. Here, spontaneity and planning are
complementary.
With respect to computer application, the preference and estimation for one of the two contradictory
forms of behaviour depends on a large number of personal and company-specific factors. Spontaneity
of one project team member is perhaps considered by other members as a venturesome planning
deficit. On the other hand, extensive planning can also be regarded as a sacrifice of creative
spontaneity. Being fond of experimenting, the head of the organization department of a region~ plant
within a large company group, together with the head of a special department and an external
consultant, intends to test a department secretariat model on the basis of personal computers
connected via LAN. In the headquarters of the group, the head of the department for office
communications considers this plan to be too daring since two-year planning has not yet led to a
proposal for the implementation of a uniform model as company standard.
4. Symptoms of Spontaneity and Planning
In company practice, various symptoms and comments on different parameters identify the degree of
planning with respect to system implementation. Typical parameters to be taken into consideration
comprise (see table at the end of the article):
Tasks, hardware, software, organization, personnel, learning process, information, data protection,
forms of presentation
187
What is intended with the rather spontaneous application of computer support to the performance of
business-economic tasks? Comprehensive enrichment of activities is expected or will be achievable:
Horizontal enrichment of activities: "to do more within one process"
Vertical enrichment of activities: "to test new tasks"
Social enrichment of activities: "to cooperate with new partners".
If work is performed in such spontaneous way, planning deficits with respect to these activities can
also be recognized. Some executives fear that the tasks of their departments cannot be performed
comprehensively on account of the existence of several project groups. Tasks and responsibilities
perhaps become 'undefined quantities'. This, in turn, could undermine the official authority of the
company management.
A more spontaneous evaluator will select hardware by testing and applying the systems. This
purchaser behaviour is based on the experience that real compatibility can almost never be achieved,
and particularly not for a long time. This behaviour could also be led by the desire to be released from
the dependence on market-leader dominance. As a contrast, hardware selection after thorough
planning is intended to achieve a synoptic comparison of the systems. It is led by the conviction that
compatibility can be planned and thus ensured. Action is determined by the worry about possibly
uncontrollable mixed hardware.
With respect to software procurement, the possible behaviours span a similar spectrum from the desire
for individually adapted versions for test purposes to the systematic planning approach to maintenance
and documentation problems. For two years, a central planning group 'methods' has explored and
assessed network planning software for uniform project support in the different plants within a large
industrial company. In the meantime, the rapidly improving cost-to-performance ratio of new network
planning software packages on PC basis offers solutions of very high efficiency. After a PC
demonstration, the head of the organization department of a plant spontaneously purchases two
different low-priced packages - from residual and reallocated budget items. Faced with the reference
to'the standardization planning, he replies: "My team members now have to acquire competence. The
low price offers the possibility of replacing the software later on, if required!"
Different forms of organization can he distinguished according to the density of regulation they are
subjected to (KieserlKubitschek 1983). Legal obligations to governmental authorities, employees,
trade unions, customers, clients, and suppliers considerably abridge the freedom to act spontaneously.
On account of modifications with respect to information technology, new tasks for the personnel
department will arise. Spontaneous promotion of individual employees is opposed to organized
personnel development. With the latter form of behaviour, the entire organization, and not only some
individuals - the so-called computer freaks - can benefit from the systematic personnel development.
On the one hand, the learning process can spontaneously be accomplished by practical work with
colleague support. On the other hand, curricular preparation by specially skilled DP trainers offers
itself.
188
Spontaneous handling of project infonnation provides the experience that infonnation can
individually be acquired and adapted to the respective requirements. To the same extent. however, the
experience is gained that the acquisition of infonnation incurs rather great expenses. By systematic
handling of this production factor technically optimum provision of infonnation is ensured, cost
transparence provided, and repeated data acquisition and storage avoided.
The field of tension between creative, almost uncontrollable computer application and comprehensive
regulation, including restricted access rights, becomes especially clear when data protection is
concerned.
Personal computers are accepted and approved by the users mainly because of the possibility of
flexibly designing result presentation. Spontaneous "If ... , then ... " decisions, short response time, and
simple visualization perfectly complement each other. In this connection, workplace software (word
processing, spread sheet calculation, and presentation graphics) is absolutely characteristic. As a
contrast, systematic preparation of professionally designed computer reports could he achieved by
thorough planning. In a large-scale research organization, the high-level executives of one research
division were discontented with the sumptuously prepared quarterly budget report, since, in their
opinion, they did not obtain the appropriate control information for the different projects. Within a
very short period, an external consultant applied an integrated PC workplace package to develop a
three-dimensional budget simulation model to comply with specific project requirements. Periodic
data exchange with the host computer is now performed via floppy disks; in a later phase, the stand-
alone mode is to be converted into online mode.
5. Factors of User Behaviour
The exemplarily mentioned symptoms already show that certain factors of user behaviour exert an
influence on the spectrum between spontaneity and intensive planning. In addition to the already cited
parameters, further factors will be mentioned:
Technological dominance
Form of innovation
Type of software
Centralization of organization
Objectives/reasons for conversion
Personnel (structure).
The influencing factor 'technological dominance' has already been described. The form of innovation
is also a decisive factor. In many respects, information technologies (IT) signify innovation. They
have to be classified as objective innovations, if they represent new technical solutions (technological
innovations) or if an already introduced information technology can he used for new functions
189
(functional innovations). Technological innovations on the IT market mther correspond to a supply
market with a product policy which to a large extent is planned by the manufacturers. Functional
innovations, however, refer more to the actual demand, e.g. new modules for project software. If IT
systems which have already been on the market for a certain time are opemted in a special workplace
for the first time, this change represents a subjective innovation for the user. This particular learning
situation of the user has to be taken into consideration by the DP organizer. Planning intensity will
also depend on the question whether a new IT, e.g. the microprocessor which came up in 1971, has a
multiplicative effect as a basic innovation, or only leads to improvement innovations.
Objectives and reasons which are significant for IT equipment also affect the degree of planning
intensity:
Fondness of experimenting up to a playing urge (e.g. computer graphics)
Discontent about type, volume, and form of information supply (e.g. by centml project software)
Pressure for mtionalization due to calculations of profitability (e.g. contractual demand established
by the project customer)
Systems standardization in organizational units (e.g. with respect to PC, minicomputer, and host
software).
According to the following list of different types of project software system selection is dominated by
the demand for planning rather than by the chance for spontaneity:
Teachware
(interactive software used for teaching special project topics)
Workplace software
(e.g. project reporting by means of graphics software)
Data bank dialog software
(e.g. for configuration/documentation management)
Network planning software
(according to requirements specification)
Functional project software
(e.g. self-programmed cost control software)
Telecommunications software
(e.g. LAN for project teams).
Practice and science work with different organizational models (Kieser/Kubicek 1983, pp. 132).
Hierarchical models have a rather centml structure. Other models permit spontaneous action and
support project groups or task forces. Basing on the distribution of competence between computer
centre and distributed special departments with respect to the implementation of personal computers,
a centralization indicator can he determined (Dworatschek et al. 1989, pp. 48.). It is understandable
190
that a high regulation density concerning data protection and security demonstrates a tendency
towards a limitation of user spontaneity when handling DP equipment.
Application tests on a cost-benefit analysis model with centralization factors provided the following
result: "A completely centralized design of the infrastructure of the information functions can meet
the requirements only in extremely rare cases. Installation of partially autonomous, decentralized
system components.is indispensable... The task of a computer centre is developing from pure
processing to planning, designing, and coordinating." (Heinrich 1986, p. 20).
A factor which is especially decisive for the user behaviour is certainly represented by the personnel
structure of an organization. Within the scope of an empirical research study, 107 medium-level
executives of four large-scale organizations were questioned about the factors of influence on
innovative events (Kasper 1986, p. 118). The results essentially showed three types of contradictions
and conflict areas:
"Convention versus experiment"
(tradition vs. innovation)
Generation conflict
("old" vs. "young" organization members)
"Double-bind"-like situations
The higher the degree of standardization is in their own areas, the more impulses for innovative
activities are conveyed to the medium-level managers by their superior executives; the actual working
situation, however, provides less impulses. If these managers, in contrast, are confronted with
unexpected problems, they can carry more of their own innovation proposals into effect. This is
generally applicable to projects. With respect to the generation conflict, this study provides the
following result: "With increasing age, less innovation proposals are made. Older employees have to
experience more considerable resistance to innovation put up by immediate superiors, management,
the department concerned, departments not concerned by the innovation, and by the works council."
(Kasper 1986, p. 119).
The study also shows that "with an increasing (decision) decentralization, the medium-level managers
interviewed submit less innovation proposals." This unexpected result is probably due to the double-
bind blockade. Such situations include:
The superior reminds the employee:
"Be innovative, but adhere to the regulations!"
The DP manager requests the 'autonomous' user:
"Use the PC creatively, but remain compatible to the central system!"
The DP experts demand from the project team members:
"Define your information requirements by now, but remember that they have to be DP-specific!"
191
An interview of 3300 management board members and directors significantly showed that acceptance
of DP and office communication technology considerably decreases with increasing age. More than
40% of the persons interviewed mentioned a relief from routine work, and only 5% considers DP
application to provide a higher degree of systemization of the decision-making process (Streicher,
1984).
One of the reasons for the executives' continuing resistance to direct communication with the personal
computer is the fear of the computer. The executives also refused keyboard-oriented work, since it
was considered as a 'subordinate' activity not complying with the conceptions of their own status.
Application of mouse technology and touch-screen, as well as voice input/output, should remove such
obstructions and permit spontaneous PC inquiry. Project managers normally employ personal
information assistants for spontaneous PC inquiries and individually designed evaluations.
Up to now, one question has heen treated unsufficientIy: To what extent management executives at all
exhibit rational decision-making and problem-solution behaviour? Can analytical and partial
computer data really support and influence the intuitive-holistic thinking of management executives?
And finally: To what degree spontaneous or improvising action, already practised for many years, is
regarded to be supported or obstructed by computer-assisted model calculations? "Schumpeter's
entrepreneur can neither be rationalized by scientific company control, nor replaced by special
support programmes. ... The solution of innovative problems can not be achieved by means of
algorithms and thus cannot be transferred" (Staudt 1985, p. 77). The assumption of almost unlimited
planning and information requirements of executives and skilled employees had to be modified.
Significance of project management software is overestimated (49% approval among 649 project
managers), personal discussions and impressions are preferably applied to project status assessment
(79%; Dworatschek 1988).
Rather than the command over technological communications equipment, such as keyboards,
management executives have to develop the ability to determine, critically assess, and exactly define
their own, as well as their employees' demand for information (Dworatschek 1981, p. 276).
Professional socialization often determines the type and form of the expected computer data output:
Mathematicians prefer formulas, whereas engineers rely on diagrams and commercial clerks on data
lists; system analysts think according to flow charts, lawyers appreciate linear text, and many other
people can apprehend and assess complex information only in form of graphics. The large variety of
workplace software offers enough freedom for spontaneous evaluation and individual design.
The concrete user behaviour of management executives, as well as their own conception of their role,
is characterized by the high expectations placed in them by various persons, including top
management, team members, works council, inhouse system experts and external consultants, system
manufacturers, clients, and customers. With respect to information technology projects, the manager
can thus assume the role of a promoter, opponent, client, expert, or change agent.
192
6. Project.like Implementation Strategies
Practice and literature offer a wide variety of strategical recommendations for the implementation of
computer-assisted user systems. In general, a balance between spontaneity of the user and planning by
mainly central expert authorities is intended. Additionally, replacement of traditional organization
work by innovative modification of organization is often recommended. The traditional organization
has maInly been characterized by the following three features:
Empirically almost unproved organization principles, e.g. the principle of a certain control period;
Work studies, mainly concerning workplaces with comprehensive technical equipment (Work
Study Association), applied to office work practice without being adapted or, partially, even
without any reflection;
Mainly instructive organization structure, e.g. preplanned organization solutions implemented via
organizational instruction.
On the one hand, future organization work implies new demands on organization experts, but on the
other hand, it also offers a series of different methods:
High innovation rates due to which the principle of durability of organizational regulations is
impeached;
Considerably more process-specific organization rather than structural organization;
Increasing problems of acceptance and requirements for participative organization developments;
Codified, company-politically intended, or actual participation of works councils;
More argumentative instead of instructive organization work;
Less model reassessment, more organizational fantasy.
Among the manifold strategical recommendations, some proposals will exemplarily be mentioned.
Multi-department DP project organization today is already applied rather often (DebusmannNoigt
1985, AbeVGroth 1984, Lohner 1984). Conversion tasks, schedules, budgets, as well as personnel and
computer capacity, are systematically planned (e.g. by application of network planning), gathered, and
progress-specifically monitored. More-over, they offer organizational freedom to include participant
creativity. In this connection, phase models for software development allow interest group
participation of varying intensity, corresponding to the respective project phase. Related strategies for
IT implementation comprise:
Pilot projects (Allerbeck 1985)
Prototyping
Group-oriented approaches (Heeg 1986)
Organization development projects (Debusmann et al. 1989).
193
According to several empirical studies, worlc:s councils can adhere to a strategy which combines
institutionalized joint management with forms of direct participation at the workplace or in project
groups (Monsees 1986, pp. 479). The latter provides the possibility of personally, immediately, and
spontaneously influencing the process of information technology implementation. The former places
emphasis on the less complicated'participation in the decision-making process after submission of the
planning results.
An empirical study which can already be considered as a classical study on the type of procurement
projects (Witte 1973) analyses the user behaviour towards the offering computer manufacturers and
distributors. The promoter model developed in this study recommends to combine a 'technical
promoter' with an 'authority promoter'. For example, a project manager with comprehensive authority
today is capable of performing informationtechnological experiments in his own project area only
together with a technologically skilled assistant (business data processing expert) and without the
suppon of the computer centre. On the other hand, supponed by a member of the executive board, the
technically responsible head of the computer centre can develop and enforce a project planning for
medium-term user organization with respect to new information technologies.
In this process, external consultants play a kind of 'catalyst' role. As change agents within an
organization development or as innovation consultants, they are supporting the companies by
transferring scientific knowledge into practice. A large savings bank: has established a little 'consultant
pool'. The special departments require these consultants to suppon the implementation of PC
workplace software for a limited period of time. Comparable project service departments have been
established in several enterprises.
A similar strategy is recommended within the scope of an extended model of distributed DP officers.
These officers regard themselves as direct contact partners for the computer centre. They provide it
with all necessary information with respect to requests or acceptance problems occurring in the
application areas. Within the different divisions they act as 'internal transfer' consultants for
innovations in the field of information technology. In a manufacturing plant of a large-scale
enterprise, the number of DP officers rose from 15 to 40 between 1979 and 1985. Simultaneously, the
number of individual data processing (IDP) users advanced from 40 to 200 (Dworatschek 1989,
p.450).
The idea of personal computing is conceptually similar to the strategy described above. It is intended
to provide all divisions with hardware and software equipment - either in the form of terminals or as
offline Pes.
In the past, 'data cemeteries" grew on account of the systematic central DP-repon supply. Today,
however, also the spontaneous PC user in the project group soon loses orientation in a self-created
chaos - his "electronic collection of notes and jotting slips" at the workplace. An interesting
counterbalance to the flood of information was provided by the American Federal Government with
the Paperwork Reduction Act enforced in 1980. According to this act, every government authority
must appoint one IRM (Information Resource Management) officer.
194
"Information management signifies the management of the value added process of information
gathering, processing, and distribution as an integrated and plannable process for which control is
required and which is controllable. Information management deals with the phenomenon 'information'
as a time-critical, costly and profitable production factor." (Klaus/Otten 1985, pp. 133, also
Reinermann 1986). In brief: Information resource management is urgently required. Product life cycle
management usually applied in project management can definitely contribute to the solution of this
problem. From initiation to elimination, all life cycle phases should be examined cost-effectively not
only with respect to hardware but also concerning user software. Even comprehensive reports,
generated with computer support, are intended to be examined according to this procedure. This
would offer the possibility of economically balancing central standard reports against spontaneous
information procurement at the workplace.
Experience gained with already implemented information technologies shows that acceptance and
efficiency of technological application also depends on training. To the same extent, spontaneously
initiated and systematically curricular training processes both require time, and this demand for time
is often underestimated.
On account of the short half-time of information-technological innovations, it seems not to be
significant to take up spontaneously and implement every new IT-product offer. On the other hand,
however, more than two decades of user experience with computer systems show that total risk
planning can also lead to a loss of know-how and to a certain paralyzation. Organizations cannot
reject all application experiments and try to avoid the mistakes of other institutions only by adhering
to a delayed schedule. In order to accomplish computer application, innovation has to be combined
with configuration concepts, creativity with a limitation of risks.
Deficits in spontaneity caused by extensive planning can not represent the answer to the challenges
of computer application. In practice, project management is characterized by planning metho~ology
and spontaneous modification management.
SYMPTOMS AND CONFIGURATION PARAME1ERS CONCERNING

SPONTANEITY PLANNING (DEFICIT)
TASKS
- To do more within one process - No more large-scale task performance

(horiziontal enrichment of activities)
- To test new tasks - Organizational authority of the company
(vertical enrichment of activities) management is undermined
- To cooperate with new partners - Tasks and responsibilities
(social enrichment of activities) become 'undefined quantities'
195
HARDWARE
- Test and trial assessment - Systematic comparison prior to selection

(cost-benefit analysis)
- Experience: "Nothing is really compatible" - Compatibility is plannable and has to be
ensured
- Release from dependence on a market leader - Uncontrollable mixed hardware
SOFTWARE
- Selecting by experimenting with - Excessive tool costs for unskilled DP users
the offered software items
- Individual adaptation/configuration - "Who assumes servicing and
documentation?"
- Rapid evaluations - Gaming increases, no comparability
(if ... then ...)
ORGANIZATION
- Almost unregulated working conditions - High regulation density, e.g. because

of legal obligations
- Flexible project organization - Customer/supplier relation
PERSONNEL
- DP-interested personnel are promoted - Project management acting

as an interim executive
- Individuals learn - Organization 'learns'
LEARNING PROCESS
- Learning by doing - Theory and practice

- Learning from colleagues - Learning from a didact
- Demand-oriented learning - Preparatory training
196
INFORMATION as a PRODUCTION FACfOR
- Individually procurable - Technically optimum acquisition

- Experience: Information - DP cost transparency
procurement is expensive
- Acquisition during the work - Repeated acquisition!
storage can be avoided
DATA PROTECTION/SECURITY
- "Almost no personal data - Preliminary definition and centralization

to be handled on PC" of personal data to ensure transparency
and access rights
- "Saving everything impedes - Project documentation is unpopular
productivity and the
"joy in the copying chaos"
PRESENTATIONS
- 'If ... , then .. .'-simulations - The demand for information can

preliminarily be defined
- Short response times concerning - Determination of computer
requests of superiors performance profile/requirements
- Flexible visualization - Highly standardized output quality
Table: Symptoms of spontaneity or planning (deficits) in computer application (Source: Dworatschek

1990)
197
References
Abel, R.D., Groth, K.: Durchftihrung einer Organisationsuntersuchung mit internen und externen
Organisatoren [Perfonnance of an organization analysis with internal and external organizers], in:
VOP 1984/4/pp. 136-140.
Allerbeck, M.: Pilotprojekte in der Biirokommunikation [Pilot project in office communication], in:
zfo 1985/3/pp. 182-185.
Debusmann, E., Voigt, B.: Projektmanagement-Fallstudie zur Einflihrung von Biiro-Servicegruppen
[Project management case study for the implementation of office service groups]. In:
Projektmanagement, GPM-Jahrestagung 1985, MUnchen 1985.
Debusmann, E., et al: DV-gestUtzte Sachbearbeitung in BUro und Verwaltung [DP-assisted business
in office and administration], Ktiln 1989.
Dworatschek, S.: Problemfelder. von FUhrungskriiften und aktuelle Anforderungen [Areas of
management-specific problems and current demands]. In: VOP 1981/S/pp. 272-276.
Dworatschek, S.: Thesen zur Situation und zur Entwicklung im Projektmanagement [Theses on
situation and development in project management]. In: GPM-N 1988/15/pp. 42-47.
Dworatschek, S., Hayek, A.: Marktspiegel Projektmanagement-Software [Market review of project
management software], Ktiln 1987.
Dworatschek, S., et al: Personal Computer und Datenschutz [Personal computers and data
protection], 4th ed., KOln 1990.
Dworatschek, S.: Grundlagen der Datenverarbeitung [Fundamentals of data processing], 8th ed.,
BerlinINew York 1989.
Heeg, F.J.: Einftihrung neuer Technologien - ein gruppenorientierter Ansatz [Implementation of new
technologies - a group-oriented approach]. In: zfo 1986Npp. 41-46.
Heinrich, L.J.: Fallstudie Zentralisierung/Dezentralisierung [Case study centralization!
decentralization], in: Information Management 1986Npp.16-20
Kasper, H.: Widersprliche und Konflikte beim Innovationsmanagement [Contradictions and conflicts
in innovation management]. In: zfo 1986/2/pp. 115-123.
Kieser, A., Kubicek, H.: Organisation [Organization], 2nd ed., BerlinINew York 1983.
Klaus, H.G., Otten, W.: Informationsmanagement in amerikanischen Bundesbehorden (I)
[Information management in American Federal agencies]. In: VOP 1985/3/133-136.
Krallmann, H. (ed.): Informationsmanagement auf der Basis integrierter BUrosysteme [Information
management on the basis of integrated office systems], Berlin/Bielefeld/MUnchen 1986.
Lohner, B.: Erfahrungen hei der Realisierung technologieunterstUtzter Informationsprozesse
[Experience in the accomplishment of technology-supported information processes], in.: zfo 1984/S-
6/pp.307-314.
198
Monsees, G.: Partizipation in innovativen Entscheidungsprozessen der Untemehmung - Am Beispiel
der Einfiihrung neuer Informationstechnik [participation in innovative decision-making processes
within an enterprise - Based on the example of the implementation of new information technology],
(Diss. Univ. Bremen) Frankfurt 1988.
Reinermann, H.: 4 BOV-Phasen in der Offentlichen Verwaltung [4 BOP phases in public
administration], in: VOP 1989/3/pp. 126-153.
Reinermann, H.: Brauchen wir einen ganzheitlichen Neuansatz rm die Planung der
Informationstechnik? [Do we need a new holistic approach to the planning of information
technology?]. In: Strunz, H. (ed.): Planung in der Datenverarbeitung [Planning in data processing],
Berlin/Heidelbefg/New York/l'okio 1985/pp. 158-190.
Reinermann, H.: Verwaltungsinnovation und Informationsmanagement [Administration innovation
and information management], Heidelberg 1986.
Staudt, E.: Innovation und UntemehmensIlihrung [Innovation and company management]. In: zfo
1985/2/pp.75-79.
Streicher, H.: Die Angst des Vorstands vor dem Computer [The top management's fear of the
computer]. In: Office Management 1984/lVp. 1074.
Tepper, A.: Beteiligungsbereitschaft bei der Systementwicklung [Readiness to participate in systems
development]. In: VOP 1985/2/pp. 60-67.
Witte, E.: Organisation Ilir Innovationsentscheidungen [Organization for innovation decisions],
Gottingen 1973.
199
MANAGEGEMENT BY PROJECTS - A TURN AWAY FROM OR
TOWARDS mERARCHY
Wolfgang Schallehn
Abstract
"Management by projects" is a new management paradigm. Its gist is to realize the companies
strategy by performing projects. Its procedure is : Hierarchical organizations are replaced by flat
structures". But: Hierarchical orders will retain their importance. For that reason: How to connect
"management by projects" with hierarchical structures? Or even: How to realize "management by
projects" using hierarchy? After all: Can "management by projects" help to reorganize hierarchical
structures in time?
1. "Management by Projects" - a Phantastic Idea!
"Management by projects" is "elementary" in the best sense: It is a very plausible and apparently
constructive idea.
In a way" it is the reversal of the classic PM philosophy. Whereas it is debatable whether a "project-
specific organization" is an indispensable feature of the term "project" (see discussion in [ 1] ) " the
term project management undeniably refers to a specific form of management of projects which merit
a special organization on account of such features as uniqueness " scope " worksharing and the like.
Management by projects as the abbreviated form for " 'the companies complex strategy . . .
management' by projects" [2] entirely changes the emphasis: Issues of importance to corporate
strategy are to be treated as projects. These can also be actions whose intrinsic features would not
justify a particular organization. But "organization as a project" substantially furthers systematic
handling and linking with other projects and is thus appropriate for realizing corporate strategy.
2. "Management by Projects" and HlliRACHY
2.1 What is Speaking for a Hierarchical "Management by Projects"?
Hierarchical orders can only be dropped in organisms in which each element principally acts to the
benefit of the overall organism. All non-trivial biological and social organisms " therefore " link
hierarchical structures with network structures. This becomes automatically important when elements
of the same organism are not directly connected and suddenly face each other as an "environment
system". Hierarchy becomes indispensable when the organism calls for coordinated operations for
which the individual element has no motive.
This is exactly the reason for this paper. Complex corporate strategy requires numerous coordinated
operations. Yet " it is unfair to expect the individual elements in a cooporation to change in
accordance with an overall goal. There is an objective reason for this: Each profit corporation lives on
a productive basic process which - as long as possible - provides a continuous output with maximal
effectiveness (which in most cases also implies: with maximal intensity). This basic process is
composed both of a production and a management process. The latter is principally structured
hierarchically whereas the former is usually networked by material flows.
Changes to this basic process, i. e. both to production and management, are usually brought about by
corporate strategy or external interference. The tendency to shorter periods between such processes of
change with more far-reaching economic consequences and increasing interrelationships (also see [3])
is clearly evident here.
My efforts to combine these processes of change to a "stream of projects" have resulted from this. The
"multilevel system for process control" commonly referred to as MESA" which is described in the
following" is designed to support, primarily by employing hierarchical orders the management of
project streams or in other words: "managing the interrelationships between projects" [2].
If eventually hierarchy updating also was professionalized as a project, i.e. performed in time and
after thorough preparation, the link between project organization and hierarchy would be perfect.
Subjective errors would only arise in shaping the update mechanism.....
2.2 Problems and limitations of the hierachical principle
Nowadays" hierarchy cannot be endorsed without referring to its many potential dangers and failures.
Today a tendency towards saturation with incompetence (peter principle [4] ) is observed. This is
combined with the transition from stability to sterility which often goes unnoticed at first. Inherent in
hierarchy, however, is "only" the lack of cross-links which can result in long information paths.
It is not a problem of hierarchy as such that these problems are ignored when shaping or operating a
system.
202
3. The MESA concept
The fundamentals of the MESA concept were set forth in the thesis "Eine Mehrebenensteuerung fiir
komplexe diskrete Prozesse mit unvollstiindig vorbestimmter Struktur" [5], where the "project
streams" to be controlled were modeled as network plans. The basic novelty in this thesis was the use
of control reserves which is possible with a fuzzy structure.
Figure I depicts such a stream of projects. The characteristic feature of the term "stream" is that the
projects "collide" at many points, e.g. when they compete for resources.
Figure I: A stream of projects
The original aim was to coordinate scheduling and resource allocation. It was assumed that objectives
and priorities are defined "from outside". With a corporate strategy that originates from an
organization it is necessary to detail priorities and orders downward from level to level.
MESA relies on five basic concepts:
* Hierarchy,
* Feedback,
* Principle of corresponding horizons,
203
* Concept of residual quantities,
* Control by selection of structure.
Hierarchy and feedback are classic concepts which are specially linked in the MESA concept. The
principle of corresponding horizons and the concept of residual quantities are presumably a complete
novelty. Control by selecting the structure establishes a new correlation between known optimization
methods and residual quantity accounting.
Several other interesting details have to be added such as the provisioning or coordination deadline,
the step-by-step procedure (Pilgerschrittverfahren) for residual quantity accounting, some aspects of
software design and the like.
These basic concepts can be used independent of each other; their effect, however, then is distinctly
reduced. Feedback and working horizons, in particular, are vital when a "large-scale" system has to be
handled. And it is only the residual quantities that permit resources to be accounted across all levels.
As a result, only the interaction of all MESA components produces the full effect.
3.1 MESA hierarchies
MESA naturally consists of many categories which, in tum, are structured hierarchically [6]:
* Management, organizational structure
* Project structure(s)
* PTocessstructure
* Resource structure
* Time units (year, month, (decade), week, day, hour.... ), and further units of measurement, e.g. for
resources.
All these structures exist objectively. They are mapped in data structures, but these maps inevitably
remain incomplete. Therefore, it is "vital"
* to interconnect the categories (this is done with the MESA operating functions)
* to assure consistency of databases (operating cycles and especially the compatibility checks are
conceived for this)
* to identify uncertainties in the data models (the concept of residual quantities provides a new
approach here)
* to limit databases to the volume actually required (the working horizons are a helpful tool).
The MESA concept imposes no conditions on the number of levels. Practical experience has shown
that in many cases "flat" but in other cases "steep" hierarchies are set up. The decision on whether to
use "few" or "many" hierarchical levels cannot be objectified since the conceivable criteria counteract
204
each other: A high degree of specialization increases productivity in the individual processes but
requires much coordinating effort and thus a steep hierarchy.
Team work and computer support, however, help set off the disadvantages of specialization, in
particular, in the field of intangible services. As a result, the tendency goes towards flatter hierarchies.
The process network hierarchy is of central importance to MESA. A process network may include
many small projects or one project or part of a big project. For such a process network" the
responsibility is assigned to one manager.
Generally, except for the highest and lowest levels, each process is part of an upper process, and is, as
one can imagine, composed of a lower of lower processes.
.F? .....
Level
Figure 2: The process network hierarchy
205
Each project goes through all levels from top to bottom, becoming more detailed with each advancing
level. But a typical characteristic of MESA is: The activities data is preserved even when the activities
responsibility has been handed over to the next lower level. In this way, each manager has a clear
picture of the whole process, which, additionally is detailed to fit his needs.
The process networks are the decision-making basis for the managers at the individual levels. Figure 3
shows how the top level gives the go-ahead for a project which is still relatively far away. When the
project proceeds "normally", the following decisions only have to be taken at the lower levels.
Figure 3: Sequence of decisions
Yet, when the process model is used, the top-level decisions relate to the remotest period whereas the
decisions of the next-lower levels refer to shorter and nearer periods. The decisions on issues at the
individual levels, of course, must completely cover the process to be controlled.
206
Figure 4: Areas of decisions
3.2 MESA Cycles
Such a complex system naturally requires numerous feedbacks to assure data consistency among the
models and with reality (at least within certain tolerances).
MESA discriminates between "object" and "control" cycles on the one hand and between main and
operating cycles on the other.
Object cycles describe system flow of process-relevant object data. Such data, for instance, are work
volume and logic dependencies, and all data which have to be provided in advance(!) for project
scheduling.
Control cycles describe the system flow of control infonnation. At the center of control information is
the "freezing" of activities to fix their schedule, intensity (usually the standard value "nonnal
intensity") and their allocation to the resources.
207
The operating cycles each consist of a work step and the subsequent compatibility check. The
individual steps as a rule imply the transfer of certain data from one level to the next. The result of
such a transition to another level is a degree of itemization which differs from the initial information.
It is therefore necessary but often not self-evident to check them for "compatibility" (at least within
certain tolerances).
The main cycles generally consist of a so-called "feed-forward loop" in which project idea
information is gradually refined and the "feedback loop" in which the information is reduced from
"detail to rough outline" for control purposes. For each concrete object the main cycles end with its
completion (at the earliest!), i.e. they are of no significance for object control. They are, however,
important as a mental summary of the operating cycles and, naturally, for the overall valuation of each
project.
3.2.1 Object Cycles
The main object cycle starts out with a first project predefinition. The draft is gradually refined until
the detail documents, e.g. construction drawings, are available. The principal phase of the main object
cycle is the realization process. The accumulation of the actual data and their compression via the
same stages as in the design process forms the "feedback loop" of the main object cycle.
Compressing the actual data for the overall project would be much too late for control purposes. Each
work step in the design process is a creative process providing results that deviate more or less from
the initial data. An immediate feedback is, therefore, indispensable. An object, of course, is always
better known after a more detailed solution has been worked out, and the "current" data will, thus, be
more applicable. Minor variations also are acceptable but in case of substantial differences a decision
must be taken on whether to modify the low-level data model or the upper-level model. In the first
case this means projecting according to given restrictions and in the second accepting new facts.
3.2.2 Control Cycles
The control problems will be treated exhaustively in 3.5. Here, it is only noted that each control
information influences a level with a higher information content. As a result, compatibility has to be
verified immediately. The decisive feature of such controls is that they feed back to expected (!)
actual conditions - and this over as many stages as the system has levels.
208
3.2.3 Accounting Cycles
MESA assumes that some of the required resources, which are the most important, are limited. The
term accounting (abbreviation of accounting optimization) within the meaning of MESA denominates
the time-related correspondence between resource requirement and resource allocation. From the
viewpoint of the mathematical theory of complexity this is a very difficult task. MESA complies with
this by keeping the process segments to be accounted as small as possible. This is primarily achieved
with the tool of the working horizons (see 4.3).
On the other hand the "dimension" of the accounting areas is defined subjectively: It is entirely up to
the senior manager to combine several projects into one process or to break down projects into several
processes. By this, he shapes either a flat or a steep hierarchy
For MESA it is only a question of handling many small or a few big accounting tasks. The restrictions
here primarily result from the performance of the employees in charge.
On principle, the accounting areas are "accounted" successively according to given priorities. MESA
assumes that specific resources are allocated to each accounting area. This means in particular that
each "higher-level" area has resources only for the purpose of using them deliberately in its
subordinate (!) areas.
The accounting cycle starts with the top priority area. Both its own resources and the total resources of
the higher-level area are available. Following this accounting process, a substantial portion of these
resources will be allocated. The remaining part is now available to the accounting area with the next
lower priority together with the latter's own resources. After accounting the second (and each
following) accounting area the impression could be gained that a much better process would be
feasible if certain bottleneck resources were available which, due to higher priority but maybe not to
urgent reason" have already been allocated. Feedback is activated here. The manager of the priority
area will rarely be motivated to transfer resources. Only when a senior manager considers it
reasonable, will resources be used contrary to priorities. Consequently, the senior manager must take
the decision.
Within the overall process there may quite often be grounds for returning to an area already accounted
- and this is how an accounting cycle is created.
3.2.4 Final commentary on MESA cycles
To sum up the operating cycles" the following can be stated: It is true that they are "entirely normal"
feedbacks but
* on account of the MESA horizons and levels they are clearly and effectively networked into
overall processes, and
209
* on account of the use of residual quantities (see 4.4!) they require far less tricks and can consider
much more realistically the conditions in and among the levels.
3.3 Corresponding horizons
The MESA concept's dynamics lives on networking the levels by means of "corresponding horizons".
They divide each process network "across the time axis" into ·operating intervals. Each interval
consists of a set of activities whose principal common feature is that they will jointly pass the
following work step. This is marked as "status" on each activity.
In practice this means that each process model of a certain level is subdivided into four intervals:
Status Contents Bounds (to the right)
(A) the activities going fit-to outline

(in account)
f(F) the activities (to be) fixed fixed-process horizon
at this time, "today"
(b)B the activities (to be) accounted accounting horizon
(with provisional times)
(v)V the activities (to be) prepared preparation horizon
for the accounting procedure
Each pair of neighbouring levels is connected by corresponding working horizons:
Lower level horizon Upper level horizon
Fit- to-outline «no outline»

Fixed-process horizon fit-to outline
Accounting horizon fixed-process horizon
Preparation horizon accounting horizon
«no data» preparation horizon
This means that a fit-to outline of a (higher) level "corresponds" to the fixed-process horizon of the
next lower level, the accounting horizon of the following level and" finally" to the preparation horizon
of the fourth level involved. This means that each process element basically passes all horizons at the
same time as it is the same process which should be mapped at all levels.
210
I
I
I
I
I
I
I
I ~--
..-/ --
l..-/
Figure 5: Corresponding horizons
3.4 Residual quantities
Originally" the concept of residual quantities was developed [ 5 ] to control the differences between
the data models of the individual levels. Under the terms of a reconstruction plan for the city of
Leipzig in 1976 " for instance" approximately 40 projects could be indicated" but it was clear that the
total number would have to be three times as high and the value more than double.
Of course it would have been possible to include one object or the other. This, however, would have
increased the uncertainty about the objects. The "fuzzy theory" was a possibility but it required the
indication of "candidates" . .... Apart from that, there was no obvious bridge from the fuzzy model to
the network plan.
There was no chance at all to present a real, complete list. An agreement was reached only on the
scholastic formulation" namely that infinitely much time and efforts were needed to achieve this goal.
211
Parallels also were evident with respect to prework and rework which forms part of certain work
packages but usually is handled outside the duration of the actual activity.
Defining this residual quantity at first only means a "softening" of the provision according to which
resource requirement coupled to the activity. Previously, resource requirement was distributed evenly
over activity duration or assumed to be fixedly allocated to the start or completion of an activity, at
least in determined form.
The claim for resources of the residual quantity is expressed as an area. At first such an area can take
any shape in the resource accounting. It is evident that an "enlargement" of the square as shown in the
figure 6 is barely realistic and rather a distortion.
a) b) 111_ c) U
1
~'~7 ~--~1~~
L.._ _ _..... R~ D D
Figure 6: "Enlargement" of the square
These principal ideas are no dogma. The "residual quantity dynamics" (see figure 7) of course admits
that a part of the residual quantity retains its character of residual quantity on the next lower level. It is
even expected that a certain portion of "residual quantity" is visible when transferring an explicit
element to the next lower level.
Lower ,- - - - - - ... , , - . _ - - ......

Iw~J t I I A&1;,,/t1 82-1 I \
I~:-';:-:-:;:-' ,
~\
\
,", OII~/~'
I .. I
\ ["divil, sz" II \ \.~~.~I
r-AA.;;'f"":'-:--f8;-:1 J
,
------ _"/
-----_./
Figure 7: "Residual quantity dynamics"
The author developed a step-by-step procedure to perform resource analysis with residual quantities.
This method bases on the principle that "normal" activities are integrated with a certain feed-forward
212
("two steps forward") whereas the residual quantity is filled in the remaining gaps in a second run
("one step back"). In other words: The capacities which are still free after satisfying "basic resource
requirements" (see square modules in the picture) are allocated to the residual quantities. It is evident
that this can only improve the quality of the resource usage plan, i.e. the rate of resource usage. The
"normal" solution is given when there is no residual quantity. The rate of usage is 100 % when the
residual quantity is bigger than its "gaps".
The concept of residual quantities is especially suited when risk surcharges have to be considered
which always require a compromise: on the one hand, they have to be available upon request, but on
the other they must not act as a delay when everything is running smoothly.
The mathematicians consulted to date have not yet accepted this concept as entirely new. The author!,
however, is not aware of any analysis model which has processed single and summary planning
objects in a comparable manner.
3.5 Control by selection of structure
MESA" s real purpose is to specify who of the participants involved in a very complex process has to
perform which activity at what time to ensure proper performance of the overall process. Control
means selection from certain options, i.e. from the so-called "control reserve" " and then realization.
As opposed to controls which operate on the basis of intensity selection within the frame of fixed
process structures (typical examples are temperature and pressure control), MESA primarily uses the
"fuzziness" of the process structure for its "control by selection of structure". The result is a process
structure which in many cases already works efficiently at normal intensity. Intensity control,
however, can be added (thesis Bohr [7]).
"Classic" control more or less as optimal resource analysis, is naturally the basis of MESA control.
The structuring is most evident in sequence optimization.
Up to now" the structuring of at first formless residual quantities (see 4.4) has been entirely unusual in
network planning. However, it must be pointed out that residual quantity structuring is always of a
preliminary nature. Actually, only the control reserve for the next lower level is fixed by this. This
especially applies to the lowest level where the residual quantity, for instance, is available to the
construction manager.
4. MESA Implementation
MESA represents a systems solution to project data management and processing. Many MESA
procedures are only reasonable for streams involving many projects. It is probably not possible to test
213
and valuate their effectiveness only on the basis of a few isolated projects. But on the other hand" is
also not possible" to test and valuate them only in theory.
For this reason, a MESA prototype was developed to get to know the principal methods and data
structures. A comfortable user interface ensures that a user can fully concentrate on his specific
problem. He only must be familiar with individual data files if he wishes to combine files from
various network versions.
The first MESA software version is expected to be operational by the end of 1990. However, in the
near future it will not be possible to complete it entirely and supplement it with expert system
components.
5. MESA and "Management by Projects" in the GDR
Transforming the GDR economy into a free market economy poses many problems. Project
management has to deal with three categories of tasks:
* Professional management of a tremendous amount of (more or less interrelated) individual
projects;
* thereof, as a special category, the reorganization of entire companies, and
* thereof the introduction of "management by projects" as a management philosophy for the
continuous realization of corporate strategy.
There may be a correlation: When the reorganization projects proceed successfully, a routine
"management by projects" will also have good startup conditions. And vice versa: The one who
intends to practice "management by projects" successfully in the future, is well advised to look for
competent advisers on the reorganization process and cooperate with them as closely as possible.
References
[1] Schelle, H.: Zur Lehre vom Projektmanagement. In: Reschke, H., Schelle, H., Schnopp, R.
(Eds.): Handbuch Projektmanagement, KOln 1989, p.3-21.
[2] Gareis, R. (resp): Management by Projects, Final Invitation to the 10th INTERNET World
Congress on Project Management, Vienna, June 26-29th, 1990.
[3] Briner, W.: THE PROJECT AS A VEHICLE FOR CHANGE IN ORGANIZATIONS in
Integration of Projects into the Company Organization. In: Proceedings of the 13th INTERNET
International Expert Seminar, Ruschlikon 1989.
[4] Peter, L. J.: Das Peter-Prinzip, Berlin 1989,
214
[5] Schallehn, W.: Eine Mehrebenensteuerung fUr komplexe diskrete Prozesse mit unvollstiindig
vorbestimmter Struktur, Dissertation, Technische Hochschule Leipzig, 1983.
[6] Schallehn, W.: Hierarchien in der Ablaufplannug. In: Proceedings of the Int. Congress
"Mathematik im Bauwesen", Weimar 1969.
[7] Bohr, W.: Steuerungsaspekte in der Ablaufplanung, Dissertation Technische Hochschule
Leipzig, 1986.
[8] Autorenkollektiv: MESA-Dokumentation, Technische Hochschule Leipzig, Sektion
Mathematik und Informatik, 1990
[9] Dworatschek, S., Hayek, A.: Marktspiegel Projektmanagement Software, 2. Aufiage, KOln
1989
215
Project Managem.ent
Organization
and
Hum.an Factors
CONTENTS OF THIS CHAFfER
PROJECT TEAM PLANNING: THE NEED, METHODS AND BENEFITS

Russell D. Archibald
TRAINING
David Mathie
MANAGEMENT OF INTERSTED PARTIES

Juhani Silvasti
CO·DEVELOPMENT • A FUTURE FOR INTER·ORGANIZATIONAL PRODUCT AND

PROJECT DEVELOPMENT
Alex van den Honert, Rieks Broersma
THE KEY ROLE OF THE CLIENT OR OWNER IN THE MANAGEMENT OF

CONSTRUCTION PROJECTS
E. Geoffrey Trimble
ROLE OF SENIOR MANAGEMENT IN DEVELOPMENTAL PROJECTS

Bob Gillis
PROJECT TEAM PLANNING: THE NEED, METHODS AND
BENEFITS
Abstract
Project planning is of course a well-known topic, and many tools and methods have been developed to
carry out this important aspect of project management. Too frequently this has been assumed to be the
responsibility only of the project manager, or even delegated entirely to specialized project schedulers
and cost estimators.
In recent years the importance of the multi-disciplinary project team has been recognized more
widely, and the power of project team planning has been discovered by many practitioners. This is
becoming evident in the increased emphasis on systematic project start-up, using team planning
workshops at the start of each phase of the project life cycle.
This chapter describes the need for project team planning, and describes various ways that have been
developed and observed to carry this out in an effective manner. It further describes the planning
deliverables which the project team can produce, and identifies the important benefits that can be
obtained by using the project team planning approach. An example is given to illustrate the approach
and its benefits.
1. The Need for Project Team Planning
Recognition of the need for project team planning has grown out of the increased awareness of (1) the
weaknesses in the more traditional project planning approaches, (2) the difficulties in getting
functional managers and team members to be committed to a plan that has been created by others, and
(3) the need to accelerate the project planning and team building processes at the very beginning of
the project. The concept of project team planning applies equally to the inception of the conceptual
phase and to the starting up of any subsequent phase of a project. It can also be used effectively when
any major change in scope is required, or when a major, unforeseen problem is encountered.
1.1 Traditional Project Planning Approaches
Traditionally, project planning activities are considered to be a primary function of the project
manager. On smaller projects, and within organizations that have relatively little experience in
formalized project management, the project manager is typically expected to put together whatever
plans and schedules may exist for the projecL
In larger organizations, especially when they have considerable experience in project management
and have formalized their approa,ch to managing their projects, project planning specialists are used to
create the project plans, schedules and budgets. The basic tools used by such specialists are well-
known and documented in the extensive project management litemture:
o Clear definition of project objectives and scope using descriptive statements.
o Systematic project defmition using a multi-level project/work breakdown structure (pBS/WBS).
o Defmition of responsibilities using a task/ responsibility matrix based on the PBS/WBS.
o Development of an integrated project master schedule, using a time-scaled bar chart with key
interface events identified (the bar-net).
o Preparation of the project budget, based on the PBS/WBS, and reflecting the resource estimates of
those responsible for doing the work, using established estimating procedures, and linked with the
organization's cost accounting system
o Preparation of an integrated, more detailed project plan and schedule, based on the PBS/WBS and
reflecting the resources required and available to perform the work, using PERT/CPMlPDM
network planning and critical path "analysis methods.
o Preparation of detailed, short-interval functional task plans and schedules using the most
appropriate methods (bar charts, check lists, other), but integrated with the less detailed integrated
project plan and schedule.
Ideally, these project planning specialists (planners, schedulers, cost estimators, cost engineers,
software and computer operations specialists) will carry out their work for a specific project under the
direction of the project manager assigned to that project. In other situations, they may work mther
independently of the project manager, as discussed below.
220
1.2 Weaknesses in the Traditional Approaches
Several critical weaknesses can often be observed in the traditional approaches described above:
o PrQject plans. schedules and bud~ts do not reflect the realities of how the work will acmally be
~. There are always many ways to plan and execute a project; even the best plans will not be
followed if they do not reflect the methods that the people doing the work will acmally use.
o The functional mana~ers and other team members. and even the project mana~er. are not
committed to the planS and schedules. If the plans do not reflect how the work will be done, the
people doing the work obviously will not have a sense of commitment to the plans, with the result
that they are not committed to the project itself.
o More than one plan exists. Given the above points, it is not surprising to find many situations
where more than one plan exists, either for the entire project, or for many portions of it. The
project manager who does not believe in and is not committed to the plans and schedules produced
by a central planning department will produce his or her own plans as a result. Many functional
managers often do the same thing.
o The plannin~ process is inefficient in the use of key persons' time. A project manager or the
planning specialists who recognize the need for involvement of the key project team members in
creating the plans will often meet with each individual team member one-on-one to obtain the
needed information. After meeting with other team members, a second or even third round is
usually needed to work out various conflicts or discrepancies. This process is inefficient and
consumes much time of all concerned, compounding the dislike most people have for planning in
the first place. This approach slows down the critical start-up phase of the project, and does not
enhance teamwork or communication.
o Plans created either without involvement of the keypeople. or with their involvement throu&h the
"rouridrobin" or "honey-bee" !U!proach described above. will fienerally be based on a "bottom-up"
view of the project. This bottom-up approach results in project plans and schedules which are
often poorly integrated, and harbor unrecognized conflicts which will be identified later when
there is insufficient time to avoid them through more integrated, "top-down" planning.
These weaknesses -- unrealistic plans, lack of commitment to the plans, the existence of multiple
plans, inefficient use of key persons' time, delay in starting up the project and building the team, and
bottom-up rather than top-down planning -- have led to a rapidly growing realization that there is a
better way. That is the use of project team planning.
221
2. The Project Team Planning Process
2.1 Project Start-Up Workshops
Although the importance of getting a project off to a good, well-planned start has long been
recognized (see, for example, "Project Start-Up Checklists" ([1], pp. 245-263); and ([2], Section 4)), it
has only been within the last ten years that the concept of systematic, well-planned project start-up
workshops has been widely accepted and used. The INTERNET International Project Management
Association's Committee on Project Start-Up, which was established in 1982 under the leadership of
Dr. Morten Fangel, who continues today as its Chairman, has been instrumental in promulgating and
documenting this concept. (The Committee's Handbook of Project Start-Up [2] provides detailed
information on the concept, the methods, and many examples of experience in its application in
various industries and geographic areas of the world.)
The fundamental essence of the concept of these systematic project start-up workshops is project team
plannin&. The start-up workshop, when properly conducted, provides the setting and well-planned
process that enables the project team to work together effectively to produce integrated plans and
schedules in a very short time period.
The phrase "project start-up" may be misleading, since the concept applies not only to the very flrst
"start-up", say, at the beginning of the conceptual phase of a project, but also at the beginning of each
subsequent phase: defmition, planning or proposal; execution or implementation; and project close-
out. The term "project phase transition workshop" may be more appropriate than "project start-up
workshop".
2.2 Elements of the Team Planning Process
The basic elements of an effective team planning process are:
o Adequate preparation.
o Identiflcation of the key project team members.
o Interactive exchange of information.
o Capture of the "Team Memory".
o Use of a planning process facilitator.
o Physical setting conducive to the process.
Each of these is discussed in the following sections.
222
2.2.1 Adequate Preparation
Prior to bringing together a project team for a team planning session it is vital to prepare adequately
for the meeting. This includes:
o Defining the specific objectives of the team session and the results to be achieved.
o Establishing a well-planned agenda.
o Preparing sufficient project planning infonnation in preliminary form (project objectives, scope
defmition, top levels of the PBS/WBS, team member list, established target schedules - if any, and
soon).
o Setting the session date sufficiently in advance to ensure that all team members can attend.
o Announcing the session through appropriate authoritative channels to ensure higher management
interest and suppon -- and to assure that all team members show up.
o Defining and understanding the planning process to be used, and the roles and responsibilities of
the project manager and the planning process facilitator.
o Arranging for a suitable meeting facility and related logistical suppon.
2.2.2 Identification of the Key Project Team Members
It seems obvious that in order to have a project team planning session, it is necessary to identify the
team members. However, this is often not a simple task. Who are the key project team members?
Which functions must be included, and what level of manager or specialist from each function should
be identified and invited to the team planning session? How many people can participate effectively in
such a session?
A few basic rules can be helpful in answering these questions:
o Each of the imponant functional specialties contributing to the project must be represented. This
may include people from within 'and outside of the organization (contractors, consultants, major
vendors, etc.).
o The perSon holding responsibility and accountability for the project within each functional area
(the "functional project leader") must be present.
o If a functional project leader cannot make commitments of resources for his/her function, that
person's manager (who .!<l!.D. make such commitments) should also be invited to participate in the
team planning session.
o If the key team members number more than 20 people, special effons are needed to assure
appropriate interaction (such as breaking into smaller working team sessions).
223
o The project manager obviously plays a vital role in the team planning sessions; and, if available
and assigned, project planning, scheduling and estimating specialists should also participate in --
but not dominate -- the sessions.
2.2.3 Interactive Exchange of Information
Central to the project team planning concept is the need for intensive interaction between the team
members during the planning process. The session prepamtion, the information provided, the physical
setting, and the methods of conducting the planning sessions must be designed to promote, not inhibit,
this interaction. If the project manager goes too far in preparing planning information prior to the
meeting, and presents this information as a fait accompli to the team in a one-way presentation, there
will be little or no interaction, and the objectives of the team planning session will not be met.
Robert Gillis has pioneered the development of such sessions over several decades in his work in
Canada, and Figure 1, from Gillis' paper, "Strategies for Successful Project Implementation" ([2],
Section 4) illustrates several important factors in achieving the interactive exchange of information
that is needed for effective project team planning. As indicated in Figure 1, the intemction process is
based on:
o Immediate recording of keyword abstract of what is said (recall trigger).

o Immediate display of group memory.
o Exploration of what it means (through interactive discussion).
o Fitting the keyword card in the right information structure.
o Continuing the process until the objectives of the session have been reached.
2.2.4 The Planning Theater
As shown in Figure 1, Gillis uses the term "planning theater" for the room in which the intemctive
team planning sessions are held. This is an important factor in achieving the interaction desired. It
does not have to be an elaborate design, but it must provide:
o Plenty of wall space with good lighting for display of the team memory and planning results.
o Open access to the walls by the team members (elimination of tables and other impediments to
individual movement to fill in keyword cards and place them on the walls).
o Sufficient space to enhance individual comfort, movement to view other walls, and open
communication.
224
IlIlllGffKilfi' MANAGEMENT WORK SESSION
Moderator/recorder
Interaction process .. provides the process of
.. Immedlale recording of Group Memory inlaraelive communication
keyword abstract of what is .. key word cords as
satdRECALL TRIGGER) 'memory-hooks- . .. skilled in information
caplure. structuring. and
.. Immediate display on group .. cumulative visual record on analysis
memory walls of planning theDlre ;
.. expert in projeel planning
.. informalion structures: and conlrol lechniques .
.. exploration of whet it means
symbols. drawings. models
.. leads the group in exploring .
.. card is filled in the r ight
.. documenled posl-session 85 idenlifying. evaluating. deciding
information structure
the record of the work and planning
.. process continues unW the
objectives of lhe session h..,.
been r8lched
§§= =
=
§§= Cl ===
==
Cl Cl
= =
Cl =
Cl
== = =
=
PLANN I NG GROUP
.. key decision makers & resource
people;
.. provide ell content - facls. PLANNING THEATRE

definilions. assumptions. need.s .
ideas. approaches. evaluations; .. specially prepared
meeling room;
.. dec-Ide what they wanl to do;
.. facilities. equipment.
.. make aelion decisions: whet. who, and furnilure suilable
for promoting group
when. how _
communication _
.. develop aclion plan & schedule
Figure 1: Impact Management Work Session (Source: [2])
225
2.2.5 Capturing the "Team Memory"
The team memory ("group memory" in Figure 1) is based on:
o Using the keyword cards as "memory books" to recall specific ideas.

o Creating a visual record on the walls of the planning theater or meeting room.
o Proper information structures that are appropriate to the planning work: being done: models,
matrices, drawings, symbols, charts.
The team memory resulting from capturing and structuring the information exchanged and produced
during the planning sessions provides an agreed, understood post-session record of the plans created
by the team.
2.2.6!The Project Manager Role in Team Planning
It is widely recognized that the key characteristic of the project manager role is that of integration. In
project team planning, the integrative role of the project manager becomes quite obvious. The project
manager must assist the project team members in developing an acceptable plan and schedule that
achieve to objectives of the project and reflect the plans and available resources of the various team
members. The project manager usually holds the lead responsibility for preparing for the team
planning sessions, as discussed earlier.
During the planning sessions, the project manager must be alert to real or potential conflicts,in plans,
and bring these to the surface for resolution. He/she must concentrate on identification of the key
project interface events, or those points of transition of responsibility from one team member to
another, since one of the key tasks of the project manager is to properly manage these interfaces.
A second key role in the project team planning process, that of the process facilitator, can also be
taken by the project manager, but experience shows that it is much more effective for another person
to carry out the facilitator role,as discussed below.
2.2.7 The Planning Process Facilitator
The facilitator (moderatorlrecorder in Figure 1) is a crucial player in the project team planning
process. This person:
o Provides the process of interactive communication.
226
o Is skilled in infonnation capture; structuring, and analysis.
o Is expert in the application of project planning and control methods and techniques and other
aspects of project management.
o Leads the team during the planning sessions in exploring, identifying, evaluating, deciding, and
planning.
o Maintains the process discipline to adhere to the established agenda for the planning session.
2.2.8 Setting the Stage for Detailed Planning
The plans, schedules and other planning documents created during a team planning session should be
limited to integrated plans at the overall project level. These will, of course, require definition of the
project down to the major functional task level, so that responsibilities can be assigned, agreed and
understood among the team members. The team-produced project master schedule will show the
agreed target dates for key milestones, reflecting the team's judgement on the overall allocation of
time to accomplish the intermediate and final objectives.
Team planning sessions are not intended to produce detailed, functional plans, schedules and budgets.
To attempt to do so would be an extravagant waste of valuable time. Rather, these team sessions are
intended to set the stage for truly effective detailed planning, scheduling, and budgeting. Based on the
results of the top-down planning performed by the project team, under the integrating influence of the
project manager and guided by the planning process facilitator, the stage is set very effectively for the
detailed planning needed to validate the team's efforts and prove whether their judgements are correct.
At this point, the project manager, often with the assistance of planning, scheduling and estimating
specialists, can proceed with the more detailed, integrated planning that is necessary to assure
effective monitoring and control of the project. The top level project plans produced by the team can
be entered into the computer software to be used on the project. The more detailed functional plans
and schedules can also be entered in the planning and control system, to the extent that this is
warranted and practical.
3. An Example of Team Planning in Action
An example of team planning in action in the telecommunications industry is provided in "Project

Start-Up of Complex Information System Projects" ([2], Section 2; and [3]). In this example, the team
planning sessions were called project start-up workshops.
227
The projects involved designing, manufacturing, installing and testing complex voice/data
communications/information systems by the AT&T Corporation under contract to companies and
agencies who were purchasing the new systems. AT&T had sound project management practices in
place, but needed to accelerate and improve their project planning, scheduling and team-building
efforts for these major projects. The team planning start-up workshops typically were conducted in
two or three sessions of one full day apiece, usually one week apart (to allow time for cleanup of each
day's results and preparation for the next planning session). The first two days usually included 15 to
20 internal AT&T team members and managers (although on one very large project the team
comprised 40 people!). The third day included the AT&T team members plus the client project team
members.
3.1 The Planning Deliverables Produced
The specific planning deliverables produced during these team planning sessions were:
o List of key concerns and major open issues.
o List of all project team members with office and home telephone numbers and electronic mail
addresses, including the client team members. Also included were the names of immediate bosses
and their office and home telephone numbers, for use in escalating unresolved problems or
conflicts.
o Project scope and objectives.
o Agreed definition of the project in the form of a project (work) breakdown structure (PBS),
usually down to four or five levels.
o Agreed task/responsibility matrix, based on the PBS, with codes showing, for each task, (1) who
does the work, (2) who must be consulted, (3) who must be notified or receive a copy of the
results, and (4) who must approve the results.
o A list of the key project interface events, indicating who would be the originator and who the
receiver.
o The project master schedule, based on the PBS, with team commitments thereto.
o Agreed project monitoring and control procedures.
228
o Action assignments from the planning sessions.
o The Project Handbook, a three-ring binder with dividers for retention of the above documents, for
use by each project team member throughout the life of the project. As the plans were revised and
up-dated, the latest documents were placed in these handbooks.
3.2 Conduct of the Planning Sessions
For each AT&T project, the assigned project manager planned and prepared for each team planning
session, following the guidelines described earlier in this chapter. An experienced facilitator assisted
the project manager in this preparation, and in conducting the sessions. For each planning deliverable,
the facilitator gave a brief presentation of the project planning concept, and then the project team
immediately applied that concept to the project. In developing the project breakdown structure and the
task/responsibility matrix, small teams of four or five people worked together on the specific portions
of the project for which those team members held responsibility.
The small teams reported their results to the full project team to assure complete agreement and
understanding.
3.3 Results Achieved
The results of these team planning sessions were, and continue to be, excellent. The projects have
been completed on schedule and without crash efforts near the end date, saving money and increasing
the quality. Improvements have been noted in getting the projects started more quickly and smoothly,
in cooperation with the client, in better communications and better teamwork.
The functional team members have reported that this approach requires less of their time for planning
than the more traditional methods used previously. Team planning through start-up workshops has
been incorporated into the AT&T corporate project management process, and is used on all major
projects within this business segment of AT&T.
3.4 Hidden Agenda Items
Several hidden agenda items have been reported as benefits of the team planning approach:
o Introducing uniform project management methods.
229
o Hands-on training of project team members in project planning.
o Tapping the team wisdom.
o· Creating a shared vision of the project and its objectives.
o Demonstrating the power of open team communications.
o Exchanging experience and developing skills.
o Creating a team and getting commitment.
4. Benefits and Limitations of Project Team Planning
4.1 Benefits of Project Team Planning
The basic benefits of project team planning are:
o The plans produced will be based on how the work will actually be accomplished.
o The persons responsible for performing the work will have a greater sense of commitment to the
plans and to the project.
o Only one set of plans will exist: those that the project team has created and is following.
o The time required to be devoted to planning by the key project team members will be minimized.
o The project plans will reflect a top-down approach using the total wisdom of the project team,
which then sets the stage for more effective, detailed, bottom-up validation of the plans.
Other benefits, including the hidden agenda items, are listed above.
4.2 Limitations of Project Team Planning
The decision to use project team planning should be based on the characteristics of the project in
question. If it is an effort that is very well known to the organization, and very repetitive of many
previous projects, with project team members who are all experienced in this type of project, and
planners who can produce plans and schedules that are valid and acceptable to all concerned, then it
would not be appropriate to insist on the type of project team planning described above.
There appears to be no upper limit in project size for the use of the project team planning approach.
At the top of a massive mega-project, as one extreme, the objective of the top level project team
230
planning session would be to define the major sub-projects into which the mega-project should
appropriately be divided, identify the key milestones and interface events which will link these sub-
projects, assign responsibilities as appropriate, and layout the target project master schedule. At each
subordinate level, the project team must recognize the appropriate level of detail below which they
must not attempt to develop plans and schedules. Each team must concentrate on handing down the
structured plans and schedules within which the next level teams must in turn develop their plans.
The primary limitation in project team planning is probably the time required of the project team
members to devote to the team planning sessions. Although planning should be given a high priority
in any organization, frequently it is viewed as unproductive and even wasteful, hence it difficult to
convince the project team members that they should devote even a few days to developing the project
plans. Top management understanding and support is required to overcome these ingrained attitudes
and habits. A successful project team planning session can also do a lot to demonstrate the power and
usefulness of this approach.
References
[1] Archibald, R.: Managing High-Technology Programs and Projects, New York 1976.
[2] Fangel, M. (ed.): INTERNET Handbook of Project Start-Up, INTERNET Committee on
Project Start-Up, Saettedammen 4, DK-3400, Hilleroed, Denmark 1989.
[3] Ono, D., Archibald, R.: Project Start-Up Workshops: Gateway to Project Success. In:
Proceedings of the 1988 Project Management Institute Seminar/Symposium, Sept. 17-21, 1988,
pp.50-54.
231
TRAINING
David Mathie
Abstract
In today's industrial world (from the manufacturing to the service sectors) managing modem projects
has become an increasingly complex specialized task for managers, and their teams. .
Project management, although part of business management, is a specialized task for most managers
with multi-function and often multidisciplinary responsibilities.
The project team and, more specifically, the project manager has to provide leadership in the
technical, administrative and inter personal areas.
In order to function properly and effectively, training is essential and should be addressed to: general
training in project management techniques and methodology; specialized training to cover the specific
industry/company requirements.
Most training has historically been given in the industrial environment and that is still true today.
There are very few organized courses in project management available from technical schools and
universities. The majority of project management professionals are involved in the business because it
"happened to them", they did not plan it.
1. Introduction
This chapter attempts to provide, in a few short pages, guidelines for project management training. It
starts by discussing why training is necessary, and why training should be the best possible available
why it is necessary to define the training objectives from the trainer (company) viewpoint and from
the trainer (employee) viewpoint. It goes on to discuss the types of training available and why the
organization requiring training should adopt a structured approach.
In conclusion, it gives some examples of training programmes related to how training should be
carried out.
2. Wby Training is Necessary
2.1 Training is necessary for the proper execution of any professional task and this statement is also
true for project management where the objective is to manage the aspects of time, cost and
technical quality of the fmal product(s). In particular, the culture of project management, which
is a complex management process with horizontal and multidisciplinary aspects, requires a
sound preparational base. The days of managing projects with only basic technical or
administrative expertise are long gone.
2.2 Good, professional training organized in a structured manner should really start early; ideally it
should begin at university level, or even before. However, as project management is not really
identified as a career possibility, very few centres of learning offer the proper courses; those
that do have excellent postgraduate courses or courses additional to the main degree course. In
industry, training is generally hap hazard and career planning in the project management field is
rare. Most courses are provided by a mix of intemal and external resources and they vary in
quantity and quality.
2.3 Training has to address the human element and is most likely to be successful if the participants
have already some technical experience of a company's product. In project management, as in
all other management tasks, the human element is of fundamental and critical importance to
ensure the successful (and profitable) outcome of a project. Each single "human resource"
involved in the project must be professionally capable and must possess a management culture
which, in terms of language (terminology), comprehension, application and behaviour, presents
a large degree of uniformity with, and superimposition over, that of the other resources 'Yithin
the project structure with which there is interaction.
In a normal company environment, this condition is very difficult to attain; it requires dedicated
effort and time, but the final returns are: consolidation of the company's image and identity;
improvement in the effectiveness, and sinergy, in achieving the company's goals; reduction of
sterile intra-company conflicts.
3. Training Programme
3.1 Any project management training programme, be it company internal or company external (in a
recognized training centre or centre of learning) has to be properly structured and has a
recognized "curriculum". This section addresses the training problem in industry. There is no
single training programme that can adequately address the differing requirements of thousands
of companies in the various industrial sectors. Therefore the Project Management training
234
programme should be customized and structured in accordance to individual company
requirements and in accordance with the level. the mix and the number of "resources" involved.
3.2 All courses and seminars in the programme should attempt to bring together good theory and
good practice. To make the ambient more interesting and stimulating for the participants and to
allow better comprehension. understanding and application of the concepts illustrated. modem
inter-active educational techniques should be used; case studies should be included (both actual
and simulated); group and open discussions should be planned. The use of computer-aided
education (CAE) tools using personal computers should be examined. At the very least the
software product to be used in the work environment should be employed as a training tool.
Also. the trainers should be selected early in the process in order that they can give the
maximum contribution; they should be educated if necessary and the use of external resources
should be given healthy consideration. (They can educate the educators). The company's
management should have the following prime objectives for their training programme:
- promote the diffusion of a common project management culture at all levels;
- create across the board awareness of project management problems typical to the company's
business;
- provide training in project management techniques;
- provide training and instruction in the optimal use of the P.M. Infonnation System and the
selected project management software package.
3.3 The training process should be in the fonn of a structured programme of Seminars and courses
which include:
- introductory and awareness seminars for management and key professionals in the basic
concepts of Project Management;
- round table discussions to identify. debate and interiorize specific problems;
- specialized training courses on methods and techniques of planning. scheduling. control. and
decision making;
- instruction in the use of in-house Project Management manuals and the relative
organizational procedures;
- training and instruction in the optimal use of information systems and Project Management
application packages.
4. Training Programme Recommendations
4.1 After a diagnostic assessment of the particular requirements. with the aid of key user resources
(in order to obtain positive feedback) the training programme should be addressed, in general.
235
to senior managers, key managers and professionals, specialists and computer operators. These
resources will form the basis of the company's project management services and will be the
driving force behind a continued effort to put into practice the methods and techniques of
integrated project management on all projects, and to inform all related areas of competence.
With this in mind, the following structured programme of interactive seminars and courses is
proposed:
a) project management seminar using a project model simulator (Avots Project Simulator)
covering all areas of Project Management, addressed to management and key professionals
and customized to the level and the requirement (introductory or in depth) with durations of
2, 3 or 5 days.
b) Seminar on the organizational and behavioural aspects of the Project management process in
the form of a workshop or round table discussions to create awareness of the company's
particular requirements. (Duration 1 or 2 days).
c) Seminar on the development of the human resources operating in the project environment, in
the form of round table discussions to identify problem areas and to delineate methods of
professional development for skills which are particularly critical. (lor 2 days).
d) Specialist Seminar on project planning and control structures (ABS, CBS, CWBS, OBS,
PBS, RBS, WBS) which define the approach, the application and the use of these
information structures and which are the basis of project planning and control (2 or 3 days);
e) Specialist Seminar on the most common and useful methods and techniques (CPM/PERT,
Rolling Wave, Earned Value, Performance Mesurement) and which derme their optimal use.
(3 or 4 days).
1) Customized seminars for the instruction in the use of manuals, procedures, per~nalized
Project Management software and application packages, etc. which must be defined on an
ad-hoc basis; addressed to specialists, key professionals and operators, with the objective of
providing in-depth knowledge of those parts of the Project Management System in the
defined areas of responsability of the participants.
4.2 All of the above could be combined into lengthier courses from say 20-25 days to up to 6
months. The former aimed at planning and control personnel already with some experience. The
latter, aimed at inexperienced personnel, would incorporate a number of modules of
"classroom" training and at least 20% of the period in an industrial environment. Table 1 shows
a suggested outline of a course actually developed by the author.
236
COMPUTER-AIDED PROJECf MANAGEMENT TRAINING FOR NEWLY QUALIFIED
ENGINEERS AND TECHNICIANS
This course would be aimed at newly graduated engineers and is organied into 11 modules of
theoretical and pratical computer-aided training in the classroom. with a duration of 100 days, plus a
25 day stage of hands-on experience in selected engineering and construction companies. The
theoretical and practical training modules are:
A. Introduction to the business environment 2 days
B. Introduction to business planning and control 3 days
C. Introduction to Information Systems 5 days
D. Projects, composition, types 5 days

E. Introduction to Project Management 5 days
F. Organizational structures for Project Management 5 days
G. Project Management methods and techniques

(incl. case studies) 20 days
H. Project Management Information systems (PMIS) 5 days
I. Computer Tools: Project Management Software 25 days
J. hnpact of PMIS on other Information Systems 20 days
K. The Project Management function within the organization 5 days
Table 1: Suggested Course Outline
237
MANAGEMENT OF INTERESTED PARTIES
Juhani Silvasti
Abstract
Interested parties have to be taken into account in Project Management. How it should be done is the
key question. In the article there is described one method based on the known analyzing and planning
methods. The overall objective of the article is how to manage interested parties.
1. Introduction
The task of the project management can be defined, for example, as follows: To achieve the technical,
schedule and economical goals and deadlines in a certain environment with the help of human
resources. Until now the technical, time schedule, economical and organizational aspects have been
dominating in Project Management. The project environment including the interested parties have
very often been considered as risks, which can cause delays, additional work and additional costs. But
the fact is that the interested parties can support the project execution very strongly, if they are
handled in the right way. This paper describes one method of how this can be done.
2. Interested Parties
For managing the interested parties, the first thing to remember is that you know them. You can start
by listing all the parties which can be involved in the project. You can group them, for example, into
internal and external parties. Internal means interested parties within or close to the company and
external ones are those outside the company. Below - as an example - is a list of typical interested
parties:
futernal futerested Parties:
- owners of the company
- top management
- line functions, such as marketing, production, maintenance, etc.
- quality assurance organization
- safety organization
- internal personnel groups
- workers
- representatives of trade unions
- reference groups
- other projects.
EXTERNAL
Figure 1 INTERESTED PARTIES
External futerested Parties:

- authorities of various sections, like construction, social, import/export, taxation, work safety,
labour, environment, etc.
- financing sources, like banks, stock holders, public finance, etc.
- the press
- politicians
- trade unions
- church
- competitors
- suppliers
- co-operative parties
- families of the personnel
240
Depending on the project, the country and the culture, the list can be quite different. An important
thing is to list the interested parties which can have a certain impact on the execution of the project.
Those authorities for which power is based on laws and regulations are always included for example
the financing organizations. The others are underestimated. After listing the interested parties, you can
strike out the less important ones. But be careful, don't underestimate anyone. You can also favour
them according to the support needed for the project or according to the effect, when someone is
against the project execution.
3. Objectives and Values
As for a negotiation, it is easier to develop the right strategy if you have as much as possible
information about the other party, in this case about the interested parties. The next step is to gather
information about the important ones.
One thing to be clarified is what the objectives of an interested party are. Which are the general
objectives and which are the objectives and expectations particular to the project in question. For
example, concerning a modernization project of an industrial plant, the objectives of the owner and
the top management can be to lower production costs. The production organization expects that the
plant will easier be operated. Quality people want to produce higher quality products. Workers want
to have better working conditions and perhaps higher salaries. The general objective of the trade union
can be higher employment. Some of these objectives can be conflicting with each others.
PROJECT
Figure 2
OBJECTIVES
241
The other thing to be clarified are the values of the interested parties. Objectives and values are
connected in some way. But there are many values which are not so visible, which are perhaps more
personal. These may concern family life, environment, intellectuality etc.•
When the interested party is a group of people, there are values on two levels. The group has common
values and additionally each member has his/her own individual values.
One thing to be remembered is that verY often among interested parties there are key persons who
have strong opinions of their own and who are some kind of leaders within their groups. It is
important to identify these "leaders", because if you want to manage an interested party you have to
take into account his or her personal objectives and values.
This information about objectives and values is a basis for a successful management of interested
parties. It enables you to predict how an interested party may react to the project and its results. If the
objectives of an interested party and those of the project are parallel, it is very likely that the project
will be supported by the interested party in question. If the objectives are contrary to each other, you
can expect difficulties, in the case the interested party has the power to influence the project
execution. Doing this you will find out the most likely friends and enemies of the project.
4. SWOT-Analysis
For getting a better idea of how to prepare the right management strategy, it is useful to make a
SWOT (strength, weaknesses, opportunities, threats) analysis. It means that you determine which are
the strengths and weaknesses of the most important interested parties as well as which are the
opportunities and threats of your project related to interested parties. Mostly there are both,
opportunities and threats related to each party. After identifying these, you must decide whicp. of them
are essential with regard to the project and concentrate on those.
....
OPPORTUNITIES i'HREATS
SWOT ANALYSE
Figure 3
242
Another series of SWOT analyses is evaluating which are the strong and weak points of your project
with regard to each interested party, as well as which opportunities and threats it offers each of them.
Doing this will give you a very wide understanding of the relations between your project and the
interested parties.
5. Strategy for Managing Interested Parties
After doing the SWOT analysis you have a list of each interested party's strengths and weaknesses as
well as a list of opportunities and threats you have related to them. When you develop your strategy,
you must concentrate on those opportunities and threats which are the most critical ones concerning a
successful project execution. Which of them are critical depends on how powerful the interested party
is in general and how strong the party is in the area where you see some opportunities or threats.
~mENGHTS
PPPORTUNITIES THREATS ~
~ <1-
O<i- ~
~
I~V I~~
STRATEGY
Figure 4
It is easy to develop strategies after you have favoured opportunities and threats. You decide which
opportunities you want to exploit, and which threats you have to ward off. Your strategy will be a list
of opportunities to be exploited and threats to be warded off. The list can be organized by interested
parties.
243
6. Management Plan
The most difficult part is to develop an action plan, a management plan how to handle interested
parties. The questions to be answered are:
- how the opportunities given by an interested party are exploited
- how the threats caused by an interested party are warded off
- how the opportunities given by the project to an interested party are taken into account
- how the threats caused by the project to an interested party are handled
The action plan, like the other project plans consists of a number of activities. But it is very important
how the activities are executed. In this kind of management plan there are a lot of activities where you
give information about the project. The way you give information is often decisive how the interested
party reacts and whether you will achieve the objectives laid down or not.
Each meeting where you give information has to be planned carefully, starting from the defmition of
the target group. Then you describe their general objectives and values and finally their expectations
and objectives concerning the project in question.
Based on the definitions above and the project situation, the things to be informed are defined as well
as objectives of the meeting. Then the way the things will be informed is planned. One must be sure to
pay enough attention to this phase of the preparation work. The first thing is that the same language as
the target group uses is also used in giving the information. The second thing to remember are the
objectives and values of the target group. If you can appeal to them and prove that the objectives of
the project are not conflicting with them you have better possibilities to get the target group's support
to the project. The way to inform is most critical when the target group is the interested party which
forms the biggest threat to the project.
The management of interested parties has mostly to communicate with them, inform them, and listen
to their opinions. Also some other ways exist to manage them. Sometimes it is possible to activate
them to work for the project You can ask them for example to make suggestions or statements
concerning some details of the project. You can also organize a working group, where they participate
in finding out solutions to problems they are interested in.
The management plan of interested parties consists mainly of information activities. In addition to
these, there can be required approvals, statements or suggestions, but there can also be active
participation in the project execution. Whatever the activities are, they have to be planned separately
for each of the interested parties. This refers especially to the way the actvity will be executed. Also
all kinds of preparation work of meetings participated by interested parties have to be planned. There
should also be a responsibility for each activity of this management plan.
244
ACTION PLAN
Figure 5
This action plan is like the other project plans. It defmes what will be done, why and how, who will
do it and when, and what the expected output from the activity is.
7. Conclusions
Management of an interested party is the ability to regulate and control interaction between the project
and an interested party so that it promotes the achievement of project goals. This interaction has to be
planned carefully. To be able to do that you must know your interested parties well. You must know
what kinds of opportunities and threats there are, what are their values and their expectations
concerning the project. Success depends mainly on the way how the interaction activities are
executed. Paying more attention to the interested parties you will fmd out that there is a lot of epergy,
which can positively support the achievement of the project goals. An interested party can be more a
resource for the project than a risk.
245
CO-DEVELOPMENT
A FUTURE FOR INTER-OROANIZATIONAL PRODUCT AND PROJECT
DEVELOPMENT
Alex van den Honert, Rieks Broersma
Abstract
Co-developing, or more often called Comakership, is fastly becoming a new way of inter company
cooperation. This form of cooperation distinguishes itself from other forms, like acquisition!
merging/joint ventures/strategic alliances/normal contracting etc., in that a longterm relationship is
aimed at. When embarking on a comakership relation it always concerns the relation between the
principal (maincontractor) and the suppliers. Co-developing seems to be one of the answers to cope
with global competition because it enhances product/market flexibility, lowers developing costs and
has strong potential for better quality.
This article will provide some insight into what co-development means and what areas are of interest,
when to go for it, what the consequences are for Project Management and participating organizations
(both pros and cons), and some trends observed. Some general remarks will be made in a more global
perspective, existing differences between eastern and western oriented cultures will be observed.
1. Definition and Scope
Although many articles have recently been written on the subject of comakership and many writers
have tried to find a good single definition, the issue in principal handles developments in the relations
between principals/main contractors and their suppliers/subcontractors. In the following text the
expression "principal-supplier relations" will be used.
When establishing the so-called comakership relation, however, it always means that a principal, and
of course his supplier, are aiming for along term cooperation with the objective to benefit both.
One is willing to invest in each others operations to reach the common objectives. It will be clear that,
in doing so, principals will restrict the suppliers of a certain commodity to one or at least a few.
Interdependency of course increases, so does the need for openness and trust.
The field of interest in comaking reaches into the main areas of manufacturing and product
development. Although these areas are finnly linked, this article will focus on mainly product/project
development being the most interesting for the Project Management profession.
2. Why Comaking
National, international and global competition is generally increasing. The world becomes smaller
through improved means of communication and transportation. Clients are becoming more clever and
critical and are demanding better quality, up-to-date technology and more functionality in products
and services.
Among other reasons, companies have been reconsidering their main objectives, their strength and
weaknesses, and their possibilities in geographically growing markets in an increasingly complex
world. One of the answers is to do things you are really good in. Or in today's jargon, going back to
"core business". This automatically meant that management started reconsidering its former make or
buy policies. Logically, in favor of subcontracting more work and products to suppliers.
The development of globally increased demand of quality and technological innovation sparked a new
way of looking at suppliers however. How to assure that supplier deliveries of either know-how or
products/services meet requirements and are, last but not least, in time? And at the same time reduce
operating, in this case product-developments costs and risks? Suppliers also started to think on how to
assure continuity in a world of higher principal requirements and increasing dependenay on the
principal-supplier relationships. Both parties in the game started to think how to get better together
and deliver better poducts to their clients.
This whole set of objectives sparked off the development of comakership, first in Japan and now at
full speed anywhere. It will most probably set the stage for the coming decade, at least in the area of
high technology and fast-changing services.
When you have identified problems and main objectives the direction of improvement is often clear.
The road to get there is difficult and time consuming. Before going into the application of
product/project development, i.e. project management, areas of organizational change are identified:
* Open up each others organizations, also showing weaknesses, in order to correct mistakes in
time. This is beneficial for both parties. Prevent rather than correct.
* Go from product to process assurance. Thus be able to abolish outgoing and incoming quality
control efforts and discussions on penalties.
* Cut down on costly bargaining with (too) many suppliers.
248
* Coordinate development processes in relevant project development phases.
* Share markets and risks collectively.
* Coordinate planning.
* Decide collectively on technology.
* Respect each others profit objectives.
* Share relevant information.
* Etc..
3. Management Areas
3.1 Introduction
Comakership revolves around three main issues:

* Product/project development
* Quality improvement
* Logistics.
Within the scope of this contribution we will look· mainly at the first item, running development
projects within a comakership setting. The issue of quality will however be incorpomted as far as it
concerns the quality of the project management process.
Two areas here are of interest:
* Development of investment projects.
* Development of (consumer) products.
Although many differences may be pointed out, they will be treated identically since they have much
more in common as well, and in many ways.
3.2 Phasing
One of the most difficult issues of product development in a principal supplier relationship is to
synchronize the project life cycles and relevant interfaces. Especially so if the supplier is working for
more than one principal. We will go through the different main project development phases in the
principal and supplier organizations, using figure 1, and discuss shortly the interfaces.
Figure I illustrates, just as an example of complicating factors when collectively developing in a
comakership setting, that principal and supplier life cycles phases are out-of-phase. ~owing the
problems encountered already within one company, it will be clear that phasing is important to
coordinate. The indicated phases 0 through 5 will be discussed below:
249
Phase 0: Product and market orientation.
Generally principal and supplier will have to be in phase when discussing and deciding upon new
markets and products. At least when the principal is relying on the supplier's own innovating
capabilities. A collective decision is taken to start developments.
Phase 1: Product definition.

The principal's definition phase will take more time, due to more complexity and integrating problems
and the necessity to have exclusive information on the suppliers subsystem/component possible
performances in order to take a decision. The supplier will have to provide input to the principal's
definition phase process. Generally there are more "know-how" suppliers for the principal to cope
with.
supa ! J
2
JJ
3/4/5
j
Principal I)
----
2 3 4/5 Users
01 1 I
Figure I: Principal-supplier life cycle and interfaces.
Phase 2: Development and engineering.

The development phases of the principal need early evidence from suppliers that supplier
developments are feasible. Otherwise the principal can not proceed effectively. This means that
supplier development is preferably ahead of the principal's.
Phase 3: Manufacturing preparation.

At the principal's company it might be a separate phase, at the supplier's it may be integrated with the
manufacturing start up.
As observed in practice, higher levels in the business structure ask for more project development
phases. Anyway, the principal will ask for products during the manufacturing preparation phase to test
out its own manufacturing processes. Thus manufacturing and delivery should start earlier at the
supplier premisses.
250
Phase 4/5: Manufacturing/delivery.
The principal's manufacturing process, in high measure governed by its logistics, needs suppliers
goods and know-how well in advance. And of course during the entire sales and manufacturing life
cycle.
In-time delivery is of course essential, being .the art of logistics management, but not part of the scope
of this contribution.
Important for the development project is to plan for the end-of-life decision. They are out-of-phase as
well and ask for special measures which are project oriented.
3.3 Product Development Quality
This is where process quality comes in. Very essential for comakership relations. The process here is
nothing else than to assure good project management practices. The question here is "how good is the
development projects run and how can it be assured as being professional up to current standards?"
When looking at the project life cycles in figure 1, the quality issue has to be subdivided into two
aspects:
1: The quality of the product/market assessment and resulting product definitions.
2: The assurance that developments and operationalizations will be performed according to plans
agreed upon in the orientation and definition phases.
A short vision on how both aspects can be controlled is elaborated below.
1: How does one assure a good product development plan in a principal-supplier relation?
The answer is both standard and complicated by the comakership approach. First of all the assurance
in this project phase can only be obtained by observing how the information on clients and future user
categories was obtained. Identifying user categories is a first step. These should be:
* The end users, i.e. those who are actually "buying" the future product/service. From the
principal and from the supplier.
* The "system users". These people are those who are confronted with the product during the
entire product life cycle but are not buying the product. The operational functions. They may be
sales, maintenance, packaging, transportation, manufacturing, etc.. They also need to have their
influence, both in the principal and in the supplier organization.
* The "once-only-users" of the plan. These are the development, engineering,
manufacturing/maintenance/sales/documentation preparation people. They have acquired skills
which also should be heard.
251
* The last group being of importance consists of those who never really involved in the project
directly. They are the outside stakeholders, either politically or through the internal powergame.
They should be found and heard.
2: How to 8&'iure conformity to agreed plans and actions?

When plans are made and well communicated to project related employees, the art of quality
assurance is to have a system where employees assure to the project management that they do or did
their job according to agreements. They concern both product requirements as well as planning, costs
and organizational commitments and infonnation rules. Between principal and supplier this asks for
open communication and trust in order to reach common goals.
4. Organizational and Cultural Consequences
The above may sound as an approach of "good for everybody". Implementing the ideas is something
else. Both for the principal and for the suppliers. In this article a choice is made between the following
aspects:
1: Fitness to embark on co-development/co-makership
2: Structural!proceduraV organizational adaptations
3: Cultural barriers
4: Change process.
Since all aspects are interrelated, this is no easy task to be undertaken by the principal and supplier
management. Using figure 2, the above four points will be analyzed more closely.
Structure
/i~
·~T/·~~re
Fitness
Figure 2: •
Change
252
1: Fitness for co-development
First the strategic desirability should be established, i.e. the longer tenn objectives for both parties
will have to be made clear. Items are:
* market developments
* opportunities and threats
* organizational developments
* environmental developments
* future make or buy policies
* what is the real core business
* etc..
The next one should assess what the current principal-supplier relations are per supplier. Steps of
increasing involvement are:
* buying the cheapest products
* prefered suppliers
* a few, fixed suppliers
* full fledged co-development/comakership.
Eventually it should be considered what steps could be taken. How fast things can be improved and in
what areas. Such as:
* development of needed technological skills
* improvement of project management practices
* creating mutual trust and organizational openness
* improve inter company communication and infonnation flows
* etc..
2: Structural/procedural/organizational adaptations
Going for co-development will ask for organizational change. Things to look at are:
* is the sitting management fit for the job?
* the role and function of purchasing
* the level of project managers/changing authority
* project procedures
* legal/contracting skills
* improving product development reliability
* adapting quality assurance process
* etc ..
253
3: Cultural barriers
Without going into any detail here, it can be stated that organizational cultures are very hard to
change. Analyzing them is absolutely necessary in order to assess the possiblities for change. Some
typical (sub) cultures are:
* hierarchicallbureaucratic culture
* developmentfmnovative culture
* rationaVformal culture
* grouprmformal culture.
When starting to work more closely together, as it is the case in co-development processes, different
cultures will clash and prevent to reach set objectives. If problems arise, employees within the
different organizations will increasingly stick to "the way we always did it".
4: Change process
Before deciding to enter, or significantly improve a co-makership relation, a short term and long term
strategic implementation plan should have been made. It is strongly advised to consider the
organizational change as a project as well. Normal project management skills and techniques can be
applied such as phasing, planning, cost control. And last but not least, quality assurance.
To reach a co-makership relation the organizations have to go through a radical change process i.e. a
transition process. In such a transition process the role of the management is crucial and a stepwise
approach is necessary to succeed. Important phases of the change process are:
showing the necessity of change
creating the vision/direction
reaching the commitment
the institutionalization of the change in details.
5. Pros and Cons
As the most important pros of a co-development relationship can be mentioned:

exploitation of the most advanced technological know-how of the (specialized) supplier
growing effectiveness and effectiveness during the development (design) phase, so reducing
lead time
faster introduction of new developments to the market
reduction of development costs up to 10-30 percent
strong improvement of quality of organization process and product
long term relationship for the supplier and a trustable supplier for the principal.
254
Of course there are cons of a co-development relationship to be mentioned. Some of them are:
the dependence of the supplier is increasing
limitation to select other technologies
possibility that the supplier gets dominant
6. Trends
By the growing pressure of competition, especially from the Far East, the demand of the market of
new modern technologies and functionality of the products and services we see different kinds of c0-
operation. This co-operation can be focussed on several phases of the life cycle of the product/service.
Each kind of co-operation has its own terms and goals. Strategic alliances, co-development, co-
makership and value-adding partnerships are examples.
7. Concluding remarks
As mentioned before (competition, market demands, etc.) principals are looking for ways to improve
the performances of the product and their own conduct of business. One of the possibilities is the start
of co-operations with suppliers especially in the development phases of products and services, so
called co-development.
Results of co-development are:
cost reduction of the development phase to 10-30 percent
reduction of the lead time of the development phase to 30-50 percent
higher level of innovation
use of modern technologies in the product
increasing quality of product and (project) organization
improvement of flexibility in both organizations
The origin country of these evolutions in the area of co-operation is Japan.

Conditions to succeed are to handle the right project management philosophy, the correct phasing and
interfaces, and the right turning between principal and suppliers. In general one can say that this
demands important organizational changes at principal and suppliers to more open and flexibel
organizational structures. Also the culture of both organizations is changing.
255
References
Bridges, W.: Making Sense of Life's Transitions, New York 1980.

Hill, W., Fehlbaum, R., Ulrich, P.: Ziele, Instrumente und Bedingungen der Organisation Sozialer
Systeme, Bern/Stuttgart 1976.
Mintzberg, H.: The Structuring of Organizations, New Jersey 1979.
256
THE KEY ROLE OF THE CLIENT OR OWNER IN THE
MANAGEMENT OF CONSTRUCTION PROJECTS
E. Geoffrey Trimble
1. Introduction
Traditionally the owner (or client) has been separated from the project and has controlled it at arm's
length. Clients in the process industries engage design contractors, civil engineer clients engage a
design consultant; building clients engage an architect, usually two or more engineering consultants
and, in the UK, a quantity surveyor. There has been a tendency for the client to stand aloof and let his
advisers get on with the project. This has had an adverse effect on efficiency for a number of inter-
related reasons. These show themselves in inadequacy in one or more of the following areas:
- Clarity of economic objectives
- Selection of procurement method
- Management of design and quality
- Use of new technology
- Control of cost and time
- Contstructability
- Mutual understanding.
These factors are discussed in Section 2 of this paper. Section 3 describes the steps that are 'being
taken in setting up the European Construction Institute as a means of improving the position and
Section 4, entitled "The Way Ahead", suggests ways in which this institute is likely to develop.
2. Areas of Interaction
2.1 Economic Objectives
Much has been said in recent years abqut "life cycle costing". Essentially this is a procedure for
looking at a project during its full life and making decisions about it that achieve the minimum total
cost allowing appropriately for the cost of servicing capital. There have been some obvious failures to
apply these principles of which the inadequate allowance for the cost of de-commissioning nuclear
power stations is the most striking. The more sophisticated project advisers may take it as axiomatic
that the client will want a solution that minimizes the life-time cost. But this may not be the case. A
developer for example may assess the attitude of prospective purchasers and decide that simply
minimizing the capital cost is the best strategy. Industrial clients may be tight for cash so they too may
seek to minimize capital expenditure.
For building projects there will usually be two separate advisers whose work affects the economy of
design, namely a quantity surveyor (or cost consultant) and a designer. The client must take active
steps to ensure that they are working together in a way that reflects his particular economic objectives.
2.2 Procurement Methods
Various contractual procedures are available to the client including traditional procedures, design and
build, fast track and various types of negotiation. Each has its own pros and cons and readers will be
aware that many public authorities favour a traditional approach, simply because it provides
accountability. (Many uneconomic decisions in the public sector can be attributed to this' approach
which often fails to take adequate account of the time value of the capitellock-up.)
Good advisers will alert the client to the alternatives available and to their merits. However an
effective client will wish to study the full implications and how they impinge on his own business
strategy.
2.3 Management of Design and Quality
Although project management is well understood in relation to physical processes the management of
design is more difficult. One of the problems is that a protracted analysis of a possible design solution
may show it to be inappropriate so the designers must go back to an earlier stage and start again.
Control of quality too is well understood in relation to the physical artefact but quality starts with the
design process and the quality of the design and adminstration procedures also need to be controlled.
258
Although the client. in theory, can prepare a brief and let his advisers work to it he will often wish to
review this brief when he sees the first candidate solutions.
The client in this way is part of the naturally interactive nature of the design process. The quality of
his administration will affect the quality of the total project
2.4 Use of New Technology
New technology will be exploited both in the fmal product and in the process of designing that
product The fonner will include such items as the technology of oil refineries, chemical plants, power
stations etc. and to a lesser extent the technology of buildings and the building process. This topic is
obviously very wide and outside the scope of this paper.
The technology of the design process however has more universal application and the words
Computer Aided Design are well-known but not always adequately understood. CAD can be a
considerable aid in the preparation of accurate drawings and in deriving related data e.g. material lists.
When 3D (three dimensional) software is adopted, CAD can be a powerful tool in avoiding fouls and
mismatches. Had it been used in the early stages of North Sea Oil developments hundreds of millions
of pounds could have saved.
Where the technology of the end product is more sophisticated the client is usually more involved. In
general, his greater involvement not only in the decisions about the final product but also in the design
process, the greater will be the efficiency of the total process.
2.5 Control of Cost and Time
Clients often fail to realize the extent to which their decisions during the development of a project
affect the final outcome. For example when the client changes his objectives and detailed decisions
about a project on which physical work has started, the consequences can be extremely serious. A
good contractor will plan his work carefully in such a way as to use his resources efficiently. When
his plan is disrupted by changes of design this will often have the effect of causing delay to the
completion date and serious repercussions in the use of resources. The client will then be faced with
additional construction costs often in the fonn of claims which are only settled by arbitration or
litigation.
Some changes are inevitable. Some indeed are economical. The main point is that client should be
aware of the consequences of any change he proposes and should only proceed with the change if he
is prepared to live with those consequences.
259
2.6 Constructability
When there is inadequate communication between the designer and the builder the designs are often
unnecessarily difficult and expensive to build. The client, or his design consultant, if aware of the
construction problems could often choose alternative designs which would be much easier to
construct. There may even be cases where the contractor has specialist plant available which could be
brought in to deal with difficult construction situations. When there is mutual understanding between
the designer and the builder it is usually possible to develop designs which are easily built and
consequently economic.
2.7 Mutual Understanding and Involvement
No construction project can proceed without the client. But his involvement can be greater or less in
various respects as shown in the foregoing sub-sections. There is growing recognition that the client's
greater understanding of the decisions and actions taken on his behalf by his consultants and
contractors, will help to promote greater efficiency. His direct involvement in the construction process
undertaken in the light of this understanding must be the ultimate objective.
3. The European Construction Institute
In the period from mid 1989 to the Winter of 89/90 steps have been taken to establish an Institute
which will study the factors listed in Section 2 and take positive action to implement any findings that
are judged as promoting greater efficiency. Unlike existing research organizations ECI will taken its
lead from the identified needs of clients of the industry. The research will be directed by the members
themselves through task forces set up for the purpose. Thus the fact of undertaking the research will
sell its merits to the potential users. At the time of writing (June 1990) the following organizations had
joined the Institute:
Babcock Energy Ltd. John Brown pIc

Balfort Beatty ICI Engineering
Bechtel Highpoint pIc
British Gas George Corderoy & Co
British Petroleum MW Kellog Ltd
Brown & Root (UK) Ltd National Power
ceo Contracting NECEA
Chevron UK Ltd Northcrofts International
260
Colin Draycott Group Nuclear Electric
Conder Group Technical Powergen
DarchemLtd Shell International Petroleum
Davis Langdom & Everest Shell UK Ltd
Davy McKee (London) Ltd Stone & Webster Engineering Ltd
Du Pont de Nemours-BV Taylor Woodrow Construction Ltd
Electrical Contractors'Association Technip (paris) S.A.
Fluor Daniel pIc Texaco Ltd
Foster Wheeler Energy Ltd Try Group pIc
GEe Alsthom Engineering systems Ltd Wimpey Engineering Ltd
Major organizations will contribute £5.000 p.a. to the work of the institute and smaller ones
£2.500p.a..
The ECI will comprise mainly clients of the construction industry and contractors. They will be drawn
from the process, building, and civil engineering sections of the industry. Membership will be open to
any organization with an interest in the efficiency of the contruction industry, including government
bodies. It will not engage in any political activities.
The ECI will have five main activities:
providing an international forum in which senior personnel can meet and exchange views;
commissioning and supervising specific research projects as subjects that will improve the
efficiency of the industry;
communicating the results of these projects and information from other sources on technology and
management systems, to members;
assisting in the implementation of newly devised management techniques and procedures;
collaborating with other countries, notably the USA and Japan, when this is judged to be of benefit
to members.
It ist proposed that results of projects be confined to members so far as this is practical.
Meeting!! of the ECI will be held in a variety of locations throughout Europe, hosted by member
companies.
The priority topics for research will be decided by the membership. The work will be undertaken by
research contractors such as an university department, an industrial research company, or a
government department.
Some projects can be expected to have wide support from the membership and will be administered
by a "standard" procedure. Others may be proposed by a limited set of members and will be controlled
under a "specific" procedure. These procedures are now described.
261
Standard procedure:
A task force will be established comprising roughly equal numbers of client and contractor
representatives. This task force will formulate a specification for the project and seek bids
from research contractors. A contract will be placed but the task force will direct the work.
The cost of the contract will be bourne by the general funds of the Institute. The work: will be
closely monitored to ensure that the results are genuinely relevant to the needs of the
membership and essentially practical in their orientation. The results will be available to the
membership at large. Seminars will be run where appropriate to disseminate the results and
specific assistance will be provided in implementing new techniques and procedures that
result from the study.
This approach contrast with the more usual research situation in which an academic
institution performns the work on its own initiative and is then faced with the task of
persuading industry to adopt the results. These efforts often meet stiff resistance.
Specific procedure:
This procedure is designed to deal with projects that are supported by a few members who
may represent a particular sector of the industry. For example oil companies may support a
study of working conditions off shore but this is unlikely to interest building developers. The
supporting members will form a task force and they will be free to co-opt other members
who express interest in the project. The work will be funded by the supporting members in
equal or otherwise agreed proportions and the results will be confined to the supporting
members and to other members of the task force who have attended most of the meetings.
The Institute will include members from all European countries both EEC and EFTA members. It will
have an informal constitution initially; it is hoped to establish it later in Luxembourg as a company
limited by guarantee.
4. The Way Ahead
A pathfinder project has been started with a task force drawn from four of the members namely:
- BP International
- Technip SPA of Paris
- Davy McKee (London) Ltd
- Northcrofts International
The objectives are to assemble a list of initial project topics in order of precedence and priority. These
are expected to reflect some of the areas discussed in Section 2, but will undoubtedly include some
262
short term urgent items particularly where the task force judges these as not duplicating work by other
bodies.
Once the Institute is operating on a self-financing basis, funds will be sought for major longer term
research from statutory funding bodies such as EEC and SERC. Evidence suggests that an application
made by an university jointly with an industrial partuer has much greater chance of success than a
separate academic application. For this reason the Institute is likely to exert "leverage" i.e. to enhance
substantially the funds subscribed by its members.
It seems likely that projects funded in this way will include some of the technological challenges such
as:
* The use of expert systems as an aid in management and decision making.
* The development and economic exploitation of intelligent buildings.
* The analysis and effective management of risk.
* The genuine use of computers in the design process.
On the last of these points arrangements are already in hand for a workshop to be held in Antibes,
France in 1991. This will bring together the leading authorities in the application of expert systems in
design with the researchers who are exploring the basic nature of design and the human process of
innovation.
In addition to its role in promoting and undertaking research the Institute will provide a new channel
of communication between client, designer and contractor. This will occur in an informal way and
will therefore not be restricted by legalistic protectionism.
It is intended that ECI will operate on a Europe-wide basis either as one supranational body or as a
federation of national bodies. Either of these formats will promote studies of the differing project
procedures which are found in Europe. These studies will provide a means of evaluating the
procedures and of highlighting objectively those features that are most efficient. It does not follow
that changes will occur rapidly thereafter as the nationally preferred procedures are deeply embedded
in the culture of each country. However the identification of the contrasting features and their
strengths and weaknesses will, no doubt, facilitate moves towards a more cohesive approach in
Europe generally and will then promote the objectives of co-operative international commencement.
263
ROLE OF SENIOR MANAGEMENT IN DEVELOPMENTAL
PROJECTS
Bob Gillis
1. Introduction
What role should top and senior management play in developmental projects? What organizational
vehicles are appropriate for his role? What impact can a 'steering' group have on successful execution
of a project?
The author explores the significance of senior management participation in front end planning and in
the implementation of major projects.
2. The Steering Group
A steering group consists of senior people assigned by the owner or by the top management of an
organization to oversee the successful initiation and execution of a project.
Not every project requires a steering group as such. For some types of project it is sufficient to have a
member of senior management act as a mentor for the project and plays the role similar to that of a
steering group.
IIIIIII~ ROLE OF THE STEERING GROUP
FRONT END PLANNING TASKS

• Define The Owner's Overall Goals
L • Evaluate The Major Business Risks
E • Develop the Funding Strategy
A
• Develop the Project Organization
D
E • Develop the Project Manager's Mandate
R IMPLEMENTATION TASKS
S • Select the Project Manager
H • Provide Access to Resources And Power
I • Monitor The Progress of The Project
p
• Monitor The External Environment
• Resolve Major Conflicts and Problems
Figure 1
2.1 When Required
A steering group should be assigned for one or more of these conditions:

o the project has a potential for major impact on the survival or economic success of the
organization
o the project ties up a major part of the resources of the organization for a long period of time
o the project is innovative: a major departure from current practice involves or affeets several
organizations or departments
o there are major business, environmental or social risks associated with the project.
2.2 Make Up of the Steering Group
The group is generally selected for one or more of these reasons:

o they have knowledge and experience in the subject
o they have authority over resources
o they represent people affected by the project
o they must carry out the project.
266
The steering group generally includes:
o a senior manager assigned as project sponsor
o heads of functional departments or cooperating organizations who must assign resources to the
project or perform part of the work
o specialists who have a particular expertise in the contents
o people responsible for funding approval
o the project leader or the leader for a particular phase of the project.
The group may also include representatives of other key stakeholders such as government, special
interest groups, unions, operators.
3. Planning Tasks of the Steering Group
The outputs or information products of front end planning by the steering group will vary somewhat
with the scale and complexity of the project and the management style of the organization. The
following are suggested guidelines for a useful front end (or start-up) planning effort by the steering
group.
3.1 Define the Owner's Overall Goals (purpose)
(Key words: Goals, objectives, needs, scope, requirements, direction, benefits, priorities, background,
rationale, time window, phasing, spin-off benefits, related projects).
The first requirement is to establish a clear direction: What is the vision? What is the purpQse of
undertaking the project? What will be created? What are the expected benefits? What are the success
criteria? What are the time constraints? What are the trade-off priorities among these? What are the
overall business objectives of the project? These should be stated in terms of specific achievement
targets: what is to be done and in what time frame?
This section should not be done casually or written up by a planner for approval by the management
team. The creative participation process should create not just a written description of purpose and
scope, but also a deeply felt, shared understanding of what is to be done and why. The outputs of this
section include:
o background information - how the project developed? What has been done previously?
o hierarchy of goals and objectives
o potentially conflicting views on the purpose of the project
o a shared view of the roles of the department heads and other key people vis a vis the project
o success criteria and trade-off priorities.
267
3.2 Identify the Major Constraints and Buisiness Risks
(Key words: assumptions, problems, resource constraints, policy constraints, political constraints, risk
management, evaluation, ecological impact, social impact, contingency plans, stakeholders, risk
sharing).
''We were too busy killing the alligators to get around to draining the swamp." Since this is a universal
problem, familiar to every project manager, we can think of this part of front end planning as
allegorical alligator hunt: First you find the alligators and then you decide how to deal with each one.
Unfortunately, each hunter can see only the type of alligator that he has been trained, by his
experience to identify. Thus the financier perceives the financial concerns, the technician sees the
technical problems, the manager sees the management risks, the personnel expert sees the social
problems, the politician sees the political dangers and so on. Often it is a combination of these
allegorical alligators that can cause serious harm or even disaster to the project. TI at is why risk
evaluation should be an open, participative forum. Some of the output of this section include:
analysis of stakeholders, objectives
- risk evaluation and risk management strategies
analysis of constraint and problem areas
analysis of solution strategies.
3.3 Developing the Funding Strategy
(Key words: funding sources, cash flow requirements, bridge financing, financing methods).
There is a wide variation in the funding methods for projects. For many large organizati9ns, the
funding is primarily the concern of the financial department, which require cash flow projections for
each project. In these cases, the timing of the project or even the feasibility assessment may be
affected by the relative priority of competing cash requirements and the cost of financing.
For large R&D projects or other projects which have a mixture of public and private financing and a
complex mixture of equity, debt and grants, the development and application of a workable funding
strategy is a critical activity which controls the timing and the viability of the project. In these case the
funding phase of a project may take months or years, and the project may require a special type of
leadership talent during this phase.
Feasibility studies for this type of project are usually very expensive and often require the
participation of highly specialized experts whose availability is limited. There is often a catch-22
situation: the funding will not be approved by the funding agencies without a thorough feasibility
analysis, and the analysis cannot be made without substantial preliminary funding. In such cases the
funding for the feasibility developments may depend on public or private grants.
Resolving these problems may be major concern and time commitments for the steering group.
268
3.4 Develop the Funding Strategy
(Key words: leadership, organization structure, management style, personnel, contracting policy,
responsibilities, authority, communication, definitions, assumptions, coordination)
This section is concerned with the identification and organization of the human resources required to
carry out the project. The outputs may include:
o the general strategy for carrying out the project (e.g. internal vs contracted resources)
o the overall organizational and communication structure
o the specification of roles and authority relationships
o the specification of a management style and control philosophy for the project
o the mandate of the Project Manager
o the selection of the Project Manager
o the policies and procedures for contracting and procurement.
3.5 Administration and Control Procedures and Policies
(Key words: systems, process, methods, administration, procedures, monitoring, control, measurement
of progress, communication, personnel administration, financial administration, contract administra-
tion, administrative services).
The Front End Plan should specify policy, standards and procedures such as:
o procedures required for progress reporting and control
o procedures for documentation and communication control
o external communication policies - public relations
o contracting and procurement administration policies and procedures
o personnel and financial administrative procedures identifed in enough detail to identify the
resources required to administer the project
o a procedure for identifying and resolving potential conflicts.
For many organizations these procedures are well documented and it is necessary only to refer to
internal policy standards.
269
4. Implementation Tasks of the Steering Group
4.1 Select the Project Manager
The steering group generally selects the project manager and develops his mandate: they define the
goals and objectives of the project and define his authority and responsibility. For large complex
projects different leadership style and skills may be required for different phases of the project.
The criteria for selection of the project manager for a particular phase should be identified and the
candidates evaluated against these criteria.
4.2 Provide Access to Power and Resources
The steering group includes those people who have authority over the resources which will be
required to execute the project - e.g. heads of functional departments or other resource organizations.
The steering group must assure that the project leader has access to the skilled people and other
resource required to execute the process.
4.3 Monitoring the Progress of the Project
Having appointed the project manager, the steering group has a responsibility to monitor and evaluate
his performance. Monitoring and control procedures for carrying out this function should be included
in the mandate of the project manager.
4.4 Monitoring the External Environment and the Business Risks
Having identifed the critical assumptions and evaluated the major business risks the steering group
should monitor the external factors such as action of competitors, market trends and social, economic,
or political changes which affect the success of the project.
4.5 Resolve Major Conflicts and Crisis
There are problems which are outside the authority of the project manager to resolve. These include
disasters, internal competition for resources, developing technical issues which have a major impact
on cost or feasibility, action of competitors or suppliers, major economic or political changes, lack of
270
cooperation within the organization, or internal political problems. Resolution of these problems may
require changes in scope, cost or time and may even involve a judgement to implement contingency
measures developed during the planning process. The steering group may bear the responsibility for
confronting and resolving these critical problems which threaten the success of the project. These
measures may even include postponement or abandonment of the project.
5. Conclusions
5.1 Steering Group Establishes Direction and Control
A grain of foresight is worth a tonne of hindsight. Intensive planning, done at the right time, by the
right people, in the right way is the only way to reduce the risk of serious errors in overall direction.
The Steering Group approach can be an effective way for senior management to establish the
direction and control the course of developmental projects.
5.2 Building Teamwork is Essential
Teamwork is what project management is all about: getting people working together coordination of
effort. Achieving teamwork requires considerably more than having a good plan, more than having
the right resources, more than disseminating information. It is more than having good administrative
practices and skilled people. Each of these elements is essential to success. But in addition, all the key
people must have a shared understanding of what is to be done, why, when, and by whom. A shared
sense of mission and a shared perception of values and priorities is essential to achieving the
seemingly effortless coordination that marks effective teamwork.
5.3 Teamwork Requires an Open, Participative Planning Process
The way in which planning is done is as important as the plan. Strategic decisions are perishable.
They may become obsolete in the light of emerging reality. However, the sense of purpose, of
mission, of intent, can be maintained if the on-going planning process has been clearly established.
The planning process should be open and participative. It should foster the building of shared
understanding, mutual trust and cooperation. Above all it should create a 'buy-in' to a shared vision
[1].
271
5.4 Leadership Style is a Key to Effectiveness
Creative participation in Stan-up Planning by the Steering Group is a way to initiate and lead the
process of building shared understanding, shared definitions, shared values, and mutual trust. This is
the basis of working together effectively.
The appropriate leadership style can and should begin with the steering group. It can then be diffused
through the entire project organization through creative participation in the planning process
5.5 Management Preparation Pays Off in Better Results
The keys to good management of development ru;e leadership, preparation, team building, and
process. It starts with the steering group. They can create the organizational climate and leadership
style that will allow the project team to function successfully. They can initiate the open
communication, planning and team building processes. The degree of overall success is influenced
profoundly by how well senior management does its job through the Steering Group.
References
[1] INTERNET Handbook of Project Start-up.
272
Application of Project
Managem.ent
in Selected Countries
PROJECT MANAGEMENT AS PERCEIVED FROM ANCIENT EGYPTIAN PROJECTS

Abdel-Fattah EI-Marashly

V1adimira Machova

Abdel-Wahab S. EI-Bishry
THE PROJECT AS A MODE OF WORK IN SWEDEN - FROM TECHNICAL THINKING

TO MANAGEMENT THINKING
Sten Nordstrom
PROJECT MANAGEMENT AS PERCEIVED FROM ANCIENT
EGYPTIAN PROJECTS
DESTINATION: ETERNITY
Abstract
Pyramid building was a milestone in the history of man because it was his first true application of
large-scale technology. Like all later technological efforts, down to our day, pyramid construction
relied on tools and methods which were already well-known, but the potentialities of those had not yet
been recognized. The keys to the problem of pyramid design and construction were manpower and
superior management. The first was provided by a peaceful and united country, while for the second a
unique human genius was required. His name, which the Egyptians cherished and venerated for more
than 3000 years, was IMHOTEP - the royal architect who designed and constructed for King Zoser
the fIrst Great Stone Structure built by man. Imhotep must have had foremost in his mind the problem
of large scale organization. This article is supposed to throw some light into this occult period of
project management history since 5000 years.
Introduction
Egyptian archeology covered a wide spectrum of projects including: irrigation (dykes ,and reservoirs),
navigation (canals), minerals exploitation (gold and copper), tunnels, palaces, towns and cities and
many other domestic projects. A great deal of ancient Egyptian projects belonged to religion which
was physically translated into the riddle of different structures: temples for worship and funerary
structures (tombs starting from mastabas to pyramids). These gigantic undertakings were developed
(studied and designed) and at last executed since thousands of years when the Egyptians learned to
rely to a great extent upon their own natural resources and to perfect the requisite skills. All these
rely to a great extent upon their own natural resources and to petfect the requisite skills. All these
structures - using surprisingly only primitive working tools and measuring instruments - still stand to
demonstrate the skill of their architects, craftsmen and workers. But it was impossible to realize all
these miracles without the native genius of the project managers who could organize, coordinate and
direct the massive labor force. They planned and controlled the huge and complex tasks that were
implemented with utmost perfection.
In this article it is intended to throw some light into this occult period of project management history
which was symbolically expressed by Mr. Roland Gutch in one of his presentations ([1], p.3) as
follows
·Project Management" 1950

Critical Path Planning-
Operations Research 1960
PM Computer Software 1970
PM Personal Computer Software 1980
Integrated Data Processing
for Project Standards 1990
Table 1: The History of Project Management
Because of limited time and space available, this article will present some points as preliminary
investigation, in the sense that it is intended as a try-out for possible future research and more in-depth
investigation in this exciting angle of archeological research.
The Great Pyramid project (Khufu or Cheops Pyramid) is chosen as the world's most famous
monument, to perceive - as an example - some aspects of the ancient Egyptian project management
1. The Start of Pyramid Building Technology
The King Zoser Step Pyramid at Saggara - surrounded by a complex of courts and buildings and
enclosed within a girdle wall measuring over a mile in perimeter - was the flrst experiment using a
new architectural form and new building materials and techniques. The principal pyramids built in
Ancient Egypt are shown on a map in flgure 1. The three Giza pyramid complexes, built in the Fourth
276
Dynasty for King Cheops, Chephren and Myncerinus, were the peak achieved in this field. A general
plan layout of the three Giza pyramids is shown in figure 2(a,b). Cheops pyramid's size is so
significantly larger than any pyramid that came before or after as if it marked a summit of
achievement after which there was no need to go further ([2],p.65).
ABU ROASH
ZAWIYET
El ARYAN
N~O~~.,
lURA
AO" G",O'- -
- - ~ - - : . Sehvre
ABUSIR N.I."ker . ... Niv,errd
------ -~a
S.k~.::.~::~..,kof MEMPHIS
a.
@:.
,"
SAOOARA • " :'
- ... • I
Pepill ...... ~.:'

.'
Sh.pse,kef . ••••
(Mo"abat Faro'un).
-- -------
Snofrv ...
Red Pyr . ...
DAHSHUR •
Snofru
Bent Pyr ••
Figure I: A statue of IMHOTEP, scalptured in a later age and a map of principal pyramids in Egypt
277
( J)Pyramid 0/ Cheops
(2) Pyramid of Chcphrcll
(3) Pyramid of Mycerinu..
(4) SQJ~IIi/~ of Pyramids
(5) The Sphinx
(6) Lower lemp/~ of Olephrt!ll
(7) Fidd of ma.llabas
o
(8) Tomb of Hcu:p-/I/!TIts " '=l::!"'::==;'="~'OO ......
==:t
Figure 2a: General plan layout of the Giza pyramids
1MfJj~
(1) oftua ~ by a SmDU subsidilll)' J1)Talllid,
stood ill II COWl surrolUltkd by 1I1t1U'nos ..'a ll (2) A
funulIrJ I~mple (J) "'<IS udjQunI 10 Ihe ,asl..". ~itk of
1M wunud wid from il 4-11 u CUllS""~)' (4) lu 1111: ,·ull.,),
building (5) wllich could be reQC~J by buvl from the
Nile.
Figure 2b: The classical pyramid complex
278
2. The Great Pyramid "King Khufu's Pyramid" - Project-2650BC
Hitching ([2], p.I46) and David ([3], p.14) has put - surprisingly -the
following statements concerning Khufu's pyramid structure:
"How, at such an early stage of civilization, was such a precision
achieved?"
"Whoever laid out the design of the world's most renowned tomb was
aiming for something mere funerary pomp?"
"How this immense structure was build at all, let alone how it was built
so that it could incorporate complex mathematical formula, is still not
resolved?"
The following numerical figures, defining the General Pyramid structure as - built may give the
reasons for these above astonishing statements.
The Great Pyramid is composed of 210 courses of limestone of varying heights ranging from about
50 cm to 130 cm as concluded from the very precise measurements conducted by Davidson and
Aldersmith ([4]. p.120), 2.3 million limestone blocks with an average weight of 2.5 tons each
(Herodotus estimate 400 BC) weighing about 5.75 million tons. The square base area is in the order of
13 acres (about 55000 m2). The base side was originally 230 meters (now 227 meters). Maximal
difference between the longest and shortest base sides is about 20 cm. These sides were originally
oriented accurately towards the 4 radial points. Today a slight discrepancy of (3'6") results.
Michalowiski indicated that this discrepancy is due to the gradual shifting of the angle of the earth's
axis during the more than 4000 years since the pyramid building ([5], p.482). The pyramid's angle of
inclination is 51° 51'. The pyramid's height 146 m. (now 137 m.) Each side is equilateral triangle,
originally smoothed and painted. Sections of the pyramid and its internal passages and chambers are
shown in figures 3 and 4.
279
N
00 ::n
o
~
~
~
('I>
HORIZONTAL AND VERTICAL MOVEMENTS
DUE. TO SUBSIDENCE SHOWN lOTIMES
GREATER THAN ACTUAL MOVEMENTS
~ CONFIRMING GENfgAJ.. DIP OF COURSES, S-I-N
PETRIE STAT!!.S U I CONT/NUALLY
~ OBSERVED THAT THE COUJ:lSES
01'" THE COJ:lE HAD DIPS a.<"AS
§. MC/C/'f AS H' TO / ' ~
p.. -P'I'lIAMIDS ~ TEMPl~S
01' 61ZEH" .. ~2.
ANCIENT fORCED ENTRY VIA GROTTO INTENTIONALLY

LOCATED "TO PASS THROUGH NEW FISSURES TO
INSPECT t.P.ME. ALL I<NOWN flSSURfS
ANCIENT FORCED ENTRY MADE SOUTH TOP END L£TT!!.RfD AS G - H
Of GRANO GALLERY fOR IN SPEC.TION OF CONS!!.CUTIVELY TO V-W.
CRACI<S ETC IN OHAMBERS Of
CONSTRUC.TlON. I
'~/----1
I
-.. -.... --.~- .-
o ;0 iOO 110 200 m.
Figure 4: Section of the passages and chambers of the great pyramid
281
3. Setting the Methodology for Perceiving the Pyramid Project Management
As this research work is my continuing exiting activity in the future, I had to put a plan for organizing
the relevant data and records to be collected and consequently the evidences that could be perceived
from the analysis and investigations concerning the different management elements and functions for
the pyramid project cycle activities. This cycle includes the development study (feasibility), design
and construction. For the pyramid building, four main physical activities have to be considered for the
construction, i.e. quarrying (cutting, levelling and dressing the stones), transporting (on road or by
water), building (lifting and positioning the stones) and fmally finishing (plastering and painting). The
acknowledgement of the methods and technologies at the Ancient Egyptian disposal for executing
each of these activities is a prerequisite for perceiving the probable techniques of management The
management functions and elements which we are looking for are the historical planning and control
for time, economics and quality. The problem of organizing and directing the massive labor force is a
crucial aspect of the research. Risk, communication and other resources (materials, tools)
management should also be included whenever records and data could be available.
A great deal of relevant data and records is collected from different resources, which is now a treasure
for the research work. However, for this limited space article, only some examples within this wide
spectrum of management - enthusiastically set for the prolonged research work - could be presented.
The following four aspects are briefly investigated.
3.1 Pyramid Project Building Objectives and Religion Effectiveness
Many archeologists tried to understand the purpose of such vast constructional efforts' and got
different viewpoints. The Great Pyramid was designed on the basis of a hermetic geometry only
known to a restricted group of initiates, mere traces of that reached to the classical and Alexandrian
Greeks. The majority of modem Egyptologists believed that the Great Pyramid is simply a fortress-
tomb designed to be impenetrable, in which the body of Pharaoh Khufu was secreted. The central
belief of ancient religion was that attainment of an after-life depended on the corpse remaining
undisturbed. Hence, any important Egyptians spent a life-time preparing for the moment when they
died, building tombs, designed to last forever and which contained a complex maze of secret passages
and tunnels to defeat the attention of future-robbers intent upon the treasures buried with them.
Hitching believed that Cheops was able to enforce the construction of a tomb of such monstrous size
and ingenuity, if the tradition recorded by Herodotus is to be trusted, considering that it was 2000
years old when he heard it : Cheops was a tyrannical and hated king ([2] P.66). David explained
another logic evidence. She stated that when the Nile inundation precluded work, the largest part of
the population could be employed on the great state building projects. They believed that without
Pharaoh, their life was of little value for he alone could give them some vicarious etemity. So they
282
worked for him in the hope that their efforts would win some chance of survival after death. Indeed
the whole economy of Egypt and most of the architectural and artistic effort had this one aim to
ensure Pharoah's existence after death. ([3], p.14).
Hence, we have to assume that the above thoughts and analysis can give us the access to the following
major inputs for the project management.
First: The pyramid project designer had to fulfill these requirements as a fortress-tomb, impenetrable
and to last for ever; i.e. it should not collapse in course of time, to be fitted with complex maze of
passages and to be finished before the King's death (design for construction stages 3.2.2).
Second: The motivation and incentive for the labor force in order to be mobilized were strongly
activated from their beliefs and religion. In other words, we have to assume that pyramid building was
an essentially voluntary activity and the incentive was based on the self-interest of the individual.
Third: The project economics was linked with the whole State economy to fulfill the only aim which
is the assurance of Pharaoh's existence after death.
These three definite problems - from which we suffer a lot in our present project management - were
fully solved in the pyramid project age. The result was time-, economics- and qUality-optimization.
3.2 Pyramid Design Complexity and Construction Activities Management
3.2.1 Design
The usual polar entrance passage in the north face of the pyramid first runs through the masonry and
then continues into rock beneath the pyramid (Figures 3, 4). Under the apex, the passage ends in a
chamber hewn out of the rock, whose irregular shape and rough finish show that it was abandoned
before completion. The original descending passage was interrupted about 28 m from the entrance and
a corridor ascending at the same angle (about 26°) was driven through the existing masonry. Mter
about 40 m the ascending corridor levels off into a horizontal passage, leading to a second tomb
chamber; again exactly under the apex, and about 30 m above the base. Then the ascending passage
was continued beyond the levelling-off point, but in much enlarged form. It now turns into an
ascending gallery of polished limestone, 47 m long and nearly 9 m high. Its walls are slightly
corbelled and each of the roofing slabs is held separately by notches in the walls. This impressive high
passage, usually called the Grand Gallery, was for a long time believed to have served ritualistic
purposes until it was discovered by Finders Petrie that the real objective was to serve as store for a
series of large limestone blocks. These blocks were let down into the ascending passage, when the
tomb chamber was to be sealed. The tomb chamber at the other end of the Grand Gallery,was further
protected by three portcullises which were removed by intruders. The room itself - King's chamber - is
a room of 10.5 m x 5.3 m, it is 5.8m high and completely lined with granite. It contains the lidless,
283
rectangular sarcophagus which must have been placed in position while the pyramid building was still
going on because it was too large to pass through the entrance passage. The roof of the King's
chamber is made of flat granite slabs and protected from the superincubment weight of masonry by
five relieving spaces, weighing about 400 tons.
The design of the Grand Gallery with its high and sloping passage provides interesting evidence for
safety precautions to stones slip risk which seems to had been ever present in mind of the designer.
The roof slabs are made to be individually against notches on the top of the walls and not against
something else. This was to ensure that the weight of the slabs did not accumulate at the lower end of
the sloping ceiling.
The pyramid design proved to be a remarkable stable structure in spite of its immense size and weight.
The pressure exerted by its own weight at the base smounts to about 25 Kg/cm2 ([6], p.98). It
certainly would not cause crumbling of limestone in a well built huge structure. Taking the case of an
ideally, constructed pyramid, like Khufu's pyramid, built with perfectly squared blocks, the pressure
everywhere within the structure acts only downwards (Figure 5). At each horizontal face of any block
the force of the above weight acts vertically downwards on the face of the underlying block. It is
balanced by the rigidity of the building material and will not cause considerable deformation.
However, if the cube is not ideal, these condition change and the blocks will touch at a few points
only and consequently the pressure at these points of contact will rise to even thousands of
atmosphers, which is high enough to cause crumbling and serious deformation of the blocks. The
result will be the lateral component forces, favouring break-up and flattening of the structure
(FigureS).
Figure 5: Direction of gravitational force acting within a well-built pyramid (a) and in one
composed of badly squared stones (b).
It seems that Imhotep was fully aware of the danger of these lateral forces and introduced a stablizing
inernal structure in Zoser's step pyramid which was followed in Khufu's pyramid and the others. This
is only one example of many other vital design criterions which have been discovered in Khufu's
pyramid.
284
These design factors, taken into consideration at that age, ensured the utmost quality standard which is
beyond any imagination. Also, the interior design of the Great Pyramid addressed the problem of the
complex interrelationships and consequences for implementing the construction activities. An
intensive research work on this planning and programming problem should be .investigated in the
future in-depth research elaboration.
3.2.2 Construction
A great deal has been written about the methods of pyramids construction - in particular about the
type of ramps and the way in which the blocks were quarried, transported and placed. Much of this
has necessarily been mere conjecture with the intention of estimating the size of the working force
employed.
As far as the construction of Khufu's pyramid is concerned, it appears that the arrangements ·of
passage and tomb chambers underwent three successive stages ([7], p.l72). Figure 6 illustrates the
three stages (1,2,3) of construction.
1
... rflrr'i(rr:;'~~
.../.l1fl{jmU i;
rl LJj.J.I-':'-;-. --'---'--'-'-'.1...
rI~ ''· ···.,
U-i.-
.
'- ..
3 .::~y:~.'~~::<=,; ;~~"'/"': '"
'" .
Figure 6: Stages of the Great Pyramid's construction
285
The intention was to have a ready burying chamber until the King's death was not known.
Ropes and rollers existed. Ancient Egyptian Engineers might have used well more sophisticated
lifting dervices; However, one of the problems that had to be solved on the central adminstrative level
was the lifting of building materials to a great height.
The tools used to cut the stones, particularly the hard ones, have always been a point of controversy-
but the great feats of Ancient Egyptian were probably achieved only with tools of stone, copper and
wood. Hard stones were doubtless pounded with balls of dolerite and it appears that it was sawn with
copper tools and polished with abrasives-probably blocks of sand stone. Soft stones were worked with
soft chisels and mallets. Various tools have been found inside the step pyramid and the diorite
quarries. It seems that the tools were of a simple kind: chisels, drills, saws and engraving points
(exihibited in the Cairo Ancient Museum).
The basic steps involved in quarrying and transporting the stones to the pyramid site have been
worked out by many archeologists. The following summary is based on the account of what Hiching
perceivd from preceeding archeologists ([2], p.68).
(1) Choosing the site; on the west bank of the nile, closest to the setting sun on solid rock and near
to water-borne transport.
(2) Organizing labour; gangs of 250 workmen were probably the basic unit, working mostly when
not needed in farms. Master masons and skilled workes were needed full-time.
(3) Levelling the site; by forming a grid of ditches and filling them with water. Gradually drain,
chiselling the floor level. Inaccuracy is in the order of 0.004%.
(4) Aligning the pyramid orientation; by observing the nightly position of the pole star. The fine
adjustments were made by observing the midnight positions of other stars. At last the square for
the pyramid base was formed.
(5) Quarrying the stones; a quarry nearby the pyramids site was used for the body building blocks.
Facing stones came from fine white limestone in Tura quarries on the east bank of the Nile
(about 20 km distance) whose tunnels are still existing until today.
(6) Shaping the stone; T squares, plumb pops, facing plates and paired rods were the measuring and
marking tools for shaping the stones. Copper saws and chisels were used for cutting.
(7) Transporting the stone; by placing the stones, normally 2-5 tons but sometimes up to 200 tons
on sledges. Chanting of the labor force helped them to pull stones.
(8) Building a ramp; remains of such ramps were found, averaging a slope of 1:10, forming the
major supply route to one face of the pyramid. Steeper and narrower embarkments surrounded
the other three faces of a pyramid. An illustration of such ramp is shown in figure 7.
286
Figure 7: Major route ramp for building materials supply to the Pyramid
(9) Finishing the Stones; the outside blocks were accurate to a few centimetres and cut very exactly
and pre-fitted by master masons at ground level.
(10) Levering and positioning the stones; how the final positioning of stones was achieved is not
known in any reference available till now. We can assume that some sort of leverage must have
been used on the narrow embarkments "step (8) above".
The most important issue which is still under investigation is the necessity of standardizing the
measurements of stones of each course in the vertival direction and a coding system for managing
each stone to be placed in its specific position in the 210 courses, specially those tapered stones
forming the interior ascending and descending passages.
3.3 Stones Transport Management
The following example of transporting a colossal granite statue (about 150 tons and 6m high) from
quarries to far distant temple is shown in Figure 8, illustrating the top awareness of planning,
organizing and controling, together with all precausions for safe transportation.
By analogy, this organization can be considered as the traditional form of management followed in
transporting the huge blocks of limestones to the pyramid site.
* The statue (1), secured by ropes on a wooden sledge and protected by pieces of leather from the
chafing of the rope, is pulled by 172 men (6,7,8,9) hauling on the drag ropes attached to the
front of the sledge.
* To ensure the simultaneous action of the workers an overseer (2), standing on the statue knees,
chaps his hands; this is repeated by another man (3) in the front with a little hand drum.
* One man (4) stands on the base and pours out continuously a stream of water (may be oil) to
make the earth slippery and enable the c10ssus to pass more easily.
* Below the sledge are the water carriers (10) to quench the thirsty throats of the workers and to
reml the pot of the sledge lubricator.
* There are also men (11) carrying a notched beam (tree truck) used probably to place down in
the hollows of the road to prevent the runners from slipping.
287
* At the bottom of the left corner stand three supervisors (12) holding wooden staffs as symbols
of their authority.
* On the left there is a reserve band of workers (13,14,15,16) to relieve those who get exhausted.
* On the upper register a troop of soldiers (5) oversees the moving of the statue.
'"
<I)
.~
::I
C"
<I)
£
§
J::
0..
~
0
::t
.!.
::I
.c
0
<I)
u
C
;E
....0
<I)
::I
E
'"
";
'"
'"
.9
'0
u
<I)
£
'c;
'§
~
c
~
00
...::I
<I)
rr:
bIl
288
3.4 Time and Labor Force Estimate
The main issue considered by archeologists is concerning whether the pyramids were constructed
consecutively or with overlapping. However, there is a fact, that each pharaoh began building of his
pyramid with ascending the throne. It was his aim to fInish it well before his death. It means that the
pyramids would have been built consecutively in the succeeding reigns. But there is a strong evidence
for overlapping building periods. (Figure 9).
tzTillle~
Figure 9: Labor force employment diagram for consecutively and overlapping construction
periods of the pyramids
Overlapping construction periods could be phased in such a manner that the employable labour force
was always equal to the maximum available labor force 'M'. If we consider the technological effort
involved, it soon becomes apparent that consecutive construction is an economic and organizational
impossibility ([6), p.142).
In view of their immense size, the building of pyramids on the scale undertaken in the forth Dynasty
had to become an activity in its own right and demanded its own economic rules. It essentially
dominated the pattern of life and, once started, tended to continue and escalate.
According to the size of working force employed the estimates have varied in different publications
from a few thousands to a third million. The only historical fIgure of labor force is that given to
Herodotus (440 Be) by his Egyptian informants 2000 years after the pyramid age. Herodotus
mentions a labor force of 100000 persons working three months each year during the annual
inundation of the Nile. Generally, nobody knows the size of Egypt's population at that age.
All we should assume is, that the labourforce for building pyramids was organized very well. In view
of superb planning, we may also asssume that they made use of the most economic methods at their
disposal.
It is clear that the concentration of a large labour force for pyramid building also required the
institution of a large-scale food storage. These grain stores had to be extensive enough to ensure
continuous supplies as an important buffer against the fluctuations of the Nile. In this concern,
Mendelssohn mentioned the story in Koran (Moslem's Holy Book) of prophet Joseph's prediction of
289
seven fat years to be followed by seven lean ones ([6], p.148). It is clear that he refers to fluctuations
of the Nile inundation which made the setting up of governmental grain stores imperative. It could be
concluded from this example that Ancient Egyptians were very aware of critical situations and in
modem management term they exercised with genius risk management.
Another important evidence of the pyramid project work teams is provided by the tally marks on the
casing of stones delivered from the quarries. They give the titles of the individual work teams, who
were to be credited with the supply. Some of the names read: Stepped Pyramid Gang, Boat Gang,
Craftsmen Crew, Vigorous Gang, Enduring Gang, Sound Gang.. , which seems to refer to expressions
of pride and competition. In fact, it looks as if participation in the pyramid project had created a sense
of comradeship among the workmen, i.e. the spirit of team work.
Acknowledgement
The resear~h work on Egyptology now fill thousands of books and periodicals. Thanks to this massive
treasure of information I have been able to select from it the most relevant background and basic data
to my specific topic. I am also very grateful to the Egyptian Egyptologists, who welcomed to listen to
me in the hope that I might make some contribution to their own field from Project Management
science and art angle; miracly conducted since 5000 years. In this concern I should mention with
gratitude Dr. Hassan Ragab; the founder of the Papyrus Research Institute, Dr. Abdel-Aziz Sadek;
general manager of the Centre of Documentation and Studies on Ancient Egypt and Mr. Ahmad EI-
Sanadeely, Director of the Cairo University excarvation-faculty of Archeology. Eng. Adel Yaseen,
one of the pioneers in developing PM techniques in the Egyptian Environment deserves my highest
appreciation for devoting a great deal of his time to discuss many aspects in this article.
References
[1] .Gutsch, R.: International Project Management -The Necessity for Comprehensive Stan-
dardization, paper presented to Cairo PM Symposium, 1990
[2] Hitching,F.: The World Atlas of Mysteries, 1st edition, London, 1978.
[3] David, A.: The Making of the Past; The Egyptian Kingdom, 1st edition, Oxford, 1975.
[4] Davidson,D., Aldersmith,H.: The Great Pyramid - Its Divine Message, Vol 1, 9th edition,
London 1941.
[5] Michalowiski, K.: The Art of Ancient Egypt, 1st edition, London, 1969.
[6] Mendelssohn, K.: The Riddle of Pyramids, 2nd edition, Spain, 1975.
[7] Fakhry, A.: Egyptian Pyramids, 1st edition, Cairo 1963.
[8] Gosse, A.: The Civilization of Ancient Egyptians, London.
290
Vladimira Machova
Abstract
Before the establishment of the Czechoslovak: Republic (1918) a field of activity called "Technical
Management" was raised in Czech lands, including two directions, one concerned itself with the effect
of work and technology on the economic life and the other with individual entetprises, their operation
and possibilities of internal arrangement. This period reflected a marked interest in scientific
management.
In 1924 Prague arranged the frrst International Management Congress. The Second World War caused
stagnation in this field. The early 1960's marked the beginning of the development of management
methods in Czechoslovakia, among others the method of network analysis.
At present in the frame of progressive democratization of the society and independence of enterprises
the education has to be interested in project management as a necessary condition of the development
of the state.
1. Project Management Development in Czechoslovakia
1.1 Technical Management
Interest in American management knowledge was shown in Czech lands which belonged to Austria-
Hungary at the beginning of the first decade of the 20th century. In Czech lands, in the same way as
25 years ago in USA, the development of technology and technique increased rapidly and the social
development, which caused changes in workers position contributed the engineers increasing interest
to management questions.
Articles dealing with technology and management relations started to appear in professional
magazines, first articles informing on new management methods especially introduced by Taylor.
Taylor's methods were also tested in industrial enterprises. Differences between conditions of the
USA and Austria-Hungary were too obvious. Taylor's system was set up and used in enterprises with
serial manufacture. Industry in Czech lands mostly was not specialized at that time and there existed
only some enterprises with serial manufacture. The original version of Taylor's system ran into the
resistance of workers in the USA. All attempts to apply Taylor's method in Czech lands finished
unsuccessfully after a short period because of worker's resistance.
Taylor's books and articles exerted a predominant influence on engineers activity as to management
problems. From the beginning of interest in management problems the organization of work and
production was considered as a fundamental management task of an engineer. Gradually one came to
the view that engineers have to organize the whole economy, that they have to eliminate existing
bureaucratic and uneconomical management methods and introduce new methods in practice.
There was set up a new field of activity called "Technical management" including two directions of
which one was concerned with the effect of work and technique on the economic life and the other
with individual enterprises, their operation and possibilities of internal arrangement.
Considering that technical management stressed the organizational and management role of engineers,
this period reflected a marked interest in new management methods, especially in scientific
management.
The group of engineers was set up studying systematically American literature on scientific
management, German literature on "Industrielle Wirtschaftslehre" and "economy of human labour"
and was anxious to interest other engineers in these problems. The most active member of this group
was Stanislav Spacek.
As attempts to introduce Taylor's system were unsuccessful, utilization of the experience in research
of working physiology and psychology, of "human economy" and "saving management of labour"
was considered as the most important. A special committee for study of working physiology, the
living-conditions of a worker and his capacity to engagement and the Institute for Research of Work
were established in France in 1913. In Czech lands the Institute of Emperor Vilhelm for Working
Physiology which was established according to the French model exerted predominant influence.
Further institutes were established in Belgium, Italy and England. Also at that time it became
obviously that the scientific base for management which contributed to the justified title - scientific
management - has been obtained especially by means of physiological research and further research of
human activities. Therefore also after acquaintance with the experience ofF. B. Gilbert in possibilities
of working output raising by means of effective motions and with the first knowledge of applied
psychology and psychotechnique the attention was rather given to the propagation of the study of
motions, psychotechnique and physiology than to investigation in possibilities of organization and
production management improvement. Gilbert's motion studies and improvement of working
conditions were considered as more significant for Czech industry at that time than Taylor's technique
and principles of management.
During the last years of the war Czech engineers tried to utilize the increasing importance of
technique and to strengthen their positions in public and economic life. Proposals for the
292
establishment of various institutions were developed. The establishment of a special technical and
economic institute or an Academy was considered as the long-tenn program. The technical and
economic association was to serve as the preparatory organ. This association was set up by chance at
the same day as the new state Czechoslovak Republic was established (28.10.1918) and was called
Technical and Economic Union. In the time after its establishment this association made atmosphere
of great enthusiasm IUld expectation of new independent state considerable activity.
A program including a number of proposals which were used later either directly or with certain
modifications was developed at the same time as the Academy of Work: was established.
1.2 First International Management Congress
According to the law nr.86 of the 29.1.1920 the Masaryk Academy of Work was established as an
independent scientific institute in Prague. Its assignment was to "organize technical work aimed at
economical utilization of abilities of all people and natural resources of the Czechoslovak state for the
highest common benefit". Then the government rendered the order "Basic regulations of the Masaryk
Academy of Work".
The psychotechnical institute which made every effort on acquirement of public attention both by
lectures and consultant finn on choice of career and by research directly in enterprises was established
in March 1921 .
In 1922 the establishment of the World Engineering Federation seemed to be necessary. Prague was
suggested to become a centre for Europe with regard to the fact that in Prague were always many
engineers from various Slav countries who could join in the world organization then. For this reason
Prague was also considered as the place where the first International Management Congress was to be
held.
The Council for Prague International Management Congress met on February 20th, 1924 determined
the date when it would be held (21-24 July 1924) and the program which was divided into five
groups:
- general, group
- scientific management in industry: elimination of losses, standardization and simplification
- scientific management in the main public industry
- scientific management in public administration
- education in the sphere of scientific management.
21 states were represented on the congress: United Kingdom, Belgium, Brazil, Bulgaria,
Czechoslovakia, Denmark, France, Jugoslavia, Holland, Italy, Latvia, Lithuania, Mexico, Gennany,
Poland, Austria, Romania, the Soviet Union, Spain, Switzerland and USA. The largest delegations
were the American (50 delegates) and the Polish (40 delegates). On behalf of the Czechoslovak
293
delegation S. Spacek, one of the institutors of the Masaryk Academy of Work, delivered "confession
of faith" in advantage of scientific management
THE MASAR.YK ACADEMY

&&.IIlTlTVT& '0& UI'lUIT~ 1UoJI"''''''UlT)
FIRST
INTERNflTIONflt
MflNHGEMENTCON6RESS
PRfl6UE
_~d''''rle ••• t
JUt,. r. a. '>4A,UR. YK
JI,'.ll••••/ d. C~...1 ..1_..1 R'J.Jl; •
..l l ......." .1&1••....11, .r

lIlSRBllll.:r llOOVB~
'n.s. S_a4••, ef '1.D.I ••' ..·•••
../D........
nOETAIUAT CD.TR.J.I. OF TIIZ CO~'CRtsS

tllACUI n. HtJNiClPAL aU1WING, nt..uu.. _ PRM;Jf: JL.J1NDP.I~5;.1, 1'. TEL t~u.
~'wkslmll, ttrulnl Irrtlnkll profJ,amu I, mutnarodnlho ;:ongresu 0 II·

Itfnl p Prall
Figure 1
294
"IT we sum up tasks of scientific management of work, we find that this is to facilitate work of all
nations, to raise the level of people, to eliminate complaints and poverty, to have more spare time for
improvement of life which all is the best way for understanding of nations. National hate among
nations will be eliminated as soon as nations will mutually cooperate in favour of the public where
any nation won't struggle for humiliation, abuse of another nation.
The century of resources is followed by the century of scientific management, of work making
possible to improve not only living conditions of individuals, but also of whole nations, leading these
to the mutual understanding and cooperation on the base of new policy, policy of the world economy
and economy of work and life of men. World organization of scientific management will form the
base and change-over for the establishment of world production and sales-cooperatives and on the
base of social economy it will contribute to elimination of economic causes of war. II
The resolution which became the base for gradual formation of the World Management Council
(CIOS) was accepted in the conclusion. CIOS was established on June 11th, 1924 and it pertains to
some of these institutions which haven't had to change (in their course) for more than 60 years there
basic program and aims while mankind and world economy had developed very quickly.
Literature and professional articles relatively often marked the first International Management
Congress as the event which contributed to the world the movement and the formation of management
improvement and the establishment of intemational organization.
1.3 Czechoslovak Scientific Management Committee
In 1926 also were established the Czechoslovak National Committee for scientific organization and
research institutes for the study of principles of scientific management and scientific organization of
work. The management theory was developed, the Czechoslovak National Committee for Scientific
Organization and the Institute of Human Labour continued their work. However, early in the fifties
both institutions were disolved.
In 1964 the preparatory council of the Czechoslovak Scientific Management Committee of the
Czechosl~vak Scientific and Technical Society (CSVTS) was established which developed the plan,
the statute and the program of the activities in the near future. The Committee, according to its
program, aimed at the development of mass movement in the raising of scientific management and
developed the base for exchange of practical experience and theoretical knowledge. Like that it
formed the base for exchange of practical experience and for promotion of carrying scientific
management ideas in the wider circle of our professional public.
295
2. Project Management Methods
The development of scientific project management based on applications of operation research

methods which showed by wider education activity - by lectures, publications, courses started in
Czechoslovakia in the second half of the fifties.
In 1965 the first national seminar was held at Plzen: "Some problems of network analysis in
engineering entetprlse. The first national conference concerning experience in application of network:
analysis methods in Czechoslovakia was held in Prague in 1967. This conference was held to make a
survey of the state of theoretical equipment and namely to summarize obtained practical experience in
existing application of network analysis methods, to give real information about ther situation in
individual spheres and to explain problems of further development and intensification of these
methods."
The application of progressive methods and computing technique by project management was
coordinated and methodically managed by the activity of professional groups for network analysis
methods which worked in the Committee for Scientific Management A professional group consisted
of employees of research enterprises, research and project organizations, members of high schools
(universities), of central organs and ministries. At the end of the sixties its members became
institutors of the National Terminology Committee which developed the draft of the standard terms of
network analysis. In 1969 this draft was accepted as the Czechoslovak State Standard 01.0111 "Terms
of Network Analysis" which has determined Czech and Slovak terms used by application of network
analysis and also included Russian, English and German terms for information. This standard was
presented for acceptance at the second international congress INTERNET (1969 in Amsterdam).
Within the CEMA-countries it was later accepted as recommended standard of vocabulary. After the
United Kingdom as the first Czechoslovakia became the second country in the world which developed
and issued a state standard of this type.
Since 1965 a number of actions concerning project management was held, organized by different
organizations and institutions in Czechoslovakia; a lot of publications were issued. However, the
greatest tradition in Czechoslovakia have had the national and international seminars on "Manage-
ment. and network analysis" organized since 1965 always in October in Gottwaldov, since 1985 in
Znojmo, Prague, Karlovy Vary and Mariansk6 Lazne.
Both Czechoslovak experts from all spheres of national economy and foreign experts of various
countries have shown more and more interest in the seminars on "Management and network analysis"
(in 1985 for example, experts from 14 countries took part in the seminars). The interest of
Czechoslovak participants in these seminars is connected with the permanent increasing application of
scientific project management methods in economic practice.
Qualification and interest of managers have been decisive for the prosperity by application of modern
methods and utilization of efficient computing technique in great extent. Therefore since 1983 in
Czechoslovakia systematic preparation (namely as specific postgradual study) has been realized;
296
managers have gotten an attestation about their ability of preparing and realizing projects. Students of
economic and technical universities have been acquainted with basic management methods.
3. Stagnation of Development
In spite of all we have to state that we didn't have results in Czechoslovakia during the past 40 years
in the sphere of project management which are contrary to the expended effort of some individuals or
whole groups. It was the fault of the face that the small group or some incompetent individuals
representing not only absolute political power but also absolute authority to solve principal problems
of science, culture, technique and further spheres of the public life decided on all principal problems
in a quite privileged way. This absolute authority - according to the well known principle of
absolutism "L'etat c'est moi" (the state is me) - requested all inventive workers in science, technique,
culture and economy, to carry out only accepted principles or orders; that means to move quite
decently only within the limits of this frame, within the limits of orders and instructions delegated
"from above". Scientific management methods weren't naturally requisite to this. If they were used
somewhere these methods were doomed to failure or considerable deformation in the near future.
Czechoslovakia was more than 40 years a state with centrally planned economy.
4. Training of Managers
It's commonly known that results of scientific and technical development have influenced the
development of mature society to a decisive extent. Behaviour of enterprises and their managers has
conducted to a great extent on application of science results and research in practice which has formed
the main criterion of success in this sphere. A manager has to possess necessary properties and
abilities, necessary knowledge and professional, managing and language skills. All conditions of
managing activity have to be steadily developed and completed by means of training, education and
practice. As far as training and education of adults have concerned knowledge and skills have been
completed and improved by organized forms namely in the sphere of management, organization,
decision, inventive thinking, management of inventive team, speech, mental hygiene. In this sphere in
Czechoslovakia we have considerable lacks, great attention has been given to education and
acquirement at the present political situation. It turned out that without substantial help of experienced
foreign experts we aren't able to solve this problem in the near future.
Czechoslovakia has been cooperate with IN1ERNET-IPMA for a long-time and its representatives
brought in last years every year at our seminars "light of knowledge", therefore we reckon on
initiative of our partners from IN1ERNET-IPMA by solution of above-mentioned problem.
297
Abstract
Initiation of the Idea of Project Management in Developed Countries since 1950.

Start of the concept of Project Management as a profession in Egypt in the Seventies.
- The role of the Management Engineering Society MES in developing Project Management
expertise from 1980 until now.
- Examples of the activities undertaken by MES in the field of education and training of project
managers, in organizing seminars, symposiums and workshops, both on the national and
international level and in maintaining a lively contact to the International Project Management
Association INTERNET and to other national societies.
Review of future activities mainly to extend the scope of Project Management from the
Engineering and Contracting industries to non-conventional applications of project management
techniques, such as factory overhaul, management information systems, establishing quality
control systems .... etc.
This will open the way for Project Management to increase the efficiency of the existing
enterprises over and above its main role in conventional project management.
1. Initiation of the Idea
1.1 Project Management in essence was not something new in developing countries. Lots of
projects have already been established since the early history until now and many projects have
reached the state of excellence to the extent that some of them have been included in the Seven
Wonders of the World.
The fields of projects were not only restricted to big buildings and establishments, but a great
part has been established in various productive and service sectors. Those who took part in the
implementation of these projects had followed the practical experience gained from older
generation and have managed to fulfill their objective and to achieye the required standards of
the quality for the project. during the time span allotted and within the determined budget
1.2 Following the establishment of the named project, factory or enterprise however, this
establishment entrusted with the construction phase became responsible for its management
during the phases of production and services although this phase differs in regard to its
requirements from the previous phase. The special expertise for Project Management in this
way was stopped and was supplemented instead by the management of the enterprise with the
aim oriented towards achieving production and offering services.
With the repetition of the projects, the experience was repeated in different locations but with
different personnel. This did not give the opportunity to consolidate the experienced expertise in
the phases of the project management in the same group of personnel who started the task of
project management since experience is scattered among other groups who started on
subsequent projects. Trails were renewed over and over again with the effect that we have
become like those who were .. reinventing the wheel ".
1.3 The various industrial countries have passed through this phase and the vestiges of progress
since the industrial revolution until 1950 resemble those which we are passing through here at
present. But with the multiple variety of products and the increase and complexity along with
the repeated desire for the development of products or the development of processes in the
period after the second World War, particularly in the fields of production of aeroplanes and
missiles, the real need had arisen for the necessity of functional coordination so that efforts are
directed towards the realization of the aim exemplified in the production of the new or
developed product or process. In this scope, different phases were perished towardS, effecting
such coordination.
- The appointment of one responsible along the staff level, for the follow up of the different
phases to achieve the new product: But such a responsible staff was not endowed with
sufficient authority permitting him to exert his influence on the administrative departments of
the organization in a noticeable way and without causing any setbacks or opposite results.
- The task of follow up was assigned to one of the directors. This too, was not conducive to a
total solution of the problems resulting from communication contacts along the horizontal
levels of the project with those of the vertical ones representing the skeletal functional
organizations.
- At last, some companies have altered their organization in the form of products and by
introducing a form of decentralization. This was a novel step towards the realization of the
suitable organization of the project.
- Beginning with the 1950's and with the conviction of the means of systems, a new
organization became suitable for the project requirements and commensurate with its
300
specifications namely - Project Management -. A Project Manager was appointed with the
suitable qualifications that enabled him to coordinate the requirements of the project and
those of the administrative management.
In this way a new form of organization was created and sanctioned - The Project
Management -. The acceptance of the idea of appointing a Project Manager has been
consolidated with the different merits that such an organization can gain.
1.4 The new organization realized following merits:

- That there should be a specified aim that should be reached and achieved,
- that every project has its unique properties and that it represents a new situation and is not the
continuation of a preexisting one,
- that project management is considered to be existing all through the phases of execution; by
the completion of execution, the existing project management is to be considered as over.
Those who were responsible for work within the scope of the project will form the base for
undertaking project management in other fields. That helps to upgrade the experiences in this
particular field.
2. The Management Engineering Society MES
2.1 The Management Engineering Society MES is a specialized professional society established in
1970 under the patronage of the Egyptian Society of Engineers. Therefore it has added a new
link in the chain of the professional societies emanating from the Egyptian Society of
Engineers.
2.2 The Egyptian Society of Engineers ESE has been established in 1920. The decree for its
establishment has been issued in 1922 and offered it with the supervision of the Egyptian
Government. The main objectives of the society have been the following:
- The activation of research and techniques both in theory and practice for the engineering
sciences.
- Cooperation in collection and upgrading engineering information and their editing.
The other following amendments have been:

- Strengthening relations and scientific cooperation between Egyptian engineers and their
colleagues outside (1958).
- The law governing the organization of scientific societies issued in 1956 should be applied by
the Egyptian Society of Engineers (1964).
301
- ESE allowed the establishment of specialized engineering societies (1970).
Each of these societies had fully authority in directing its own affairs within its own budget but
with a moral commitment to help the ESE to achieve its main objectives.
2.3 The Management Engineering Society formation was based on the fact that the engineer since
the Industrial Revolution, had played the primary part in the movement of the technological
development and plays a control-part in the recent scientific achievements on one hand, and the
management on the other hand. His part is profiting by the scientific discoveries and
achievements all or in part and changing this through his design abilities into products and
services which benefits mankind and society. In this field he acts as a bridge between
engineering and management: Engineering-aims towards the utilization of available resources
for the service of mankind - Management-aims towards the optimum and most efficient
utilization of these resources.
Therefore the link between engineering and management provides the society with the
efficiency in its best form which can be expressed in higher economic returns.
Within this concept the Management Engineering Society MES has been established in 1970, as
mentioned before:
- The main aim of the MES is to develop management expertise of the Egyptian Engineers
and Managers in both areas of Project Management and Operation Management.
During the early stages of MES establishment more emphasis was given since the seventies
to the area of Operation Management, the same way which has been followed by the
developed industrial countries to increase the performance and efficiency of the enterprises.
- But following the introduction of the open door policy in our country during the seventies
and the expansion in number and size of development projects, some of them reached billions
of dollars, whereby time, space and budget for these projects needed to be strictly observed, it
was imperative for MES to give more emphasis to developing "Project Management" both in
theory and practice. This is achieved through
- Education and training of groups of engineers in Project Management
- Organizing symposiums, seminars, workshops on different aspects of the modem tools and
techniques of Project Management
- Maintaining a lively contact to the international Project Management Association
INTERNET and to other national societies.
302
3. Differentiation between Project Management and Operation Management
3.1 The management of a project is not the same as managing operating business or function.
Although both project management and operational management activities must be planned,
executed and controlled just the same. Yet there are some distinct differences:
- First: Project management is associated with creating something new or improving the
current method of operation. It is oriented to innovation or change and it is a one time
activity. Technical groups are involved with developing the new or changing the old; this
includes the activities of machines and people. Operational groups, on the other hand, deal
with more predictable well defined tasks. The emphasis is assuring adherence to procedures
and plans. Most operational functions are repetitive and unpredictable behaviour by people or
machines is unacceptable. Project management seeks for changes while operational
management seeks for sameness.
Thus the Project Manager must exercise and create an atmosphere that is conducive to
creativity innovation and change, while the Operational Manager must demand predictability
and a pattern of behaviour that is highly structured and precisely defined.
- Second: Project functions usually deal with one time activities. When a study is done, a new
machine designed or a new system developed, the work is seldomly repeated. Operational
work, by contrast, is associated with routines that repeat themselves periodically (hourly,
daily, weekly etc.). Since it is an integral function of running the business, the operating
routine is expected to perpetuate itself when it is developed.
- Third: The costs of one time activities are much more difficult to estimate for the future and
so estimates are liable to have errors while estimates of operational costs can usually be
predicted based on historical data.
- Fourth: There are differences in the way of expediting work. Generally we can increase
production of an operational activity in proportion to the resources applied. However, we find
that deminishing returns may be reached very early, with the addition of resources to
expedite project activity. Too many people on a project may be less efficient than missing
people.
- Fifth: The ability to measure performance is different. If 50% of time resources planned for
project management are expended, we do not know whether that project is in trouble or not.
We must know how much time and effort are needed to complete the activity and what effect
a schedule slippage or cost overruns will have on the total project objectives.
303
3.2 So the major differences are summerized as follows:
The Project Manager is concerned with one time future oriented tasks directed towards
innovation and change. The resources required and the end results are rather uncertain and
unpredictable. The Operational Manager on the other hand is concerned with present oriented,
periodically repetitive tasks, strict adherence to predetermined policies, procedures. The
Operational Manager must deal with enforcement of plans, schedules, policies and procedures
where the results of decisions are much more predictable.
So in order to achieve the aims of the Society, there is a necessity to develop the project
management which mainly deals with creation, innovation, together with the development of
operational management which aims to achieve the required level of performance of existing
enterprises.
3.3 So the task of the Management Engineering Society MES is directed to both activities; the
Operational Management (OM) and Project Management (PM).
- In Operational Mana~ement, the Society renders its services to the management of existing
enterprises for better utilization of the available resources in the fields of planning and
control, directing activities towards fulfilment of the aims of the enterprise, organization and
coordination, problem solving and development of skills in all these fields.
- PrQiect Mana~ent Actiyities started to appear in its proper shape in a number of projects
after the adoption of the open door policy in 1974. Before that, the functions of project
management were more similar to those of site managers.
The usual term adopted at that time was the "Resident Engineer" who was mainly ~sponsible
for site operations, leaving other management functions to the main functional departments.
Thus now there is great need for forming proper cadres who can undertake the role of project
managers. This has been the current feeling since the beginning of the eighties.
The crucial role of the Project Managers in developing countries covers: the ability to
evaluate and select the right projects, to negotiate financing and implementation contracts, to
manage the engineering, procurement, construction and start-up. These are the basis for the
development process.
304
4. Role of MES Activities in Developing Project Management
4.1 Education and Training Groups of Engineers in Project Management
4.1.1 Egyptian Universities
Apart from the short courses that are conducted each year'containing short and appreciation courses
on Project Management and implementation, systems analysis, feasibility studies, use of computers in
Project Management •. etc., MES has already in 1983 presented a proposal to the Egyptian higher
Council of Universities as well as the American University in Cairo, to develop and offer post
graduate courses and diplomas in Project Management.
Now, responding to this demand there are three post graduate courses in Project Management, of the
same standard as those carried out in other developed countries and it is expected that these graduates
will form a good base which will help in developing project managers in the future.
These Universities are:
- The Cairo University,
- The Ain Shams University,
- The American University.
4.1.2 Cooperation with the Carl Duisberg Gesellschaft CDG
Contacts with the Carl Duisberg Gesellschaft CDG started in 1984 and have offered fellowship
training for 18 engineers on Project Management in Germany in two groups:
The first course was held from Sept 86 - Feb. 1988
The second from Sept. 87 - Feb. 1989.
In view to the advantages which have been achieved from the two courses, certain meetings have
taken place between the CDG and the MES and other experienced personnel from Universitiy
industries with the main object to "Identify Training Needs", to specify the system of training and to
expand the scope of Project Management not only to deal with construction activities but also to
extend the scope towards:
- Managing the rehabilitation of plant facilities,
- Installing management information systems,
- Establishing preventive maintenance systems,
- Establishing quality control systems,
- Introducing carreer development systems.
The results of the meetings with the CDG came to mutual agreement that:
305
It is important for Egypt to continue with its efforts in Project Management to modernize
management techniques.
- There should be more efforts placed by the MES to increase the awareness amongst Senior and
Top management to provide the most suitable climate for carrying over Project Management
Training.
A project to increase the awareness for top and senior management is in preperation now.
4.2 National Seminars
The first introductory seminar in development of Project Management was held in 1980 called: "The
Role of Management Engineering in Development Plans"
This was held in conjunction with some visiting professors and specialists from the USA and it was
the base from which the concept of real "Project Management" has emerged.
The second introductory seminar was held in 1981 with participation of a group from the George
Washington University and Oklahoma University together with other specialists who had undertaken
jobs in the most advanced projects of the NASA, titled "Project Management".
These two seminars - although they were still introductory - have created a concept that Project
Management is a framework of knowledge and experience and forms a specialised profession which
is necessary for the development of projects, and for serving the economy in general. This feeling has
reinforced the will of the MES to join the International Society for Project Management INTERNET.
This has happened in 1984, and in this occasion we have to illustrate the help that has been given to
MES by Mr. Roland Gutsch and the GPM in introducing MES to the INTERNET and in participating
-he and his colleagues- in the various International Symposiums which are mentioned later.
4.3 International Symposiums
Since MES has joined the INTERNET as a member, it has organized until now three international
symposiums:
The first in Feb. 1984:
"Planning and Implementation of Projects in developing Countries"
The second in Jan. 1987:
"Rationalization of Resources in Project Management"
"Project Management between Theory and Practice".
The program of this symposium contained the following:
- Three Panel Sessions on:
306
- Training in Project Management,
- Contractor/Owner Interaction,
- Applied Project Management.
- 12 Paper Sessions presented in three streams to the following topics:

- Project Management General,
- Construction Management,
- Contracting,
- Control,
-Finance,
- Information Systems and Software,
- Quality Assurance,
- Resources Management,
- Risk Management and
.- Tools and Techniques.
- Three Open Sessions along the three working days of the Symposium, introduced by keynote
speakers.
4.4 Other Activities
Over and above the training courses which are held locally in Egypt or outside and the National
Seminars and International Symposiums mentioned above there are other activities, which are mainly
directed to increase the awareness of top and senior management to develop management capacity
both in the private and public sectors and to carry over the concept of management development to
various government departments in order to create the favourable climate for development.
One of the main activities fqr this was the establishment of the "Management Club" in Jan. 1988.
Under its pattonage monthly meetings are held with guest speakers on one of the most interesting
management subjects. These meetings are attended by all members and interested people in various
specializations to exchange opinions between engineers and other specialists working in management.
This gives opportunity to a multi-disciplined meeting which coordinates activities between engineers
and other specialists to form the framework of Project Management.
307
5. Future Activities
A view of Project Management in the futuie:

Project Management as a management concept is well established in the Engineering and Contracting
Industries. Outside these branches it is not used very widely. Unconventional applications of Project
Management techniques, such as factory overhaul, management information system installation or the
formation of intemational joint ventures are almost unknown.
With regard to the advantages which have been achieved from two long term courses in Project
Management which have taken place in Germany sponsored by COO and due to the experiences
gained through cooperation with organizations to "Identify the Training Needs ", it was considered as
a necessity to expand the scope of project management not only to deal with construction activities
but also to extend it towards unconventional items, which help operational management to raise their
performance. Such new fields contain:
- Managing the rehabilitation of plant facilities.
- Installing management information systems.
- Establishing preventive maintenance systems.
- Establishing quality control systems.
- Introducing career development systems.
If this is applied, project management will be· the vehicle for project as well as for enterprise
development.
References
Shannon, R.E.: Engineering Management, Huntsville Alabama.

Extracts from "New Trends in Project Management", INTERNET Proceedings of the 11th
International Expert Seminar: Project Strustures versus Project Performance, April 1987.
308
THE PROJECT AS A MODE OF WORK IN SWEDEN
FROM 1ECHNICAL TIllNKING TO MANAGEMENT TIllNKING
Sten Nordstrom
Abstract
The project as a mode of work goes back to prehistoric times. In modem times the development starts
in the fifties. Today the project is an established mode of work. The trend in the development is partly
from the technically to the management orientated approach and partly from plant project to product
development project.
A sound knowledge and a good ability to cooperate are required not only of project managers and
participants in the project but also of executives and staff in the company's base organization. For the
project manager the development means that specialized knowledge must be complemented with
knowledge of communication, motivation, negotiation and procurement. We have learnt that
knowledge about the environment in which the project is to work is important, as the project must be
able to work in harmony with the project.
What, then, will the development towards the 2000s look like? The development trend will continue.
The project of the future will be an important focus for development, creativity and social intercourse
in addition to productivity and professionalism. New techniques, of which we know nothing today,
will dominate certain of our workplaces. The future is exciting not least for us who work in and with
projects.
1. From Then to Now
Development in the project field has been fascinating and dynamic. By which laws has it been
governed? Two factors deserve to be emphasized. One is INTERNET and the national associations.
The other is the fruitful cooperation between researchers, practicians and consultants not to mention
the curiosity and will to adopt and practice new forms to carry out business shown by many
companies. Originally various methods, techniques and aids for time-planning and financial control
were the focus of attention but by the time this became concentrated on management and
organizational questions, at the same time as the project management discipline was widened by
incorporating methods from other areas like quality assurance. In Sweden the Swedish Project
Management Society "Niltplan" was formed in 1968. The item which then was most discussed was the
application and development of the network planning technique.
The Viggen Project (development of an aircraft fighter) was then going on. Planning and coordination
were carried out using network: techniques and an BDP program which they had developed
themselves. The extension of Sweden's nuclear power stations was started. The coordination was
carried out using network techniques. The EDP program was used to some extent. It can be added that
these aids have been in the retirement during the seventies and eighties but now have started to come
back into fashion again as a result of the development of the personal computer.
The need for management and coordination of these large projects was considerable. A project
manager or, rather, a project coordinator, was appointed. In the seventies we learned to work with a
matrix organization. The project managers' situation was, however, frustrating as they had been given
responsibility without the corresponding authority. In addition, the company management showed
little understanding for the project manager's work situation.
In "stationary" industry projects are still usually run as a matrix organization. Understanding of the
importance of reaching a good balance between line and project has increased. In the "mobile"
industries (building and plant activities) it is traditionally common to work in the project form. The
projects are stronger than the basic organization and one can thus notice a certain imbalance here as
well.
To work in a project is a common form of work today. Project has also become a trend word that cuts
both ways. It is difficult to choose an optimal form of work. It requires both knowledge and maturity.
The choice can be between anything from a pure project organization to carrying out tasks in,the line.
2. Development Trends
2.1 Development
The trend. has been from a technically orientated to a management-orientated approach but also from
plant projects to product development projects. Development in this direction will continue. This
development makes new demands on project managers, project staff and on the organization as a
whole. Specialized knowledge had been and will still be important but the emphasis will more and
more shift towards characteristics like type of leadership and ability to negotiate, communicate,
motivate and handle relations and conflicts in the project work. Old knowledge is however valuable
knowledge. The art of planning, for example is such important as the art of choosing methods and
aids. Methods like stage-by-stage planning from pilot study to winding-up, with well-defined stage
310
goals both from a qualitative and a quantitative point of view are irreplaceable, just to take an
example.
2.2 Trends in Swedish Trade and Industry and Public Administration
Within Swedish trade and industry and public administration the present trend is for the business to be
divided into smaller profit centres. It is very common that these profits centres after some time are
turned into limited companies. This causes an effect not only on the mode of work and the rules of the
line of command like for example increased requirements on the fmancial system and priorities
between internal and external deliveries but also on the handling of projects and on the project
manager. The trend is from a technically-orientated mode of work to a market orientated mode of
work.
This means that project managers and staff must improve their abilities to communicate, motivate,
negotiate and perhaps to persuade. The demand for controllability increases. The trend is from detail
control to target control.
2.3 Training
Training and transfer of experience are important comer-stones in development. The participants in
this field in Sweden are the university and consultants. In company-training is also found. Courses
and part-courses in Project Management are available at university level and are being developed.
Several of our well-reputed consulting companies like ProjektStyrning AB, ProjektTeknik Gunnar
Selin AB, AB Pertab, Wenell Management and others run advanced training within the field.
They were established early on this market and have many years of experience in Project
Management. The quality of the courses is high which can be explained by the fact that apart from
running their courses they also take on assignments. This gives a valuable cross-fertilization and a
transfer of experience. In relation to it~ number of inhabitants Sweden has a considerable number of
courses in project work. However, further efforts are needed. The development of mode of work and
approach for example require that training in project work is integrated with other training within the
companies and at university and high school level.
2.4 Methods and aids
Methods, aids, rules and routines will also be necessary in the future. Development and adaptation to
new approaches and management philosophies must be carried out. This could mean a certain
311
demolition of rules and routines to the advantage of a flexible mode of work which is adapted to the
needs in question. PC-based systems for planning and other routines become more and more flexible.
The CAD technique is being developed into the project's perhaps most important information system
apart from the financial and the office information systems, is making its breakthrough and becoming
an important communication media. The development sketched here is not without its dangers if one
looks at it purely from a technical and system point of view.
Modes of work and fonns of cooperation are affected and must be adapted. Users become more and
more aware and the demands increase. This means, for example, that the computer environment must
be radically improved and that a well thought-out philosophy as regards the use of the systems must
be developed.
3. Research
A large research project has just been finished: The Vasa-Alv Project, a comparison between two
construction projects from the Project Management's point of view. The project was initiated by the
Swedish Project Management Society.
The researcher was Mats Engwall; a summary of some of the most important conclusions is included
as Appendix 1.
See also documentation from INTERNET 88 and NORDNET/INTERNET 89.
As an example of other interesting research "The Fenno-Skan Project" can be mentioned (a. plant for
high-voltage DC transmission between Sweden and Finland). In this project the customer's and the
supplier's way of handling project, fonns of cooperation, drawing-up of borders etc. is being studied.
The research project "Consequences of error during the process of product design and development"
also deserves to be mentioned.
There is also a strong increase in the research within the field. It is mainly concentrated on projects
which are sponsored by enterprises. The advantages are apparent to all parties. It is also worth to be
mentioned that a research group for project organization is being fonned with professor Gunnar Selin
at the Royal Institute of Technology in Stockholm as the prime mover.
Finally some interesting areas of research can be mentioned:
1) How should a company be organized, managed and controlled in order to handle its project
activities efficiently?
312
2) How should the project manager in his specific situation plan and lead the project work in order
to make it efficient and achieve the targets?
4. INTERNET
INTERNET has played an important role in the development of the project as a mode of work.
INTERNET will be needed in the future as well. One overall target is to work internationally for an
optimized utilization of the project as a mode of work and similar modes of work. The national
societies have a corresponding task within their countries. A large and important task is to work as a
catalyst and be a forum for the exchange of knowledge and experience and to function as a
communicator and source of inspiration. The value is increased through a widening of the established
network. This can be done in the future by both initiating and supporting the formation of new
societies and by activating the cooperation with other societies working within the field. Finally,
INTERNET should also turn to new target groups like line managers at various levels and to new
disciplines like humanists.
The Swedish Project Management Society works in this direction. This has recently been indicated by
a change in the bylaws and through a widening of the Society's objectives.
313
Appendix 1
1. The Project Environment and Today's Issues of Project Management
Mats Engwall, Royal Institute of Technology, Stockholm, Sweden.
Today, there is a well developed knowledge of the state of the art of project management. There is a
lot of literature which deals with such questions that have absorbed many researchers all over the
world. In spite of that it seems to be more a rule than an exception that projects (still) are late and/or
exceed the predetermined budget. It is not difficult to find examples of such projects, see for example
Morris & Hough [1]. It is, however, more difficult to imagine that this overrunning depends on
incompetent projects managers alone.
The situations and conditions which govern project managers and project organizations work are
rarely discussed. In project management literature the work of a project is usually treated as a
independent phenomenon without being connected with the other activities of the company. The
project organization is described as an independent, closed system, over which the project manager
has full control and can manage freely without disturbance from other activities. However, such a
situation does not exist in real life. In practice, there are few project managers who are free to plan
and lead the project work without having to give cOnsideration to the company's base organization and
its normal modes of work. Real-life project managers are instead tightly tied and controlled by the
company's traditional hierarchies, organizational forms and mode of operation (for example, it is
probably very rarely that a project manager has the freedom to select his staff himself). However, this
is very sparely dealt with in the literature and in published research results. While many have studied
and described how project management should be carried out, few have described how project
management really is carried out in practice (Le. how the project organization, governed by its own
situation, applies and utilizes current project management techniques and aids).
1.1 Different Project Environments· Different Sets of Rules
The research study "Project Vasa-Alv" is an empirical study where I have followed two major
Swedish investment projects for two years. The purpose was to study each project's internal and
external preconditions and their influence on the project work (see Engwall & Selin. [2], [3]). One of
the projects that has been studied was the construction of the Stockholm World Trade Center
(Vasaterminalen) nearby to Stockholm's Central Railway Station. The other project was the
refurbishment and extension of the Alvkarleby Hydro Power Station in Northern Uppland which was
carried out by the Swedish State Power Board under their own management.
314
There were several similarities between the two projects. For example, both cases dealt with
traditional construction and civil engineering projects, the contract had in both cases the worth of
about SEK one billion, both were turn-key contracts and both project teams had the same majority
owner as their (main) client. Although this the project managers worked under entirely different
conditions.
The decisive differences were not found in the internal work of the project organizations, but in the
interfaces between the project management and the project organizations' surroundings, i.e. in the
project management's collaboration with the client, with their own company management, with the
base organization's other activities and with suppliers, consultants and sub-contractors in the projects.
1.2 An Efficiency Model
In order to study these interface problems we have to change perspective and look at the project
organization and the project work in a perspective from the outside (instead of the traditional inside
perspective), see [4]. In this different perspective the concept "efficient project work" receives a wider
meaning than before. Seen from an outside perspective it is not only a case of the project organization
working as free from friction as possible, but we must also talk in terms of target fulfllment and
evaluation of each specific project in relation to other projects and other concurrent activities in the
company. A model how we should be able to view the efficiency of the project, with this widened
approach, is given in Figure 1.
This efficiency model describes a situation where a project team has been formed within a company
(or corresponding organization) in order to fulfil a task for one of the company's customers. In order
to fulfil the task a number of sub-contractors has been engaged (like consulting firms, contqlCtors,
machine and material suppliers). The project organization's external relations have three main
directions: towards the client, towards the own company's base organization and towards the sub-
contractors. Between the different parts of the project organization there are furthermore internal
relations. The project's effectiveness could thus be regarded as a measurement of well these external
and internal relations work.
315
Vl
......
0\
i
......
>
g, PROJIECT TIEAlVl
l I ~~NS&NTS
~
.9. ~ Internal CLIENT
a In Relation Efficiency In Relation
o E"~~"~~~ Suppliers To The Client
::::l
Al £) EIII,'"",
~
~.
~ UNTRAC10RS
en
en
8.
Efficiency In Relation
~r9J To The Functional
j LV"S
FUNCTIONAL ORGANIZATION
We can thus divide the project effectiveness into four different efficiency criteria (see figure 1).
1. Efficiency towards client

The project organization does the right things. The project's result meets the client's requirements as
regards function, time and cost. The client is satisfied and would be pleased to come back with new
tasks.
2. Efficiency towards the base or~anization

The project corresponds with the interests of the company management both as regards the project's
target and the project organization's methods. The project organization and the base organization
complement and are in harmony with each other.
3.Internal efficiency (in the prqject organization)

The project organization does the right things in the right way. The project organization uses all its
resources in an optimal and economic way.
4, Efficiency towards sYWliers

The project organization and the suppliers cooperate in such a way that efficiency to the client,
internal efficiency and efficiency to the base organization, become as high as possible.
1.3 The Project Environment - the Controlling Factor
If we complement the efficiency model with the most important factors which determine the set of
rules for World Tmde Center's and AIvkarleby's project managers respectively, we get a picture of
two entirely different project environments, with entirely different sets of rules (see figure 2).
One example which manifests this difference was the different degree of focusing on questions of
contmct and agreements in the projects (cf. the controlling factors for effectiveness towards the client
in figur~ 2). In the World Tmde Center Project there were several persons in the all-in contractor's
project organization who actively and continuously looked for any changes and additions in relation to
the client's original contract. These changes concerned two different legal entities and the
compensation for the changes was agreed in direct negotiations between the parties. In the Alvkarleby
Project, however, there was not this commercial relationship between the client and the turn-key
contmctor (the project organization) as they were the same legal entety. Here the turn-key contmctor
worked without any interest in profits of its own and via internal debiting obtained payment in full for
all its costs. Part of the turn-key contractor's undertaking was to look after long-term technical
questions like the operation and maintenance of the power stations. In the AIvkarleby Project, as well
as in the other project, there were discussions regarding the contents of the project and the financial
317
rewards but to nowhere near the same extent or on the same detail level as in the World Trade Center
Project.
Take together the differences between the projects (see Figure 2) meant that the two project managers
we studied, in spite of holding similar posts, worked with entirely different sets of rules. Alongside of
the project manager's direct leadership there are thus many different rules, persons and conditions in
the projects manager's surroundings - the project environment - which have a decisive influence on
the project work and its result. If we are to study and understand the real-world project management
these factors must also be taken into consideration.
Thus the management of a project must be viewed as a wider concept than traditional project
management. It is not enough that the project manager writes ambitious project routines, time plans
and handbooks as long as the project mode of work does not have support in the company and the
company does not have a well thought-out and well supported project strategy. With this approach
various project technicians and aids are only interesting when they are placed in their contexts, i.e. in
the specific project and the project environment in question. The importance of the project manager as
a person for the success of the project is reduced (compared with the traditional outlook on project
management) and the project manager's governing situation and conditions - the set of rules - become
interesting.
318
THE WORLD TRADE CENTER PROJECT
INTERNAL EFFICIENCY EFFICIENCY IN RELATION TO

THE CLIENT
Project oriented
EFFICIENCY IN RELATION team members Demand and competition
TO THE SUPPLIERS rules the market
Wide range of suppliers
The project team keeps
with similar competences
commercial risks
The suppliers keep
The commission does not
long-term engineering
include the production
competence
process of the object
The clients are responsible for

keeping watch over operational
EFFICIENCY IN RELATION TO matters
THE FUNCTIONAL ORGANIZATION
The clients rules the degree of
Extensive skill of project
the object's performance
management
The project team guarantees
Project teams organized as the object for two years of
task forces operation
Projects are profit enterprises
THE HYDRO POWER PROJECT
INTERNAL EFFICIENCY EFFICIENCY IN RELATION TO

THE CLIENT
Object oriented
team members Long-term plans and investment
budgets rules the market
EFFICIENCY IN RELATION The project team takes no

TO THE SUPPLIERS commercial risks '
Short supply of
engineering experts The project commission
includes the production
process of the object
The project team is keeping

watch over operational
EFFICIENCY IN RELATION TO matters
THE FUNCTIONAL ORGANIZATION
The project team rules the
Extensive knowledge of
degree of the object's
the technology of the object
performance
Project teams working in a
The pro:·,-:;t team takes an
functional matrix organization
"endless· functional
responsibility for the object
Projects are non-profit enterprises
Figure 2: Factors which set up the rules of project management in the

World Trade Center and the Alvkarleby Project.
319
1.4. Conclusions
By tradition, the holders of the Project Management paradigm look at project management from an
inside perspective. Consequently, discussions, research and development on project management
emphasize methods and techniques to improve the internal efficiency of projects. Few projects
however, can be characterized as closed systems. On the contrary, project organizations are usually
affected strongly by their environments.
On the other hand the traditional school of General Management provides an outside perspective on
projects and pays attention only to the evaluation of projects as capital expenditures. This dissimilarity
of perspective is a major problem. To solve this, we will have to answer the following questions:
a) The Outside Perspective:

How should a company be organized, managed and controlled in order to pursue projects in an
effective and efficient way?
b) The Inside Perspective:

How should the project manager, from his specific prerequisites, plan and manage the project in
order to achieve efficiency and effectiveness?
References
[1] Morris, P; Hough, G: The Anatomy of Major Projects, London 1987.

[2] Engwall, M, Selin, G: The Vasa-Alv Project. In: INTERNET 88, From Conception to
Completion, Proceedings of the 9th World Congress on Project Management, Glasgow 1988.
[3] Engwell, M; Selin, G: Projektmiljon - den styrande faktorn ? (In Swedish), Stockholm 1989.
[4] Panielsson, A: Foretagsekonomi - En oversikt (In Swedish), 3rd ed., Lund 1983.
320
THE AUTHORS
Riccardo A1bonetti
Born in Italy in 1932. Received a Chemical Engineering degree from the University of Bologna in
1957. Worked with Montecatini Spa as a process engineer from 1957 to 1960. Joined Snamprogetti
Spa in 1961 where he remained until the end of 1988. During this time he had the function of project
engineer, project manager, project director, director of projects, director of project management and
project control dept assistant to the chairman for liaison with the control of affiliated companies. As
project manager and preoject director he was in charge or some very large projects, up to nearly one
billion dollar value, for a single project. From early 1989 he is active as a private consultant in project
. management. He was one of the founders of the Project Management Association of Italy and he is
still an active member of its board.
Born 1924 in Independence, Missouri, USA. MS, mechanical engineering, U. of Texas. President,
Archibald Associates, Consultants in Project Management, 343 Medio Drive, Los Angeles, California
90049, USA. Honored Fellow, Project Management Institute. Certified Management Consultant,
IMC.; Certified Project Management Professional, PMI. Listed, Who's Who In the World. CI~ents in
Europe, North & South America, Asia & the Far East. Author of two books, many articles on project
management
Ivars Avots
Ivars Avots is President of Trans-Global Management Systems Inc. in Arlington, Massachusetts,
USA. He has thirty years of experience in the application of management systems for various types of
projects around the world. He is author of the APS MODEL simulation which has been used to teach
project management to professionals from 45 countries. Prior to starting his own company in 1981, he
was with Arthur D. Little, Inc. and the Boeing Company.
Mr. Avots has published many articles and contributed to books on project management in the United
States and Europe. He has received the McKinsey Award for contribution to management literature,
the Arthur D. Little Presidential Award for effective project leadership, and the Person-of-the-Year
Award from the Project Management Institute.
Mr. Avots is a member of the Board and past Vice-president of INTERNET. He is also a past Vice-
president of the Project Management Institute and founding President of its New England Chapter. He
is President of the Arthur D. Little Alumni Association.
Martin Barnes
Born 1939. Degree in Engineering from University of London, PhD from University of Manchester.
He is a partner in Coopers and Lybrand Deloitte, London, responsible for engineering and
construction project management activities of the firm. Chairman of the Association of Project
Managers (UK).

Born in Eindhoven the Netherlands. Degree in Mechanical Engineering from the Technical University
of Delft. He has been 10 years engaged in PrQduct Development of the Philips Industries in
Eindhoven and thereafter 25 years Efficiency & Organisation Consultant for R,D&E in the same
company. The main subjects have been Project Management, Value Management and Creativty. He
has authored and presented several papers on the occasion of among others various congresses and
seminars of the International Project Management Association INTERNET.
Jiirg Brandenberger
Born 1937 in Zurich. Degree in Mechanical Engineering from Federal Institute of Technology Zurich.
He is partner in the consulting company Brandenberger & Ruosch AG, specialized in project
management and organization. He has authored several publications in the field of project
management.
322
Rieks Broersma
Born in Rotterdam, the Netherlands, in 1948. Degree in civil engineering at the Technical University
of Delft. Senior management consultant for Berenschot Management Consultants. Specific areas are
Project Management, Quality, and Transitions. Author of several articles on project management and
co-makership. Currently performing a PhD study on co-makership.
Sebastian Dworatschek
Born 1941 in Germany. Education: Study in Communication Science at the Technical University
Stuutgart, study of Industrial Engineering at University Aachen, Ph.D. in Operations Research at the
University Aachen. Mr. Dworatschek is manager/partner of a consulting company, director of a
management acadamy and professor for economics at the University Bremen. Mr. Dworatschek has
published several publications in the field of project management and project management software.
Date of Birth: Jan. 20,1915
Degree: 1936 B.Sc. Electrical Engineer, Cairo University
1943 M.Sc. Military Science Graduate Staff College, Egypt
1951 Special one year course in Industrial Administration, Manchester College of Technology
Affiliation: 1977-Present President of Engineering Management Consultants EMCO
1971-1976 International Labour Organisation ILO Project Manager in Iraq. National Centre for
Consultancy and Management development NCCMD.
1962-1969 Minister of Military Production, Egypt.
1953-1962 General Manager & President of Organisation For Military Production.
Main Areas Of Scientific Work: Industry & Management.
Voluntary Activities:President, Management Engineering Society MES
Chairman, Industrial Research Council, Academy of Scientific Research & Technology.
Born 1935 in Cairo. Degree BSc.Mech.Eng. from Cairo University. He is assistant general manager at
the Arab International Bank and vice-chairman of INTERNET. for many years he organized
conferences and conducted training programmes on project management for arab states professionals.
He has authored some articles and research work on project management published internationally
and locally.
323
Morten Fangel
Morton Fangel, a MSc in Civil Engineering and BSc in Business Economy, received his PhD in
Industrial Research in 1973. After six years in consulting engineering firms, he founded Morton
Fangel Management Consultant in 1975. Through practice as well as research, the firm has
specialized in corporation development, project start-up services and project management training. He
has published several books on project planning and management and was President of the Danish
Project Management Association 1980-85. As Vice President of Internet, he is now responsible for
services to the national associations.
Eric Gabriel
Eric Gabriel is a Chartered Engineer by profession, who has been involved in projects and project
management for the last 30 years.
His early career was spent in the power generation industries, fossil and nuclear. He was Chief
Commissioning Engineer for the Berkley and Dungeness A power stations in U.K.. There followed 7
years as Project Planning and Computing Manager for Babcock International. In the next 10 years
with Foster Wheeler he was Manager, Cost & Planning, for projects in the Process and other
industries.
He is currently Project Manager for the Sainsburry Wing, the £35m. extension to the National Gallery
in London.
Bob Gillis
Bob Gillis is president of R. B. Gillis and Associates, consultants in group communication and
application of planning and control methods, which has served industrial, governmental and
institutional clients in eight countries. He has 33 years experience in various management role with
Canadian Pacific Ltd. Mr. Gillis is active in professional organizations concerned with the
management of projects and the management of change. He is a Fellow of the Project Management
Institute. He was a PMI Board member for the annual meeting in 1976, Chairman of the organizing
comrriittee for PMI 76 in Montreal. He was a founder of the Montreal chapter of PMI and served for
many years on the Advisory Committee for that chapter. He is a founding director of Internet, the
International Project Management Asssociation, which coordinates the international work of member
organizations in some 16 countries and is presently the board member responsible for liaison with
PMI. He has been involved as organizer or chairman of World Congress, Seminars and Symposia for
these organizations for the past 18 years, and has presented many papers to both PMI and Internet. He
has been guest lecturer for international organizations and universities and is recognized as an
authority on group processes and project start-up planning.
324
Per Willy Hetland
Born 1945 in Stavanger, Norway. Degrees in Civil Engineering and Business Administration. He has
extensive experience fonn a variety of projects in the civil, mechanical and petroleum industries.
Employed by Statoil, the last 12 years have been devoted to planning and execution of mega projects
in the North Sea. Mr. Hetland is a co-founder and president of the Norwegian Asociation of Project
Management (NFP). He has authored several publications in the field of Project Management.
Alex van den Honert

Born in Indonesia in 1935. Degree in mechanical engineering at the Technical University of Delft.
PhD in applied physics at the same University. Researcher for the Royal Dutch Navy. Nuclear fuel
manufacturer. Internal consultant in the data processing industry. Currently being a management
consultant, increasing internationally, for Berenschot Management Consultants, and a part time
associate professor at the University of Groningen.
Hans Knopfel
Hans Knopfel received his civil engineering diploma in 1965 and graduated in structural analysis and
design. In 1973 he joined the Institute for Engineering and Construction Management, and he is
currently unvolved in the teaching of, and research into, project management at the Dpartment of
Civil Engineering of the Swiss Federal Institute of Technology (ETH) in Zurich. Dr. Knopfel has
acted as consultant on several construction projects, taught as a visiting associate professor and now
also acts as Vice President for INTERNET.
Steen Lichtenberg
Born 1930 in Copenhagen. M.Sc.(Eng.)in 1953 from Copenhagen. Since 1970 Associate professor of
Construction Management and since 1975 an international management cosultant. After ten years'
responsibilities in construction he in 1967 initiated a new "generation" of management principles.
Among several honours he in 1974 received the Dr. of Science degree in Copenhagen. Extensive
national and international activities and responsibilities include e.g. that of elected president, 1985-88,
for the International Project Management Association, INTERNET.
325
Vladimira Machova
Born 1930 in Prague. Degree in Mathematical Statistic from Charles University in Prague. PhD in
Econometries methods on Economical University in Prague. She is a specialist in project management
research and investment She has dealt with preparation and attesting to managers. She is the Board
member of INTERNET-IPMA from the very beginning.
David Mathie
Born in Sydney, Australia. David Mathie is an electronic engineer by profession. He is an INTERNET
Board Member, a founding member and president ex-ufficio (1987-1989) of the Italian ANIP Project
Management Association. Founder and CEO of CPM, Torino, Italy he has been consulting in project
management for over 15 years. His management experience covers a wide spectrum of industry from
petro-chemicals through nuclear power to aerospace, defence and telecommunications. As part of his
current main assignment he is the Industrial Architect for management to the Science Division of the
European Space Agency at ESTEC.
Dietrich Miiller
Dietrich Muller, Dipl.Math. is born 1940.
Education: Study of Mathematics at University of Freiburg (FRG)
Professional Development: 1966-1986 Dornier Company Friedrichshafen; at first system analyst in
the EDP-center; 1970 head of department in the area of management systems; from 1972 responsible
for development, application and training or PPS - Project Planning and Control Systems; later on
head of management systems with focal points on project management and military command control
and communication systems (C3-systems). Since 1986 professor at the Polytechnic in Reutlingen:
Foundations of computer science, programming languages, data base systems, software engineering
and project management.
SteD Nordstrom
Born 1923 in Stockholm. Diploma as electric engineer and economist. Employed by Swedish State
Power Board. Among other positions, he is manager of a project planning and cost control
department. He was former president of the Swedish Project Management Society. Actually Sten
Nordstrom is consultant in project management.
326
Gerold Patzak
Gerold Patzak:, born 1939 in Vienna, Austria, studies of Mechanical Engineering and Industrial
Engineering at the Technical University of Vienna, 1965 Master's Degree in Engineering, 1971 PhD-
Degree in Reliability Engineering, 1977 Habilitation (Associate Professor) in the field of Systems
Engineering and Organization. 1985 Full Professor for Systems Engineering and Methodology at the
Technical University of Vienna. Lecturer at the University of Economics and Business Administrator
in Vienna and at the Johannes Kepler University in Linz, Austria.
Visiting Professor at the Georgia Institute of Technology, School of Industrial and Systems
Engineering, Atlanta, USA, in the years 1971n2 and 1977n8. Visiting Professor at the Virginia
Polytechnic Institute and State University, Department of Industrial Engineering and nOR in 1989/90
and 1990/91. Professional Engineer in the field of Industrial Engineering and Engineering
Management, variety of consulting and training activities in industry. Vice President of the Project
Management Austria Institute. Several publications in the field of Systems Engineering, like on
Reliability Theory, Simulation and Project Management.
Hasso Reschke
Born 1941 in Germany. Education: Study of Economics at the University of Munich. Ph.D. in
Economics. From 1967-72 scientific assistant in a project-group at Domier. Contracts Officer at the
European Space Agency, Nordwijk (NL), from 1975 Professor for Economics at highschools in
Landshut and Munich. Several Publications in project organization. Mr. Reschke is member of the
board of the german project management association (GPM).
Wolfgang Schallehn
1936 born in Dresden, GDR. 1954-60 Study of civil engineering at the university of Leipzig. 1970
Lecturer on information science in civil engineering. 1975 Visiting professor at the college of civil
engineering in Moscow (MISI). 1985-1990 President of the committee of project guidance (chamber
of technology in GDR). 1990 First chairman of the board of "Gesellschaft fUr Projektmanagement
INTERNETDDRe.V."
Heinz Schelle
Born 1938 in Germany. Education: Study of national-economics at the University of Munich, M.Sc.,
Ph.D ..From 1963-1968 scientific assistant at the University of Munich. From 1969-1975 at Siemens
AG Munich responsible for research in the fields of project management, communication, prognosis
and simulation. From 1975 professor for economics and project management at the University of
327
federal armed forces. Many publications in the field of project management. Mr. Schelle is founder
member of the board of the german project manageplent association (GPM).
AdolfSchub
Born 1931 in Berlin. Dipl.-Ing. in Civil Engineering from the Technichal University-Munich (TUM),
1957. Dr.-Ing. at the TUM 1965. Professor for Construction Management at the TUM since 1974. His
research interests are: project scheduling and monitoring, cost control and forecasting, applied
production theory, decision models, expert systems and project management. He is the author of
numerous papers in professional journals, has co-authored three books concerning construction
management, and co-editored a standard handbook of project management.
Juhani Silvasti
Born in 1942; 1968 M.Sc., Mechanical Engineering at the Helsinki University of Technology. Juhani
Silvasti is specialist in project management of investment projects as well as cost control, scheduling
and resource control. He is also specialist in training of project staff in the field of project
management, project planning and control. From 1981-87 he was president of Project Management
Association of Finland and from 1982-88 he was member of the Board of INTERNET.
Geoffrey Trimble
Geoffrey Trimble is a Professor Emeritus of Loughborough University England and a consultant to
Northcroft. In the period 1967 to 1989 he held the appointment of Professor of Construction
Management and was responsible for postgraduate teaching in this subject and research and
consulting. Prior to 1967 he held appointments with the PE Consulting Group, Dve Arup & Partners,
Scott & Wilson, Kirkpatrick & Partners, Costains and Wimpeys.
His consulting work includes, the Victoria Line in London, the main line from London to
Bournemouth, the Hong Kong Mass Transit Railway, North Sea productivity studies and various
hospital and local authority projects. He was founder President of the Association of Project Managers
and founder Vice-President of INTERNET.
R. Max Wideman
Mr. Wideman is a registered professional civil engineer specializing in project management
consulting. Since graduating in civil engineering at London University, his experience has included
hydro-electric, river, marine, transportation, industrial, institutional, commercial and residential
construction projects. As Project Director, Project Manager, or Manager of Project Services, he has
328
worked variously for gouvernment, manufacturing industtry, consulting engineers, developers, and
general contractors.
Mr. Wideman has aslo been instrumental in managing social and environmental impact studies and
major contract and expropriation claims. Thus, he has gained a broad perspective and insight into the
project management process, and has contributed to the project management capability of clients in
both the public and private sectors.Mr. Wideman is a Fellow or the Engineering Institute of Canada, a
Fellow of the Institution of Civil Engineers (UK) and a Fellow of the Project Management Institute
(US).
329
INDEX
Activity durations, 152 Computer integrated project management

Accounting cycles, 209 (CIPM),36
ACWP,163 Concern wide quality improvement (CWQD,
Alternative planning, 187 103
Ancient egyptian projects, pp.275 Conditional uncertainty, 148
APM,18 Configuration management, 29
Approximation methods, 124 Constructability,260
Areas of decisions, 207 Construction management, pp.169,283
Construction projects, pp.257
Contingency, 6
Contingency planning, 102,268
Bar charts, 127,220 Contracting, 29
Bayesian statistical concept, 148 Contracting policy, 269
Benefit management, 16 Contract management, 16
Bid estimates, 149 Control cycles, 207,208
Bottom-up procedure, 26 Control estimate, 164
Brainstorm, 152 Corporate strategy, pp.85,pp.201
Bridge financing, 268 Corresponding horizons, 210,211
Budget, 6,9 Cost(s)
Budgeting, 39 - accounting, 132
Business risks, 268,270 - accounting system, 220
- benefit analysis, 183,191
- benefit ratio, 131
- control, 15,20,39,131,259
Carl Disberg Gesellschaft (CDG), 305,308 - efficiency, 162
Cash flow requirements, 268 - engineering, 105
Computer aided design (CAD), 180,259,312 - estimation, 108,130,131,145,148
Capacity planning, 113 - estimation, standards for, 163
Certainty equivalent, 166 - forecasts, 129,133
Claim management, 29 - management, 15,16
Client(s),7,16,20,pp.257 - optimization, 130
- key role of, pp.257 - planning, 15,pp.129
- preferences of, 21 - prognosis, 151
COCOMO,129 - reductions, 101
Co-development, pp.247 Critical path method (CPM), 25,39,220
- management areas of, 249 CTR-sheets,162
- relations, 251,254 Czechoslovak scientific management
Comakership see co-development committee, 295
Communication management, 282
Computer aided education (CAE), 235
Computer aided project management training,
237 DAM (program), 179
Computer support, 15 Data base systems, 16
Data bank: dialogue software, 190 General objective, 241
Determination of work progress, 132 German society for value analysis, 108
Decision box method, 123 GERT,123
Decision calculus, 117 Gesellschaft fUr Projekt Management (GPM),
Decision making process, 11 112,306
Decision support systems, 117,159 Giza pyramids, 277,278
Decision tree, 172,173 Graphe de produit, 103
Degree of detailing, 147 Great Pyramid project, pp.276
Degree of planning, 144
Delegation, 11
Design to cost, 130
Detailed planning, 227 Hidden agenda items, 229
Deutsche Gesellschaft fUr Operations Hierarchical organizations, 201
Research, 112 Hybrid systems, pp.l71
Development project, 101,265 -logic numeric, 174
DFA (Design for assembly), 103 - logic numeric logic, 178
Distributed data processing (DDP), 185 - numeric logic, 176
Dominant objective, 9
DP officer, 194
Dynamic scheduling, 166
IMHOTEP,275
Impact management work session, 225
Individual data processing (IDP), 185,194
Ecological impact, 268 Inference mechanism, 171
Economic objectives, 258 INFOLOG,41,44,48
Economy of Egypt, 283 Information management, 186
ECWP,163 Information research management (IRM), 194
ECWS,163 Information table, 43
Efficiency, 161 Information technologies, 186
- measure of, 161 INSIGHT2+ (program), 175,179
- model, 315 Integrated project management approach, 103
- tools, pp.99 Integrated planning, 150
Egyptian Society of Engineers (ESE), 300,301 Interested parties, pp.239
Environment see project environment - external, 239,240
European Construction Institute (ECn, - internal, 239,240
260,261,263 International Expert Seminars, 21
Event-on-node-network,124 International project management association,
Expert system(s), 117,135,pp.169,263 99
- applications, 169 International symposiums, 306,307
- in design, 263 INTERNET,
- objectives of, 171 21,102,103,155,157,222,296,297,299,300,306
- shell, 175 309,313
European association of networkpla,nning, 103 - proceedings of, 112
Inter-organizational product development,
pp.247
Failure mode and effect analysis (FMEA), 104

FAST-diagramming, 103
Financing methods, 268 Key project interface events, 228
First international management congress, Key project team members, 223
291,293,295 Knowledge base, 171
Ford-Fulkerson algorithm, 131 Knowledge based systems, 169
Functional ,managers, 219 KSP (program), 174,176,177
Functional project leader, 223 K&T-problem analysis, 103
Functional project software, 190
Funding sources, 268
Funding strategy, 268,269
Generalized activity network method, 123
332
Leadership, 11 - explicit, 93,95,96
Life cycle see project life cycle - external, 96
List of options, 8 - identification of, pp.93
Main cycles, 207,208 - implicit, 94,95,96
Major sub-projects, 231 - instrumental, 96
Management - internal, 93,96
- by projects, 159,pp.201 - main, 94
- Cub, 307 - multidimensional, 16
- Engineering Society (MES), pp.299 - planning, 187
- functions, 35 - of the company, 96,97
- information system (MIS), 185 - priorities of, 94
- of interested parties, pp.239 - valid, 93
- plan for interested parties, 244 - system, 28
- subsystems, 45 Office automation system, 186
- systems, 99 Operating cycles, 207,208
- tools, evolution of, 99 Operational manager, 3033,304
Masaryk academy of work, 293,294 Operation management, 303,3304
Master control estimate, 164 Operations research, 101,pp.lll,139,185,296
Masterplan, 152 Optimum level of confidence, 166
Master schedule, 227,228,231 Optimum resource constrained scheduling,
Measurement of progress, 269 111,112,113
Mega projects, 141,230,231 Optimum time compression, 111,114
MEMI (program), 175, Original programme, 7
MESA, pp.202 Original budget, 7
- cycles, 209
- hierarchies, 204
- implementation, 213
Methodical product development (MDP), 103 Parameter Tripod, 32
Milestones, 162 Parametric cost estimation, 112
Money contingency, 10 Performance
Monitoring, 269 - objective, 4
- the external environment, 270 - standards, 1633
- the progress, 270 Permanent organization, 16,20
Multi-project environment, 97 Personal computer (PC), 183
Multi-project planning, 126,127,128 PERT, 25,39,40,124,220
Multi-system conditions, 16 PERT/COST, 115
Multi-user conditions, 16 Phase(s), 19
- conceptual-, 27,99
- design-, 27
- development, 99,101
NASA, 306 - engineering, 101
National seminars, 306,307 - implementation-, 27
Network - integration-, 27
- analysis, 3,111,127,296 - maintenance, 99
- planning, 40,100,104,220 - objectives definition-, 27
- planning package, 184 - operation-, 27
- planning software, 190 -production/acquisition-,27
- schedule, 159 - realization-, 27,99
- technique, 121,125 - removal-, 27
North Sea Oil developments, 259 - restitution-, 27
NT (program), 175 - system defmition-, 27
Phasing, 249,267
Physical progress, 161
- reporting of, 161
Objective(s),16,28,152,160,267 Planning documents, 227
- and programmes, 97 Planning procedure, 144
- budget, 94 Planning process facilitator, 226
- cycles, 207,208 Planning session, 226,229
333
Planning theater, 224 - leader, function of, 157
PMI, 155 -life cycle, 19,27,249,251
Policy constraints, 268 -life cycle costing, 258
Political constraints, 268 - life cycle cost prognosis, 117
PRICE, 129 - managers, 159,pp.220,233
Principal-supplier-life cycle, 250 - manager, authority of, 270
Principal-supplier-relationship, - manager, mandate of, 269
247,248,251,253 - manager, role in team planning, 226
Problem solving process, 169,170 - manager, selection of
Process network hierarchy, 205 - master schedule, 220
Process planning, 187 - model, deterministic, 123
Product(s) - objectives see objectives
- development, pp.247 - organization, 15,16,20,29,125
- development, efficiency of, 99 - organization (acting system), 28
- development quality, 251 - parameter, 121,128
-life cycle, 99,100,104,105 - participants, 93
- orientation, 249 - phase, see phase
Production factor information, 184 - planning, 36,95,127,219
Production function, 180 - planning, traditional, 220
Production planning, 127 - planning (system oriented model), 25
Production technologies, 186 - predefinition, 208
Professional training, 134 - process, pp.27,122
Progress control, 131 - process models, 122
Project - process planning, 122
- acting system, 33 - progress, 31
- administering phase, 34,35 - PR-Work, 29
- assessment, 133 - rebuilding phase, 3
- breakdown structure (PBS), 220 - R&D-, 112
- budget, 166 - risk analysis see risk
- catastrophies, 138 - scope, 15
- close down phase, 34,36 - selection, 111,113
- conditions, 93,97 - service contractor (PSC), 162
- constraints, 93 - simulation, 111
- control, 97,132,pp. 159 - software, pp. 183
- controllability, 164 - software, application of, pp. 183
- controlling, 36 - stakeholders see stakeholders
- control science, 159 - start-up, 34,35,103,133,134,219,222
- coordination phase, 34 - start-up checklist, 222
- costs see costs - start-up workshop, 227,229
- crisis phase, 34,36 - status, 132,13
- decisions, 147 - status assessment, 133
- definition, 130,220 - stream of, 203
- documents, 93,94 - success, 20
- duration, 124 - team, 20,29,pp.219,233
- environment, 13,16,pp.51,152,314,317 - team, multi-disciplinary, 219
- environment, managing the, pp.51 - team planning, pp.219
- environment (economical-technical), 29 - team planning, benefits of, 230
- environment (natural), 29 - team planning, limitations of, 230
- environment (physical), 40,51 - team planning process, 222
- environment (socio-culutural-political), - team planning session, 223
29,40,51 - team planning start-up work shop, 228
- execution, 30 - total system view of, 42
- execution (input/output model), 26 Project management
- financing, 13 - and operation management, 303
- goals see objectives - and operations research, pp.111
- handbook, 229 - application of, 155,156
- interfaces, 249 - application of knowledge in, pp.155
-leader, 267 - alternative concepts of, 140
334
- assessment, 20 Pyramid project management, 282
- associations, 21
- change of, 13
- certification programmes for, 17 Quality
- competencies of, 19 - assurance, 159
- control perspectives on, pp.159 - control, 101,159
- course material for, 17 - improvement, 101
- culture, 20,233 - management, 16,159
- decisions, 147 - management systems, 101
- defmition of, 4,52 - testing equipment, 101
- development of, 155
- development of methods in, 121
- fundamentals of, pp.3
- history of, 276 R,D&E-process, pp.99
- in ancient Egypt, pp.275 Related projects, 267
- in Czechoslovakia, pp.291 Replanning, 153
- in developing countries, pp.299 Residual quantities, 211,212,213
- in Egypt, 299 Resource(s),5,8,pp.39,pp.125
- in Sweden, pp.309 - additional, 161
- informal definition of, 141 - analysis, 125,126,127,128
- information system, 235 - analysis, EDP-support for, 127
- institute, 52 - analysis software, 128
- instrumental, pp.30 - allocation, 39,46,47
- knowledge (framework model), 26 - allocation (process diagram), 47
- methods in Czechoslov!lkia, 296 - constraints, 268
- model of, 34 - estimates, 220
- model simulator, 236 - financial, 33
- modules of, 17 - human, 33
- multi-, 16 - limited scheduling, 126
- new logic in, pp.137 - levelling, 126
- objectives, 5,9,11 - management, 48,282
- operational, pp.29 - planning, 116,117
- participants, 52 - pool, 47
- perestroika of, 15 - scheduling, 45
- paradigm - smoothing, 1126
- phases, 33,34 - technical, 33
- principles of, 13 - type, 126
- process, 229 Revised project level structure diagram, 46
- seminar, 236 Reporting, 29
- software packages for, 116,127,235,236 Risk(s), pp.149
- standards for, 17 - adjusted forecast, 166
- status of, 157 - analysis, 111,149
- strategic, pp.29 - assessment, 102
- struturing, 25 - buffer, 166
- styles, 141 - engineering, 105
- system approach to, 27,5 - factors in cost planning, 130
- systematic framework of, 17 - management, 15,29,104,263,268,282
- systems (PMS), pp.39 - model, 165
- techniques of, 3,6 - source of, 149
- training see training -sharing,268
- trends in, 143
- usefulness of, 13
- within the system context, 39
Pyramid building, pp.275 Schedule planning see scheduling
Pyramid building technology, 276 Schedule uncertainties, 125
Pyramids construction, 285 Scheduling, 15,39,46,122,123
Pyramid design complexity, 283 Semi automation, 128
Pyramid project building objectives, 282 Senior management, pp.265
335
Sequence of decisions, 206
Social impact, 268 Team planning workshop, 219
Society of american value engineers, 103 Teamwork, 271
Spontaneity and planning, pp.186 Technical coordination, 15
Spontaneity in systems selection, 183 Technical management, 34,37,291,292
Spin-off benefits, 267 Telecommunications, 186
SPRINT program, 103 Telecommunications software, 190
Stage-by-stage planning, 310 TERKON (program), 178,179
Stakeholder, 51,268 Three-time-estimate see triple estimate
- analysis, 29 Time
Start-up planning, 272 - buffer, 165,166
Start-up sessions, 150 - control, 20,259
- content of, 152 - prognosis, 151
Steering group, pp.265 - scheduling see scheduling
- implementation tasks of, 270 - window, 267
- make up of, 266 Top-down planning, 227
- planning tasks of, 267 Top-down procedure, 25
Stochastical analysis of project costs, 163 Top level project plans, 227
Stochastic network analysis, 111,112,114 Top management, 265
Stones transport management, 287 Total quality management (TQM), 159
Strategic alliance, 255 Total system level structure, 45
Succesive principle, pp.147 Trade-off priorities, 267
- applications of, 148 Training, pp.233,311
- basic procedure of, 148 Training of managers, 297
- experiences of, 148 Training programme, 234,235
Succesive scheduling, 153 Training tool, 235
Swedish project management society Tree structure, 26
(Niitplan),310 Triple estimate, 124,152
SWOT-analysis, 242,243
System(s), 18
- analysis approach, 48
- approach, 25,40 Uncertainty, 9, 123,pp. 147
- breakdown of, 25 - source of, 149
- context, 25 User behavior, 189
- designing, 170 User organization, 186
- engineering, 170
- environment, 28,29
- internal relations of, 25
- optimizing, 28 Value adding partnership, 255
- requirements, 44 Value analysis (VA), 100,101,103,108
- specification, 43 V alue .~ngineering, 105
- structure (hierarchical), 18 Vasa-Alv project, 312,314
- sub-, 19 Viggen project, 310
- with pure logic, 172 VOB (program), 173,175
- with pure numeric, 173
Work breakdown structure (WBS), 40,220,228

Task force, 262 Working horizons, 209
Teachware,190 Workplace software, 190,192
Team memory, 226 Workshop, 236
Team planning, pp.219 World Management Council (CIOS), 295
336

MARTIN 1 Dikompresi

Uploaded by

Copyright:

Available Formats

MARTIN 1 Dikompresi

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MARTIN 1 Dikompresi

Uploaded by

Copyright:

Available Formats

H. Reschke· H. Schelle (Eds.

Publication in Honour of Roland W Gutsch

ISB'i 978-3-540-53157-9 ISB'i 978-3-642-49344-7 (eBook)

2362/3020:-543210 - Printed on acid-free paper

Munich, August 1990 Hasso Reschke Heinz Schelle

In the name of all congratulators, the Editors

FUNDAMENTALS OF PROJECT MANAGEMENT

THE FUNDAMENTALS OF PROJECT MANAGEMENT

CHANGE AND USEFULNESS OF PROJECT MANAGEMENT

PROJECT MANAGEMENT PARADIGM" A SYSTEM ORIENTED MODEL OF PROJECT

PROJECT MANAGEMENT WITHIN THE SYSTEMS CONTEXT

MANAGING THE PROJECT ENVIRONMENT

THE CULTURAL DIMENSION OF PROJECT MANAGEMENT

THE VIKING APPROACH TO PROJECT MANAGEMENT

PROJECT MANAGEMENT TECHNIQUES

PROJECT OBJECTIVES IDENTIFICATION AND PROPER FORMULATION FOR

THE EVOLUTION OF MANAGEMENT TOOLS AND THE EFFICIENCY OF PRODUKT

1. Introduction: Operations Research and Project Management. . . . . . . . . . . . . . . . . . . .111

DEVELOPMENT OF METHODS IN PROJECT MANAGEMENT - A SUBJECT FOR

EXPERIENCES FROM A NEW LOGIC IN PROJECT MANAGEMENT

THE APPLICATION OF KNOWLEDGE IN PROJECT-MANAGEMENT

CONTROL PERSPECTIVES ON PROJECT MANAGEMENT

1. From Planning Experts to Project Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

DEVELOPING KNOWLEDGE BASED SYSTEMS IN CONSTRUCTION MANAGEMENT

1. Preliminary Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

MANAGEMENT BY PROJECTS - A TURN AWAY FROM OR TOWARDS HIERARCHY

1. "Management by Projects" - a Phantastic Idea! . . . . . . . . . . . . . . . . . . . . . . . . . . .. 201

PROJECT MANAGEMENT ORGANIZATION

PROJECT TEAM PLANNING: THE NEED, METHODS AND BENEFITS

1. The Need for Project Team Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219

MANAGEMENT OF INTERSTED PARTIES

CO-DEVELOPMENT - A FUTURE FOR INTER-ORGANIZATIONAL PRODUCT AND

THE KEY ROLE OF THE CLIENT OR OWNER IN THE MANAGEMENT OF

APPLICATION OF PROJECT -MANAGEMENT

PROJECT MANAGEMENT AS PERCEIVED FROM ANCIENT EGYPTIAN PROJECTS

1. The Start of Pyramid Building Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

PROJECT MANAGEMENT IN CZECHOSLOVAKIA

1. Project Management Development in Czechoslovakia . . . . . . . . . . . . . . . . . . . . . . . 291

THE PROJECT AS A MODE OF WORK IN SWEDEN - FROM TECHNICAL THEINKING

THE AUTORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321

THE FUNDAMENTALS OF PROJECT MANAGEMENT

CHANGE AND USEFULNESS OF PROJECT MANAGEMENT

PROJECT MANAGEMENT PARADIGM - A SYSTEM ORIENTED MODEL OF PROJECT

PROJECT MANAGEMENT WITHIN THE SYSTEMS CONTEXT

MANAGING THE PROJECT ENVIRONMENT

THE CULTURAL DIMENSION OF PROJECT MANAGEMENT

THE VIKING APPROACH TO PROJECT MANAGEMENT

PROJECT MANAGEMENT AND CORPORATE STRATEGY

2. A Definition of Project Management

3. The Basic Propositions

(a) The task which is the project is made up of separate activities.

4. But What Does a Project Manager Actually Do?

The First Law

The Second Law

6. Project Managers Need Space

The plan we are working to now is based on

It is not c1ever/masculine/foresighted/respectable to be still on the original programme. It is

STAGE ONE - Recognize the need for a decision:

STAGE TWO - List the options: