Project Management Handbook - Agile - Traditional - Hybrid-Springer (2023)

Management for Professionals
Jürg Kuster · Christian Bachmann ·

Mike Hubmann · Robert Lippmann ·
Patrick Schneider
Project
Management
Handbook
Agile – Traditional – Hybrid
Second Edition
The Springer series Management for Professionals comprises high-level business
and management books for executives. The authors are experienced business
professionals and renowned professors who combine scientific background, best
practice, and entrepreneurial vision to provide powerful insights into how to achieve
business excellence.
Jürg Kuster • Christian Bachmann •
Mike Hubmann • Robert Lippmann •
Patrick Schneider
Project Management
Handbook
Agile – Traditional – Hybrid
Second Edition
Jürg Kuster Christian Bachmann
Zürich, Switzerland Rapperswil-Jona, Switzerland
Mike Hubmann Robert Lippmann

Liebefeld, Switzerland Männedorf, Switzerland
Patrick Schneider
Nussbaumen TG, Switzerland
ISSN 2192-8096 ISSN 2192-810X (electronic)

ISBN 978-3-662-66210-6 ISBN 978-3-662-66211-3 (eBook)
https://doi.org/10.1007/978-3-662-66211-3
# Springer-Verlag GmbH Germany, part of Springer Nature 2015, 2023

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology
now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
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.
The publisher, the authors, and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or
the editors give a warranty, expressed or implied, with respect to the material contained herein or for any
errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.
This Springer imprint is published by the registered company Springer-Verlag GmbH, DE, part of
Springer Nature.
The registered company address is: Heidelberger Platz 3, 14197 Berlin, Germany
Preface to the Second Edition
This second, entirely revised edition of the “Project Management Handbook” is

based on the fundamentals of the previous standard work and is aligned with the
German 5th edition. It now covers a large number of new or updated topics. The
handbook contains insights and recommendations from our everyday practice as
project managers and project coaches as well as from our teaching activities in
project management. We are particularly pleased that this work is not just the sum of
contributions penned by different authors, but that we thoroughly exchanged ideas
as a team and structured and developed contents together.
We have conducted both public and company-specific training on project man-
agement for over 10,000 participants in more than 200 companies and organisations
in Switzerland, Germany, and Austria, and carried out development work to promote
project management competence in these organisations. It is therefore fair to say that
this work reflects both the current and future practice of project management.
One of the major trends in recent years is that not only proven leadership
structures with their concepts and processes are in demand, but that also temporary
structures are increasingly being used in order to be able to act more quickly and
flexibly. Hierarchical leadership relationships are being replaced by holacratic
systems with flexible role models and forms of cooperation with a high degree of
self-organisation. Project management is strongly affected by this development. We
have implemented this new reality with a clearly recognisable reader guidance. This
not only distinguishes between agile and traditional project management, but also
delves into their combination, namely hybrid project management. We as authors are
convinced that the future lies in the golden mean. It is not about a traditional or agile
approach, but about a situationally skilful combination of both agile and traditional
elements.
Another novelty are real project documents, which we have included in this book
as practical examples. For this we would like to thank the transport company BLS,
namely Daniel Hofer, Irina Schneider, Daniel Leuenberger, and Marc Zesiger, and
Metrohm AG, the Swiss manufacturer of precision instruments for chemical analy-
sis, namely Patrick Hunziker, Christian Feuerlein, and Michael Edelmann.
Our great thanks are due to the authors Eugen Huber, Emil Schneider, and Urs
Witschi, who have gone into well-deserved retirement, and to the late Alphons
Schmid and Roger Wüst, who over many years have played a notable role in shaping
v
vi Preface to the Second Edition
the contents of this book and also the Beratungs- und Weiterbildungsinstitut BWI
AG in the field of project management.
Structure of This Book
Various structural elements simplify the application of this comprehensive work in

practice. The Project Management Compass serves as a detailed orientation guide
for project management and presents two different process models for agile and
traditionally managed projects.
The success of complex, interdisciplinary projects requires an increasingly wide
range of competences, especially from the project manager. That is why we link the
methodological foundations to the people who implement the project with a team.
The domains “methodology”, “people”, “leadership,” and “team” interact with each
other. That is why the content of this book is divided into the following chapters:
1. Introduction: Project management at a glance and in a leadership context

2. Methodology: Models and working methodology for handling agile, traditional,
and hybrid projects
3. Human: Essential characteristics of people as designers of projects
4. Leadership: Models and methods of leading projects
5. Teams: Aspects of successful team development and cooperation
This work has also been updated with a view to IPMA certification and offers a
comprehensive reference table for all competence elements of the Individual Com-
petence Baseline of IPMA® (ICB4) in Chap. 6.
We wish you many new insights through reading this book and the success you
desire for your future projects.
Zürich, Switzerland Jürg Kuster

Rapperswil-Jona, Switzerland Christian Bachmann
Liebefeld, Switzerland Mike Hubmann
Männedorf, Switzerland Robert Lippmann
Nussbaumen TG, Switzerland Patrick Schneider
February 2023
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Project Management, What for? . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 The Taylor Tub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 BANI Is the New VUCA . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 What are Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Project Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Project Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Emergence of Projects . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 What Is Project Management? . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Hierarchies in Project Management . . . . . . . . . . . . . . . . 9
1.3.2 Dimensions in Project Management . . . . . . . . . . . . . . . . 10
1.3.3 Principles of Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Process Models in Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.1 Agile Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.2 Traditional Approach: Phase Concept . . . . . . . . . . . . . . 18
1.4.3 Hybrid Project Management . . . . . . . . . . . . . . . . . . . . . 23
1.4.4 Procedure in Change Projects . . . . . . . . . . . . . . . . . . . . 24
1.4.5 Further Process Models . . . . . . . . . . . . . . . . . . . . . . . . 24
1.4.6 Choice of a Process Model: Traditional, Agile
or Hybrid? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.5 Projects are Based on Teamwork . . . . . . . . . . . . . . . . . . . . . . . . 29
1.5.1 Content: Working in the System . . . . . . . . . . . . . . . . . . 29
1.5.2 Organisation and Relationship: Working on the
System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.5.3 Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.6 Projects are Social Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.6.1 Taylorism in our Heads . . . . . . . . . . . . . . . . . . . . . . . . 32
1.6.2 Mechanistic and Systemic World View . . . . . . . . . . . . . 32
1.6.3 People and Teams Are Non-Trivial Systems . . . . . . . . . 34
1.6.4 Systemic Approach to Project Management . . . . . . . . . . 35
1.7 Versatility and Creativity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.7.1 Versatility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.7.2 Creativity as a Surplus of Attention . . . . . . . . . . . . . . . . 37
vii
viii Contents
1.7.3 Interplay Between Human, Field and Domain . . . . . . . . 38

1.7.4 Framework Conditions for Creativity . . . . . . . . . . . . . . . 40
1.8 Standards and Certification Models in Project Management . . . . . 41
1.8.1 IPMA: International Project Management
Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.8.2 PMI: Project Management Institute . . . . . . . . . . . . . . . . 43
1.8.3 PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.8.4 Hermes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
1.8.5 Scrum Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.8.6 DIN 69901 and ISO 21500 . . . . . . . . . . . . . . . . . . . . . . 46
1.9 Project Portfolio, Multi-Project and Programme
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Further Readings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.1.1 Traditional, Agile and Hybrid . . . . . . . . . . . . . . . . . . . . 49
2.1.2 Accuracy of Estimates . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.1.3 Practical Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.2 Project Commissioning Phase . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.2.1 What Is Important in the Commissioning Phase? . . . . . . 57
2.2.2 Project Factsheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.2.3 Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.2.4 Project Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.2.5 Checklist Completion Project Commissioning . . . . . . . . 61
2.3 Initialisation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.3.1 What is Important in the Initialisation Phase? . . . . . . . . . 62
2.3.2 Setting Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.3.3 Requirements, Requirements Engineering . . . . . . . . . . . 72
2.3.4 The Magic Triangle . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.3.5 Stakeholder Management . . . . . . . . . . . . . . . . . . . . . . . 79
2.3.6 Project Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.3.7 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.3.8 Project Organisation, Roles, Committees . . . . . . . . . . . . 91
2.3.9 Information Gathering and Situation Analysis . . . . . . . . 111
2.3.10 Project Structuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
2.3.11 Project Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
2.3.12 Project Manual, Project Management Plan . . . . . . . . . . . 128
2.3.13 Kick-Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
2.3.14 Problem-Solving Process . . . . . . . . . . . . . . . . . . . . . . . 130
2.3.15 Checklist Completion Initialisation Phase . . . . . . . . . . . 134
2.4 Concept Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
2.4.1 What Is Important in the Concept Phase? . . . . . . . . . . . . 136
2.4.2 Product Goal (Product Concept) . . . . . . . . . . . . . . . . . . 139
2.4.3 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Contents ix
2.4.4 Release Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

2.4.5 Requirements Specification: Solution Concept . . . . . . . . 143
2.4.6 Effort Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
2.4.7 Schedule and Timetable . . . . . . . . . . . . . . . . . . . . . . . . 149
2.4.8 Resource Deployment Plan and Resource
Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
2.4.9 Cost Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
2.4.10 Information, Communication, and Documentation . . . . . 162
2.4.11 Quality Management . . . . . . . . . . . . . . . . . . . . . . . . . . 164
2.4.12 Checklist Completion Concept Phase . . . . . . . . . . . . . . 166
2.5 Realisation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
2.5.1 What Is Important in the Realisation Phase? . . . . . . . . . . 167
2.5.2 Sprint Planning, Sprint Backlog . . . . . . . . . . . . . . . . . . 169
2.5.3 Sprint Implementation, Daily Scrum . . . . . . . . . . . . . . . 172
2.5.4 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
2.5.5 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
2.5.6 Project Controlling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
2.5.7 Deadline, Cost and Resource Control . . . . . . . . . . . . . . 184
2.5.8 Project Changes, Change Request Management, Claim
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
2.5.9 Checklist Completion Realisation Phase . . . . . . . . . . . . 193
2.6 Introduction Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
2.6.1 What Is Important in the Introduction Phase? . . . . . . . . . 194
2.6.2 Types of Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 196
2.6.3 Acceptance and Commissioning . . . . . . . . . . . . . . . . . . 197
2.6.4 User Training and Education . . . . . . . . . . . . . . . . . . . . . 198
2.6.5 Transfer to the Operational Organisation . . . . . . . . . . . . 199
2.6.6 Project Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
2.6.7 Checklist Conclusion Introductory Phase . . . . . . . . . . . . 202
2.7 Project Portfolio and Programme Management . . . . . . . . . . . . . . 203
2.7.1 Project Portfolio and Multi-project Management . . . . . . 203
2.7.2 Lean Portfolio Management . . . . . . . . . . . . . . . . . . . . . 214
2.7.3 Programme Management . . . . . . . . . . . . . . . . . . . . . . . 215
2.7.4 Project Management Office: PMO . . . . . . . . . . . . . . . . . 216
2.7.5 Project Management Handbook . . . . . . . . . . . . . . . . . . . 218
2.8 Creativity and Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
2.8.1 What is the Difference? . . . . . . . . . . . . . . . . . . . . . . . . 219
2.8.2 Finding Creative Solutions . . . . . . . . . . . . . . . . . . . . . . 219
2.8.3 Evaluate and Decide on Solution Ideas . . . . . . . . . . . . . 228
2.8.4 Innovation Management . . . . . . . . . . . . . . . . . . . . . . . . 232
2.9 Procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
2.9.1 Procurement Procedure in the Agile Approach . . . . . . . . 234
2.9.2 Procurement Procedure in the Traditional Approach . . . . 235
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
x Contents
3 Human . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
3.1 Competence Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
3.2 Conditions for Good Performance . . . . . . . . . . . . . . . . . . . . . . . 242
3.3 Human Phenomenon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
3.3.1 The Brain Is a Miracle . . . . . . . . . . . . . . . . . . . . . . . . . 244
3.3.2 Basic Needs Determine Our Lives . . . . . . . . . . . . . . . . . 247
3.3.3 Human Perception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
3.3.4 Awareness and Self-Reflection . . . . . . . . . . . . . . . . . . . 252
3.3.5 Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
3.3.6 Humour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
3.4 Culture and Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
3.4.1 What Is Culture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
3.4.2 Organisational Culture . . . . . . . . . . . . . . . . . . . . . . . . . 255
3.4.3 Project Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
3.4.4 Generations Y, Z, and Alpha in the World of Work . . . . 258
3.4.5 Becoming Aware of One’s Own Cultural Imprint . . . . . . 259
3.5 Stress and Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
3.5.1 Fight or Flight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
3.5.2 Psychological Stress . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
3.5.3 Stress Traffic Light . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
3.5.4 Stress Competence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
3.5.5 Life Means Change . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
3.5.6 Personal Coping Strategies and Dilemmas . . . . . . . . . . . 263
3.5.7 Burnout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
3.6 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
3.7 Motivation and Meaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
3.7.1 Goal Orientation of the Human Being . . . . . . . . . . . . . . 267
3.7.2 What Is Motivation? . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
3.7.3 Meaning as an Intrinsic Motivator . . . . . . . . . . . . . . . . . 269
3.8 Self-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
3.8.1 Human Self-Efficacy . . . . . . . . . . . . . . . . . . . . . . . . . . 272
3.8.2 Personal Competence Circle: Strengths and
Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
3.8.3 Time Management and Work Technique . . . . . . . . . . . . 274
3.8.4 Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
3.8.5 Dealing with Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
3.9 Personal Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
3.9.1 What Is Communication? . . . . . . . . . . . . . . . . . . . . . . . 281
3.9.2 Axiom Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
3.9.3 Communication Square . . . . . . . . . . . . . . . . . . . . . . . . 282
3.9.4 Communication Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 285
3.9.5 Meta-Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 286
3.9.6 I and You Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
3.9.7 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
3.9.8 Questioning Techniques . . . . . . . . . . . . . . . . . . . . . . . . 293
Contents xi
3.10 Personal Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

3.10.1 The Three Living Worlds . . . . . . . . . . . . . . . . . . . . . . . 297
3.10.2 Self-Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
3.10.3 Coaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
3.10.4 Intervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
3.10.5 Upside or Downside Strategy? . . . . . . . . . . . . . . . . . . . 307
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
4 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
4.1 Leadership and Cooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
4.2 Leadership: What Is It? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
4.3 Different Forms of Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . 312
4.4 Leadership Styles and Models . . . . . . . . . . . . . . . . . . . . . . . . . . 313
4.4.1 Directive Versus Delegative Leadership Style . . . . . . . . 315
4.4.2 Situational Leadership Model . . . . . . . . . . . . . . . . . . . . 315
4.4.3 Leadership Without Authority to Issue Directives . . . . . . 317
4.4.4 Positive Leadership in Projects . . . . . . . . . . . . . . . . . . . 319
4.4.5 Tips for Remote Leadership . . . . . . . . . . . . . . . . . . . . . 321
4.5 Self-organisation, Specific Characteristics in the Agile
Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
4.5.1 Principles and Requirements for Self-organisation . . . . . 322
4.5.2 What Does Self-organised and Agile Working
Mean? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
4.5.3 How Does Self-direction and Leadership Work
in Self-organisation? . . . . . . . . . . . . . . . . . . . . . . . . . . 323
4.5.4 Decide on Procedures and Solutions in Their Own
Competence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
4.5.5 Important Factors for Self-organisation to Succeed
and Be Effective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
4.6 Leading with Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
4.6.1 Management by Objectives MbO . . . . . . . . . . . . . . . . . 327
4.6.2 Leading by Objectives and Key Results (Management
by OKR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
4.7 Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
4.7.1 Decision-Making Process in the Delegation . . . . . . . . . . 330
4.7.2 Delegation as a Recurring Process in Project
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
4.8 Task, Competence, Responsibility (TCR) . . . . . . . . . . . . . . . . . . 333
4.9 Power and Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
4.9.1 Empowerment and Seizure: Power Is Based on
Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
4.9.2 Traditional Sources of Power . . . . . . . . . . . . . . . . . . . . 335
4.9.3 Other Sources of Power in Project Management . . . . . . . 336
4.9.4 Projects Always Need Borrowed Power . . . . . . . . . . . . . 337
xii Contents
4.9.5 Sources of Power: Between Person and Institution . . . . . 338

4.9.6 Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
4.10 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
4.10.1 Negotiations in Project Management . . . . . . . . . . . . . . . 340
4.10.2 What is a Negotiation? . . . . . . . . . . . . . . . . . . . . . . . . . 340
4.10.3 Negotiation Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
4.10.4 Conducting a Negotiation According to the Harvard
Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
4.11 Moderation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
4.11.1 Iceberg Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
4.11.2 Phases of Moderation . . . . . . . . . . . . . . . . . . . . . . . . . . 352
4.11.3 Responsibility and Competences of the Moderator . . . . . 353
4.11.4 Checklist for the Preparation of a Moderated
Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
4.12 Communicate Effectively with Virtual Teams . . . . . . . . . . . . . . . 355
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
5 Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
5.1 Aspects of Teams and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 359
5.1.1 What Distinguishes Teams from Working Groups? . . . . 359
5.1.2 Composition of the Project Team . . . . . . . . . . . . . . . . . 360
5.2 Dynamics in Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
5.2.1 Forming: Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . 362
5.2.2 Storming: Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 363
5.2.3 Norming: Familiarity . . . . . . . . . . . . . . . . . . . . . . . . . . 365
5.2.4 Performing: Working in the System . . . . . . . . . . . . . . . . 366
5.2.5 Adjourning: Farewell and Separation . . . . . . . . . . . . . . . 367
5.2.6 Dynamics and Interaction . . . . . . . . . . . . . . . . . . . . . . . 368
5.3 Roles in the Project Organisation . . . . . . . . . . . . . . . . . . . . . . . . 368
5.3.1 “Line-up” in Teams: Position and Role . . . . . . . . . . . . . 368
5.3.2 Role Carrier and Role Sender . . . . . . . . . . . . . . . . . . . . 370
5.3.3 The Role as a Link Between Organisation
and Person . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
5.4 Influencing Factors for Successful Cooperation . . . . . . . . . . . . . . 374
5.4.1 Psychological Safety . . . . . . . . . . . . . . . . . . . . . . . . . . 374
5.4.2 Positive Psychology and What Distinguishes High
Performance Teams from Others . . . . . . . . . . . . . . . . . . 377
5.4.3 Belbin Team Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
5.4.4 Radical Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . 381
5.4.5 Multicultural Cooperation . . . . . . . . . . . . . . . . . . . . . . . 383
5.4.6 Organisational Constellations . . . . . . . . . . . . . . . . . . . . 388
5.5 Change and Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
5.5.1 Change and Transformation . . . . . . . . . . . . . . . . . . . . . 391
5.5.2 Mind Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Contents xiii
5.5.3 The Human Being and Change . . . . . . . . . . . . . . . . . . . 392

5.5.4 “Formula” of Change . . . . . . . . . . . . . . . . . . . . . . . . . . 394
5.5.5 Readiness for Change in Organisations . . . . . . . . . . . . . 395
5.5.6 Psychology and Factual Logic in Projects . . . . . . . . . . . 395
5.5.7 Willingness to Shape and Cooperate . . . . . . . . . . . . . . . 396
5.5.8 Change Process Model . . . . . . . . . . . . . . . . . . . . . . . . . 397
5.5.9 Dealing with Resistance . . . . . . . . . . . . . . . . . . . . . . . . 399
5.5.10 Procedure in Change Projects . . . . . . . . . . . . . . . . . . . . 405
5.6 Conflict Management and Crises . . . . . . . . . . . . . . . . . . . . . . . . 408
5.6.1 What Is Conflict? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
5.6.2 Origin and Symptom: The Systemic Phenomenon . . . . . 410
5.6.3 Conflict Syndrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
5.6.4 Conflict Symptoms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
5.6.5 Potential of Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . 415
5.6.6 Types of Conflict in Project Management . . . . . . . . . . . 415
5.6.7 Conflict Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
5.6.8 Models for Conflict Diagnosis . . . . . . . . . . . . . . . . . . . . 427
5.6.9 Conflict Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
5.6.10 Conflict Resolution Depending on the Type
of Conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
5.6.11 Conflict Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
5.6.12 Dealing with Crises . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
5.7 Finally. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
6 Reference List for the Individual Competence Baseline (ICB) from
IPMA (International Project Management Association) . . . . . . . . . . 457
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
About the Authors
Jürg Kuster, Graduate Engineer ETH Zurich

Studied electrical engineering and information tech-
nology at ETH Zurich. Worked for many years as a
manager and project manager in different companies.
Trainer and expert for the Swiss professional
examinations for IT project manager and business IT
specialist. Lecturer at various training institutes. Owner
of Pentacon AG in Zurich, and, from 2008 to 2020,
Managing Director of BWI Management Weiterbildung
at the Department of MTEC of ETH Zurich.
Main areas of work: Leadership development and
training, coaching for leaders and project managers,
conception, design and implementation of company-
wide project management standards and training
programmes.
www.pentacon.ch
Christian Bachmann, Business Economist FH

Studied at the University of Applied Sciences in
Aargau and Chur, graduating as a business economist.
Further training in coaching, organisational develop-
ment, and theology: Systemic Training Group,
Koenigswieser & Network, Vienna; MAS ZFH in
Supervision and Coaching in Organisations, IAP
Zurich; MAS Spiritual Theology in Interreligious Pro-
cesses, University of Salzburg. Ten years of operational
project management in the financial services industry.
Independent consultant and coach since 2006, trainer
since 2011, and partner at the BWI AG Consulting and
Further Education Institute, Zurich, since 2020.
Main areas of work: Trainer in self-management
with a focus on resilience and stress management, proj-
ect management, and facilitation of meetings
xv
xvi About the Authors
(in industry and in educational organisations). Process

support in the further development of project
organisations. Coaching of managers and project
managers.
www.bwi.ch
Mike Hubmann, Engineer FH, EMBA HSG, Integral

Systemic Coach
Training in coaching, organisational development,
systemic constellation work, agile and traditional project
management (Certified Senior Project manager IPMA
Level B, Hermes 5 Advanced, Certified scrum master),
MBA in Business Engineering, Marketing and Electri-
cal Engineering. More than 30 years of experience in
project management of agile and traditional projects.
Mastering challenging projects is his core competence.
Since 2009, assessor for IPMA Level B certifications at
VZPM, and, since 2017, additionally examination
expert. Since 2011, trainer, coach and, since 2020, part-
ner at the consulting and Further Education Institute
BWI AG, Zurich. Owner of Mike Hubmann GmbH
since 2016.
Main areas of work: Coach and organisational
developer for individuals, teams, and organisations in
challenging business situations or in change situations,
constellator (systemic constellations, organisational
constellations), trainer, consultant, project manager,
and project management expert.
www.bwi.ch
Robert Lippmann, Lic. oec. publ., NDU SNU

Commercial training, then studies and degree in eco-
nomics (Lic.oec.publ., University of Zurich). Further
training and diplomas in work and organisational psy-
chology, group dynamics and postgraduate diploma in
corporate development (DNU SNU). Since 1996, inde-
pendent management and organisational consultant,
trainer and coach in industry, the service sector, and
public administration, primarily in project management,
leadership, coaching, communication, and facilitation.
Many years of experience as a project manager,
specialising in the operational implementation of
concepts, organisational projects and as a client repre-
sentative. Co-author of the reference book Lippmann
About the Authors xvii
E. (ed.), Coaching (3rd ed. 2013) published by Springer

Verlag.
Main areas of work: project management and con-
sulting, coaching, trainer in Further Education for
executives and project managers, mandates as tempo-
rary manager.
www.lippmann.ch
Patrick Schneider, graduate engineer ETH, EMBA,

University of Zurich
Studied electrical engineering at ETH Zurich.
Diploma thesis at Harvard University. Executive MBA
in General Management at the University of Zurich and
Stanford University. Certified project manager IPMA
Level C. Fifteen years of experience in business devel-
opment with internationally active service providers, in
e-commerce and IT outsourcing. Four years of divi-
sional management at executive level with product man-
agement, project management, test department, and
customer service in the machine industry. Since 2015,
active as a trainer for project management, as a project
manager and as a consultant for project, product, and
process management. Founder and owner of Schneider
Associates GmbH.
Main areas of work: In-house training for product
and project management; introduction of processes and
standards; project management mandates.
www.schneiderassociates.net
Introduction
1
1.1 Project Management, What for?
The dynamics of change in business and research are high. Innovative organisations
have recognised project management as a critical success factor. The products and
services of tomorrow emerge from temporary, targeted, and interdisciplinary coop-
eration. For this, it is necessary to design the optimal working methods and
organisational forms according to the situation, so that efficient management and
communication channels are possible.
Project management was developed in the 1950s in the aerospace and plant
construction industries. Special planning methods such as the network planning
method (Critical Path Method) or PERT (Programme Evaluation and Review Tech-
nique) were developed for these projects. They were used to solve complex tasks not
only for technical undertakings, but also for problem and crisis situations in all
management functions: for example, for marketing, and in human resources, finance
and organisation in private-sector companies and public administrations. The tradi-
tional approaches are still valid today and are widely applied. However, in various
areas such as product or software development, they have reached their limits. Agile
methods such as scrum help and increasingly rely on the principle of self-
organisation of teams. They are deliberately lean and focused on fast, iterative
delivery of results and prototypes. Mixed forms have developed from the traditional
and agile approaches, which are referred to as hybrid project management. If projects
include operational, structural, organisational, or personnel aspects, project manage-
ment is often also called change management.
1.1.1 The Taylor Tub
In the industrial age of Taylorism, traditional project management helped to create

efficient procedures. Today, in the knowledge age of the network economy, com-
plexity and dynamics determine the everyday life of companies. Bernd Oestereich
# Springer-Verlag GmbH Germany, part of Springer Nature 2023 1

J. Kuster et al., Project Management Handbook, Management for Professionals,
https://doi.org/10.1007/978-3-662-66211-3_1
2 1 Introduction
Share of value added
Machine complicated
Efficiency
Man pressure complex
Who? How? Who?

Efficiency Knowledge
Craft Method Trying it out
Rules Meaning
Innovation
pressure
Zeit
1900 1980 2000
Taylorism Network
Manufactury
Industrial age economy
tight local markets wide global markets tight global markets

Market pressure
Fig. 1.1 Taylor tub
and Claudia Schröder illustrate this using the model of the Taylor tub by Wohland
et al. (2004) and Pflaeging and Hermann (2015) in Fig. 1.1.
Companies have to adapt to the intense competition and the increased demand for
personalised offers. In order to master the high dynamics and complexity of every-
day life, they tend to use agile approaches in project management. Depending on the
situation in which an organisation finds itself, it then chooses the appropriate
approach accordingly.
1.1.2 BANI Is the New VUCA
Science is constantly developing new explanatory models for changes seen in the
world; e.g. the sensemaking model BANI by Jamais Cascio (Facing the Age of
Chaos, April 2020). It describes four trends that are increasingly observed in today’s
world:
• Brittle: many systems have become unstable and can collapse at any time
• Anxious: a diffuse basic fear has taken hold of the world
• Non-linear: linear logic has long since reached its limits
• Incomprehensible: previous explanatory models are increasingly losing their
value
1.2 What are Projects? 3
The VUCA model (W. Bennis, B. Nanus, 1987) was developed after the end of
the cold war and consists of the following four elements:
• Volatility: Fluctuations and rapidity in the digitalised world

• Uncertainty: Difficulty in predicting events and trends
• Complexity: Many influencing factors are interdependent
• Ambiguity: Clear and unambiguous decisions are rarely possible any more
This great speed of change also repeatedly leads to adjustments in the under-
standing of project management. In summary, the following features characterise
this domain:
• A flexible and quickly reactive temporary organisation ensures the optimal

handling of the respective project.
• Project management facilitates and promotes direct, interdisciplinary
cooperation.
• The competences of leadership are clarified in the project organisation.
• Direct communication channels within and outside the project are easily
accessible.
• The existing performance potential is activated through teamwork and a
stimulating atmosphere.
• Clear affiliation to the project team makes it easier to identify and deal with
conflicts of loyalty.
• Involving the people concerned makes it possible to form a learning organisation.
1.2 What are Projects?
A generally valid definition of the term project has not been agreed upon yet.
Organisations define projects differently according to their needs. The following
common characteristics can be singled out:
• Projects are goal-oriented. They bring about changes that can result in very
different reactions: from euphoria to resistance, from scepticism and fear to joy
and motivation. They require great organisational-psychological demands to
manage.
• Projects are innovations. Either they push the limits of what has been technically
or organisationally feasible so far (e.g. new information and communication
technologies), or they are something completely new for the organisation, for
which knowledge has to be acquired at first (e.g. by means of self-organisation).
• Projects are undertakings having clear boundaries: They are one-off, limited in
time and under deadline pressure.
• Projects are interdisciplinary: they go beyond the usual organisational structure
and touch on different disciplines and areas of responsibility.
• Projects are of high content and social complexity.
4 1 Introduction
• Their character changes from a phase to the next (vision, concept, execution), and
they require different management skills at every step.
• Projects are difficult to plan and control, they require special organisational
measures as well as clear and unambiguous decisions.
• Projects need extraordinary resources in terms of leadership, knowledge, person-
nel, and finances.
• Depending on their size and complexity, projects also carry various risks, namely
risks of a financial, personnel, technical, and scheduling nature.
• Projects are social systems: they need their own project organisation for their
execution.
The team of authors defines a “project” as follows:
Definition
A project is a unique, cross-departmental, time-limited, goal-oriented, and
interdisciplinary undertaking that is so important, critical, and urgent that it
cannot be handled within the existing line organisation, but requires special
organisational framework conditions.
Projects which are not really projects, but in which individual elements of project
management are applied, include:
• one-off special assignments that can essentially be fulfilled by one person,

i.e. without a separate project organisation.
• continuous processes such as learning, production, development, or change
processes without a defined end. They are more like a stream. However, projects
can be embedded in them. For example, the conception and introduction of a
quality management system is usually handled as a project in order to install
on-going feedback and learning processes.
The principles and methods of project management can on the whole be adopted
for such projects, too.
Each organisation can and should set criteria based on its level of project
management maturity as to the scope and complexity of a project. It is often a
good idea to classify projects. A higher number of governance documents and
processes are prescribed for projects with a higher classification. Table 1.1 shows
an example of project classification.
Other criteria used in practice for classification can be:
• Personnel expenses internal/external

• Content/social complexity (Sect. 1.2.1)
• Internal vs. customer projects
• Project duration
• In addition to the project-specific classification, projects can also be grouped
together in programmes according to their interdependence, see Sect. 2.7.3.
Table 1.1 Example of a project classification

Criterion A Projects B Projects C Projects D Activities
Project costs >€1m > 250 k€ > 100 k€ ≤ 100 k€
Complexity Group-wide Business unit Maximum Maximum
3 departments 2 departments
Strategic High Medium Low Low
importance
Risk Very high High Medium Low
Default All Many Some mandatory, No
documents mandatory mandatory, many optional specifications
according to some optional
matrix list
Governance Monthly Regular steering Ad hoc steering Optional
structure steering committee committee at the
committee (business unit) request of the PL
(group)
Classification (A, B, C, D) is based on the highest criterion
Table 1.2 Project characteristics

Task Closed Known, clear task with limited solution options, e.g. structural
extension for certain uses
Open Many possibilities regarding content and approach without solution
ideas, e.g. improving the flexibility and reaction speed of an
organisation
Social Deep Unproblematic cooperation, e.g. few stakeholders, little differences in
complexity interests, cooperation mainly in one field of expertise
High Interdisciplinary, politically explosive, different user interests, great
potential for conflict
1.2.1 Project Characteristics
The character of a project gives the project manager important information on how to
structure the project, define the project organisation, and see what resources are
needed. There are different ways of characterising projects.
A distinction is made between projects according to the nature of their task:
closed or open, and according to their social complexity.: low or high (Table 1.2).
Four project characteristics can be derived from this (Fig. 1.2):
6 1 Introduction
High
Extends across departements
or areas, interdisciplinary,
complicated causal
relationships
Social complexity
Acceptance project Pioneering project
Standard project Potential project
Low
Cooperation mainly within one
specialist field, simple causal
relationships, low risk
Goals
Closed Open
Clear goals Goals with a wide range
of possibilities in terms of
content and approach
Fig. 1.2 Project characteristics
• Standard projects can draw on a wealth of experience and can therefore be

handled in a standardised and simple manner. Examples: technical customer
project, replacement investment.
• Acceptance projects are projects with clearly defined tasks. Based on experience,
methods and tools can be formalised and standardised to a certain extent. As they
are often associated with acceptance problems, communication with stakeholders
plays a crucial role. Examples: a road construction project, or a complex software
project.
• Potential projects are tasks with open questions, but which are not (yet) closely
linked to the project environment and are not too risky in this respect. The project
organisation here is usually simple and small. This category includes studies,
potential clarifications, feasibility studies, often also research projects. Examples
would be: product innovations, and the development of new business models.
• Pioneering projects are interventions having far-reaching consequences in the
organisation; they span several areas, have a high novelty content, and are
threatening and risky for many of those affected. The scope of the task is difficult
to estimate. Examples might be, for instance, the merger of two companies, or the
development of self-driving vehicles.
Many projects alter their project character during their development from the
initialisation phase to the introduction. They often change from a potential project to
a pioneer project and then turn into an acceptance or even a standard project.
This typology can not only provide information about the basic project manage-
ment approach, the choice of the project organisation, the characteristics of the
communication, or the methodological focus, but also about the necessary strengths
and qualifications of the project manager. For example, a construction project
requires different qualifications than a change project, a development project, or
an order processing project.
The traditional approach is well suited for the handling of standard projects. On
the other hand, agile approaches are better suited for the handling of pioneer projects,
potential ones, and even acceptance projects. Estimating dates and costs is easier in
standard and acceptance projects. Dates and costs can be planned with a low
tolerance. In contrast, the estimation of the effort needed and the derivation of a
possible schedule in potential and pioneer projects is much more demanding and
tends to be associated with a higher degree of uncertainty and fuzziness.
1.2.2 Project Types
Another way of classifying projects is to arrange them according to their purpose.

For some purposes, separate project procedures have been developed and
standardised by appropriate bodies. Typical project types are:
• Investment projects
• Product development projects
• Organisational development projects
• Change projects
• Information and communication technology projects (ICT projects)
• Software development projects
• Order processing projects, customer projects
• Process optimisation projects, efficiency improvement projects
• Infrastructure projects
• Building projects
• Research and development projects
1.2.3 Emergence of Projects
Projects can arise in different ways as shown in Fig. 1.3.

Depending on how the project originated (as an internal project or customer
project), depending also on what its history is, what type of project it is, or what
project characteristics it has, the project manager has to adapt his approach accord-
ingly. These points have a direct influence on the selection of processes and tools, as
shown in Table 1.3.
8 1 Introduction
Company
Project order
B
Management Employees
external customer
Idea, suggestion for
C
Request for proposal improvement = Project request
A
Signing
Proposal = Project order
Contract negotiations
External contract
Fig. 1.3 Emergence of projects
1.3 What Is Project Management?
Every company wants to achieve strategic and operational objectives. The objectives
set cannot always be achieved through the line organisation. Depending on the
situation, it makes sense to approach and implement plans and measures as a project.
This makes it possible to bundle and focus forces. With regard to the management of
projects, the traditional and agile approaches pursue different approaches.
In the traditional approach, the following steps have proven to be very successful:
• Subdividing the procedure as a whole into phases and work packages

• Defining decision-making, leadership, and technical competence per phase
In the agile approach, the focus of the elements is slightly different:
• Empowered, self-organised teams are to continuously review and adapt

• Timebox procedures with early and frequent deliveries
" Project management is understood as a generic term for all planning, monitoring,
coordinating, and controlling measures that are necessary for the redesign or
reorganisation of systems, processes, or problem solutions.
1.3 What Is Project Management? 9
Table 1.3 Different project types and characteristics require different approaches
Order processing project An external customer has a problem. The company has
made a binding offer to the customer. Deadline and costs
are fixed and legally binding, perhaps a contractual penalty
has been agreed upon. The project manager focuses on
proven standardised processes, low-risk and on-time
execution, and effective cost control
Internal development project at Management has initiated a strategic project to realign the
own risk company. Objectives and deadlines are not set in stone. In
case of new findings, targets, deadlines, or costs can be
discussed and adjusted
Suggestion for improvement, idea Motivation and knowledge are given. The supervisor must
from own employees have the employees’ backs in that they have sufficient
resources to be able to work on the project efficiently in
addition to all routine tasks
Small project Individual phases or activities can be passed over. The
project manager works according to the standard process,
decides at the start of the project to skip individual steps and
reviews. He records this in the project documentation
Acceptance project If major resistance is to be expected in a project, the project
manager will involve all relevant stakeholders at an early
stage and draw up a carefully coordinated information and
communication concept
Innovation project, pioneering The company has reached its limits with its product line and
project needs to rely on a completely new technology in
manufacturing. The project manager will use a balanced
mix of people with a wide range of abilities and experienced
specialists and have both types of work in self-organised
teams
The procedure for achieving the solution, the resources required for this, their use
and coordination are more important than the solution itself. In contrast to project
management, line management is more concerned with day-to-day business and its
management of the organisations involved.
1.3.1 Hierarchies in Project Management
The “project management” method permeates the entire organisation. Different tasks
are carried out by different hierarchical levels in the company.
Programme management is about coordinating different interdependent projects,
aligning priorities and allocating all resources, such as labour and finances, accord-
ingly. Examples: Research programme, development programme, etc.
A project portfolio consists of the projects and/or programmes of a company or a
division. They do not necessarily have to be related to each other, but they have
access to the same pool of resources, i.e. mostly to people and finances. It is about
making the best use of the organisation’s resources and achieving the organisation’s
strategic objectives while minimising risks.
10 1 Introduction
Product management encompasses all strategic and operational activities of a

position or person responsible for a product or service in all areas of the company.
Whoever is responsible for product management is usually also the contact person
for customers. Developments, introductions, or problem solving in connection with
a product may very well be regarded and handled as projects.
1.3.2 Dimensions in Project Management
The dimensions in project management can be illustrated well using the IPMA “Eye
of Competence” (see Fig. 1.4).
1.3.2.1 Competence Area Perspective

This competence area deals with the context of a project. It contains the following
topics:
• Strategy
• Governance, structures, and processes
• Compliance, standards, and regulations
• Power and interests
• Culture and values
People Practice
People Practice
Perspective
Perspective
Fig. 1.4 Eye of Competence from IPMA (International Project Management Association)
These topics set the framework and define the environment in which the project is
carried out. In this handbook on project management, these topics are addressed in
various places of this reference work and explored in greater depth.
1.3.2.2 Competence Area People

This competence area deals with personal and social competences. It contains the
following topics:
• Self-reflection and self-management

• Integrity and reliability
• Personal communication
• Relationships and engagement
• Leadership
• Teamwork
• Conflicts and crises
• Ingenuity
• Negotiations
• Results orientation
This area of competence is key to the success of a project. A project is successful

if it succeeds in shaping the relationships between people and teams in a constructive
and positive way. In this handbook on project management, these topics are dealt
with in Chaps. 3 “People” and 5 “Teams”.
1.3.2.3 Competence Area Practices

This area of competence deals with methods employed in project management. It
contains the following topics:
• Project design
• Requirements and objectives
• Scope of services and deliverables
• Procedure and dates
• Organisation, information, and documentation
• Quality
• Costs and funding
• Resources
• Procurement
• Planning and control
• Opportunities and risks
• Stakeholders
• Change and transformation
To master a project successfully, mastering the craft is an indispensable prerequi-

site. However, the decisive factor for project success often lies in the question of how
to manage the relationships between people and teams. In this handbook on project
management, these topics are mainly dealt with in Chap. 2 on “Methodology”.
12 1 Introduction
1.3.3 Principles of Procedure
The following principles and attitudes have proven effective in practice:
• From the general sketch to more detail

• Investigate alternatives; variant formation
• Arrangement of phases
• Problem-solving methodology
The principles “from the rough and general to greater detail” and “investigating
alternatives” are explained below. The two other principles (phase structuring Sect.
1.4.2 and problem solving Sect. 2.3.14) are so crucial to project management that
they are dealt with separately.
1.3.3.1 From a Rough Sketch to a More Detailed Depiction

The principle shown in Fig. 1.5 is an important basic attitude in the handling of a
project. It is described as follows: At the beginning of the project, the field of
observation should be broadly defined and then gradually narrowed and focussed.
This applies to both the investigation of the problem area and the design of solutions.
Level A
Area of investigation
Area of design
Procedure from rough to detail
Level B
Level C
Fig. 1.5 Procedure from the rough to the detailed

Only when the problem area has been first structured in a more general way,
embedded in its environment and delimited, or when interfaces to the environment
have been defined, can detailed surveys begin.
When designing the solution, general objectives and a general solution frame-
work must first be defined. Their level of detail and concretisation is to be elaborated
step by step in the course of the project.
The principle of “top-down” can be reversed to “bottom-up”. The bottom-up
approach can make sense under special conditions, e.g. for improvements in
existing, functioning solutions, in the so-called empirical procedures. In the case
of a conceptual approach, i.e. in new approaches or large-scale redesigns, it is
usually more effective to develop an overall concept from the outset, so that an
orientation framework is created for the sub-steps to be carried out.
During implementation, it becomes apparent that a circular approach of “top-
down” and “bottom-up” leads to the necessary common view. This coordination also
significantly increases the commitment of each individual involved to take responsi-
bility for a structure or plan created in this way.
1.3.3.2 Variant Formation

Figure 1.6 shows an indispensable part of good planning. It is a basic methodological
approach and, if the principle of “from the rough to the detailed” is observed, works
without any significant additional planning effort. If this principle is not observed,
Problem:
Car ready for the scrapheap
Spontaneous project idea: New car
Solution
principles
Variants on
the concept
Detail
white red blue
variants
Fig. 1.6 Example of a step-by-step variant formation

14 1 Introduction
there is a greater risk that fundamentally different solution approaches will only be
introduced into the discussion at an advanced stage of planning.
1.4 Process Models in Projects
Depending on the type of project, the size and complexity of the project, and the
given framework conditions, different process models are used.
• Agile methods are often used in software development, in other sectors such as
plant engineering or product development, in transformation projects and
organisational development.
• For standard projects (Fig. 1.2), the traditional project management (waterfall
model) is widely used: e.g. for customer projects in which an existing technology
is adapted to specific customer requirements. Here the phases are arranged
sequentially.
• In hybrid project management, traditional and agile approaches are applied
together. The project is managed traditionally vis-à-vis customers or the internal
organisation. Internally, parts such as development are handled agilely.
• In change projects, elements from the agile and traditional approaches can be
integrated. However, in order to shape change successfully, independent process
models are needed.
Each process model has its advantages and drawbacks. It is important to select
and apply the best one for the respective situation. To say it again: the future lies in
the golden mean. It is not about a traditional or agile approach, rather about a
situationally skilful combination of agile and traditional elements.
In this handbook on project management, the traditional and agile approaches are
not treated separately. In the sense of hybrid project management, the elements of the
traditional and agile approach are explained and elaborated on the basis of the phases
of traditional project management (project commissioning, initialisation, concept,
realisation, and introduction).
1.4.1 Agile Approach
Traditional approaches have made and continue to make significant contributions to

project management. In product and software development, however, it has been
shown that many projects that were carried out with a waterfall method did not bring
the desired results or even failed. The reasons for this are to be found in task
complexity, faster working environments, and there being constant changes. Agile
methods such as Scrum, Large Scale Scrum (LeSS), Extreme Programming, Kan-
ban, or the Scaled Agile Framework (SAFe®) are employed to maintain control.
Agile methods also help to realise a customer or user-specific and functioning
software in the shortest possible time span, without the complete requirements
1.4 Process Models in Projects 15
having to be defined in detail at the beginning. Agile project management refers to an

elastic, nimble, process-oriented, reflexive, learning approach. Its principles and
values were published in the Manifesto for agile software development (Beck
et al., 2001, http://www.agilemanifesto.org):
• Individuals and interactions are more important than processes and tools
• A software that works well is more important than extensive documentation
• The cooperation with project stakeholders is more important than contract
negotiations
• Responding to change is more important than sticking to a rigid plan
The agile manifesto follows these 12 principles:
• Our highest priority is to satisfy the customer through the early and continuous
delivery of valuable software.
• Welcome changes in requirements even late in development. Agile processes use
change to the customer’s competitive advantage.
• Deliver working software regularly within a few weeks or months, giving prefer-
ence to the shorter time span.
• Subject matter experts and developers have to work together on a daily basis
during the project.
• Build projects around motivated individuals. Give them the environment and
support they need and trust them to get the job done.
• The most efficient and effective way to communicate information to and within a
development team is face to face.
• (Well-)functioning software is the most important measure of progress.
• Agile processes promote sustainable development. The project owners,
developers, and users should be able to maintain a steady pace indefinitely.
• Constant attention to technical excellence and good design promotes agility.
• Simplicity—the art of maximising the amount of unnecessary work not done—is
essential.
• The best architectures, requirements, and designs are created by self-organised
teams.
• At regular intervals, the team reflects on how it can become more effective and
adjusts its behaviour accordingly.
The values and principles of the agile manifesto can also be applied to areas
outside of software development. In an agile approach, the dimensions time and
budget are rigid, the result (the scope) is flexible. In a traditional approach, the scope
is usually set while the time and budget dimensions remain flexible (or they are
estimated based on the scope). This is a principle that often leads to time delays and
budget overruns in projects.
In this project management handbook, scrum is examined in depth as an agile
process model.
16 1 Introduction
1.4.1.1 Scrum
Scrum was initially very strongly influenced by the lean and innovative ways of
product development in Japan (lean management). Scrum consists of a few rules.
Figure 1.7 shows schematically the procedure according to scrum. The start phase
(initialisation and product conception) is followed by iterations or sprints during
pre-planned intervals of time (i.e. within timeboxes). The agreed-upon partial
assignments are processed by teams that do and organise things acting largely on
their own responsibility.
The basic principle underlying these forms lies in the relatively short and
predefined iteration cycles (timeboxes), within which highly motivated teams inde-
pendently develop and test solutions (increments). In the process, learning
experiences or new user insights flow into the next cycle.
In scrum there are three roles (responsibilities): product owner, developer, and
scrum master. The role of the traditional project manager either does not exist or is
divided up between the two roles of product owner (technical and content-related
control) and the scrum master (method specialist who removes any hurdles).
The requirements for this are recorded in a prioritised product backlog. The
content and prioritisation of this product backlog changes continuously during the
project, which means that changes can be dealt with easily and flexibly. It is the
product owner who controls the product backlog and determines the prioritisation.
Scrum is an empirical process that follows a credo of “inspect and adapt”. The
achieved result (increment) and the ways of working are thus regularly assessed in
the sprint review and improved retrospectively. This ensures continuous
improvement.
A sprint is planned in such a way that at the end an increment is created which
represents added value and is functional. This focus on the delivery of added value
Start-up Sprint 1 Sprint 2 Sprint 3

phase
•
Product •
•
Target •
•
•
Product •
•
Backlog •
•
Sprint Product Sprint Product Sprint
Backlog Increment Backlog Increment Backlog
Release
•
• 1 1 2 2 3
• • • • • •
Plan •
•
•
•
•
•
•
•
•
•
•
•
…
Time
Fig. 1.7 Schematic representation of the agile procedure according to SCRUM

prevents one from being preoccupied with anything unimportant. In sprint planning,
the product owner specifies his priorities, wishes, and the sprint goal. Ultimately, the
developers themselves decide on the effective content of the sprint according to the
pull principle. This promotes personal responsibility and self-organisation. In addi-
tion, the pull system avoids systematically overloading the developers. It is also
advisable to identify and address problems and obstacles at an early stage. Especially
in the first sprints, the sticking points should be tackled and directed towards a
solution.
Scrum is hard work. New rules have to be learned, old habits discarded, obstacles
overcome, and problems solved. Successfully applying scrum is a constant learning
process that also requires time and patience. It is the central task of the scrum master
to support the developers and the product owner in overcoming these challenges and
to apply scrum successfully.
The phase concept can also be applied to scrum in an adapted form. In the initial
phase of a scrum project, it is essential that a product goal is first developed. This
concretises the idea. The product goal describes the benefit for the future user of the
product or service and the essential performance features. Furthermore, the initial
product backlog and the release plan must be created in the beginning phase. Agile
approaches have proven to be more flexible, faster, and more economical than
planning-oriented project management in complex areas.
1.4.1.2 Kanban
Kanban has its origins in the mid-twentieth century at Toyota. Kanban was devel-
oped as a method to increase flexibility and efficiency in production. The transfer of
kanban’s ideas to the management of projects was later undertaken by David
J. Anderson.
Kanban does not prescribe any processes or structures. Like scrum, kanban
promotes self-organisation in that the employees or the team independently pull
tasks to themselves (pull principle). Kanban is based on four basic principles and six
practices.
The four basic principles of kanban are:
• Start with what you are doing right now.

• Aim for incremental, evolutionary change.
• Respect current processes, roles, responsibilities, and titles.
• Promote leadership and responsibility at all levels of the organisation.
The six practices of kanban are:
• Make the work visible (Kanban board, see Sect. 2.5.2).

• Limit the amount of work started.
• Measure and manage flow.
• Make process rules explicit: clear and known.
• Develop feedback mechanisms.
• Make collective improvements.
18 1 Introduction
The principles of kanban can be combined well with other agile methods such as
scrum or the traditional approach to project management.
1.4.1.3 Scaled Agility

An agile approach using scrum is suitable for teams with a size of three to ten people.
If larger teams or an entire company want to work agilely, an approach like scrum is
not sufficient. The two best-known approaches to scaling agility are Scaled Agile
Framework (SAFe®) and Large Scale Scrum (LeSS). SAFe® and LeSS provide
approaches for agile working and synchronisation across multiple teams. Both
approaches are based on teams working according to scrum or a scrum adapted
approach.
In SAFe® several teams are grouped into an “agile release train”. These release
trains are aligned with value streams. Quarterly big room planning takes place in
which the next product increment and the work for the next 3 months are planned.
The implementation then takes place in sprints during the next 3 months. At a higher
level, a programme backlog is kept and each team also keeps its own backlog. There
is a product owner for each team and also a product manager at this level, who
among themselves divide up the work of the product owner. This also applies to the
work of the scrum master. At a higher level there is a release train engineer. For large
organisations, several agile release trains can be combined into one solution train. At
the company level, management is carried out according to the principles of lean
portfolio management (see Sect. 2.7.2).
The LeSS framework is closer to the scrum method. It divides events such as
planning, review, and retrospective into a general part for all teams and an individual
part for each team. In addition, there are further synchronisations between the teams
during the sprint.
SAFe® and LeSS are efficient approaches to scaling agility across the whole
organisation. They are oriented towards scrum and lean management. Part of the
autonomy and self-organisation in the teams is given up in favour of a common
orientation. In addition to the methodological support of these frameworks, it is also
crucial to develop the attitude and mindset of the people involved in the direction of
agility. If this is not done, there is a high risk that the methodological approach will
be changed, but the old problems will be retained or simply reorganised.
1.4.2 Traditional Approach: Phase Concept
The principles of “from the rough to the detailed” and “variant formation” mean the
following for the processing of problems: namely that the Idea, development,
implementation planning, and the realisation of a solution are divided into individual
work packages, and these in turn into phases that can then be logically and tempo-
rally separated from each other. The purpose of this is to split the development of a
solution as a whole into manageable stages. This enables a graduated planning,
decision-making, and concretisation process with predefined milestones or correc-
tion points.
Assignment Initialisation Concept Realisation Introduction
Milestone: Size of the rhombus as a measure of the probability of a project break-off

Project break-off
Fig. 1.8 The ideal phase concept
In Fig. 1.8, the phase model is described in its simplest, ideal-type form.
Number of Project Phases

The number of project phases and also the formalism with which they are handled
depend considerably on the type, scope, risk, and importance of a project and also on
the influence the project owner wants to have.
Smaller projects can be seen through with a smaller number of phases and less
formalism. On the other hand, compared to the theoretical model, phase extensions
are also possible, e.g. by including a feasibility study, a prototype phase, a test phase,
or an acceptance phase.
The representation as a block diagram or as a “waterfall model” and the designa-
tion of the phases are of secondary importance, as they are influenced by the
industry, the task and the terms used in the company. Some common phase models
are listed in Fig. 1.9. The decisive factor is that in decision-making meetings
between the stages, the complexity of a problem and the risk of a wrong decision
can be reduced by the targeted structuring of the work packages into individual
planning and realisation stages.
1.4.2.1 The Project Commissioning Phase

This phase, which is usually rather unstructured, comprises the period between the
recognition of the problem and the decision to do something concrete. The problem
can either be formulated in real terms or merely be the result of vague assumptions. It
is not important where the impetus for redesigning or reorganising comes from.
What is important is that it is received, accepted, and approved in a project agree-
ment by those authorised to allocate the necessary human, financial, and
organisational resources.
20 1 Introduction
Systems Engineering Product development Building projects SIA IT projects with Scrum
projects projects
1 Preliminary 1 Preliminary 1 Strategic planning

project project 1 Initialization
2 Preliminary studies
2.1 Feasibility
2.2 Selection process 2 Rough concept
3 Project Planning
3.1 Preliminary project
2 Main project 2 Development
3.2 Building project
3.3 Approval process
3 Detailed project 3 Production 4 Tender process 3 Sprints

preparation Iterative programming
5 Realisation Introduction and
5.1 Detailed design acceptance
4 Implementation 4 Pilot series 5.2 Execution
5 Introduction 5 Serial 5.3 Commissioning

production
6 Facility Management
6.1 Operation
6.2 Maintenance
Fig. 1.9 Phase models and phase designations
The preliminary work and activities of this first “definition phase” ideally result in
a project factsheet. The project factsheet contains information on the strategic
reference and the expected added value, an initial rough schedule and the expected
costs. It names the central project roles and, together with the business case, serves as
a basis for deciding whether the project should be approved and included in the
project portfolio.
1.4.2.2 The Initialisation Phase

In the initialisation phase, binding statements on feasibility, risks, and stakeholders
must be developed. Essential bases for this are the analysis of the current situation as
well as clearly agreed-upon objectives and the formulation of requirements for the
outcome of the project, e.g. for the product to be developed.
At the beginning of the project, knowledge about the project content and
solutions is low. The risks and the importance of decisions are greatest at the
beginning. This can be alleviated or resolved with a feasibility study in the
initialisation phase.
In this phase, the project order is written. This sets out the objectives and the
framework conditions for the project. The following thematic blocks are worked out
and fixed in the assignment:
• Elaborate requirements: What should be realised?

• Determine project organisation
• Identify and analyse stakeholders
• Identify risks and develop measures to reduce them
• Structure and roughly plan the project
The project owner is responsible for transforming the proposal into a project
order. From a tactical point of view, the project owner often delegates the prepara-
tion of the project proposal to the project manager, who conducts the “kick-off” at
the end of the phase.
If one decides to abandon the project at the end of the initialisation phase, this is
neither a “mistake” nor some kind of failure, but rather a conscious decision based on
newly attained knowledge.
1.4.2.3 The Concept Phase

The purpose of the concept phase is to develop solution variants. In this phase, the
planned achievement of objectives, functionality, expediency, and economic effi-
ciency is to be assessed in a well-founded manner. Attention is focused on the
elaboration of possible solution variants.
The result of the concept phase is to come to a decision about which solution
variant to go with. Plans are then drawn up for the variant selected, ready for
implementation, and solution concepts are developed that describe how the
requirements are to be set up. The next step is to plan the chosen solution in detail.
Subsystems or individual aspects of the overall system are often worked on here.
1.4.2.4 The Realisation Phase

In the realisation phase, the plans from the concept phase are put into practice.
Typical work steps of the realisation phase are:
• Manufacture plants and equipment

• Create software
• Create user-friendly documentation or operating instructions
• Establish organisational arrangements in the event of disruptions, etc.
• Determine support organisation, maintenance concepts, etc.
• Perform tests
Often, individual subsystems are also built here which are integrated into the
overall solution. Comprehensive project controlling helps to ensure that the targeted
objectives are achieved. Any change requests are managed via the change request
process and therein taken to the decision-making stage.
1.4.2.5 The Introduction Phase

Introduction
Only relatively small and simple solutions can be introduced as a whole without
taking a great risk by keeping them in one piece. With large and complex systems, an
22 1 Introduction
abrupt introduction of a change does not make sense because of the large number of
incalculable side effects and dependencies. It is therefore advisable to proceed in
stages: With the overall concept in sight, further steps are taken based on the first
experiences made with the introduction.
In practice, this—superficially seen—very technical phase often turns out to be
delicate and lengthy. The project team has already been occupied for a long time
with the innovation or change that the project brings with it, and no longer even
notices the drastic change that this introduction means for all of the other people
involved. This disparity between the two systems, project and line, requires good
cooperation within the leadership team.
Handover
The success of a system introduction largely depends on the way and extent to which
the knowledge transfer takes hold. This means whether it is possible to train and
inform the system administrators and the users comprehensively and with adequate
quickness. The goal is to make the development and implementation teams super-
fluous as quickly as possible.
Closing
Every project finally comes to an end. Even aborted projects need closure, and that,
too, is work. If project closure is not done consciously, no one knows whether the
project is finished or not.
The following work is to be carried out for project completion:
• Complete project work, i.e. clearly assign and schedule possible remaining work
or postpone it to a future release
• Elaborate final account
• Complete project documentation and ensure archiving
• Hand over tasks, competences, and responsibilities to the users or an operating
organisation
• Submit project documents of the operational or maintenance organisation
• Project closure with the project owner to “hand over the project” and with the
project team to dissolve this team. In both systems it can be useful to hold a
critical project review, on the one hand, to let go of the project, but above all
because recognised mistakes are a great learning opportunity in the sense of the
learning organisation. Possible questions to ask might be: What went well?
Where did problems occur? Could the planned efforts (personnel, costs, time)
be kept within predicted limits? What might be done better in the future?
1.4.2.6 The Utilisation Phase

When the project is completed, the utilisation phase begins. After a predefined
period of time an evaluation or control of the project outcome takes place.
Depending on the type of project, work is recorded under warranty or for an
improved version of the solution in a new release. Usually, an effectiveness review
or project evaluation is carried out here: How precise have the business
forecasts been?
1.4.3 Hybrid Project Management
Fewer and fewer projects are so clearly positioned that only the traditional or agile
approach is suitable for their management. In practice, they usually lie somewhere in
between, so that a combination of both project management approach models
becomes obvious (Fig. 1.10). The best way to combine them is to handle selected
project phases or sub-projects differently. For example, in a product development
project in which the requirements are only known roughly at the beginning, an agile
phase can be switched on in order to afterwards continue in the traditional way. In a
complex customer project with sub-projects, software development with scrum can
be more advantageous, while the traditional approach is more suitable for the other
sub-projects.
It is also possible to use individual components of the traditional approach such as
daily stand-up meetings, kanban board, planning in cycles and iterations, or using
retrospectives gained from the agile approach. This form of hybrid project manage-
ment has a lot of potential. Often, corporate structures require that a project is set up
in a traditional way towards the outside environment. This means that existing
reporting structures or stage-gate processes can be utilised. In order to maintain
Traditional and agile settlement of phases
Set up of
Manufacturing
Initialisation Conception Realisation production
planning
line
Traditional and agile settlement of subprojects
Realisation
Initialisation Conception Introduction
Hardware I
Realisation
Hardware II
Realisation
agile Software
traditional
Fig. 1.10 Traditional and agile phases

24 1 Introduction
the necessary flexibility in project management, it is advisable to work agilely in the

project. The aim is to skilfully combine traditional and agile elements.
From the point of view of project management, the “both and” approach places
high demands on flexibility. Whereas in traditional project management the focus
lies more on rational connections, planning, and direct control, in the agile approach
it is on the evolutionary and social aspect as well as on indirect control. Both
approaches require a different understanding of organisations, roles, and leadership.
Individual methods can be “hybridised”. But the rule here is: only mix them in a
targeted and conscious way, otherwise there is a risk of weakening them. For
example, the kanban method can be used in a traditional project sequence with
parallel work packages, as it is more flexible and transparent than bar charts.
1.4.4 Procedure in Change Projects
Every project brings about change. The term “change project management” covers
all projects that aim at radical, comprehensive, and interdisciplinary changes within
the organisation. This can be: introduction of new processes, mergers, implementa-
tion of new strategies, etc. In the process, new behaviours and cultures are often
aimed at, e.g. communication culture, error culture, etc. In contrast to change
projects, we exclude “continuous improvement” (CIP, KAIZEN).
The procedure in change projects depends very much on the context in which the
change or transformation takes place. In order to understand this context, it is advisable to
carry out a context analysis as a first step. Kurt Lewin developed the basic cycle of change
management consisting of unfreeze (initiating change), move (shaping the transition
process), and refreeze (institutionalise the new state). Building on this, John P. Kotter
developed the traditional approach of the eight-step model for change projects (Kotter,
2012). Since change projects often do not run in a linear fashion and can therefore only be
planned in advance and to a limited extent, an agile approach such as Jason Little’s lean
change cycle can also be used in change projects. See also Sect. 5.5.10.
1.4.5 Further Process Models
1.4.5.1 V-Model
The V-model is another sequential process model. The procedure is suitable in
industries and areas putting high demands on safety, such as medical technology
or aviation. On the left branch of Fig. 1.11, the project object is specified step by step
from the loose design to the detailed design (top-down specification). On the right
branch, the different realisation and verification stages are gone through from the
bottom-up (bottom-up integration).
1.4.5.2 Simultaneous Engineering

Simultaneous engineering (also called concurrent engineering) is a response to the
demand for shorter development times. The partial parallelisation of processes speeds
Stakeholder Validation Validation

Requirement Release
System requirements Verification

System test
System specification
Architecture, techni-
Integration test
cal detailed design
Fine architecture, Component module

Component design or unit test
Development
Programming
Fig. 1.11 V-model
up project realisation. The various areas involved in product development should be

included as early as possible and ought to work together at least partially overlapping
in time, as shown in Fig. 1.12. This requires a close coordination between the
departments, which then often has to be moderated by the project manager.
Many projects are carried out according to this principle. The simultaneity of a
wide range of activities requires the project manager to constantly monitor compli-
ance with objectives and plans. This task is often made more difficult if one is also
involved in the project as a subject matter expert or in other projects. If simultaneous
engineering is required or approved of by the project owner for a tightly scheduled,
parallel project procedure, the project manager should be able to devote himself fully
to the control of the project, free from other work.
1.4.5.3 Version Concept

The version concept can be used as an iterative procedure for developments of any
kind (machines, systems, hardware, and software). It is also referred to as the spiral
model or as prototyping.
In the version concept, the solution is not created in one go. Instead, a first
version, a first rough, unrefined prototype is created early on and made available
to the user for evaluation. Based on the user’s feedback, improvements then take
place over several iterations, which become possible as a result of operational
experience (Fig. 1.13). The advantages of the version concept are the customer-
oriented development method, the rapid and concrete progress for tasks that are
difficult or not easy to precisely specify, and the on-going learning that takes place if
there is a high degree of uncharted territory. The biggest risk of the version concept
is getting bogged down in “happy engineering”, as there is always another round
26 1 Introduction
Sequential project procedure
Correction loop Correction loop Correction loop
Preceding phase Engineering Procurement Succeeding phase
Simultaneous Engineering
Time saving
Preceding phase
Coordination
Optimised market introduction

Engineering
Originl market introduction

Coordination
Procurement
Project start
Coordination
Succeeding phase
t
Fig. 1.12 Simultaneous engineering as an overlapping phase concept
Step 4: Step 1:
Planning next iteration Analysis, Feedback
De
tai
led
Ro de
ug sig
hd n
Ta es
rg ign
ets
Step 3: Step 2:
Realisation Evaluation
Fig. 1.13 The version concept (spiral model)

attached. To prevent this, it must be clarified at the beginning at which point good is
good enough. Hence, termination criteria have to be defined, e.g. three iterations of
2 weeks each or optimising until test users give a certain grade. This concept is very
similar to the agile approach according to scrum. Another development method with
a high user focus is the design thinking described in Sect. 2.8.2.6.
1.4.6 Choice of a Process Model: Traditional, Agile or Hybrid?
The choice of the most appropriate process model for the situation depends on
various factors:
• Characteristics of the project

– For a standard project, the traditional approach is recommended.
– For an acceptance project, a potential or pioneer project, an agile or hybrid
approach is more recommended.
• The project type very often specifies a process model. Construction projects are
handled according to the relevant industry standard, such as that of the Swiss
Society of Engineers and Architects (SIA).
• Companies, customers, or the regulatory authorities also specify which standards
and requirements must be met.
• Complexity of the task
– With the Cynefin framework (David J. Snowden, Fig. 1.14) and the Stacey
Matrix (Fig. 1.15) the complexity of the task or project can be determined.
– The traditional approach is more suitable for simple or complicated tasks,
whereas an agile approach is more suitable for solving complex and chaotic
tasks.
• Stability of the requirements
– An agile approach is more suitable for volatile requirements.
– In the case of stable requirements, the traditional approach brings more
security and plannability in the implementation.
– It is also important to consider how to deal with changes in the project.
• Competences, qualifications, and experience of the project team members as well
as affinity of the management to agility are further decisive factors.
• Planned team size
– Agile methods are very suitable for small teams with fewer than nine people.
– Large teams, for example, can work very well in an agile way using LeSS
(Large Scaled Scrum) if they have profound knowledge and experience in the
application of agile methods. Otherwise, a hybrid or traditional approach is
more advisable.
• Spatial distribution of the project team
– For an agile approach, it is recommended that the project team works in a
common room or at least in the same building.
– The application of agile methods in distributed project teams is demanding.
Therefore, in the case of spatial distribution, a hybrid or traditional approach is
the first choice.
28 1 Introduction
complex complicated
• everything is in flux and unpredictable, • the system is predictable,

• no correect answers, several unknowns, • cause and effect are present but
• recognisable orientation patterns, not everyone can see it,
• many competing ideas, • expert advice is needed, but
• creative and innovative approaches are more than one correct answer.
needed.
senss – analyse – respond
probe – sense – respond
er
ord
Dis
chaotic simple
• high turbulence, • repeatable patterns and unique

• no cause-effect relations, events
• big unknowns, • clear causes and effects,
• many decisions under high time • clear relationships,
pressure. • there are correct answers.
act – sense – respond sense – categorise – respond
Fig. 1.14 Cynefin framework according to David J. Snowden (simplified representation)

unclear
ch
ao
tic
WHAT: Requirements
co
po
m
liti
pl
alc
ex
co
m
pl
ica
te
d
sim
vis
pl
ion
e
clear
ar
y
certain HOW: Technology uncertain
Fig. 1.15 Stacey matrix

1.5 Projects are Based on Teamwork 29
Table 1.4 Criteria for selecting a suitable process model

Traditional Agile Hybrid
Characteristics Standard project Potential project or pioneer Pioneer project,
of the project project acceptance project, or
potential project
Complexity of Simple or Complex or chaotic Complicated or
the task complicated complex
Stability of the Stable Volatile Volatile
requirements
Team member Inexperienced in Experienced in agile Experienced in agile
qualifications agile approaches approaches approaches
Team size Small and large Ideally less than nine Large teams
teams people. Multiple networked
teams possible
Spatial Local or Locally in one room or at the Distributed over several
distribution distributed over same site locations
several locations
The choice of a suitable process model is a demanding task. It should be done at

the beginning by the project owner together with the project manager. It is possible
to change the process model during the course of the project, but this should be done
in a well-considered and conscious manner. Making ad hoc changes in the process
model is not advisable. It can still be observed too often that companies use agile
methods and processes in projects or parts of them, but do not enable the
corresponding teams to act in an agile manner. Table 1.4 provides guidance for
the selection of the process model.
1.5 Projects are Based on Teamwork
Project work is always teamwork. An individual cannot manage the complexity of a

project doing it alone, but only in association with others. This makes teamwork an
essential success factor in project management. The model of the three levels of
cooperation in Fig. 1.16 summarises the requirements for teamwork.
1.5.1 Content: Working in the System
The scope is always the deeper meaning and the reason for the existence of a project,
whether it is a product, a service, an application, a process, or the further develop-
ment of the organisational culture. In some way, added value must be created for the
organisation or the customer.
In order for several people to work towards a common scope, they must know it
and know what it is about. Objectives and restrictions guide them to make the right
decisions and to create the appropriate documents, e.g. concepts, specifications,
project orders or product visions, product backlog, and sprint backlog. The produc-
tive work is also located at this level.
30 1 Introduction
To know, what is going on

Work in the
Content Productive work, requirements and scope,
system
cost, time, decisions, concepts
Interdisciplinary cooperation
Relationship Develop relations, trust, personal communication,
project culture, conflict management
Work on the
system
Shape the cooperation
Organisation Project organisation, connection to line organisation,
approach (structures, processes, methods)
Fig. 1.16 The three levels of cooperation
1.5.2 Organisation and Relationship: Working on the System
In order for several people to be able to achieve a common scope, framework

conditions must be fulfilled for their cooperation.
Organisation
The line organisation provides the project with financial, technical, and human
resources. The project is therefore always dependent on the line organisation.
Consciously or unconsciously, the following aspects, among others, have an effect
on the project coming from the organisational level:
• Linking the project to the leading line organisation (Sect. 2.3.8.8)

• Position, roles, and role assumption in the project organisation (Sect. 5.3.1)
• Methodological guidelines, guides, or manuals (Sect. 2.3.12)
• Competence regulations (Sect. 2.3.8.9) and communication processes (Sect. 3.
9.4)
Relationship
Interdisciplinary cooperation is an integral part of project management. It is assigned
to the level of relationship. We, as people, as social creatures, depend on being able
to live sustainable relationships. This enables us to satisfy essential basic needs such
as security, social recognition, and self-development (Sect. 3.3.2). For this, it is of
prime importance that every human being can perceive him- or herself as part of the
greater whole. As explained in Sect. 1.6.3, human beings are non-trivial systems:
their behaviour is neither externally controllable nor predictable. What may be
controlled, however, is the shaping of relationships between people in a group. In
project management, the first step towards shaping these relationships is the stake-
holder analysis with the communication concept. Other aspects also have an
influence:
1.5 Projects are Based on Teamwork 31
• How well developed is the basis of trust (Sect. 3.3.5) and cohesion (Sect. 5.2.3)?
• How do the formal and informal networks work? (Sect. 4.9.3)
• How is communication to be rated (Sect. 3.9) and how is feedback dealt with?
(Sect. 3.9.7)
• How does a team deal with problems or even failure? (Sect. 3.8.5)
• How are negotiations conducted (Sect. 4.10) and how are conflicts managed?
(Sect. 5.6)
• How is the project culture shaped? (Sect. 3.4.3)
1.5.3 Interactions
Of course there are interactions between the three levels of cooperation. Unclear
objectives or a contradictory project organisation sooner or later become visible on
the relationship level and can manifest themselves in the form of personal or
emotional conflicts (Sect. 5.6.2).
In addition, the needs of the individual team members are also different: some
want to work on the substantive issues immediately, as this is the level at which they
feel safe. Others cannot work on content at all until they have attained well-
developed relationships and a solid basis of trust for an open exchange. Individuals
have needs but these may be expressed differently even if similar. They can be
captured by personality typologies such as VIA Character Strengths, Belbin Team
Roles or MBTI (Sect. 3.10.2).
An important task of the project manager, product owner, and scrum master is to
promote and develop cohesion in the project team or scrum team. If this succeeds,
the team goes in the same direction (Fig. 1.17).
Develop and promote

cohesion in the team … … and work towards the goals with
combined energy and determination Project goal
Fig. 1.17 Team building and traction

32 1 Introduction
1.6 Projects are Social Systems
1.6.1 Taylorism in our Heads
We as humans like to organise our lives in a predictable way. This gives us a sense of
security. This attitude is an important basis for the Taylor tub in Sect. 1.1.1.
Frederick Taylor developed his theory around 1910, when transport costs were
falling and an increasing amount of different machines were being invented. This
was something that opened up the global market to companies for the first time.
Innovation was not crucial back then because there was little competition. And
where there was a competitor, he could move to another market.
White Collar vs Blue Collar workers
The mantra of Taylorism was that humans had to function like machines (Oestereich
& Schröder, 2017, p. 7). Discipline became a primary virtue. The existing rules and
processes had to be followed. Every step in the process was precisely prescribed.
Thinking along and creativity on the part of the workers were not desired. A clear
distinction was made between thinking and acting. The superiors (white collar)
defined the methods and made the decisions, the workers (blue collar) were respon-
sible for their implementation.
Today, there exists high pressure to innovate in global markets. As a result, the
complexity in project work has increased manyfold. The separation between think-
ing and acting is no longer practicable or at least very ineffective: if decisions cannot
be made by the people who have the specific expertise, the proximity to the problem
or to the corresponding market, this entails communication and decision-making
processes of very little added value in hierarchical organisations.
Agile project management brings thought and action together again by giving the
product owner far-reaching decision-making powers and granting the scrum team
the autonomy to make their own decisions during the sprints. However, the change
to a network economy cannot be achieved by adapting these methods alone: it
requires the appropriate attitude, an adequate view of people and the world.
1.6.2 Mechanistic and Systemic World View
The dose makes the poison (Paracelsus).
Taylor based his teaching on a mechanistic world view. This is characterised by the
conviction that people and organisations can be explained by means of logic and
linear causal chains. Hard facts and the conviction that there is a common objectivity
and thus also some kind of truth dominate here. The aspects of systemic project
management described in Sect. 1.6.4 are based on the systemic world view.
Table 1.5 compares the main differences between these two world views.
1.6 Projects are Social Systems 33
Table 1.5 Based on Königswieser and Hillebrand (2004, p. 28)

Mechanistic world view Systemic world view
Objectivity, one truth, immutable laws Reality construction, many truths, hypotheses
Right–wrong, guilty–innocent Contextuality, usefulness, connectivity
External control Self-direction, self-organisation
Linear causal chains Multiple interactions
Formal logic, freedom from Integration of contradictions
contradiction
Hard facts, rational relationships Integration of hard and soft factors (emotions,
intuition)
Every organisation that handles projects is a living and thus a non-trivial system.
This makes the systemic approach an integral part of every project organisation,
regardless of whether it works according to the agile or the traditional approach.
The point here is neither to denigrate the mechanistic world view nor to dump the
Taylor tub. For certain projects, the traditional approach is better suited, for others
the agile approach. Of course, project work is also about hard facts. The budget has
to be discussed and the controlling has to be handled. Complexities have to be
abstracted and linear causal chains to be formed. But when people work together it is
always about the aspects of the systemic world view. As Paracelsus’ proverb reveals,
it is the dose that distinguishes poison from medicine: Anyone who is only at home
in mechanistic thinking will one day have the experience of being confronted with
phenomena such as resistance and conflict. He might also then not be able to find
creative solutions. Those who are only oriented towards systemic thinking are in
great danger of not understanding the principles of cause and effect or of then
developing creative solutions that no client wants to pay for.
It is not about the “either-or”. Dealing with polarities and thus integrating the
opposites with an “as-well-as” approach should mediate moderately between the
opposing positions: Depending on the question or situation, we should be able to
assess which attitude or which mode of thinking is goal-oriented. In any case,
experience shows that the systemic approach offers an extremely effective design
option for both traditional and agile project management. It is important to know that
the systemic approach does not replace the psychological or group dynamic
principles. Both complement each other.
In traditional project management, the focus is on external control. The project
owner and the project manager take in the two central roles having the essential
decision-making competencies. Of course, the expectations and responsibilities of
the other stakeholders must also be clarified, which can be illustrated, e.g. with a
RACI matrix (Sect. 2.3.8.9). The objectives are also specified as well as that is
possible at the beginning of the project.
The project manager is often challenged by the fact that he is responsible for both
the work on the system and the work in the system. In small- and medium-sized
projects, the project manager is often also an essential technical resource. The high
time pressure then tempts him to focus his restricted resources on the productive
34 1 Introduction
work in the system. The work on the system then takes a back seat. Thus, a project
kick-off is carried out in only 1 h. That is barely enough to get an understanding of
the task. But it is far from creating a social team structure and an organisational
framework in which the members can see themselves as part of a larger whole. This
also means that the basis for clarification and discussion is lacking in an early phase
of cooperation, which then manifests itself in specific symptoms such as conflicts
and resistance during project implementation.
In agile project management, the focus is on self-organisation. This is in the
foreground. The team members have to divide the management work among them-
selves and can thus merge thinking and action. Networking with internal and
external stakeholders is also not regulated via the hierarchy, which, too, is
challenging.
The project manager does not exist in this approach. With the scrum master, a role
is explicitly created in this approach that should not or cannot do any productive
work in terms of content, but concentrates entirely on the work on the system. The
scrum master’s sole purpose is to ensure optimal cooperation between the two
“productive” roles, namely those of product owner and developer. In addition, it is
his task to remove obstacles that the scrum team is confronted with and to ensure that
the respective requirements and challenges are dealt with using the optimal method-
ological approaches.
1.6.3 People and Teams Are Non-Trivial Systems
Anyone who has children experiences again and again: what you tell them (input)
and what they finally do (output) as a response to that can be miles apart. In
professional cooperation, too, we experience time and again that an apparently
clear instruction to a colleague results in a completely unexpected response. Heinz
von Foerster explains this phenomenon through the concept of trivial and non-trivial
systems.
Trivial Systems: External Control

A trivial system is based on the logic that a clearly specified input triggers a specific
function, which then leads to a clearly defined output. In Taylorism, the human being
had to function like a machine; the image of the human being was thus shaped by the
logic of the trivial machine.
This definition is valid in inanimate nature (minerals, inorganic substances) as
well as in mechanical, electronic, and IT systems, or at least it should be. Cars, ships,
or planes are built to be controlled by actions from the cockpit. Our computers with
all the programmes and applications are designed to generate specific outputs and
performances based on specific inputs from the users via the programmes.
Non-Trivial Systems: Self-Control

Everything that lives is non-trivial, be it organisms such as plants or animals,
individual people, project teams, and other organisations. Living systems are self-
1.6 Projects are Social Systems 35
organised and cannot be controlled from the outside. It is never possible to predict
and plan with absolute certainty what the reaction (output) to a specific instruction
(input) will be.
A remark addressed to a colleague with the best of intentions can be completely

misunderstood by the colleague. His reaction, which stems from an emotion, makes
this clear. Or: Despite a signed project order and clearly defined priorities in the
project portfolio the resources are not made available to the project manager. In our
private and professional lives, we are repeatedly confronted with behaviour from
other people that was neither expected nor agreed upon. This unpredictability is due
to the fact that the function is always being influenced anew by the state of the
system. This state can be influenced by very different factors depending on the
situation: Sets of experience, personality traits, interests, feelings, moods, people, or
world views (Seliger, 2008, p. 67).
Individuals as well as teams have many different ways of responding to external
stimuli. They are basically self-directed and unpredictable. Taylorism was built on
the opposite view of what constitutes a human being. As is so often the case, the truth
probably lies in the middle: People cannot simply act out all their moods and
impulses at all times. Communities such as families or project teams depend on a
person’s behaviour to remain within the confines of certain norms and conventions.
Therefore, people have to allow themselves to be “trivialised” to a certain extent in
order to become predictable for others. Only in this way can the complexity of living
together be reduced. In society, this means obeying the laws. Project teams, too, can
only function if roles are clarified (Sect. 5.3.1) and common rules of cooperation are
defined and followed (Sect. 5.2.3). In spite of all agreements and rules, human nature
remains “non-trivial”, which is why unpredictable reactions can always occur. This
in turn often leads to conflicts (Sect. 5.6) and makes the design of change processes
so demanding a task (Sect. 5.4).
1.6.4 Systemic Approach to Project Management
“Systemic project management” refers to a holistic project management in which the

human aspects play an essential role. The systemic approach is based on the
assumption that projects are social systems which have a self-dynamic and self-
referential effect and are networked with the environment. Their smallest unit is not
the human being, but personal communication as such. Thus, the focus lies on the
communicative relationships between people and groups: frameworks, rules of the
game, dynamics, and tensions. Communication, too, depends on the framework and
context in which it takes place. Communication is the central core element of social
systems such as projects. This approach leads to the following insights, among
others:
36 1 Introduction
Operational Framework Conditions and Cybernetics

The “project” system is related to the “line organisation” system. The different
cultures create tension and interaction between the two systems. Understanding
these interactions and thinking in control cycles, i.e. thinking in a circular instead
of a linear way, helps to reduce tensions. The differences between the world of the
“line organisation” and the world of the “project” can be influenced, for example, by
the degree of management and decision-making freedom in the project and the
allocation of resources. The nomination and the design of project roles or of the
rules of communication are concrete examples of this. Such measures increase
mutual attention and raise awareness for the fact that attention can be controlled.
The organisational dynamics gained in this way energise the project. Often, how-
ever, little attention is paid to the operational framework and thus to the work on the
system. Therefore, they often hardly ever support projects (Dierig, 2015).
Self-Organisation
Rigid external control contradicts the principles of non-trivial systems and the
systemic world view. This has been recognised in agile project management such
as scrum: The self-organisation of the scrum team is an integral part here. The scrum
master is explicitly responsible for the framework conditions. He works as a “context
manager” on the system. The scrum team organises itself and thus works both in and
on the system. This may be irritating, as it represents a paradigm shift from the clear
hierarchies that are still found in many organisations today.
Self-organisation is based on the process of self-creation and self-maintenance
from biology (autopoiesis). Systems (projects, people) cannot be controlled directly
from the outside. Influences of any kind are processed according to the laws of the
system, based on self-organisation (autopoiesis).
Constructivism
Our perceptions are the product of our brain’s selection and interpretation, each a
subjective construct that does not necessarily correspond to external reality. Every-
thing that is said is said by an observer, i.e. each person in the project and each
stakeholder constructs their own reality. Therefore, it is important that we at regular
intervals compare our ideas in the project and establish a common denominator.
Stakeholder Management
Stakeholder management is also influenced by systems thinking (Sect. 2.3.5). This
involves analysing the relationships with the people and groups involved in and
around the project system and identifying support, critical attitudes, or different
interests in relation to the project. This is the basis for project organisation and
project communication.
Networks
Networking is still little used. For example, sub-project teams that are mutually
networked instead of coordinated by an overall project manager can achieve a much
higher coordination performance in complex situations.
1.7 Versatility and Creativity 37
1.7 Versatility and Creativity
The reason for the existence of every project is to create something new. Be it a new
customer request or an internal problem: the existing products and solution strategies
do not (or no longer) meet the new requirements. The requirement for creativity is
rather low in a standard project (Sect. 1.2.1) but in a potential or pioneer project it is
very high. This will be discussed in the second part of this section. Always essential
for project managers is their versatility.
1.7.1 Versatility
In projects, objectives of medium to high complexity have to be reached in a limited

period of time with interdisciplinary teams. Even if an organisation has handled
many similar projects before, a simple “copy and paste” repetition of a completed
project order or plan does achieve the goal. Projects, as social, living systems, are
always in a process of development and learning. The professionalism of project
managers in both approaches lies in the fact that they always succeed in choosing the
most effective strategy based on the current situation. This is expressed in the
principles of procedure (Sect. 1.3.3), in the choice of process models (Sect.
1.4.6)—or in the design of cooperation. Each new project opens up new scope for
action, which those responsible for the project should recognise and exploit. A lot
can be achieved if the existing resources and competences are optimally integrated
into the design of the new projects.
1.7.2 Creativity as a Surplus of Attention
The crown of versatility is creativity. This is about creating innovation, developing

ideas and approaches to solutions that are new in nature. Specific creativity
techniques are described in Sect. 2.8. Basic thoughts on this topic are presented
here in connection with people and the organisation.
The psychologist Mihaly Csikszentmihalyi has studied creativity scientifically.
He considers creativity to be the central source of human meaning. This is because
all human cultural achievements, be it language, technology, science, art, or the
economy, are the results of human creativity (Csikszentmihalyi, 2015, p. 9).
If you want to be innovative, if you really want to create something new in a
sustainable way, you need a lot of energy. The tried and tested must be let go of and
the boundaries of knowledge must be transcended. Creativity always requires
learning anew. This is not an exclusively pleasurable process; it often also involves
effort, stress, and setbacks.
Humans are limited beings. We can only absorb and process a limited amount of
information at any given time. If we want to learn something, we have to give it our
attention. The problem is that our attention is also limited. First and foremost,
humans need their attention to ensure their survival. As long as our basic need for
38 1 Introduction
bodily integrity is not satisfied, we cannot take care of anything else. In addition,
there are many other expectations from family, friends, and society that require our
attention. In everyday working life, it’s the same song: many things demand
attention. The more we are held captive by operational necessities from the lines
or project work, the less attention is left for the sustainable creation of
something new.
For Csikszentmihalyi, creativity is only ever possible when there is a surplus of
attention (Csikszentmihalyi, 2015, p. 20). As long as people are completely
absorbed with themselves and others, they cannot muster the energy for innovation.
A look back at history also proves this: Significant bursts of human creativity took
place, for example, in Athens in 500 BC, in Florence in the fifteenth century, or in
Paris in the nineteenth century. These were always places and times of relatively
high material prosperity. This allowed people to direct their attention beyond the
necessities of survival to other aspects of life. This enabled enormous developmental
steps in philosophy, art, architecture, and science.
1.7.3 Interplay Between Human, Field and Domain
Creativity is any action, idea, or thing that changes an existing domain or transforms an
existing domain into a new one (Csikszentmihalyi, 2015, p. 48).
A further differentiation seems appropriate in the source of creativity. In many cases,

the individual with his or her good ideas is described as the most important factor for
creativity. Of course, these are important. However, for an idea to become visible,
another aspect is essential: it has to be understandable for other people and
recognised by experts in the specific field. Otherwise, no sustainable innovation
can take place.
Thus, creativity is always the result of interactions between people or groups who
have a new idea, experts (in the field) who can evaluate this idea, and a field (domain)
which is changed by this idea (Csikszentmihalyi, 2015, p. 47 ff.):
Human
Whatever has value also has a price.
Man’s inventiveness is the source of our cultural goods and technology. Currently,
humans are in the process of losing their pioneering role in creativity to artificial
intelligence. Enormous resources are flowing into the further development of artifi-
cial intelligence. Machines and robots are becoming adaptive and autonomous,
beating humans at chess and other things. For Dennis Lück (Lück, NZZaS, 11.3.
2018), it is an extraordinary contradiction that, on the one hand, everything is being
done to promote artificial intelligence, while on the other hand, the foundations of
human creativity are not being sufficiently promoted.
1.7 Versatility and Creativity 39
In addition to heredity, the environment has a significant influence on human

creativity. This brings the school system into focus. Often, the focus in schools is still
on acquiring knowledge. What is needed to be creative, however, are competences
or skills in that domain: it is about developing new approaches to solutions in
complex situations (Sect. 2.3.14), questioning existing rules and methods, learning
from mistakes and failure (Sect. 2.3.5), and to change perspectives (Sect. 3.9.8.3).
Lück recommends more project work for schools, through which students can work
together on topics that really interest them. In this way, they may develop their
competences more than just accumulating knowledge with an expiry date. Thanks to
the fact that people are capable of learning throughout their lives, these
recommendations also apply to all organisations that carry out projects.
Creativity does not come for free: Those who value it must be prepared to pay a
price for it.
Example
With regard to scrum, it was Jeff Sutherland and Ken Schwaber who asked
themselves in the mid-1990s how software development could be made more
effective. Schwaber and Sutherland developed new ideas for handling projects
because they felt that the current project management approaches did not lead to
the desired results. ◄
In order to be creative, a person has to be able to think outside of commonly

accepted norms and habits. In doing so, he challenges the existing system and
confronts it with its weaknesses. Measures to promote creativity are listed in Sect.
2.8.
Field
The field consists of experts and opinion leaders who can assess the content of a new
idea and on whom it also depends whether an idea should or can be developed
further. The field includes all persons and organisations who monitor access to a
subject area (domain). They decide which idea or which new product should be
included in a domain. In project management, the field essentially consists of the
standards and certification models (Sect. 1.8). What is included here becomes part
of the domain. The field of the domain project management also includes the
professional bodies and communities, publishers, established authors, or consulting
and educational institutions.
If Schwaber’s and Sutherland’s ideas had not been taken up by representatives of
the field, it is unlikely that it would ever have become an established procedure as it
is now used in many areas. In a company, the field is often formed by the members of
the management, the head of the PMO, or the project owners in the projects. They
are confronted with the ideas and creative suggestions of their employees. What they
approve of can bring about sustainable change. What they reject or prevent, how-
ever, is lost in most cases.
40 1 Introduction
Domain
In the example of Sutherland and Schwaber, their ideas of agile project management
were adopted into the “cultural asset” of project management. This is what
Csikszentmihalyi calls a domain. Here, knowledge is collected and managed that
is recognised and valid for a specific field.
Each company also has one or more domains in the area of its specific business
activity which allow them to develop value creation. This domain can be in specific
technologies or services and is always linked to a specific process competence in
how the services are provided to the customers.
Every project organisation has also gained experience of some kind in what is the
best way to handle projects in their specific fields of business. Such experiences are
often described in a project management manual. This then serves as a binding
guideline for all project managers on the procedure and methodology of the project.
If those responsible in a company now decide not only to handle their projects
according to the traditional approach, but also to apply agile or hybrid project
management, depending on the type of project, they would thereby expand the
company’s internal domain of project management.
1.7.4 Framework Conditions for Creativity
What consequences do these considerations have for operational project manage-

ment? Creativity is only possible when there is a surplus of attention.
• Project teams are predestined to develop an excess of attention for a specific topic.
• Working on the system (Sect. 1.5.2) is essential: the project team must be
protected as much as possible from disruptive influences from the line
organisation or from other projects, which might divert the attention of
individuals within the team.
• The more a person works on several projects at the same time—while possibly
also having line tasks—the more limited is the attention this person can give to a
specific issue. This is especially a problem in project coordination (Sect. 2.3.8.
• Creativity starts in the individual mind and is supported by good creativity
techniques (Sect. 2.8).
• The field controls access to the domain: this means that the decision-makers in
every project organisation play an essential role: line managers, project owners,
project managers, or product owners: how do they deal with new ideas? Whatever
they reject is lost. Those who pursue illusory approaches waste valuable
resources.
• What organisational culture is effectively lived; what behaviour is rewarded?
(Sect. 4.4) Are project managers encouraged to bring in new ideas? What happens
if something does not work? How is failure dealt with?
• Professional decision-making techniques (Sect. 2.8.3), risk management (Sect. 2.
3.7), and managing stakeholder expectations (Sect. 2.3.5) are integral
components of sustainable creativity.
1.8 Standards and Certification Models in Project Management 41
1.8 Standards and Certification Models in Project

Management
There are different standards and certification models for project management on the
market. The different standards focus on different topics such as competences or
project management processes. At the international level, there are three well-known
certification models: IPMA, PMI, and PRINCE2. In Switzerland, Hermes is widely
used as a process model in public administration. In addition, there are also
standards that describe and structure project management.
Each different certification model specifies its own standard. The advantage of
using a standard is thereby having a common language and a common process
framework in a company or whenever there is cross-company collaboration. How-
ever, if a model is chosen that does not fit the company, the problems in project
management will multiply.
The certifications offered by IPMA, PMI, Prince2, and Hermes are summarised in
Table 1.6.
The scrum alliance offers various certificates in the field of scrum.
1.8.1 IPMA: International Project Management Association
IPMA is spread worldwide and has European origins. For individuals, IPMA offers a
certification system with four levels. The basis for certification is the Individual
Competence Baseline (ICB).
Table 1.6 Overview of certification models

IPMA PMI Prince2 Hermes 5
Project staff Certified Project CAPM PRINCE2 Hermes
Management Associate/ Foundation 2021
Certified Agile Associate Foundation
(Level D) Level
Project manager Certified Project manager/ PMP, PRINCE2 Hermes
Certified Agile Leader PMI-ACP Practitioner 2021
(Level C) PRINCE2 Advanced
Certified Project Senior Agile Level
Manager/Certified Agile Practitioner
Senior Leader (Level B)
Project Director, Certified Project Director/ PgMP,
Programme Manager Certified Agile PfMP
and Portfolio Organisational Leader
Manager (Level A)
42 1 Introduction
In addition to the certification of individuals, IPMA also offers the possibility of

certifying teams in accordance with the Project Excellence Baseline and
organisations with the Organisational Competence Baseline. The certification of
persons on the basis of the ICB is the most successful certification model of IPMA.
The certifications are issued by the respective national organisations (Germany:
Deutsche Gesellschaft für Projektmanagement GPM, Switzerland: Association for
the Certification of Persons in Management VZPM, and Austria: Projekt Manage-
ment Austria PMA) are offered and carried out.
IPMA certification is about proving existing and applied competences. In this
way, IPMA differs significantly from the other certification models, which are very
process-oriented and designed for the application of a defined framework.
IPMA understands individual competence as the application of knowledge, skills,
and abilities to achieve the desired results. Skills build on abilities, which in turn
require knowledge:
• Knowledge is the totality of information and experience that a person possesses

Example: Being able to explain the concept of a Gantt chart
• Skills are specific technical abilities that enable a person to perform a task
Example: Creating a Gantt chart
• Skills describe the effective use of knowledge and skills in a specific context
Example: Creating a project schedule with a Gantt chart and using it to success-
fully manage the project
The heart of the ICB is the “Eye of Competence”. The competences are described
in Sect. 1.3.2. Table 1.7 shows the IPMA certification system for persons.
Table 1.7 IPMA certification areas and certification levels

Domain
Level Project Programmes Portfolio
A Certified Project Director Certified Programme Certified Portfolio
Certified Agile Director Director
Organisational Leader
B Certified Project Senior Certified Senior Certified Senior
Manager Programme Manager Portfolio Manager
Certified Agile Senior
Leader
C Certified Project manager
Certified Agile Leader
D Certified Project
Management Associate
Certified Agile Associate
In Switzerland, certification at level D is purely a knowledge examination with an

“open book”. For certification at levels B and C, proof of project experience and a
completed project is required in addition to the knowledge examination. The candi-
date has to prove in a written report and an interview how he has applied the
individual competences in his reference project. At level A, the knowledge test is
omitted.
1.8.2 PMI: Project Management Institute
PMI is a globally established provider of a certification system. In the USA, PMI is

the de facto standard for project management. The certifications are carried out
directly by PMI. There are country-specific chapters that serve the networking and
dissemination of PMI methods.
The certifications are based on the PMBOK® Guide (Project Management Body
of Knowledge), which since the seventh edition also supports agile project manage-
ment in addition to traditional project management (Project Management Institute,
2021). In addition to organisational influences on project management, the
PMBOK® Guide describes a project process as having four phases. The
PMBOK® Guide structures the project process into eight performance domains
and 12 principles. These performance domains are:
• Team
• Stakeholders
• Life cycle
• Planning
• Navigating uncertainty and ambiguity
• Delivery
• Performance
• Project work
The PMI offers the following eight certification options, these are, among others:
• CAPM, Certified Associate in Project Management

• PMP, Project Management Professional
• PgMP, Programme Management Professional
• PfMP, Portfolio Management Professional
• PMI-PBA, PMI Professional in Business Analysis
• PMI-ACP, PMI Agile Certified Practitioner
• PMI-RMP, PMI Risk Management Professional
• PMI-SP, PMI Scheduling Professional
44 1 Introduction
The certification is done via a multiple-choice exam (closed book) and is based on
the PMBOK® Guide.
1.8.3 PRINCE2
PRINCE2 is the de facto standard for project management in the UK. Prince2 stands
for “Projects in Controlled Environment”. PRINCE2 was originally developed by
the British government. Today, PRINCE2 is offered by the company AXELOS Ltd.
PRINCE2 is a very detailed and integrated process model that defines exactly
what needs to be done in the project from start to finish. PRINCE2 focuses on the
framework provided. It is less about a set of methods or competences. Figure 1.18
shows the Prince2 project management system, consisting of basic principles,
themes, and processes.
Project environment
Business case
Progress Organisation
PRINCE 2 processes
Change Quality
Risk Plans
PRINCE 2 themes
PRINCE 2 principles
Fig. 1.18 Overview of Prince2 Model

The seven basic principles of PRINCE2 are:
• On-going business justification

• Learn from experience
• Defined roles and responsibilities
• Control over management phases
• Taxes according to the exception principle
• Product orientation
• Adapt to the project environment
The seven themes of PRINCE2 are:
• Business case (What for?)

• Organisation (Who?)
• Quality (What?)
• Plans (How? How much? When?)
• Risks (What if?)
• Changes (What are the effects?)
• Progress (Where are we? Where do we go from here? Shall we continue?)
The seven processes of PRINCE2 are:
• Prepare project
• Steer project
• Initiate project
• Control a phase
• Manage product delivery
• Manage phase transition
• Complete project
The following certifications are offered for PRINCE2:
• PRINCE2 2017 Foundation

• PRINCE2 2017 Practitioner
• PRINCE2 2017 Agile Practitioner
Certification is by means of a multiple-choice examination (open book) and is

based on the current PRINCE2 manual.
1.8.4 Hermes
Hermes is the project management method for public administrations in Switzerland.

Hermes 2021 supports the control, management, and execution of projects having
different characteristics and degrees of complexity. The so-called scenarios are
46 1 Introduction
available free of charge for different types of projects such as development or

adaptation of services or products, IT application development and adaptation, IT
infrastructure and organisational adaptation, each in traditional or agile execution. In
the Hermes 2021 version, there are 6 phases, 3 for traditional and 1 for agile
implementation, as well as 2 joint phases (traditional and agile). As part of an
evolutionary adaptation, proven agile aspects were integrated into the basically
traditional project implementation, resulting in a hybrid approach. A scenario
consists of modules. A module contains the thematically related tasks, results, and
roles. They are assigned to the phases.
The following certifications are offered for Hermes:
• Hermes Foundation Level for Project Staff (Exam: multiple choice)

• Hermes Advanced Level for Project managers (exam with multiple-choice and
open questions)
1.8.5 Scrum Alliance
The goal of the scrum alliance is to further establish scrum. To this end, the scrum
alliance offers certifications for scrum:
• Certified scrum master

• Certified scrum product owner
• Certified scrum developer
Building on this, the certification as a certified scrum professional can then be

completed.
1.8.6 DIN 69901 and ISO 21500
In Germany, there is DIN 69901 a series of standards for the standardisation of

project management:
• DIN 69901-1 Basics

• DIN 69901-2 Processes, process model
• DIN 69901-3 Methods
• DIN 69901-4 Data, data model
• DIN 69901-5 Terms
At the international level, there is the standard ISO 21500 “Guide to Project
Management”, which describes terms, basics, processes, and process models in
project management. Both standards represent the traditional view of project man-
agement and do not give clear recommendations regarding the process model. Agile
1.9 Project Portfolio, Multi-Project and Programme Management 47
project management had not yet been incorporated into the standards by the time this
book went to press.
1.9 Project Portfolio, Multi-Project and Programme

Management
Many organisations are suffering from a project boom that completely diverts the
available resources. For reasons that are not always accessible, every problem is
turned into a project, or the simple solution to a problem is called a project. Often this
has to do with the fact that many managers feel overpowered by having to make
serious or unpleasant management decisions. They therefore delegate these to a
project or leave unanswered which criteria should be used to separate something
from the line organisation into a project.
The management of projects is often underestimated. An overview of all the
projects running in the company as a whole is missing or inadequate. This means that
it is neither possible to prioritise the individual projects, nor can the available
resources be used in a targeted manner. A project portfolio can provide support
here as an overview and decision-making aid. In practice, portfolio management is
also called multi-project management (Table 1.8). For the implementation of strate-
gic initiatives, it can also be helpful to bundle projects in a programme. These
different topics can be distinguished from each other as follows:
The focus of this book is on project management. The topics of project portfolio
and programme management are dealt with in Sect. 2.7 in more depth.
Table 1.8 Project portfolio, multi-project, and programme management

Project portfolio • Strategically oriented and interdependent management of
management = multi-project all projects of a company or division
management • A project portfolio consists of individual projects and/or
programmes
• A project portfolio has no time limit
• Configure, prioritise, and control project portfolios to do
the right things
Programme management • Serves to implement selected strategic initiatives and
objectives
• Composed of the implementation of various projects
• Lasts until the strategic initiatives are implemented and
the strategic objectives are achieved. A programme is thus
limited in time
• After the end of the programme, the temporary structure
of the programme management will also be dismantled
Project management • Project management is used to design, steer, and control
individual projects: doing things right
48 1 Introduction
References
Beck, K., Schwaber, K., Sutherland, J., et al. (2001). Manifesto for agile software development.
http://agilemanifesto.org
Csikszentmihalyi, M. (1997). Flow und Kreativität (2. Auflage, 2015). Klett-Cotta.
Dierig, S. (2015). Projektkompetenz im Unternehmen entwickeln. Wissenschaftlicher Verlag Berlin.
Königswieser, R., & Hillebrand, M. (2004). Einführung in die systemische Organisationsberatung.
Carl-Auer-Systeme Verlag.
Kotter, J. P. (2012). Leading Change: Wie Sie Ihr Unternehmen in acht Schritten erfolgreich
verändern. Vahlen Verlag.
Lück, NZZaS, 11.3.2018.
Oestereich, B., & Schröder, C. (2017). Das kollegial geführte Unternehmen: Ideen und Praktiken
für die agile Organisation von morgen. Verlag Franz Vahlen GmbH.
Pflaeging, N., & Hermann, S. (2015). Komplexithoden. Clevere Wege zur (Wieder)Belebung von
Unternehmen und Arbeit in Komplexität. Redline.
Project Management Institute. (2021). PMBOK® Guide in der 7. Edition.
Seliger, R. (2008). Das Dschungelbuch der Führung (5. Auflage, 2014 Ausg.). Carl-Auer
Verlag GmbH.
Wohland, G., Huther-Fries, J., Wiemeyer, M., & Wilmes, J. (Eds.). (2004). Vom Wissen zum
Können. Merkmale dynamikrobuster Höchstleistung. Eine empirische Untersuchung auf
systemtheoretischer Basis. Detecon & Diebold Consultants.
Further Readings
Doppler, K., & Lauterburg, C. (1994). Change Management, den Unternehmenswandel gestalten
(13. Auflage 2014). Campus.
Königswieser, R., Sonuc, E., & Gebhardt, J. (2008). Komplementärberatung. Das Zusammenspiel
von Fach- und Prozeß-Know-how. Klett-Cotta.
Petersen, D., Witschi, U., Kötter, W., & Bahlow, J. (2011). Den Wandel verändern. Change-
Management anders gesehen. Gabler Verlag | Springer Fachmedien.
Methodology
2
2.1 Introduction
2.1.1 Traditional, Agile and Hybrid
Chapter 1 gives a brief introduction to the traditional, agile, and hybrid approach
to project management. In the traditional approach, a project is divided into phases;
the result is available at the end of the project. In the agile approach, partial results
are produced continuously.
On closer inspection, an agile approach such as scrum also goes through a shortened
concept phase, a realisation phase, and an introductory phase. In the agile approach, the
tasks of initialisation are carried out before or often together with a refinement of the
product vision, the product backlog, and the release plan in the concept phase.
The most important phase in the agile method is the realisation phase. After a
defined number of sprints, a release goes live. This go-live phase is comparable to
the introduction phase in the traditional approach.
In this handbook on project management, the traditional and agile approaches are not
treated separately. In terms of hybrid project management, the elements of the traditional
and agile approach are explained and expanded on the basis of the phases of traditional
project management (project commissioning, initialisation, concept, realisation, and intro-
duction). Hybrid project management leaves open the issue how the parts of the traditional
and agile approach are to be combined with each other. It must be decided on a situational
basis which of the combination options should be used in hybrid project management:
• Traditional and agile phases

• Traditionally and agilely handled sub-project
• Situational combination of elements from the traditional and agile approach
methods (e.g. daily stand-up meeting and retrospective in the traditional approach)
Focus of the Traditional and Agile Approach in the Specific Phases

The compass in Figs. 2.1 and 2.2 provides an overview of the focus, activities (risk
management, planning, controlling, information, and communication) and of the

https://doi.org/10.1007/978-3-662-66211-3_2
50 2 Methodology
Project Management Compass Agile
Preparation phase 0 Commissioning

Project phases
0 1 Initialisation 1
Usage phase
Agile project
(based on Scrum)
Focus Idea Constitute project team
Risk management First risk assessment List risks
Planning Business case, profitability Feasibility study

Assess financial viability
Controlling
Information & Set up project handbook

communication
Results Project factsheet (1-Pager) Project order

Business case Stakeholder analysis
Project request Risk list
2 Concept 2 3 Realisation 3 4 Introduction

4
Usage
Product target / Product concept Implementation (sprints) Acceptance
Assess risks Ongoing monitoring Ongoing monitoring

Agree on measures
Release planning Update product backlog Update product backlog

and release plan and release plan
Sprint planning Sprint planning
Daily standup meeting Daily standup meeting
Sprint review Sprint review

Burndown charts (release, sprint) Burndown charts (release, sprint)
Daily standup meeting Daily standup meeting Daily standup meeting

Retrospective Retrospective
Product target / product concept Sprint backlog Acceptance protocol

Product backlog Increment Project closure
Updated produt backlog
Release plan Updated release plan
Test concept Implementation or operating concept
Fig. 2.1 Project management compass for the agile approach

2.1 Introduction 51
Project Management Compass traditional
Preparation phase 0 Commissioning

0
Project phases 1 Initialisation 1
Usage phase
Traditional project
Focus Idea Project targets / specification (WHAT)

Check and confirm feasibility
Project structuring, rough planning
Constitute project team
Risk management First risk assessment Identify risks
Planning Business ase, Profitability Feasibility study

Assess financial viability Project structuring
Phase and milestone plan
Project structure plan
Controlling Project status meeting

Constitute project steering
Information & Set up project handbook

Communication Conduct kick-off
Results Project factsheet (1-Pager) Project order

Business Case Specification (HOW)
Project request Stakeholder analysis
Risk list
Project plan (milestone
and project structureplan)
Deliverables
2 Concept 2 3 Realisation 3 4 Introduction

4
Usage
Solution concept (HOW) Implementation (development, Serial production (product)

Detailed planning construction, etc.) Launch (system, plant)
Test Go-live (software)
Assess risks Ongoing monitoring Ongoing monitoring

Agree on measures
Detailed planning Ongoing monitoring Ongoing monitoring

Time and cost planning Change request management Change request management
Resource planning
Progress control Progress control Progress control

Corrective measures Corrective measures Corrective measures
Steering group Steering group Steering group
Project status meeting Project status meeting Project status meeting

Reporting Reporting Reporting
Technical specification Test reports Series release (product)

Time and cost planning Construction release Acceptance protocol (system,plant)
Resource planning Content results Project closure
Risk management tool Lessons learned
Introduction concept
Quality management plan
Test concept, operating concept
Fig. 2.2 Project management compass for the traditional approach

52 2 Methodology
Discovery Realisation Introduction
Daily Scrum
Retro
Product
Target
•
• Sprint Planning Sprint Review Increment
•
DoD
1.
Product 2.
Backlog 3.
Sprint Backlog
Sprint Target Refinement
Release Plan Release
Fig. 2.3 Agile project planning
results in the individual phases for the agile and traditional approaches. The
overview clearly shows that the discussion of WHAT and HOW takes place at a
later stage in the agile approach than it does in the traditional approach.
Different Approach in the Planning of the Project

The agile and the traditional approach follow different concepts in the planning of
the project.
In the agile approach, only rough planning takes place in the concept phase.
Since we work with a fixed team, resource and cost planning is simplified. Detailed
planning is only carried out immediately before the implementation of a sprint.
Planning in scrum is conducted on three levels as is shown in an overview in
Fig. 2.3:
• In release planning during the concept phase, the following points are deter-
mined: Planning the number of sprints, determining the provisional order of
implementation of the requirements from the product backlog, and determining
the go-live dates of releases. The release plan is dynamic and is constantly
adapted to the latest circumstances.
• During sprint planning in the realisation phase, the activities of a sprint are
planned. The result is recorded in the sprint backlog.
• The planning of the work day takes place in the daily scrum.
2.1 Introduction 53
Fig. 2.4 Traditional project planning, consisting of project structuring and detailed planning
In the traditional approach, planning takes place over several stages. After the
objectives and requirements (specifications) have been defined in the initialisation
phase, the project is structured (rough planning) according to Fig. 2.4. The project
structuring contains the following elements:
• Project phases and milestones

• Work breakdown structure with sub-projects, deliverables, and work packages
with a rough cost estimate
In the concept phase, solution variants are developed for the requirements. For the
selected solution variant, a detailed elaboration of the solution concept takes place.
The detailed planning of the project is based on the solution concept. The detailed
planning contains the following elements:
• Schedule
• Resource plan
• Cost plan
2.1.2 Accuracy of Estimates
An estimate is a provisional or preliminary calculation. However, the project owner

or the management of the company expects a cost estimate that is as reliable and
dependable as possible.
In the agile approach, this context is taken into account by defining the duration
(timeboxing) and the costs of the project in advance. The uncertainty then lies in the
effective scope of services that will be realised.
54 2 Methodology
In the traditional approach, the scope of work is fixed. For simple projects and
standard projects, the estimation of the duration and costs is relatively reliable. For
large projects, pioneer or potential projects, estimating the duration and the costs is
subject to many uncertainty factors and is accordingly inaccurate at the beginning.
The inaccuracies decrease as the project progresses, see Sect. 2.4.7.3. Depending on
the type of project, the following tolerances must be expected in the phases:
• After project order: +100%/–50% or more

• After project structuring: +40%/–20%
• According to detailed planning: ±10%
2.1.3 Practical Examples
The theory discussed is supported by the following two real-life examples of hybrid
project management.
BLS AG
BLS is one of the largest transport companies in Switzerland. In its core rail business,
BLS operates the Bern S-Bahn and thus the second largest S-Bahn network in
Switzerland. BLS also operates the western lines of the Central Switzerland
S-Bahn and is besides that anchored in tourist transport. Its services include railway
lines through the Emmental, lines in the Jura, the Seeland, the Simmental, to
Interlaken, and the Lötschberg mountain line. Furthermore, BLS operates InterRegio
and RegioExpress lines. BLS is active in the areas of bus, ship, car transport, and
freight transport, too:
• In Emmental and Oberaargau, BLS operates a bus network of 18 lines with its
subsidiary Busland AG.
• BLS shipping on Lake Thun and Lake Brienz is a flagship for the Bernese
Oberland as a tourist destination.
• The BLS car transport on the Lötschberg from Kandersteg to Goppenstein offers
a fast connection from Bern to the Valais all year round. With the car transport
from Brig to Iselle, BLS also offers a connection to Italy.
• The subsidiary BLS Cargo AG occupies a central position in rail freight transport
through the Alps.
Project Sales Back-End VBE

Two developments in public transport formed the basis of this project. Firstly, the
public transport platform and the associated standard interface NOVA were devel-
oped in the industry project ZPS (future pricing system public transport
Switzerland). Each transport company can connect its own distribution systems to
this interface. In order to effectively sell tickets from the public transport platform, a
dedicated distribution back-end and front-end are needed. Secondly, due to market
trends and the on-going digitalisation of society, the importance of digital sales is
2.1 Introduction 55
increasing strongly. In order to meet this trend as well as the underlying needs, and to
strengthen its customer orientation, BLS has to be able to serve its customers via the
internet as well as via a mobile channel.
The VBE project brought these two developments together, aiming to realise a
separate, independent, and multi-client capable sales back-end—including a mobile
solution and an online sales channel based on the future industry standard public
transport platform/NOVA.
Metrohm AG
Metrohm AG is one of the world’s largest manufacturers of high-precision
instruments for chemical analysis. It was founded in 1943 by engineer Bertold
Suhner in Herisau, Switzerland. Metrohm has made it from a start-up to a global
player and is now present in more than 80 countries with its own subsidiaries and
exclusive sales partners and a good 2200 employees. As the worldwide market
leader for analytical instruments in the titration sector, Metrohm develops solutions
for all ion analysis tasks.
OMNIS Titration System Project

The OMNIS project developed a fully integrated titration system that meets the
needs of today’s laboratory and delivers faster results with more safety, convenience,
and efficiency. The fully integrated system included the titrator, liquid handling
modules, new software, and a new sample robot. OMNIS offers performance at a
whole new level, having all the answers to the growing demands of everyday
laboratory operations:
• Quadrupling of sample throughput: With a single system, four analyses can be

carried out simultaneously and fully automatically.
56 2 Methodology
• Touch-free chemical handling: Thanks to the patented 3S adapter technology, no

bottle needs to be opened when changing reagents.
• An analysis platform that everyone can master: thanks to intuitive system man-
agement, OMNIS can be operated by almost all users.
The OMNIS titration platform project was launched 6 years before the planned
market release.
2.2 Project Commissioning Phase
Changed market conditions, customer demands, and the pressure to realise effi-
ciency gains force companies to implement projects on an on-going basis. Usually
there are more requests for new projects than a company can afford. The project idea
has to first make it into the portfolio of projects in the project commissioning phase
(Sect. 2.7).
The project owner and other staff (e.g. the portfolio manager, product manager, or
project manager) then clarify whether a new project is worthy. For this purpose, a
project factsheet and a business case (Sect. 2.2.3) are developed and included in the
project portfolio discussion. The project factsheet clarifies the most important key
data of the project idea: namely, the objectives, added value to be created, an
approximate idea of how much time it will take, what the budget is, and its relation
to the strategy. The business case clarifies the strategic relevance, the benefits, and
the economic viability. In this phase, the project is not yet planned in concrete terms,
but a sufficient amount of key data is gathered so that the management can decide
which projects should be implemented and which should not. Ideally, the project
manager, the product owner, or scrum master are also appointed in this phase, at the
end of which the project proposal is drawn up to plan the initialisation phase.
Figure 2.5 shows a possible sequence of project factsheet, project proposal, and
2.2 Project Commissioning Phase 57
Project Project Project

factsheet request order
Global Detailed
Vision target targets
Require-
ments
Requirement Technical
specification specification
Commissioning Initialisation Conzept Realisation Introduction
Fig. 2.5 Step-by-step operationalisation of the project objectives
project order as well as the objectives hierarchy and the assignment of requirements
and specifications to the corresponding phases (see also Table 2.37).
In this phase, there are no specific distinctions between projects that are handled
agilely or traditionally. For small projects and order processing projects, this phase
can be shortened or skipped.
2.2.1 What Is Important in the Commissioning Phase?
Steps of the Project Commissioning Phase

Table 2.1 shows the most important steps in the project commissioning phase.
Results of the Project Commissioning Phase

In the project commissioning phase, the project is usually not yet public. This means
that communication is limited to a very small number of people or bodies involved.
Especially in this circle, communication must be very carefully designed. In
strategically important projects, the decision-makers have to deal with whether
they want to show the intention to go ahead with this project to the outside world
or whether strict secrecy should apply, e.g. in development projects. This phase is
about deciding whether the project should be implemented or not, or whether the
next stage of concretisation should rather first be worked out. The results of the
project commissioning phase are shown in Table 2.2.
58 2 Methodology
Table 2.1 Steps of the project commissioning phase

Work step Description
Check project The following criteria apply when deciding whether a project is to be
worthiness handled as an order within the line or as an overarching project:
• Are other areas affected?
• Which areas have to contribute to how many resources?
• What is the significance and what are the consequences of the project
for the future of the company?
• What are the risks?
• What happens if the project is stopped?
Record the project Develop a project factsheet and business case. These documents are
factsheet and business the basis for the decision on whether or not to implement the project.
case in writing
Planning: first rough At a very early stage, as soon as an idea begins to take shape, the
estimate project initiator will consider how much effort it will take to
implement the idea and what else is needed
In this phase we cannot speak of planning, it’s more of a first idea. The
uncertainty characteristic of a rough estimate can vary greatly,
e.g. +100%/–50%. For projects with a high novelty value, it can be
even greater (see also Sect. 1.2.1)
If a project-worthy idea is further clarified and a project factsheet and
a business case emerge from it, the project owner wants a rough
estimate of the resources required and wants to also know by when the
project will be completed and at what cost, and by when interim
results can be expected
Preparation of project Once the decision has been made to carry out the project, the next step
proposal and planning is to prepare the project proposal, answering the following questions:
of the next phase • What results must be achieved at the end of the initialisation
(initialisation) phase?
• Which interim objectives must be achieved by when in order to
enable the initialisation phase to be completed on schedule?
• Are there specific risks or problems that need to be clarified? Does a
risk analysis or feasibility study need to be carried out?
• How should the focus of work be set in this phase in order to make
the best use of resources?
• What special knowledge is needed for this?
• Where is the use of bottleneck resources required?
• Who is available? With what experience? Is there already a binding
commitment from the line organisation?
• Does an activity need to be initialised earlier because it has an
excessive lead time?
• What internal and external costs will be incurred in the next phase?
People and Team

The following aspects from the competence areas of people and team may be
relevant in this phase of the project. However, they may also occur at a later stage
or not at all.
In this first project phase, an informal team is usually created that has the
necessary technical and methodological expertise to identify the critical success
2.2 Project Commissioning Phase 59
Table 2.2 Results of the project commissioning phase

Questions to be • Is the project feasible with the available resources in addition to the
answered decided project portfolio?
• Is it worthwhile to carry out this project, considering the effort and
expected benefits?
Process-oriented • Project factsheet
results • Project request for the initialisation phase
Content-oriented • Business case: Consideration of whether the project is economic and
results makes sense from the point of view of the market, corporate strategy, etc.
• Depending on the type of project and situation: initial feasibility
assessments, rough coordination of resources, basic financial feasibility
factors of the project idea and to formulate the business case and project request. The
following actions and competences are important.
• Lateral leadership (Sect. 4.4.3): Usually a formal organisation is not formed in

this phase, but a coordinator is appointed who leads his team laterally.
• Work in the system (Sects. 1.5.1 and 5.2.4): The content-related work is in the
foreground.
• Versatility and creativity (Sect. 1.7): From the beginning, different variants and
scenarios should be illuminated.
• Informal network (Sect. 4.9.3): The project manager has no official mandate at
this stage. How effectively he can fulfil his mandate in this situation depends
strongly on his informal network.
2.2.2 Project Factsheet
In the project factsheet (1-pager), the idea for a project is recorded in a structured
manner and made more concrete. The project factsheet should be brief and contain
statements on the following contents:
• Project name
• Strategic reference
• Short description
• Brief history (how did the project come about, what previous work has
been done?)
• Expected added value, benefits, revenue (from the business case)
• Expected costs (from the business case), rough resource requirements
• Choice of process model (agile, traditional, hybrid)
• Estimated start and end date
• Designation of central project roles (project owner, project manager or product
owner, scrum master)
• Known dependencies
• First risk assessment
60 2 Methodology
The project factsheet, together with the business case, serves as the basis for
deciding whether the formulated idea should be pursued further and a concrete
project should be launched. Every company is organised and positioned differently.
Typically, such decisions are made during strategic planning, project portfolio
planning, multi-year or budget planning. The body in which such decisions are
made also varies: executive board, portfolio board. In the case of order processing
projects, the project factsheet can also correspond to the customer’s quotation or
order, possibly supplemented with internal company requirements.
2.2.3 Business Case
Organisations live through the creation of benefits. That is why the question of the
benefit of a project idea arises at a very early stage. An organisation can survive in
our economic system if it has enough money at its disposal. Every planned project
must be examined to see if it improves the chances of the organisation’s survival.
Whether a project should be undertaken must be assessed by the project owner or
the relevant body before the contract is awarded. Not only quantifiable monetary
values, but also strategic considerations, philosophies, resources, etc. play a role. In
the run-up to a project many organisations require, together with the project
factsheet, a business case with the following content:
• Problem and justification of the project

• SWOT analysis
• Customer needs and market potential
• Framework conditions
• Competitive position
• Strategic relevance, contribution to the achievement of strategic objectives (strat-
egy alignment)
• Marketing mix
• Economic efficiency (expected added value, benefits, revenues, investment and
operating costs, result, return on investment)
• Non-monetary benefit for the company
• Effects of non-implementation
2.2.4 Project Request
If a company decides to carry out the project on the basis of a project factsheet and a
business case, the next step is to then prepare the project request for the initialisation
phase.
The project proposal corresponds in essential parts to the project order. However,
the project request only considers just the initialisation phase and not the whole
project and regulates the following points:
2.3 Initialisation Phase 61
• Objectives for the initialisation phase

• Basics (on what preliminary work or basics is the project based?)
• Delimitations (project boundaries, project scope)
• Dependencies
• Framework conditions
• Results and deliverables of the initialisation phase
• Project costs and personnel resources for the initialisation phase
• Risks
• Project plan for the initialisation phase (procedure and schedule)
• Project organisation for the initialisation phase
• Signatures of project owner and project manager, product owner
Some companies do not just focus on the initialisation phase and the content of
the project proposal alone. As a preliminary stage for the project order, they already
roughly plan the whole project. They also estimate the total costs and the follow-up
costs such as those of operating.
2.2.5 Checklist Completion Project Commissioning
• Has the project proposal been prepared?

• Have project eligibility and priority been clarified?
– Does this project fit into the corporate strategy?
– Is this project mandatory?
– What are the consequences of failure to do the project?
• What position of importance does the project have in the portfolio?
• Has an economic feasibility study been carried out with realistic
assumptions?
• Has the business case been prepared?
• Has the choice of process model been made: agile, traditional, hybrid?
• Has the initialisation phase been planned? Results, intermediate objectives,
resources, deadlines, means?
• Has the project request been approved?
2.3 Initialisation Phase
In the initialisation phase, binding statements on feasibility, risks, and

stakeholders are to be drawn up in the traditional approach. Essential bases for
this are the analysis of the current situation as well as clearly agreed objectives and
the formulation of requirements.
It is a declared concern to reduce the uncertainties and risks that exist at the
beginning of a project as quickly and as far as possible. If the objectives and
62 2 Methodology
requirements go to the limits of what is possible, or if what is possible is only

vaguely known (technological limits, politically sensitive objectives), it makes sense
to conduct a preliminary study (similar terms: feasibility study, pre-project) or to
choose an agile approach to project implementation before carrying out the whole
project. If it becomes apparent that it is not realistic to achieve the objectives with
one’s own possibilities, it is advisable to cancel the project at this stage. This avoids
using valuable resources on a hopeless project.
In the initialisation phase, the project order is drawn up. This sets out the
objectives, the procedure, the project organisation, plans and the framework
conditions for the project. Formally, the project owner is responsible for the project
order. In practice, the product owner or the project manager prepares the document.
This makes it much more likely that both parties agree and mean the same thing. The
project order is signed by the project owner and the product owner or by the project
manager. This formalism protects the company from an unmanageable excess of
projects and instead gives the project team a clear direction. In the agile approach,
this phase is very short or even left out.
2.3.1 What is Important in the Initialisation Phase?
Steps of This Phase

Initialisation must be carried out carefully in the traditional approach: The points
along the path that are set in this phase have the greatest impact (Fig. 2.6). At the
beginning, project decisions or risk provisions (blue) have a great influence on the
project. Towards the end of the project, costs (red) are high, but decisions have little
influence on this. Often the initialisation is done too superficially. This is paid for
dearly with additional time and resources later on.
The project is officially launched, the kick-off is held with the project team.
If the initialisation concludes with a request to continue the project, the decision-
maker must give the go-ahead for the project to proceed. In the opposite case, the
project has to be terminated. Results achieved so far have to be documented in such a
way that they can be put to further use if required. The participants are to be thanked
for their work. The commitment to the protection of resources should be
acknowledged.
Early in the initialisation phase, a decision has to be made as to whether the
project ought to be implemented using the traditional, agile, and hybrid approach.
Table 2.3 shows the most important steps of the initialisation phase in the agile and
traditional approach.
Results of the Initialisation Phase

In the initialisation phase, the feasibility is checked and thus it is clarified whether
the project is feasible and whether it will generate sufficient benefits. If the
conviction matures that the project has to be done, the next phase and the project
are planned. Depending on the chosen approach, traditional, agile, or hybrid, the
results set out in Table 2.4 are elaborated. As soon as the project order has been
released, the kick-off is held with the project team.
Risk
large
Relative importance Project costs
of the decisions
Knowledge
medium Risk
typical management
attention
small Time
Initialisation Concept Realisation Introduction
Fig. 2.6 Possibilities of influence in the project
Table 2.3 Steps of the initialisation phase

Agile approach Traditional approach
Most Clarify initial situation and Clarify the initial situation and the problem
important problem Survey and analyse the current situation
steps Survey and analyse the Clarify and define objectives
current situation Define requirements (specifications)
Clarify and define objectives Analyse stakeholders
Analyse stakeholders Check feasibility
Draw up a rough project Prepare a detailed project order:
order: • Objective
• Objective • Procedure plan: Methods, steps, milestones,
• Plan of procedure: Methods, rough schedule, project structure plan
very rough schedule • Dependencies and influencing variables
• Human resources and • Human resources and project organisation
project organisation • Rough estimate of the project costs
• Rough estimate of the • Framework conditions and delimitations
project costs Identify risks
Identify risks Write project manual
Write project manual Set the rules of the game
Set the rules of the game Carry out project kick-off
Carry out project kick-off
64 2 Methodology
Table 2.4 Results of the initialisation phase

Phases
and
activities Agile approach Traditional approach
Principle In the agile approach, this phase will be In the traditional approach, the project
very short. Only the rough key data is planned comprehensively. This
from the commissioning phase are allows clear statements to be made
checked and, if necessary, concretised. about deadlines, costs, and resources
The planning of the project takes place
with the creation of the release plan in
the Concept phase and in the respective
planning of the individual iterations of
the Realisation phase
Questions • Who are the relevant stakeholders? • By when can the results or interim
to be • Who is the product owner, scrum results be expected?
answered master, and who are the developers? • What is the planning for the project?
• What is the composition of the • What is the estimated effort in person-
scrum team? days?
• What are the rough benchmarks for • How much money is to be invested
the project? over the entire duration of the project?
• How are the risks assessed? • Who are the relevant stakeholders?
• Who is the project manager?
• Who are the sub-project managers?
• What is the composition of the team?
• Which bottleneck resources are
needed in which time period?
• How are the risks assessed?
Process- Project order as a document of agreement between two parties:
oriented • Procedure plan: Methods, steps, milestones, first deadline, resources, and cost-
results plans (in a more detailed form for the traditional than for the agile approach).
• Project organisation
• Plan of action for the next phase
• Information and communication concept (internal and external) and rules of the
game
Project manual, project management plan
Risk list
Stakeholder analysis
Status reports, protocols
Application for the next phase
Content- In the agile approach, it is not until the Documents in the traditional procedure,
oriented concept phase that the in-depth which concern the substantive results:
results discussion of content takes place in • Prerequisites and assumptions
order to create the product concept • Weaknesses and deficiencies of the
(product goal). This means that no current state
content-related topics are developed • In-depth market studies, surveys,
in the initialisation phase. At most, the employee interviews, etc.
feasibility is checked • Revised, detailed objective
• Requirements/specifications
• Examination and assessment of
feasibility, costs, economic viability,
risks, and detailed profitability
calculation
(continued)
Table 2.4 (continued)

Phases
and
activities Agile approach Traditional approach
Concept: in the initialisation phase,
solution concepts are not yet in the
foreground. Here, analysis results and
objectives are more decisive. Solutions
are initially limited to ideas for
solutions or rough variants
Critical Success Factors and Key Performance Indicators

The concept of Critical Success Factors (CSF) can be applied at the level of a
company, but also within a project. CSFs are the factors and key variables that are
central to the achievement of the project’s objective. The CSFs of a project are
directly related to the CSFs of the company. The product owner or project manager
has to be able to align the CSFs of the project with the CSFs of the company.
Addressing the CSFs is important in the initialisation phase as this helps to align the
project more effectively to achieve its objectives. Critical success factors in a project
can be:
• Project approach
• Project start
• Project organisation and the filling of roles
• Experience of the key people in the project
• Motivation and cooperation of the project team
• Managing the magic triangle of scope, time, and cost
• Stakeholder management
• Risk management
• Agile or traditional project planning
• Dealing with stress, resistance, and conflicts in the project team
Based on the defined CSFs, the project strategy (Best in Market, Design to Cost,
Time to Market) (Sect. 2.3.4) can be determined.
Key Performance Indicators (KPI)) are performance indicators. They help to
continuously measure and assess the progress of the project and the degree of goal
achievement. KPIs are used to manage CSFs. Each critical success factor (CSF) has
one or more KPIs.
People and Team

The aspects below from the competence areas of people and team may be relevant in
this phase of the project. However, they may also occur at a later stage or not at all.
During initialisation, the team organisation is formalised based on the choice of
the methodological approach (agile, traditional, or hybrid). In addition to this, the
project order is then negotiated. This results in the following measures.
66 2 Methodology
• Depending on the chosen methodology (agile, hybrid, traditional), the corresponding

key positions in the team have to be filled (agile: Sect. 2.3.8.4—traditional:
Sect. 2.3.8.5).
• Select key people: Choosing the right project manager, product owner or scrum
master is crucial for the success of the project.
• Working on the system (Sect. 1.5.2): With the official project order, the coopera-
tion in the team has to be formalised.
• Manage stakeholders (Sect. 2.3.5): Recording different views and expectations of
stakeholders and managing their networking begins in this phase. Even small
changes are noticeable in this network.
• Setting up teams (Sect. 5.3.1) and roles in the agile Sect. 2.3.8.4) and traditional
(Sect. 2.3.8.5) approach.
• Consider dynamics in teams (Sect. 5.2): A project team can already fall from
“forming” into “storming” even in this first official project phase. This increases
the competences in personal communication (Sect. 3.9) and in conflict manage-
ment (Sect. 5.6).
• Negotiations (Sect. 4.10): Project managers are strongly challenged in this phase
to work out a project order with the responsible decision-makers, in which the
influencing factors of the magic triangle (Sect. 2.3.4) as well as the distribution of
task, competence, and responsibility (Sect. 4.8) are in a realistic relationship to
each other. Negotiation as an important competence is required here.
2.3.2 Setting Objectives
Objectives are statements about what is to be achieved with future solutions or what
future state is to be aimed for. They are ideas, wishes, hopes, emotions around the
question: What is to be achieved? Solutions, on the other hand, are not objectives,
rather possible ways how objectives can be achieved.
It often makes sense to distinguish between objectives and requirements. While
objectives state what is to be achieved by a solution, requirements describe the quality
of a solution or of a system that is required in order to achieve the objectives.
Requirements are derived from objectives and listed in the “catalogue of requirements”
(e.g. for offers). Objectives and requirements are often used synonymously: In this
case, a distinction has to be made between objectives and detailed objectives.
The importance of setting an objective is different in the traditional and in the
agile approach. In traditional project management it is important to arrive at a
precise, operationalised and stable objective as soon as possible, which then forms
the benchmark for assessing the solutions. In the agile field, the objectives (fre-
quently these are more “visions” than objectives) are often fuzzy and subject to
change, i.e. they can be handled flexibly. The “magic triangle” in Fig. 2.7 shows the
differences: In the traditional field, the objectives are described in more detail than
the costs and deadlines from the beginning and are therefore relatively constant,
whereas in the agile field, deadlines and costs are set as quickly as possible and the
objectives and possible solutions are aligned accordingly (Sect. 2.3.4).
Traditional: Plan Driven Agil: Vision Driven

Scope (Vision, Objectives) Scope (Vision, Objectives)
operationalised, relatively fixed approximate, flexible
Time Costs Time (Deadlines) Costs

estimated, estimated, fixed fixed
planned planned
Fig. 2.7 Magic triangle in traditional and agile project management
Basically, it is the type of project that determines how far target structuring ought
to be advanced. For example, a target structure is less important in an organisational
project than in a technical and highly complicated investment project. In traditional
project management, the objectives can be operationalised using the following
structuring features:
• Global objective and detailed objectives

• System objectives and process objectives
• Elimination criteria and optimisation criteria
2.3.2.1 Setting Objectives Along the Project Phases

The goal-setting process along the phase progression (see Table 2.5) is also different
in the traditional and agile approach.
In traditional project management, where the objectives are relatively fixed and
form a formative orientation for the development of solutions, it is important to
formulate the objectives and the requirements as early as possible and to refine them
step by step. This enables a wide range of solution variants.
In the agile field, i.e. when new findings, adjusted priorities and surprises are to be
expected in projects, one proceeds iteratively, i.e. by learning. This means that there
is a constant flow of new insights into objectives and requirements. The goal-setting
process is therefore flexible throughout all phases. At the beginning there are more
inexact objectives (or “stories” or “visions”), which then only become concrete
requirements in the realisation phase.
In many projects, the goal formulation process takes place over several project
phases. This process is basically characterised by the fact that clear and specific
68 2 Methodology
Table 2.5 Objectives along the project phases

Initialisation phase Concept phase Realisation phase
Agile • Vision, • Product objective • Requirements according to the
project approximate global (product concept) iterations
management objective • Objectives and • On-going learning shapes the
requirements requirements (product backlog)
• Derive requirements
(product backlog)
from customer
“stories“
Traditional • Objectives • Review objectives • Refining or correcting
project derived from on an on-going basis requirements (specifications)
management analyses and adjust as and solution concepts
• Formulate global necessary (specifications) if necessary
goal and • Derive criteria for
requirements the evaluation of the
(specifications) solution variants
• Develop solution
concepts
(specifications)
requirements are developed from initially existing global objectives

(e.g. introduction of a titration system for the Analytica trade fair by the end of
April 2022). In the process, the objectives are refined step by step through an
iterative application of the problem-solving process. They are thus operationalised.
Even Non-objectives Are Helpful

Non-objectives can be very useful as they narrow down the project and better
describe what room there is for new solutions. Or vice versa: without formulating
non-objectives, new problems or difficulties may arise and might be allowed to arise.
Also, non-objectives can be an obstacle to ever new desires that inevitably arise in
the course of the project process, e.g.:
• The new regulation must not create additional bureaucracy

• The adaptation of the website is done without rewording the texts (this
non-objective can also be called a framework condition)
2.3.2.2 Global Objective and Detailed Objectives

The rough, global or overall objective is often part of the project order and ought to
be concise. It characterises the final state to be achieved in the project in a focussed
manner and serves as orientation for the project staff. The formulation of the global
objective contains a succinct statement regarding:
What is to be achieved? Quality, functionality, scope

When is this to be achieved? Time limit
With what is this to be achieved? Cost framework
Example: Practical Example BLS Project Sales Back-End
Global objective: Technological foundation for an expandable, future-oriented,

independent, and multi-client-capable BLS sales platform, mobile solution (app),
online ticket shop, and timetable solution for the bls.ch project by the timetable
change in December 2023, while not exceeding the defined budget. ◄
Example: Practical Example Metrohm OMNIS Titration System Project
Global objective defined at the beginning of the project: To further strengthen the
market leadership in the field of titration, a “best in class” titration system is to be
brought to the market.
A fully automated, modular, user-friendly titration system with leading mea-
surement precision is to be developed with the aim of being able to offer a
Minimal Viable Product (MVP) for potentiometric titration in 2023, which will
be expanded with further titration methods in the following years. The system
should consist of a robotic solution for sample handling, a processing module, a
measurement module, and a new software platform. Non-objectives of the MVP:
No devices from the current portfolio are to be integrated into the software in the
system. The planned cost framework is to be adhered to and will be reviewed on a
quarterly basis. ◄
Detailed objectives are formulated as requirements. In extensive and complex

projects, these can comprise up to several hundred pages and are in many industries
also referred to in their entirety as specifications, as the requirements specification or
as a requirements catalogue.
2.3.2.3 System Objectives and Process Objectives

System objectives are all demands and needs that are to be satisfied by the solution
at the end of the project. They are the assessment criteria for the project solution,
namely performance and quality objectives, the deadline goal, and economic
objectives. They also include all the project owner’s ideas about the short-term
and long-term effects and benefits that the project should achieve.
Process objectives include all requirements or conditions that have to be fulfilled
over the course of the project but that are no longer relevant at its end. Process
objectives can define milestones, specify certain tools for implementation and/or
impose conditions to avoid disruptions during the course of the project. They often
form the framework conditions for the execution of a project.
The practical example in Table 2.6 of BLS shows system objectives and process
objectives.
70 2 Methodology
Table 2.6 Practical example BLS: Process and system objectives

System objective Process objective
• Connection to the public transport • The project is being carried out in accordance with
platform via NOVA interface the Hermes 2021 process methodology and passes
• Multi-client capability regarding sales through the BLS-internal quality gates (systematic
back-end and digital sales channels review of interim results at defined milestones)
• Expandable architecture that allows the • On-going coordination with Postbus and
connection of all distribution channels Südostbahn regarding the NOVA connection
• Realisation of a mobile solution for ticket
sales
• Realisation of the online ticket shop for
bls.ch
• Integration of a timetable into the mobile
solution and the online ticket shop
2.3.2.4 Criteria for Appropriate Project Objectives

The following rules should be observed when formulating project objectives:
• Describe objectives as if they have already been achieved; this has a suggestive
effect. For example, “Half a year after the solution goes into operation, the entire
project costs have been amortised”.
• Formulate objectives in a solution-neutral way: What can be perceived when the
goal is achieved? If solutions are given or described, there is a danger that good
solutions will be excluded too early. Example: “When a customer calls, the
current information about him is available”. And not: “System XY provides
current customer data on the screen”.
• In addition to the objectives, the framework conditions should be recorded:
What has to be adhered to? What must not happen under any circumstances? E.g.,
which safety aspects must be respected?
• Formulate objectives as operationally as possible: Simple, understandable, clear,
unambiguously measurable or in such a way that the achievement of objectives
can be assessed. In particular, quantitative objectives should be stated in absolute
values and not merely as a percentage improvement (compared to an often
unstated reference value). For example, “The reject rate should be reduced from
1.0% today to a maximum of 0.5%” instead of “Halving the reject rate” or
“Reducing the reject rate by 50%”.
• Objectives should be realistic, even if the solution is not yet apparent at the
moment. Realistic means that the achievement of objectives allows being actively
influenced by those involved. Objectives can be put forth as demanding and
challenging, because this has a strong motivating effect, especially in an innova-
tive environment.
• Operational detailed objectives In the traditional approach, detailed operational
objectives should be formulated as early as possible after the project order and
formulated as precisely as possible, and modified or supplemented later in the
course of the project if necessary.
• Objectives can also be prioritised or weighted: which objectives are more
important than others?
In summary, the SMART formula is helpful:
" SMART objectives are:
Specific
Measurable
Attractive (also: achievable)
Realistic
Terminated
In many situations, the benefit of objectives is not measurable yet at the end of the
project, e.g. in organisational development projects that aim to achieve efficiency
gains or cultural improvements. In situations such as these, it is important to identify
appropriate measurable indicators for the actual achievement of the objectives.
Examples: Reduce error rate from 10 to 5%, reduce lead time from today’s 12 to
10 months, reduce the number of interfaces from 50 to 40, reduce staff turnover by
3 percentage points from 11.5 to 8.5%, halve the number of stock items to 1500
items, increase profit margin by 33% from the current 12 to 16%. These indicators
can then be reviewed 6 months or a year after project completion.
Finding and Agreeing on Objectives Together

Objectives must be discussed, questioned and, above all, accepted and agreed upon.
Therefore, the project manager or the product owner will never formulate the project
objectives alone, but will work out and agree them with the project owner, the project
team, if necessary with the project committee or with a support team. Objectives have
to be agreed upon by all project participants, all ought to feel responsible for them.
2.3.2.5 Mandatory and Optimisation Objectives

Often it is also useful to distinguish between objectives that have to be achieved and
objectives that should be achieved as far as possible:
Elimination criteria, or mandatory objectives (also called: must-have or essen-
tial objectives) are conditions that need to be achieved or adhered to in order for a
solution to be useful or viable, even if it costs more or takes longer. These include
above all: laws, safety regulations, standards, etc. Solutions that do not meet the
mandatory objectives are gotten rid of and rejected. Mandatory objectives have to be
free of contradictions.
Optimisation criteria or also wish objectives (sometimes also referred to as
nice-to-have or desired objectives) are objectives not having a decision-making
character. Since these can be more or less strong desires, and are also often
contradictory, such as cost objectives on the one hand and cost-generating perfor-
mance and quality objectives on the other, optimisation criteria need to always be
provided with an additional indication: the weighting. The weighting is easiest to
understand if it is expressed in %.
72 2 Methodology
2.3.3 Requirements, Requirements Engineering
Requirements are derived from the objectives. They concretise the objective and
answer the question “What is to be achieved?”. The requirements are formulated
much more concretely and in more detail than the objective. The requirements are
summarised in a specification. The further concretisation of the requirements into a
solution concept answers the question “How should the requirement be
implemented?”. This step is presented in the technical specification. Figure 2.8
shows the connection between objectives, requirements, and the solution concept.
In the traditional approach, the requirements should contain all the criteria
according to which a solution or solution variant will later be assessed and evaluated.
Checklists help to achieve completeness early in the project. If no requirement is
formulated for an aspect of the solution, the criteria for selecting the best solution are
missing.
Comprehensive requirements specifications and functional specifications are
primarily developed in the traditional approach. In the agile approach, the
requirements are developed iteratively in the realisation phase. Furthermore, a
sharp separation of the requirement specification and technical specification is not
always possible. The requirements are compiled in a product backlog (Sect. 2.4.3).
Requirements, according to IEEE 610.12-1990, are defined as follows:
Global Objective
Detailed
Target
Requirement regarding …
(Requirement specification: what shall be achieved?)
Functionality Quality Boundary Conditions
Solution Concept
(Functional specification: how shall the requirements be implemented?)
Fig. 2.8 Interplay between objectives, requirements, and solution concept

• A condition or capability required by a user (person or system) to solve a problem

or achieve a goal.
• A condition or capability that a system or subsystem fulfils or possesses has to
meet a contract, standard, specification or other formally specified document in
order to achieve an objective.
2.3.3.1 Requirement Engineering Activities

Requirements are developed and defined in Requirement Engineering, often
abbreviated as RE. The main activities of requirement engineering can be
summarised as follows:
• Investigate: Gaining, detailing, and refining requirements

• Document: Adequately describe requirements
• Check and consolidate: Check quality criteria
• Manage: Requirement Management
Another important task of requirement engineering is to clarify the context,

system boundaries, and scope of delivery. Requirements are elaborated through
the use of different elicitation techniques, such as questioning (interview, question-
naire), use of creativity techniques (brainstorming, change of perspective), or obser-
vation (field observation, doing the user’s work under his or her guidance),
(brainstorming, change of perspective) or observation.
2.3.3.2 Types of Requirements

Table 2.7 shows the different types of requirements.
The framework conditions (also called boundary conditions) are not requirements
that are implemented, but they limit the solution space. Laws (for example:
regulations for safety, health and environmental protection), norms and standards
(for example, relevant codes of conduct, professional regulations, principles and
objectives of sustainability) have to be identified and it is to be ensured that they are
complied with.
Table 2.7 Types of requirements

Functional requirements Non-functional requirements
• Functions and capability Quality requirements: Framework conditions
of the system • Details on functions (organisational and technical):
• Behavioural (safety, accuracy) • Development process
requirements • Reliability • Budget
• Structural requirements • Usability • Dates
• Business rules • Efficiency • Team
• Data • Modifiability • Laws
• States • Transferability • Standards
• Error handling • Operation
• Interfaces
74 2 Methodology
Table 2.8 Criteria for the Requirements Requirements document

quality of requirements and
• Tuned • Consistent
requirements documents
• Rated • Unique, Versioned
• Clearly • Clearly structured
• Valid and up to date • Modifiable
• Correct • Extendable
• Consistent • Complete
• Testable • Trackable
• Realisable
• Trackable
• Complete
• Understandable
2.3.3.3 Criteria for the Quality of Requirements and Requirements

Documents
Requirements and requirements documents can be checked for their quality using the
criteria in Table 2.8.
2.3.3.4 Prioritisation of Requirements

In many projects, users, customers, or marketing formulates more requirements and
wishes than can be implemented within a reasonable period of time or with the
available resources. To ensure that the important and central requirements are
implemented, they have to be prioritised. Requirements and wishes can also change
in the course of the project. The agile approach takes this circumstance into account.
In scrum, the requirements in the product backlog are continuously prioritised.
Prioritising the requirements helps the project team to focus on the important and
central requirements. Prioritising requirements is demanding, it is done by
representatives of users, customers, or marketing. In scrum, this responsibility falls
to the product owner. Frequently used criteria for prioritisation are: benefit, cost, and
risk. Various methods are available for carrying out prioritisation. It is advisable to
combine different methods.
Kano Model for Determining Benefit

Noriaki Kano, in his model, distinguishes between basic, performance, and enthusi-
asm requirements, see Fig. 2.9. The fulfilment of basic requirements (e.g. a heated
holiday flat in winter, a brake on a bicycle that works well even in rainy weather) is
essential, but does not lead to high customer satisfaction. Performance requirements
(e.g. the number of rooms, the equipment of the kitchen in the holiday flat, the
number of gears on the bicycle) lead to a linear increase in customer satisfaction. The
motto “the more, the better” applies to performance requirements. Enthusiasm
features (e.g. a beautiful view, a good location, intelligent gears) lead to high
customer satisfaction. The indifference zone is the area where expectations are
more or less fulfilled. The satisfaction values in this zone are moderate. Outside of
the indifference zone, the satisfaction values of the basic and enthusiasm
requirements rise or fall disproportionately. In the prioritisation, a clever
Fig. 2.9 Kano model for determining utility
combination of the requirement categories has to be found, whereby the basic

requirements are implemented. Over time, enthusiasm requirements shift to perfor-
mance requirements and performance requirements to basic requirements.
MoSCoW Prioritisation
The MoSCoW prioritisation (sometimes also known as MuSCoW) divides the
requirements into four groups: Must have, should have, could have, and won’t have:
• MUST: Implementation is mandatory for acceptance.

• SHOULD: Requirements ought to also be implemented, but unlike MUST
requirements, they can be changed through change requests or negotiations.
• COULD: These requirements are implemented when all must and should
requirements are met and sufficient resources and time are still available.
• WON’T: These requirements are not yet implemented in the current project and
are instead saved in an idea pool or the requirements list for the next project.
Business Value
As described in Sect. 2.4.6 effort estimation, the business values for the individual
requirements are determined using the T-shirt sizing method. The requirements with
the highest business values are given the highest priority for implementation.
76 2 Methodology
high avoid implement first

Risk
implement last implement second

low
low high
Value
Fig. 2.10 Value-risk matrix
Costs
Prioritisation based purely on estimated costs usually makes little sense. The com-
parison of business value and costs can provide valuable input for prioritisation. See
also Sect. 2.4.6.3 Cost estimation with T-shirt sizing method.
Value–Risk Matrix
In this method, the requirements are ordered according to value (benefit) and risk.
The order of implementation of the requirements results from Fig. 2.10. By
prioritising the implementation of requirements with high benefits and high risks,
the relevant pain points are addressed at the beginning of the project. This helps the
project team to deal with difficult challenges right away at the beginning instead of
delaying them or allocating them to a different position on the timeline.
Prioritisation Workshop
In a prioritisation workshop, the requirements to be implemented are prioritised
together with users, customers, or marketing. For this purpose, the requirements
having a price tag are presented to the participants. Each participant now receives ten
chips and can distribute these chips among the requirements to be prioritised. It is up
to the participant whether he selects ten different requirements or places his ten chips
on one requirement. Through this joint approach and involvement in the
prioritisation process, the result is better accepted by the stakeholders concerned.
2.3.3.5 Feasibility Check

At the end of the initialisation phase, it must be clear whether the project can be
carried out successfully. A feasibility study provides the basis for decision-making:
• Is the project technically and politically feasible as well as possible in time?

• Can the necessary resources (financial, human, knowledge, management support,
etc.) be provided?
• Do regulatory/legal requirements allow the implementation?
• Are the benefits of the project known to and recognised by all relevant
stakeholders?
• Other sources for clarifying the feasibility can be: stakeholder analysis, SWOT
analysis, risk analysis, best practices, industry experience, business case, etc.
2.3.4 The Magic Triangle
The “magic triangle” is used in project management to illustrate the interdependence

of the influencing factors “scope” (vision, objectives), “costs”, and “time”, see
Fig. 2.11.
• Scope: Desired outcomes from the project: scope, quality, functionality, comfort,
service levels, etc.
• Time: Desired time frame for the achievement of the agreed project objectives.
• Costs: The maximum of costs incl. labour and other resources that can be used
for this.
None of these factors can be changed without the change having an impact on the
other two factors. These are the three decisive components in the negotiation. They
must be formulated and agreed upon with the project owner in as much detail as
possible. The project manager must ask the project owner to weight these three
78 2 Methodology
Scope
1 At the beginning of the project

2 During the project
3 Towards the end of the project
1
3 2
Time Costs
Fig. 2.11 The magic triangle
dimensions. This determines his room for manoeuvre in dealing with these three
restraining factors. This may be the “magic part”: How does the project manager deal
with these conflicting demands? Beyond this balancing act, there is nothing magical
about the term “triple constraint”.
Sometimes a meaning is also assigned to the connecting lines in the magic
triangle: Between scope and cost is profitability, between scope and time is effec-
tiveness, and between cost and time is productivity. Different strategies lead to
different weighting, see Table 2.9.
As shown in Sect. 2.3.2 there are also differences in the magic triangle between
the agile and the traditional approach. In the agile approach, time, costs, and team
size are fixed. In contrast, the scope is fixed in the traditional approach.
Table 2.9 Different project strategies with influence on the project objectives
Best-in- The highest priority is to maximise quality and functionality. This “attraction” is
Market intended to draw in as many new customers as possible on the market.
Time-to- The highest priority is a minimum project duration in order to be able to appear
Market on the market as quickly as possible (e.g. product development). Costs and
quality are of secondary importance.
Design-to- The highest priority is given to the cost objective, i.e. how much the developed
Cost result may cost. The project manager breaks the cost objective down into smaller
units and monitors these partial cost objectives (also called “target costing”).
The meaning of the corners of the magic triangle also changes in the course of a
project. At first the focus is on finding and defining the scope, soon the focus changes
to costs and towards the end of the project the focus is on time.
2.3.5 Stakeholder Management
Stakeholders are persons, groups, or organisations that have relevant relationships

with the project. Such relationships can, for instance, be: specific interests, legiti-
macy or experience. Stakeholders external to the company are sometimes referred to
as the invisible project team, as they can significantly influence, support, or even
derail the project. Thus, different stakeholder groups often also make contradictory
demands on a project.
Influential stakeholders, for example, try to leave their mark on the objectives and
the project planning and request certain partial results earlier than planned. Or
investors have an interest in keeping project risks low. This influence can take
place on a formal or on an informal level.
Figuratively speaking, the project is integrated within a social network or field of
forces that not only needs to be considered, but should be harnessed to ensure the
project’s success. Stakeholders can be dealt with in different ways: communicative
relationships can be established, but they can also be included in the project
organisation. Where interests are very different, it is often advantageous to create
opportunities for stakeholder representatives to discuss mutual interests and
disagreements directly. This is more likely to guarantee that a broad-based and
therefore good solution might come about (Sect. 1.6.4).
A stakeholder analysis is advantageously developed with the project owner and
the project team at the beginning of the project. This also creates a common “project
reality” and a sense of the interconnectedness for the project. The stakeholder
analysis should be updated regularly for the whole duration of the project. Stake-
holder management comprises the three steps of identifying stakeholders, analysing
and evaluating them, as well as then managing them:
1. Identify stakeholders
(a) Who provides particularly important resources?
(b) Who can influence the project?
(c) Who is particularly affected by the project?
(d) Who can help or hinder the success of the project?
(e) Who needs the project results?
(f) Who must not be passed over?
2. Analyse and evaluate stakeholders

(a) Pictorial structure of the stakeholders: Group stakeholders around the project
(b) Name and visualise intensity and quality of influence and interest of individ-
ual stakeholders, e.g. proximity to the project by positioning close to the
project and quality of relationships with symbols for positive, neutral or
negative, as shown in Fig. 2.12.
80 2 Methodology
Expected reaction: Project

positive, promoting Owner
neutral, indifferent
negative, hindering
Authorities Project Customer

Manager
Project
Employees
Suppliers Competitors
Fig. 2.12 The project as a social system
Each stakeholder’s interest, influence, and power (Sect. 4.9) over the project
should be assessed. The influence can be on a formal or an informal level. The
question of how the stakeholder will react to the project is also of interest. This task
is most easily presented in tabular form, see Table 2.10. The following
considerations are helpful in addressing this question:
• What do the stakeholders think about the project? The problem should be
considered from the different perspectives of the stakeholders.
• What are the relationships between the stakeholders? How do they relate to each
other? What interests and objectives do the individual stakeholders pursue? Are
there any conflicts of objectives and interests (Sect. 5.6.6.1)?
• What reactions and behaviours of the stakeholders must the project manager or
product owner expect?
• A stakeholder map can be derived from the first analysis, see Fig. 2.13.
3. Steering stakeholders
Based on the stakeholder analysis and assessment, measures are formulated and
implemented. Possible approaches for dealing with stakeholders are:
(a) Involve stakeholders in the project, i.e. include them in a suitable project
committee and define the tasks and roles of the stakeholders in the project.
(b) Clarify interests and objectives, resolve objectives or conflicts of interest
with conflict management or mediation
Table 2.10 Practical example “New Town Hall”: Excerpt of a tabular representation of a stake-
holder analysis
Power, Expected
Interest, influence, reaction to
Stakeholder concern legitimacy the project Measures
Voting citizens Multifunctional 3 Public vote 3 Consent + Communicate
town hall probable effort/benefit
well
Administration No open-plan 3 Indirectly 2 Different ? Inclusion in
staff offices! via reactions office
motivation planning
Associations Infrastructure 2 Influence 1 neutral Ø Arouse
for activities! voting interest
Residents Impairment due 3 Legitimate 2 Objection – Early
to shadow cast to raise probable information
objections
Monument No impairment 1 Objection 3 Public – Integration
protection of the possibility debate, into the
townscape objection project team
Degree of relationship with the project: 3, high; 2, medium; 1, small
Type of relationship: +, positive; –, negative; ?, unknown; Ø, neutral
large
Monument Environmental
protection organisations Voting citizens
(-) (+) (+)
Residents
Influence
medium
(-)
Employees
(?)
Customers Clubs Providers

(+) (0) (+)
small
small medium large

Interests
Fig. 2.13 Practical example “New Town Hall”: Stakeholder map

82 2 Methodology
(c) Based on the information and communication concept Inform

stakeholders in a way that is appropriate for the target group and maintain
dialogue, i.e. consciously align the communication types and channels with
the stakeholders.
(d) Create additional communication vessels, e.g. workshop, large group inter-
vention, information event.
In order for the project manager or product owner to successfully manage the
stakeholders, they have to be given authority by the line to play their role. The
product owner or project manager needs to address the stakeholders at all three levels
of cooperation (relationship, content, and organisation: Sect. 1.5) and involve them
in the project.
The stakeholder map (Fig. 2.14) shows directly how those responsible for the
project should deal with whom. Basically:
• The power and influence of stakeholders can hardly be controlled. However, the
relationship of the stakeholders to the project can be controlled through relation-
ship management.
• Identify changes and developments in relation to stakeholders
• Communicate regularly with stakeholders
• Periodically check and adjust the measures taken
large
Respond to Pay greatest

demands, com- attention,
municate early, involve them,
involve project work close to-
owner gether
Influence
medium
Maintain minimal
contact, observe, Keep up to date,
small
show interest appreciate
small medium large

Interests
Fig. 2.14 Strategies for dealing with stakeholders

2.3.6 Project Marketing
Project marketing includes all supporting activities that can positively influence the
acceptance as well as the course and progress of a project. It is about selling the
project, where “selling” is understood to mean how to:
• Communicate the meaning of the project, create benefits, pass on one’s own
conviction.
• Create trust and acceptance
• Show fairness: also make possible disadvantages or problems transparent, take
fears and questions seriously and address them
• Create publicity, generate expectations that energise the project
• Tap into resources and sales markets
Project marketing promotes the relationship between the project and its environ-
ment or stakeholders. Project marketing means shaping communication and can be
approached very creatively depending on the situation and stakeholders, comprising,
e.g.:
• Wide-ranging information with opportunities to engage with the topic (e.g. open
space event)
• The project blog, in which those affected, users, etc. (i.e. not project actors) are
allowed to express themselves critically
• Info market: information boards and stands with documents; project participants
answer questions
• A creative workshop for interested parties; the results of which will be recorded
and further processed by the project team
• Visit and experience the project object
• The use of key people, promoters, decision-makers for information
• Speaking the language of the stakeholders and getting a notion about what they
are interested in
Project marketing is often not just about “selling” the project, but also about
conveying management messages and values at the same time, e.g. that a new culture
of cooperation is being introduced simultaneously with the project.
The basic attitude in marketing is important: showing off, deceiving, talking up,
pretending to be involved only works in the short term at best. In order to really
create trust, honesty—transparency and appreciation are required. Project marketing
already begins during the initialisation of the project. However, its importance
increases during the implementation phase, namely when the project gets introduced
and the number of people to be informed increases.
84 2 Methodology
Risk Process
Identification Quantification Coverage Control
• Identify all possible • Evaluate and weight • Develop measures • Regularly check and
risks (fields) identified risks and prepare actions: announce status
• Collect all risk relevant • Probability of occur- - Avoid (preventive) • Ensure that new risks
information rence - Mitigate (preventive, are identified
• Evaluate extent of reactive)
damage - Pass on (insurance,
contract)
- Accept (carry
consciously, plan)
Fig. 2.15 The risk process
2.3.7 Risk Management
Risk management in the context of a project should cover not only the product risks,
which are often well mapped in the company processes, but especially the actual
project risks. In many companies, project and product risks are well thought out in a
joint risk analysis. In the following concentration on project risks, the considerations
also apply mutatis mutandis to product risks. Figure 2.15 shows the sequence of the
risk process.
In the same way that risks are dealt with, opportunities can also be identified and
realised.
2.3.7.1 The Concrete Steps in the Risk Process

Since a variety of unforeseeable risks can arise in a project, an assessment method
for potential project risks must be established. Depending on the project phase, new
risks may arise for which appropriate measures must be developed. This risk process
must be run through regularly in the course of a project.
1. Identify Risks
Depending on the project phase, various tools are available for identifying potential
risks. In many cases, an analysis of the project environment, e.g. on the basis of a
stakeholder analysis, is sufficient to carry out an initial rough risk assessment. The
primary aim is to identify the most important risk categories, as Table 2.11 shows.
Table 2.11 Examples of risk categories

• Methodological risks (complexity, procedure)
• Technological risks (new products, material properties, etc.)
• Economic risks (cost ceiling, creditworthiness of business partners, etc.)
• Personnel risks (availability, bias, dilemma with different roles, illness, resignation, etc.)
• Political risks (change in corporate strategy, legislation)
• Competition and market risks (competitor product is better or lower cost)
• Legal risks (product liability, contracts, etc.)
• Environment risks
• Stakeholder-related risks (resistance from opponents)
large
hi
gh
-ri
sk
Probability of occurrence
medium
sk
Ri
pr
ob
lem
-fr
ee
small
small medium large

Severity of damage
Fig. 2.16 Extent of risks
2. Quantify Risks
To quantify the risks, both qualitative and quantitative methods are available. This
step is primarily concerned with describing the “level” of the risk. The risk can then
be described quantitatively from the two following parameters:
Risk = probability of occurrence × severity of damage
The probability of occurrence can be divided into probability classes as shown in

Fig. 2.16 or estimated as a percentage.
The severity (degree of harm) is often quantified in monetary terms or given as a
time delay. Instead of a supposedly precise calculation of the risk, in practice it is
86 2 Methodology
Risik Map
Overview all risks
R1: Introduction of public transport platform

Probability of Occurence (P)
70-100
R2: NOVA Pilot

R3: Scarce resources at BLS
R4: Project is overloaded
R5: Dependence on other projects
R6 R4 R1
(CEM, bls.ch, ESB, S16)
30-70
R3 R2 R6: Quality of cost estimates

R1
R14 R9: Experience with agile approach
R10: Compliance with pace by project team
R9 R12: Coordination difficulties between
R5 R13
0-30
R12 BLS, PAG, SOB and ZVV

R10 R13: Decision to connect TUs by ZPS
R14: Ongoing changes to NOVA interface
low Medium high
Severity (S)
Fig. 2.17 Practical example BLS: Risk matrix
often sufficient to assess the risk in terms of the probability of its occurrence and the
severity of the damage, as shown in Fig. 2.16.
In Fig. 2.17 the risk matrix is shown and in Fig. 2.18 a description of the main
risks of the practical example BLS is presented.
It is recommended that the assessment of the probability of occurrence and the
expected severity of damage get carried out in the project team. A jointly developed
view promotes understanding and increases the sensitivity towards the critical risks
by the project team. For this assessment, the cards from the Planning Poker (Sect.
2.4.6.2) can also be used.
A sensitivity analysis looks at the influence of one parameter at a time
(e.g. observation period, interest rate, annual returns, etc.). This means that it is
examined how sensitively the parameters react to small changes. This can help to
identify sensitive assumptions or critical parameters in order to be able to monitor
them intensively during implementation.
A method that follows the basic idea of sensitivity analysis and has become
established in many industries and companies is FMEA, the Failure Mode and
Effects Analysis, see Sect. 2.3.7.2. In some industries it is compulsory for every
system and every component that is newly created, also by all suppliers (automotive
engineering, medical technology). In other industries, this method has been adapted
to the different conditions, e.g. in the food industry (HACCP: Hazard Analysis and
Critical Control Points). Another way to assess the risks is simulation. With it,
several parameters can be run through in the form of different scenarios.
Risks
Description of the top project risks
Risk Description Impact Measures Trend
R4 Project is overloaded, great Change Requests Rapidly press ahead with
project complexity, parallel parallel clarifications of
The replacement of distribution
clarifications of principles principles
channels or the development of
new channels is done in the
project.
Burden in the project increases
with declarations of principle
R5 Dependence on other projects Requirements / requests from Voting meetings (Trident+)
(CEM, bls.ch, ESB, S16) linked projects
R6 Quality of the cost estimates Cost overruns Regular evaluation of the
assumptions underlying the
project
Identification and monitoring of
cost drivers
Strong involvement of
controlling
Measures show effect (improvement)

No deviation foreseeable
Deviations foreseeable (deterioration)
Fig. 2.18 Practical example BLS: Description of the top project risks
3. Cover Risks
To ensure that a project can still be carried out or that the risk is acceptable for the
company, targeted preventive measures should be developed that are able to reduce
the risk to an acceptable level. The basic measures according to Table 2.12 can be
helpful.
In a risk management tool all identified risks are listed and evaluated. Measures
are defined for each risk, and their influence on the risk is presented. In practice, the
risk management tool is often mapped out in a spread sheet programme; the
market also offers specific software solutions.
Table 2.12 Measures to reduce risks

Avoid How can a risk be avoided or eliminated in the first place?
→ Develop solutions that do not contain the risk
Decrease How can a risk be reduced or mitigated?
Does the measure affect the probability of occurrence, the severity of damage,
or both?
→ Explore potential for improvement, examine alternative scenarios
(e.g. having a second supplier)
Roll off How can a risk be passed on to others?
→ Contract adjustments (e.g. restricting warranty, agreeing on contractual
penalty), insurance, hedging of currency exchange rates
Carry How can a risk be borne?
consciously → Provide for in the project plan and budget, make provisions, document and
communicate (customer, decision-makers)
88 2 Methodology
Table 2.13 Example of a risk list

Risk P0 S0 R0 Measure P1 S1 R1 Costs Decision
Two weeks 7 6 42 Clear 1 6 6 1/4 h at Implement
milestone communication project
delay due to of project meeting
staff priorities
bottleneck according to
because of portfolio
work on
several
projects
Failure of the 3 4 12 Procure a 3 1 3 35k € Do not
existing test second test implement
facility for facility as a
testing the backup
prototypes
Legend:
P, probability of occurrence; S, severity on a scale of 1–10; R0, risk before implementation of the
measure; R1, risk after implementation of the measure
Table 2.13 shows an exemplary risk list with qualitative risk assessment before
and after implementation of the corresponding measures.
In addition to the measures for reducing risks shown in Table 2.4, conscious risk
strategies as shown in Fig. 2.19 can be selected for coping, too.
For risks that can be influenced by the project, measures can be developed or the
FMEA (Sect. 2.3.7.2) can be applied. Despite all the measures, risks remain that can
hardly be influenced by the project. The project manager can only prepare to these
and observe them carefully on an on-going basis.
4. Control Risks
The implementation of the defined measures has to be monitored continuously. In
addition, the risk process needs to be run through periodically. This ensures that new
risks are identified and the quantification of the identified risks is reviewed and
adjusted if necessary.
2.3.7.2 Failure Mode and Effects Analysis (FMEA)

An FMEA (Failure Mode and Effects Analysis) can be carried out at different stages
of a project, a distinction is made in particular between the following types
of FMEA:
• Design FMEA (also called concept FMEA)

• System FMEA (also called product FMEA)
• Process FMEA (also called production FMEA)
All potential errors that are conceivable in a wide variety of situations are listed.
Then, preventive, focused measures are taken. Their effectiveness is checked on an
on-going basis. Procedural steps of an FMEA include:
low
Prepare several scena- Process multiple
rios and act accordingly alternative solutions
Own responsiveness to events / changes if needed in parallel
sk
Ri
Develop preliminary
considerations and act Monitor closely
decidively if needed and react immediately
high
good poor
Predictability of events / changes
Fig. 2.19 Risk strategies
• Listing all conceivable errors, failures or problems.

• Indicating possible consequences of the failure or problem.
• Formulating possible causes and corrective actions
• O = Occurrence: Assessing the probability of occurrence [1 ... 10].
• S = Severity: Determining the severity effects of the error [1 ... 10].
• D = Detection: Finding out the probability of detection in the company [10 ... 1].
The probability of detection is linked to a point in time. It makes a big difference

whether I detect an error early or late. The values W, T, and E are expressed in a
precisely defined scale of values. In addition to the scale 1 ... 10 shown here, a scale
of 1 ... 6 is often used. The product of these three values is the risk priority number:
O × S × D = Risk priority number ðRPNÞ
The higher the risk priority number, the more sensible and necessary it is to
implement preventive measures. Especially if there is also a favourable cost–benefit
ratio.
Figure 2.20 shows an example of an FMEA analysis. The company defines an
upper limit for the risk priority number. The organisation’s understanding of quality
only allows risks below this limit. If the limit is exceeded, preventive measures are to
be initiated and their effectiveness has to be checked. The new risk priority number
90
Failure Mode and Effect Analysis (FMEA)

EWP100 OMNIS Titriersystem red fields have to be mitigated
Assessment after
Assessment prior to measures Measures
measures
Current Status Measures Improved State

ID Error Consequences Root Cause
O S D RPN M1 M2 M3 O S D RPN
R1 Dosing precision User has * Valves do not operate 8 10 6 480 Optimise valves through Optimise drive con- Determine waiting 2 10 3 60
does not meet inaccurate and correctly material selection trol, measure with times using existing
required fluctuating results * Drive control improvement, test all high-grade linear metering system,
measuring inaccurate variants path measuring sys- check metering
accuracy * Waiting times for tem, compare with accuracy with
changes in movement existing metering different waiting
not sufficient system times
R2 New valve Dosing accuracy * Clogging of valves 9 10 8 720 Find alternative solution 1 8 2 16
technology does is not achieved (Plan B)
not work
Fig. 2.20 Practical example Metrohm: FMEA analysis

R3 ASIC is not Test of system * ASIC technology has 8 8 10 640 Provide more resources, Enable test start by Clear prioritisation 3 8 2 48
functional in time cannot start as long design loops obtain external support integrating existing of functions,
planned * Not enough ASIC schedule those
Resources needed later in a
later design loop
R4 UL certification will Sales in the North * UL requirements will not 3 8 3 72 0
not be achieved American market be achieved
will be difficult
R5 Software is not Market * SW backlog is not met 6 10 10 600 Make more resources Prioritise backlog 2 10 2 40
available with introduction of the on time available, obtain with experienced
sufficient system cannot external support specialists
functionality take place as
desired
2 Methodology
after implementation of the measures is then determined. It needs to also be below

the limit value.
2.3.8 Project Organisation, Roles, Committees
The project organisation is a temporary organisation for the duration of the

project. Its necessity arises from the fact that the existing line organisation is
optimised for the fulfilment of its technical tasks, but not for the management and
processing of new, unique, and interdisciplinary projects. It also lacks the necessary
flexibility to react quickly to problems and changes. Table 2.14 shows the important
prerequisites for a well-functioning project organisation.
It is important to regulate in the formal project organisation who is to take on
which roles, tasks, responsibilities, and competences. If this is set up properly and
well coordinated, it is an important cornerstone for the success of the project. In
addition to the formal organisation, in the course of the project, some people or
groups of people outside of the formal project organisation will repeatedly try to
influence the project and thereby seek to exercise informal power (Sect. 4.9). For
those responsible for the project, it is essential to recognise this informal influence
and to use it to the advantage of the project. Often relevant decisions are made in
informal ways and later on approved of in the formal project organisation.
2.3.8.1 Line and Project: Two Different Worlds

If special problems are dealt with by project teams in a company, this means that, in
addition to the line organisation, a further work formation is permitted which differs
from the regular line organisation:
• In the delegation of authority

• In the nature of the cooperation
• In the conflict culture
• In communication
• In dealing with taboos
Table 2.14 Important prerequisites for a well-functioning project organisation

Important prerequisites for • Clear project agreement: challenging objectives and framework
a well-functioning project conditions or guard rails that define the scope of action
organisation • Clear and sufficient decision-making authority and
corresponding leadership responsibility of the project management,
respectively, the product owner and scrum master
• Adequate interdisciplinary subject representation and expertise
in the project team
• Active users and stakeholders in order to achieve the highest
possible level of acceptance
• Work culture that promotes communication, commitment, and
creativity
• Good anchoring in the line organisation, if possible
“connected” to the relevant decision-makers
• Availability of resources
92 2 Methodology
Line organisation Project organisation
Line culture Project culture

hierarchical, given reporting team-oriented,
channel and decision-making simultaneous cooperation,
structures networked communication
Fig. 2.21 Two worlds: Line organisation and project
This differentiation should be made quite deliberately. Depending on the project,

it can be classifiable or not. Example: The introduction of new production structures
that require a new way of working together can be supported considerably by living
the future culture in the context of the project. In standard projects, however, project
culture and subordinate relationships remain closer to the line hierarchy, and the
differences between the two worlds are minimal. Figure 2.21 shows the difference
between the line organisation and the project organisation.
2.3.8.2 Roles and Bodies

In project organisations, people are often appointed without there being a clear idea
beforehand of what their role ought to be. As a result, roles are not clearly defined
and delimited, or even missing. Example: The project owner, who also likes to work
in the team, makes decisions “from above” (as is expected of him) due to his given
position of power and “from below” in the team as a team player. The project
manager is faced with having to fulfil conflicting roles because of this dual function.
Such cases should be clarified at the beginning of the project.
Multiple roles are dangerous. In small projects, a complete assigning of divided
roles is of course not possible down to the last detail. But then, if achievable,
“neighbouring roles” should be played by the same person, e.g. the project manager
ought to also work on the content of the project.
Several roles together form a body (e.g. project committee). The committees and
roles, often also referred to as project organs, are formed and named according to the
project and corporate culture (and industry culture) in such a way that all levels of
competence are represented and the project objective can be achieved as effectively
as possible. Often it is not really known who decides. The role of the project manager
is seen as a necessary evil and is therefore only marginally perceived.
The project has to be clearly anchored in and at the decision-making level. The
decision-making process has to be made transparent. Further explanations related to
the topic of position and role are given in Sect. 5.3.1.
2.3.8.3 Competences and Management Tasks in the Project

Organisation
The competences of the various roles and committees differ in part in the agile and
traditional approaches. Table 2.15 shows the institutional roles and committees with
their respective focal points at the competence level.
In order for a project team to work effectively, the project manager, the product
owner, or the scrum master must perform a variety of management tasks and
Table 2.15 Roles and committees with their respective focal points at the competence level
Role, board Agile Traditional
Project owner: • Decision-making authority regarding • Decision-making authority
what? project thrust regarding the direction of the
• Social competence project
• Negotiation skills • Social competence
• Subject matter expertise • Negotiation skills
• Subject matter expertise
Project • Preliminary ruling • Preliminary ruling
committee: • Connection project-line • Connection project-line
what?
Project • Self-competence
manager: • Social competence
what & how? • Negotiation skills
• Team and leadership
competence
• Methodological competence
• Decision-making authority
within the framework of the
project
Product • Self-competence
owner: what • Social competence
& how? • Negotiation skills
• Subject matter expertise Decision-making
authority within the framework of the
project
Scrum master: • Self-competence
how? • Social competence
• Team and leadership competence
• Methodological competence
Project team: • Team and leadership competence • Subject matter expertise
how? regarding self-organisation
• Subject matter expertise
• Decision-making authority on what to
include in the next sprint
94 2 Methodology
Table 2.16 Different tasks

Team development • Take care of the relationship structure, the group climate, i.e. ensure
that there is an atmosphere in which the members become or remain
able to work
• Create meeting opportunities that bring members closer together
• Helping to manage tensions and conflicts, i.e. providing support for
dealing with underlying issues
• Ensure that no member’s dignity is violated or treated disrespectfully
Conflict management • On-going monitoring of possible signs of crises and conflicts
and crises • Clearly address suspected or obvious conflicts and crises as such
• Dealing with and managing conflicts and crises in the team
Chair and moderate • Structure and lead meetings
meetings • Involve all members and involve them in the solution process
• Preventing “treading water”, provoking decisions and pushing the
group forward
• Ensure the right mix of methods (e.g. individual-, small group- and
plenary work; brainstorming, etc.). Use appropriate visualisations (pin
board, flip chart, beamer, etc.)
• Continuously visualise and document the work process
• Initiate and lead evaluation rounds: “Who does what by when?” and
“How did we work?”
services. These are described in detail in Chap. 5. In Table 2.16 individual aspects
are listed by way of example.
2.3.8.4 Project Organisation in the Agile Approach

A scrum team (see Fig. 2.22) in the agile approach according to scrum consists of the
following members:
• Product owner
• Developer (the team)
• Scrum master
Agile teams are self-organised and interdisciplinary (Sect. 4.5). The members
have all the skills required to generate value in each sprint. Each role in the agile
project organisation has specific result responsibilities, which are described in
Table 2.17.
Weighted Competence Profiles Product Owner and Scrum Master

The competence profiles shown in Fig. 2.23 for a product owner and a scrum master
are based on the competency model in Sect. 3.1
Non-hierarchical, Network-Like Project Organisation

Similar to scrum, non-hierarchical, self-organised project organisations are very
effective especially for highly complex and dynamic projects. Practice has shown
that these “work” very well in projects with a lot of creative freedom and carefully
worked out framework conditions and rules. For extensive projects, it is possible to
Product Owner Scrum Master
Scrum Team
Developers
Fig. 2.22 Scrum team
Table 2.17 Responsibilities for results of the individual roles and committees in the agile project
organisation
Role, board Task
Project owner The project owner has less influence on the project in the agile approach
than in the traditional approach. Nevertheless, the project owner has to
fulfil the following tasks:
• Setting the strategic framework
• Support the product owner, give him back-up
• Affirm resources
• Open doors, for example for important informants
• Show your motivation (for example at the kick-off)
Project committee, The use of a project committee in the agile approach is optional. It is best
Steering committee to invite the important stakeholders to the sprint reviews. This allows them
to provide valuable input to the project
Scrum team The scrum team as a whole is responsible for the implementation.
Activities such as stakeholder involvement, verification, maintenance,
operation, experimentation, research, development, and everything else
that is needed are detected and carried out together. The scrum team
produces a valuable and useful increment in each sprint
Product owner The product owner controls the scrum team at the content level by
determining what is to be implemented. He manages the product backlog
and is responsible for maximising value. In summary, the responsibilities
of the product owner are:
(continued)
96 2 Methodology

Role, board Task
• Development of the product goal and its explicit communication
• Capturing customer needs and describing the requirements in the product
backlog
• Management and prioritisation of the product backlog
• Ensuring that the product backlog is transparent, visible, and understood
• Creating and updating the release plan and deciding alone on the delivery
date of realised functionalities
The product owner can be supported by the developers in the completion
of his or her tasks. For the product owner and the project to be successful,
the whole organisation needs to respect and accept his decisions. The
product owner has to be given the necessary power by the organisation
(Sect. 4.9). The role of the product owner is a full-time job and cannot be
done on the side. If the product owner is not available, questions remain
unanswered and ambiguities cannot be resolved. This leads to
inefficiencies in the scrum team
Scrum master The scrum master helps the scrum team to use scrum correctly. He is the
method specialist. The less the scrum master is needed, the better he has
done his job. The responsibilities of the scrum master can be summarised
as follows:
• Establish scrum, teach the necessary techniques, and help to establish the
processes
• Coach the scrum team in self-management and interdisciplinary
collaboration
• Support the scrum team in focusing on creating high quality increments
• Remove obstacles
• Ensure that all scrum events take place, are positive and productive, and
stay within the timebox
The scrum master is a good listener. With his personality, he is also able to
support the scrum team in difficult situations. The scrum master applies the
instruments of moderation and coaching. Depending on the project, the
scrum master’s job is all in from the start. In the course of the project,
however, his workload will decrease and it is quite possible that a scrum
master will then supervise two or three projects
Developer The developers carry out the work and ensure the realisation of the
requirements. The developers are made up of specialists who deliver a
finished increment at the end of a sprint. They are necessary for the
completion of the task. All of them must have the relevant knowledge and
skills and be able to work together efficiently. If this is not guaranteed, the
developers are usually not very productive. In summary, the
responsibilities of the developers include:
• The creation of a plan for the sprint and the sprint backlog
• Ensuring quality through compliance with the Definition of Done
• Daily adjustment of the plan, to achieve the sprint objective
• Holding each other accountable as experts
Developers who work well together have the following characteristics:
• They organise themselves and are autonomous
• They decide how many requirements will be implemented within the
next sprint
• There are no further subdivisions among the developers
• The developers are usually in the scrum team at 50–100% of their
(continued)

Role, board Task
capacity and work together in close proximity where possible
The ideal team size is between three and nine members. If more than nine
members are needed to realise a project, parallel teams are ideally formed.
The Large Scale Scrum (LeSS) approach can be followed. The realisation
of projects with several teams working in parallel is very demanding and
requires a lot of experience from all participants. In a setting with several
teams, there is only one product owner
Product Owner Scrum Master
Expertise Expertise
4 4
3 3
Metho- Self- Metho- Self-
dological 2 competence dological 2 competence
skills 1 skills 1
0 0
Team and Social skills Team and Social skills

leadership leadership
skills skills
Negotiation Negotiation
skills skills
Key:
0 not relevant
1 not necessary
2 helpful
3 important
4 requirement
Fig. 2.23 Weighted competence profiles in agile project management
have several parallel teams that are networked with each other. Direct networking
ensures better coordination than a central coordinator. These teams are self-
organised, and relations with the project owner and any project committee are
non-hierarchical.
Management must explicitly commit to self-organisation (Sect. 4.5), because it
delegates part of its decision-making power and must support the project accord-
ingly. As the project owner, it defines the project order, i.e. the content framework
and the rules of the game. The project owner is thus more of a customer and agrees
on the assignment with the team. The “project lead” can have two forms:
• In hybrid projects, the “agile project manager” is responsible for the overall
planning (Kolb, 2014).
98 2 Methodology
Project Team 1
Project Owner
Support Team
Product Owner
Organiser/
Team Coach Project Team 2
Scrum Master
Project Team 3
Fig. 2.24 Possibility of a project organisation as a network
• In agile project parts, the “team coach” or scrum master is responsible for
supporting the team.
Depending on the project, both roles can be combined in one person. Basically,
however, it should be noted that project managers do not have a leading but an
organising and supporting function in the context of self-organised teams: They
organise the nomination of team members, plan and moderate meetings such as the
kick-off or the coordination and presentation meetings, present a shield from outside
influences or offer coaching.
If there is a project committee, it also has a supporting function vis-à-vis the
team(s), in addition to the preliminary work (developing the vision and guidelines,
carrying out higher-level strategic work, etc.). In such situations, the project com-
mittee is therefore also called a support team, as shown in Fig. 2.24.
Alternatively, frameworks such as SAFe (Scaled Agile Framework) or LeSS
(Large Scaled Scrum) can be used as orientation and alignment for parallel agile
teams.
2.3.8.5 Project Organisation in the Traditional Approach

Each role in the traditional project organisation has specific tasks to perform, which
are described in Table 2.18.
Table 2.18 Tasks of the individual roles and committees in the traditional project organisation
Role, board Task
Project owner Synonymously used terms are project sponsor, client, or principal. In
most cases, the project owner is also the decision-maker. However,
situations are conceivable in which the decision-making function is
divided, e.g. between management and the board or between the
executive and the legislature. Essentially, the role of the project
owner includes the following tasks:
• Setting the strategic framework
• Prioritising which projects are important or urgent
• Agreeing upon a mandatory project order
• Taking milestone decisions
• Supporting project management, giving back-up
• Assuring the availability of resources, the project management
does not have the power to simply take resources as needed. Here the
project owner must provide support
• Opening doors, for example for important informants
• Informing: It can often be important for the commissioning body to
inform the outside world (representation).
• Showing your own motivation (for example at the kick-off)
Project committee The project committee is also called the steering group, steering
Steering committee committee (SC, SteCo), or review board and is the technical
extension of the project owner. It assumes the role of general
control and preliminary decision-making, especially in large
projects. The project committee usually includes exponents from
senior management or important stakeholder groups. If the steering
group is composed only of members of upper management, this
group can often delegate the substantive steering of the project to a
technical committee or a technical review board
Sounding board The sounding board supports the project by giving its opinion on
important results. It can be useful for projects in which different
stakeholder groups are represented. The objectives are to discuss the
project and ensure its broad acceptance. Sounding boards are most
likely to be found in research projects, acceptance projects, or
change projects
Project manager (PM) The project manager is responsible for the operational
management of the project, i.e. he is the process designer. He or
she is responsible for the process. As a rule, only one person is
responsible for the overall management. However, a management
team is also conceivable—in which case, however, the
complementary roles need to be very well clarified. In large
customer or construction projects, one project manager is nominated
in each of the two companies (contractor and client)
Leadership and organisation:
• Negotiate project agreement with project owner and put it in
writing
• Select and adhere to a problem-solving and procedural system
• Conduct stakeholder management and ensure the inclusion of the
entitled stakeholder groups (Sect. 2.3.5)
• Form project team and project organisation, procure necessary
resources together with the project owner.
• Role clarification (tasks and division of roles) (Sect. 5.3.1)
(continued)
100 2 Methodology

Role, board Task
• Start the project, kick-off (Sect. 2.3.13)
• Coordinate different sub-projects and activities (Chap. 5)
• Lead the team, coordinating participants (Chap. 5)
• Facilitate meetings and workshops
• Conduct conflict and crisis management (Sect. 5.6)
• Establish risk management (Sect. 2.3.7)
Planning
• Plan, monitor, and control deadlines, people, costs, and quality
• Project efficiency assess
• Prepare milestone decisions
• Show consequences of objective changes
Information and communication:
• Inform and communicate actively and situationally
• Ensure documentation: Protocols, project plans, descriptions,
programmes, etc.
Controlling:
• Set up a control system that monitors the achievement of the goal,
progress (content, deadlines), effort (time and costs) and reports
deviations
• Identify deviations from objectives and initiate measures
Sub-project manager In large projects, autonomous sub-projects can be formed. The
(SPM), sub-project teams management of these sub-projects is the task of the sub-project
manager (SPM). The tasks of the SPM are similar to those of the
project manager (PM). In any case, there needs to be a clear
agreement on the scope of tasks between the PM and the SPM
Project team The project team has the role of handling the content of the
project. In larger projects, it can make sense to structure the team
into a core team and an extended team. This structure makes
meetings and workshops more efficient. Not all members have to be
present everywhere
Temporary groups Working groups can be set up to work on specific aspects, which are
even more temporary than the whole project
The ideal-typical project organisation is shown in Fig. 2.25.

The project manager should have self-competence, social competence, negotia-
tion competence, team and leadership competences, and methodological compe-
tence. Of course, he cannot be a specialist in all of these areas. But depending on the
project and the task at hand, he or she should have the competences that are
favourable for project management in each field.
Weighted Competence Profiles Project Manager and Project Owner

Based on the competence model in Sect. 3.1 a possible competence requirement
profile for project managers and project owners is shown in Fig. 2.26.
Self-competence: The project manager’s view of himself and the world influences
the way he interacts with his team. His general awareness (Sect. 3.3.4), his
Project Owner
Project Committee
Steering Committee
Project Team Project Manager
Core Team
Subproject-Team Subproject-Team
Subproject-Team
Fig. 2.25 Ideal typical project organisation
Auftraggeber Projektleiter
Expertise Expertise
4 4
3 3
Metho- Self- Metho- Self-
dological 2 competence dological 2 competence
skills 1 skills 1
0 0
Team and Social skills Team and Social skills

leadership leadership
skills skills
Negotiation Negotiation
skills skills
Key:
0 not relevant
1 not necessary
2 helpful
3 important
4 requirement
Fig. 2.26 Weighted competence profiles in traditional project management

102 2 Methodology
motivation (Sect. 3.7), and his handling of stress (Sect. 3.5) will also influence the
behaviour of his team.
Social competence: Personal communication (Sect. 3.9), interdisciplinary coopera-
tion, and dealing with conflicts (Sect. 5.6) require a high level of social compe-
tence from the project manager.
Negotiation skills: In many situations the project manager has to negotiate (Sect.
4.10) and find a balanced agreement between parties.
Team and leadership competence: Project managers are designers of social pro-
cesses and above all need to be able to lead teams (Chap. 5). Leading is a very
demanding task and is strongly based on the project manager’s view of human
nature (Chap. 3). It requires a high degree of social competence and empathy. Of
course, this competence is also largely dependent on the type of project and is
complementary to technical knowledge: The less the amount of technical knowl-
edge that is in the foreground, the more is leadership competence required and
vice versa. Since the project manager does not administratively lead the people
working on the project, he has to be able to assert himself without formal power.
Methodological competence: This refers to structuring and planning methods,
problem-solving methods, moderation techniques, procedural methods, etc.
In smaller projects, as well as in standard or repeat projects, it is an advantage if

the project manager also has specialist expertise.
2.3.8.6 Project Organisation in the Hybrid Approach

In the introduction (Sects. 1.4.3 and 2.1) we describe possible organisational forms
for hybrid project management. The best combination of agile and traditional
elements must be determined individually for each project. Figure 2.27 shows the
hybrid project organisation using BLS as a practical example.
2.3.8.7 Project Organisation in Customer Projects

The project organisation in customer projects has to be assessed and determined
according to the situation. Various constellations are conceivable:
• The customer project is a sub-project in a larger project.

• The project is implemented jointly. Key roles such as project management are
filled twice. This is the case in many construction projects, for example, with an
owner’s representative and a construction manager.
• The project is implemented independently. The customer is involved in defined
sub-steps for acceptance and reviews.
It is important to clarify the roles together. Who does what? How are the tasks
differentiated from each other? Who is responsible for which topic? It is also
advisable to establish a common set of rules.
Principal /
Project Board
Quality Gates
Overall project manager
Technical Committee
Enterprise architecture Finance/ Controlling
Technical lead, Processes, Supplier mgmt., Testing, IT operation,

Requirements, Product Owner Architecture, Development Procurement
IT Project Manager, Scrum Master
Product Owner & Change Log IT-operations / Infrastructure Solution Architecture
Processes, Requirements, Developer & Realisation

Req. Engneering IT Security partner
Communication & Marketing Testmanagement Tenders
Operational preparation / Operational preparation IT

set-up Customer support Purchasing, Legal
1
agile traditional agile and traditional mixed
Fig. 2.27 Practical example BLS: Hybrid project organisation
2.3.8.8 Linking the Project Organisation to the Line Organisation

The question with every temporary organisation is how it is linked to the
organisation as a whole. Project organisations are set up in three different forms:
• Project coordination
• Pure project organisation
• Matrix organisation
The various organisational forms differ in the way the entirety of leadership and
decision-making authority is shared between the line and the project, or in how great
the degree of freedom for the project manager and his team is. An agile project can
only be implemented in the pure project organisation or in a matrix organisation. For
details, see Fig. 2.28.
The Project Coordination

The Project Coordination (or Influence Organisation) is the minimal form of a
project organisation in which the primary organisation is merely supplemented by
the staff position of the project coordinator. For organisational chart, see Fig. 2.29.
The functional hierarchy remains unchanged. The coordinator (project manager on
staff) has no authority to issue directives. However, he or she is responsible for the
104 2 Methodology
small
Authority of line management
Authority of project management

small large
Project coordination Pure project organization

The decision-making authorities The decision-making authorities
are with the line instances are with the project instances
Matrix project organization

Decision-making is negotiated bet-
ween line and project organization
Fig. 2.28 Forms of project organisation and allocation of competences
Management
Department A Department B Department C Project Manager
Employee A1 Employee B1 Employee C1
Authority
Organization Project
Fig. 2.29 Project coordination

Table 2.19 Advantages and disadvantages of project coordination

Advantages Disadvantages
Project • High degree of flexibility with regard to • No one feels responsible for
coordination staff deployment the project
• Simple exchange of experience • Low reaction speed
• Large collection of experience across the • Cross-organisational
different projects perspective is more difficult
• No organisational change • No real project team
• Responsibility of the project remains
largely with the line
factual and temporal course of the project, for the timely information of the relevant
line instances and for the correct procedure.
In his coordination function, he proposes measures and next work steps to the
line. This type of project management requires that the line management cooperates
constructively and makes the necessary information available to the project manager.
In this form of organisation, the project manager is not to be held solely responsible
for the achievement of objectives, since he lacks leadership responsibility in the
project and is particularly dependent on the willingness of the line management. The
advantages and disadvantages of project coordination are shown in Table 2.19.
This form of project coordination is particularly suitable for projects that do not
significantly exceed the scope of conventional tasks. Examples: Customer orders,
simple product developments
The Pure Project Organisation

At this organisational form, an independent new organisational unit is formed for the
project. For organisational chart, see Fig. 2.30. The project manager and the team
members are full-time members of the project. Thus, the project manager also bears
full management responsibility with all decision-making powers (except with regard
to milestone decisions). An independent, efficient team/task force is created. This
project organisation can be quite expensive, because the previous positions have to
be filled. And if the employees are not fully utilised in the project, there will be idle
time.
The advantages and disadvantages of pure project organisation are shown in
Table 2.20.
The pure project organisation is clearly demarcated from the line and has a high
degree of autonomy. As a task force, it handles very important and urgent projects in
a short time. It is suitable:
• For projects that have relatively little contact with traditional tasks
(e.g. developing a completely new product line, constructing a new building)
• For projects carrying a very high risk (spin-off of the project from the company)
• For time-critical projects
• Where a specifically resounding impact of the results is needed
106 2 Methodology
Management
Employee B1 Employee C1
Project Team
Member 1
Employee A2 Employee B2
Project Team
Member 2
Employee A3 Employee C3
Project Team
Member 3
Authority
Organisation Project
Fig. 2.30 Pure project organisation
Table 2.20 Advantages and disadvantages of pure project organisation

Pure project • Efficient organisation for large • Little staff flexibility, especially for
organisation projects specialists who are only needed
• Clear responsibility and temporarily
decision-making authority with • Recruitment and reintegration of project
the project manager staff after the end of the project can be
• Fast reaction time in the event of difficult
mistakes • Danger of authoritarian or non-team-
• High degree of identification of oriented leadership by the project manager
the project team with the project more probable, as he/she leads in a special
• Independent of the influence and temporary situation
any arbitrariness of the line
The Matrix Project Organisation

This organisational form represents a mixture of pure project organisation and
project coordination. For organisational chart, see Fig. 2.31. The responsibilities
and competences are divided between the project manager and the line instances.
This division depends on the project and can vary within wide limits. The matrix
project organisation places very high demands on the clear division and adherence to
the agreements between the line and the project as well as on the role awareness of all
Management
Employee A1
40% Employee B1 Employee C1
Project Team
Employee A1
60%
80% Project Team
Employee C2
Employee B3 20%
Employee A3 60% Employee C3
Project Team
Employee B3
40%
Authority
Organisation Project
Fig. 2.31 Matrix project organisation
participants. Therefore, it is very conflict-prone and requires a high degree of

communication, especially for regulations and agreements.
The advantages and disadvantages of the matrix project organisation are shown in
Table 2.21.
The matrix project organisation is by far the most common organisational form in
the practice of traditional project management. Many companies, with regard to
limited resources, have almost no other choice. Because of the dependencies and
Table 2.21 Advantages and disadvantages of the matrix project organisation

Matrix project • Project manager and team feel • Danger of conflicts of
organisation responsible for the project competence between lines and
• Clear responsibility and decision- project authority
making authority with the project manager • Insecurity of managers due to
• Flexible staff deployment, no workload waiver of exclusivity
problems • Insecurity of employees as
• Continuity of professional development, “servants of two masters”
no loss of contact with the line • High demands on information
• Targeted coordination of different and communication readiness
interests
• Promoting a holistic, interdisciplinary
approach
108 2 Methodology
contradictions that arise from the hierarchically oriented line organisation, on the one
hand, and from the team culture of the project organisation, on the other, this is
probably the most delicate and demanding form in terms of organisational psychol-
ogy. It only works sensibly when:
• The tasks and competences are clearly regulated, analogous to a right-of-way

regulation at intersections,
• The line uses capacity planning to optimally coordinate the employee’s use of
resources in line work and in project work,
• Problems and conflicts are addressed and discussed at the right hierarchical level,
i.e. if the conflict culture is sufficiently developed; if this is not the case, the
conflicts are delegated to the system,
• The business units want to work together and do not compete over the project.
2.3.8.9 The Competence Regulation
RACI Matrix
Many conflicts and misunderstandings arise from unclear or differently understood
responsibilities. The RACI Matrix is a method for recording responsibilities
completely and without overlaps and visualising them in the form of a table. All
work packages or tasks are listed in the rows; the different project roles are listed in
the columns. The RACI matrix answers the following three questions for a project:
• Which work packages need to be completed?

• Which project roles are involved?
• Who is responsible for what?
In the fields, the four responsibilities R, A, C, I are entered according to

Table 2.22.
Table 2.23 shows an example of a RACI matrix.
Several variants of RACI exist, such as RASCI, which describes the additional
responsibility of “support”, or RACIQ, which includes the responsibility of “quality
Table 2.22 RACI responsibilities

RACI code RACI accountability
R Responsible Responsible in the sense of being responsible for implementation. The
person carries out the work package him/herself or delegates it
A Accountable Accountable, authorised to make decisions, superordinately responsible
in the sense of “approve”, “endorse”, or “sign off”. The person bears the
legal or commercial responsibility
C Consulted To be consulted. The person who may not be directly involved in the
implementation but has relevant information for the implementation and
therefore should or has to be consulted
I Informed To be informed. The person who receives information about the course or
outcome of the activity or who is authorised to receive information
Table 2.23 Example of a RACI matrix

Sub-
Project Project Project project Sub-project Sub-project
Work package owner committee manager R+D production marketing
Draw up the A I R C C C
project order
Create proof of A I R C I
concept
Develop A R C
prototype
Produce A R I I
prototype
Create a A I C R
marketing
concept
Build a support A I C R
organisation
review”. The RACI matrix can now be reviewed and analysed in a horizontal and
vertical manner as follows:
• There should be one R in each line. If there are several R’s in one line, check
whether the work package can be further subdivided. In this case, at least those
responsible should consult each other.
• There should be exactly one A in each line. The higher-level responsibility cannot
be shared.
• If the number of Cs or Is is high, it should be examined whether this is still
expedient or how high the expected benefit of this consultative or informative
involvement is.
• If a project role is assigned a high number of R’s, check whether the person can
complete all work packages on time.
• If a high number of A’s is assigned to a project role, check whether accountability
can be delegated to other bodies.
• If a project role has hardly any empty fields, it should be questioned whether this
person needs to be involved in all work packages.
• A general overview enables a plausibility check as to whether, in principle, the
work packages are allocated in a sensible and balanced way to the skills and
strengths of the corresponding persons.
The RACI matrix is very suitable for resolving conflict situations, the causes of
which lie in unclear or unclarified role definitions. In larger project environments,
individual work packages can be assigned to different roles, true to the motto “All
roads lead to Rome”. It is of little relevance to which role a work package is
assigned. It is of utmost importance, however, that all participants are aware of
which role bears the corresponding responsibility and that each role is lived and
110 2 Methodology
respected. A similar representation of the competence regulation is the function

diagram.
Leadership Continuum with Changing Responsibility

Traditional companies usually organise their work processes through a clearly
regulated separation between different organisational units. The handling of projects
often runs through several organisational units. This is complicated by the fact that
not all units see their work as a project. For example, an account manager hardly
considers his acquisition activity as the commissioning and initialisation phase of a
project, although a project manager takes over the assignment at a later stage. Thus,
the agreement on delivery date or product costs often takes place before the
requirements can be checked for feasibility within the deadline and budget. This
puts the success of the project at high risk, and broad recriminations are very likely.
From a project perspective, this is a project with changing project managership
and often also changing project teams. To ensure a continuum of leadership, the
following steps have proven themselves in practice:
• In addition to a clean handover between the two project managers, e.g. called
“account manager” and “project manager”, the intended future project manager
should already be called in at the beginning of the account manager’s activities
for selective customer talks or internal meetings. In this way, he can already get an
idea of what he will be facing. He can also bring in experience from previous
projects. For example, he can ensure that tolerances that go to the limits of his
own production process are defined with the customer before the project begins.
• The account manager should also participate in the final review and the lessons
learned of the project. Here he receives important information for future orders,
which details increase or erode the margin.
This repeated dovetailing of the project management managers involved

increases the probability that the overall project can be completed successfully.
Such an approach is helpful in the face of increasing project complexity.
2.3.8.10 Formation of the Project Organisation

In general, project organisations are put together too uncritically and too carelessly.
Frequent reasons for this are
• A one-sided view (e.g. seeing things only from the perspective of the project
owner, the specialist department, etc.),
• A culture of constantly replacing staff,
• Fear of delicate and conflictual discussions about the personnel composition of
the team (commitment, interests, availability, knowledge, sympathy/antipathy),
• The availability of people.
The following tips for forming the project organisation have proven successful in
practice:
• In projects with strongly diverging interests, the degree of participation of the

stakeholders will be greater and thus the project organisation will be more
extensive. Nevertheless, it is advisable to keep the project organisation as
lean as possible. Broad participation can also be achieved with support groups,
special workshops for stakeholders and users, possibly with a large group event.
• Pay attention to defined roles, avoid multiple roles! Strive for separation of
powers between the bodies.
• Do not leave the appointment of project members to chance. In addition to
assigning participants for the committees, also determine how to nominate
managers, project owners or project managers in order to achieve broad stake-
holder support.
• Project members should have the necessary resources at their disposal.
Overloaded project members are not motivated or feel forced to set their own
priorities according to their interests.
• In the course of the project, the project organisation may change from phase to
phase. Within a phase, the organisation should be kept as constant as possible in
order not to interrupt the team processes.
• It is better to have fewer projects with professionally excellent and motivated
people. Management must also be able to commit to the project.
2.3.9 Information Gathering and Situation Analysis
One of the focal points in the initialisation phase is the critical examination of the real
project objective. This can differ in several respects from the superficial objectives:
• The project order, the framework conditions, or the objectives are unclear and/or
incomplete.
• The project owner may have set an incomplete objective based on his perception.
• Conflicts of interest and power relations between different stakeholders may have
led to an unclear objective.
• The project order first requires the identification and analysis of a symptom. Only
with the results of the analysis can the actual objective formulation take place.
Example: “For 3 months we have been receiving increased amounts of returns
from the market. Find the problem and fix the root cause!”
In project work, not everything is clear from the start. That is why it is worthwhile
to first switch to fact finding mode, carry out a situation analysis, and gather
information.
The situation analysis serves to clarify the problem situation, the relevant problem
environment in the sense of clarifying the task and assessing the situation, and to
narrow down the problem. The state of affairs is reviewed at each milestone and can
be repeated or supplemented for partial aspects as needed. Depending on the
problem and the available knowledge, a situation analysis can be carried out “ad
hoc” in a few hours, or it may in other cases require detailed clarifications by several
112 2 Methodology
Table 2.24 Elements of the situation analysis

Task Instruments and issues to be addressed
Order • What is the reason for doing something?
clarification • What is it really about?
• Is the project order complete?
• Do the project owner and the project team have the same understanding of
the assignment? (Sect. 2.3.11)
Analysis of the • Context analysis
present • Stakeholder analysis (Sect. 2.3.5)
• SWOT analysis
• Cause–effect analysis
• Analysis of the legal basis and compliance specifications
• Information security and protection need analysis
Inclusion of the • Planning horizon
future • Scenario technique
people, possibly over a period of months. This is typical in product development and
investment projects and carries with it the danger of driving the analysis to paralysis.
A complete situation analysis includes at least the aspects according to
Table 2.24.
2.3.9.1 Context Analysis

In practice, context analysis is used in two different cases:
• Environment or environmental analysis

• Method for recording the tasks of users
The environment and environmental analysis have a certain correspondence with

the stakeholder analysis. The following three perspectives are relevant:
• Temporal: What happened before the project? What did the world look like
before the project? What should happen after the project is finished? What does
the world look like after the project?
• Factual: Which factual influencing factors, framework conditions, and trends are
relevant for the project?
• Social: Which persons or groups of persons have an interest in the project? Who
influences the project or is affected by the project? (Sect. 2.3.5)
The recording of users’ tasks also includes the processes involved and can be
done through various forms of work such as user interviews, questionnaires, online
recording, etc. The following questions need to be examined in more detail:
• Where do users perform their tasks?

• What do they do under which circumstances?
• How do they fulfil their tasks?
• Why do they do it this way?
2.3.9.2 SWOT Analysis

The SWOT analysis identifies Strengths, Weaknesses, Opportunities, and Threats of
the system (company or project) under consideration. The SWOT analysis examines
both the internal and external environment. Strengths and weaknesses are controlla-
ble internal factors in the present and can be changed if necessary and with the
appropriate will. Opportunities and threats are either only to a small degree or not at
all controllable external factors in the future that cannot be influenced by the
organisation. However, the organisation can take appropriate measures to counter
them appropriately if they do occur.
A SWOT analysis can be done at different flight altitudes and for different
scopes: An organisation, as an entity, can be considered as a whole. Individual
subject areas, service offerings, the project to be carried out or individual
departments can also be subjected to a SWOT analysis. Table 2.25 shows how
the individual topics can be analysed and what questions can be asked of the
members of an organisation.
The strengths, weaknesses, opportunities, and threats are to be dealt with in
different ways, as shown in Table 2.26. The SWOT analysis also makes a valuable
contribution to the formulation of objectives: in all four dimensions (strengths,
weaknesses, opportunities, and threats) concrete (SMART) objectives can be
derived through reformulation.
A company or project can only work on and influence its strengths and
weaknesses and thereby respond to the opportunities and threats of the market.
In practice, it appears that recognising and distinguishing strengths and
weaknesses is rather easy, while on the other hand many teams find it difficult to
Table 2.25 Questions for Viewing level Possible questions

the SWOT analysis
Strengths • What is going well?
• What can we rely on?
• What satisfies us?
• Where do we get energy from?
• What are we proud of?
• What do we want to keep?
Weaknesses • What is unsatisfactory?
• Which disturbances hinder us?
• What are we missing?
• What is difficult for us?
• Where are our traps?
Opportunities • What opportunities are opening up for us?
• Which market segments will boom?
• What can we use in the environment?
• What is undeveloped?
• What is expandable?
Threats • Where do the dangers lurk?
• What difficulties are we facing?
• What should we expect?
• What are our fears?
114 2 Methodology
Table 2.26 Dealing with the dimensions of the SWOT analysis

SWOT Positive Negative
• Internal aspects Strengths Weaknesses
• Today’s situation → Maintain or expand → Eliminate or reduce
• Impressionable
• External influences and trends Opportunities Threats
• Future situation → Use or expand → Evaluate and develop
• Hardly influenceable alternatives
Strengths Weaknesses
S-T W-O
Strategy Strategy
S-O W-T
Strategy Strategy
Opportunities Threats
Fig. 2.32 SWOT strategies
identify opportunities and threats, and so the upper and lower halves in Table 2.26
are mixed: Strengths are often interpreted as opportunities and weaknesses as threats.
In Fig. 2.32 possible SWOT strategies are presented in the four analysis
dimensions. In order to concretise the strategies, the following questions can be
asked, as shown in Table 2.27.
Table 2.27 Questions for the concretisation of the SWOT strategies

Strategy Question
S-O strategy What opportunities could be exploited, e.g. by expanding the current
strengths?
S-T Strategy Which threats can be eliminated or reduced with the current strengths?
W-O Strategy What opportunities would arise if the current weaknesses were eliminated?
W-T Strategy What threats could be reduced or eliminated if the current weaknesses were
eliminated?
2.3.9.3 Cause–Effect Analysis

A systematic method that allows complex cause–effect relationships to be depicted
was developed as early as the 1950s by the Japanese Kaoru Ishikawa. It is a simple
technique for systematically identifying the causes of problems. The problem is
written down at the top of a fishbone image. The main causes, which point, like fish
bones as arrows to the “spine”, can be used again and again for a variety of other
situations: Man, Method, Machine, Material, Milieu, Measurement, and Manage-
ment. These main arrows are now in turn pointed at by arrows which can represent
possible secondary causes (Fig. 2.33).
The creation of an Ishikawa diagram takes place in a moderated working group.
For the method to be successful, it is important that knowledgeable participants are
present for each affected area of the problem to be analysed. This may mean that
external people (e.g. suppliers, customers) also need to be involved.
The team members write down the problem on a large piece of paper (pin board,
flip chart) as clearly and comprehensibly as possible until everyone agrees with the
problem formulation. The individual results of the root cause research are noted
down on cards with a brainstorming session. These cards are then lined up according
Men Methods Machines

(1st order (1st order (1st order
cause) cause) cause)
«Too much
Process axis waste»
(Clearly
formulated
Cools down effect)
too quickly
(2nd order
cause)
Causes
of lower Material Milieu Management
order (1st order (1st order (1st order
cause) cause) cause)
Fig. 2.33 Cause–effect analysis

116 2 Methodology
to the “blueprint” to form the Ishikawa diagram. Alternating between the diagonal
and horizontal arrows, deeper and deeper causes can be explored.
The Ishikawa diagram can also be used to structure activities in processes or to
analyse processes. In this case, the result of the process is at the top of the main
arrow, while the individual branches represent the activities in a hierarchical order.
With the dispersion method, individual causes are assigned to a main cause. Each
individual cause is questioned: “Why does this cause (dispersion) occur?” The
questioning continues until the team can think of no more causes. The rule of
thumb here is the “five whys” technique: Ask “Why?” up to five times to get to
the root of the problem.
Possible questions are: “What causes the effect...? Why did... happen? How would
things be different if this aspect were to change? Who is affected by the problem? How
do you experience...? Who suffers from this situation, this condition?”
2.3.9.4 Analysis of the Legal Basis and Compliance Requirements

The implementation of projects requires a detailed knowledge of the different laws
and regulatory or internal company requirements. The laws and specifications can
limit the search for solution concepts (for example, compliance with environmental
regulations) or strongly influence the execution of the project (for example, compli-
ance with the maximum working hours of the project staff). Therefore, it is important
to identify and analyse the relevant topics for the project in the following areas:
• Legislation (laws, regulations)

• Compliance and governance
• Regulations for safety, health, and environmental protection (SHE)
• Rules of conduct and professional regulations
• Principles and objectives of sustainability
• Standards and norms
After the analysis, the impacts and consequences for the project are to be assessed
and derived. During the implementation of the project, ensure that the identified and
relevant framework conditions are adhered to.
2.3.9.5 Information Security and Protection Needs Analysis

Cybercrime is a rapidly increasing daily threat. Many companies underestimate this
danger and only react when an attack has already occurred instead of developing
preventive defence measures. Often only the top management level can take final
responsibility for information security and data protection. The protection needs
analysis determines the protection needs for data, documents, and applications. The
three crucial protection objectives are confidentiality, integrity, and availability.
Personal, technical, organisational, and infrastructural security measures are defined.
Business processes, ICT systems and infrastructures, applications, data, documents,
access to buildings and rooms, as well as external partners and suppliers are
analysed.
The lessons learned have to be considered in the implementation of the project
and in the design of the solution and may limit the scope of the solution. Possible
measures to protect confidentiality and integrity can be, for example, encryption of
data during storage or an authorisation system for access to applications or data.
2.3.9.6 Planning Horizon

A changed environment can significantly influence the project objectives and the
subsequent benefits of a product. The more pronounced the influencing factors
change, the greater the effect on the project, and the greater the time periods, the
more pronounced the change can be. The goal-setting process has to therefore be
directed at the planning horizon, as Fig. 2.34 shows.
2.3.9.7 Scenario Technique

Scenarios are alternative representations of the future and help to identify possible
project courses at an early stage and to assess their effects. The scenario technique is
particularly helpful in situations that have major consequences when they occur and
that allow only short reaction times.
Scenario techniques are used to develop and prepare “if-then” options. Both the
impact strength of individual actions on one’s own organisation and the forecasting
reliability in predicting these actions are examined. The higher an expected action tends
to be with regard to both dimensions, the more attention is needed, as reaction time and
costs or investments play an enormous role. If the uncertainty is reduced to two
Environment at Environment at
Environment the end of the
today planning horizon
project
Project tasks Product at the end Product at

at project start of the project planning horizon
Determining for Determining for Determining for

solution finding successful product successful usage
introduction of the product
Fig. 2.34 Consideration of factors influencing the future

118 2 Methodology
alternatives with very different costs, both scenarios are recorded as alternatives in
planning.
Imagine a customer wants a high-precision machine that you have never produced
before with such a low tolerance. Your engineers have determined in a feasibility
analysis that you could achieve the required precision with your current production
methods and some additional work “with a bit of luck”. How much additional work
will be necessary cannot be estimated from the outset. If it turns out that the goal is not
achievable with the methods you know, a new process will have to be devised with an
effort of eight person-months. In addition, a clean room for the new process must then
be obtained, which requires investments of 600k €. Both scenarios are planned for in
advance. A milestone is set by which the decision has to be made to discontinue the
first of these alternatives (deadline). The project management may also decide to
implement both alternatives in parallel. If the existing procedure proves unsuitable
after, say, 3 months, the new procedure is ready for implementation only 5 months
later. The price for this speed lies in the costs and tied-up resources for the second team
and in any investments in initial cleanroom components.
2.3.10 Project Structuring
The planning and therefore also the structuring of projects is carried out very
differently depending on the situation. In distinct standard projects with a great
deal of experience in the company, the structure is already provided in specification
documents and is also enforced for the purpose of a uniform procedure. In smaller
projects or potential projects with a high degree of openness to objectives, e.g. in
basic research or if the detailed specifications have not yet been bindingly defined,
only basic structures are set, e.g. different teams are put together.
Project structuring, also called rough planning, is about clearly structuring
projects according to their size and complexity and thus making them manageable
in the first place. The project is structured in two dimensions, as shown in Fig. 2.35:
Goals Concepts
Project structuring
Requirement Technical
Specification Specification
Fig. 2.35 Project structuring

• Phase structure by setting milestones between the phases: Milestone plan

• Break down the project into tangible and definable building blocks: sub-projects
and work breakdown structure (project structure plan)
The phase structure with the milestone plan is a temporal structure of the project.
Usually, a project phase is completed before the next phase is worked
on. Sub-projects divide an extensive and complex project into several parts, which
can be divided per department or per subsystem. A sub-project manager is appointed
for each sub-project. The work breakdown structure is a building block-oriented
structuring of the project and helps to divide the project into manageable
deliverables, deliverables, and work packages.
2.3.10.1 Procedure for Project Structuring

• Determine project phases and milestones
• Determine decisions to be made upon reaching the milestones
• If necessary, divide large projects into sub-projects: Delineate sub-projects and
appoint sub-project managers, carry out initial consultations.
• Define and delimit the deliverables and work packages: Define the structure of the
deliverables and work packages and assign responsibility. The sum of all work
packages forms the work breakdown structure (Project Structure Plan).
The result is documented in the milestone plan and the work breakdown structure.
Sub-projects are documented in the organisation chart.
2.3.10.2 Setting Milestones in the Project: The Phase Plan

The phase plan (also called milestone plan), as shown in Fig. 2.36 roughly depicts the
chronological sequence of the project and is intended to clarify the following questions:
Review Review Design Review User System Design System Market

Project Idea Goals Requirements Specifications Freeze Release Release
System / Project
Level
Ideas Study Phase Design Phase Utilisation Phase
System Integrations
Review Design
Review Review
Output
Design Input Design Transfer
Sub-Project
(Design Freeze)
Level
Development Phase Pre Production Series Production
Fig. 2.36 Practical example Metrohm: Milestone plan

120 2 Methodology
• Into which phases should the project be divided in terms of time?

• Which milestones, documents, and results must be achieved and checked at the
milestones between the phases?
• Which deliverables and work packages are processed in which phase?
• At which milestone is a review necessary?
According to Which Criteria Is a Project Divided into Phases?

It would be risky to carry out a large project in one go and to only make a check-up at the
end whether the intended goal has been achieved. That is why large projects are divided
into individual phases with verifiable interim results, the milestones. The project man-
ager thinks about what work has to be done in which phase or for what eventuality a
concept has to be created in which phase, which then gets decided on at the milestone.
It is also necessary to further subdivide a project or a project phase if the later
discovery of a mistake, a wrong direction taken or an inadequate attitude would lead
to disproportionately sizeable consequences. It does make sense to set a prearranged
point in time with a further milestone at which what has been achieved is reviewed
and the further course of action is determined.
For a small, unproblematic project with a high routine factor, two phases may be
sufficient: an initialisation and concept phase and an implementation phase. For
larger projects or greater uncertainty in the project, more phases and milestones at
the critical points in time make sense. Figure 2.37 shows milestone plans for simple
and complex projects.
0 0 0
Definition and Commissioning Feasibility study

design phase 1 1
1 Initialisation Specification WHAT
2 2
Realisation phase Concept Rough concept HOW
3 3
2
Realisation Detailed concepts
4 4
Introduction Realisation
5 5
Integration / Test
6
Pilot series
7
Series adjustments
Milestone 8
Fig. 2.37 Milestone plans for simple and more complex projects
When is a Review Necessary?

If, after a milestone, the further process is able to bring about major consequences, risks
of a financial nature are taken or the company’s image may be affected, or if the team is
breaking new ground with correspondingly greater uncertainty, it always makes busi-
ness sense to carry out the milestone review particularly carefully and critically. Then
the project manager applies an established procedure and conducts a review.
The purpose of the review is to critically review the interim status achieved and
the further procedure, also from another, independent point of view. This is to ensure
that the degree of maturity of the documents developed and the basis for decision-
making is adequate for inducing the next phase. Any errors that would have an
impact later on should still be detected in time. Possible topics of the review are:
• Are there new risks to be identified or existing ones to be re-qualified?

• Are the earlier assumptions still correct?
• Do the general conditions still apply?
• Does the chosen approach still make sense?
• Often the project owner requires such a critical review before signing off on the
next phase and thus releasing the necessary funds. The project manager and the
project owner agree on where a review is necessary.
In certain companies with standard project processes, the review and the timing of
this review may be predetermined. Terms such as quality gates or milestone review
are used to describe this activity.
2.3.10.3 Projects, Sub-projects, Work Packages, Deliverables,

and Activities
There is a hierarchy within and between the overall project, the sub-projects, the
work packages, and the deliverables, as shown in Fig. 2.38.
Sub-projects
For small to medium-sized projects, project management is the responsibility of a
single person. If, in the case of very large or very complex projects, the management
span becomes too large for just one project manager, it makes sense to then manage
sub-projects and divide up the project management activities (planning, control and
steering of the process) between two or more people. The price for this is the
necessity of additional agreements and of a coordination between the sub-project
managers and the overall project manager. It only makes sense to form sub-projects
if the advantages (manageability, independence) outweigh the disadvantages.
Merely dividing the content into work packages or activities is not sufficient reason
for introducing sub-projects.
The overall project manager and the sub-project manager have to agree on the
interfaces between the sub-projects and define continuous milestones at which
decisions are made for the entire project. On the occasion of a milestone, all
sub-projects have to have the corresponding basis for decision-making so that a
go/no-go decision can be made for the entire project.
122 2 Methodology
Project
Subproject 1
Subproject Manager
Project
Manager
Work package 1 Work package 2
Deliverable Deliverable
Activity Activity
Subproject 2
Subproject Manager
Work package 3
Deliverable
Activity
Fig. 2.38 Hierarchies in the project
Work Packages
The project as a whole is divided into clearly structured activities or tasks, with
simple interfaces and a technical allocation of the task holders, so that a clear
assignment of responsibilities is possible. Throughout the different phases of the
project, it has to be warranted that there is a clear demarcation and continuous
responsibility of the task bearers. The project should be presented in its entirety. A
work package is the totality of several deliverables and activities that are to be self-
contained in order to get a verifiable result or outcome. A work package manager is
designated for each work package. Work packages can be put together in two ways:
Top-down: the whole project is broken down step by step into smaller units with a
sensible delineation of work packages. This requires experience with similar
projects and a good overview of the project.
Bottom-up: If little experience is available, this procedure is chosen. All activities that
come to mind are collected in the team. Then group related activities into deliverables
and work packages. Finally, check whether the listed activities are complete.
In large or complex projects, a work package description is created for each work
package. This provides information about prerequisites (input), activities that are
carried out with this work package, results (deliverables, output), the effort required
for this work package, the people responsible, and the general conditions.
“Prerequisites” section lists in keywords the information or documents that need to

be available before the work can be started. Figure 2.39 shows an example of a work
package description from the BLS practical example.
T-TA Work package description
Designation Test concept project sales back-end

Context / initial situation In the Sales-Bach-End project, standard components (e.g. timetable) are purchased
from the market and substantial parts are developed in-house. The realised system
must be systematically checked and tested before going live.
Goal / Description Creation of a test concept for the Sales-Bach-End project as a basis for setting up
the necessary test organisation and test infrastructure.
Client Mike
Contractor Bruno, Thomas
Total effort [h] 80 h
External costs No external costs
Start date 1 December 2022
Deadline 31 January 2023
Dependencies None
Input, prerequisites The general requirements for BLS projects regarding testing must be taken into
account.
Result The test concept describes the test objectives, test objects, test types, test
infrastructure and the test organisation of the project. It also includes the test
planning and a definition of the test scope, as test case descriptions or as a
reference to the test cases in an external test tool. A detailed test case
specification is created for each test case. The test planning defines the logical and
temporal sequence of the tests.
The test concept forms the basis on which the test organisation and the test
infrastructure are provided and the tests are carried out.
Acceptance of the results Mike, Irina
Degree of target Good (at least 80%):
achievement Test concept contains all elements as described in the result
The BLS specific specifications are complied with.
The test concept has been approved and the findings have been incorporated.
Very good (100%):
How good, in addition, the test concept is considered best practice in the BLS
project community.
Content Approval
Job Date Signature
Client
Mike
Assessment after completion

Job Date Signature
Client
Mike
Comment
Fig. 2.39 Practical example BLS: Example of a work package description

124 2 Methodology
Deliverables
The Deliverables are the results that are to be delivered by the project, such as a
product, a service, or a concept. The success of the project is measured by the
deliverables.
• Deliverables are part of a work package.

• Depending on the size of the project, deliverables and work packages are merged
and not differentiated.
• Project objectives, or more precisely, system objectives and deliverables are
linked to show the connections and interrelationships.
Activities and Tasks

The activity (also called task) is the indivisible unit in project planning. While a team
or a department can be responsible for a work package, an activity should be
assigned to exactly one person. The granularity of the activities, i.e. the intellectual
and temporal scope, also depends in particular on the experience of the person
carrying out the task.
2.3.10.4 The Work Breakdown Structure WBS

The work breakdown structure WBS (Project Structure Plan PSP) is the result of the
appropriate structuring of all work packages.
There are different criteria according to which the work breakdown structure can
be organized. It can be object-oriented (content, goal or product-oriented), process-
oriented (process, activity or function-oriented), or mixed-oriented (object and
process-oriented). Sometimes a distinction is also made between process-oriented
and function-oriented. In production-oriented companies, project structuring is often
carried out according to objects or contents, e.g. assemblies, which results in a
favourable division for management and processing, as shown in Fig. 2.40.
Figure 2.41 shows an example of a process-oriented WBS structure.
However, it is more important that responsibility can be clearly assigned to the
task bearers. Often the structuring according to functions corresponds to the
specialised areas of the organisation such as sales, marketing, customer service,
development, construction, or production. In service-oriented companies, this
demarcation also makes sense.
The deliverables have to be recorded in the work breakdown structure. This is the
case in an object-oriented WBS. Instead of the work breakdown structure, in practice
one sometimes also speaks of the results plan.
The practical example from Metrohm (Fig. 2.42) shows a work breakdown
structure with the levels project, sub-project, and deliverables.
Phases and work breakdown structures can also be mixed, as shown in Fig. 2.43.
Vacuum cleaner structured according to modules
Mechanical Electrical Housing

system system and assembly
Small impeller Motor Support plate
Big impeller Power switch Housing base
Filter holder Power cable Filter cover
Filter element Overload protection Operating flap

Fine filter Control Air hose
Flap valve Operating elements Nozzles
Cable drum Filter holder
Sealing Dividing wall
Sound isolation
Fig. 2.40 Example of an object-oriented WBS structure
Vacuum cleaner structured according to activities
Technology Production Marketing
Alternative solutions New production processes Market analysis

Wooden model Subcontracting agreement Customer survey
Fluid dynamics Expansion of inspection Specifications
Rough draft Prototype production Pricing
Detailed development pilot series Distribution network

Energy optimization Series adjustements Exhibition
Prototype testing Serial production Marketing campaign
Qualification Introduction program
EMC testing
Fig. 2.41 Example of a process-oriented WBS structure

126 2 Methodology
Project Organisation
Bottle OMNIS
Sample Robot Pick & Place Titrator Software
Cap
Pick & Place Modul
Measuring system
Lab Logic Service

Gripper Module
Magnetic stirrer
Liquid Adapter
Dosing system
Power Supply
Power Supply
Main module
Pump modul
Equipment
Mainboard
Mainboard
Bottle top
Processes
Samples
Rack
Fig. 2.42 Practical example Metrohm: Work breakdown structure
Subproject Subproject 1 Subproject 2 Subproject 3

Technology Production Marketing
TPL 1 : TPL 2 : TPL 3 :
Phase Developer nn Production assistant Head of marketing
MS 0 Decision on specification and product development
Development Development tests Preliminary clarification Advertising concept
Construction prototype for production Service concept
Make a prototype Consulting construction Sales concept
Test the prototype Production planning Contract negotiations
Adjust documents Preliminary costing Economics
MS 1 Decision on pilot series

Transfer to Pilot series documents Procurement of producti- Optimise production
production Test pilot series on means Service and sales
Small adjustments Produce pilot series organisation
Optimise production Field test pilot series
MS 2 Decision on serial production and market introduction

Launch Documentation adjust- Optimise serial produc- Marketing campaign
ments tion
MS 3 Decision on further projects
Fig. 2.43 Example of a mixture of phases and work breakdown structure

2.3.11 Project Order
The project order constitutes of the basis for deciding whether the initiated project
should be implemented or not. The creation of the project order is an agreement
process between the project manager or product owner, the project owner and other
stakeholders. The project order is created in a similar way to the request for proposal,
which is discussed and negotiated with the external customer. It is the task of the
prospective project manager or product owner to formulate the project order. The
project manager, as the person responsible for the process of the project, knows
which elements need to be regulated. With his signature, the project owner shows
that the project manager or product owner has correctly grasped the issue. He gives
the green light, usually for a project phase.
The project order in the agile approach is formulated more concisely and is less
detailed than in the traditional approach (for example, with regard to the scope of the
project). Regardless of whether a project comes from within or from the outside, the
points according to Table 2.28 belong in a project order or in an offer.
Depending on the project and the company, the emphasis of the planning in the
initialisation phase is different. In certain cases, the focus is on planning the entire
Table 2.28 Content of a project order

Initial situation • Circumstances that led to the project
• Background, factors causing the project
• Description of the actual situation
• Problems or potentials of the current situation
Objectives Objectives, i.e. the overall objective
Scope of the project It is important that there is clarity among all project participants regarding
(Scope) and results the final result and possibly the important intermediate results
• What form should the end result have (presentation, document,
system)?
• Scope of delivery of the project: the essential requirements in a
summary form (for details, reference can be made to requirements
documents). From these, the deliverables and work packages can be
derived
Delimitations At this point, what is not realised by the project is clearly delineated. The
project boundaries are defined. The boundaries can refer to functions,
data, organisational units, etc.
Dependencies and Dependencies may exist, for example, on:
influences • Other projects (in terms of content, time)
• External circumstances (e.g. changes in legislation)
What are the main influences on the project?
Framework Framework conditions are requirements or restrictions of a general nature
conditions for the project: requirements to be taken into account, known restrictions
Basics On what preliminary work or foundations is the project based? Such
foundations can be, for example:
• Studies, analyses
• Concepts, strategies
• Standards, norms
• Results from previous projects
(continued)
128 2 Methodology

Project costs, • How big will the effort for the project be?
benefits • Are the required financial and human resources budgeted?
• Which cost centre will the planned project costs be charged to?
• What quantifiable/non-quantifiable benefits or advantages result from
the implementation of the project?
Risks • What risks are present or discernible from today’s perspective?
• What measures can be taken to reduce them?
• What are the consequences of non-realisation?
Procedure, schedule • Project structure and project plan with milestones
• When is the project finished?
• Notes on special procedures
Project organisation • Project owner
• Contractor (Project manager)
• Project team(s), possibly staffs
• Supervisory bodies (e.g. project committee)
• Escalation path
Information, This describes the flow of information or communication with the project
communication owner, the supervisory bodies, the user, and other interested parties.
Reporting can take place in writing or orally. The creator and recipient of
documents as well as the periodicity should be clearly recognisable:
• Progress report (status report)
• Project plan
• To-Do and Decision Lists
• Project Newsflash
Signatures • Project owner
• Project manager
• Controlling (for major projects)
• Decision-making bodies according to financial competence
Appendix • Project plan
• Project organisation
• Detailing “economic efficiency”
• Resource plan
• Planned expenditure
project. In other cases, only the next phase is planned in detail, the remaining phases
only roughly.
2.3.12 Project Manual, Project Management Plan
The project management manual (Sect. 2.7.5) regulates how project management is
applied throughout the company and how it applies to all projects. The project
manual is the specific adaptation for a project. It has to be adapted to the specific
situation of each project. The project manual or project management plan depicts the
most important process regulations such as agreements, plans, structures,
organisational charts, and rules of the game of the project. Possible contents of the
project manual are shown in Table 2.29. The project manual is intended to create
Table 2.29 Possible Project order and • Project order, project agreement
content or structure of a performance planning • Structure: Project phases, work
project manual breakdown structure
• Interfaces in the project
• Decision-making process
Project environment • Environment analysis, stakeholder
groups
• Embedding in the corporate strategy
Project organisation • Organigram
• Description of roles, tasks, and
competences
• Contact persons and addresses
• Rules of cooperation, escalation
procedures
Project planning • Scheduling
• Resource planning
• Cost planning
Controlling • Quality assurance, test plan
• Risk management
• Control and steering
• Measures in case of deviations,
change management
Information, • Information and communication
communication concept
• Meeting planning
• Meeting and workshop minutes
• Progress reports (possibly under
controlling)
• Filing structures, document
management
transparency and commitment for all participants. It is kept up to date from the
beginning. The updated version is made available to the entire project organisation.
2.3.13 Kick-Off
The Way a Project Began is How it Usually Ends With regard to the management
of a project, the beginning of a project needs to be given the utmost attention. The
formation and establishment of the project organisation is an essential part of this. In
order to lay a good foundation in the project organisation, the design and implemen-
tation of a kick-off is of central importance. Depending on the type of project and the
timing of team members, several kick-offs take place at different times.
The kick-off meeting is the official start of the project. It is not only about content-
related or organisational issues, but also in particular about building up or expanding
the relationships of the project team that has just been put together (see also Sect.
1.5). The checklist according to Table 2.30 should help to plan the kick-off compre-
hensively. It is quite possible that several kick-offs are held in the course of a project.
130 2 Methodology
Table 2.30 Checklist: Objectives of the kick-off

Content level • The product vision, the benefits to be realised, and the background of the
project are presented.
• The current project status or assignment is discussed
• The intentions and objectives are explained
• The team members have a common understanding of the tasks
• The interrelationships of the individual task areas are explained
Relationship • All team members get to know each other
level • Rules of the game are defined and adopted by the team
• Identification (sense of togetherness) with the project and project team
(through insight into the meaning of the project, highlighting the special
characteristics of this team)
• Informal platforms are available which enable an interpersonal exchange of
opinions
Organisational • The methodological procedure is outlined
level • Project planning already in existence or release planning is presented
• Possible problem areas of the project have been addressed and the team
members responsible for solving them have been identified.
• The project organisation is shown, the resources of the individual members
are known
• The communication and decision-making channels are defined
• The tasks, responsibilities, and competences are assigned to individual team
members or groups
• The meeting rhythm and the taking of minutes are fixed
These kick-offs may take place with different participants or at different points on
the timeline.
Procedure of a Kick-Off
Table 2.31 shows a possible sequence of a very comprehensive kick-off. A kick-off
can also be shorter. The authors of the book recommend not to simply hold
information events, because it makes sense to start working on the topics together.
2.3.14 Problem-Solving Process
An important procedure, that can sometimes even be used as a management tool, is a

systematic, structured approach when encountering new situations. The problem-
solving process, as shown in Fig. 2.44, is a structured tool for solving technical
problems, whatever their nature might be. It can be applied to a whole project, to a
part of it or just to a difficulty that has come up unexpectedly.
The term “problem-solving cycle” is often used to emphasise that in reality
finding a solution is not a linear process and that the individual steps can be run
through several times, as often as is required (iterative procedure).
With the problem-solving process, the advantages of a systematically structured
way of working come to the fore, compared to a free-float or jerky approach. It
sometimes makes sense to tackle an “obvious” solution directly, without examining
the current situation in detail or even thinking about objectives and possible
Table 2.31 Example “Kick-off”

Time Topic Objective
08:00 Arrival of the people, coffee Informal reunion or getting to know each
other
08:30 Start, welcome by project manager, Punctual start, orientation to the meeting,
introduce kick-off procedure (with times), transparency, building trust
project manager briefly introduces
himself/herself
08:45 Introduce project, explain brief overall Create information level, introduce
history and global goal project objective
08:55 Introductions of project staff, discuss Get to know each other, establish a
personal connections to the project: What relationship with the project, discuss
do I personally expect from my wishes, expectations, fears and related
involvement in the project? project experiences, initiate networking.
09:25 Inform about the project status or create it Information
together
09:40 Prepare stakeholder analysis, identify Recognise environment and
system boundaries dependencies, identify people’s attitudes
towards it
10:00 Break Informal exchange
10:20 Showing the field of forces of the project Knowing which forces promote the
project, which hinder it
10:40 Derive already identified problem areas Situation analysis, data on risk
considerations
11:00 Show the organisation of the project with Set up the project organisationally,
regard to cooperation and project identify bottlenecks, regulate fixed
sequence (deliverables and work deadlines, show scope for action
packages)
11:10 Regulating cooperation, meeting interval, Determine communication, rules of the
document management and minutes game
11:20 Discuss and determine next steps Create a clear work plan
11:30 Each person briefly comments on the Recognise commitment and resistance,
further process, their role and function and create commitment
the planning
11:55 Closing words from the project manager Appreciate and show importance
or project owner
12:00 End of the kick-off
solutions. However, most of the time important details get overlooked and hence
solutions are adopted that were suitable in the past, without taking into account the
currently changed situation. This situation, which is often encountered in practice, is
called the “solution trap” or “jumping to solution”, as Fig. 2.45 shown. A structured
approach is worthwhile for projects that enter new territory.
The problem-solving process is run through in each project phase. The emphasis
on the individual steps of the problem-solving process shifts in the course of the
project: while in the initial phase the focus is on the situation analysis and the
formulation of objectives, in later phases it will be on the search for or evaluation
of solutions and the decision. The level of detail also increases from phase to phase.
132 2 Methodology
Monitoring Situation analysis

Did I forget or overlook What exactly is it about?
something in the plan- 6 Strengths / Weaknesses
ning? Opportunities / Threats
Causes / Effects
5 1
Implementation
Problem-solving
Plan, who can do the process
work or whether I can
delegate it Formulation of goals
4 2
Goal criteria > SMART
Must / desired goals
Find a suitable solution Procedural goals
3 System goals
Solution with best benefit,
best achievement of goals
Search for alternative solutions

Thinking in alternatives
Fig. 2.44 The problem-solving process
Experience
Automatism
Pattern behavior
Monitoring 6 1 Situation analysis
jumping to solution
Implementation 5 2 Formulation of goals
Find a suitable solution 4 3 Search for alternative solutions
Fig. 2.45 The solution trap

Alternatives to the Problem-Solving Process

The problem-solving process is so universally applicable that this system has been
served up again and again under different names since the 1960s. The project
manager is confronted with different tasks and problems. Depending on the situa-
tion, one or the other model (Table 2.32) is more helpful in terms of terminology and
methodological procedure:
• Something completely new can be created that did not exist before (new product,
new service). Creativity and breaking new ground are in the foreground (e.g. in
pioneer projects).
• Something that previously worked satisfactorily suddenly no longer fulfils its func-
tion. Identifying malfunctions and searching for the cause are the order of the day.
• Existing processes need to be improved or optimised.
In a different project environment, the best practices may differ or different terms
may be used. In research, the steps are, for example: Literature study, data collection,
data analysis, hypothesis, verification. In the social field the steps are: Observation,
hypothesis, intervention.
Table 2.32 Alternatives to the problem-solving cycle

Design thinking • Understanding: Design Challenge
See also Sect. 2.8.2.6 • Observe: User-Centred Design
• High user acceptance • Define point of view: Synthesis via Persona
• Finding ideas: Customer-oriented solutions, thinking in
variants
• Develop prototype: Iterative approach
• Testing: early feedback loops
Lean, Six Sigma • Define: what customer needs should the process meet?
(DMAIC, DMAEC) • Measure: expression of the performance characteristics of
• Improvement the process
• Optimisation of a business • Analysis: Identify causes of deviation from defined
process performance objectives
• Improve, engineer: seek possible solutions to identified
problems, set evaluation criteria
• Control: Introduce and monitor improvements and new
procedures
Deming circle (PDCA circle), • Plan: analyse current status, identify potential for
Shewhart cycle, continuous improvement, plan measures, sprint planning
improvement process • Do (implement): implement, try out, test on a small scale,
The sprint cycle in the agile sprint implementation
approach scrum corresponds • Check: Check results with regard to effectiveness, sprint
completely to the PDCA cycle review
• Act (improve): introduce as a standard across the board or
identify improvement actions, sprint retrospective.
Appreciative inquiry • Discovery: discovery phase, recognising and
See also Sect. 2.8.2.9 understanding
Appreciative questioning in team • Dream: Vision design, dream of the best solution
and organisational development • Design: Future design, develop a vision, take a decision
• Destiny, Delivery: implementation phase, determining
what will happen, implementing new ideas
134 2 Methodology
2.3.15 Checklist Completion Initialisation Phase
Agile and traditional approach:
• Is the overall objective of the project clearly formulated? Do the project

owner and the project manager or product owner agree on the objectives
and framework conditions?
• Are the objectives formulated as if they have already been achieved?
• Are the objectives formulated in a solution-neutral and positive way,
specific, as measurable as possible, free of contradictions, demanding,
scheduled, and also achievable? How do you know that your objectives
have been achieved?
• Have conflicting objectives been discussed? Have the stakeholders been
identified and analysed? Who are the relevant stakeholders?
• Is it clear which stakeholders have which interests and power of influence?
• Are there any intentions that are not disclosed at this stage?
• Do the project owner and the management support the project team with all
the means at their disposal?
• Has feasibility been proven in the market and in the political and technical
environment?
• Have the relevant stakeholders been identified?
• Is the project’s economic viability (business case) still verified at the
present time?
• What do the risks look like? Are the risks realistically assessed and have
any differences in the assessment been adjusted?
• Have measures been formulated to reduce the risks?
• Has a kick-off been held with the project team?
• Were the following issues clarified in the project order:
– Objective
– Procedure plan: Methods, steps, milestones, schedule, work breakdown
structure
– Influencing variables: Dependencies and influences
– Human resources and project organisation
– Project costs
– Framework conditions and delimitations
• Have the foreseeable follow-up costs of the project been clarified and
mentioned in the project order?
• Is the nature of the cooperation regularly reflected upon together?
• Specific points of the traditional approach:
• Have the requirements (specifications) been developed?
• Have the requirements been checked regarding their quality?
• Are the requirements prioritised?
(continued)
2.4 Concept Phase 135
• Were the future users involved in the formulation of the requirements?

• What does the project organisation look like?
• Have the competences and responsibilities been agreed upon?
• Are clear and sufficient decision-making competences and corresponding
leadership responsibilities assigned to the project management?
• Is adequate interdisciplinary representation and expertise ensured in the
project team?
• Are active users and stakeholders involved in such a way that the highest
possible acceptance can be achieved?
• Are the resources available?
• Has a work breakdown structure been drawn up? Has the division into
sub-projects been correctly made or planned? Have critical decisions been
scheduled?
• By when can the results or interim results be expected? What is the
planning for the project?
• What is the estimated effort in person-days, how much money is to be
invested over the entire duration of the project?
• Are the effort, deadlines, necessary knowledge, and availability of key
personnel checked and realistically aligned to the new findings?
• Which bottleneck resources are needed in which time period?
• Are any estimates (quantities, frequencies, milestones, costs, times) realis-
tic? Is the accuracy of the estimate indicated?
• Are the specialists, necessary means, and resources available at the
right time?
Specific points of the agile approach:
• Who is the product owner, scrum master, and who are the developers?
• Is the product owner well anchored in the line organisation and does he or
she have direct access to relevant decision-makers?
• Are the resources available?
2.4 Concept Phase
In the agile approach, the concept phase focuses on the development of the product
concept (product goal) and the requirement catalogue (product backlog). Planning
takes place in a less concrete form than in the traditional approach. As a part of this
planning process, a release plan is drawn up. The concept phase should be much
shorter in the agile approach than in the traditional approach. The work in the agile
project begins with this phase.
In the traditional approach, during the concept phase, solution variants are
developed and evaluated. Plans are drawn up for the selected variant, ready for
implementation, and solution concepts as well as the technical specifications are
136 2 Methodology
drawn up. The needs of all interest groups must be reconciled as far as possible. In
doing so, it is important to be aware of one’s own habits. In large projects, the
“concept” phase can be divided into the main project and the detailed project. The
division creates another milestone. This avoids the project team getting bogged
down in rough terrain. At each milestone, the project owner decides which variant
to pursue. He also releases the funds for the next phase.
2.4.1 What Is Important in the Concept Phase?
Steps of This Phase

In the concept phase, the relevant stakeholder groups are represented, be it those in
the project team or those in sub-project teams, in special working groups or support
groups. There is often a tendency to involve as many representatives of a stakeholder
group as possible, which makes the project organisation cumbersome and time-
consuming. The steps of this phase are shown in Table 2.33.
Table 2.33 Steps of the concept phase

Most important steps • Develop the idea by means of a • Further specify and revise the
product concept (product goal) requirements as needed
and, if necessary, visualise it by • Develop solution variants
means of a simple model (culmination of creativity in this
• Start building the requirements phase) and check them for
catalogue (product backlog) conformity with the goal
• Prioritise and estimate the • Evaluate solution variants, have
entries in the product backlog and one variant selected by the project
derive a release plan from them owner
• Establish and ensure • Develop the solution concept
information and communication (specifications) for the selected
• Establish documentation/ variant.
ticketing system • Review and adjust means and
resource needs
• Detailed planning: scheduling
and resource planning
• Establish and ensure
information and communication
• Establish documentation system
What should be paid Based on the rough project • Based on the requirements, a
particular attention to planning by means of the release solution variant has to be found in
in the concept phase? plan, the planning in the the concept phase and this needs
realisation phase is concretised on to be worked out in detail by
the occasion of the sprint means of a solution concept
planning and the daily stand-up • The detailed plan for the rest of
meetings the project developed in this
phase serves as the basis for
progress monitoring in the further
course of the project
Table 2.34 Results of the concept phase

Principle In the agile approach, asking In the traditional approach, the focus lies on
“what” is central asking “how”
Questions • What should be implemented, • Which solution variant should be selected?
to be what is the vision? • What is the chosen solution?
answered • What added value is to be • How should the chosen solution be
realised? implemented?
Process- • Updated project order • Updated project order (if necessary)
oriented (if necessary) • Information and communication concept
results • Release schedule • Detailed plans for the realisation according
• Project documentation and to the traditional approach
ticketing system • Project documentation system
• Phase report • Phase report
Content- • Product concept (product • Solution variants are developed
oriented objective) • A variant with plans ready for
results • First version of the product implementation is selected
backlog (requirements • The specific solution is elaborated in
catalogue) detail with the necessary concepts
(functional specification) (The way of
solution conception differs greatly within
sectors and project types)
Results of the Concept Phase

Communication with stakeholders needs special attention in order to achieve trust,
identification, and support. Important instruments for this are: the information and
communication concept and project marketing. In the concept phase, the results
according to Table 2.34 are of importance.
Phase Report
In some organisations it is common to produce a phase report at the end of a phase.
The phase report gives a brief overview of the results and outcomes achieved. This
document contains the evaluation or summary of the concept phase and forms the
basis for the next phase:
• Initial situation: prerequisites, assumptions, problems encountered, consequences

• Achieved results and outcomes
• A critical review of the process during this phase is of great value: what does the
team learn from it for the next phase?
• Objectives, newly identified framework conditions
• Solution, solution variants
• Impacts on stakeholders, e.g. customers, owners, personnel
• Benefits and updated economic efficiency calculation, in particular changes
compared to initialisation
• Updated project organisation
138 2 Methodology
• Overall planning of the project, planning of the next phase, financial management
incl. funding requirements for human resources and material resources
• Risks
• Motion: Solution and further procedure
Upon reaching the milestone “Conclusion of the concept phase”, the solution variant
to be implemented gets defined formally and the further procedure is made known.
People and Team

Various aspects from the competence areas of people and team (see Chaps. 3 and 5)
may be relevant in this phase of the project. However, they may also occur at a later
stage or not at all.
With the signed project order the concept phase begins. In the agile approach, the
effective project work at this stage begins with the development of the product vision
(product concept, product goal). In the traditional approach, substantial and demanding
conceptual work must now be done. The team is often changed during this phase: New
people join because more capacities are needed. This changes the social structure of the
project team. Therefore, initialisation measures often have to be repeated. The follow-
ing topics are important now:
• Work on the system (Sect. 1.5.2): With the official project order, the cooperation
in the team must be formalised.
• Versatility and creativity (Sect. 1.7): As in the commissioning process, high
attention should be paid to variant thinking and creative approaches to solutions
in the initialisation process.
• Dynamics in teams (Sect. 5.2): In response to a possible “storming” it is important
to further clarify and possibly adjust the roles in the project through “norming”.
• Self-management (Sect. 3.8): The intensity of the work now also places greater
demands on individual project participants in terms of their self-management and
behaviour in relation to stress and change (Sect. 3.5).
• Motivation and meaning (Sect. 3.7): How well do you succeed in communicating
the meaning and benefits of the project to the team? This has a strong influence on
intrinsic motivation.
• Connection of the project to the line (Sect. 2.3.8.8): The way in which a project is
integrated into the line has a significant influence on the decision-making
competences and the management style of those responsible for the project.
• Concretisation of the leadership approach (Sect. 4.4) and the necessary power and
authority (Sect. 4.9).
• Project culture, multicultural cooperation (Sect.5.4), and possibly also aspects of
virtual cooperation.
2.4.2 Product Goal (Product Concept)
It all starts with the idea. With the creation of the product goal (also product concept
or product vision) in the agile approach, this idea is concretised. The product goal
describes the benefits for the future user of the product or service and the essential
performance features.
The product objective should be deliberately formulated in concise way. This
puts the focus on the essentials. It is advisable to visualise the product goal with the
help of a physical model, as shown in Fig. 2.46 on the practical example of BLS.
The product objective and the model define the vision for the project. This is a
simple way of efficiently picking up stakeholders at different management levels in
order to win them over for the project. The product objective describes the following
topics:
• Needs of users, customers

• Benefit or added value for users, customers
• Key features and functions
• Target figures
Fig. 2.46 Practical example BLS: A simple model for visualising the product idea
140 2 Methodology
The product goal is defined by the product owner together with the scrum team and
stakeholders such as users, customers, marketing, market research, product manage-
ment, sales, manufacturing. The product goal forms the basis for the efficient creation
of the product backlog and stands for commitment to the artefact product backlog.
2.4.3 Product Backlog
Ken Schwaber and Jeff Sutherland define the product backlog in the scrum Guide in
the following way:
The product backlog is an emergent, ordered list of things needed to improve the
product. It is the only source of work done by the scrum team.
Product backlog entries that can be completed (Done) by the scrum team within a
sprint are considered ready for selection in a sprint planning event. They usually
achieve this level of transparency through refinement activities. Refinement of the
product backlog is the process by which product backlog entries are broken down
into smaller, more precise elements and further defined. This is an on-going activity,
adding more details as, for instance, description, order, and size. The attributes often
vary depending on the working environment.
The developers who will do the work are responsible for sizing implementation.
The product owner can influence the developers by helping them to understand the
product backlog entries and make trade-offs. (Schwaber & Sutherland, 2020, p. 11/
12).
The statements can be summarised as follows:
• The product backlog is the source of the requirements

• The product backlog is dynamic and never complete or free of contradictions
• The product owner is responsible for the product backlog
• The entries are prioritised (ordered)
• The entries have different levels of detail
• The entries are estimated in terms of their effort
The product backlog is a list and can be set up as a table in all commercially
available tools. In the initial phase, it is also advisable to visualise it with slips of
paper on a wall, as Fig. 2.47 shows.
A product backlog can also be structured by focus topics. A focal topic is often
referred to as an epic. Each focus topic (epic) is divided into several features and
enablers in a subsequent step, if required. Features are business functionalities for
users. Enablers are technical prerequisites or foundations for the implementation of
features. Features and enablers are divided into several user stories. It should be
possible to implement several user stories in one sprint.
It is advisable to define acceptance criteria for the epics, features, enablers, and
user stories. (Definition of Done) for the epics, features, enablers, and user stories.
Fig. 2.47 Practical example BLS: Initial Product backlog BLS
Key Summary Description Status Issue Type

BLS Mobile App For customers who buy public transport tickets from BLS, the BLS Mobile APP is their personal travel companion, allowing them to buy tickets, store Open Epic
subscription moments and call up timetables.
VBE-463 Timetable preferred I, as an end customer, would like to be able to find my preferred travel route at a time defined by me with as little interaction effort as possible. Open Feature
travel route
Acceptance criteria:
- Suggestion list for stations
- Route finding without location
- Target timetable data
- Presentation of results in tabular form
- Consistency of customer information with station displays and existing sector specifications.
- cf. V580
VBE-36 National timetable The timetable server must support national queries in Switzerland (all means of transport and lines in Switzerland) and in the border area of Switzerland Closed Enabler
queries (according to GA validity area). All stops and connections provided by INFO+ shall be offered.
VBE-329 Route finding "I, as an end customer, would like to be able to find my way from a certain station to another certain station and, if necessary, define via stations. Open Story
without location
Acceptance criteria
* When entering station names (updated at each keystroke), possible values from the list of all UIC-code stations (Switzerland and near-border area according
to INFO+ station list) are suggested
* The sorting of station names is based on a statically defined weighting (basis of entry and exit numbers).
* The autocompletion mechanism does not cause any additional server roundtrips, but takes place exclusively locally on the device.
* It must be ensured that the application has an up-to-date list of stations.
* The autocompletion mechanism allows stations to be found even with slight typing errors (no exact matching).
* The searched part can be anywhere in the station name (e.g. ""mundigen"" in ""Ostermundigen"")
* Via limitation to 5 stations
* Via stations are collapsed by default and must be explicitly activated by the user
* Reuse of autocompletion logic between mobile and online ticket shop
Fig. 2.48 Practical example BLS: Excerpt from product backlog
This makes it promptly recognisable for the scrum team when a user story, feature,
enabler, or epic has been fulfilled for the product owner. The acceptance criteria also
help with testing. Figure 2.48 shows an excerpt from the product backlog with one
epic, feature, enabler, and user story each using BLS as a practical example.
A product backlog does not need to be filled with as many requirements as
possible at the beginning. This would actually even be counterproductive. It is
advisable to keep the product backlog small at the beginning. It should contain the
important requirements. The product backlog ought to contain enough requirements
for at least two to three sprints. Good requirements (user stories) show the INVEST
characteristics according to Table 2.35.
142 2 Methodology
Table 2.35 INVEST features for good requirements

I Independent Requirements should be as independent of each other as possible and have
as few interdependencies as possible
N Negotiable Negotiations can take place between the product owner and the project team
regarding the order, modification, or reduction of requirements
V Valuable Requirements produce a demonstrable benefit
(useful)
E Estimatable The implementation of the requirements can be estimated by the team. This
requires that the requirements are understood by the team
S Small The description of the requirement should be brief
(small)
T Testable All entries in the product backlog are verifiable/can be tested. This requires
the formulation of acceptance criteria for each entry
2.4.4 Release Plan
In the agile approach planning takes place on three levels:
• Release planning: Number of sprints, order in which requirements from the

product backlog are implemented, go-live dates of releases
• Sprint planning: Planning of a sprint, sprint backlog
• Daily scrum: Planning the working day
The release plan is created based on the product backlog. The release plan is
characterized by rough, “coarse-grained” planning, as shown in Table 2.36. Essen-
tially, it determines how many sprints are necessary in order to implement the
requirements and to find out in which order the requirements from the product
backlog should be implemented. In an agile procedure like scrum there is designedly
no detailed planning at the beginning of the project. Detailed planning takes place at
the beginning of each sprint for the duration of the sprint to be planned. The scrum
guide does not suggest release planning. In practice, however, it has proven useful to
carry out rough planning over several sprints.
To create a release plan, the total effort from the product backlog (each entry
should be estimated) and the development speed of the developers (velocity) must be
known. Velocity varies from team to team. Furthermore, the velocity should increase
Table 2.36 Practical example BLS: Release plan

Sprint 4 Sprint 5 Sprint 6 Sprint 7
Back- Timetable Administration After Sales Clearing
End Itinerary VBE Service
App Ticket sales Payment Ticket control After Sales
Service
Webshop Timetable Ticket sales Payment Ticket control
Itinerary
over the course of the project among the developers. The velocity is lower at the
beginning of the project because:
• Knowledge must first be built up or deepened

• Teams must first grow together and find the optimal interaction
• Ideally, the requirements with a high risk are addressed first
• Infrastructure needed at the beginning must be built up first
• Obstacles are more likely to occur at the beginning
The simplest way is for the developers to carry out two to three sprints. The speed
of development is thus measured. Each user story was beforehand approximated
with Story Points. At the end of the sprint, the developers check how many Story
Points have actually been implemented. The sum of the implemented Story Points
then reveals the velocity that the developers apply in a sprint. It is important to
mention that only the user stories approved by the product owner are counted. If a
user story has only been partially implemented or if it still contains an error, no
points are given for these user stories. The motto is “all or nothing”. Only after a
reasonably reliable velocity has been attained can a meaningful release plan be
drawn up, which means that a reasonable release plan can only be created after
two to three sprints.
To create the release plan, it has to furthermore be set how long a sprint lasts. The
sprint length should be constant (timeboxing, Sect. 1.4.1.1) and should be between
1 weeks and 1 month (possibly up to 2 months for hardware). Reasonable exceptions
for a variation are exploration sprints (sprints at the beginning to build up knowl-
edge), release sprints (sprints to deliver a result or partial result), or holiday periods.
The release plan is created in the following steps. One has to:
• Determine the required timeframe based on the total effort of the product backlog
and the velocity.
• Determine the order in which the requirements are implemented, based on the
prioritisation in the product backlog and an equal distribution of effort across all
of the individual sprints.
• Set an objective per sprint, noting that each sprint delivers a conveyable product
increment.
• Determine when the result or a partial result is to be released.
The release plan serves to optimise customer satisfaction and value creation. The
responsibility for creating the release plan lies with the product owner. The product
owner is often supported by the scrum team.
2.4.5 Requirements Specification: Solution Concept
The specifications result from the sum of all solution concepts and describe how the
needed objectives and requirements are to be achieved.
144 2 Methodology
Table 2.37 Project objectives, requirements specification, and functional specification

Term Explanation Question Responsible
Project What is the scope/the aim of Project owner
objectives the project?
Specifications Catalogue of What can the product do? Requirements
requirements engineering
Specifications Sum of the solution How is this achieved? Contractor, project
concepts team
If the objectives and requirements are formulated in a solution-neutral way, they

allow for various implementation options and give the project team a high degree of
freedom in selecting the most suitable solution variant. Table 2.37 shows the
different issues in the objectives, requirements, and specifications.
In traditional project management, a complete set of requirements is assumed in
order to develop the specifications. Subsequent changes to the requirements, i.e. to
the specifications, can lead to completely different solutions with considerable costs
and scheduling consequences. For example, the subsequent change of the tolerance
from 0.1 to 0.08 mm can mean that a completely new production technology has to
first be developed and introduced in order to be able to manufacture this product line.
This additional requirement can double the project duration and costs or cause the
entire project to fail.
In practice, terms used synonymously for the functional specification include
overall system specification, target concept, technical specification, and system
specification.
2.4.6 Effort Estimation
In the traditional approach, the project manager is responsible for the planning
(planning procedure, method, tools, plausibility test). For the effort estimation he
will involve the project group for the following reasons:
• The whole project group together has more necessary interdisciplinary expertise
than the project manager as a generalist. This results in there then being better
estimates.
• With joint planning, the sub-project managers are better informed. This also
increases their motivation and willingness to take responsibility for their
activities.
• In practice, it has proven useful for the sub-project managers or the project staff to
approximate the effort of their work packages and activities and then consolidate
it with the project manager.
In the agile approach, the scrum team is responsible for carrying out the effort
estimation. The product backlog entries are estimated entries and, during sprint
planning, the identified activities. Ideally, the project group is guided by the follow-
ing credo whilst making their calculations:
" Counting before calculating before expert opinions
The reason for this recommendation is the decreasing accuracy of the estimation
methodology.
2.4.6.1 Importance of Effort Estimation in the Traditional Approach

In the traditional approach, the effort estimate is the basis for calculating the project
duration (scheduling) and the project costs. The company asks itself whether the
project should be realised, whether the funds are available in the time span set aside
for this, whether the project is economical, or which investment, when there are
several possibilities at hand is the best to secure the future. The quality of the
decisions thus depends on the accuracy of the effort estimate. For companies that
have to make binding price offers to their clients, e.g. in engineering or architecture,
a very accurate effort estimate is necessary and vital to avoid losses.
From this point of view, effort estimation and the associated uncertainty are of
great importance. Making a useful effort estimate requires experience, care, and
preparation.
Basic options for effort estimation are:
• Experience and analogy through comparison of deliverables or work packages

with similar tasks already realised (empirical values from similar projects)
• An analytical procedure of breaking down the task into individual, clear activities
or functions, estimating the effort
• Combining these possibilities
Many estimation procedures are based on empirical values. These have to be

systematically built up by evaluating many projects at the end of the project over a
longer period of time. The deliverables or work packages need to be clearly
structured and delimited. From the analysis of the actual values of completed
projects, adjusted effort values as well as influencing factors for the future are to
be worked out. Possible influencing factors are: Scope and complexity of the task,
experience of those carrying out the work, acceptance by those affected, available
infrastructure, applicable regulations, etc. Only the most important influencing
factors then get selected. These characteristic values are only valid for the company
and the project type for which they were evaluated.
A company must select an estimation procedure and adapt it to its circumstances.
In order for them to be applicable across an entire organisational unit in the
company, the definitions and delimitations of the deliverables and work packages
and their contents have to be uniformly defined, interpreted, and handled. Empirical
values cannot be adopted that are invisible to others.
146 2 Methodology
In many procedures, a correlation is empirically sought between one or more

variables in the project (e.g. result variables, customer requirements) and the time
necessary for this in person-months. The correlation can be presented as a formula or
graph. Examples of variables: Performance or accuracy of a plant, volume of a
construction, number of processing or function points in a software. If the customer’s
requirements are used as an independent variable, these methods can already be used
in the early phases of the project (e.g. for the preparation of offers), before the exact
solution is known in detail.
2.4.6.2 Planning Poker, Story Points

The estimation method with story points is a frequently used method in the agile
approach. It is a modernised and optimised further development of the Delphi
method according to gamification aspects. The project team estimates a size for
each user story (or requirement, or building block). Cards with the values 0, 0.5, 1, 2,
3, 5, 8, 13, 20, 40 or with 100, based on the Fibonacci numbers, are used. After the
user story has been presented, each member of the project team approximates the
effort and places the card face down on the table. Once all members have given their
estimates, the cards are turned face up and compared. If the estimates do not match,
the members with the highest and lowest estimate briefly justify their estimate. Then
there are further rounds of estimation and discussion until a consensus is reached.
The number of story points for the implementation of a user story says nothing
about the effective effort. As soon as the project team is working, an empirical value
can be formed of how many story points can be realised by the team in a sprint. The
speed of implementation (velocity) in the team increases with each sprint.
2.4.6.3 T-Shirt Sizing

Often it is difficult to estimate the exact effort needed at an early stage of the project,
a stage during which marketing or sales staff often have to make decisions on the
project scope. However, an engineer is not able to provide a perfect calculation
without there being defined specifications. To resolve this dilemma, it is advisable to
make people aware that estimated figures accurate to the millimetre are not necessary
in an early phase.
In the T-shirt sizing method, the developers classify the size of each requirement
in relation to other requirements into the T-shirt sizes Small, Medium, Large, or
Extra Large. Likewise, the marketing and sales representatives classify the business
value of the requirements using the same scale.
By comparing business value and effort, this simple method can be used to have
qualified discussions about project scope. Example: I would like to have requirement
A implemented, as this represents a business value of Extra Large and can be
implemented with an effort of Medium. In return, I will forego requirement B
because the effort is Large and the business value was only estimated as Small.
2.4.6.4 Multiplier Method

The task to be realised is broken down into small, manageable units for which the
effort is known. Or it is tried out on an example: Number of modules, number of
pages, number of graphics. The effort per unit multiplied by the number of units adds
up to the total effort for all types of units.
2.4.6.5 Percentage Method

The percentage method gives empirical values for the percentages of the total effort
for each phase. The percentages per phase are highly dependent on the project type
and the company. A phase is estimated and realised in detail. When this phase is
completed, it is used to draw conclusions for the whole project. Caution is advisable
if the entire project is to be inferred from a first small project phase with little effort.
However, the procedure is well suited as a plausibility test for checking estimated
values that were developed in another way. The empirical values or key figures must
come from projects that were developed under comparable framework conditions
(e.g. same infrastructure, same corporate culture).
2.4.6.6 Analogy Method

When estimating effort using the analogy method, the work packages, tasks, or
features of the project to be estimated are listed and compared with actual values
from similar or identical work units from previous projects. Correction factors can be
used to make situational adjustments. The better the match between the reference
base and the object of estimation and the higher the expertise of the estimators, the
more precise the estimate will be. Figure 2.49 shows the use of the analogy method.
Previous projects (actual values) Project to be estimated
Project A Project C
Feature list: Feature list:

Feature 1 10 h Feature 1 10 h
Feature 2 15 h Feature 2 15 h
Feature 3 23 h Feature 3 ?h
... Feature 4 15 h
Feature 5 23 h
...
Project B
Feature list:
Feature 11 10 h
Feature 12 15 h
Feature 13 23 h
...
Fig. 2.49 Effort estimation by analogy method

148 2 Methodology
It is particularly well-suited for standard projects, e.g. for the preparation of

quotations for modular overall systems (see also Sect. 2.8.2).
2.4.6.7 Expert Estimation (Delphi Method)

At the risk of great uncertainty about the effort estimate, expert surveys are nonethe-
less common. The Delphi method interviews several experts independently of each
other. The different estimates are presented to all of them anonymously. In further
rounds, the experts use the opportunity to make their arguments known and to then
still adjust their values before a group opinion is formulated.
Another expedient procedure is the estimation meeting. Here, all the
implementing specialists come together well-prepared and state their values and
arguments. This creates a welcome group dynamic process, which is moderated by
the project manager. The aim of an estimation meeting is to have a consolidated
estimate at the end, in which the specialists reach a consensus.
2.4.6.8 PERT (Programme Evaluation and Review Technique)

For projects with a high degree of uncertainty (e.g. pioneer projects, acceptance
projects, research projects), the dispersion can also be taken into account. In this
case, a probable time expenditure pT (most frequent case) is estimated for each work
package and additionally a minimum time expenditure MinT (optimistic, most
favourable case) as well as a maximum time expenditure MaxT (pessimistic esti-
mate, most unfavourable case). The planning is continued with a single planned
value:
Planning value = ðMinT þ 4 × pT þ MaxTÞ=6
2.4.6.9 Reserves
Already even with medium-sized projects, in terms of the number of deliverables
and work packages, statistical equalisation has a favourable effect on the deviation in
the total effort, provided there is no systematic error in the individual estimates. Even
when there is careful planning, unforeseen events can occur, effort items are
forgotten, small changes are made, or the effort that needs to be made is
underestimated, which is why a project needs project reserves in the form of
money or time reserves, for instance. The project manager has these project reserves
at his disposal. If a project team member has an overrun in his deliverables or work
packages that he can no longer absorb within his own deliverable or work package,
he informs the project manager. In this way, the project manager controls the use of
the project reserve and can adjust his goodwill towards desirable changes to the
situation. If no project reserves may be created in a company, the project manager
should consider creating hidden or undisclosed reserves.
2.4.6.10 Typical Errors in Effort Estimation

Efforts estimating expenses are always associated with uncertainties. There are
always traditional errors in the estimation of expenses that occur due to:
• Changing scope of functions

• Forgotten activities
• Unfounded optimism
• Chaotic development process
• Subjectivity
• Off-the-cuff estimates
• Unjustified precision
• Business areas or technologies that are not very familiar
• Incorrect conversion of estimated time into project time (e.g. project team works
8 hours a day, 5 days a week)
2.4.7 Schedule and Timetable
2.4.7.1 Create Procedure and Schedule

The content of the deliverables and work packages is now further detailed and
recorded in its entirety in an activity list. All activities to be carried out,
i.e. everything that takes time or money, including milestone review, is chronologi-
cally listed omitting nothing as far as that is possible. Each activity is given a unique
identification number as shown in Fig. 2.50.
Tasks and deadlines Date:

No Tasks Res- Pre- Dura- Scheduling / Gantt chart
Measures pon- condi- tion
Processes sible tion (weeks)
1 2 3 4 5 6 7 8 9 10 11 12 13 14
1 Project
2 Phase 1
3 Task A MM - 6
4 Task B MM 3 1
5 Task D PP - 2
6 Task E PP 5 3
7 Task C MM 3;6 2
8 Task F TT 7 3
9 Task G MM 8 1
10 Preparation MS PL 4;9 1
11 MS-Decision AG 10 0
12 Phase 2
13 Workpackage H MM
Fig. 2.50 Exemplary activity list with bar chart (Gantt chart)
150 2 Methodology
Thus, for each activity, the executing agency or the responsible department is
entered, as far as known. The executing agency must have the necessary expertise for
the activity and have sufficient free capacity at the scheduled time. In the case of
bottleneck resources, availability should be taken into account as soon as it is
roughly known.
The subject matter expert estimates the time and lead time required to solve the
problem. Time required is the amount of time in person months, -weeks, -days, or
-hours required by the task owner to fully complete all tasks associated with the work
package, taking into account the resources expected to be used.
The lead time (duration) is the shortest time necessary to achieve the previously
defined effort, taking into account the availability of bottleneck resources, unavoid-
able waiting times, and other general conditions. Example: A painter needs four
hours to prepare and spray a bathtub. Then the tub needs 72 h of drying time until the
next work step is possible. The painter needs another four hours for sanding the
bathtub. The time required for the painter’s work is therefore eight hours, but the
turnaround time is 4 days.
Then the sequence of activities is determined that makes the most sense or that is
necessary from a work point of view. For each activity, the questions must be
answered: What results must be available? Which general conditions must be
fulfilled so that the activity can be started? These time dependencies are entered in
the activity list as preconditions. With this information, scheduling can then take
place.
2.4.7.2 Termination, Critical Path, and Slack

Scheduling can be carried out using the bar chart technique (Gantt chart). Scheduling
provides the final date and also the intermediate dates of the project, taking into
account the dependencies. The scheduling process results in an earliest and a latest
start and end date for each activity. The earliest finish date indicates when an activity
can be completed at the earliest, if all conditions are fulfilled as best as possible. The
latest end date indicates when the activity must be completed at the latest so that the
project is not delayed.
If the latest and earliest dates of two consecutive activities are different, the
preceding activity has time leeway (slack, buffer). The slack is the time by which
an activity may be delayed without this having an effect on the final deadline. The
critical path is the connection of all activities that have no slack. It also determines
the end date. If an activity is delayed along this path, the end date of the project is
then postponed by the extent of this delay. In order for the project manager to be able
to take early action if necessary, he must check the activities on the critical path
regularly and at sensible intervals.
The Gantt chart shows the earliest possible start, the earliest possible end date,
and the latest possible end date for each activity in a compact and clear presentation.
Duration, slack, temporal relation of the individual activities and the dependencies
on each other are clearly visible, as Fig. 2.51 shows.
Activities
Critical path
Slack
10
11
1 2 3 4 5 6 7 8 9 10 11 12 13 Time
Fig. 2.51 Bar chart with critical path and slack
Figure 2.52 shows an excerpt from the process and schedule in two levels of
detail based on the practical example from Metrohm. The picture also shows the
on-going exchange between the project and the system architecture.
2.4.7.3 Accuracy in the Process and Scheduling

How precisely should one plan deadlines, resources, and costs? Does the project
management have a better grip on the project the more precisely it makes plans?
Any planning constitutes a hypothesis made about the future. In some projects,
especially those that are highly dynamic, the future reality will often be different
from prior ideas about it. It is therefore worthwhile to assess the project dynamics:
can a relatively smooth course of events for the project be expected, is there a high
degree of certainty about the individual events and activities, or must uncertainties,
many changes and surprises be expected? Examples: In the case of a “normal”
single-family house on a problem-free plot of land, the individual planning and
realisation steps have been tried and tested and can be planned with relative certainty
until commissioning. This is a standard project (see Sect. 1.2.1). Detailed planning is
very helpful here in order to be able to meet deadlines and costs. In the development
of a new product or software, where new findings change the situation after each step
or where new impulses flow in from the environment, precise planning would be an
obstacle, acting like a rail of fixed expectations that one wants to fulfil to as high a
degree as possible. Iterations or learning loops are thus made more difficult, new
152 2 Methodology
Fig. 2.52 Practical example Metrohm: Procedure and schedule
ideas are blocked out. In this case, it is more appropriate to plan for milestones or
fixed deadlines in order to be able to use flexible planning and controlling
instruments like kanban in between. It would be even better to handle a project of
this type using the agile approach. Figure 2.53 shows that the estimation accuracy
improves in the course of the project.
2.4.7.4 Procedures for Planning

During the planning stage, one often starts from specifications (e.g. completion date)
and subdivides the work steps needed more and more finely down to individual
activities, the efforts of which can be assessed. At this level, detailed scheduling,
resource, and cost planning are carried out. The results are presented in condensed
form and compared with the specifications, see Fig. 2.54. If there are deviations, the
project manager looks for solutions to meet the specifications. If the deviations are so
great that one has to see these as unrealistic specifications, or if priorities have to be
set between deadlines, resources, and costs, the project manager needs to discuss this
with the project owner.
According to the management concept of MbO (Management by Objectives, see
Sect. 4.6.1), this process of specification (top-down) and alignment (bottom-up)
must necessarily take place. If the person carrying out the work has no say (bottom-
up), it will also be difficult to obtain co-responsibility for the realisation. In self-
Commissioning Initialisation Concept Realisation Introduction
Project request Project order Technical specification
1. Rough 2. Rough 3. Detailed

estimate planning planning
+50%
+10%
-10%
-50%
Accuracy of estimation e.g. similar projects (already carried out)
Accuracy of estimation e.g. pioneer projects (new territory)
Fig. 2.53 Estimation accuracy
Requirements Adjust deviations

Top-down: break down requirements
Bottom-Up: Consolidate detailed plans
Management
Project Management
Work Level
Detailed planning
– Time planning
– Cost planning
– Resource planning
– Resource leveling
Fig. 2.54 Planning top-down and compaction bottom-up

154 2 Methodology
organised teams, other leadership concepts than MbO exist today. Three approaches
are common for planning a project:
• At the beginning of the project, the whole project duration is planned in detail
• At the beginning of the project the whole project is roughly planned and at the end
of one phase the next phase is planned in detail
• At the beginning of the project, the whole project is roughly planned and every
month the immediate future (deliverables, work packages, and activities) is
planned in great detail
If a lot of experience with similar projects is available or fixed price quotations

have to be submitted, the entire project gets planned in full detail and over its entire
duration. This involves a great deal of effort. If there is a lack of useful experience or
if the assignment is open and completely new, only rough planning for the whole
project with a rough estimate of the costs is made in the initialisation phase for the
entire project, with a rough estimate of the effort and resource requirements. The
concept phase, on the other hand, is planned in detail. Rough estimates should
always be given within a range, e.g. +40/–20%. This procedure is very efficient
and often used.
For large projects, it is advantageous to plan in several steps to make the project
manageable. First level of detail: a process and schedule planning for deliverables
and work packages as a project overview. In a next step, the level of detail is
increased to activities, possibly by the sub-project managers. The planning depth
should be adapted to the level of knowledge and the consequences if deviations from
the planning occur.
If the degree of innovation is high and the deadline is critical, the level of detail of
the deliverables and work packages is increased step by step. At the beginning, the
project is divided into a few rough deliverables and work packages, but the entire
planning horizon is covered. As the level of knowledge increases, a manageable part
of the project is detailed even more. In a further step, the immediate future, e.g. 2
months, is planned in great detail. This step then gets repeated every month.
In large projects, planning consists of several steps. The project manager makes a
first draft. If the lead times are too long or not compatible with the specifications, he
carries out an initial optimisation. If there are resource conflicts, negotiations are held
with the resource managers and binding agreements are reached. The initial planning
is now frozen and approval is given by the project owner. If the framework
conditions change later (e.g. priorities of the management), adjustments become
necessary. In the case of major changes, it may be necessary to reschedule the
remaining tasks (time-to-complete and cost-to-complete).
2.4.7.5 Adherence to Deadlines and Capacity Planning

Depending on the objective, planning in the project is carried out on schedule or on
capacity, as Fig. 2.55 shows.
If the final deadline has a high priority, we plan on schedule. How do we have to
proceed? What resources do we have to use? What measures need to be taken to
Capacity (FTE)
…results in required capacity
1.0
fixed deadline
Time-oriented planning
The work package A (200
working hours) must be
completed in 5 weeks
fixed capacity
…results in required time

0.5
Capacity-oriented planning
The work package A (200 wor-
king hours) obtains a capacity
of 0.5 FTE
Time
5 weeks 10 weeks (weeks)
Fig. 2.55 Resource histogram
make sure this deadline is met? How substantial is the overload at that point and how
long will it last? Do the costs or other projects have higher priority, is planning in line
with capacity? What is the deadline depending on the available resources?
Forward Scheduling
Scheduling from project starts to project completion. If the deadline is exceeded,
measures of adapting to this event have to be examined (more resources,
parallelisation, infrastructure improvement, externalisation of subtasks, reviewing
the objective, etc.). Forward scheduling with possibilities of correction is the most
common approach.
Backward Scheduling
Starting from the required end date, scheduling is done backwards in order to be able
to answer the question: When do we have to start so that the deadline is reached? If
the start date is in the past, the time until the planned date can be split into parts in
proportion to the ideally required lead times—and used as orientation.
Adjustments to the Planning

In the initialisation phase, initial planning was prepared and released. At the
milestones, critical questions are asked and the situation is reassessed: Are the
assumptions made in the initial planning phase still applicable in full? Have new
156 2 Methodology
general conditions arisen? If necessary, the existing planning with regard to

resources, deadlines, and costs has to be modified accordingly. This may also
mean that new agreements have to be made. Changes to project planning need to
be documented and communicated to those affected.
If absolutely new framework conditions arise or new knowledge is gained to such
an extent that the previous planning is no longer suitable as a basis for a comparison
of planned/actual data because the content and delimitation of the deliverables and
work packages have changed significantly since the initial planning, then a cut has to
be made in the planning at the current project status and a new planning prepared
from that point on (time-to-complete and cost-to-complete). Any new resource
conflicts that have arisen due to the new situation are required to be resolved.
2.4.7.6 How Detailed Should a Plan Be?

The level of detail is oriented towards the purpose. The planning should be detailed
to such a degree that we are able to derive the necessary measures from it and reliably
monitor and control the project. The planning must be at least as detailed as we
would like to have it when controlling it later. If control is to take place at shorter
intervals so that problems can be addressed early on, the tasks must need to be
broken down more finely. The quality (accuracy, completeness) of the data is more
important than the level of detail. The level of detail should not be chosen to be
higher than necessary because then the corresponding effort for planning and control
quickly becomes very large.
2.4.7.7 Further Planning Variants: Target Costing, Design-to-Cost

In a price-sensitive environment, the costs of the result from the project (e.g. the
manufacturing costs of the product) are more important than the “one-off” costs of
the project. The product costs are mainly determined in the definition and develop-
ment phase and can only be influenced to a very limited extent in later project phases.
This results in a special responsibility of the project manager and the developer for
compliance with the cost objectives agreed in the requirements catalogue.
When defining target costs, a maximum value is set for how high the
manufacturing costs of the product is allowed to be (target costing) and may be
included as a binding value in the objectives. The project manager monitors compli-
ance with this manufacturing cost budget.
From the customer’s point of view, the operating, training, maintenance, and
disposal costs incurred during use are relevant in addition to the acquisition costs. He
is interested in low total costs (life-cycle-costs). The project manager should prefer
solutions that aim at low total costs, as long as this does not excessively increase the
manufacturing costs and project costs, unless, of course, the customer accepts these.
At the price of higher project costs, manufacturing costs can be further reduced.
The break-even analysis helps to illustrate the relationship between project costs and
manufacturing costs for a forecast sales quantity. It also shows the effects if the
planned number of units cannot be sold on the market, see Fig. 2.56.
Costs
Variable costs 1
Variable costs 2
Break-even
Fixed costs 2
Fixed costs 1
Quantity
N
Fig. 2.56 Break-even analysis
2.4.8 Resource Deployment Plan and Resource Coordination
In the traditional approach, resource planning can be derived from the process and
schedule. A prerequisite for this is the coordination of the required resources in the
project with the available resources in the line. In practice, failure to coordinate
resources is often the cause of problems in demanding multi-project environments.
2.4.8.1 Resource Planning in the Project: Line and Project Manager

as Partners
The project manager is responsible for project planning. With process planning and
scheduling, he plans what is to be done and when it is to be done (Fig. 2.57). At the
time of planning, the availability of resources is not yet guaranteed.
Once the schedule is available, the resource input has to be planned. The resource
utilisation plan of a project contains the planning data of at least all bottleneck
resources involved in the project. The project manager is responsible for resource
planning together with the line managers or an assigned resource coordinator.
2.4.8.2 Resource Coordination in Multi-project Management

For resource planning, the project manager and the line managers depend on each
other. The project manager reports his resource needs and wishes to the line
managers. If the required resources are available, they are promised and reserved
158 2 Methodology
Number of persons (FTE)
D E G
B F V
WE 1 2 3 4 5 6 7 8 9 10 11 12 13 Time
Fig. 2.57 Resource allocation plan of a project
in a binding manner. A prerequisite for a binding commitment by the line managers

is that they carry out an updated resource utilisation planning for all projects (see
Sect. 2.7.1.6). If resource conflicts arise because several projects want to access the
same resource at the same time, the project manager and resource managers must
find solutions together and reach agreements.
It is good if the resource manager (often the line manager) is aware that he has a
service responsibility in his field for the benefit of the projects. However, it is also
helpful if the project manager is aware of not always being able to have exactly the
specialist he wants at any given time, and that he must therefore show a certain
degree of flexibility. It is then that the conditions need negotiations to be conducted
in a spirit of partnership between project managers and resource managers.
Figure 2.58 shows the resource alignment of various projects with the line.
Figure 2.59 shows the workload of an employee by basic load and several
projects over time.
If the resulting deadline does not meet the specifications, it is the project
manager’s task to check measures and make corrections. If the timeframe or effort
proves to be unrealistic, the project manager will discuss it with the project owner.
Possible optimisation measures in the event of the planned result happening too
late are:
Project Project
A 21 T 05
Line Management, Resource Manager
Workload % Deployment plan: Marcus Miller
150
Resource F 34 Resource
requirement 100 requirement
D
Resource 17 Resource
requirement requirement
50 A 21 T 05
Base load
0 2 4 6 8 10 12 14 Period
Resource adjustment
Project Project
D 17 F 34
Fig. 2.58 Multi-project planning
Capacity
150%
100%
50%
0%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 Time
Project F 34
Project T 05
Project A 21
Project D 17
Base load
Fig. 2.59 Workload of a project staff member

160 2 Methodology
• Shifts within the buffer time

• Increased parallelisation (first, look for the activity with the greatest potential for
further integration on the critical path. This is usually an activity with a long
duration. Now check the dependencies on subsequent activities with the aim of
bringing forward the dependent activities so that subsequent activities can start
earlier. In this way, the activity under examination is to be divided into two or
more parts and the list of activities extended);
• Use of additional available resources
• Setting of project priorities by the management, whereby individual projects are
given preference to the detriment of others
• Outsourcing of suitable activities or work packages
• Distinction between basic functions and options to be implemented later in
updates.
2.4.9 Cost Plan
With cost planning records all resources used in the project that incur a cost or direct
expenditure of money, such as:
• All internal and external project staff incl. project manager

• Temporary use or rental of special facilities such as rooms, machines,
instruments, and ICT
• External investments for purchases
• Other direct costs such as expenses, fees, and insurances
The time at which costs are incurred depends on the use of resources. A
distinction is made between three types:
• Use and costs evenly distributed over the duration of the activity by charging the
corresponding cost rate
• Use or incurrence of costs at the beginning of the activity, for example as a
pre-investment in acquisitions that will be necessary later on
• Use or incurrence of costs at the end of the activity through invoicing of a service
or acquisition after delivery
Cost planning and budgeting in the project serves the following purposes:
• The company as a capital provider has a basis for providing the financial
resources and can plan its liquidity
• The project owner has a decision-making basis for milestone decisions
• The project manager has an operational monitoring and control tool at his
disposal
To determine the project costs, the costs of each individual activity or resource
item are calculated and totalled over the period of the entire project, see Fig. 2.60.
No. Task Duraon FTE Effort Rate external internal

days days € p.d. cost € cost €
3 Acvity A 30 0.50 15 1’200 18’000
4 Acvity B 5 1.40 7 1’500 10’500
5 Acvity D 10 1.00 10 1’200 12’000
6 Acvity E 15 1.40 21 1’500 31’500
Invest 95’000
7 Acvity C 10 1.50 15 1’200 18’000
8 Acvity F 15 0.80 12 1’833 22’000
9 Acvity G 5 1.60 8 1’500 12’000
10 Prepare MS 5 1.00 5 1’800 9’000
11 MS-Decision 0
Subtotal 117’000 111’000
FTE = Full Time Equivalent Project Cost Total 228’000
Fig. 2.60 Information for cost planning
If the budgeted data from resource and cost planning is overlaid with the schedule
planning, the cost curve is created, showing the course of the cumulative total costs
of the project over the project duration. The cost curve shown in Fig. 2.61 is a useful
tool for making approximations about:
100 250
90
80 200
1'000 € (cumulative)
70
1'000 € (per week)
60 150
50
40 100
30
20 50
10
0 0
1 2 3 4 5 6 7 8 9 10 11 12 13
Time
Internal costs
External costs
Total costs (cumulative)
Fig. 2.61 Cost curve

162 2 Methodology
• Period costs when releasing the individual project phases

• Budget amounts for the individual financial years for the provision of funds
• Liquidity for the required investments
It also provides a basis for a comparison of planned and actual costs.
2.4.10 Information, Communication, and Documentation
Information and communication processes always take place in some form or

another in projects. The question here is: do these “happen” by chance, or are they
configured deliberately? Leaving things to chance involves high risk: project
participants are either not provided with the necessary information or not in a timely
manner. Documents are neither filed nor found. Stakeholders do not feel involved
and resist. Rumours spread.
Information flow and the communication taking place in projects are often seen as
a necessary evil or simply forgotten, because the project management or the project
team is too busy with content-related issues. However, the project management
should be aware that good information and communication are essential factors for
the success of the project and represent a further success factor in stakeholder
management (Sect. 2.3.5). In agile projects, a structured exchange of information
takes place daily via the daily stand-up meeting (Sect. 2.5.3). Information and
communication are addressed internally and externally:
• Internally to the group of project participants: goal-oriented action requires a

high degree of transparency and comprehensive information for the project
participants and comprehensive information. The facts and documents such as
specifications, schedules, and contracts must be accessible to all team members.
• Externally to customers, users, interest groups, and the public: during the
project, the most important thing is to gain acceptance and support. Rumours are
replaced by facts, thus reducing negative influences on the project.
After project completion in the utilisation phase, project documentation must be

available to ensure operation. Information and communication are handled differ-
ently in the project and in the line. In the line hierarchy, communication takes place
via predefined reporting channels. In projects with rather small teams, direct infor-
mation channels that are as short as possible are more suitable. They allow for
flexible and rapid decision-making and better coordination.
2.4.10.1 Principles of Information and Communication

Projects cause changes, fears, illusions, frustration. These can be “processed”
through open communication. Usually, too little information is given or it is
provided too late. Especially in sensitive projects, those potentially affected very
soon notice that “something is going on”. This often gives rise to disconcerting
gossip and diffuses fears, all of which can be very damaging to the project.
Therefore, in most cases it is advisable to provide information at an early stage. Of

course, nothing can be said about the results. But information can be revealed about
what is going on, who is involved, what the project is about, the vision or the goal,
and it can also be said when a first result is to be expected.
One can also inform about processes, not only about contents and solutions.
Delays and difficulties can be made transparent to the outside world. In any case, this
promotes trust more effectively than if information were always given in the most
positive tones or not at all.
Incorrectly prepared information can do more harm than good. Recipients usually
have different interests, questions, or understandings than those involved in the
project. The latter usually make little effort to put themselves in the shoes of the
customers, users, or those affected. It is no coincidence that large projects often hire
communication officers who have a certain outside perspective and can better
recognise the descriptive language used as well as the interests of the recipients.
2.4.10.2 Scope of an Information and Communication System

The whole system of project information and project communication can be
structured as follows:
• Oral communication in conversations, meetings, problem-solving, and content-

related cooperation at workshops
• Reporting: minutes, progress reports, amendments, etc.
• Project documentation: project manual, project-related files, content-related
documents such as concepts or instructions
• Project marketing to create trust and acceptance through information events,
in-house posters, presentations, lobbying, etc.
• Cooperation tools to collaborate and share plans, documents, backlogs, etc.
Not all components have to be equally important in a project. For example, in a

research project the keeping of a diary can be important for continuous data
collection, while hardly any marketing needs to be done. In a change project, on
the other hand, oral communication and marketing are important.
Since the communication concept practically always has to be reinvented for each
project, it is worthwhile for standard projects to standardise the corresponding
reporting channels, checklists, documentation principles in project management
guidelines and to provide corresponding templates.
The totality of information and communication can be represented in a commu-
nication matrix as shown in Table 2.38.
The so-called W-questions can be helpful in creating the communication matrix:
• Who is the sender? Who informs? It can often make a considerable difference
whether the project management or the CEO informs!
• Who does the project need? Who are the beneficiaries?
• What is the subject of the information? What is the objective? What is the
message?
164 2 Methodology
Table 2.38 Communication matrix

Characteristics, Responsible Date,
information type person, reporter Distributors, participants frequency
Oral information
Project status Product owner, Stakeholder According to
(presentation) project need
manager
Project committee Team, project Project committee, internal As needed,
meeting, Sprint review manager stakeholders at end of
sprint
Project meeting, Daily Scrum master, Project team Weekly,
stand-up meeting project daily
manager
Written information
Project status report Project Project committee, portfolio Monthly,
manager, management, internal quarterly
product owner stakeholders
Phase completion report, Project Project committee According to
project completion report manager, need
product owner
• When and in which periodicity is information provided and announced?

• How is information provided, in what form, with what media e.g. paper, mail,
notice board, scrum board, in-house newspaper, etc.? What method is used to
inform? How should feedback be obtained?
• Where and in what framework should the information be conveyed, the debate
conducted?
• How far, to which degree should the information be made accessible to serve as
a working platform for the spatially separated project staff, e.g. homepage,
intranet?
2.4.11 Quality Management
Quality management ensures that the results produced meet the requirements in that
regard during the course of the project. For this purpose, a corresponding process
must be established in the project. In addition, an understanding of what quality
entails has to be created among all members of the project staff.
Quality is relative and depends on the requirements of the project owner. The
demands on the quality level to be achieved can vary greatly. The project is not about
achieving the highest possible quality level, but rather simply about just the required
level. The quality objectives for the project can be derived and defined from the
requirements. In quality assurance, a distinction is often made between checking and
testing:
• Check: Check documents and compliance with agreed-upon processes and tasks
in terms of content and form.
• Testing: Checking the fulfilment of the requirements and the applicability of the
processes on the developed product, system, or plant.
Review
Procedures such as consultations, audits or reviews are suitable or reviews. This
means that the review is to be carried out by affected stakeholders or experts. The
aim is to find out whether the required quality has been achieved or whether a
concept or an architectural sketch serves to achieve the set project objectives. Any
defects or deficiencies found are recorded in a list of findings or in an inspection
report and returned to the project team for further processing. In many cases, the
auditor also makes a recommendation on how best to remedy adverse findings.
Testing
Before testing, it is advisable to develop a test concept. A test concept describes the
test objects, test methods, and the test infrastructure. It is also advisable to record test
objectives and the test organisation. In addition to the test concept, test cases and a
test plan are developed in practice: Who tests what and when? The test cases can be
built using Office applications or in a comprehensive test suite (software). The use of
a test suite has the advantage that the errors found can be recorded and tracked until
they are completely eliminated and tested again. With a test suite, evaluations of test
progress and test success can also be made. By carrying out the tests, the fulfilment
of the set requirements is checked. Any errors found are recorded. At the end of a test
sequence, a test protocol is created.
Quality Management Plan

Quality planning involves defining all those inspection and test measures that are
made necessary by regulations, good practice, and the company’s quality
requirements in order to ensure the quality objectives of the project or product. In
the quality plan, all defined and economically justifiable measures are listed, namely
by when they will be carried out and who is responsible for them. In large projects,
these measures are recorded in a separate quality plan. In small projects, this
information can be integrated into another planning document, e.g. the process and
schedule plan.
Examples of Measures in the Quality Plan

• Document verification
• Test of the finished product, intermediate tests
• Testing in the customer’s operating environment, qualification test, conformity
test, homologation, clinical tests, approval tests
• Design reviews, design verification, design validation
• Value engineering, value analysis, reliability analysis
• Special tests: Integration test, safety tests
• Pre-treatments (endurance test, burn-in, etc.)
166 2 Methodology
• Environmental tests, climate test, shake test, drop test

• Corrosion test, test for chemical residues, test of flammability
• Electromagnetic compatibility, interference radiation
• Prototype, pilot series
For economic reasons, only measures which are necessary in terms of the subject
matter and economically justifiable may be defined and implemented.
2.4.12 Checklist Completion Concept Phase
• Are there changes compared to the initialisation with regard to objectives,

system boundaries, and their design? Are these justified? What are the
consequences?
• How were the desired changes taken into account in the project plan?
• Are the estimates of quantities, frequencies, and dates concrete enough to
be implemented?
• Has the assessment of the risks been checked against the findings of the
concept phase? Have the necessary measures been defined and the actions
prepared?
• Is the economic viability of the project still provable at the present time?
What is the overall economic viability of the project?
• Has the procedure for the realisation phase been coordinated with all those
involved?
• Are competences and responsibilities regulated according to the
requirements?
• How are the guidelines for project controlling and reporting adhered to?
• Are the planning documents complete, or is at least completion specifically
planned?
• Is there a concept of who informs whom about the project and how?
• Is there an idea of the form in which the project should be documented?
• Is there clarity about who will maintain the future solution? Do those
responsible know at what stage and time they will take responsibility for
the outcome of the project?
• Specific points of the traditional approach
• Have alternative solutions been developed and evaluated?
• Have all possible solutions been identified?
• Are the advantages and disadvantages of the variants and their risks clearly
discernible?
(continued)
2.5 Realisation Phase 167
• Has a variant with plans ready for implementation been selected?

• Has the chosen solution been worked out in detail with the necessary
solution concepts?
• Were effort, resources, and deadlines planned completely and realistically
in detail? Has a plausibility test been carried out?
• Are the financial resources and liquidity secured for the entire duration of
the project?
• Is the availability of the required financial and human resources assured?
• Is the necessary knowledge available? Are the appropriate resources
assured?
• Specific points of the agile approach
• Has the product goal (product concept) been clarified and the vision
defined?
• Has a first version of the product backlog been developed?
• Are the entries in the product backlog prioritised and estimated?
• Has the release plan been defined?
• Are the entries prioritised?
2.5 Realisation Phase
In the traditional approach, the plans from the concept phase are accomplished in
the realisation phase. Comprehensive on-going review and control help to keep the
project on track and achieve the desired goal.
In the agile approach, external monitoring of the plans is no longer necessary.
Due to the self-organisation of the teams, control takes place within the team. The
detailed conception is made for each sprint and implemented directly. This makes it
possible to respond flexibly to changed wishes or framework conditions.
2.5.1 What Is Important in the Realisation Phase?
Steps of This Phase

Table 2.39 shows the most important steps in the agile and in the traditional
approach for the realisation phase.
Results of the Realisation Phase

In the realisation phase, the results according to Table 2.40 are of importance.
People and Team

In the realisation phase, the composition of the team can change again, which means
that all the aspects listed in the concept phase can be relevant again (Sect. 2.4.1). In
addition, the introduction is already to be planned.
168 2 Methodology
Table 2.39 Steps of the realisation phase

Most important steps • Concretise the solution and • Provide material, human, and
realise it iteratively financial resources
• On-going realisation of • Produce and test solution
improvements to the product • Plan training for future users
and in the cooperation of the • Steering the project process
team • Carry out plan-actual
• Plan training for future users comparisons (financial
• Conduct project marketing, management, controlling)
i.e. inform stakeholders and • Communicate deviations
external bodies (e.g. clients). • Conduct project marketing,
i.e. inform stakeholders and
external bodies (e.g. clients)
What should be paid • Focus on the solution to be implemented. Avoid delays
particular attention to in • In the agile approach, continuous learning and improvement
the implementation are institutionalised. Successful project managers consistently
phase? apply the principles of continuous improvement in the traditional
approach as well
Table 2.40 Results of the realisation phase

Principle The solution or system is built and tested. In order for the project to be completed,
the following objectives have to be achieved at the end of the realisation phase:
• The system, the product, the service have been procured or created
• The solution has been tested and approved
• The results are used as soon as the users are empowered to do so
Process- The iterative development is based on The project management puts
oriented current priorities. The solution to be controlling in the foreground: it
results realised is continuously adapted to the communicates the project status
latest needs compared to the planning as well as
• Current product backlog the planned changes. Since there are
• Sprint planning often many project participants in this
• Offers, contracts, settlements phase, systematic information and
• Phases, review report communication is essential
• Project progress reports
• Realisation plans, change documents
• Offers, contracts, settlements
• Quality assessment
• Phases, review report
Content- • Implemented partial solutions • Realised results
oriented (increments) • Test reports
results • Results from the sprint review • Documents for the introduction and
instruction summarised in the
introduction concept
The following measures and competences are important:
• Dynamics in teams (Sect. 5.2): Conflicts and resistance often arise in the team
during this phase. The team can fall back from “performing” into “storming”. The
work on the system (Sect. 1.5.2) and conflict management (Sect. 5.6) remain
important aspects for those responsible for the project.
• Project teams are dependent on constantly adapting their procedures and learning
quickly. To do this, it is essential to be able to give constructive feedback and to
master the questioning techniques (Sect. 3.9).
• Constructive feedback, in turn, is based on a communication culture that is based
on a human image of the “non-trivial system” (Sect. 1.6.3), selective perception
(Sect. 3.3.3) and thus also on making the distinction between evaluation and
effect.
• Success factors of cooperation: project teams that are balanced in their team roles
are more efficient than those with the highest intellect. There needs to be a balance
between team roles. In order for this balance to be transformed into higher
performance, high competences are required in terms of personal communication
(Sect. 3.9), conflict management, or negotiation (Sect. 4.10)
• Every project brings about minor or major changes. Project managers are always
also “change agents”. Changes in turn cause resistance. Attention must now be
paid to planning the introduction and thus to dealing with change and resistance
(Sect. 5.5)
2.5.2 Sprint Planning, Sprint Backlog
The implementation in the agile process according to scrum takes place in iterations.
These iterations are called sprints. Depending on the type of project, the duration of a
sprint is between 2 weeks and 1 month (possibly up to 2 months for hardware). In
practice, sprints most often last 3 or 4 weeks. A sprint should be planned in such a
way that the results can be achieved in a relaxed and focused manner. The scrum
team should still be fresh enough after a sprint to be able to tackle the next sprint in
such a mindset.
Before sprint planning, the product owner makes sure that the product backlog
items are understood by everyone in the scrum team and that they contribute to the
product goal. Sprint planning is done in three steps.
• Step 1: Why is this sprint valuable? (Why)

– The product owner proposes how the value for the product can be increased
and which benefits should be realised in the sprint.
– The scrum team members work out the sprint goal together
• Step 2: What can be accomplished (Done) in the sprint? (What)
– The developers select the product backlog entries to achieve the sprint goal.
– If necessary, a refinement of the product backlog entries takes place in the
scrum team to increase the understanding and confidence for the implementa-
tion in the scrum team.
170 2 Methodology
– The developers can best estimate what can be implemented in a sprint based on
their past performance, their future capacity (e.g. holiday absences), and the
Definition of Done.
• Step 3: How is the selected work done? (How)
– For each selected product backlog entry, the developers plan the necessary
tasks and activities to create the desired increment. This is often broken down
into tasks. These tasks should be able to be completed within 1 day.
– Each task or activity is given an estimate by the developers or the existing
estimate is validated. Different estimation procedures can be used. The
Planning Poker method is often used to estimate the story points.
– The developers check the estimated efforts against the available team capacity.
The developers finally decide which requirements (entries from the product
backlog) will be implemented in the next sprint. In this way, the developers
also make a commitment as to what will be implemented in the sprint.
– The sprint backlog contains all the necessary work required in order to achieve
the definition of done.
The sprint backlog is created from the product backlog during the sprint planning
session. The sprint planning meeting is attended by the product owner, the
developers, and the scrum master. The scrum master moderates the process and
supports the product owner and the developers in the process and in decision-
making.
The sprint backlog is composed of the sprint goal, the selected product backlog
entries, and the implementation plan (tasks from Step 3). The sprint backlog (see
Fig. 2.62) is the list of requirements that will be implemented during the next sprint.
It represents the concrete and verifiable result and serves to achieve the defined sprint
goal.
At the end of a sprint, there is a realised increment. The increment has the
characteristic of an executable product, regardless of whether it is delivered to the
user as a release or not. This means that at the end of the sprint, the requirements
recorded in the sprint backlog have to be implemented, executable, and presentable.
This guarantees that added value is created with each sprint. In the first sprints of a
new project, concepts, architectures or functioning working environments can also
be created as increments. However, by the third or fourth sprint at the latest,
functioning partial results of the product to be realised should be created. Sprint
planning takes 8 h at the most for a 1-month sprint.
The sprint backlog can be kept in a tool. The best way to do this is to use cards on
a wall, the so-called kanban board. A card is created for each task. The kanban
board contains the following five areas, for example:
• Task (To Do)

• In Progress
• Developed
• Examination (review)
• Done
Fig. 2.62 Practical example BLS: Sprint Backlogs
The kanban board can be supplemented by other areas: ideas, backlog, specifica-
tion, integration, delivery, etc. This creates transparency and the flow of work gets
visualised as a process. This increases the scrum team’s sense of responsibility.
Figure 2.63 shows a kanban board that is managed in a tool.
Fig. 2.63 Practical example BLS: Scrum board (Kanban board)

172 2 Methodology
2.5.3 Sprint Implementation, Daily Scrum
If the sprint is planned and the sprint backlog is created, the sprint begins. The length
of the sprint was beforehand determined during release planning with a fixed
duration.
During the sprint, the scrum team implements the requirements defined in the
sprint backlog. If new requests or changes arise during the sprint, these are included
in the product backlog. The sprint backlog is neither changed nor adapted during
the sprint. This ensures that the scrum team works on defined topics for a fixed
duration. This increases efficiency; and the scrum team is not distracted by new
needs or changes.
The responsibility for the implementation of the sprint lies with the scrum team.
The scrum team works in a self-organised manner and adheres to the defined
agreements of the agile approach. The developers ensure the required quality and
the achievement of the Definition of Done.
The daily scrum (Daily stand-up meeting), as the name says, takes place every
day. The focus lies on the daily adaptation of the implementation plan by the
developers in order to achieve the sprint goal. If necessary, the product owner and
the scrum master also take part in this meeting. This meeting is not conducted sitting
down, it is rather done standing, preferably directly at the kanban board with the
sprint backlog. The daily scrum should be of short duration (max. 15 min). Each
participant answers the following three questions:
• What have I done and achieved since the last daily scrum?
• What will I do before the next daily scrum?
• What problems or ambiguities have I encountered?
However, the developers are free to adapt the structure and technique of the daily
scrum. The sprint backlog on the kanban board can be updated during the daily
scrum.
No problems are to be discussed nor are solutions worked out at the daily scrum.
It is purely a position and planning meeting. A high degree of transparency is to be
achieved. It is clear to every participant who is working on what and who has
achieved what. This transparency also motivates each individual team member to
take a step forward every day and realise something. This also creates a clear focus
on the sprint goal. Problems should be solved in a small circle.
Furthermore, the sprint progress ought to also be checked at the daily scrum by
means of a sprint burndown chart. The sprint burndown chart looks at how the
efforts in the sprint backlog develop from day to day, as Fig. 2.64 shows.
The vertical axis shows the cumulative number of efforts contained in the sprint
backlog. The horizontal axis is for the number of working days. The ideal burndown
(linear line from top left to bottom right) shows the effort that needs to be made from
day to day to reach the sprint goal. At the beginning, the real burndown will lag
behind the ideal line, though it should approach it in the course of the sprint.
Story Points
Remaining Story Points

Burndown ideal
Time
1. June 3. June 5. June 7. June
Fig. 2.64 Example: Sprint Burndown Chart
The product backlog is a dynamic list that continuously gets adapted to the latest
findings and needs. If details are added to entries, estimates are made, or the order of
the entries in the product backlog is determined, this is called refinement of the
product backlog, often also called refinement or grooming. Refinement is a contin-
uous process in which the product owner and developers work together to detail the
product backlog entries. During the refinement of the product backlog, the entries are
reviewed and revised. The scrum team determines when and how this work of
refinement is done. However, the product owner can update the entries in the product
backlog or have them updated at any time.
2.5.4 Sprint Review
The sprint review takes place at the end of a sprint; during these occasions, the
developers show what they have accomplished in the previous sprint. The
developers make a presentation and demonstration of the realised increment.
During the sprint review, together with the product owner, it is clarified to what
extent the sprint goal and the requirements defined in the sprint backlog have been
achieved. It is up to the product owner to decide whether a requirement has been
fulfilled or not. Only requirements that have been implemented 100% are considered
to have been fulfilled. If only 80–90% of a requirement has been implemented, it is
174 2 Methodology
not seen as fulfilled and gets carried over to the next sprint planning as a left-over.
With regard to the implementation of a requirement, the principle of “all or nothing”
applies. In addition to the developers, the product owner and the scrum master other
stakeholders such as clients, representatives from marketing, or customers can also
participate in the sprint review. A sprint review lasts a maximum of 4 hours.
2.5.5 Retrospective
Between the sprint review and the planning of the next sprint, a retrospective takes
place. The aim of the retrospective is for the product owner, the developers, and the
scrum master to review (reflect) on the last sprint and evaluate suggestions for
improvement. This is done intending to increase quality and effectiveness. In doing
so, the scrum team checksteam reviews how the last sprint went in terms of
individuals, interactions, processes, tools, and Definition of Done. The following
procedure has proven successful:
• The participants think about the following topics and write a card or post-it for
each contribution:
– What went well?
– What went wrong?
– What could be improved?
• Participants post their contributions onto a pin board, grouped around the three
questions.
• All participants look at the contributions and let them sink in.
• Each participant can comment on and add to their contributions.
• The group discusses the question “What could be improved?” Improvement
measures are defined and decided together in the group.
The retrospective is moderated and led by the scrum master. He pays attention to
constructive and objective contributions. Contributions that personally attack other
group members are to be avoided.
The sprint review and the retrospective firmly establish continuous learning and
improvement in the process. The two meetings generate knowledge and stimulate
the constant improvement process. In many cases, this also leads to a steady increase
in the speed (velocity) of development. As a result, more and more requirements and
topics can be implemented from sprint to sprint during the fixed sprint duration. This
improvement process is also called kaizen in lean product development. In practice,
retrospectives are often conducted very mechanically and with little commitment.
Questions such as “liked, learned, lacked” or “start, stop, continue” are reeled off
emotionlessly, a few impressions are collected, the team members pat themselves on
the back and move on to everyday project work. Retrospectives only make sense if
they are done with commitment and all topics are addressed openly.
2.5.6 Project Controlling
Overview
Project controlling is to be regarded as an independent term in the traditional
approach and describes the processes and rules within project management that
contribute to seeing to it that the project objectives are achieved. Project controlling
in the overarching sense is a cycle in three stages, as Table 2.41 described.
The elementary basis for successful project controlling is the correct definition of
binding objectives and reliable planning. In project controlling in the narrower sense,
corrective measures are derived from a comparison between the target and the actual
status, which can lead to adjusted plans or to altered objectives, a new target state.
Project management runs in cycles: If executed well, it is aligned with the goal,
otherwise the project goes round in circles, as shown in Fig. 2.65.
Project controlling is therefore a direct management task of the project manager in
cooperation with the project owner, project committee, decision-maker or manage-
ment. Depending on the level of flight, a distinction is made between the following
terms:
• Strategic controlling (by the management)

• Multi-project controlling (through the project portfolio board or the project
committee)
• Project controlling (also individual project controlling) by the project manage-
ment and the project committee
Table 2.42 summarises the main tasks of effective project controlling.
Table 2.41 Project controlling in the context of overall project management

Definition Correct and complete agreement on objectives between project owner and project
stage team
Planning Project planning can be derived and elaborated from the objectives of a:
stage • Phased plan
• Project structure plan
• Date and schedule
• Resource plan
• Cost plan
Control Within the framework of project controlling in the narrower sense, the target state
stage is compared with the actual state. In case of deviations, corrective measures are
defined
Disturbances in the form of conflicts or change requests flow into this stage and
lead to a new cycle run:
• Approved change requests modify the original objectives in the definition stage
• The handling of conflicts as well as changes in objectives leads to an adjustment
of the planning in the planning stage
176 2 Methodology
Definition
• Set goals
Control Plan
• Content, quality • Phase plan
• Deadlines • Project structure plan
• Costs, resources • Schedule
• Conflicts • Resource plan
• Changes • Cost plan
Fig. 2.65 Project controlling as a cycle in three phases
Table 2.42 Aspects of project controlling

Project control Continuous monitoring of the achievement of the project’s objectives in terms
of deadlines, costs, and quality
Reporting Reporting includes documentation and communication of the results achieved
in the project to the relevant bodies and the decision-makers
Project Corrective measures are formulated based on the results of the project control
management
Project changes Changes in the on-going project are documented: Requirements, technology,
market, etc., measures formulated and implemented
Project At regular intervals, but at least at the end of each project phase, the project is
assessment reassessed with regard to predefined criteria and expected risks
2.5.6.1 Project Control

The basis for the task of project control is the current project plan. The project must
be checked at regular intervals to see to it that it remains on schedule and within
budget. The more complex or time-critical the project is, the shorter the control
intervals need to be. If many project managers create meticulous plans with great
effort, they should also have suitable methods of recording the project progress
against the plans and to control it in a goal-oriented way. Three aspects make this
possible:
• The progress of the project is determined objectively

• The data obtained is interpreted correctly
• Comparison with the target state presupposes clear, measurable objectives
Depending on the size and complexity of the project, different methods can be
used to record and visualise the progress of the project and to compare target and
actual values. The bar chart or work package schedule control, the earned value
analysis, and the milestone trend analysis can be mentioned.
Earned Value Analysis

The Earned Value Analysis (also called Performance Value Analysis or Completion
Value Method) is used to assess the progress of projects. It allows the three elements
of the “magic triangle”, scope, costs, and time, to flow simultaneously into the
project assessment. This is done by calculating the following quantities:
• Planned expenditure (planned value)

• Completion value (earned value)
• Actual expenditure (budget burned)
Earned value is the key performance indicator in this model for controlling the
progress of the project and the associated costs (Fig. 2.66). Only work aspects that
are fully completed and audited contribute to the earned value (0 or 100%)
Costs
PV
AC – Actual Cost
AC
Extra effort
PV – Planned Value
EV – Earned Value Delay

EV
Time
Project start Reporting date End of project
Fig. 2.66 Earned value analysis

178 2 Methodology
Mar
Feb
Jan
Dec
Nov
Oct Introduction
Milestone dates
Sep Realisation
Aug Concept
Jul Initialisation
Jun Commissioning
May
Apr
Reporting date
Mar
Feb
Jan
Fig. 2.67 Milestone trend analysis
Milestone Trend Analysis

The Milestone Trend Analysis (MTA) shows which temporal development is
emerging in the project. The prerequisite for this is the definition of a sufficient
number of milestone dates for the project to be assessed. These dates are checked at
regular intervals to see whether they can be achieved and transferred to a coordinate
system (Fig. 2.67).
This results in a forecast curve for each milestone, which ideally runs horizontally
(without any deviation). The experienced project manager can create a forecast for
the future course based on the course of the curves. The milestone trend analysis
gains its special value from the combination of a review of achieved results and an
outlook on achievements still to be made as well as being able to provide a
comparison between different projects.
2.5.6.2 Reporting
The reporting to all stakeholders of the project is probably one of the most important
and at the same time less popular tasks of the project manager. A regular exchange of
interim results with the responsible bodies and decision-makers ensures that the
project is kept in touch with those at management level and that the project manager
can quickly count on the appropriate support in case of problems arising.
In a status report, also called a progress report, for the attention of the decision-
makers (customer, project owner, or project committee), the following statements
should be made at regular intervals (often monthly or even weekly):
• What work or work packages have been started or completed?

• Plan actual comparison with regard to time, costs, and resources
• Can the remaining milestones with all outcomes be achieved as planned?
• What problems have arisen since the last status report?
• What measures have been taken? Who will solve the problem and by when?
• What new risks have been identified in the meantime?
• Where is management support necessary?
The shortest variant answers the questions:
• Highlights: What’s going well?

• Issues: What is not going according to plan?
It is advisable to develop a solution proposal for each issue, which should ideally
be able to be supported and implemented or commissioned by the decision-maker.
This gives the project manager a great deal of power and can strongly influence his
project outside of the scope of his formal competences. The reporting system serves
as the basis for all steering and control measures necessary in the course of the
project.
In many cases, reporting is regulated in the project management guidelines.
Appropriate forms and templates are provided for this purpose. Traffic light systems
have proven useful in practice. A common understanding of the meaning of the
individual traffic light levels has been seen to, for example:
• Green: stands for being on course

• Yellow: means that an escalation to project management is required. The project
manager can then decide and implement measures
• Red: escalation to management is necessary. Management is to decide on
measures and implement or delegate them
If different stakeholders define the traffic light levels differently,

misunderstandings and empty runs become inevitable.
At Metrohm, the monthly status report is structured with, among other things, the
following elements, see Fig. 2.68:
• Project status with traffic lights and management summary

• Milestones
• Risk management
• Project costs
180 2 Methodology
PROJECT STATUS REPORT

IC Project Type
Sp EWP 100 23.04.2022
Titr OMNIS Project EWP Number Reporting Date
1
KPIs:
Next MS Go Live PC Project Budget Resources Scope Deviations Risk
07. Okt 22 03. Jul 24

Release Prototype Market Release
Management Summary
- Project on Track for Market Release, but delay of Prototype Release of 10 days due to late arrival of critical component
- First titration-tests showed very good results, the ambitious requirements could be achieved
- Major Decision: New Sample handling Concept will be implemented, as agreed with Product Management
- Request: Investment 100k for automated production prozess is required, see separate evaluation and busienss case
Last Approved Initial Plan

Milestone Actual Plan Status
Dates (LH-based)
1 Start of project 01. Jan 20 01. Jan 20 01. Jan 20
2 Review Design Goals 19. Jul 20 19. Jul 20 19. Jul 20
3 Review URS 04. Feb 21 04. Feb 21 04. Feb 21
4 Review Design Input 23. Aug 21 23. Aug 21 04. Jul 21
next MS Release Prototype 07. Okt 22 27. Sep 22 08. Aug 22
6 Review Design Transfer 19. Feb 24 09. Feb 24 21. Dez 23
7 System Freeze 20. Mär 24 20. Mär 24 30. Jan 24
8 System Release 19. Mai 24 19. Mai 24 30. Mär 24
Go Live Market Release 03. Jul 24 03. Jul 24 14. Mai 24
Top 5 Risks Risk (after mitigation)
Description Level Level Status x

before after
R1: Präzision des Dosierers erfüllt
80 20 in Arbeit
geforderte Messgenauigkeit nicht
R2:Neue Ventiltechnologie
90 8 in Arbeit
funktioniert nicht
R3: ASIC steht nicht funktionsfähig

64 24 in Arbeit
zeitgerecht zur Verfügung R1
R5
keine
R4: UL-Zertifizierung wird nicht
24 Aktivitäten
erreicht
notwendig
R5: Software steht nicht ausrei-
60 20 in Arbeit
chend funktionsfähig zur Verfügung
Project Costs (TCHF)
Fig. 2.68 Practical example Metrohm: Project status report

2.5.6.3 Project Steering

A project needs to be managed flexibly and according to the situation. Every project
and each individual problem that arises is every time so specific and complex that
there can be no universal formula for project control. Based on the results of the
project control, measures have to be defined for the controlling influence on the
course of the project.
The tasks of the project manager are:
• To update and monitor agreed-upon project metrics

• Getting the project plan to achieve the original project objective update
• Developing alternative scenarios in case of deviations from the project plan
• Requesting additional resources and funding as needed
• Changing the tasks of the project staff
• Subcontracting
• Having to negotiate with the project owner
• Implementing decisions made by the project committee
• Requesting project reviews and project audits
• Requesting project cancellation
The tasks of the project owner or project committee are:
• To approve or reject additional funding

• To approve of and then enforce additional resources (from the line)
• To give the go-ahead for the next project phase
• To decide on the cancellation of projects
• To change project priorities
Some preventive measures for efficient project control are:
• Clearly understandable and measurably formulated objectives

• Situationally flexible and rolling project planning
• Periodic coordination meetings of the project team to clarify the current situation
• Identifying future difficulties, agreeing on preventive measures and making
decisions.
• Consistent making of binding decisions by the project owner
• Periodic team meetings
• Context or environment analysis
• Reviews and milestone meetings
2.5.6.4 Project Assessment

Normally, the most important steps (milestones) of a project are already agreed upon
in the project order. These agreed-upon milestones are particularly suitable for
project assessment because clearly defined deliverables and work packages have to
have been entirely fulfilled at this point. Milestone meetings enable a critical review
of that which has already been achieved, of what is still to come, and of the degree of
182 2 Methodology
maturity of the interim results. Together with the project owner or the project
committee, the project management has to clarify the following questions in a
binding manner:
• Is the achievement of the project objectives still guaranteed?

• Is the economic viability of the project still ensured?
• What risks could jeopardise the project?
• Do prior assumptions still apply or have new framework conditions emerged?
• Are there any open problems that prevent the project from proceeding?
• Will the next project phase be released? Dependent on what conditions?
• Should the project be terminated prematurely?
At the end of the meeting, minutes with any conditions, responsibilities, and
deadlines should be drawn up and signed by each of the involved parties.
Reviews and Audit for Project Assessment

Reviews are critical during and after the completion of the project so as to determine
whether the required objectives have been achieved in full and having the required
quality. Organisations often distinguish between different levels of reviews, as
shown in Fig. 2.69:
• Milestone review at each milestone

• Gate review according to selected milestones with a particularly large impact
• Final review incl. debriefing and lessons learned at the end of the project
• Post-control incl. post-calculation to check whether objectives have effectively
unfolded their desired effect.
Final Follow-up
Level 3
Review inspection
Gate
Level 2
Review
Milestone Milestone
Level 1
Review Review
Phase 1 Phase 2 Phase 3 Phase 4
Project Usage, Operation
Fig. 2.69 Various project reviews

Table 2.43 Aim and participants of a project review

Main objective Possible participants
Milestone Control of the project process • Project manager
review Assessment of the: • Project team
Gate review • Phase objectives, deadlines, finances • Project committee
Stage-gate • Resources customers
review • Procedural methodology • Possibly other
Quality gate • Project organisation stakeholder groups
review • Information
• Communication and cooperation
• Derive consequences for the further procedure of
the following phase
End review • Assessment of the achievement of the project • Project manager
objective • Project team
• Critical review of the project process • Project committee
• Derive lessons learned, i.e. measures for internal client
operational project management • External moderation
Follow-up • Assess long-term goal achievement and project • Team external to the
impact project
In contrast to a review, an audit does not check the results achieved, but rather the
compliance with applicable (external or self-imposed) procedure:
• Audit: checks process conformity

• Review: checks the achievement of objectives
Of course, the situational suitability of a chosen approach, of the methodology or

the tools can also be looked at in the context of a review. It is then assessed whether
the corresponding methodology is suitable for achieving the objectives under the
given circumstances. Table 2.43 shows the objectives of different reviews.
Often the possibility of reviews is used far too little for (self-)critical retrospec-
tion, be it for the on-going phase controlling or for the evaluation of the whole
project. Honest reviews are an opportunity to identify emerging problems while they
are still small and solvable.
In the agile approach, a sprint review takes place after each sprint (approx. every
4 weeks). Improvement measures are identified in the team retrospective. This
creates a learning organisation that can react quickly to problems or changed
situations. In the traditional approach, it should be examined to what extent such
elements can be adopted from the agile approach.
2.5.6.5 The 90% Syndrome

Relatively soon after the project has really got going, some project participants
believe that a large part (90%) of the project work has already been done, as
Fig. 2.70 shows. This phenomenon occurs because some feasible solution ideas
are already emerging, for example a working prototype might already exist. How-
ever, the obstacles and as yet unknown problems that then arise in the realisation
184 2 Methodology
Stage of completion
100%
90%
ted
ed
ma
nn
ti
a
Pl
Es
al
tu
Ac
Time
End of project
Fig. 2.70 90% syndrome
phase are then underestimated. This assessment of one’s effort is typically very
optimistic in the first half of the project and usually requires correction in the second
half. Objective control methods are needed to avoid the 90% syndrome.
2.5.6.6 The 0/100 Method

In order not to present the degree of completion of a work package (or any activity)
too positively, the 0/100 method is well-tried and successful. Using this method
means that an activity is only credited to the progress of the project after it has been
completed. The 0/100 method is used especially in earned value analysis, but also in
the agile procedure for progress control (see Burndown Chart).
2.5.7 Deadline, Cost and Resource Control
2.5.7.1 Deadline and Cost Control

For schedule and cost control, it is usually sufficient to compare the following key
figures, as shown in Fig. 2.71. However, the current data required for these needs to
often be compiled in time-consuming detail work (e.g. evaluations from reporting
systems, statements from project staff, etc.). For this, the planned and actual data has
to be available in a compatible form:
Schedule 1 completed in %
Duration/Costs
2 according to initial planning
Forecast
3 Reporting date
4
6
Time
Cumulative
cost curve
Planned
Costs
Actual
Time
Fig. 2.71 Project status assessment and cost control
• Planned and effective duration

• Planned and effective costs
• Degree of fulfilment in %
A project status assessment with cost control should take place in pre-determined
intervals, which ought to be adhered to for the duration of the entire project (weekly,
monthly, or quarterly). It is not always easy to say whether the costs incurred are
sufficient for the services actually provided.
In general, the following conditions are required for effective cost control:
• Transparent cost planning

• Rapid availability of the cost status
• Periodic review of the projected final costs
If significant changes are made to the task during the project or if there are large
deviations between the planned and actual values, the original planning needs to be
revised. For the remaining or not yet completed activities, the remaining duration
(time-to-complete) and the expected remaining costs (cost-to-complete) are deter-
mined, as Fig. 2.72 shows.
186 2 Methodology
Time-to-complete
Costs
Cost-to-complete
d2
nne
Pla
d1
nne
Pla
l
tua
Ac
Time
Reporting date
Fig. 2.72 Time-to-complete and cost-to-complete
2.5.7.2 Resource Control

The personnel deployment is difficult to plan and even more difficult to enforce. If
no empirical values were available at the beginning of the project, or if unrealistic
estimates of effort were being made, or if the assumptions and prerequisites turned
out to be wrong, large differences can arise. In practice, the problem is made more
difficult by the fact that the planned resources are often not available at the agreed-
upon point of time or within a given time period. Possible causes for this might
be that:
• The project management philosophy has not yet been established in the company
• Project leadership is only half-heartedly supported by management
• Managers do not have an overview of the resources they have committed or do
not stick to negotiated arrangements
• Many more projects have been initiated than there are resources available for their
realisation
• There is no or insufficient operational planning and coordination of available
resources
• Projects are not centrally monitored and prioritised
2.5.7.3 Cost Transparency and Realistic Assessment of Economic

Efficiency
In order that necessary project control measures turn out to be appropriate and
adequate, a reliable prior assessment of the project situation is needed. In addition
to the progress of the project and the use of resources, the current cost situation is
calculated completely and realistically.
Full cost accounting must be applied to planning and project requests, i.e. both
internal and external costs need to be taken into account. Not only the direct project
costs are to be listed, but also follow-up costs that are caused by this project:
Operation, follow-up projects, maintenance, decommissioning. The life-cycle costs
should be used as assessment criteria. The sum of project/non-recurring costs and
operating costs ought to be used as classification criteria, provided the project owner
is open to doing this.
At the start of the project or for a fixed price offer, the project costs are planned to
the best of our knowledge and belief. Due to the market situation or for capacity
utilisation reasons, the management may sign an order at a sales price that does not
cover the costs. This is an entrepreneurial decision. The responsibility of the project
manager is nevertheless measured against the values of the planning. Every planning
carries with it a degree of uncertainty. The project manager presents the situation as
realistically as possible, shows the alternatives in the form of scenarios, quantifies
the planning uncertainty, and shows the consequences if a decision is not
implemented as intended.
When a project is completed, the project team is broken up. Whether the savings
objectives are actually achieved after the implementation usually only becomes
apparent at a later stage. Therefore, a point in time should be set at which the project
manager initiates a post-calculation and reviews the results with the project owner
and the former team members.
Economic Efficiency
The project request is the immediate decision-making basis for the approval of a
project. The responsible decision-makers are guided by the simple questions: “What
does the project cost? What will it achieve?” These questions must be reviewed
regularly throughout the project. If the answers are no longer clearly positive, a
premature termination of the project must be discussed and decided upon.
A simple cost–benefit analysis is often used to calculate the profitability of a
project. For complex projects, traditional procedures and key figures from invest-
ment appraisal are used, e.g.:
• Profitability calculation
• Return on Investment (ROI)
• Net present value method
• Break-even analysis
• Dynamic Payback Method
188 2 Methodology
2.5.8 Project Changes, Change Request Management, Claim

Management
2.5.8.1 Project Changes

Projects are in a highly networked and dynamic environment: events can occur at
any time that may then have a major impact on the project. However, events external
to the project or influencing factors such as rapid changes in the market, new laws, or
new competitors are difficult to control. They usually occur at short notice and
unexpectedly.
Project-internal events or influencing factors are partly predictable, since the project
is self-controlling, meaning that developments are able to be followed. However, as the
realisation progresses, new findings arise within the project that can lead to changes.
Basically, project changes are handled differently in the agile approach than in the
traditional approach. In the agile approach, changes are included in the product
backlog and prioritised by the product owner. Here, duration and budget are fixed.
The inclusion of changes takes place through a different prioritisation in the product
backlog. This way a newly emerging feature gets classified as being more important
than an already known one, the implementation of the latter is postponed until later,
or the implementation is waived. Change management as in the traditional approach
is therefore not applied in the agile approach. The following explanations are sound
for the traditional approach: Every event with change character is to be examined by
the project manager with regard to its effects on the project, especially effects on
performance, deadline, and cost objectives as well as risks. A distinction is made
between future changes (change request management) and changes that have already
occurred (claim management), as shown in Table 2.44.
Effects on content and organisational changes are easier to solve than interper-
sonal aspects. In order for project management and project team members to be able
to deal with these as well, they need to have special knowledge and skills.
2.5.8.2 Change Request Management

Change Management encompasses the organisation, administration, and processing
of change requests to project objectives and processes during the course of the
project according to traditional procedures. It should be clearly distinguished from
organisational change and systemic change management. Project changes can arise
due to:
Table 2.44 Differences between change management and claim management

Change management (change request) Claim management (claim)
The change was only requested The change has already been implemented
Weighing the benefits and consequences of Allocation of additional costs incurred: Who pays?
change request
Allows for factual discussion More likely to lead to enforcement claims
Is a natural process in a dynamic world Cannot always be avoided with very extensive and
complex projects
• Customer wishes, customer complaints

• Development errors
• New insights gained in the course of the project
• Components or materials that are no longer available
• Amended rules
• General product improvements
• Possibilities for improving economic efficiency
Changes should be managed depending on their importance and urgency,

summarised in a to-do list and jointly edited and released in versions: Is the change
implementable? Is it necessary? What risk, what benefit, what effort does it entail?
The follow-up costs need to be endurable to the company. Therefore, changes have
to also be assessed and decided upon from an economic point of view. In the case of
customer projects, it is to be clarified whether the change is made as a gesture of
goodwill or whether it is rather to be treated as an additional requirement.
In many companies with a high proportion of development, the change request
management process is mandatory. Change requests are submitted by the project
manager to the committee that approves all major change requests. If no change
process is installed, the project manager sees to it that a decision-making body and its
responsibilities are defined. Relevant stakeholders should be represented in this
expert team. In practice, it is up to the project manager to decide whether a change
request will be handled as a gesture of goodwill or incurs an additional invoice.
Change requests contain the following items:
• Nature of the change

• Reasons for the change
• Deliverables and work packages affected by the change
• Impact on project costs, duration, and other project parts
• Effects of rejecting the change
• Impact on safety, emerging risks
• References to previous change which have an impact now
• Body responsible for the decision
• Consent of the customer
• Order placement (from design change request to design change order)
Figure 2.73 shows a template for a change request application.

The processing of a change request is always a two-step process:
1. Change Request and impact analysis

(a) The applicant sends the change request to the project manager
(b) The project manager has the application reviewed by all potentially affected
project staff or departments on:
• Cost impact
• Timeline impact
• Risk impact
190 2 Methodology
Change Request Project Distribution Back-End
1 Change request identification

Creator: Overall project manager Identification no.: 005
(to be filled in by the project manage-
Subproject / Overall project ment)
Work package
Contact Overall project manager Creation date: 15.05.2022
Title/short descrip- Sale of Libero subscriptions

tion:
2 Classification of the application / error message

Category: Postponement
(Please mark with Change / Extension
a cross where ap-
plicable) Change of responsibilities / organisation
3 Effort estimation
Sub-sector Expenditure exter- Internal expendi- Total
nal ture
Additional costs for realisa-
tion Verbund - subscripti- CHF 350,000 160'000 CHF CHF 510,000
ons
Total CHF 510,000
4 Description of the problem

The sale of Libero season tickets has been brought forward in the ZPS range expansion. By the timetable
change in December 2022, the sale of Libero season tickets must be possible via the webshop on bls.ch. In ad-
dition, a white-label shop solution is now to be made available for other transport companies. It makes sense for
this requirement to be implemented by the sales back-end project team.
The implementation of a web shop for the sale of Libero season tickets or other public transport season tickets
is not envisaged in the scope of the distribution back-end project.
5 Desired change - possible solutions

Planned webshop to be implemented in first priority for the sale of season tickets. The sale of single tickets for
public transport will be downgraded to 2nd priority.
6 Consequences of non-realisation
Automatic renewal of BLS customers' subscriptions will be handled through other sales channels outside BLS
from December 2022.
7 Supplements
Further details are described in the documents of the steering committee.
8 Approval internal, department and area

15.05.2022 Submission amendment Page 2 from 3
Fig. 2.73 Template “Change Request”

Change Request Project Distribution Back-End
Instances (electronic only, no signature required)

Date
Applicant Overall project manager 31.05.2022
9 Decision
Reason Appointment
Change will be realised Securing the sale of Libero subscriptions as of 31.05.2022

December 2022
Change will not be realised
Documentation of any restrictions or conditions.
10 Signatures
Commissioning instanceCommissioning instance

Chairman Steering Committee Overall Project Manager
_______________________________________ ______________________________________
_______________________________________
15.05.2022 Submission amendment Page 3 from 3
Fig. 2.73 (continued)

192 2 Methodology
(c) The sum of the (additional) costs, the postponement, and the additional risks
are combined
2. Approval and implementation
(a) Change request (Scope Change) and impact analysis (cost, timeline, risk) are
submitted to the project owner, steering committee, or customer for a decision.
(b) If the change request is accepted, the project budget, deadlines, and risk
analysis are adjusted accordingly. The project team is then measured against
the new objectives.
2.5.8.3 Claim Management

If an approved change request causes additional costs, the project result is changed or
the final deadline is postponed, the disadvantaged project partners will submit claims
to the originators. The handling of these claims is part of claim management, which is
positioned at the interface between change management and contract management.
The systematic monitoring and assessment of deviations and changes as well as
their economic consequences is an important factor for the success of complex
projects. The determination of additional services rendered and the associated claims
serves as the basis for their compensation. It is the task of the project manager to
guarantee an appropriate balance between the claims of the project participants and
the optimal project process.
In order to achieve this, the warranty claims and deadlines should already be
clearly regulated in the contract and the acceptance of partial services agreed upon.
The contract ought to therefore specify which factors are not influenced and also
from which no claims can result. The issue of claim management is particularly
sensitive in projects, as it is seldom possible to clearly define what the project has to
achieve in its initial phase.
Defining the expected results in the project contract so narrowly that everything
that goes beyond this is evaluated and compensated as additional work—is a form of
art. On the other hand, the service recipient should be able to prove
underperformance by pointing out what is stated in the contract. The documentation
of the project work thus makes it possible to provide evidence, if necessary.
Supported by project-accompanying quality management, deficiencies can therefore
be detected in time and making it possible to limit unjustified additional claims.
Instead of relying on legal quibbles, however, a relationship based on partnership
should be established between the project owner and the contractor for the sake of a
good image and long-term cooperation.
In practice, it is helpful to keep a “plus and minus list” which shows additional
and reduced expenses and thus provides a good basis for negotiation for both parties.
The steps of claim management are shown in Fig. 2.74.
Prevention Preparation Implementation Experience

Delivery and Implement nego- • Recognise possible claim events building
service scope tiation results for • Documentation • Checklists
delivery and ser- • Factual and commercial exami- • Strategy
Contractual
vice in a contract nation • Procedural rule
agreement on
• Clarify the facts
claim process Implement pro-
• Compensate claim-related requests
cedure rule in the
project
Fig. 2.74 Steps in claim management
2.5.9 Checklist Completion Realisation Phase
• How well were all the objectives agreed upon in the project objective
achieved?
• How well do the results accomplished match the objectives?
• Is the introduction of the solution to the user planned in such a way that it
can realistically take place?
• How are the accompanying measures such as training, adaptation of the
organisation for the introduction seen to?
• How broad is the acceptance for a successful introduction? Is it sufficient?
Specific points of the traditional approach:
• Have changes been systematically documented?

• What successes do the planned checks and tests on the new object display:
product, system, organisation?
• Is a pilot test necessary before widespread introduction is initiated?
• Which results were not achieved? What are the consequences?
• For which deficiencies are there no corrective actions?
• What specifically needs to be considered in the closure review? What open
points remain?
(continued)
194 2 Methodology
• How did self-organisation and cooperation work in the team?

• Were the individual sprint objectives achieved?
• How was the team’s learning curve?
• Has the speed of development (velocity) increased over the course of the
project?
2.6 Introduction Phase
After realisation is completed, the system is put into operation and introduced. In
the case of it having had to do with product manufacture, serial production begins.
Services are then actively offered or the new organisation is put into effect. Now
the phase of utilisation begins. Here, experience is gained that can be used to
improve the present solution and to design similar systems.
When the new service or product has been introduced to the user, the project
organisation has to be ended again, a process which includes appreciating what has
been achieved and the drawing of lessons from what has taken place. Ideally, this
happens when, after an agreed period of productive use of the developed solution, a
retrospective assessment is undertaken together with the project owner and the user.
2.6.1 What Is Important in the Introduction Phase?
Steps of This Phase

Table 2.45 shows the most important steps in the agile and traditional approach for
the introduction phase.
Results of the Introductory Phase

A good introduction of the new solution and a complete conclusion with an evalua-
tion of the project ensure that the project can be completed, leaving a positive overall
impression. The project team it not to be allowed to fall prey to the “almost done
syndrome”, and must not be permitted to inwardly say goodbye to the project before
all pending work has been completed. Conclusions can be drawn from any mistakes.
Other projects can benefit from the acquired and documented knowledge.
When the project is finished, the following can be ticked off and stated:
• System, product, service has been carefully handed over to the line
• Users can deal with it productively
• The acceptance protocol has been signed
• The recalculation has been carried out
• A documentation on expertise and experience is available
• The final assessment has been carried out
• The project team members are relieved and say goodbye to one another
• An appointment for a follow-up has been arranged
2.6 Introduction Phase 195
Table 2.45 Steps in the introduction phase

Most important steps The following work is scheduled for project completion:
• Enable users to use the new solution productively
• Introduce solution and put into operation
• Check whether the objectives have been achieved
• Prepare maintenance and upkeep, define successor organisation
• Prepare final account and recalculation
• Prepare a report and proposal for the final evaluation
• Hand over project documents to the maintenance organisation
• Hand over the system to the users or the customer (acceptance
protocol)
• Complete and ensure archiving of project documentation
(particularly important in plant construction with regard to product
liability)
• Consciously disassemble the project team
For the assessment of the sustainable achievement of objectives, the
effectiveness and yield of the project objectives are reviewed again
with the project owner after an agreed-upon period of use. An
immediate review at the time of handover may be more appropriate
What should be paid Really complete the project and hand it over to operations. It is
particular attention to important that project staff are no longer responsible for operations
in the introductory
phase?
Table 2.46 Results of the introduction phase

Principle In terms of information, the focus is on the operators and users. Updating and
completing the documents is often unattractive for those involved in the project, as
the project objective has been achieved and there is little to be gained from
documents put together for future users. With the introduction, the usefulness of the
documents can be tested. At the latest during revisions, omissions become visible.
History is at that stage catching up with those responsible for the project at the time!
Process- • Final project report: results, statements on the project process, administrative
oriented final work
results • Final account
• Acceptance report
Content- • Training documents, updated • Training documents, updated
oriented instructions for users, operating instructions for users, operating
results instructions instructions
• Updated results documents • Updated result documents,
• Product backlog with unrealised e.g. construction plans, programming
features documents, product descriptions
• Archiving • Archiving
In the introductory phase, results according to Table 2.46 are relevant.
People and Team

With the introduction, all tasks, competences, and responsibilities are transferred
from the project team to the internal or external customers. It is now a matter of
196 2 Methodology
handing over to the new people in charge the significant amount of experience as
well as the knowledge advantage that the project team has acquired. Only if this is
successful it is possible to really achieve the economic objectives of the project.
The following measures and competences are important:
• During the introduction, the project team is confronted intensively with the values
and the culture of the internal or external service recipient (Sect. 3.4). The success
factors of the cooperation are highly relevant.
• For the successful transfer of knowledge from the project team to the customer or
internal buyer, the three levels of cooperation have to be newly coordinated (Sect. 1.5).
• For the “content” training, a relationship needs to be built up between the project
team and the buyers as a basic prerequisite for mutual respect and trust (Sect. 3.
3.5). Adequate organisational measures have to be taken.
• The representatives of the client system have different competences, which leads
to resistance and sometimes on-going conflicts. Conflict management is therefore
relevant in this phase.
• It is possible that individual members of the team are withdrawn during the last
phase of the project. The project managers should ensure a good end to the story
during this time of upheaval.
• Since innovative solutions have to be achieved in the project under time pressure,
not everything always succeeds. That is why it is important to deal with
failure well: “Am I serving failure?” or “Does failure serve me?” (Sect. 3.8.5).
• Learning organisation: The project review or the retrospective provides a unique
opportunity to analyse what went well in the project and where mistakes were
made. This analysis should again be made on the three levels of cooperation
(Sect. 1.5). All three levels are based on well-developed competences of commu-
nication (Sect. 3.9).
• At the end of the project, the achievements of all those involved should be
acknowledged, since acknowledgment is an important basic personal need
(Sect. 3.3.2) and strengthens future motivation (Sect. 3.7) for project work.
2.6.2 Types of Introduction
The Introduction needs to be planned and prepared in good time. Ideally, an

introduction concept is developed in the concept or realisation phase for the prepa-
ration of the introduction. A new solution can be introduced in three ways:
• Abruptly on a defined date (big bang approach)

• Gradually, sub-area by sub-area
• Parallel: Old and new solution are operated simultaneously until the new one
works and can be operated.
It is often difficult to assess in advance how a system, a plant, or a process

adaptation will perform in productive use. Despite good preparations and
comprehensive tests, unpleasant surprises can occur, e.g. performance problems

with software. Therefore, a gradual introduction is recommended. If problems
occur, only a part of a company is affected. The experience gained from a phased
introduction can also be taken into account on an on-going basis. Running two
solutions in parallel is costly and can rarely be sustained over a longer period of time.
The big bang approach should only be chosen in exceptional cases, as this
procedure involves high risks. It can be the approach of first choice, for instance,
in the course of launching a new product or a new service on the market. In
preparation for the launch, the following points need to be clarified:
• Type of introduction, introduction procedure

• Introductory measures
• Introductory organisation
• Implementation planning
• Planning of the pre-acceptances and acceptances
Depending on the type of project, the introduction has to be planned meticu-

lously. In certain cases, it makes sense to draw up a detailed schedule of the
introduction with checklists. This should also show who does what and when.
Such a schedule should be tested once or twice before productive implementation.
When planning the introduction, it is also very advantageous to prepare a fall-back
plan or a plan B. In the preparation, it is important to consider how the introduction
will be carried out. In the preparation phase, consideration is given to how the
transition from the old to the new can be shaped. The principles of organisational
change management (Sect. 1.4.4) should be taken into account.
2.6.3 Acceptance and Commissioning
2.6.3.1 Acceptance
In the previous phase, the product or service was realised and tested. Based on the
tests in the realisation phase or on special acceptance tests, the deliverables are
accepted by the project owner. The project owner can also delegate this competence,
e.g. to the product owner in the agile approach. It helps if clear acceptance criteria
have been defined for the acceptance itself. The acceptance criteria in the traditional
approach should be based on the requirements and the solution concept.
2.6.3.2 Commissioning
Depending on the type of project, commissioning and effective use of the plant,
product, or software take place before or during acceptance. In the case of services or
organisational adaptations, there is less talk of commissioning. In these cases,
productive use takes place after acceptance. Depending on the size of the project,
it makes sense to already carry out preliminary and partial acceptance in the
realisation phase.
198 2 Methodology
2.6.3.3 Going Live in the Agile Approach

In scrum, a release is formed from several sprints. A release is a deliverable product
version that is put into production and made available to the users for use. The
release plan is developed in the concept phase.
2.6.3.4 Pilot Test, Pilot Series

When introducing new work processes or infrastructure in a company, it makes
sense to test their practicality in a limited organisational unit by means of a pilot test
or a pilot series and to only then extend it to the other organisational units, to
companies of the group, or to other countries.
If a prototype was able to be produced successfully, this does not mean that the
manufacturing process has been mastered. By producing a pilot series with the
intended manufacturing process, the processes can be optimised and any errors
eliminated in time.
2.6.3.5 From Pilot Series to Serial Production

During the transition from pilot series to serial production, the method may well get
critically reviewed again. The following steps should be taken into account:
• Putting the new system into operation

• Preparing and monitoring introduction
• Consolidation, rectifying deficiencies
• Making and introducing organisational arrangements
• Handing over new system to users, starting serial production
2.6.4 User Training and Education
2.6.4.1 User Training Concept

The goal of training is to enable users to handle the new product or to provide the
new service. The further development of employees’ skills safeguards the
company’s ability to survive. If experience derived from the pilot phase or from
the pilot series is available, it can be used for user-oriented documentation (e.g. as
operating instructions) and for user training. Which form of training fits best depends
on various factors:
• Are there different target groups?

• Who is scheduled for the training?
• What information from the project needs to be communicated?
• What is the scope of the training?
• When should training take place and in which way?
• Do all users have to work with the new solution at the same time?
• Is the training short and hefty, or is a gentle introduction more beneficial?
• How do later users get re-trained?
2.6.4.2 Types of User Training

With any kind of imparting of new knowledge or skills, questions concerning the
aim of the training have to be formulated: What do you want the participants to know
or to be able to do after the course? Depending on the situation and requirements, the
following possibilities are suitable:
• E-Learning
• Training video (Youtube.com, Vimeo.com etc.)
• User manual
• Direct on-screen, online help
• Seminar, workshop
• Training-the-trainer or power user
2.6.5 Transfer to the Operational Organisation
In addition to the introduction, acceptance and commissioning and user training, the
operational organisation needs to also be prepared and the realised results handed
over to the operational organisation.
2.6.5.1 Preparing Operation

The first step is to clarify the following questions:
• What does the operational organisation look like? How is this organisation
integrated into the organisational structure?
• What do the operating processes look like?
• What tasks are there to do in the company?
– Support of users, customers, etc. (support organisation possibly multi-level)
– Review of process steps
– Periodic final papers
– Checking and adjusting configuration settings
– Archiving data
– User administration
• Is there a need for an operating infrastructure? If so, what should it look like?
• How are disruptions and errors dealt with?
• Have maintenance and servicing concepts been drawn up?
• Is maintenance organised?
• Are the guarantee services ensured?
• Are there other points to consider depending on the type of project?
2.6.5.2 Business Organisation

When the basics for the operation have been regulated, the operational organisation
needs to be set up and prepared.
The members of the company organisation are to be trained. Ideally, they actively
take on tasks during the induction measures.
200 2 Methodology
2.6.5.3 Business Handover

The realised results and the documentation are then handed over to the company. In
addition to the application and operation manual, the system concepts, requirements,
and solution concepts are also part of the documentation that gets given to the
company. The operational organisation has to clarify whether and in which ways
these documents will be further used. It makes sense to keep the product backlog as a
basis for continuous development. Documentation should not be designed, set up,
and continuously maintained only at the end, but during the course of the project.
2.6.6 Project Completion
At the end of the project, a final assessment of it is conducted. This serves to pass on
experience gained and to provide the basis for project closure. Ideally, the project
review includes different levels as shown in Fig. 2.75.
The final project appraisal at the content level provides information on the
following topics:
• Assessment of the achievement of objectives

– What was achieved and what was not?
– What results were delivered?
• Plan-actual comparison of costs and deadlines
• Assessment of economic efficiency
• Any follow-up inspections in the company, also after the expiry of the warranty
period, for economic efficiency, etc.
Review from a meta level
Content level
Project start End of project
Relationship level
Organisational level
Fig. 2.75 Project review

In addition to the evaluation of the content, organisational and administrative final

work, the cooperation is also to be consciously reflected upon and concluded:
• How did the team members work together? Were personal goals reached?
• What can be learned from this experience?
• Are there any bad feelings or unresolved issues remaining needing to be
addressed and resolved?
• At this point at the latest, the project manager, the product owner, and the scrum
master have to deal with what the future of the project team members looks like:
Where do they go back to? Is their place in the “organisation of origin” secure?
Do they need a recommendation or active support to move on?
With every project, and thus also with every project organisation, an official
conclusion is to be reached and formulated. This will relieve the project committees
so that they are able to devote themselves to new tasks. Of course, the project is
never over entirely. There is follow-up or guarantee work to be done, or documenta-
tion still to be added. This can be organised and carried out by commissioned
individuals.
Project teamwork is often recommended as an important element to further
personal development. But especially in project teams, staff development is still
underdeveloped. Their cooperation having begun with a special launch event, it
should therefore also be ended in an appropriate setting. This is especially important
when the project result is not entirely positive. A final clarification creates free space
for new, improved cooperation.
Analogous to the kick-off, a closing event needs to be conducted which should
take place on the same three levels as the kick-off: The process is concluded in a
meaningful way at the different levels, and the successes are to be celebrated.
Organisational topics for the closing event:
• Introduction and training of future users

• Setting up and reviewing the successor organisation: Who runs the solution?
• Critical review: How appropriate was the project organisation?
• What can the company learn from this for later?
• Appreciation of team achievements, relief of project members
• Feedback of team members’ performance to managers
• Conscious dissolution of the project organisation
• Possibly offer support for the reintegration of team members into the line
organisation
• Organisation of the follow-up work and the subsequent review of success
(follow-up control)
202 2 Methodology
2.6.7 Checklist Conclusion Introductory Phase
• Is it necessary and is there an intention to review the benefits formulated in

the project order?
• Were the results achieved in light of the project owner’s requirements?
• Is the functionality of the product or service well realised?
• Does the impact of the product/service meet the objectives?
• Does the organisation that ensures the correct handling of the product/
service work well?
• Has the final report been approved of?
• Did the project team members have the opportunity to analyse the coopera-
tion and give each other feedback?
• In a joint review, were positive and negative experiences regarding effort,
methodical procedure and cooperation evaluated and measures introduced
to ensure the transfer of knowledge to other projects and the systematic
process improvement?
• Has a list of all open points been drawn up and their implementation
planned? Is it clear to all those involved who it is that will complete
which final work and by when?
• Where will the project team members once again have adequate employ-
ment after the end of the project?
• Do all beneficiaries of the project results know who to contact should future
problems of some predefined form or other arise?
• Who checks the sustainability and effectiveness of the project and when?
• Who calculates—and when—whether the results planned in the profitabil-
ity calculation have been achieved, what financial benefit the project
unfolds, and how well this holds up to predictions made?
Specific points of the traditional approach:
• Have all project documents been created and completed? Has all the
necessary information been handed over to the future users?
• Has the documentation been checked for completeness and archived?
• Has an acceptance protocol been drawn up and signed by the project owner/
customer?
• Has the project manager carried out an assessment of the performance of
the project staff?
• Has excellence been identified and appropriately acknowledged?
(continued)
2.7 Project Portfolio and Programme Management 203
• Has the product backlog with not yet realised wishes, requirements, and
features been handed over to the line or product management?
2.7 Project Portfolio and Programme Management
2.7.1 Project Portfolio and Multi-project Management
Organisations have many more project ideas than resources available to implement
these. Therefore, a project idea has to fit the formulated strategy and fulfil the desired
framework conditions until it finds a place in the strategic project portfolio. Man-
agement has to see to it that available resources are used in a targeted manner. The
portfolio should prevent too many projects from being undertaken at the same time,
and it should also prevent these projects from obstructing each other too much in the
allocation of resources. Apart from the question of resources, however, there are also
others needing to be answered in project portfolio management, as listed in
Table 2.47.
In order to establish the link between corporate strategy and project management
(prioritisation), an overview of the “intended” and “on-going” projects has to be
developed that is as complete as possible. A project portfolio is an overview of all
existing projects and programmes, which are presented in the form of a structured list
or graphically arranged according to different criteria.
The multi-project management process includes the management of all project
management processes of task configuration and project portfolio prioritisation and
control. In practice, the terms project portfolio and multi-project management are
often used to describe the same thing.
Table 2.47 Questions to be answered in project portfolio management

What does the portfolio mix Which are the right projects?
look like? When is the right time to start a project?
Which projects are running at all? Which ones will still be
running next year?
Too many projects? Are all projects useful and necessary? Does the quantity of
projects entail risks?
Which are the really important projects?
Effects of project delays? Will another project be affected?
What does this mean for resources (finances, people)?
Qualifications needed in the Who is assigned to which projects?
future? How much longer will it take?
What do projects that are planned require? Are needed skills
available?
204 2 Methodology
The project manager has to consider different intersections with the project
portfolio management. First and foremost, he has to provide information about his
project to the project portfolio management, including information on evaluation,
dependencies, resources, or the progress of the project. The project portfolio man-
agement also gives the project manager instructions on the form of reporting or on
the available resources.
2.7.1.1 Multi-project Management: Problem Areas, Tasks and Elements

Providing no Transparency and a general lack of information regarding projects or
about ad hoc control of projects are two widespread phenomena in companies. As a
result, wrong decisions are often made. Figure 2.76 shows the problem areas of
multi-project management in everyday life. From these problem areas, task areas and
elements for multi-project management can be derived (Kunz, 2007, p. 24).
Typical planning and decision-making tasks are ones such as multi-project
configuration and multi-project prioritisation. In addition to the allocation of strate-
gic budgets, multi-project management also continuously checks the evaluation
criteria for their appropriateness and adjusts them to the requirements. Multi-project
control is used for on-going monitoring. Project portfolio management has become
established in many companies. The multi-project structure reflects the on-going
optimisation and adaptation of the organisation. For companies setting up multi-
project management for the first time, the multi-project structure constitutes the
Problem areas Task areas

Power-political frictions Use of consistent and objectively designed
configuration
Multi-project-
within the project selection assessment and decision-making processes

Overruns of Coordination of projects and strategic
strategic budgets budgets at corporate level
Inappropriate resource allocation Bottleneck-oriented allocation of resources
to projects to strategic projects
Selection of not value-adding Ensuring adequate use

projects, duplications of evaluation tools
prioritisation
Multi-project-
Lack of strategy orientation Alignment of project prioritisation

Elements
of projects to strategic requirements

Disregard of interactions Evaluation and visualisation of all
between projects project dependencies
monitoring
Multi-project-
Loss of control over the totality Establishing of consistent and method-based

of projects monitoring and review processes
Loss of project-related Establishing knowledge management
knowledge and experience tailored to specific requirements
structure
Multi-project-
Missing organisational Establishing a leadership organisation

regulations for multi-project-management
No timely project- and portfolio- Establishing an information system
related information for multi-project-management
Fig. 2.76 Problem areas, task areas, and elements of multi-project management
--
Planning and Multi-project Multi-project
Structuring the multi-project management

decision configuration prioritisation
Realisation = Project Management
Multi-project
Control
control
Fig. 2.77 Elements of multi-project management
central task in the start-up phase. Figure 2.77 shows the interaction of the elements of
multi-project management (Kunz, 2007, p. 35).
2.7.1.2 Multi-project Management Process

Figure 2.78 shows the ideal-typical multi-project management process.
The first step is to configure the portfolio. The remaining steps are then run
through repeatedly. Depending on the company, the multi-project management
process is run through quarterly to annually. Individual steps such as reporting can
take place in shorter cycles (e.g. monthly). The periodicity to a large extent depends
on the project types. Companies with innovative and agile projects tend to have
shorter cycles. On the other hand, a company with many construction projects may
be satisfied with quarterly reporting.
2.7.1.3 Configuration of the Portfolio

When configuring the portfolio, the following points need to be considered and
determined:
• Dimensioning the portfolio: Which parts of the company should be represented in

the portfolio?
• Evaluation criteria for project selection
206 2 Methodology
Planning and decision Control
Configuration portfolio
Reporting
Ideas Planned – Actual comparison
Project requests
Current projects
Project portfolio
Project assessment
Resource availability
Prioritized project list:

Mandatory projects
Projects under implementation
Ranking of remaining projects Content dependency
Fig. 2.78 Ideal-typical multi-project management process
• Standardised reporting: what information is required at what intervals?

• Suitable multi-project management information system: Office application or a
specialised portfolio board
• Established portfolio board and clarified roles
• Rules of the approval process
• Organisational adjustments
When a company sets up multi-project management, those are the central tasks. In
companies with established multi-project management, these points should be regu-
larly reviewed for appropriateness and adjusted.
Once the portfolio is configured, the first step is to collect the necessary informa-
tion on ideas, project proposals, and pertaining to on-going projects. This gives the
multi-project manager an overview of planned and current projects and represents
the first big step towards a portfolio. In practice, it can be observed time and again
that companies do not have such an overview. This lack of transparency leads to
friction and problems that, at the latest, surface when resources are allocated.
2.7.1.4 Prioritised Project List

Since organisations usually have more ideas and wishes than they can realise with
the available means and resources, they have to select and choose the best and most
Strategic Monetary
significance value
Political Project Relative

motives priority comparison
Project risk Project

+ flexibility dependencies
Fig. 2.79 Influencing factors for project priority
suitable projects from the line-up of these ideas and wishes. Evaluative questions to
be answered in order to find out, which projects are the right ones: Is it:
• Those that make the greatest contribution to the strategy?

• The ones that are most urgent?
• Those that generate the greatest benefit?
• Those that to the project have the highest priority?
The issues are manifold. There are different influencing factors that affect the
priority of a project, as shown in Fig. 2.79.
Priority classes are often used for prioritising projects. Table 2.48 shows a
possible priority classification. Recommendations for action can be derived from
the priority classes.
Evaluating projects means finding a clear project priority. This project priority
serves as the basis for decisions regarding budget allocation and the implementation
of a project. At least for priority classes B and C, a ranking list should still be created.
For this purpose, it is helpful to define the criteria as well as the weights and
importance of each in order to distinguish the “right” projects. A uniform evaluation
scheme is absolutely central and mandatory. The evaluation criteria can also be
grouped into categories. Figure 2.80 shows typical categories in project evaluation.
By means of a utility analysis, a ranking list with a clear priority order is formed.
208 2 Methodology
Table 2.48 Priority classes and recommendations for action

Priority
class Importance for the company Recommendation for action
Mandatory Legal requirements, existential for the Full implementation
organisation, mandatory software, or
hardware updates
A Strategically aligned and/or high Full implementation, unless
profitability prioritised otherwise due to
interdependencies
B Positive economic efficiency Implementation based on ranking
list taking into account
interdependencies
C Low or negative profitability Do not perform
Priority
Cost-benefit analysis
Project Prio-Class Priority

Urgency 20% P1 Mandatory 1
Contribution to strategy 40% P8 Mandatory 2
Economic benefit 30% P6 A 6
Non-monetary benefit 10% P2 A 7
Total 100% P5 B 12
Fig. 2.80 Typical categories in project evaluation
Tables 2.49, 2.50, and 2.51 show possible evaluation criteria for the categories
mentioned in Fig. 2.80. The assessment criteria are to be individually aligned to the
company. Due to the changing environment of the companies, these assessment
criteria need to also be continuously adapted to the latest circumstances.
As the end result of the evaluation of the projects, a prioritised project list
becomes available.
Table 2.49 Evaluation criteria for the urgency category

None Small Medium Large
Criterion (0 points) (1 point) (2 points) (3 points)
Mandatory—Legal, regulatory, No – – Yes
compliance constraints
Mandatory—Technological No – – Yes
constraints (HW, SW, security
updates)
Introduction date postponable By 3 years By By 1 year Not movable
2 years
Stage at which the project is Idea, Concept Early Late realisation
preliminary phase realisation phase,
study phase introduction
Table 2.50 Evaluation criteria for the category contribution to the strategy
Contribution to the achievement of No 25% 50% 100%
strategic goal XY contribution
Reduction of ICT costs No 25% 50% 100%
reduction
Increase customer loyalty/customer No increase By <5% By 5– By
satisfaction 10% >10%
Opening up new markets No – Partial Yes
Creation of competitive advantages No – – Yes
Creation of innovation No – – Yes
Table 2.51 Evaluation criteria for the categories economic and non-monetary benefits
Net Present Value, NPV Negative =0 – Positive
Return on Investment, ROI > 3 years 2 years 1 year <1 year
Expected benefit, added value None Low High Very
high
Image gain No – Partial Yes
Increasing attractiveness as an No – Partial Yes
employer
Improvement of quality, reduction No reduction in By <5% By 5– By
of error rate error rate 10% >10%
Building up internal knowledge No – Partial Yes
Minimising risks/lowering the risk No reduction By <5% By 5– By
index 10% >10%
210 2 Methodology
2.7.1.5 Content Dependencies

The next step is to clarify the dependencies between the projects in terms of
content:
• What are the relationships among the projects?

• What are the interdependencies between the projects in terms of content?
• What synergy potential exists?
• What risks arise when adding up the projects?
• When is the right time doing them?
• Would all projects be conducted right now?
– If the professional dependencies and risks were low.
– If human and financial resources were to permit it.
If one project is dependent on the outcome of another, this can lead to needing to
make adjustments in the prioritised project list. In order to analyse the dependencies,
in-depth knowledge of the content of the individual projects is essential. Since this is
lacking in many places, making a dependency analysis is often neglected.
2.7.1.6 Resource Availability and Dependencies

The resource availability and dependencies must be clarified next. If several projects
are carried out in a company at the same time, which access the same resources in
whole or in part, resource conflicts can arise in the case of personnel resources
(specialists) or special equipment and machinery. Multi-project planning needs to be
carried out by those responsible for resources, managers, or department heads, as
Fig. 2.81 shows.
The project managers plan the projects in terms of activities and deadlines
(project view) and inform the line of their resource needs and wishes regarding
preferred resources with a time dependency. The line manager, who has the
resources, has to merge the needs of all projects into a resource deployment plan
across all projects and all resources for which he is responsible. In addition to this, he
needs to take into account all the basic loads for each employee: line tasks, absences,
secondary tasks, etc. The resource plan that the line creates for every staff member
represents all the tasks for that specific staff member across all the projects each is
involved in.
In multi-project management, the availability of resources can also be deter-
mined by comparing required and available personnel resources across all
departments. In doing so, the overload or underload of each individual employee
is determined.
Regardless of whether the review of resource availability and resource
dependencies is done at the level of the department or at the level of the whole
organisation, the question is whether the right human resources are available to a
sufficient extent.
Management
Projects Department A Department B Department C Externals
Resources 2 3 4 5 6 7 8 9 X
1 20% 3 4 X
2 20% 2 5 6
3 4 7 8 9
4 40% 2 4 6 X
Fig. 2.81 Multi-project structure
2.7.1.7 The Project Portfolio

The consideration of the content-related dependencies and the resource availability
and resource dependencies lead to adjustments needing to be made in the prioritised
project list. The end result is the project portfolio that is to be then implemented.
The project portfolio is an overview of all existing projects, which are presented
in the form of a structured list or graphically, ordered according to different criteria.
The organisation is free to distinguish between different types of projects, such as
internal and external, short- and long-term, highly complex and standardised or
customer as well as infrastructure projects.
For the graphical representation, projects are often presented according to two
important evaluation criteria, see Fig. 2.82. Depending on the nature of the projects,
a breakdown into dual opposites, such as opportunities vs. risks, costs vs. benefits, is
already sufficient for this purpose. Frequently, several such views are created about
one and the same project. However, a project portfolio can also be structured in a
multi-dimensional way:
• Contribution to strategy implementation

• Urgency
• Economic criteria (key figures, market)
• Ecological criteria
• Opportunities, risks
• Must criteria (new laws, technological leaps)
212 2 Methodology
Criterion 1
P4
P7 P5
P3 P6
P2 P8
P1 P9 P10
Criterion 2
Fig. 2.82 Example project portfolio
As shown in Fig. 2.82, the costs of the projects can be visualised using areas of
different size for the projects displayed.
2.7.1.8 Reporting
The reporting in the multi-project management process focuses on the entirety of
on-going projects and is based on controlling in the individual projects. Reporting
helps to control the project portfolio and to identify the need for action. Reporting
can be structured as follows:
• Progress checks: Is the project on track?

• Checking results: Were the objectives achieved?
• Reviews: Are the strategic direction and priorities still right?
For progress monitoring at the project portfolio level, for example, the monthly
reports of the individual projects are consolidated, as shown in Fig. 2.83.
The control of results takes place in a first step at the project level. At the end of
the project, there is a check whether the set objectives have been achieved and the
planned effect has occurred. At the multi-project management level, the results are
consolidated and merged.
Reviews focus on multi-project management itself and take place on a quarterly,
semi-annual, or annual basis. The purpose of this is to review the strategic relevance
of the multi-project configuration and to identify any need for adjustment. Further-
more, the evaluation criteria for prioritisation are to be reviewed.
As of: June 1, 2022
September
Deadlines
on track PL escalation Exec. Brd. escal completed
October
Quality
Scope
Cost
Risk
Project name Start End Current Phase
Belflower 5-2021 1-2022 04 - Realisation
Dandelion 10-2021 3-2024 01 - Commissioning
Edelweiss 1-2019 4-2023 04 - Realisation
Hibiskus 10-2020 4-2023 02 - Initialisation
Lily 12-2020 4-2021 05 - Introduction
Rose 1-2014 5-2022 04 - Realisation
Tulip 9-2020 6-2021 05 - Introduction
Violet 4-2020 6-2022 04 - Realisation
Fig. 2.83 Example of monthly reporting at portfolio level
2.7.1.9 Steps Towards an Excellent Portfolio Management

The development of portfolio management takes place in stages and lasts for several
years. Table 2.52 shows the possible stages in the development of excellent portfolio
management.
Table 2.52 Steps to excellent portfolio management

Level Destination Services Activities Duration
Information • Transparency • Overall view of • Common project After
• Overview current and key data 0.5–1.5
planned projects • Uniform reporting years
• Basic evaluations • Uniform
of the portfolio processing grid for
(costs, progress) projects
Methods + • Harmonised and • Comprehensible • Standardise project After 2–
Processes enforced procedures, evaluations of development and 3 years
methods and tools ideas/projects reporting processes
• Analysis of • Introduce methods
project • Form functional
relationships organisational unit
• Portfolio (define roles)
reporting with
recommendations
Excellence, • Actively managed • Dedicated • Integrate project After
strategy project landscape evaluations on and resource >4
orientation • Evidence of effort and impact management years
effectiveness via key • Planning- • Connect/integrate
figures relevant analyses strategy process
for all stakeholders • Operate CIP
214 2 Methodology
To reach a level of excellence, critical success factors include the following:
• Criteria and methods have to be adapted to the company: What is important?

• Prioritisation system provides clear and unambiguous solutions
• Consistent and stable project evaluation methodology and criteria over time
• Prioritisation system is transparent and comprehensible to all stakeholders
• Data quality is a prerequisite for a good result
• Defined and lived process for multi-project management
• Support from top management
2.7.2 Lean Portfolio Management
The shift to agile approaches is in full swing in companies. The pace of change and
market upheaval is forcing companies to evolve from traditional portfolio manage-
ment to lean portfolio management.
The prerequisite for the application of the lean portfolio management approach is
the introduction and implementation of agile approaches (e.g. scrum) and scaled
approaches such as SAFe or LeSS (Sect. 1.4.1.3) in the company.
Table 2.53 shows the difference between a traditional and an agile approach to
portfolio management:
The comparison shown in Table 2.53 can be interpreted as constituting polar
opposites. Companies that use rolling planning in traditional project and portfolio
management already come very close to agile approaches. The authors advocate an
ideal middle path, i.e. the use of elements from the traditional and the agile approach.
The following prerequisites should be created for a lean portfolio management
approach:
Table 2.53 Comparison between traditional portfolio management and lean portfolio manage-
ment (based on SAFe)
Traditional approach Lean-agile approach
Employees move from project to project and work Work is passed on to teams and value is
on many different projects at the same time created step by step in the value streams
Project-related budgeting is carried out and the Funding is based on value streams and lean
financing is monitored by the controlling budgets
department
Planning is top-down and projects often follow Plans are value-added and customisable to
inflexible annual plans achieve maximum customer benefit
Control is centralised. As a result, projects are Strategic demand is managed decentrally in
often overloaded the value streams via portfolio kanbans
Detailed project plans full of requirements and Lean business cases are used to prioritise
business cases are prepared before work starts and fund the work that matters most
There is an alignment with work activities driven There is an orientation and focus on results-
by waterfall, corner deadline, or stage-gate oriented value creation
projects
• Lean approach to budgeting, financing, and governance

• Value stream planning and alignment in the teams
• Agile project management
The lean portfolio management approach maximises value output, which means
that planned investments are managed in a backlog in a portfolio kanban system. In
doing so, the business opportunities with the highest value for the customers are
continuously identified and aligned with the work in the teams in the value streams.
This creates a balance between existing implementation capacity and demand for
high value business opportunities and thus prevents bottlenecks.
2.7.3 Programme Management
A programme is the totality of interrelated projects and organisational changes. A

central element is the consistent alignment of a programme with an overarching
strategy (new strategy or periodic revision of the strategy). The programme is used
as an instrument to give more impetus to strategy implementation. In contrast to
this, line organisations strive for stability and for promoting continuous staff devel-
opment. They align themselves with continuous improvement processes that last for
a longer period of time.
By bundling projects under one programme management leadership, the hope is
that there will be a significant improvement in the planning, prioritisation, imple-
mentation, and control of projects compared to the approach of handling these
projects individually.
2.7.3.1 What Characterises a Programme?

Programmes, like projects, have a beginning and a (planned) end: initialisation,
implementation, and completion. A programme relates to one or more strategic
objectives. It has a mission and a vision. The reference to the strategy is an essential
educational criterion for programmes. At the start of the programme, the projects
belonging to the programme may not yet be fully defined. In the initialisation phase,
however, a general rough roadmap for the programme is created. It is necessary to
continuously review the suitability (project evaluation) of individual projects within
the programme with regard to the strategy.
The projects and their concrete objectives and requirements must always be
oriented towards the strategic objectives of the programme. Projects within a
programme are related to each other in terms of content and time. Later projects
within the programme depend on the results of earlier projects.
2.7.3.2 Added Value of the Programme Organisation

The introduction of a programme organisation has to add value. The following added
values (drivers) are derived from programmes:
216 2 Methodology
• The programme directs a theme professionally and thus creates coherence.

• The formation of programmes leads to more transparent planning and control,
especially of financial processes: Top-down, consistent alignment with strategic
objectives, “breaking down” of objectives.
• The quality of the project definitions should be better in the sense of providing a
better alignment of the project objectives, outputs, and their expected effects on
the strategic fields of action. The quality of the project definitions should be
better, i.e. lead to a better alignment of the project objectives, the deliverables, and
their anticipated effects on the strategic fields of action.
• The importance of individual projects within the programme with regard to the
strategy is continuously monitored.
• In necessary decisions on the prioritisation of projects within the same
programme, the decision is removed from primary line interests (“this is impor-
tant”) and instead guided towards consistent alignment and assessment of the
contribution to the achievement of the strategic objectives.
Another advantage lies in the decision-making hierarchy, which is in line with the
status quo:
• The executive board determines strategy and means.

• The programme keeps an eye on the desired objectives at the tactical level.
• The projects, once defined, have a predominantly operational focus.
2.7.3.3 Distinction Between Project and Programme Management

Table 2.54 shows the differences between project and programme management.
2.7.4 Project Management Office: PMO
More and more organisations see the need to manage, control, and monitor their
project business as a whole. The causes for this range from programme management
control and multi-project planning, competitive pressures, the obligation to demon-
strate the economic and effective use of funds, to managing the workload of staff so
as to avoid their overload and burnout.
Such a staff function exercised by the executive board, which carries out these
tasks, is usually called the Project Management Office (PMO). Other common
names are “Project Office” or “Competence Centre Project Management”. The
respective tasks, responsibilities, and powers of a PMO can be defined in different
ways. The more centrally the management functions of project management are
brought together in the PMO, the more powerful and controlling it becomes for the
whole organisation. Ideally, it becomes the support and competence centre for
projects and defines how projects, programmes, project portfolios, and the day-to-
day business of an organisation can be aligned and managed with maximum
effectiveness. Depending on the maturity of the organisation, functions and tasks
are performed by a PMO. These can be summarised in four core functions:
Table 2.54 Project management versus programme management

Characteristics Project Programme
Changes A project tends to try to minimise A programme expects changes and
changes (deadline, costs, quality) responds to them if they appear
promising in terms of achieving the
strategic objectives
Leadership The main focus is on the execution of The main focus is on relationship
style the project and the creation of the management and the resolution of any
defined, contractually assured conflict situations such as project
deliverables dependencies, programme and line,
conflicts of interest, resource
allocation, capital requirements
Management “Team player”, using skills and Maintaining an overview, emphasis is
style knowledge mainly for team on mission and vision of the
motivation programme
Monitoring Orientation inwards into the project Perspective shifting between projects
and interfaces with projects outside of
the programme. A view that
systematically looks for potential
synergies or risks that could endanger
the programme
Planning Detailed work package planning, Roadmaps as well as rules of action
resource allocation, etc. for project managers regarding
planning (similar to QA
specifications, risk management, etc.)
Scope Usually, a well-defined, limited Scope at programme level is broader
scope is pursued, focussing on the and can undergo changes in order to
content, organisation, and achieve a strategic objective
relationship of the assigned project
Success Customer satisfaction Return on Investment (ROI), KPI,
Deadline, costs, quality achievement of the strategic goal or at
least evidence of impact
• Support function: Support for the individual projects in operational project

work, e.g. writing project documentations and reports and other traditional
back-office tasks.
• Advisory function: advise, coach, and train project managers and project staff,
define and maintain process standards, provide methods and tools
• Coordination function: interfaces and communication management (deadlines,
content and scope, synergies). This includes resource coordination between the
line and the projects.
• Governance, regulatory function: strategic project portfolio management and
project portfolio steering manages project prioritisation and approval of the
project portfolio and project controlling in a multi-project company.
218 2 Methodology
2.7.5 Project Management Handbook
It is highly advisable for a project-oriented company to draw up a project manage-

ment guideline in the form of a handbook that defines the rules applying to all project
processes, making them binding. The project staff will adopt and live this project
culture most quickly if they are able to understand the rules while also finding the
document as a whole helpful, which is the case provided the document is lean and
easy to understand, and if furthermore the employees were involved in the creation
of the document and also if, lastly, useful tools are provided, e.g. templates,
instruments, and checklists.
In the case of complex projects, these guidelines are to be adhered to fully and
strictly. For small routine projects, the steps are adapted to the entrepreneurial needs
and applied in a scaled manner. For important projects, a form adapted to the project
needs can be created. The project management manual is utilised company-wide.
The project manual, on the other hand, applies only to an individual project. Possible
topics in a project management handbook are:
• Scope
• Definition “project”
• Project types (organisation, ICT, product development, infrastructure)
• Project categories (strategic, international, small projects)
• Overview of the process landscapes, value chain, phase plan, milestones, reviews,
releases, traditional and agile approach
• Description of the activities, related documents
• Project organisation, team composition, steering committees
• Responsibilities, competences
• Stakeholder analysis, function diagram, escalation paths
• Scheduling and cost planning, multi-project management
• Information, communication
• Change request management
• Managing the risks
• Project controlling, cost and schedule monitoring, reporting
• Project closure
• Applicable documents, tools, templates, checklists
• Knowledge transfer, continuous improvement process
• Cooperation between line organisation and project organisation
• Competences, responsibilities, project manager career planning
• Glossary
2.8 Creativity and Innovation 219
2.8 Creativity and Innovation
2.8.1 What is the Difference?
The two terms, creativity and innovation, are often and erroneously used synonymously.
Yet there is a clear distinction between the two interrelated approaches they refer to:
Creativity is a thought process that ideally leads to an unexpected or unique idea
for a solution or invention. Whether or not this idea actually turns into something
that works is initially of secondary importance. That is why creativity is difficult to
measure from a business perspective. The focus of creativity lies on originality. It is
therefore about the question of how new ideas come about.
Innovation is the process of transforming this solution idea into a new product or
service, i.e. into something tangible: you can touch it, try it out, change it, make it. And
if it works, then money can be earned with it; a result that can usually be measured. The
focus of innovation is on effectiveness and feasibility. It is about exploiting an idea.
Idea management is that part of the organisation which actively manages new
ideas and suggestions for improvement within it. Ideas can come from employees
but also from customer reactions thereby forming an important pool of ideas.
Extraordinary ideas, giving the company a real competitive advantage, come from
its employees. An environment promoting the development of creative ideas is a
necessary thing. An environment that also allows enough time and space for experi-
mentation, in which employees may fail with their ideas once in a while. In a rapidly
changing business field, projects are often the biggest drivers of innovation for a
company, e.g. when it comes to developing new products to market maturity or seeing
to it that new technologies get accepted and thus become suitable for the masses.
The ability to innovate is therefore one of the critical factors for companies wanting
to remain successful in the long term. What a company can do to achieve this is
described in detail in Sect. 2.8.4. The following section will show which instruments
and methods are helpful for promoting and supporting creativity in the project team.
2.8.2 Finding Creative Solutions
The solution finding follows the goal formulation and is the creative part of a
problem-solving process. In this step of the problem-solving process, the aim is to
identify as many variants as possible after which the suitability of the solution ideas
is examined. The best variants are finally evaluated by means of a systematic
comparison. The methods of solution finding are mostly used in the concept phase
in the traditional approach and in the realisation phase in the agile approach.
In the creative phase of finding a solution, the project team should consciously
step back from the real project environment and its framework conditions in order
not to fall into “old familiar” patterns of solution finding. The more complex the
problem is, the more versatile do different techniques and ways of thinking have to
be applied and combined to find a good solution.
The best way to have a good idea is to have a lot of ideas.

(Linus Pauling)
220 2 Methodology
2.8.2.1 The Creativity Process

Creativity is the ability of human beings to produce thought results of any kind that
are essentially new and were previously unknown to the person who produced them.
Creativity requires above all intuition, intelligence is secondary. Many creative
solutions are prepared unconsciously. The facilitator should create a climate in this
phase that promotes the independence of the team members and the fun of finding
new ideas. The project objectives should appeal to the emotions and thus stimulate
the curiosity of the entire project team.
However, creativity is also often hindered by blockages. Such blockages are
usually created or reinforced unconsciously by ourselves or by external influences
and unfavourable circumstances. Creativity can be positively influenced by:
• A team that is able to work with little tension
• An informal working atmosphere
• Clear tasks and objectives
• The ability to defer judgement
• Different perspectives, optics, viewpoints
• Permission to turn things upside down
• Working with analogies from nature
• Allowing fantasies and images
• Visualisation of all contributions and ideas
Due to the way they work in the creative process, a distinction is made between
intuitive-creative methods and analytical-systematic methods. In a solution process,
several instruments can be applied one after the other, depending on the level of
detail. A creative process takes place in four phases, see Fig. 2.84. These can flow
smoothly into each other.
2.8.2.2 Brainstorming
Brainstorming was developed in the 1940s by the American A. F. Osborn with the
aim of allowing the stream of ideas to flow unhindered productively and effectively
in a problem-solving conference. He separated the creativity process from the
immediate discussion of the suitability of the ideas found.
Prepare
• Assemble a heterogeneous group representing the system (five to twelve people)
• Designate moderator and “secretary” to visualise the ideas
• Determine topic
• Create a productive working atmosphere (space, time, environment)
• Set time frame (20–30 min)
• Announce rules: No criticism, not even non-verbal criticism (evaluation comes
later), quantity before quality, let the imagination run free
Task Define, understand and clarify the task or problem. Collect

1. Preparation information and activate knowledge.
Known solution approaches in today‘s frame of reference.
Preparation Unbiased consideration of the task or problem.
Phase of unconscious further development.

2. Incubation Departure for new approaches, distance from the known
problem, distance from known tasks.
Phase of meaningful insight.

3. Illumination Solution ideas suddenly become conscious in their entirety.
Synthesis of the unsconscious processes.
Phase of reflection and evaluation.

4. Evaluation The idea is checked for its usefulness and feasibility.
Adjustments are still possible.
Fig. 2.84 The creativity process
Perform
• Formulate the problem clearly
• Write down ideas on an on-going basis for all to see
• Let ideas be expressed spontaneously; do not discuss; do not criticise; intervene in
case there is criticism
• Welcome unusual ideas, but also steal ideas!
• Give new impetus when fatigue sets in
Evaluate
• Group ideas
• Evaluate ideas and eliminate unusable ones
• Further concretise useful ideas
• In the case of challenging topics, hand over the ideas to the specialists for
processing
• Give feedback to the group on what has become of the ideas
It has proven helpful in practice to give impulses after the phase of initial fatigue
by the facilitator in order to find the ideas that are “crazy” in the sense of the word in
a second wave (Fig. 2.85).
222 2 Methodology
Ideas
well-known
crazy
withstand silence,
distance, give
new impulses
Time
Fig. 2.85 Course of a brainstorming session
2.8.2.3 Mind Mapping

A more structured approach to finding solutions can be employed using the method
of mind mapping. The topic to be discussed is placed in the centre of the mind map
(Fig. 2.86). The relevant aspects of the given topic are then identified along main
branches attached to it. If further sub-groups emerge from individual aspects during
the discussion, these are in turn attached to the main branch with yet more branches
attached to these. This procedure is particularly suitable if the problem is not a “black
box” situation and some framework conditions are already known and the direction
of the solution is predefined.
The advantages that arise using this method are that it:
• Addresses both the right and left hemispheres of the brain

• Sharpens the memory and increases the ability to concentrate
• Provides a good overview
• Helps save time
• Brings hidden ideas to a more conscious level
2.8.2.4 Brainwriting
This creativity technique is suited for generating ideas based on concrete questions
intending to tackle challenges of simple to medium complexity. It is equally well
Pack up
Closing Cleaning place
Thank you mail

Music / Dance
Entertainment
Bithday Event Shuttle for guests Games

Party
Decoration
Invitations
Drinks
Preparation
Catering Fingerfood
Staff
Fig. 2.86 Example of a mind map
suited for idea enrichment. A brainwriting session (Fig. 2.87) proceeds in the
following steps:
Step 1: Each participant receives a prepared worksheet. At the top of the sheet is the
question that is to be worked on. Below this, there are, for example, three empty
fields on one line, in which each participant is supposed to write out three ideas
for a solution.
Step 2: Depending on the difficulty of the question, the facilitator now sets a time
limit for working on this task. Each participant then develops solution ideas, and
then passes the worksheet to the neighbour on the right.
Step 3: Next, each participant tries to take up, add to, or further develop the ideas
already described by his predecessor. He writes his modified ideas onto the next
free line.
Step 4: The worksheets are passed around until all participants have written a
contribution onto all of the sheets.
2.8.2.5 Scamper
This procedure is based on the model of the “Osborn checklist” (Alex Osborn) and
consists of the following steps (Table 2.55):
224 2 Methodology
Birthday present for mother

Idea 1 Idea 2 Other ideas
A Weekend
describes his Flowers ...
excursion
ideas:
With father she

B Favourite color ...
went several
complements is purple times to ...
ideas of A:
C ... to an island ...

complements with many
ideas of A or B:
Each person starts a worksheet on the top position and has his ideas
complemented by the persons following up.
Fig. 2.87 Example: Brainwriting
Table 2.55 Model Scamper

Substitute Replace: components, materials, and people
Combine Combine: mix with other additional functions or aggregates; overlap with services,
integrate functionality
Adapt Change from: change function, use a part of another element, an assembly, an
aggregate
Modify Increase or decrease: Size, scale, change shape, vary attributes (colour, feel,
acoustics, ...)
Put Find another use (“put to some other use”), find another context for the use, rephrase
the scope of use
Eliminate Remove: elements, components, reduce
Reverse Turn around: turn the inside out, turn upside down, find an opposite use
2.8.2.6 Design Thinking

The successful project manager has to deal with two developments:
• Project managers increasingly find themselves in situations where they are also
responsible for the design and specification of the products to be developed in the
project.
• If the problem-solving process is implemented in a purely factual manner, there is
always the risk that the project, despite a de facto good performance, will be
terminated due to lack of acceptance by important stakeholders and so cannot be

successfully implemented.
Design thinking is an approach to finding solutions with high benefits from the
user’s point of view. The customer or the user is often confronted with products that
do not meet their needs or that do not take their framework conditions into account.
Customer and user do not have to be one and the same person: Just think of the
manufacturer of a ticket vending machine having a transport company as his
customer and the passenger as a user. Design thinking combines a structured,
analytical approach with an intuitive, creative way of working:
• Collect, organise, and evaluate information in a structured way

• Formulate assumptions intuitively, generate ideas creatively, and develop
customer-oriented solutions
Design thinking always focuses on the true needs of the user and helps to create
true innovation. Asking users directly rarely leads to radically new solutions: When
Henry Ford asked people what they wanted, he was told, “A faster horse”. The
innovative answer was a self-moving vehicle, an automobile.
Design thinking adopts proven procedures from the traditional problem-solving
cycle such as using an iterative approach and the basic sequence: problem analysis,
goal definition, and solution search. They are supplemented by further aspects with
the aim of consistently aligning the problem solution with customer benefit, or more
generally: with the needs of the stakeholders:
• Working in flexible spaces: plenty of wall space, flexible furniture, the necessary
tools and materials for visualisation, but also removed locations to work out new
ideas.
• Heterogeneous teams, where lateral thinkers and people with a so-called T-profile
can make a particularly valuable contribution. In the T-profile, the vertical bar
stands for the depth of subject-specific and analytical knowledge that each
participant brings from his or her discipline. The horizontal bar stands for the
qualities of curiosity, openness, and intuition, i.e. the ability to network one’s own
knowledge with that of others and to find a common language.
The method itself consists of six steps, which ideally follow one another, as
shown in Fig. 2.88 shown. However, it is possible to switch iteratively between the
individual steps.
1. Understand the problem
The first step is also called the design challenge and, together with the second
step, is a research phase in which the symptoms are considered so that, building
on this, the problem, the cause, can be reasoned out. Hypotheses put forward and,
if the real problem cannot be identified in this phase, the team develops a solution
that may cause the symptom to disappear, but that probably does not eliminate its
cause.
226 2 Methodology
Defining Find Develop

Understand Observe point of Testing
ideas prototype
view
Problem analysis Solution finding
Fig. 2.88 The six phases in Design Thinking
2. Supplementary information through observation

Based on the human or user-centred design approach, the essential part of the
research is carried out through qualitative investigations with people. What gets
observed is then visualised in order to make oneself and the team aware of
it. After this step, the team members will have become experts.
3. Define position
Now a synthesis is created from the perspective of the stakeholders. A proven tool
for this is the persona, a structured description of an ideal-typical customer
segment for the problem. Personas help to keep the customer’s view in focus.
4. Brainstorming with creativity techniques
Using brainstorming or other creativity techniques, the synthesis is then further
developed with concrete solution approaches and takes on its first tangible form.
Since the team now has a good understanding of the problem from the point of
view of those affected, it is highly likely that customer-oriented solutions will be
identified as such and developed even more.
5. Prototyping
Fast, but iterative prototyping is a central element of design thinking. A prototype
can take on many different forms. Possible examples, for instance, are: Storytell-
ing, paper models, role plays, or first software elements (clickable prototypes).
On the basis of the first prototype, the team will find gaps or inconsistencies on its
own and already be able to correct them.
6. Test and feedback
The prototype is tested with defined stakeholders and then goes into feedback
loops for improvement. It is often much easier for users to make an assessment
based on a concrete prototype than to describe the desired behaviour in a
greenfield way. When testing, it is important to also involve critical stakeholders
in order to have their required acceptance.
In design thinking, the motto is: every failure, if recognised at an early stage, is an
advantage for the progress of the innovation process.
2.8.2.7 Morphological Box

This method, developed by the Swiss astrophysicist Fritz Zwicky, first divides the
problem to be solved into its sub-problems. Corresponding solution ideas are then
developed for each of these sub-problems in order to reassemble them again in
numerous variations to thus come to a solution for the entire problem. This is an
effective method for arriving at astonishing combinations. Figure 2.89 shows an
example of the idea behind this method
In the front column on the left, the sub-problems, properties, functions, or also
sub-objects (called parameters) are taken down. Ideas for solutions (partial solutions)
are written onto the horizontal axis for each sub-problem or sub-object, or they are
indicated with a sketch. Drawing up a morphological box is somewhat time-
consuming but it is one of the best methods for developing new solutions. This
systematic written matrix also makes it possible to retrace the creative process later
and to thus optimise the individual sub-steps leading to the best overall solution.
2.8.2.8 Analogy Method

This method uses the recognisable similarity in form, property, or function of two
phenomena, as shown in Table 2.56 shown. The analogy is between identity
Partial problems Solutions

(Properties) (Characteristics of the partial problems)
Shape of the table plate
Material Wood Metal Stone Glass
Shape of the edge
Support concept
Fig. 2.89 Example: Morphological box

228 2 Methodology
Table 2.56 Procedural steps of the analogy method

Step 1 Set the desired property or function
Step 2 Look for role models that have similar characteristics or functions
Step 3 Investigate the system that possesses or produces this property or function.
Step 4 Check whether and how the mode of action is transferable
(complete sameness) and diversity (complete dissimilarity). This approach proceeds

in the following steps:
Bionics is a word combining the nouns biology and technology. Bionics looks for
solutions by studying and replicating models found in nature.
Synectics (Greek = to connect something with each other) tries to form new
analogies by alienating the original problem and thereby finding new and surprising
approaches to solutions.
2.8.2.9 Appreciative Inquiry

The appreciative inquiry (AI) method is a fully affirmative and research-based
process for change and transformation developed by David Cooperrider. It involves
working on a problem at hand through “appreciative inquiry”, doing so via the
following steps and questions:
1. Defining the goal of the problem solution: What do you really want to achieve?
Do you want to “just solve the problem” (first-order solution) or do you want to
use the problem as an opportunity to solve others (second-order solution)? Where
do you want the process to lead you?
2. Where in your day to day activity do you find examples of the problem being
absent and what do you see there instead of the problem? What do exceptions
look like?
3. Where do you find examples of situations in your practice where these learning
and development objectives are already a reality? What strengths and qualities
become visible in these particular situations?
4. What would your practice or work look like if these learning and development
objectives were already implemented? What would be different to the way things
are now? How would you be able to discern that?
5. What is the biggest challenge in creating this situation? In which direction would
you have to extend your efforts in earnest?
6. Which of your strengths, talents, and resources can you use to solve this problem
while at the same time achieving your development goal?
2.8.3 Evaluate and Decide on Solution Ideas
The solution ideas for the individual sub-problems are partial solutions. Only the
combination of solution ideas for all sub-problems results in a multitude of, often
new, overall solution variants. Creativity methods produce a large number of

possible solution variants, sometimes even unusual or seemingly impossible ones.
Not all combinations of ideas are useful as solution variants.
2.8.3.1 Analyse and Optimise Solutions

In a first pre-selection, these solution variants are initially measured against the
elimination criteria. If comprehensible partial solutions are available, for example as
the result of a “morphological box” (Sect. 2.8.2.1), it becomes possible to optimise
overall solutions by analysing the weaknesses of individual non-useful or subopti-
mal partial solutions and by replacing them if possible. For a sensible choice of
solution, at least two variants are needed, whereby one of these can also be the
existing current solution, the “zero variant”.
Projects are characterised by their not pursuing a single solution in a linear way,
rather by always providing several variants to choose from. The many ideas that
have arisen need to be condensed into different variants. By combining known
partial solutions, it is possible to shape suitable solution variants. The project team
with its expertise first optimises and then limits the number of variants through
selecting. The aim of creating variants is to expand the solution space. In this way,
unsatisfactory partial solutions are systematically improved, solutions are optimised
according to certain criteria (e.g. costs, weight), and “all” conceivable possible
solutions to a problem are found. The goal is to first narrow down the solution space.
In the concept phase of the traditional approach, the overarching solution
concepts are elaborated in several solution variants. In large projects, it is advisable
to have rough solutions confirmed by the project owner before the necessary detailed
solutions are prepared for the realisation phase. The design of products and processes
is becoming increasingly customer-specific due to the increasing transparency and
globalisation of markets. Many products are offered in variants. In improvement
management, an additional consideration of the product life cycle, i.e. of product
usage circumstances (e.g. knowledge from complaints processing) and the produc-
tion context (products, processes, and facilities) must be included in the creation of
variants.
2.8.3.2 Decide
Making decisions is often a very demanding activity and is therefore sometimes
consciously or unconsciously delayed, delegated, or carried out carelessly for
precisely this reason. In many cases, good alternative solutions are available,
which are then not selected due to a messily made choice of a particular solution,
be it for personal, political, or even largely inexplicable reasons. “Deciding” means
to give up, to part with, different alternatives in favour of a possible chosen variant.
Every assessment and decision is to a certain extent subjective. In the book “Fühlen,
Denken, Handeln” (Feeling, Thinking, Acting), Gerhard Roth comes to the follow-
ing conclusions: “All our conscious decisions, even those made after long periods of
thought and consideration, are prepared and created by means of unconscious
processes. Emotions have the first and the last word in decision-making processes.
There are no purely rational decisions. Rationality and intellect are only advisors for
230 2 Methodology
decisions. The brain always decides on the basis of an expected reward situation.
Avoiding or reducing unpleasant conditions is also a kind of reward. Reward
expectations are mediated by feelings. it is first and foremost the emotional experi-
ence system that gives rise to desires, intentions, and plans, deciding whether what is
planned should really be carried out now and in this particular way and not
otherwise. This guarantees that we always perform all of our actions in the light of
past experience. However, this does not exempt us from making wrong decisions.
Understanding and reasoning are necessary for evaluating complex, detailed
situations, retrieving and applying expert knowledge, assessing medium and long-
term consequences—especially in the social sphere—and comparing alternative
courses of action. Reason and intellect do not decide anything. This is done by the
emotional system”. (Roth, 2001, p. 445).
2.8.3.3 Utility Analysis and Sensitivity Analysis

For project management, this means that decisions, whether they concern new
products, processes, or other behaviours, need to be prepared in such a way that
they can be understood. By far the most common systematic method for this in
practice is the utility analysis. The method looks objective, but accumulates subjec-
tive judgements. The utility analysis is carried out in four, at the most five steps:
1. Determine and weight assessment criteria

2. Assign values for the variants
3. Multiply weights by the assigned values
4. Determine the weighted total results in the utility values
5. Analyse the sensitivity of the results
In the preparation phase, a scale of points is placed over all the evaluation criteria.
For the evaluation it is convenient to choose a meaningful and familiar scale
(e.g. 1–10). It may be of importance whether a neutral value (e.g. the 3 in the
scale 1-2-3-4-5) is to be allowed or not. Accordingly, an odd or even scale is to be
chosen. The weight multiplied by the value gives the partial utility (or partial utility
value) of a solution variant with regard to an assessment criterion. Values can also be
assigned to the data of the individual variants (see example in Table 2.57). If a
variant does not meet an elimination criterion, it is not further used as a solution
variant in the utility analysis.
The decision-makers either evaluate the individual variants and target criteria
together, doing this by negotiating the values (consensus) or the values are deter-
mined as an average of their grading.
The total values are determined as a factor for the individual solution variants.
The solution variant with the highest degree of target achievement thus fulfils the
calculated utility value (see example in Table 2.58). For many people, the purchase
of a car is a good example of how an apparently rational decision can soon come to
collide with emotions.
If the evaluation of the variants results in relatively close overall utility values, the
question of the randomness of the results and thus the ranking arises. In such cases, a
Table 2.57 Example: Value tables for “Car purchase”

Consumption Purchase price Operating costs
Criteria (l/100 km) (€) Range (km) (€)
Weighting 20% 50% 10% 10%
Vehicle A 5.5 21,800 620 4800
Vehicle B 4.5 29,800 850 3200
Vehicle C 5.8 25,500 500 3900
Table of values Table of values Table of values Table of values
6 l = 1 pt 30,000 € = 1 pt 400 km = 1 pt 6000 € = 1 pt
5 l = 4 pts 26,000 € = 4 pts 600 km = 4 pts 5000 € = 4 pts
4 l = 7 pts 22,000 € = 7 pts 800 km = 7 pts 4000 € = 7 pts
3 l = 10 pts 18,000 € = 1000 km = 3000 € = 10 pts
10 pts 10 pts
Table 2.58 Example: Utility analysis “Car purchase”

Vehicle A Vehicle B Vehicle C
Elimination W Fulfilled? Fulfilled? Fulfilled?
criteria
Consumption < – Yes Yes Yes
6 l/100 km
Purchase price < – Yes Yes Yes
30,000 €
At least 5 seats – Yes Yes Yes
Optimisation W V W×V V W×V V W×V
criteria
Consumption 20% 2.5 0.5 5.5 1.1 1.6 0.32
Purchase price 50% 7 3.5 1.0 0.5 4.0 2.0
Reach 10% 4.0 0.4 7.8 0.78 2.5 0.25
Operating costs 20% 4.6 0.92 9.4 1.88 7.3 1.46
Total utility 100% 5.32 4.26 4.03
value
Degree of target 53% 43% 40%
achievement
Legend: W, weight; V, valuation; W × V, partial utility value
sensitivity analysis helps. That is, weights or values are slightly changed and their
influence on the ranking is observed. This sensitivity analysis determines how stable
or sensitive an evaluation result turns out to be in the face of changed assumptions. If
there is any doubt about the result or the ranking, the completeness of the
optimisation criteria and their weights should be carefully checked. A risk analysis
could also be consulted. If a solution involves high risks, it should be possible to
assess this in the target criteria.
Exclusion criteria, required or must-have objectives or framework conditions
are mandatory, even if it all costs more or even if it takes longer. These include,
above all, laws, safety regulations, and possibly also standards. The precise defini-
tion of an elimination criterion requires that its achievement can be clearly assessed
232 2 Methodology
at the latest at the end of the project. When comparing different solution variants,
elimination criteria are only answerable by either a “yes” or a “no”. If clear criteria
for a “yes” are absent, discussions are taken up about the achievement of objectives
and the feasibility of the project. If the requirement of clear assessment cannot be
met, an objective cannot formally be an elimination criterion.
Optimisation criteria are objectives without elimination character. They are
often referred to as “target objectives” or “desired objectives”. Since these
preferences can be very sizeable and often contradictory, such as cost objectives,
on the one hand, and cost-generating performance and quality objectives, on the
other, optimisation criteria must always be provided with an additional indication:
the weighting. The weighting is easiest to understand if it is expressed in the form of
per cent values. Such a weighting is usually negotiated in the team, but it always
remains the subjective result of the assessments made.
2.8.4 Innovation Management
Innovation defines who wins and who loses.
True innovation cannot be planned and controlled deterministically. Luck and

chance are the constant companions of innovations. But at the same time, the
probability of success of innovations is greatly increased by the use of a selection
of instruments and processes, combined with innovation-oriented leadership and a
strong culture of innovation. Innovation is controlled chance. The three levels of
innovation management are:
• Normative: discussion of vision, mission values, and mission statement

• Strategic: central source for market differentiation and cost reduction
• Operational: focus on the design and management of the innovation process
Concepts for the following dimensions are to be created:
• Innovation strategy
• Innovation process
• Innovation controlling
• Innovation structure
• Customer orientation
2.8.4.1 Innovation Strategy

An innovation strategy primarily defines the desired goal, which can be derived from
the company’s vision and mission statement. The optimal innovation strategy
depends on the selected markets and has to integrate aspects of technology, compe-
tition, and customer needs. The following dimensions are developed from this
consideration:
• Competitive innovation strategy (competitors)

• Market-oriented innovation strategy (customers, requirements)
• Technology-oriented innovation strategy
• Time- and resource-oriented innovation strategy
• Cooperation-oriented innovation strategy
2.8.4.2 Innovation Process

From the development of the first ideas until the moment of the market launch, the
innovation process is divided into successive stages. With each stage, the project
becomes more concrete, but also more cost-intensive. At the end of each stage are
quality control points, so-called gates. Hence, this model is called the stage-gate
process. In this context, the term “technology roadmap” is also often used, which
refers to a prioritised sequence of technological developments in a company.
The path from an idea to market success is often difficult to plan and fraught with
various risks. Equal attention to market, technology, and yield concerns, combined
with a systematisation of the product development process, provides the best chance
of actually introducing a new product successfully to the market. It is not that
important how many stages and control points get built into the process and what
these are then called and how they are described in detail. It is crucial that the process
is actually lived and that the following five questions can be answered in the
affirmative:
1. Does the product really interest the customer?

2. Can the product also be realised technically?
3. Does the product support the company’s core competencies and its strategy?
4. Is the company really better than the competition?
5. Can the company also make a profit in the end?
6. Is innovation controlling established?
2.8.4.3 Innovation Traps

The Customer Trap
The customer’s wishes are neither recorded in time nor precisely enough and the
product is therefore developed “past the market”. It is the technically feasible and not
the product actually desired by the customer that is realised.
The Technology Trap

Unforeseeable technical difficulties in the development or production are
underestimated and the product fails while still in development or it cannot be
brought to market in a reasonable amount of time.
The Competition Trap

Products do not offer sufficient advantages over existing competitor products.
Competitors bring an equivalent product to the market first. The in-house develop-
ment either becomes a “slow seller” or it has to be sold below value.
234 2 Methodology
The Profitability Trap

The product is sold, but is not profitable because the costs for development,
production, and marketing were underestimated, or the achievable prices, quantities,
and thus revenues were overestimated.
2.9 Procurement
In many projects, goods or services have to be purchased in order to be able to

provide the required service. Depending on the agile or traditional approach in the
project, the procurement procedure needs to first be chosen well and then adapted.
Depending on the organisation, guidelines or laws are to be taken into account for
the implementation of a procurement. Such guidelines define the procurement
process and are binding for projects to comply with. Public project owners have to
comply with legal regulations and are also forced to follow the traditional procure-
ment procedure in the agile approach, unless the legal possibilities allow for a
dialogue procedure. In such cases, resources are often purchased traditionally by a
company. The cooperation with the company’s employees in the project then takes
place in an agile manner.
2.9.1 Procurement Procedure in the Agile Approach
Ideally, a product objective (product concept) (Sect. 2.4.2) and an initial product
backlog (Sect. 2.4.3) will already have been worked out before the start. The role of
the product owner (Sect. 2.3.8.4) should not be bought externally to ensure know-
how. Procurement in the agile approach is about the purchase of the most suitable
resources. For this, it is advisable to realise a small test project together with several
suppliers. The process involves that you:
• Clarify procurement needs

• Select suitable providers
• Implement the pilot project
• Negotiate the contract and finalise procurement
This procedure is also called the dialogue procedure. For the purchase of goods
and other services, the same procedure can be followed in the agile approach, or
purchasing can instead be handled as in the traditional approach.
2.9.1.1 Clarify Procurement Needs

First, it is clarified and defined what it is exactly that is to be procured: Personnel,
service, etc. Should individual people be procured for the team or a whole team? In
addition, it ought to be considered how many people will be needed and for
how long.
2.9 Procurement 235
2.9.1.2 Select Suitable Providers

The first step is to identify potential suppliers. Based on the product concept (product
goal), the initial product backlog and the procurement needs, a questionnaire is
developed for the suppliers in a second step. Possible topics for this
questionnaire are:
• Presentation of the company

• Staff structure: are resources with the necessary skills available?
• What would a possible project team on the part of the provider look like?
• Experience and references with similar projects
• Assessment of the complexity of the project to be realised
• Proposal for a project procedure: project organisation, roles and responsibilities,
risk management, quality assurance
The identified providers are now sent the questionnaire, the product concept
(product objective), and the initial product backlog. In the next step, the providers
present their proposed solutions and answer to the questions to the evaluation team.
Finally, two or three providers are selected for the implementation of a pilot project.
2.9.1.3 Implementation of a Pilot Project

During the implementation of a pilot project, the task is to select the best from among
two to three invited providers. During the presentation, the companies will show
themselves from their best side. Only through actual cooperation do you find out the
mindset, the way of working, the way of communication, the chemistry between the
people involved, etc. Therefore, you have each provider implement a small pilot
project with their own team during, for example, a sprint of 2 weeks. After 2 weeks,
in addition to being able to see the personal relationship and chemistry between the
people involved, the concrete result can also be assessed. It is also possible to
evaluate the efficiency of the provider’s staff. Based on the insights thereby gained
and other decision criteria (e.g. price), the final provider is then selected.
2.9.1.4 Negotiate Contract and Finalise Procurement

A contract then gets negotiated with the selected provider; those not included in the
project will be informed.
2.9.2 Procurement Procedure in the Traditional Approach
The process for comprehensive procurement is divided into the following steps
where you need to:
• Clarify procurement needs

• Create procurement plan
• Create tender documents
236 2 Methodology
• Carry out tender and evaluation

• Negotiate contract and finalise procurement
For smaller procurements, individual steps can be omitted. The duration of an

acquisition process strongly depends on the complexity of the procurement item and
the applicable specifications. Simple goods and services can be purchased within
days or weeks. For complex procurements, the whole process can take several
months. The duration for the implementation of procurements has to be taken into
account in the project planning.
2.9.2.1 Clarify Procurement Needs

The first step is to clarify and define what exactly needs to be obtained. The
procurement has to be clarified in terms of the type of resource to be provided
(personnel, tools, materials, services, partial deliveries, etc.) and its quantity. Pro-
curement need is most easily formulated in the form of a specification (Sect. 2.3.3).
Depending on the complexity, it can take several weeks or months to draw up such a
specification. If there are precise ideas of the object of procurement, the description
itself can also take the form of such a document (Sect. 2.4.5).
Strategic considerations also play a role in the procurement of goods or services.
In a project for internal process optimisation or in a product development project, it
must be considered very carefully what one’s own core competence and the critical
success factor or USP (Unique Selling Proposition) is. Competences in the area of
critical success factors or the USP must be built up oneself and not procured
externally.
2.9.2.2 Create Procurement Plan

In the procurement plan, procedure and important key points for the process are
recorded. The procurement plan is often also referred to as a procurement or tender
concept. The procedure is coordinated with the requirements of the line organisation
(procurement guidelines) and the legal basis. The procurement plan has to be taken
into account in the project planning and can strongly influence the project planning
depending on the duration of the procurement. The procurement plan provides
answers to the following questions:
• What is the object of procurement, what is to be procured and in what quantity

and quality?
• What are the expected costs for the procurement item?
• What is the estimated financial procurement volume?
• Do strategic partnerships or contracts with suppliers already exist that need to or
that can be taken into account?
• What does the market look like? Which and how many potential suppliers are
there?
• Which tendering procedure or procurement method should be used?
• What are the parts making up the tender documents?
2.9 Procurement 237
• What is the detailed planning in terms of deadlines and lead times for the
implementation of the tender?
• What resources are needed to carry out the tender? Who is responsible for which
activities?
Table 2.59 shows the procurement methods and their differences.

When choosing the tendering procedure, a distinction has to be made between
private companies and public contracting authorities. In the case of contracting
authorities, there are defined threshold values (financial procurement volume) that
determine the tendering procedure. For contracting authorities, a distinction is made
between the procedures according to Table 2.60.
Private companies are free to procure in any way they want and are not bound by
any threshold values, which means that you can write directly to potential suppliers
in procurement or publish a procurement on a suitable platform and put it out to
tender.
Table 2.59 Procurement methods

RFI: Request for The RFI checks whether the outlined needs can be met by potential
information providers. Non-binding price and performance information is obtained.
RFI is suitable for market clarification
RFQ: Request for Requesting non-binding prices for a defined procurement item. For this
quotation purpose, there should be an elaborated set of specifications or a
performance specification
RFP: Request for RFP is the tender in the narrower sense. Binding offers and contract
proposal specifications are obtained before the contract is drawn up
Table 2.60 Tender procedure

Invitation procedure, A defined number of companies are contacted and asked to submit an
restricted invitation RFI, RFQ or RFP
to tender
Open procedure The tender documents are published publicly on a tender platform. All
interested and suitable companies can submit a bid
Selective procedure, In a first step, pre-qualification documents are published publicly on a
non-open procedure tender platform. All interested and suitable companies can apply to
participate in the tender. The tendering body will then select at least three
suitable companies. In the second step, the request for proposal (RFP) is
carried out with the pre-qualified companies in camera. This procedure is
suitable for highly complex procurements (e.g. new rolling stock for a
railway company)
Contract by private A contracting authority may award contracts directly. This procedure is
treaty, negotiated only used for small contract volumes or in special cases. No tendering
procedure takes place, the contract is awarded directly and the award needs to be
justified
238 2 Methodology
2.9.2.3 Create Tender Documents

Once the object of procurement and the procedure have both been clarified, the
tender documents can be drawn up. The preparation of the tender documents is a
time-consuming process and usually takes longer than the execution of the actual
tender. The tender documents consist of the following documents:
• Main document (often referred to as specifications, tender documents or, in

practice, often incorrectly as requirements specifications)
• Suitability criteria
• Award criteria
• Description of the object of procurement
• Draft contract
Specifications, Tender Documents

The main document is the overarching cover document of the tender documents. It
serves as an orientation for potential bidders and regulates the course of the procure-
ment procedure. Typical contents are:
• Description of the project owner

• Objective of the procurement
• Procurement basics
• Deadlines and dates
• Description of the actual situation
• Rough description and requirements for the object of procurement
• Contractual regulations (draft contract)
• Assessment and evaluation of tenders: Explanation of the selection and award
criteria, forms to be used, indication of how tenders will get evaluated.
• Equipment of the offer: its structure and outline
• Administrative: contact point, dealing with questions, regulations on partial offers
and variants, inclusion of subcontractors, admission of bidding consortia, place of
performance, language of the offer
Individual contents can be very comprehensive and attached as a supplement to

the main document.
Suitability Criteria
The Suitability criteria describe the minimum criteria that a bidder has to fulfil. These
are often requirements for the bidder in terms of performance, experience, or
references. Minimum requirements for the object of procurement can also be
formulated. Suitability criteria are to be fulfilled by the bidding company.
Companies that do not meet the suitability criteria are excluded from the procure-
ment procedure.
2.9 Procurement 239
Award Criteria
Award criteria are used to determine the best offer. The award criteria serve to assess
the quality and price of the service offered. It makes sense to declare these, their
weighting, and how their fulfilment are already evaluated with the publication of the
tender documents. This information is important for potential suppliers to be able to
assess whether they want to make a bid at all or not.
Description of the Object of Procurement

In order to obtain good and meaningful tenders, it is advisable to describe the object
of procurement qualitatively well, i.e. precisely and completely. The criteria to be
applied should be analogous to those in the SMART rule (Sect. 2.3.2.4).
Draft Contract
To avoid difficult negotiations before awarding the contract, it makes sense to
enclose a draft contract along with the tender documents.
2.9.2.4 Carry Out Tendering and Evaluation

After the tender documents have been completed and released, they are sent to the
potential suppliers or published on a tender platform. The potential suppliers are
given a deadline for submitting their offers. During this period, the suppliers often
have questions needing to be answered.
After receipt of the bids, they are assessed and evaluated. In a first step, the
fulfilment of the suitability criteria is checked, excluding companies that do not meet
the suitability criteria from the procurement procedure. The best offer is determined
using the award criteria. Depending on the situation, the bidders may be invited to a
bid presentation. Each bid is assessed on the basis of the award criteria. The results of
the assessment are summarised in a utility value analysis on the procurement object
(Sect. 2.8.3.3). The best offer can then be easily derived from this.
2.9.2.5 Negotiate Contract and Finalise Procurement

Often there are still open questions regarding the best offer having to be clarified and
settled with the provider. These questions are clarified together with the negotiation
of the contract. During the negotiation, the principles of conducting negotiations
(Sect. 4.10) must be taken into account.
With the conclusion of the contract, the procurement is completed. All bidding
companies are informed about the award. If necessary, the award will be announced
on the tender platform.
240 2 Methodology
References
Kolb, C. (2014, November 26). Der agile Projektleiter—Bindeglied zwischen Scrum und
klassischem Umfeld. ProjektMagazin, 17.
Kunz, C. (2007). Strategisches Multiprojektmanagement (Konzeption, Methoden und Strukturen).
Gabler Edition Wissenschaft.
Roth, G. (2001). Fühlen, Denken, Handeln: Wie das Gehirn unser Verhalten steuert. Suhrkamp.
Schwaber, K., & Sutherland, J. (2020). Der Scrum guide. http://scrumguide.org.
Further Readings
Andresen, J. (2017). Retrospektiven in agilen Projekten—Ablauf, Regeln und Methodenbausteine.
Carl Hanser.
Cohn, M. (2005). Agile estimating and planning. Pearson Education Inc.
Gloger, B. (2016). Scrum—Produkte zuverlässig und schnell entwickeln. Carl Hanser.
Schweizerische Gesellschaft für Projektmanagement (spm). (2016). Swiss Individual Competence
Baseline Version 4 Domäne Projektmanagement. spm und VZPM.
Human
3
In project management, humans are players. By definition, several such players work
together in projects and communicate with each other. Therefore, it is important to
understand people better in order to provide them with the appropriate framework
conditions so that they may develop their full potential in project work and collabo-
ration in order to deliver what is expected of them.
In Taylorism, the human being was supposed to function like a machine. But we
now know that man is not a rational being and cannot be explained purely on the
basis of cause-and-effect relationships. Instead, humans are highly complex beings
with identities strongly shaped by their environment, having a brain that changes
shape throughout their lives (neuroplasticity).
Project work is always a personal experience that is marginal, as innovation has to
be created within limited resources. This chapter explains the basic features of the
modern view of man, the topics of stress and change, flow, as well as motivation and
meaning. These form the basis for self-management, which aims at achieving a self-
directed and self-responsible development of personal life. This chapter concludes
with aspects of self-responsible further development and a description of the basics
of interpersonal communication.
People are always the same whether they are working in traditional or agile
project management. The explanations in this chapter refer to both approaches.
3.1 Competence Model
The requirements and tasks for employees can be broken down into different
competences (Fig. 3.1). The methodological competences are elaborated in
Chap. 2. In this chapter, self-competence and personal communication are dealt
with in greater depth. Chapter 4 describes the requirements for social, team leader-
ship and negotiation skills. Depending on the role in the project, there are differently
weighted competence profiles for the individual job holders. For project owners and
project managers, these are presented in Sect. 2.3.8.5 for product owners and scrum

https://doi.org/10.1007/978-3-662-66211-3_3
242 3 Human
Expertise
– As part of
Methodological skills the project role Self-competence
– Project execution – Conception of man, world view
– Planning – Perception & awareness
– Organisation – Motivation & purpose
– Controlling – Self-management
– Information & – Dealing with stress
communication – Personal change &
– Stakeholder Management development
– Risk Management – Culture and values
Team and Social skills

leadership skills – Power & authority
– Position & roles – Personal communication
– Delegation & MbO – Interdisciplinary &
– Dynamics in teams Negotiation skills multicultural cooperation
– Leadership styles & self-control – Leading negotiations – Conflict Management & crisis
– Lead & moderate meetings – Negotiation cycle & – Handling resistance
– Change in organisations strategy
Fig. 3.1 Competence model
masters in Sect. 2.3.8.4. Technical competence results from the respective task of the
project content.
3.2 Conditions for Good Performance
Unfortunately, competences alone are no guarantee for successful project work.

According to Sprenger (2014, p. 183 ff), good team performance depends on three
influencing factors (Fig. 3.2):
• Commitment (Willingness): Every person needs to want to perform a task. In

order to achieve this, they give themselves inner permission.
• Capacity (Ability): Being motivated is not enough for good performance. Per-
sonal skills have to be up to the requirements of the task.
• Performance Capabilities (Allowing): On the one hand, the organisation needs
to allow a person to perform a specific service (social allowing). On the other
hand, the means of production and the capacities needed have to be available.
With optimally developed capacity, performance is strengthened. The commit-

ment to perform and the performance capabilities are not yet influenced by this.
Often, attempts are also made to encourage project teams to reach a higher level of
performance through additional motivational factors. Motivation is what primarily
3.2 Conditions for Good Performance 243
Commitment
Personal Dare
and Desire
• Inner permission
Social Dare • Values, morals,
• Rules and (unspoken) self-esteem
norms • Over- or underestimation
• Organisational culture
Performance Behaviour
Capabilities Performance
Situational Enabling
• Tasks, responsibility and Capacity
competences
• Situational conditions: re- Individual Ability
sources, time budget, tools • Individual skills
and capabilities
• Over- or underchallenge
Fig. 3.2 Conditions of good performance
influences the willingness to perform. Personal capabilities, such as methodological

or technical competences, are not enhanced by it. Performance capability also
remains the same for the time being due to motivation.
Example
A young project manager who is motivated (commitment to perform) and well

trained (capacity to perform) will only succeed if the organisational culture
supports his work (performance capabilities). If he is empowered and respected
by the “old hands” in the company for his function (social permission) and
accepted into the informal network, his ability to act unfolds. In addition to
this, he needs the time resources to successfully complete the task. ◄
The design of the performance capability is probably most often underestimated:

There are always operationally very well-managed projects that fail only because
they do not have a performance capability. The performance capability must at the
244 3 Human
start be provided by the managers of the line organisation. Additionally, the

project organisation itself always gets questioned in order to create optimal
conditions for teamwork. This emphasises the importance of working on the
system (Sect. 1.5.2).
All members of project teams should constantly connect their own performance
to the performance capability. Under very difficult conditions, a project can just
barely be kept on course. However, if the framework conditions are optimal, positive
project results can and need to be expected. Thus, the assessment of personal
performance is like the dependence of light and colour: depending on the light, the
colour appears differently. Personal performance (willingness and ability) is likewise
always dependent on the allowing: given the same performance, much more can be
achieved under optimal conditions than if the performance capabilities make it
difficult.
3.3 Human Phenomenon
3.3.1 The Brain Is a Miracle
Neuroplasticity: The Brain Changes Its Shape

Our brain consists of up to 100 billion nerve cells (neurons). Each individual neuron
is itself connected to 1000–5000 other neurons by synapses. The constituent parts of
the brain only work as a team: a neuron by itself cannot do much. Only when it
connects with thousands or millions of other neurons does it unfold its capabilities
(Esch, 2014, p. 68). A breakthrough in brain research was the realisation that the
brain changes its shape. Neuroplasticity suggests that the brain develops its struc-
ture not only because of genetic markers, but also because of the experiences a
person goes through during their life. When a person learns something, whether in
terms of how to feel, think or act, neuronal networks develop in their brain. The more
a specific neuronal network is used successfully, the more does it develop in the light
of that success. Figuratively speaking, it develops from a trail to a highway.
Neurons wire together if they fire together.
Use it or lose it.
According to this image, the human brain prefers to take the highway. The human
being is said to be a “creature of habit”. He loves the networks of thinking, feeling
and behavioural patterns that he may have developed in childhood. These habits
convey routine, security, and efficiency.
Example
A project manager who has already handled many projects according to the
traditional approach is very efficient in project planning and project management.
3.3 Human Phenomenon 245
If the employer decides to handle the projects according to the agile approach in
the future, the routines and strategies of the project manager are suddenly no
longer helpful. A demand is made of him to deal intensively with the agile
methodology and to, for instance, find his new role as a product owner or
scrum master in it. ◄
Life means change (Sect. 3.5.5). People are repeatedly confronted with the experi-
ence that the existing highways of feeling, thinking and acting are no longer
purposeful. The only way to leave the highway is to train oneself bit by bit to follow
a new behavioural pattern. This is very demanding. In the process, new neuronal
networks develop in the brain, which requires much more energy than calling up the
already existing habitual patterns, in other words: using the autopilot. The good
news, however, is that thanks to neuroplasticity, the human brain can create new
highways, in short, it is capable of learning.
The reverse of this also happens to us humans again and again: neuronal networks
that are not needed for a longer period of time degrade again. The brain has a very
efficient energy-saving mode and functions according to the motto: “Use it or lose
it”.
Example
For the project manager as described above, it is therefore not enough to simply
attend a seminar on agile project management and to then believe that one can
take on the role of product owner again with the same assuredness and effi-
ciency. What he has acquired in years of practice as a traditional project
manager, he must now be able to let go of in part. He deals intensively with
the agile approach and its critical success factors, such as self-organisation,
developing the product vision or building the product backlog. In the process,
his brain maps these new competences as new neural networks. This also means
that his agile training will only bear fruit if he keeps practising the new
approaches. If he is called back into a traditional project at some later point,
he might have a hard time using the traditional planning tools again or develop-
ing a requirements specification. ◄
Where Is the Centre in the Brain?

As part of the human central nervous system, the brain is its supreme organ of
control. For a long time, the question remained unanswerable as to where the
“control of control” was located within the brain itself. Today this function is
assigned to the frontal lobe of the cerebral cortex, the prefrontal cortex. It forms
the government or the executive committee in the brain and characterises the human
species in a general way and each person in particular (Esch, 2014, p. 86). All
experiences a person has in the course of his or her life are stored in the prefrontal
cortex. It is there that, recurring experiences are condensed, the result, ultimately is a
246 3 Human
person’s inner attitude. Since all experiences become part of the brain structure of
each person due to neuroplasticity, new attitudes can only be changed again through
great effort.
What is so special about the prefrontal cortex is that it is a coupled network with
a cognitive and an emotional part. Every experience is therefore stored with the
corresponding emotion. Although attitudes can be rationally justified by humans,
they are always also emotionally anchored and can therefore be felt. For this reason,
personal as well as organisational change that is only rationally justified cannot be
successful. Sustainable change always needs to take place in a secure space in which
people and organisations can make new experiences (Ballreich & Hüther, 2009).
More on this in Conflict Management (Sect. 5.6.9).
From Knowledge to Ability

Reflecting, reasoning and the general functions of intelligence and intellect, also
action control, are assigned to the prefrontal cortex. The knowledge that human
beings over the course of history have acquired, be it in mathematics, language or the
expert knowledge of their professional activity, serves them as a toolbox and is
stored in the cerebral cortex.
Figure 3.3 represents the relationship between data, information, knowledge and
ability: Data is available in abundance in the digital age. Interrelated data becomes
information. Information that makes sense for a person, then becomes specific
Data Information Knowledge Ability
Fig. 3.3 Knowledge and skills (Pfläging, 2015, p. 36)

knowledge. With knowledge we can solve problems. Knowledge becomes ability

when we succeed in solving new, previously unknown problems. This in turn
generates new knowledge. In order to implement knowledge, the boundary between
knowledge and ability hast to be crossed repeatedly. This leads us back to the “trail
and highway” metaphor. An ability that is able to generate new solutions thereby
creates a new trail, which then gets expanded into a new highway through repetition.
Practice makes perfect. Further elaboration on the strategies of personal change can
be found in Sect. 3.5.6.
3.3.2 Basic Needs Determine Our Lives
Mainstream psychology sees human behaviour as goal-oriented and perceives these

goals as being derived from people’s basic human needs (Bamberger, 2005,
p. 283). However, there are different views of what these basic human needs are.
“The basic needs, as they are formed, shape the individuality of a person and have
a great influence on their life” (Largo, 2017, p. 204). The hereditary disposition
creates the organic prerequisites for this and also determines their expression.
However, the degree to which the child can satisfy its individual basic needs depends
on its environment. Thus, depending on how its basic needs are laid out and what
experiences it has, a child can internalise achievement and social recognition as
desirable goals or, on the contrary, pay little attention to them. The attitude gained
from this can lead later in adult life to either a very performance-critical or
performance-oriented attitude. Remo Largo distinguishes between the basic needs
described in Fig. 3.4 below.
Physical Integrity
Satisfying the elementary physical needs forms a basis for satisfying the other basic
needs as well. These include sufficient nutrition, restful sleep, not having to freeze or
sweat excessively, living out sexuality and also physical performance. An essential
component of this basic need is human health. From the healing rituals to the
shamans to modern medicine: humans have always spent a great deal of energy on
maintaining good health.
Feeling of Security
The desire for security and affection is an ancient basic psychological need of human
beings. Without the parents’ willingness to bond, children would not survive, as they
are dependent on their attention. Love is probably the strongest emotion for most
people. It satisfies the human being’s desire for being accepted unconditionally.
Children are enormously dependent on security and attention. In adulthood, this
decreases somewhat, but the need for closeness and attention from familiar people
remains.
248 3 Human
Vital
security
Physical
Performance integrity
Self-development Security
Recognition
Social status
Fig. 3.4 Basic human needs (Largo, 2017, p. 183 ff)
Recognition and Social Status

Humans, like many animal species, can only survive within a community. It is in a
community that our ancestors developed a need for social recognition and a secure
social position. This basic need can be satisfied in very different ways within
communities. For some, the family is most important; for others, professional or
voluntary work, etc. It is not necessary to be a project manager, CEO, club president
or head of the family: “Most people are satisfied when they can occupy the social
position that suits them and when they receive the social recognition they are entitled
to expect on the basis of their performance” (Largo, 2017, p. 193). What is true for
all people, however, is that all people want to be respected in their social position,
however humble it may be. Any form of exclusion impairs well-being.
Self-Development
People want to be able to develop their innate abilities to the extent that is possible.
Even children have a strong desire to develop skills and to acquire knowledge.
However, children as well as adults tend to overextend themselves or to emulate
ideals that they cannot fulfil. “Every child is born with an individual development
potential in terms of the expression and maturation speed of its characteristics and
abilities. Depending on the living conditions in which it grows up, it can realise its
potential to varying degrees. However, even under optimal living conditions, the
child cannot develop beyond its developmental potential. There is no promotion
beyond a person’s individual gifted potential” (Largo, 2017, p. 114). Accordingly, it
is not success itself that is decisive for a person’s well-being and self-esteem, but
whether they succeed in developing their individual talents.
Performance
In their performance, people want to achieve specific results with abilities and skills
they have acquired. People do not only want to perform in order to earn a living or to
achieve social recognition. People also want to perform because that way they can
experience self-efficacy and stimulate their self-esteem.
How important the achievements are for children and also adults can be seen in
our emotions: If we succeed, we feel joy and euphoria. If we fail in an important
undertaking, we feel sad and distressed. If we are permanently underchallenged, we
feel bored and frustrated. Those who are permanently overstrained and can never
experience that they have achieved anything feel disillusioned or even exhausted.
Achievement is also not about every person climbing Mount Everest, running a
marathon or cycling around the world. It is about a person being able to perform at a
level that is commensurate with their abilities or skills.
Vital Security
If people experience a lack of existential security or even lose it completely, this
triggers overwhelming fears in them. People who are affected by poverty, war or
displacement become deeply insecure emotionally as well as psychologically
traumatised.
Humans share an urge to take precautions and to create security with other
species: the squirrel builds up stocks, the mole retreats into its cave system. Humans
first lived in caves, then in stone huts and farms. Today, cities, provision systems or
insurances of the modern world form the basis for an increasing sense of security,
though people view what constitutes security very differently: some want to be able
to pay their living expenses, others strive for wealth and power. For some, providing
for life after retirement is enormously important, while for others that is completely
secondary.
" Every human being is unique. The more choice and freedom to make
decisions a person has in his or her life, the more they will try to shape
their life in such a way that they can live out these freedoms as best as
possible. One person strives more for status and recognition, for others
security is much more important; there is no good or bad in this. But
these expressions needs have an influence on the personality traits,
which can be recorded, e.g. via personality typologies such as Belbin or
MBTI (Sect. 3.10.2). The better a person knows himself, the more he can
250 3 Human
seek out an environment that best suits him, just as the cactus needs
dryness and the reed needs wetness. Those who have a strong urge for
recognition and social status will hardly feel comfortable as members of
an agile team with collegial leadership. If feelings of security and con-
nectedness are important to you, you will not be happy performing the
role of product owner. In this case, it would be better if the two people
swapped roles, provided, of course, that they also have the appropriate
professional skills.
3.3.3 Human Perception
Selective Perception
What we perceive (“take as true”) can never be objective. First of all, our senses have
a “mechanical” limitation. We humans can only see light of certain wavelengths
and only hear sounds of certain frequencies. Nor can we smell, taste and touch
everything. Rather, our perception is a highly complex processing procedure, which
has to always be evaluated purely subjectively and selectively: “The image com-
posed of all these sensory impressions is admittedly not a true reflection of the actual
nature of the external world, but merely the image we can form of this world with all
our limitations”. Man has the unique ability to evaluate his perceptions. He can focus
on specific perceptions from the external as well as the internal world and make them
the centre of attention or leave them in the background as completely insignificant
(Hüther, 2001, p. 103 ff). This perception is different for all people, since it is based
on how intensively specific neuronal perception networks have been developed.
Depending on how strongly we “sharpen” our senses to certain phenomena, we are
then very sensitised to specific perceptions.
In interdisciplinary project work, we become aware of these opposingly “sharp-
ened” perceptions again and again: A technical expert, be it a computer scientist, a
mechanical engineer or an electrical engineer, has a highly differentiated perception
in the area of expertise with regard to the technical problem. These people may be
much less sensitive to disruptions at the relationship level, omissions in the area of
stakeholder management or even the importance of well-prepared and moderated
meetings. This is no wonder, since they have invested decades of education and
training in their domain and have built their professional careers precisely because of
these skills. A product owner, on the other hand, may not get lost in technical
problems at all. On the one hand, he has another function in the team and on the other
hand, he would not have the technical competences to do something outside of his
field of expertise.
" If it is assumed that people have different perceptions and thus different
realities, it becomes obvious that it is advantageous to bring them “to the
table” in order to let a common reality emerge. This is why joint collabo-
ration or agreements are so important. A change of perspective is often
useful: to put yourself in the other person’s place, e.g. the place of the
customer, the user, etc. What is important from their point of view, what
do they expect from the project? This is where stakeholder analysis
comes in (Sect. 2.3.5), the questioning technique (Sect. 3.9.8) or the
integration of other people into the project organisation (Sect. 2.3.8).
Purpose of Our Perception

Our senses also register many more impulses than we could consciously process.
Experts assume that only 5% of our perceptions are really made accessible to
consciousness. The other 95% of sensory impressions remain unconscious
(Stadelmann, 2017). This leads to the question, what is the nature of the 5% of
perceptions that are made accessible to our consciousness? Because survival is our
most important task, all humans are focused on creating as much security in their
environment as possible in order to attain this. Anything that threatens this sense of
security or signals the possibility of danger is therefore central to our perception.
Thus, it can be simply summarised that our perception (unconsciously) focuses on
what threatens our security, thereby requiring intervention. Safety, in turn, lies in
predictability. We do not like to be surprised. Rather, our brain keeps producing new
expectations for specific life situations. And that which deviates from these
expectations is central to our perception. That which does not deviate does not
need much attention and is often also processed unconsciously.
" This phenomenon is important for human behaviour under stress

(Sect. 3.5) and in conflicts (Sect. 5.6): The stressor or the conflict can
completely take over the perception of individual project participants
from one moment to the next. Perception then focuses on this subjec-
tively perceived security-threatening aspect. Everything else that is going
well may be faded out. In this situation, it is important for those respon-
sible for the project to be able to narrow things down with those
affected. Very helpful here, as a technique, (Sect. 3.9.8) is answering
questions such as:
• The relationship with the colleague is very strained. Was there a time
when it was better? If so, what was different then?
• On a scale of 1–10: How are the chances of success for the project
assessed at the moment? What would it take to increase these
chances by one point?
252 3 Human
3.3.4 Awareness and Self-Reflection
Between stimulus and response there is a space. In that space is our power to choose our
response. In our response lies our growth and our freedom (Viktor E. Frankl).
Frankl describes a very special characteristic of the human being: He is self-

aware and therefore has the possibility to reflect on how he deals with the
(selective) perception of stimuli from his environment and how he reacts to
them. This space between stimulus and reaction is created by our consciousness:
According to the Latin term “con-sciencia”, consciousness is an accompanying
knowledge that is aware of one’s own state of mind and activities, but also allows
one to distinguish oneself from fellow human beings and the environment (Rager
& von Brück, 2012, p. 36 ff.). Hüther understands consciousness as the ability to
become aware of one’s own sensations and perceptions, of one’s own “being-in-
the-world”. Thanks to consciousness, primary processing procedures that underlie
the brain’s performance are in turn made the object of cognitive processes (Hüther,
2001, p. 115).
Example
So, we can lead a meeting and be aware of our own state of mind while speaking:
“Do I feel stressed because of a colleague’s critical remark? Or am I talking too
fast because I’m afraid I won’t be able to finish the session on time?” ◄
By being able to reflect on superficial feelings, thoughts and actions at a higher

meta-level, the superficial level can be influenced, for example, by speaking more
slowly or asking the meeting participants if the session can be extended.
According to Frankl, our freedom lies in how the space between stimulus and
reaction is used. Man, unlike animals, is not unconditionally at the mercy of his
feelings and instincts. Rather, he is capable of controlling them through reason and
subordinating them to long-term goals (Rager & von Brück, 2012, p. 93). So if a
person is afraid, he will run away. If someone is made to feel uncomfortable in a
meeting, he does not have to retaliate immediately in the heat of the moment. Of
course, those sorts of feelings do come up in many meeting situations. We may feel
hurt or humiliated. But despite all this, thanks to our consciousness and reason, we
can keep our composure and categorise our being openly criticised by someone, be it
through verbal and non-verbal communication (Sect. 3.9) and then still remain calm.
This process, which summarises the reflections on the phenomenon of man, is
simplified in Fig. 3.5.
Not only perception is context-dependent, but also behaviour. This aspect is dealt
with in Sect. 5.3.2.
Fig. 3.5 Perception and self-reflection
3.3.5 Trust
Trust is a mechanism that allows us to deal with our uncertainty (Christoph Bosshardt).
Life is full of uncertainties. For example, if we were not able to trust that all road
users will likely follow the rules, we would no longer get into a car. Without trust in
the train driver and the train control system, we would no longer get onto a train.
Trust is the basis and prerequisite of every qualified form of human community.
Trust as Experience
Like every human ability, trust is a mixture of genetic predisposition and learned
behaviour. In order for the child to learn to trust, it above all needs a sense of security.
This sense of security comes from how sensitively and predictably the caregivers
respond to the child’s needs (Schneider, 2003). If the reaction of a parent is sometimes
loving and then again there is an outburst of anger, the reaction of the caregiver or
parent is no longer one the child can predict. This does not create security. The child
also cannot build up trust, neither in itself nor in its environment. Trust can also be
“learned” in adult life. For this, stable relationships that provide security are needed.
254 3 Human
Synonym for Trust: Closeness or Connectedness

We trust people or organisations we feel close to or connected to. Trust is, like power
(Sect. 4.9), always a relational matter. What is the basis of relationships? According
to the philosopher Wilhelm Schmid, it is shared experiences. Relationships without
regular shared experiences disintegrate. Family relationships also thrive on repeat-
edly meeting each other and thereby having shared experiences (Schmid, 2010).
Confidence in the Professional World

Everyone wants trust: Politicians want to be trusted by voters, companies by their
consumers, managers by their employees and project managers from their project
owners. However, this cannot be achieved with a wonderful speech or a nice
commercial. What is needed is predictability and a feeling of security in this
relationship with the other person. This is best achieved through interpersonal
contact, which is why formal project communication is a basic prerequisite for
cooperation. But it is only one among many. It, for instance, also needs the
unstructured communication of something like lunch and the aperitif at the end of
the day, so people can interact outside of their professional role and thus develop
closeness and security with each other, making sustainable professional relationships
possible.
Those who lack trust show an excessive need for being in control of things, with a
prevailing inner feeling of being lost. In working life, this is reflected in the inability
to delegate (Sect. 4.7) and in a high degree of perfectionism: superiors who, as
“micro-managers”, want to have every detail under control.
Trust and Psychological Safety

Trust and psychological safety (Sect. 5.4.1) have much in common. The main
difference being that trust is something that is directed towards the future: “I trust
you that I will get the concept by the end of the month”. Psychological safety,
however, refers to the “here and now”: “Because I do not feel psychologically
secure, I do not ask for help”.
3.3.6 Humour
Eckart von Hirschhausen, MD, is convinced that laughter is the best medicine. That
is why he has turned away from his work as a doctor to devote himself to cabaret. He
is a book author and hosts television programmes. Hirschhausen describes the battle
of David against Goliath as a primeval joke of humanity: “The mighty giant Goliath
is struck down by the physically inferior David with his slingshot. Wit wins against
violence. And that is why the creative spirit is such a good weapon, especially when
we ourselves are the enemy: murky thoughts, nasty pain or when the whole world is
against us” (Hirschhausen, 2016, p. 447).
It is a precious human competence to always be able to laugh at oneself. Instead
of being angry and grouchy and judging ourselves harshly when we encounter a
mishap or make a mistake, we can also try to laugh at ourselves. Humour allows
people to not take themselves too seriously, to create an inner distance. Humour
3.4 Culture and Values 255
relaxes and also allows for a sense of detachment, of being less tenacious and better
able to let go. In this way, humour also has an influence on our resilience (Sect.
3.8.4) and on our creativity (Sect. 1.7).
In humour, man experiences that he is a social being. He can only laugh heartily
in a community. Laughing together generates closeness and connection, which in
turn creates more trust.
3.4 Culture and Values
3.4.1 What Is Culture?
Culture refers to norms of behaviour and values shared by a group of people (John Kotter).
Culture is the totality of commonly shared basic assumptions, values, norms and patterns of
orientation that have been developed by the people in an organisation to cope with the
problems of external adaptation and internal integration, and which, according to common
conviction, have proved so successful that they are to be passed on to new members so that
they perceive, think, feel and act in the right way (Edgar Schein).
Culture is part of your organisation’s memory. You could also say: corporate culture is like a
shadow. You can observe it, find it beautiful or less beautiful. It exists and you cannot
change it, although it itself is constantly changing (Niels Pfläging).
The Latin word root of culture refers to the management and cultivation of the soil.
Culture is everything that man has created around himself. Culture has a visible and an
invisible part: visible are, for example, verbal and non-verbal communication: lan-
guage, greeting rituals, physical distance, food or architecture. With soil, you can dig
deeper. Thus, culture also has a deeper and thus much more personal level: the way we
think, feel and behave towards other people (Dumetz, 2012, p. 21). With this approach,
other influencing factors are also relevant for culture, as Fig. 3.6 illustrated.
3.4.2 Organisational Culture
Every community has a specific culture. This is something that applies to every
family as well as to every organisation and project team. According to the definition
by John Kotter, culture is composed of:
• Specific norms of behaviour: Shared or predominant ways of acting that have
become established in a group. These persist because group members tend to
behave in ways that transmit these behaviours to new members:
– Those who conform will be rewarded.
– Those who do not conform will be punished.
• Common values: Values symbolise what we consider important and right and
what we feel bound to. Our values determine our identity, which is why we also
react very sensitively when we feel that our values are under attack (Sect. 5.6.6.8).
256 3 Human
Physical
Distance
Habits Food
Culture
Language Religion
Tradition …
Fig. 3.6 Influencing factors for culture (Dumetz, 2012, p. 22)
These values often still remain even after the composition of the group has long
since changed.
All this feeds into Edgar Schein’s pragmatic definition, “culture is the way we
solve problems”. Many aspects of the organisation are invisible, especially to long-
standing members. What is the flow of information? How do we talk to each other?
How do we make decisions? How do we behave under pressure and stress? What
happens when mistakes are made? What reputation do project managers have in the
organisation: career springboard or siding? These questions and many more are part
of the organisational culture. It is precisely because so many aspects of culture are so
deeply entrenched that it is difficult not only to make them tangible but also to
change them (Sect. 5.5).
3.4.3 Project Culture
In Sect. 3.4.1 the topic of cultural imprinting was described. Now we will focus on
the specific project culture. This differs in varying degrees from the culture of the
3.4 Culture and Values 257
line organisation. For example, different rules, principles and values or ways of
solving problems apply here compared to what is otherwise the day-to-day business
outside of the project. While these culture-shaping elements are established in the
line organisation and are difficult to change, they can be reprioritised, agreed upon
and lived in the project sub-organisation. This is called subculture.
Example
Culture-shaping elements can be:
• Linking the project organisation to the line organisation (Sect. 2.3.8.8).

• Project management approach: agile, traditional or hybrid.
• Leadership style: from directive to delegative (Sect. 2.3.8.5) or collegial
leadership with self-organisation (Sect. 4.5.3).
• Personal communication (Sect. 3.9) with aspects such as “I or You message”
or dealing with feedback.
• Information- and communication concept (Sect. 2.4.10) and stakeholder man-
agement with formal and informal communication (Sect. 2.3.5).
• Definition of the scope for the design and determination of the decision-
making competences (Sect. 4.8).
• Error culture and dealing with failure (Sect. 3.8.5).
• Creation of the project name and project logo. ◄
Depending on the type of project, these elements may more or less differ from the
line organisation. The more complex, the more novel a project is, and hence the more
distinct the project culture will be from the line culture. For example, the culture of a
standard project is usually more similar to that of the line organisation than that of a
potential or pioneer project (Sect. 1.2.1); vice versa: in a specific project, the
behaviour of the actors may well be animated by a special culture. In a project
framework that challenges, outstanding results can also emerge.
Culture-shaping thus influences behaviour and is indirect leadership. Only: the
cultural difference has to be desired and communicated by the management in the
company, otherwise the project might be rejected, i.e. might not get taken seriously.
However, culture-shaping elements need to not only be wanted and formulated, but
also lived, which is a great challenge for those responsible for the project, especially
at the beginning. This is where the start workshop or kick-off comes in, where the
new principles and rules are agreed upon and practised.
Novel project cultures can also be a valuable experience for future permanent
organisations. For example, scrum projects are precursors for self-directed
organisations. This allows culture-changing measures to be linked to a “hard”
project object or goal of this scrum project. The culture change is thereby concomi-
tant. The complex topic of change projects is discussed in more depth in Sect. 5.5.10.
258 3 Human
3.4.4 Generations Y, Z, and Alpha in the World of Work
Each generation is described by the attributes of its time and has its own set of
basic needs. Generations Y and Z (born 1980–2010) already represent the majority
of the workforce. There is already a term “Alpha” for the upcoming generation
born in 2011 and later, but they will not enter the workforce for a few more years.
Line and project managers are challenged to bring about the inclusion of all
generations and to optimally combine their different skills in the team. To achieve
this, mutual understanding between younger and older employees needs to be
promoted. This also means repeatedly finding a respectful way of dealing with the
noticeable differences.
The various basic needs are shaped, among other things, by the social framework
conditions or the level of development of society, by the prevailing culture and value
system and also by world-changing events. For project management, knowledge of
the needs and expectations of the younger generations is particularly important. The
following characteristics, needs and expectations of younger people in the world of
work can be identified:
• They are usually well educated and invest in their further education.
• They are looking for meaning in their work: it must be interesting and above all
meaningful.
• They strive for autonomy and also take responsibility.
• They have a technology-affinity and live in various systems.
• Professional development is important to them, but it goes more in the direction
of project or expert careers than in that of wanting to manage staff.
• They do not let themselves get tied to their employer over longer periods of time.
• They are committed, while also perfecting themselves. Work-life balance is very
important to them: time sovereignty while working, doing away with the separa-
tion of work and private life, having enough time for the family, etc.
• They tend to be critical of hierarchies and enjoy working in teams.
• Shaped by the VUCA world (Sect. 1.1.2), they have a more open attitude towards
change and are more successful in repeatedly engaging with and adapting to the
changing environment.
Of course, this is a trend, and these characteristics do not apply to everyone. The
opposite can also be observed in certain people, be it an exaggerated desire for
security, adaptation or for retreating into the private sphere. Modern project
management should be able to offer the right framework conditions to meet
these needs: Teamwork, creative freedom, decision-making authority, self-
organisation, etc. instead of maximising money and status, enable an organisation
to attract good employees on whom it depends today. For many (still) largely
hierarchically managed companies, this is a great challenge. But experience shows
that with the right framework conditions, the significant potential inherent in this
can be used.
3.5 Stress and Change 259
3.4.5 Becoming Aware of One’s Own Cultural Imprint
How can you become aware of your personal cultural make-up? You cannot do it
yourself. You need other people who greet you differently compared to what you are
used to, who eat different food, tell different jokes or use different problem-solving
strategies. The differences will help you see this more clearly.
We can recognise certain things ourselves. However, a great deal remains hidden
from our own perception. That is why feedback (Sect. 3.9.7) is so important. This is
how we learn from other people what they notice about us. Of course, every human
has the right to be the way he is or the way he wants to be. This has an impact on
personal communication (Sect. 3.9), behaviour in conflict (Sect. 5.6.9), or in the
conduct of negotiations (Sect. 4.10).
3.5 Stress and Change
The aim of our stress-response is not to get sick, but to be able to change (Gerald Hüther).
Stress ensures that we are capable of high performance in a wide variety of environments
(Clemens Kirschbaum).
3.5.1 Fight or Flight
Stress in humans sets off an ancient survival mechanism in preparation for fight or
flight. When a person perceives a stressor (a stimulus or situation that poses a threat
to personal goals or well-being), the release of cortisol and adrenaline leads to
physical stimulation and the mobilisation of energy. This increases the blood flow
to the brain and the perception of the sensory organs is directed outwards. The
biological stress programme of humans makes a lot of sense from an evolutionary-
biological point of view: it allowed humans to instantly prepare their organisms to
various forms of danger. That is why the human stress reaction is not a health risk.
Figure 3.7 shows the schematic sequence of a stress reaction. If an external
stimulus (stressor) is perceived, the person’s tension increases and with it his or
her capability. If the stressor is overcome within a reasonable span of time, relaxation
sets in and with it recovery. If the tension remains, however, it first leads to
permanent stress and exhaustion.
We all need a certain level of stress to cope with our demanding tasks or to initiate
important change processes, as expressed in the quotes by Kirschbaum and Hüther.
In a state of overload, performance drops again. The main reason for this is that
the focus of attention narrows with increasing activation. “Tunnel vision”, in a
profound phase of wakefulness, helps one to concentrate on what is essential.
However, if activation goes beyond “the good level”, task-relevant stimuli and
information are blocked out when having to cope with complex demands, which
causes capability to drop once again. In addition, strong activation can lead to
260 3 Human
high
Relaxation
Tension
Excessive demand
capability
Exhaustion
Vague
attention
Recovery
small
External stimulus
Period
Fig. 3.7 Schematic sequence of the stress reaction (Based on: Drath, 2014, p. 229)
emotional and cognitive symptoms of stimulation that can distract from dealing with
the essential task (feelings such as fear, anger or rage, or disturbing thoughts,
e.g. about a possible failure).
3.5.2 Psychological Stress
The biological stress response developed to physically ward off danger (being able
to run away from a sabre-toothed tiger, for instance). However, project work is about
psychological stress: whether it is caused by the delay of a milestone, whether the
quality of a work package is insufficient or whether we see ourselves as confronted
with an enormous pressure to perform. These stressors are not manifest, physical
threats. That is why the assessment of our perception is so important.
" People have to ask themselves in stressful situations: “What is the focus
of my perception? How do I evaluate this situation?” Is every deviation
from the ideal necessarily an immediate threat to my self-esteem? Is it
still possible, especially in difficult situations, to distinguish between
personal performance (commitment and capacity) and the performance
capabilities? (Sect. 3.2) What about your resilience? (Sect. 3.8.4).
• Time and performance pressure

• Multi-tasking
Ich get into stress: Stressors
• Social conflicts
• Disruptions & interruptions
+ • Indispensability syndrom
Ich put myself Personal stress • Perfectionism
under stress: amplifiers • Being a lone wolf
• Self-exhaustion
• Physical
When I am Stress reaction, • Emotional
stressed: activation • Mental
• Behaviour
long-term
Exhaustion
Illness
Fig. 3.8 Stress traffic light (Kaluza, 2018)
3.5.3 Stress Traffic Light
The art of personal stress management lies in being able to regulate the current level
of activation in relation to the requirements of the task at hand. In practice, this often
means reducing personal activation wherever and whenever possible.
Coming up with the metaphor of a stress traffic light, Gert Kaluza subdivides
individual stress competence into three parts: stressors, personal stress amplifiers and
stress reaction (Fig. 3.8).
Possible stressors in project work are deadline and performance pressure, multi-
tasking, social conflicts or disturbances, and interruptions that hinder one’s efforts to
concentrate. However, people themselves add to these stress events through their
own personal stress amplifiers, such as wanting to be indispensable, being
perfectionistic, not allowing others to help you or overtaxing oneself in one’s own
demands. All this contributes to the fact that the effect of the original stressors on us
is intensified. Every stressor ultimately leads to a stress reaction. This includes the
physical and psychological responses of the organism reacting to the stress. People
who are exposed to stress-induced strains over the long term may experience
exhaustion or illness.
262 3 Human
• Self-mgmt, work technique

Actively address • Conflict management
Instrumental Stressors
requirements • Maintain networks
• Further education
+ • Self-reflection skills
Mental Personal Develop supportive • Perceive reality
stress amplifiers attitudes • Accept one‘s own limits
• Discover opportunites and
meaning
• Relaxation training
Recover and • Sports and activities
Regenerative Stress reaction
relax • Enjoy everyday life
• Hobbies and breaks
Fig. 3.9 Stress competence (Kaluza, 2018)
3.5.4 Stress Competence
People can develop stress competence on three levels (Fig. 3.9).

Instrumental stress competence aims at enabling people to develop specific
strategies to help them reduce their personal stress activation. At the level of
stressors, the demands themselves are actively addressed. All aspects of self-
management and personal work techniques are helpful here, so are the skills of
personal communication and conflict management and maintaining personal
networks and space for personal development. Mental stress competence is based
on the ability to self-reflect: to be able to observe oneself from an outside perspective
in one’s thoughts and actions and from this to constantly develop new beneficial
attitudes pertaining to the current situation. Regenerative stress competence works
on the level of the stress reaction and includes sport, relaxation, enjoyment, and
breaks to reduce the stress hormones in the body once again.
What is important at that point in the development of our stress competence is that
we do not just always keep doing one and the same thing, i.e. not just do sport every
time to regenerate after stress, because that way the external stressors remain in place
and the personal attitude towards them does not get reflected either. But simply
reflecting on one’s personal attitude again and again and practising “affected calm-
ness” is not enough in the long run either. Every now and then we need to be able to
directly address a stressor, e.g. in the form of a social conflict, in order to arrive at a
situation that is then once again tolerable to us (e.g. clarifying roles in a project or
negotiating expectations with my superiors). The more stress reduction
competencies we can develop on these three levels, the better we can time and
again regulate our personal stress activation.
3.5.5 Life Means Change
Most live in the ruins of their habits (Jean Cocteau).
It is a law of life that everything that lives can never remain as it is. Life around us
is constantly changing. We ourselves also change through our daily positive and
sometimes negative experiences. On the other hand, we constantly try to create as
much security and stability as possible for ourselves and our environment. Security
has a lot to do with predictability. Habits give us a lot of security. We create patterns
of feeling, thinking and behaving that we can hold on to and that give us orientation.
The problem is that these habits originate in the past: they involve our work
techniques, our modes of interaction with other people or our reactions when facing
stressful situations. In all the situations we encounter in daily life, we first try to react
to these with a familiar pattern of behaviour because it gives us security: We know
this has already worked in other situations. And so, often it is an adequate strategy.
However, there are always situations in life, in which we have to break out of our
established habits. The more we hold on to old habits, the more difficult it becomes.
Breaking out of habits and developing new strategies is always a path into the
unknown. It takes courage and self-confidence.
3.5.6 Personal Coping Strategies and Dilemmas
When current coping strategies and habitual patterns are not helpful in solving a new
situation or meeting a challenge, the following three strategies are practical:
1. Change The external situation or one’s own behaviour is changed.

2. Reassessment The person adjusts his or her personal evaluation. The situation remains, but it
is no longer evaluated as threatening or particularly challenging.
3. Displacement The person tries to suppress the stressor.
The best strategy always depends on the challenge at hand, the personality traits
of the person and his or her physical and mental condition. There are situations or
events that are best suppressed. Other situations need change or personal reassess-
ment. Project managers are often confronted with dilemmas: A dilemma occurs
when a person or an organisation has to achieve two conflicting goals.
Examples
• A company wants to respond to individual customer needs, but needs efficient

production methods and thus standardisation.
• Project managers or product owners want to maintain good relationships with
their teams, while having to make unpopular decisions.
• The magic triangle even represents a trilemma: An ambitious goal has to be
achieved at a certain time with a limited budget. ◄
264 3 Human
Many dilemmas can only be resolved by changing the external situation or one’s
own behaviour. If the dilemma remains unresolved, the causes of the contradiction
need to be identified and tackled through negotiation (Sect. 4.10) or using various
methods of conflict management (Sect. 5.6) or risk management (Sect. 2.3.7).
3.5.7 Burnout
Long prolonged stress can lead to exhaustion and burnout. As a consequence of

living and working in a meritocracy, burnout is a phenomenon that affects people
in all occupational groups and hierarchical levels. Burnout can have many causes:
for example, the persistent stress reactions described above or having to cope with
great discrepancies between abilities and requirements over a longer period
of time.
Burnout syndrome develops slowly and insidiously. The affected person
behaves inconspicuously and thus remains “undetected” for a long. There are
significant individual differences. But, in the end, total exhaustion tends to occur
abruptly. Only in the advanced stage does burnout show itself in the three forms as
Table 3.1 shown.
Depression and burnout are now treatable with medication and therapy, prefera-
bly a combination of both. The basic prerequisite for healing is that those affected
primarily admit to having the illness to themselves. Only in a next step can they
regain their former, better energy balance through professional care. The measures to
achieve this are different for each person and situation. Basically, however, it will
always be a matter of working on how to deal with one’s own limits. Anyone who
suffers a burnout has in some way exploited their individual resources. This is
probably the most difficult step for performance-oriented people to learn, namely
that their personal resources are limited and needing to realise that they cannot
meet all the demands and requirements placed on them.
" There are no limits to the demands and expectations placed on a person
by their professional and private environment: line managers, project
owners, customers, suppliers, project and line staff, work colleagues; all
other stakeholders in the project and then the personal private environ-
ment. All these people can make demands on a single person far in
Table 3.1 Forms of burnout

Physical Chronic fatigue, a feeling of weakness, physical pain such as head-, back-,
exhaustion muscle aches, weight fluctuations, sleep disturbances, increased
susceptibility to illness.
Emotional Dejection, helplessness, crying, uncontrolled outbursts of emotion,
exhaustion irritability, feelings of emptiness, despondency, loneliness.
Mental Negative attitude towards oneself, work and life. Increased feelings of
exhaustion inferiority, loss of self-esteem, increasing loss of contact and refusal to
communicate; cynicism, suicidal thoughts, and aggressiveness.
3.6 Flow 265
excess of his or her capabilities. The human being is limited in his or her
capacity and needs recreational space. In project management, the
methodology provides important impulses to make complexity visible
and to find a realistic way of dealing with it. Possibilities include clarifying
the scope, stakeholder management or planning.
Without external help a sustainable personal change that a burnout requires is

almost impossible to achieve. It is strongly recommended that those affected be
supported by learning guidance from a coach. According to Paul Watzlawick, a
return to the ancestral task would be a solution to the first order. There is a danger of
falling back into the old patterns of thinking, feeling and acting. The next burnout
would be just around the corner. Sustainable solutions need new approaches. During
re-entry into one’s former, original job after a burnout, the person concerned, the line
manager, and a coach should re-describe the job with its tasks, decision-making
powers and responsibilities.
3.6 Flow
Another concept to describe healthy and unhealthy stress is the flow concept
(Csikszentmihalyi, 2004). Mihaly Csikszentmihalyi’s research focused on the ques-
tion of what makes a person’s life worth living, what he can “burn” for and what it is
that gives him the energy to commit himself to things that promise neither wealth nor
fame. He calls this state of existence “flow”, when a person completely forgets
himself in the performing of a task and when his work emerges as if by itself.
Musicians, for example, experience flow when the piece seemingly composes itself.
Writers report that at some point, the characters in their novels take on a life of their
own. Identical to all flow experiences is the fact that in these moments, any
consciousness of self disappears. One becomes absorbed in the activity at hand
and seems to forget oneself while experiencing an altered perception. The everyday
worries that otherwise circulate in the mind are gone.
In Fig. 3.10 shows the different states in which a person can find himself or
herself. The concept relates the demands placed on a person to his or her personal
abilities. The reference point is the centre. From this centre, each person positions
himself in each task in relation to his abilities as well as he can, given the necessary
requirements.
The ideal state to which we should always direct our actions is “flow”. Here we
experience the specific requirements as a high-level request, but our skills in this
regard are also high. This is the basic prerequisite for us to enter this self-
forgetfulness in which we forget everything around us and within us and are
completely one with our activity.
266 3 Human
high Excitement
Fear
Flow
Requirements
Concern Control
Apathy Relaxation
Boredom
low
low Skills high
Fig. 3.10 Flow concept (M. Csikszentmihalyi, 2004)
Example
An experienced scrum master enters this flow state the moment his scrum team is
in a difficult situation. He feels that the way he intervenes is crucial for the scrum
team to overcome the current technical or social challenge. If the scrum master is
confident that he has all the competences to help the scrum team in this situation,
he will be able to experience a feeling of flow. However, should he realise that he
is confronted with phenomena he does not understand, he will experience a state
of fear or concern in this demanding situation. These are all aspects of being
overburdened. ◄
The lower half of the diagram shows what happens when a person has more skills
than those that are currently needed: At best, one sees this as being in a state of
control or even as being in a “comfort zone”. This is pleasant for a moment, but in
the long run it is not a satisfying situation. Every person needs, for his own
development, the feeling of being able to cope with a new challenge in a specific
aspect of life. So, if we assign the same, experienced scrum master to a very simple
project with a small, homogeneous scrum team, which also already has a lot of
experience in agile project management, a kind of relaxation sets in for this person,
3.7 Motivation and Meaning 267
that eventually turns into boredom. The hardest to bear state to be in for a person in
this model is apathy. In such a case, we see ourselves as being confronted with
activities for which we do not feel qualified and which do not represent a challenge
for us in any way, one does not feel at all that one is doing something that
corresponds to one’s skills. This is how a technical expert may feel who, after
years of research work, suddenly has to take on repetitive tasks such as those in
production. Or a project manager who, after several large projects, is assigned a
sub-project manager task. Underchallenge is even more dangerous than
overchallenge!
" This model provides guidance on how people position themselves in a

specific task in relation to the demands and personal abilities. The closer
we get to a state of flow in this context, the healthier do we experience
stress related to it. Yes, we notice that we even need additional
challenges in order to experience this state. The starting points for
then experiencing a state of flow are zones of control and excitement.
The strategies for getting there, though, are quite different: a project
manager who sees his employee enthusiastically has to focus on devel-
oping his skills even further, for instance through more training or
coaching. For an employee feeling control or even relaxation, however,
the focus is on how to meet higher demands, for example, through
challenging milestones or more exacting tasks.
3.7 Motivation and Meaning
As we no longer saw meaning of our work, we began to talk about motivation (Reinhard
Sprenger).
3.7.1 Goal Orientation of the Human Being
The concept of basic human needs implies that our behaviour is goal-oriented and
that these goals derive from basic personal needs. In Sect. 3.3.2 it is explained how
important the basic need of striving for achievement is in us and what direct
influence this has on positive emotions. Through achievement, we experience
ourselves as effective and are able to develop our creative potential.
3.7.2 What Is Motivation?
The Latin word root in movitum ire can be translated by: “to enter into that which moves
man”
268 3 Human
Basically, motivation can be described as movement. Either:
• “Towards” something called appetite, or

• “Away from” something called aversion
However, motivation is in no way standstill (Esch, 2014, p. 118).

The motivational system plays an important role in humans. At the beginning of
evolution, early forms of life had no such motivational system. Today, it is assumed
that their motor activities were more or less based on chance. Later, the activities of
living beings became connected to a system for perception and experience. This
system was in turn linked to neuronal circuits. This created the basis for reinforcing
precisely those activities that increased the probability of survival by means of a
reward system (Esch, 2014, p. 126).
3.7.2.1 Gallup: Commitment and Motivation at Work

Since 2001, Gallup has been conducting a representative survey in Germany about
the degree of emotional commitment of employees to their organisation and thus
their engagement and motivation at work. According to the Gallup Engagement
Index 2016, the five most important factors for the emotional commitment of
employees are:
• Opportunity to do what you are really good at

• Leadership quality
• Challenging and varied activity that is perceived as meaningful
• Colleagues
• Corporate goals, corporate philosophy
According to Gallup, many companies invest in the wrong measures: For exam-
ple, “the opportunity to do what you are really good at” is considered five times more
important than pay for emotional attachment.
In these five most important aspects of emotional commitment, the supervisor
plays a decisive role: Recognising the potential, but also the limits of employees and
managing them according to the flow model in Sect. 3.6 is a very demanding task,
both for supervisors in agile or for those in traditional project management. Gallup
reveals a major discrepancy in this aspect: only just 21% of all employees say that
the quality of leadership they experience at work motivates them to do an excellent
job. However, when supervisors are asked about their own leadership quality, 97%
consider themselves to be good leaders.
3.7.2.2 Intrinsic and Extrinsic Motivation

Some models explaining motivation distinguish between intrinsic and extrinsic
motivation. Intrinsic motivation is a self-control that enables the free flow of innate
human energy. It motivates the respective person with the question of “why”:
3.7 Motivation and Meaning 269
• Why does an employee choose a specific company?

• Why does a project manager commit all his energy to the project?
Extrinsic motivation provides a person with motives that they did not have before.
It therefore constitutes external control. Extrinsic motivation focuses on the ques-
tion of “how”:
• How can I encourage my project staff to perform better?

• How can I ensure that my team achieves the annual targets?
3.7.2.3 Motivation Through Working on the Demotivating Factors

The direct superior exerts the greatest demotivating influence on employees (Reinhard
Sprenger).
Based on the “downside” strategy, see Sect. 3.10.5 it is much more effective to
work on the causes of demotivation instead of asking how employees can be
motivated even more (Sprenger, 2014, p. 200 ff). Sprenger identified the following
sources of demotivation that need to be taken into account:
• The boss knows it better and can always do more than you
• Decisions that are made alone and without support
• Excessive and unobjective criticism
• Dynamic, loud dominance-oriented behaviour
• Treating employees as if they were invisible
• Insufficient information that is one-sided, gets given too late, or is restricted in
scope
To check their own attitude and approach, supervisors can ask themselves the
following questions:
• Do I trust the employee?

• Do I know his strengths?
• Am I giving him enough space?
• Do I agree on the goals with the employee or do I impose them?
• Do I give him credit for his achievements?
3.7.3 Meaning as an Intrinsic Motivator
Meaning is what has significance (Tatjana Schnell).
A key intrinsic motivator is meaning. The Gallup study identifies meaningful

work as an essential factor. This also plays an essential role for personal resilience
(Sect. 3.8.4).
270 3 Human
3.7.3.1 What Is Meaning?
Humans are the only living beings who have to explain the world to themselves in order to
cope with life (Remo Largo).
Satisfying only one’s basic needs is not fulfilling. In trying to explain the world to
himself, man inevitably encounters the question of meaning. According to the
psychotherapist Alfried Längle, meaning is man’s lived answer to the question of
“what for”. Man needs a reason for his actions. He wants to feel what he is there for
and why he does things.
3.7.3.2 Meaning in Life ≠ Meaning of Life

When we deal with the question of meaning, we need to be able to distinguish
between the meaning in life and the meaning of life. Whether there is a fundamental
meaning of life is a philosophical question. What can be explored concretely,
however, is the question of how a person gives meaning to his or her life. For
Tatjana Schnell, the fulfilment of human meaning is based on the following four
criteria:
• Coherence, fit: The feeling of coherence arises for a person when he understands
his actions, experiences them as coherent and conclusive, when things fit together
and he can achieve goals in his activities that are personally valuable to him.
• Significance: This is about how people perceive the effectiveness of their own
actions. When people realise that their actions have positive consequences for
themselves and others, they experience meaningfulness.
• Orientation: Every person wants to be able to develop further. Even in unclear
life situations, he wants to be able to orientate himself somehow. He needs some
goal at the end of the horizon that is worth striving for.
• Belonging: People must be able to perceive themselves as being part of a larger
whole. This can be the family, society, the employer or the project team. This
integration gives each person the feeling of being needed and of having
responsibility.
3.7.3.3 Our Way of Life Systematically Destroys Meaning

According to philosopher Wilhelm Schmid (Schmid, 2010), we live in a time in
which meaning is systematically being destroyed: In the past, for example, commu-
nity and thus a sense of belonging was obligatory. In village communities, one had to
participate in public life, whether by attending church or by following other
traditions. Today, we live much more as citizens of the world. As a result, many
of our meaningful relationships are disintegrating while at the same time the degree
of specialisation of our work is increasing. It is much more difficult to still be able to
see the effect one’s actions have.
A person ought to be suited for his or her occupational task. The person’s
competences (Sect. 3.1) should match the requirements of the job as closely as
possible. The comparison of the weighted competence profiles in Sects. 2.3.8.4 and
3.8 Self-Management 271
2.3.8.5 make it clear, however, that the requirements for each project role can be
quite different.
Example
In one study, participants were asked to rate how they fit their work (coherence)
• Only 14% of respondents said that the demands of their job and their skills
were a good fit.
• Sixty-two percent defined the fit as “more or less good”.
• The remaining quarter rated the fit as “not good”. ◄
So, it is not at all self-evident that you will perform a role in project work that
fully matches your competences, character traits, and your interests. It would
probably also be too much of a demand to expect this. Therefore, the question arises
how much fulfilment of meaning can be expected from the profession at all?
3.7.3.4 Meaningful Fulfilment at Work

Many people invest a lot of time and energy into their jobs. So, it makes sense that
gainful employment should also be meaningful. How ought the question of mean-
ingfulness be dealt with at work? Tatjana Schnell comments on this as follows: “As
important as the meaningfulness of professional activity is, the concept should not be
overused. Not everyone seeks their meaning in life in work, and not every job has the
qualities that make it a suitable focus of life”.
These considerations lead to a dilemma. On the one hand, people need motiva-
tion, a sense of purpose or flow for their performance. On the other hand, the results
of the above-mentioned study show that modern gainful employment no longer
makes this possible for many people. How do we deal with this? The consequence is
that it is imperative for people to consider the question of meaning holistically,
beyond their professional work, as explained in the model of the three personal life
worlds (Sect. 3.10.1).
3.8 Self-Management
In the context of burnout, self-management in project work has gained importance.

The set-up of projects is fundamentally challenging: innovative goals are to be
achieved with interdisciplinary teams and limited costs. Somehow, one is always
at the limit of one’s performance skills and abilities in a project. Of course, this has
consequences for one’s personal energy balance. For all of the project staff involved,
it is always a balancing act between being challenged and being overtaxed. In this
balance, one’s own resources have to be managed optimally. There are different
definitions of self-management. Two of them are listed below:
272 3 Human
• Jäger understands self-management as the targeted, self-directed and self-

responsible development of one’s personal life in the direction that someone
feels is best for oneself in order to be successful (In: Steiger & Lippmann,
2008, p. 151).
• According to ICB 4.0, self-management is the ability to set personal goals, review
and adjust progress, and systematically complete daily work. Self-management
includes dealing with changing conditions and successfully managing stress (ICB
4.0 PM, p. 53).
3.8.1 Human Self-Efficacy
According to the definitions, self-management is always about self-efficacy in some

form or another. Even in the most difficult situations, people with a high level of self-
management competence manage to exert a controlling influence over their own
feelings, thoughts and actions. This is why self-efficacy is also an important pillar of
personal resilience (Sect. 3.8.4). People who only do what is expected or demanded
of them live a life that has not connection to their personal ideas, goals and needs.
Thus, their personal boundaries break up more and more. Feelings of powerlessness
take over, which at some point even lead them to perceive of themselves as victims.
If you feel like a victim, your environment and all the expectations placed on you are
seen as threatening. This in turn leads to increased stress or even the danger of
burnout (Sect. 3.5.7).
Of course, we do not have free choice in everything we do. There are superiors,
project owners or customers who make demands and requirements on us that we
have to fulfil. For the protection of our own self-efficacy, the model of the sphere of
control, influence and concern offers valuable orientation (Fig. 3.11).
In the Sect. 3.3.4 it is stated that humans have developed the unique ability of
separating their behaviour from their feelings and their intuition. From this it can be
concluded that everyone has a sphere of control in which he can be self-determined.
This basically concerns one’s own feeling, thinking and acting. In relation to project
work, this includes areas such as personal work technique, communication or the
shaping of relationships. Depending on the function and role of the respective
person, the area of control expands: A product owner has clearly assigned
decision-making competences, a scrum master has control over the course of the
daily standups.
For every human being, the domain of his control is limited. Next, in line of order,
is his sphere of influence. A project manager can and has to exert influence where it
regards his project order. The sphere of influence is upheld by constructive
discussions, suggestions as well as by providing reasons and explanations. In the
case of the project order, the project manager thereby exerts his influence on the
project owner.
The outermost layer is the area of concern: Seeing how the world market might
develop or whether the new company strategy will be successful—this cannot be
influenced even with our greatest efforts. That is why we need to also be able to
Concern
„Affected calmness“
Influence
Inquire, give reasons,
suggest, discuss
Control
Own feeling,
thinking and acting
+ -
Experience of competence Feeling of helplessness
Self-esteem Victims‘ perspective
Fig. 3.11 Area of control, influence and concern
distance ourselves from such issues. If you want to protect your self-efficacy, you
must not lose yourself in the area of concern. Here, any energy invested is wasted
and in no proportion to the achievable benefit. People who want to manage and
preserve their self-efficacy focus on their specific areas of control and influence. This
is the means by which they experience competence. I can influence my environment
with my competencies and personality traits. This in turn allows experiences of
competence to take place—and it increases self-esteem.
3.8.2 Personal Competence Circle: Strengths and Weaknesses
I’m no genius, but I’m smart in spots, and I stay around those spots. (Tom Watson, founder
of IBM).
Warren Buffet coined the term “circle of competence” For Buffet, the circle of
competence is the personal reference line for deciding what someone should or
should not do. As an extremely successful investor, Buffet only invests in companies
the business models of which he understands. If he feels unable to do so, he cannot
274 3 Human
calculate a realistic company value and therefore cannot make successful

investments (Dobelli, 2017a, p. 93 ff).
Buffet may well be called a genius of his discipline. Despite his success, he stands
out because he is aware of his limits. Or, to put it the other way round: it is because
Buffet is aware of his limitations that he is so successful. For Buffet, by the way, it is
not crucial how large the circle of competence is. The world today is so complex that
each individual person can only understand a fraction of all that is happening around
them. But it is precisely in this small area that the personal circle of competence lies,
which can be the launch pad for a personal flight of fancy.
" What constitutes this circle of competence? The school education, the
university lectures? For Dobelli it is obsession: it is what drove Bill Gates
to programme or Warren Buffet when he invested his first pocket money
in shares as a 12-year-old. In the field in which a person’s obsession lies
that he will invest thousands of hours over the years. That, in turn, will
make him really good at his discipline.
The circle of competence also has its pitfalls: Those who become more and more
successful by doing something specific suddenly think they are good at doing
anything. But a technology expert is far from being a good project manager. Or a
good project manager is far from being a good managing director. Of course, it is
possible to expand one’s own circle of competence. But this should be done
consciously, in an honest consideration of one’s own strengths and weaknesses
and also in the awareness that this will take a lot of energy and effort.
3.8.3 Time Management and Work Technique
How do you start your working day? Do you get your coffee, start your PC, read
your email? That’s probably true for many who call themselves knowledge workers
and spend their day in the office processing, transforming and passing on some form
of information.
People are fundamentally curious. You can see what’s going on in the emails and
chat tools. But do you find your personal priorities realised through the use of these
tools? Does your most important task for the day show up in these? Unfortunately
not. Most of the time, colleagues, superiors or customers report in, who have
expectations of you. If you at that moment start reading and writing (using messen-
ger apps, for instance), your valuable working time is wasted. Of course, we need to
communicate, and digital platforms have many advantages. Self-effective people
adopt a working technique that allows them to effectively achieve their personal
priorities. The priorities are, of course, very different for a project owner, a project
manager or a technical expert in a project.
How can you identify your personal priorities? This can only be done through
your goals. You need to know for yourself what roles you have been assigned to and
urgent not urgent
1 2
Necessity Quality
important
• Critical path • Planning

• Troubleshooting • Controlling, magic triangle
• Resources not available • Innovation
• Crises • Stakeholder Management
• Work under time pressure • Negotiations
• Risk Management
Illusion Waste of time

• Many meetings • Irrelevant information
not important
• Many E-Mails • cc: E-Mails

• Disorders • Escape activities
• Colleagues want to get • Social Media, Web,
rid of work Smartphone
• Things we like to do
3 4
Fig. 3.12 Time management matrix (S. Covey, 2020, p. 36)
what goals you need to achieve with them. Most of the time you do not only have
just one work project, but are active in several projects at the same time or you have
responsibilities in line tasks as well. In his traditional book “Der Weg zum
Wesentlichen” (2014), Stephen Covey recommends that each person ought to define
a maximum of seven roles for themselves (Sect. 5.3.1). For each role, you define
specific goals on the basis of which you can reason out priorities. In a further step,
you also divide the goals into specific tasks, which you in turn quantify by means of
an effort estimation, and you schedule them within your personal capacities. Covey’s
time management matrix has become well known. (Fig. 3.12), which distinguishes
between urgent and important activities.
What is the difference between urgent and important? We have to respond to
urgent tasks. They need immediate attention. Colleagues call, customers send
emails. Its about crisis meetings, production stoppages or short-term staff absences.
" Important tasks are as if they were invisible: this is where we have to act.
Important tasks contribute to our personal goals and tasks.
The tasks that are urgent and important are in the quadrant of necessity. These
have to be attended to immediately. Failure to do so would have immediate
276 3 Human
consequences. Non-urgent but important tasks are listed in the quadrant of quality.
These are conceptual tasks such as planning, risk management, stakeholder manage-
ment or communication; mostly, these are not activities that are actively demanded
of one. We have to actively act on these tasks much more. If the quadrant of quality
is neglected in project work, the consequence is foreseeable: more and more opera-
tional problems then get flushed into the quadrant of necessity. Negligent planning
leads to unmet milestones, inadequate risk management generates massive addi-
tional costs, or insufficient stakeholder management leads to resistance or conflicts
with stakeholders.
" We create our personal self-efficacy via the quadrant of quality. Whoever
neglects this becomes increasingly controlled from the outside and
thereby falls into the quadrant of necessity.
We can gain time in the quadrants of illusion and waste of time: In illusion, we
think we are engaged in important tasks. But in relation to our goals, they are not.
And example for this might be attending meetings simply out of habit that have
nothing to do with our current priorities. Or we might be simply distracted by the
news on our smartphones and on the internet or by news in social media.
Active self-management challenges us again and again to reflect on our actions
and to classify them via this matrix. Those who perceive themselves as being in a
state of strong actionism for a large part of their working time need to ask themselves
which measures in the quadrant of quality they can use to reduce the number of
necessities. In the vast majority of cases, it will then be a matter of intensifying the
work on the system, as explained in Sect. 1.5.2. The time for this can be found in the
quadrant of illusion or waste of time. This requires that one is able to disconnect
oneself from habits that no longer serve any purpose.
3.8.4 Resilience
3.8.4.1 What Is Resilience?

Resilience is the maintenance or rapid restoration of mental health during and after adversity
(Raphael Kalisch).
Resilience is the ability to master crises through one’s own resources and to grow from them
(Martin Seligman)
The high pressure to perform in project work is a great challenge to all

participants in terms of personal resilience. The mode of action taken when facing
resilience reveals itself in different phases, as Fig. 3.13 illustrates.
After an event that has been subjectively assessed as a crisis, be it a failed project,
the breakup of a (work) relationship or the loss of a job, everyone normally
experiences a drop in capability (performance). One feels depressed, can no longer
concentrate or has no more energy. In the worst case, personal capability is
high
Growth
Crisis
dro
Recovery
Capability
p in
per
for
Normal state ma
g
pin
nce
Co
Damage
small
Time
Fig. 3.13 Schematic functioning of resilience (Drath, 2014, p. 102)
permanently damaged after the crisis. Those who can use resilience as a resource
regain their performance or even emerge stronger from the crisis.
3.8.4.2 Resilience Factors

In her book “Resilienz - 7 Schlüssel für mehr innere Stärke” (2013), Jutta Heller
describes the following personality traits that have a positive influence on one’s own
resilience (Fig. 3.14):
Optimism
The best attitude for resilience, according to scientific evidence, is optimism
(Kalisch, 2020). Trusting that things will get better, having a positive self-image
and a healthy self-confidence are all part of this. It should not be optimism of an
illusory sort, one that just glosses over everything, but a realistic optimism that
allows you to see the positive without ignoring the difficulties.
Acceptance
Accept, that misfortunes, disappointments and adversities are part of life and that
they can neither be avoided nor removed without a trace. Take enough time, realise
what has happened, accept ambiguities, have patience. Give the necessary space to
becoming and development. Have confidence that things will rearrange themselves
without our intervention. Trust in a larger context of meaning. Accept the unchange-
able. Self-accept your strengths and limitations.
278 3 Human
Resilience
Problems can be solved in principle

Trust that things will get better
Being able to accept crises
Feeling up to the demands
Being able to accept help,
Develop visions and goals

Learning from mistakes
Network orientation
Solution orientation
Self-responsibility
Future orientation
persons to rely on
Self-efficacy
Acceptance
Optimism
Virtues and character strengths (be capable)

Needs and motives (be willing)
Fig. 3.14 The seven keys to more inner strength (Jutta Heller)
Self-Efficacy
Self-effective people are convinced that they can influence their environment and are
not categorically at the mercy of their environments. They are able to realistically tie
their own capacity to their performance capabilities in their project organisation
(Sect. 3.2). Self-effective people have well-developed stress management techniques
at all levels (Sect. 3.5.6) and also always manage to leave the victim role after having
had difficult experiences.
Personal Responsibility
Taking responsibility for one’s own feelings, thoughts and actions characterises this
personality trait. This also includes being able to accept and protect personal
(capacity) limits. Self-responsible people to a high degree also have the ability of
self-reflection. They are able to always question their own convictions and
evaluations.
Network Orientation
Man is man’s best friend. Beneficial relationships and social networks provide
solidarity and support. Relationships are therefore to be nurtured and protected.
People with a high level of network orientation also tend to succeed in finding, as an
alternative, other people to rely on after separations or relationship breakdowns and
in building new supportive relationships. Being able to accept help from other
people without feeling bad about it or having a guilty conscience is part of this topic.
Solution Orientation
“He who wants to, looks for ways, he who does not want to, looks for reasons”
(Harald Kostial). Think about solutions, activate resources. Get out of the “problem
trance” and develop option, be open to new ideas and unfamiliar perspectives.
Developing the flexibility to change methods and behaviours when they no longer
work is as important as thinking creatively and trying out new things—or as creating
and organising structures in chaos.
Future Orientation
Have a desirable, meaningful mental representation of the future: Meaning, values,
visions, dreams, inner images and longing provide orientation in times of crisis.
Seeing the future as a potential and taking active control of one’s life is part of future
orientation, as is feeling largely responsible for one’s own well-being and knowing
what one wants to achieve in the long term or recognising limiting assumptions and
beliefs as well as focusing on the possibilities of the future: “He who is down on his
knees cannot reach for the stars” (Raffael Kalisch).
3.8.5 Dealing with Failure
3.8.5.1 Failure at Roche and Dyson

Severin Schwan, Roche’s CEO, outlined the success factors of the world’s largest
biotech company in his speech at the Swiss Economic Forum 2015 (Müller, 2015).
One of these success factors was: celebrate failures! Because the degree of com-
plexity in the pharmaceutical business is very high, nine out of ten projects fail. By
celebrating failures, a signal was given internally that it was worth taking a risk with
projects. And often the insights gained from failed projects form the starting point
and basis for the next projects.
Unfortunately, this attitude has not yet become part of all organisations. The fear
of making a mistake is still significant in many places. People are afraid of losing
their reputation or even of being sanctioned. But what does it mean for project
participants if they are afraid of failure? Where the fear of making a mistake
resonates consciously or unconsciously, people cannot develop their creative poten-
tial. Especially in project work, which has the goal of creating innovation, which is
always exposed to risk due to its nature, the attitude and corporate culture described
by Severin Schwan is needed. Only those who do not dare to try anything new can
lull themselves into the security of not making any mistakes. But those who want to
create innovation accept from the outset that the path will be a difficult one and that
the fruits of success will not be given to them easily.
280 3 Human
Example
James Dyson says of himself that he had to build 5127 prototypes before he was
able to come up with the bag-free hoover. For Dyson, everything starts with
failure: “Failure is the starting point: when something fails, you understand why it
fails, and then you start thinking about what you can do to prevent failure”
(Brand, 2017). ◄
Dealing with failure therefore always has two influencing factors: personal and
organisational parts.
3.8.5.2 Personal Assets: Attitude

Ute Lauterbach developed a simple formula for failure:
failure = intended goal þ fall short
Failure happens when we cannot achieve a goal. Fundamentally, of course, this is

unpleasant, as failure interferes with our basic need to strive for achievement. This in
turn affects our emotions: We feel sad and distressed.
Of course, we do not want to and should not simply gloss over failure. But to get
close to the attitude of a James Dyson, our project work will not succeed if we regard
every failure as a personal defeat and feel personally degraded because of it. Based
on Lauterbach, we can ask ourselves:
Do I serve failure, or does failure serve me?
When I serve failure, I let it win over me. I devalue myself and tell myself that I
did not make it. However, if failure serves me, I can ask myself, as Dyson did 5127
times, what I can learn from not achieving my intended goal?
3.8.5.3 Organisational Aspects

The organisational part of failure lies mainly in the organisational culture, the way
we generally solve problems (Sect. 3.4). In many corporate identity brochures,
employees are emboldened to be brave and to try out new things. In organisational
culture, it is not the glossy brochures that matter, but instead in which ways
employee behaviour is rewarded or sanctioned. The relevant question for
organisational culture is therefore, how it is experienced by those involved when a
project has “failed”? Is the “failure” actually celebrated? Is it analysed without
apportioning blame what worked and what did not work and what new insights or
knowledge the failure led to? Is the responsibility for the failure taken by the right
(management-) bodies, or is it delegated to the staff? Are those involved in the
project given attractive projects again, perhaps even encouraged, or delegated to the
sidelines? The real organisational culture is expressed in these rewards or sanctions.
The vast majority of employees base their behaviour on this.
3.9 Personal Communication 281
3.8.5.4 Fail Fast

The failure of an idea does not mean that the person who had the idea has failed (Biswas,
2015).
This credo in agile project management gets to the heart of the matter. Failure
should not be regarded as a taboo. Rather, it should be seen as an integral part of
project management, which is systematically managed through risk management.
Agile project management practically provokes failure by planning the sprints in
such a way that the most difficult tasks are tackled first. Under no circumstances do
you want to invest valuable resources in a fine initiative only to find out in the last
sprint cycles that the whole solution approach does not work.
In Silicon Valley, too, an open approach to failure is lived. Innovation and
creativity automatically lead to high risk and failure in corporate culture. The most
important thing in the making of these experiences—and this is an important attitude
for strengthening one’s own resilience—is to be able to distinguish between personal
performance and the framework conditions.
One can only learn and develop from “failure” experiences when the failure of an
idea or project is distinctly kept separate from the person. If a project has failed, it
primarily only means that the technological approach, the chosen methodology or
something else did not work. Operationally, brilliant project management may even
have been carried out. From this perspective, failure “serves me” and I will be able to
develop in a positive way by making this experience.
3.9 Personal Communication
3.9.1 What Is Communication?
The term “communication” is a general collective term for all processes in which a certain
information is sent (signalled) and received, even if it is not reciprocal (Iris Boneberg).
Mutual influence is called interaction. Communication serves interaction. Essen-

tial characteristics of interpersonal communication are:
• Communication is always subject to interpretation. What we perceive as relevant

information, what everyone personally considers to be “true”, is the result of a
complicated selective perception (Sect. 3.3.3). Others produce “truths” that devi-
ate from my “truth”.
• Communication is more than simply an exchange of information. Since every
person constructs his or her reality subjectively, communication always serves to
reconcile the different individual constructions.
• In communication, several messages are always sent and received simulta-
neously. Some are overt, others indirect, covert. Often, however, the covert is
more important than the overt.
282 3 Human
• Communication does not take place only with those present being involved.
Many absent people are also participants in the “communication game” in the
background, by influencing the thinking and reactions of those present: What
would the customer say?
3.9.2 Axiom Theory
A gesture or a facial expression tells us more about how someone else thinks about us than a
hundred words (Paul Watzlawick).
The quality of communication is the spice of all relationships. However, commu-

nication is often also the cause of injuries and conflicts (Sect. 5.6.6.4). Under the
guidance of the communication scientist Paul Watzlawick, five axioms were devel-
oped which represent the challenges of interpersonal communication:
1. One cannot not communicate.

The boss comes into the office in the morning and says nothing. That also says
something about how he is doing or what his relationship is with his staff.
2. Every communication has a relationship and a content aspect.
Whoever it is that says something and how something is said always carries more
weight than what is said. The relationship aspect determines the content aspect. In
conflictual relationships, the content aspect loses almost all importance.
3. Communication is always cause and effect.
The woman is annoyed because the man is nagging. The man nags because the
woman is annoyed.
4. Digital and analogue communication.
Verbal communication is referred to as digital. The non-verbal as analogue. In
interpersonal relationships, analogue communication has a great influence, as the
above quote describes.
5. Communication is symmetrical or complementary.
Symmetrical: We talk at eye level: scrum team
Complementary: There is a kind of hierarchy: project owner—project manager
3.9.3 Communication Square
The axioms 2 and 4 are taken up by Friedemann Schulz von Thun in the communi-
cation square. In this model, every message has four sides: Next to the factual
content, which is always supposed to be the point, self-revelation, relationship
and appeal resonate as part of each message (Fig. 3.15).
The aspects of self-revelation, relationship and appeal are often not expressed
verbally (digitally) but non-verbally instead (analogue) and thus get encoded via
Factual content Self-revelation

What I want to What I declare about
inform about myself
«It is …» «I am …»
«You are …» «You should …»
Relationship Appeal
What I think of you What I want you to do
and how we relate
Fig. 3.15 The 4 sides of a message (according to Schulz von Thun)
tone of voice, facial expressions or gestures. In Schulz von Thun’s model, the
receiver should have four “ears” according to the four-sided message, see Fig. 3.16.
Depending on which side of a message and thus which ear is in the foreground for
a recipient, his or her reaction can be quite different.
Example
During a meeting, one person is busy with his smartphone. The project manager,
who is chairing the meeting, sees this. Although the person concerned is not
communicating verbally at the content level at the moment, he or she is sending a
piece of information. What does the project manager do with this “communica-
tion”? If he listens by means of the relationship ear, he will feel annoyed or
frustrated. He interprets the person’s behaviour as: “You bore me”, “Your chit-
chat is unprofessional”, etc. If he has a big ear for appeals, the project manager
will look for the fault in himself and his meeting leader and try to change
something: speak faster or work through the meeting points more efficiently.
Inevitably, the project manager will feel stressed.
Consciously or subconsciously, however, people also revealsomething about
themselves with their smartphone. If the project manager can receive the
non-verbal communication on the self-revelation ear, he has another explanation
for it: maybe e.g. that the person is involved in very urgent business proceedings.
284 3 Human
Factual Ear Self-Revelation Ear

Focus on the What does he want to
matter, on objectivity tell me about him?
„What is it about?“ „What does he think
about himself?“
Relationship Ear Appeal Ear

Reaction to appreciation, What does he want
proximity, distance, from me?
warmth, cold „What should I do?“
„What does he think of me?“
Fig. 3.16 The four ears principle according to Schulz von Thun
The person who can receive at the level of self-revelation leaves the problem and
the cause of the corresponding communication with the sender. He runs less risk
of being influenced by emotions that are unfavourable in the current situation. It
makes sense if the project manager confronts the person, possibly only after the
meeting, that it is important for him/her to concentrate fully on the meeting. ◄
In such a conversation, the project manager can use the “complete message”
method by Schulz von Thun as a guide. This is to ensure that as much as possible of
what was sent is also heard, i.e. received in its informational content:
1. if you . . . (factual content: concrete cause, concrete behaviour that set off
something in me)
2. I feel . . . (self-revelation: describe what this does to me)
3. because I . . . (relationship: explanation of what is important to me about the
relationship with you)
4. I ask you . . . (appeal: wish, expectation for the future)
3.9.4 Communication Cycle
The axiom theory and the communication square are summarised in the communi-
cation cycle. When a person wants to send a message, he or she must put it into
certain words or clothe it in an appropriate form of expression. Expectations, feelings
or needs are encoded into digital and analogue communication. This requires the
receiving side being able to decode accordingly. This decoding is a highly complex
process that is influenced by, among other things:
• Selective perception with the dominance of the human sense of sight (Sect.
3.3.3)
• The quality of the relationship (2nd axiom by Paul Watzlawick)
Different people, groups, committees, organisations hear and understand things

differently, assign different meanings to the same words, thereby giving rise to
different feelings. Misunderstandings are therefore predictable and normal. The
result of the decoding process is then what makes it to the receiver; it is the
important, relevant information that he or she takes in. This process revolves around
the following questions again and again:
• Perception: what do I hear and see?

• Interpretation and understanding: what does that mean?
• Sensation: what feelings does this cause me to have?
• Action: what does what I have heard make me do?
Example
The project manager is chairing the weekly project team meeting at 9 am. One of
the sub-project managers arrives a quarter of an hour late and scurries to his seat,
mumbling an apology. At this moment, communication takes place. On the
content level, the non-verbal communication has to do with the timing, the verbal
level is the mumbled apology. In this situation, completely different reactions are
possible from the perspective of the project manager:
The project manager has a good relationship with his colleague. Just last week
he had lunch with him and found out that his wife is in training this week, so
that his colleague has to organise childcare alone. He knows this, understands
and nods sympathetically to his colleague as he takes his seat. On the basis of
the good relationship, he interprets the colleague’s lateness as a self-revelation
regarding his private constellation. He continues the meeting calmly and then
briefly informs the colleague about the points he missed. He asks how the
colleague is doing and gives him an encouraging pat on the back.
The project manager only maintains formal relationships with his colleagues.
He does not care about an informal exchange with them and is focused on a
professional and productive work attitude. He reacts hurt on the relational
286 3 Human
level because he feels that his authority as project manager is not being
respected by his being late. He interprets his self-revelation as “I had some-
thing more important to do”, and possibly as an appeal the request “this
meeting is unnecessary, having one only every fortnight would be more than
enough”. After the meeting, the project manager immediately disappears into
his office, no further exchange takes place. ◄
An identical situation can produce completely different consequences. In the first

case, the solidarity of the project manager can deepen the relationship. In the second
case, the incident can be the starting point for a conflict.
3.9.5 Meta-Communication
" Make the way we communicate with each other an issue.
The process of communication normally consists of a back and forth of sending

and receiving (third axiom of Paul Watzlawick). It is a joint game between two sides,
between action and reaction. In a systems theory approach, this means that it is not
the behaviour of only one side that should be considered, but the rules of the
interplay, the behaviour of both sides and their interdependence.
Example
If, in the above example, the project manager “snaps”, feels disrespected, he can
try to bring his authority even more to the fore. If the sub-project manager falls
behind in a work package, this is commented on with appropriate sharpness. The
project manager does not let the sub-project manager get to him: “At the moment
we seem to be suffering from delays everywhere”. The sub-project manager then
retreats and does not tell his project manager that he has been assigned to a higher
priority project by his boss. This leads to further delays. These are criticised even
more harshly by the project manager. ◄
The behaviour of both is dependent on that of the other. The cycle of an endless
back and forth can only be broken if both talk about how they are communicating,
relating to one another and in which ways both contribute to keeping the back and
forth going. coming to an agreement about how we talk to each other is called meta-
communication, see Fig. 3.17.
" The cause-effect feedback loop can only be broken through personal
conversation. In the above example, the aim is for the two to address the
problem as soon as possible in a bilateral conversation. For this, it is
necessary that both get involved in the relationship to such an extent
that personal aspects such as the family situation but also the emotional
injury can be addressed. In the conversation, it will be important for both
Discussion,
how we talk to each other
Fig. 3.17 Meta-communication
persons to be able to explain the reasons for their own behaviour or

feelings, especially from the perspective of a self-revelation. This means
that a high level of communicative skills are required from both of them,
such as the “I” message or active listening.
3.9.6 I and You Message
In verbal communication, it makes a big difference whether we are using an “I”

message or a “You” message. With a statement that begins with an “I”, I refer to
myself:
• I am not satisfied with the result of your work.

• I'll be annoyed if you’re late for our appointment.
• I am worried that we will lose this customer if we continue to communicate with
him in this way.
In my statement, I emphasise the subjectivity of my perception and its evaluation.

I describe on the level of self-revelation how something or someone affects me. If, on
the other hand, I send “you” messages, I place my evaluation at the centre. I am no
longer communicating at eye level and sound as if I am reprimanding another
person:
288 3 Human
• You did that wrong.

• You should pay attention to your punctuality.
• You are not allowed to talk to the customer like that.
3.9.7 Feedback
In project work, communication often takes place in connection with the control of
processes. This means that the behaviour of people gets addressed. This can take
place with reference to positive cases (confirmation of a performance, a result) but
also in response to negative ones (non-performance, criticism, misconduct). This
response to behaviour is called feedback.
Feedback is a communication to a person informing them how their behaviours are per-
ceived, understood and experienced by others (Klaus Antons).
Such feedback to personal behaviour is important information and provides

orientation and gives a sense of appreciation. This is also the case when it does
not contain praise but rather instead criticism. Then it is particularly important that
the feedback is structured and formulated correctly. The way in which this criticism
is formulated defines the culture and leadership style in an organisation. Is it
feedback about a behaviour with the desire to reconsider and change that behaviour,
or is it an order and at the same time a rebuke?
3.9.7.1 Structure of the Feedback

The following model, based on the Management Forum Wiesbaden, describes the
building blocks of good feedback:
Perception
• What did I see?

• What did I hear?
• What have I observed?
Effect
• What set this off for me?

• What impression do I have?
• What emotions did it evoke in me?
Wish (expectation)
• What behaviour do I hope for in the future?

• What do I expect from you by when?
• How can or will I support you?
Factual content
Self-revelation
Appeal
Encode Decode
Statement
Selective
perception
Relationship
Sender Recipient
Selective
perception
Feedback
Fig. 3.18 Communication circuit
Using this structure, any positive or critical feedback can be formulated. It is

advisable to proceed in this order, from top to bottom, because the individual steps
build on each other logically. However, there can also be exceptions, e.g. if the
emotions are very strong, one can also start with the effect and then describe the
perception. Often it is sufficient to only express one’s perception and then ask the
other person how he or she experienced the situation. The person then describes the
effect, and you can add to or compare your own felt effect. This often means that the
actual criticism has already been voiced.
3.9.7.2 Feedback as a Team Development Tool

Feedback is an opportunity to learn about one’s impact on others, as well as to
review and, if necessary, change one’s own behaviour. Feedback can also clarify
relationships. The response can be verbal, but also through a non-verbal reaction in
the other person’s behaviour to an utterance. In this respect, we constantly receive
and give feedback, often without a word being said about it. This way feedback
between sender and receiver takes place (Fig. 3.18).
Feedback is therefore one of the central instruments of team development. In the
agile approach, this procedure has a fixed place in the sprint retrospective. If we want
to expand our social competence, we are forced to keep learning about the effect of
290 3 Human
I am aware I am not aware
others are aware

1. Public Person 3. Blind Spot
Arena of free action: How others perceive me,
Area which everybody behaviours not known
knows to me
others are not aware
2. Social Facade 4. Personal

Hidden characteristics: Unconscious
my privacy, my secrets Neither accessible to
and needs I do not want me nor others
to share
Fig. 3.19 Johari window
our own behaviour from others. At the same time, we also check what actions of
others set off in us.
Now there are things we know about ourselves and things we do not know.
Likewise, there are things that we make freely available to others and those that we
keep to ourselves. For this purpose, the two social psychologists Joseph Luft and
Harry Ingham have designed a team development model, the Johari Window
(Fig. 3.19). It helps us to better perceive interpersonal relationships.
Thanks to our consciousness and the ability to self-reflect (Sect. 3.3.4), it is
possible for us to understand ourselves. This is represented in the left square by
the fields “I am aware” lying vertically below each other. I am prepared to share part
of this with others in a public person way. In professional work, however, we are
often unwilling to share our entire private sphere with colleagues. Luft and Ingham
refer to this part of our person, which we are conscious of and that is known to us, as
the “social facade” or private sphere. Of course, every person also has a subcon-
scious part. This remains hidden from the person himself as well as from his
environment.
Examples
A product owner in the finance industry, always smartly dressed, loves to go for a
ride on his Harley-Davidson at the weekend in his black leather jacket. He shares
having this “social facade” only with his assistant.
This morning I have a severe headache, but I don’t tell my work colleagues.
They wonder why I attend the meeting with little energy and enthusiasm. ◄
Relevant for feedback is above all the “blind spot”. These are aspects of our
behaviour that we ourselves are not aware of, but which others notice.
Example
Normally, the product owner has a winning personality. He takes time for the
team members and is good at listening. In the current, important project, a new
scrum master has been assigned to him, whom he does not yet know. This stresses
him out. He often does not let him finish talking by interrupting him. Due to the
difficult day-to-day routines of the project, the product owner is under more stress
than ususal. In addition to this, he does not understand that a new scrum master
has just been assigned to him for the current, strategic project. Under these
circumstances, feedback from the product owner’s established colleagues is
very valuable. They can make him aware of what is happening in his behaviour
and also in the communication with the scrum master and how this has changed
compared to previous projects. In this way, this can be made conscious and finally
also worked on to the benefit of team development. ◄
Through feedback (Fig. 3.20) one’s own “blind spot” can get reduced and one
becomes aware of one’s own behaviour. This also makes areas visible in which it
makes sense to receive support from the team. If I explain my own behaviour to
others on the basis of feedback and thus reveal my “social facade”, I can be freer and
more open and become more predictable for others. If all of us who are involved
carry out this process to further team development, then trust, and relationships
develop. This can also be used positively in different ways, for example, by
assigning certain tasks in cooperation according to the concept of Belbin team
roles (Sect. 5.4).
3.9.7.3 Feedback Rules

Feedback is of central importance for personal improvement as well as for team
development. The following rules are to be observed in order to ensure a construc-
tive handling of feedback:
Basic Feedback Rules
• “I-messages” instead of “You-statements”

• Concrete instead of general formulations
292 3 Human
I am aware I am not aware
others are aware
Cooperation is facilitated by Change through

the expansion of the field of giving and taking
free action active feedback
others are not aware
Change through openness

for own and others ideas
Fig. 3.20 Johari window: Further development through feedback
• Keeping perception and interpretation apart

• Accepting feedback without being on the defence and seeking justification
• Seeing feedback as my subjective perception of a behaviour
Give Feedback
• Concretely: I formulate statements about how I perceive the situation and how it
affects me.
• Descriptive: I make descriptions as accurate as possible and do not interpret.
• Realistic: I stick to a standard and adjust my feedback to fit the situation.
• Immediately: I give feedback as promptly as possible to enable the reference to
the situation and reality.
• Demands: I do not impose my feedback on the other person.
• Put into perspective: I formulate “I-messages” and do not evaluate.
Receive Feedback
• Leave out excuses: Do not interrupt feedback givers.

• No defence: Clarify the way the other person sees it by asking questions.
• Set boundaries: I formulate what information I want.
• Accept: I do not argue, justify or defend myself.
• Check: I assess the meaning of the statements for me personally.
• Give Thanks: I thank you for the feedback, even if it was given in an
inappropriate way.
• Allow time: I take time to examine the meaning of the statements for me
personally and share my reactions if it seems true to me.
Effect of Feedback
• Feedback allows me to learn how I am seen by other people.

• Feedback reinforces positive behaviour.
• Feedback serves to clarify relationships between people.
• Feedback straightens out behaviour that is not helping the group.
• Feedback helps to better understand the perceptions and behaviours of others.
3.9.8 Questioning Techniques
An open heart and an open mind depend on us not stopping to ask. An exclamation mark
always puts an end to everything (Bertrand Piccard).
According to the systemic worldview (Sect. 1.6.2) we can never “know” what
someone is thinking, how they are doing or what is bothering them. The only way to
find out is to ask questions.
3.9.8.1 Open and Closed Questions

Basically, there are no wrong questions. The art of the questioning, seen as a
technique, is to ask the right question that helps to get the desired information in a
specific situation. Closed questions help to establish facts or to confirm information.
They can or should be answered with a “yes” or “no”, or with specific information.
Example
• Do you get along with your boss?

• Do you speak French?
• Is this a photo of your children?
• Do you have any questions?
• Are there still risks? ◄
Closed questions are contrasted with open ones. The latter are intended to . . .
294 3 Human
• Stimulate new thought processes and reflections in interlocutors

• Motivate respondents to express their thoughts
• Stimulate others to find something new, leading them out of a block in thinking
• Provide as much information as possible, that this might have a clarifying effect
• Enable different points of view and perspectives to be illuminated
• For the examples above, the open questions are:
Example
• How is the cooperation with your boss?

• Which languages do you speak?
• Who are the children in the photo?
• What other questions do you have?
• What are the main risks from your perspective? ◄
Questions that begin with WHO, WHAT, HOW, WHERE, WHEN, WHY are
called W-questions and are also used to help describe a particular situation as
comprehensively as possible. For example, to define an information process: Who
informs whom about what? How and by when will the information be distributed?
If a conversation is conducted via open questions, the interlocutor can decide for
him/herself what information and to what degree of openness or confidentiality
he/she wishes to share it. The question about the children in the photo can be
answered briefly. The other person can also talk on a confidential relationship
level about the last holiday during which the photo was possibly taken. The open
question does not put pressure on the person and does not lead to a kind of
interrogation the way closed questions do.
3.9.8.2 Active Listening
Technique and Method

In the communication cycle (Sect. 3.9.4), it is impossible for something to be
decoded exactly as it was encoded. The “translation errors” can be recognised and
corrected by active listening. Active listening always means “wanting to under-
stand”. On the one hand, the receiver of a message can reflect back to the sender what
he or she has understood. But I can also use active listening in meetings if I have the
feeling that the meeting participants are talking past each other, if I want to get to the
heart of something or if I want to reduce the pace of the conversation.
Active listening allows the listener of the message either to confirm a piece of
information or to formulate it more precisely or to have the other person clarify
statements that were not intended.
Example
Active listening checks whether the other person’s statement has been correctly
understood:
Verbalise emotions
Stage 3 «Your
- Capture mood
emotions»
- Assumptions about perceptible emotions
- Mirror feelings
Formulate core statement «Getting to the

Stage 2 - Summarise point»
- Mirror
- Feedback
Establish relationship «I am all

Stage 1 - Eye contact ears»
- Create framework
- Listening nod
Fig. 3.21 Active listening as a basic attitude and developmental support
• Did I understand you correctly that you will complete the new draft feasibility study by the
end of September?
• In my words, that would mean we can’t deliver the specification to the client yet until the
head of development confirms the test results for the prototype? ◄
Active Listening as a Basic Attitude and Development Support

The model was originally described as a technique by the American psychologist
and psychotherapist Carl Rogers in 1942. In 2005 Friedemann Schulz von Thun
derived a basic attitude from that and in 2013 Eric Lippmann formulated a coaching
intervention. An effective coaching method can be seen in the three-stage model of
Active Listening (Fig. 3.21). This coaching is about “wanting to understand empa-
thetically” (Schulz von Thun), and about reporting back the content and emotional
state of one’s counterpart (Lippmann), whereby that emotional state is included in
particular in the 3rd stage. In this way, the coachee can recognise where his
emotional “entrapment” with the situation comes from.
Stage 1: Establish Relationship

At the relationship level, signal to the interlocutor that I am “all ears”. In this phase,
the framework for the further conversation is created and trust is built up, which is
necessary later so that personal feedback is also made possible.
296 3 Human
Stage 2: Formulate Core Statement

By asking questions and summarising, an attempt is made to work out the essentials, the
core message. Here it is important that the interests become visible. Feedback about the
situation is also part of this process. The interviewee should be able to “get to the point”.
Stage 3: Verbalise Emotions

With questions, hypotheses, assumptions, the coachee is supported to express his/her
feelings, be they verbal or non-verbal. Active listening consists of the coach trying to
put these feelings into words: “ . . .and you are quite angry about that. . .”. Even if this
assumption is not exactly true, it often helps the coachee to clarify his/her feelings.
This kind of listening is also called “mirroring”.
3.9.8.3 Other Question Types

Below are listed other types of questions that can help you to maintain an open spirit
regarding this process:
• Circular questions allow the perspectives of other people to be included in the

conversation, thereby incorporating further perspectives:
“If I were to ask your supervisor, what would he say?”
• Goal-oriented questions allow you to clearly define an objective:
“How can you tell if the objective has been reached?”
• Resource-oriented questions are used in difficult situations to help the counter-
part become aware of his or her resources:
“Was there a time when the working atmosphere was better?”
• Scale questions ask the counterpart to move from the emotional level to the
rational level and give an evaluation of a situation:
“On a scale of 1-10, how would you rate your performance?”
• Hypothetical questions prompt the other person to think through a scenario
again on the basis of an assumption:
“If person A were to leave the project team, what would be the consequences for
team performance?”
• The heart question is used to question positions in order to find out what is close
to a person’s heart:
“What exactly is important to you in this?”
3.10 Personal Development
We cannot live just any life, but only our own (Remo Largo).
In Sect. 3.5.6 the three strategies available to people for dealing with challenges,
and thus also for personal development, are explained: Change, reassessment or
displacement. Here, further aspects are presented that can support the reader in his or
her personal development.
3.10 Personal Development 297
World of work
Work
Profession
World of relationship World of one‘s own

Partnership Space for yourself
Family and others
Fig. 3.22 Life worlds of humans (Based on: Walser & Wild, 2002)
3.10.1 The Three Living Worlds
The career choice that brought you to project management is hopefully not just
coincidence, but also has something to do with your basic needs (Sect. 3.3.2) and
competences (Sect. 3.1). Gainful employment lies at the centre of life for many
people in our culture. The explanations on the topic of meaning reveal that it would
be an excessive demand on gainful employment to therein expect a very high degree
of accommodation for this topic (Sect. 3.7.3.3). It is therefore important to take a
holistic approach to self-responsible further development. Here the model of the
three living worlds helps (Fig. 3.22).
In this model, the world of work stands on the foundation of the world of
relationships and the world of one’s own. The world of work is of course not
only understood to mean gainful employment, but also family or voluntary work.
However, human beings as social beings need more in order to have a flourishing
existence than simply “just” work. Above all, the quality of our relationships has a
significant influence on our psychological well-being. Of course, we also want to
maintain good relationships within the world of work. But in this field, relationships
are always also shaped by positions, roles, power or organisational cultures. In truly
authentic relationships, we can be as we feel. We don’t have to play roles and are not
restricted by power relationships. While the relationships of the world of work are
based on respect and recognition. the world of relationships should be characterised
298 3 Human
by love and empathy. The world of one’s own forms the space for our personal
interests, hobbies and also for our extended circle of friends.
" Conflicts and crises can happen to us at any time in gainful employment,
even through no fault of our own. It is then that a dream job suddenly
turns into a heavy burden. The better we take care of our relationships
and our “world of one’s own” when times are good, the more we are able
to rely on them when a crisis in the world of work hits us unprepared. In
such (stress) situations, closeness to our fellow human beings is very
precious (Sect. 3.5.6).
3.10.2 Self-Knowledge
Every person has his or her own, specific personality, character traits, strengths and
weaknesses. The personality of an adult can only be changed to a small extent; it is to
a large extent the result of genetic disposition as well as socialisation and formative
life experiences. Much more important than change in personality development is to
increasingly get to know oneself better and better and to be affirmative with oneself.
With this knowledge, one seeks or develops a working environment fitting one’s
personality traits as well as possible. Two fundamentally different methods are
available for this process of becoming aware.
3.10.2.1 Personality Typologies

Typologies, such as Belbin’s Team Roles, the golden profiler of personality (GPOP)
by Golden, and Bents and Blank are based on empirical observations. The character
of a person is assigned categorised according to different types. Even in ancient
times, attempts were made to derive typologies of different personalities based on
human behaviour. Empedocles (495-435 BC), for example, described personality
types based on the four basic elements, which in Antiquity were considered to be air,
water, fire and earth. Hippocrates (460-377 BC) described four human
temperaments, based on four bodily fluids, namely blood, phlegm, yellow bile and
black bile, which, according to Hippocrates, characterise people kin different ways.
About 200 years later, the Roman physician Galenus categorised according to types
of temperament: one could be sanguine, phlegmatic, choleric or melancholic; these
terms are often still used today. In modern times, Ernst Kretschmer (1888–1964)
focused more on the physiques of people and assigned character types depending on
physical constitution. According to him there areAsthenic, Athletic, and Pyknic
types of physiques
3.10.2.2 Psychometric Methods

The behaviour of people is derived from the scientific measurement of various
behaviours, motives, attitudes and values. These psychological test procedures are
used in assessments, among others in personnel, traffic, school, and legal psychol-
ogy. Examples of this procedure are Workplace big five (WPB5), the VIA Character
Strengths or the Reiss motivation profile. Three personality typologies are presented
below.
3.10.2.3 Belbin
How do you behave in teams? Or even more specifically: How do you behave under
stress or in conflicts? If you are honest, you cannot answer this question in any exact
way, which is because in these exceptional situations, people lose their ability to self-
reflect (Sect. 3.3.4). But there are experts who can tell you exactly how best to
behave under exceptional circumstances: Your colleagues and employees. Because
they have often experienced and observed you in such situations. Their feedback
(Sect. 3.9.7) helps you to gain knowledge about yourself. The concept of Belbin
team roles can be used on two levels:
• Personal self-knowledge: Belbin provides a structured way of becoming aware

of your personal blind spot through a comparison of your self-image and how
others see you.
• Success factors of cooperation: The Belbin concept makes it possible to put
together teams that are as well-balanced as possible and thus also efficient (Sect.
5.3).
3.10.2.4 Belbin Basics

Meredith Belbin developed the concept of the Belbin team roles from asking the
question why certain teams succeed and others fail. He developed a management
game simulating work life. This game contained all the main variables that are
typical of the problems of decision-making in organisations. Then, test persons were
formed into different kinds of company teams. The team members were assessed
according to their personalities by means of psychometric tests and a test of their
ability to think at a high level (Critical thinking appraisal)) to assess their personality.
During the execution of the management game, the contributions of the individual
team members were scientifically recorded. At the end of the game, the economic
success of the team was measured.
3.10.2.5 What Is a Team Role?

Belbin understands a team role as: “A particular way of behaving, contributing and
interacting with others”.
A key finding with regard to the individual participants was that they behaved
very differently in the same situation. These different behaviours or behavioural
clusters were assigned by Belbin to nine team roles (Fig. 3.23).
Belbin distinguishes three competence groups and assigns team roles to each
of them:
300 3 Human
Plant Completer Finisher

theorising perfecting
Monitor
Evaluator
assessing
impartially
Shaper Specialist
driving specifing details
Co-ordinator Teamworker
generalising supporting
Resource Implementer
Investigator applying
finding new possibilities
Fig. 3.23 Belbin team roles (Belbin Germany e.K.)
• Accomplish: Shaper, Completer Finisher, Implementer

• Thinking: Specialist, Plant, Monitor Evaluator
• Communicate: Teamworker, Co-ordinator and Resource Investigator
3.10.2.6 Each Team Role Has Positive and Negative Characteristics

When working with team roles, it is important to emphasise that there are no “good”
or “bad” ones. Each team role contains important positive characteristics
(strengths) for successful teamwork. Without the ideas of the plants, no project
can develop innovative solutions. Without the shapers, the project remains stuck in
theoretical concepts and is not implemented. Without the enthusiasm of the resource
investigators, new possibilities are not explored, or stakeholder management is
neglected.
Just as the shadow belongs to the light, these positive qualities, precisely because
they tower above the average of the team, have a negative consequence and thus
constitute a weakness: the plants fall in love with their own solutions, even though
they do not meet the needs of the customers. The shapers have a tendency to run
headlong into the wall, snub other people with their forward momentum and do
things they shouldn't do. The resource investigators tear into many things but then
don’t really finish anything.
3.10.2.7 Belbin Team Roles to Increase Self-Knowledge

The basis for the personal team role report is formed by means of self-assessment.
This is done using a structured questionnaire. This is then contrasted with four to
eight external assessments from one’s own field of work. The development potential
of each individual lies, above all, in the differences between self-perception and
external perception: it is often the case that one’s own strengths are underestimated
or not seen at all.
Example
If you have always had new ideas since your youth, a certain level of creativity
comes naturally to you (plant). This is also the case if you have become accus-
tomed to taking things into your own hands instead of just talking, or if it is
normal to you to create a benchmark with other market participants in case of a
problem (shaper) or to activate your own network instead of wanting to reinvent
the wheel yourself (resource investigator). ◄
So other people can first of all help you to become aware of your own strengths.
Of course, they are then also a good mirror for sensitisation to the behaviour patterns
because of which someone feels irritated or is even rejected. For Belbin to be a
benefit on a personal level, well-developed personal communication skills are
needed in all participants (Sect. 3.9). External assessments, according to Belbin,
are feedbacks. These can only be constructive if the person receiving the feedback
can distinguish between perception and evaluation. Those who see feedback as an
evaluation of their own person may find it threatening. They will try to protect
themselves from it. However, when feedback is used to assess how one person
affects another, one’s own subjective perception is made available for this purpose.
How the person receiving the feedback uses and interprets, it is up to him or her.
3.10.2.8 MBTI
Based on the developmental psychology described by Carl Gustav Jung, Isabel
Myers and Katharine Briggs in the USA formulated the personality typology
MBTI (Myers-Briggs Type Indicator). Since 1999, the Golden Profiler of Personal-
ity (GPOP) test procedure, which is based on the same theory and has been further
developed, has also been used. Today, they are both among the most widely used
analytical instruments, as they are available in several languages and are supported
by a very large test base of several million evaluations. Its success is also based on
the fact that it builds on dimensions that describe essential characteristics of the
occupational environment (Fig. 3.24): Attitude to the environment (introversion or
extraversion), attitude to acting (judging or perceiving), Perception (sensing or
intuition), and Decision (thinking or feeling). These four basic dimensions are
each described with their characteristics. The possible 16 variations result in person-
ality profiles with very different strengths and weaknesses.
These type combinations result in 16 personality functions, consisting of the
combinations of the respective four preferred attitudes. This makes it possible to
302 3 Human
Attitude to the environment

E I
Contact
Extraversion Introversion
Perception
S N
Recording of information
Sensing Intuition
Settings
Features
Decision
T F
Assessment of information
Thinking Feeling
Attitude to acting
J P
Approach
Judging Perceiving
Fig. 3.24 Dimensions of MBTI
identify personality profiles that are better suited to certain roles, functions and tasks
than others. Many companies use these findings when filling positions and putting
together teams.
3.10.2.9 VIA Character Strengths

Strength research forms an essential element of positive psychology (Sect. 5.4.2). It
conducts scientific research into optimal human functioning. It is therefore not about
finding out what makes people sick and how they can be healed again. Rather,
positive psychology focuses on what helps people and communities to thrive.
Character strengths are referred to as the backbone of positive psychology.
Character strengths are positive human qualities and abilities that are personally
satisfying, and that do not demean other people, that are present across cultures, and
have positive effects for the individual and his surroundings. A widely supported
body of academic work has defined 24 character strengths that distinguish people
from one another (Niemiec & McGrath, 2019). The character strengths, in turn, form
gateways to the six universal virtues (Table 3.2).
Character strengths are multi-dimensional: The question is therefore not whether
a person has it or not (that would be categorising). It is rather that every person
carries all 24 character strengths. These show up on a broad continuum to either a
greater or a lesser extent. In addition to personality traits, the context, i.e. the specific
situation in which a person currently finds himself or herself, also has a great
influence on how strongly a person’s character strength is expressed.
Table 3.2 VIA Virtues and character strengths

Virtue and description Associated strengths and description
Wisdom Creativity: Finding original ways of doing
Cognitive strengths involving the acquisition things
and application of knowledge Curiosity: Fascination for subject areas and
topics
Judgement: Thinking things through, open-
mindedness
Love of learning: Systematically adding to
knowledge
Perspective: Being able to give wise counsel to
others
Courage Honesty: Authenticity and integrity
Emotional strengths that overcome inner or Bravery: Not shrinking from fear
outer resistance through willpower Perseverance: Finishing what one starts
Zest: Enthusiasm and energy for life
Humanity Kindness: Care & compassion, generosity
Interpersonal strengths that enable loving, Love: Valuing close relationships with others
human interactions Social intelligence: Knowing what makes other
people tick
Justice Fairness: Not letting feelings bias decisions
Strengths that promote community about others
Leadership: Organising group activities
Teamwork: Social Responsibility, loyalty
Temperance Forgiveness: Giving people a second chance
Strengths that protect against excesses Humility: Letting your achievements speak for
themselves
Prudence: being careful, not taking undue risks
Self-regulation: Managing impulses and
emotions
Transcendence Appreciation of beauty & excellence: Awe,
Strengths that connect us to the larger wonder, elevation
universe and provide meaning Gratitude: Thankful for the good
Hope: Optimism, future orientation
Humour: Bringing smiles to others
Spirituality: Religiousness, faith, purpose,
meaning
Within character strengths, signature strengths have an important meaning. Sig-

nature strengths are those positive, personal qualities that an individual possesses,
upholds and frequently exercises. They represent the core and essence of a person.
Thus, signature strengths are an important part of our identity. Those who succeed in
using four or more of their signature strengths at work have more positive
experiences and are more likely to see their work as a calling, according to a number
of studies. Signature strengths also contribute to achieving goals, initiating positive
emotions and meeting basic needs. In contrast, people who cannot show their
signature strength will sooner or later feel a sense of emptiness.
Signature strengths do not only contain our energy and our personality. It is
because we master our signature strengths so well, we can also exaggerate them
(“too-much-of-a-good-thing-effect”): If a humorous person gets carried away, he
becomes silly. Modesty, when exaggerated, leads to self-deprecation—and
304 3 Human
-- ++
Underload Overload
Conformity Creativity Eccentricity

Disinterest Curiosity Indiscretion
Unreflectiveness Judgement Narrow-mindedness
Self-indulgence Love of learning Know-it-all attitude
Superficiality Wisdom Insolence
Fig. 3.25 Zone of strength (golden mean)
friendliness then may turn into pushiness. On the other side of the continuum would
be understatement; this too is harmful.
The process of increasing strengths implies that people are aware of their
strengths and can use them purposefully for their own development and for the
benefit of their fellow human beings and also for organisations. However, it, too,
involves a high degree of self-reflection so that one does not lose oneself in
exaggeration or understatement. The zone of strength lies in the “golden mean”.
The “golden mean” is the zone of strength that has to always be located so that the
character strength of “creativity” can be used to the right degree in the right situation,
so that the desired results can be found for oneself and for other people (Fig. 3.25).
An important principle in this model is not simply to use character strengths, but
to find out how to employ a specific strength effectively depending on the situation,
in order to create the desired result. Personal character strengths can be determined
via a free online questionnaire on the website of the non-profit organisation “VIA
Institute on Character” (www.viacharacter.org).
3.10.3 Coaching
Similar to sport, coaching is also spoken of in a professional context when

individuals or teams receive individual professional advice and guidance.
Such support can make a lot of sense for all project participants in specific
situations. Coaching offers fields of learning and reflection that are specifically
geared to the respective functions and roles of the coachee. The content can focus
on considerations in the planning or implementation of the next work steps, on
behaviour in critical situations and in dealing with conflicts. However, reflections are
also useful in order to better understand, analyse and learn from reactions, and from
behaviour and results of past situations. On the one hand, this helps to deal with
one’s own disappointments and fears, and on the other hand, and above all, in order
to better configure future situations.
" According to the model of the three levels of cooperation (Sect. 1.5), it
makes sense for the project manager to check whether his design and
leadership intervention . . .
• Enables knowledge- and result-oriented work at the content level

• Promotes a climate of acceptance and trust at the relationship level
• Sees to it that order and favourable structures are ensured at the
organisational level
In coaching, care must be taken to support the project manager in correctly

grasping and recognising the status of the project or to discover where risks currently
remain. From this, he develops scenarios for the further process design. Coaching a
project manager is often quite difficult, as it is challenging to remain restrained while
in the role of a coach in the strict sense. Rather, the coachee needs an interlocutor for
strategy considerations and for his reflection on what has happened so far, for
planning the next steps, for conflict management, as well as a supplier of methods,
a kind of “frustration listener” and role guardian. This complexity also places some
demands on the coach. He should have a command of the following topics:
• Theoretical approaches to work such as systemic thinking, simultaneous engi-

neering, organisational development, change management
• Working techniques such as time management, moderation, crisis intervention
• Peculiarities of the dynamics of projects in organisations
• Dealing with pressure situations created by the different stakeholders
The more experience the coach can bring to the table, the higher his acceptance by
the coachee will be. On the other hand, it is all the more important to clarify in an
agreement which advisory services the coachee wants: coaching in the sense of
process advice or also expert advice on technical- and methodological questions.
" Coaching should be voluntary. The coachee should want the coaching
and not see it as a rebuke. It is not a matter of glossing over mistakes in
the descriptions of situations or embellishing something in order to
look good.
Coaching is not an assessment in the sense of an examination, but an opportunity

to examine, critically question and strengthen the quality of one’s own work
employing outside help. It helps to recognise and to then qualify risks, to understand
one’s own and other people’s motivations, to broaden one’s perception through the
use of an outside perspective and, above all, to develop possible alternatives to a
wide variety of problems associated with project management.
306 3 Human
3.10.4 Intervision
Another platform for personal development is intervision. The psychoanalyst

Michael Balint developed a method for case work among psychoanalysts. The
method is based on the basic idea that in problem situations, the contributions of
others are often well recognised, but that one’s own contributions to the problem are
partially concealed (Sect. 3.9.7.2). Neutral observers of a situation notice such
contributions quickly. Through valuable, critical feedback, they can reveal new
views related to the problem and identify new approaches to solving it. The
intervision method structures the treatment of a problem that a group member
wants to solve together with people not involved in it.
Michael Balint has found that it is helpful to discuss the outsiders’ impressions
without the caseworker immediately commenting on them. In this way, a Balint
session has a clear structure:
1. The Case Giver Describes His Problem

The group listens to this and does not interrupt him. The listeners note down what
comes to their minds while he speaks, what they feel and how they experience the
case giver (for instance, as insecure, nervous, arrogant, dissolute, etc.).
2. The Group Asks Comprehension Questions
The group only asks comprehension questions, it asks no questions that contain
an assumption, a hypothesis, or an interpretation, etc. The facilitator makes sure
that only a sense of understanding is thereby improved and lets the asking of
questions continue until he/she feels that the group has enough information for
the next phase. This can take different lengths of time.
3. The Audience Describes Their Hypotheses
Thoughts, impressions, assumptions, causes etc. are allowed to be put forward,
but not yet any solutions. The audience is permitted to then use its imagination
freely and without restrictions. Someone writes down the group’s feedback in key
words onto a flip chart. The case giver remains turned away from the group,
listening without commenting—not even doing so non-verbally. He is not
allowed to intervene, but he may note down his thoughts, ideas, etc.
4. The Case Giver Names the Hits
He goes through the list and says what applies to him and why or what is incorrect
or to what degree something is true for him. He crosses out the “false reports”. His
subjective view is correct! While the facilitator strictly observes the rules of
speech in the first three steps, he can allow more discussion to take place in this
phase.
5. The Group Develops Proposals for Solutions
The case giver or a participant notes down and visualises the suggestions. If
necessary, the solution is simulated in a role play.
6. The Final Round
This gives the case giver the opportunity to share with the group what they have
learned from the session. The other group members reflect on what they have
learned for themselves. The more personally exposed the case giver is, the more
References 307
important it is for the rest of the group to say something about themselves at that
stage.
3.10.5 Upside or Downside Strategy?
Change, reassessment or displacement: According to which criteria can we align our

personal development? The upside or downside strategy offers an effective approach
here (Dobelli, 2017b). Upside refers to all positive characteristics that are to be
achieved via an action or change. The downside strategy is exactly the opposite.
Example
• Upside: What is it that motivates me? How can I experience more meaning-
fulness? Or in general: What promotes a better life?
• Downside: What demotivates me? When do I feel stressed? And why? What
pointless tasks do I want to protect myself from? Or in general: What prevents
me from leading a better life? ◄
In many cases, the downside strategy is much more effective: the things that cause
us trouble, that seem pointless or that demotivate us—are tangible. We experience
this every day. On the other hand, it is much more difficult to ask oneself what a
suitable job might look like, what it is that would make me more satisfied. The effort
needed to keep switching from the downside to the upside perspective is definitely
worth it.
References
Ballreich, R., & Hüther, G. (2009). Du gehst mir auf die Nerven! Neurobiologische Aspekte der
Konfliktberatung. Concadora Verlag.
Bamberger, G. (2005). Lösungsorientierte Beratung. Beltz Verlag.
Biswas, C. (2015). Hier entsteht die Zukunft. NZZaS. 20.12.2015.
Brand, C. (2017). Tausendmal gescheitert. NZZ. 4.06.2017.
Covey, S. (2020). The 7 Habits of Highly Effective People. Simon & Schuster.
Csikszentmihalyi, M. (2004). Flow, the secret to happiness. Retrieved on 23rd of January 2018
on TED: ted.com.
Dobelli, R. (2017a). Die Kunst des guten Lebens. Piper Verlag.
Dobelli, R. (2017b). Ergründen Sie Ihre Downside. NZZ. 9.09.2017.
Drath, K. (2014). Resilienz in der Unternehmensführung. Haufe Verlag.
Dumetz, J. (2012). Cross-cultural management textbook. CreateSpace Independent Publishing
Platform.
Esch, T. (2014). Die Neurobiologie des Glücks. Georg Thieme Verlag.
Heller, J. (2013). Resilienz – 7 Schlüssel für mehr innere Stärke. Gräfe und Unzer Verlag.
Hirschhausen, E. (2010). Glück kommt selten allein. Rowohlt Verlag.
Hüther, G. (2016, 2001, 12. Auflage). Bedienungsanleitung für ein menschliches Gehirn.
Vandenhoeck & Ruprecht Verlag.
Kalisch, R. (2020). Der resiliente MENSCH. Piper Verlag.
308 3 Human
Kaluza, G. (2018, 2004, 4. Auflage). Stressbewältigung. Springer Verlag.

Largo, R. (2017). Das passende Leben. Fischer Verlag.
Lippmann, E. (2013). Coaching. Springer Verlag.
Müller, G. (2015). Innovation wird von unten erzeugt. NZZ. 5.06.2015.
Niemiec, R., & McGrath, R. (2019). The Power of Character Strengths. Official Guide from the
VIA Institute on Character.
Pfläging, N. (2015). Organisation für Komplexität. Redline Verlag.
Rager, G., & von Brück, M. (2012). Grundzüge einer modernen Anthropologie. Vandenhoek &
Ruprecht.
Schmid, W. (2010). Auf der Suche nach Glück. NZZ Format.
Schneider, S. (2003). Trau, Schau, Wem. Input DRS 3.
Sprenger, R. (2014). Mythos motivation. Campus Verlag.
Stadelmann, U. (2017). Warum unserem Hirn teurer Wein besser schmeckt. NZZ. 15.11.2017,
S. 25.
Steiger, T. und Lippmann, E. (Hrsg.), (2008. 3. Aufl., Bd. I). Handbuch angewandte Psychologie
für Führungskräfte. Heidelberg: Springer Medizin Verlag.
Walser, C., & Wild, P. (2002). Men’s Spirit. Spiritualität für Männer. Herder Verlag.
Further Readings
Amrein, M. (2015). In unserem Ohr steckt eine Wasserwaage. NZZaS. 13.09.2015.
Donzé, R., & Pfister, F. (2015). Leben heißt spüren. NZZaS. 11.10.2015, S. 53 ff.
Hirschhausen, E. (2016). Wunder wirken Wunder. Rowohlt Verlag.
Hüther, G. (2016, 1997, 13. Auflage). Biologie der Angst. Wie aus Stress Gefühle werden.
Schulz von Thun, F., et al. (2005). Miteinander reden: Kommunikation für Führungskräfte.
Rowohlt Verlag.
Leadership
4
In most cases, the complexity of today’s projects requires interdisciplinary coopera-

tion. In order for this to succeed, those responsible for projects need a healthy
amount of leadership competence to give their teams the right impulses, both in
the agile and in the traditional approach.
This chapter looks at different leadership styles and covers the relevant aspects of
leadership in a project, such as agreeing on tasks, competence and responsibility,
motivation as well as effective delegation, dealing with power and authority. Other
aspects such as self-organisation or the central competence of negotiation are also
covered in depth. The topics are structured according to their relevance for the agile
and the traditional approach.
4.1 Leadership and Cooperation
In projects a recurring task is to develop creative solutions for upcoming problems of

medium to high complexity. Project teams create new ideas, formulate visions and
goals. For a limited period of time, they enable interdisciplinary cooperation
between experts from a wide range of disciplines. The hierarchy of the line
organisation aims at exactly the opposite: the respective experts are concentrated
and assembled there according to their areas of expertise.
This gives weight to another important factor in project work: it is about devel-
oping a form of cooperation and cohesion so that the interdisciplinary team can work
towards the common goals. This form of cooperation is oriented towards the agile,
traditional or towards a mixed (hybrid) approach, as explained in Chap. 2. However,
the form of cooperation must never be arbitrary.
In terms of project team leadership, the following aspects are essential:

https://doi.org/10.1007/978-3-662-66211-3_4
310 4 Leadership
Project Groups Have Valuable Performance Advantages and Solve Complex

Tasks Better
Complex tasks contain a high number of unknowns. In order to develop solutions, a
wide range of specialists and people fulfilling different functions have to work
together in project teams. Interdisciplinary and cross-organisational project teams
thus develop a strong performance advantage thanks to the diversity of their com-
bined knowledge and the large amount of information and experience that is not
available anywhere else in the organisation. Direct team discussions break down the
communication barriers of hierarchy. The interaction of all participants supports the
problem-solving process. With optimal performance and commitment, the team
develops solutions in a short time which are based on high-level subject matter
expertise and that met by broad acceptance.
Consensus and Acceptance Are Greater When There Are Team Solutions
Projects often take place in an environment full of conflicting interests and demands.
For the development of common thrust and the implementation of the solutions
developed, it is crucial for the stakeholders of the different organisational units to
identify with the project results.
The joint development process brings with it that the learning experience and the
knowledge of the limits of organisational, financial, or personnel feasibility increase
among the team members and the various bodies within the organisation. The
willingness to find consensus and to accept the solutions developed in the project
team thereby increases. Outside the project team, however, this development only
takes place if the project team members succeed in carrying the solution process
back to their line organisation.
Setting out for New Frontiers Is Easier When This Is Undertaken Together
Breaking new ground means saying goodbye to the familiar, which is always
associated with uncertainty and fear. Strength grows out of the combined activity,
the participants become more courageous and willing to take risks during the course
of events. This can lead to leaving familiar paths and to, while taking these, thinking
up and trying out truly innovative and unusual solutions.
The enthusiasm of a team can make individuals rise above their limits and it can
thus motivate them to achieve top performance. By encouraging each other, chal-
lenging each other, but also stimulating and supporting each other, creativity,
originality, and innovation become possible to an astonishing extent in a well-
functioning team.
4.2 Leadership: What Is It?
Every team needs leadership, regardless of whether it works according to the agile or
the traditional approach. The word leadership is often experienced in a very ambiv-
alent way by the people involved. Some think of responsibility and challenge. Others
tend to think of domination and command and thus of oppression and a means of
4.2 Leadership: What Is It? 311
Table 4.1 Definition of leadership in projects

Leadership has to. . . • Provide orientation
• Live and enable human relationships
• Ensure that the required objectives can be achieved
Leadership requires. . . • Power consciousness
• Self-awareness (self-reflection)
• Courage
asserting one’s own claims. In fact, the word “leadership” indicates power and
influence over others. Those who have leadership exercise power over people or
groups of people. However, the way in which this power is exercised is ultimately
decisive for the quality of the leadership work and for whether it results in leadership
success.
" There are a wide variety of definitions of leadership, as the following examples
demonstrate:
• Leadership means “setting something in motion”: Those who lead ensure that
something moves. Leadership is about movement, change, development. Leader-
ship is the medium of that movement. Leadership initiates change and ensures
development.
• Leadership means “giving direction”: If we think of a “routing”, for example, the
word leadership means showing the way. Leadership gives orientation as to
where the movement should go.
• Leadership means convincing people of an idea and enabling them to transform
this conviction into action.
• Leadership always takes place in relationships. Leaders and those led behave
according to their own subjective concepts, which are also group-specific and
situation-dependent.
• Leadership is the goal-oriented, social exertion of influence to accomplish com-
mon tasks in or with a structured work situation.
• Leadership means constant problem solving in social systems.
• Leadership is the recognition, design, and control of interpersonal processes and
can be divided into two parts, namely referring to leadership activities and
leadership behaviour.
Instead of “setting something in motion” and “giving direction”, we can also

define leadership in traditional and hybrid projects as follows (Table 4.1).
Self-organised teams, as we know them in agile project management, also need
leadership. In this context, we speak of collegial leadership:
Collegial leadership is the leadership work taken on dynamically and decentrally by many
colleagues according to the pull principle instead of centralised leadership by a few exclusive
leaders according to the push principle (Oestereich & Schröder, 2020, p. 32).
312 4 Leadership
In the traditional understanding of leadership and thus also in traditional project

management, specific people and bodies are endowed with leadership competences
and management responsibility. In the self-organisation of agile project manage-
ment, the manager is removed. The team as a whole takes over the leadership work.
However, this is in turn embedded in a system with specific further leadership
competences, as explained in Sect. 5.5.
4.3 Different Forms of Leadership
A project is always ostensibly based on the achievement of objectives and thus on

the work being done in the system (Sects. 1.5.1 and 5.2.4). For this to happen,
however, essential framework conditions need to be created at the relationship and
organisational level—and work hast to be done on the system. For the work on the
system there are different forms of leadership.
Leadership = Management
In a comprehensive business sense, it is understood to mean leading and managing a
company, an organisation or a project, etc. Corporate management is concerned with
securing the existence of the company under changing conditions. It assesses the
influences of the environment and uses the knowledge gained to adapt the company
to the circumstances. Internally, it takes into account the existing strengths, abilities,
and resources. The strategies, corporate goals, and corporate policy are derived from
a combination of external and internal influencing factors. Similarly, managing a
project can be understood as securing the existence of the project in the organisation
and the permanent adaptation to the changing framework conditions and influencing
factors. Here it can be observed that more and more companies are changing from a
hierarchical to a sociocratic or holacratic organisation.
Leadership = Employee Management

In a narrower sense, one speaks of leadership when a conscious and goal-oriented
influence is exerted on employees. Employee leadership is shaped by changes in the
environment. An intelligent management can quickly adapt to new situations. It
needs many competent people who are in the know and who are willing to think, act,
and take responsibility. This requires a high degree of transparency in the area of
information and communication, coordinated interaction between all those involved,
and a high level of trust between staff and managers. Leadership here means exerting
influence on the behaviour of employees so that goals can be achieved together with
them. When it comes to issuing, demanding, and correcting goal-oriented orders, the
project manager takes on the role of employee leadership like a manager would.
Leadership = Coaching
The project manager also has the task of supporting and promoting his employees in
a resource-oriented way and developing their personality. This is what the term
coaching stands for. The element of leadership in partnership is a useful addition to
4.4 Leadership Styles and Models 313
the other instruments of personnel development. In the role of the coach, he is a

companion and trainer. He pursues the goal of supporting his project staff in such a
way that they can act independently and on their own responsibility. Coaching
quality is characterised by realistic implementation, concrete results, and
sustainability.
Leadership = Dynamic and Distributed Leadership Work

In collegial leadership, the actual leadership responsibility falls away. The leadership
work, and thus all the work on the system, is distributed among the team members.
This does not mean that everyone has to anticipate having to do leadership work, but
that different roles are performed situationally by different team members.
Leadership Characteristics in Project Management

Finally, we relate the forms of leadership described above to the tasks of the project
bodies described in Sect. 2.3.8.
With the signing of the project order the project manager takes over temporary
leadership, as well as the coaching and the management tasks for his project and the
team. The management task is carried out through controlling. It is the project
manager’s responsibility to identify and deal with all deviations from the initial
plan during project implementation. Every detected deviation has to result in an
action. The problem-solving process is suitable for developing and evaluating the
measures (Sect. 2.3.14).
The project manager needs to report to the project owner all deviations remaining
after the implemented measures that have an influence on the magic triangle (Sect. 2.
3.4), the project manager needs to report to the project owner. Through the reporting
the project owner, for his part, comes into the management function. The solution
alternatives evaluated via the problem-solving process also serve as a basis for
decision-making. The project owner focuses on the project manager with regard to
employee management and coaching. The project manager exercises his manage-
ment function vis-à-vis his sub-project managers and, to a lesser extent, also
vis-à-vis individual experts.
In agile project management, these characteristics are more clearly assigned to
their respective roles: The product owner, responsible for the content management of
the project, focuses on the management task. The scrum master takes over the
coaching. There is no actual employee management in the agile approach. This
happens through the self-organisation explained in Sect. 4.5.3.
4.4 Leadership Styles and Models
A leadership style is understood to be a relatively stable, situation-variant behavioural

pattern of the leader over the long term (Charles Lattmann).
Actual employee leadership is only applied in traditional project management. In an

agile project, the leadership task is performed collegially. In everyday leadership, the
leadership style is the way in which the leadership activities of planning, steering,
314 4 Leadership
integrative participative
directive delegative
Leadership styles
Formal leadership power decreases
Situative leadership model
Positive leadership
Self-organisation
Leadership without formal authority (lateral leadership)
Fig. 4.1 Different leadership styles
and controlling are carried out and the individual leadership processes are
influenced. A certain leadership style has the consequence that every leadership
situation is characterised by a uniform basic behaviour. On the other hand, leader-
ship always takes place in relationships. This means that the people involved in
leadership influence the respective characteristics of the leadership style with their
specific situation.
Basically, the success of a project is mainly measured by the benefits achieved for
the organisation. Is there a correct and more promising leadership style? Chapter 3
explains that every human being is characterised by a unique constellation of basic
needs and abilities. Organisations in which projects are carried out are also unique
and each has its own organisational culture. Therefore, there can be no right or
wrong when it comes to leadership styles. Rather, the optimal leadership style for
oneself and for the team needs to be found in order to achieve the project objectives.
The leadership style is also shaped by the personal style of the project manager. The
project order can influence the choice of leadership style. In the tension between
directive and delegative leadership, the project manager has to find the right mix to
bring the ability to act and make decisions into the project. Depending on the
situation, different leadership styles are suitable for this purpose, as shown in
Fig. 4.1.
4.4.1 Directive Versus Delegative Leadership Style
The leadership continuum developed by Tannenbaum and Schmidt as early as 1958

has found its widespread expression in leadership theory (Fig. 4.2). Between the two
poles of directive and delegative leadership, further characteristics are possible,
which result in different leadership styles. The leadership styles differ with regard
to the delegation of decision-making competences: In the participative or delegative
leadership style, these are partially or completely handed over to the employees. This
contrasts with the directive leadership style, in which the supervisor has all decision-
making authority.
This linear model is still useful today. In a crisis, for example, a directive style of
leadership can be deliberately applied. The emergency situation justifies quick
decisions and clear allocations of authority. Or at the other end of the scale, the
entire decision-making authority can be delegated to a project team to solve a
difficult problem.
4.4.2 Situational Leadership Model
In the situational leadership model, the leadership style is not only oriented towards
the current situation and the goals to be achieved. The main point of reference is the
integrative participative
directive delegative
Leadership styles
high low
Directive leadership
Sole decision of the manager
Delegative leadership
Delegated decisions to employees
low high
Manager allows the team to

• indentifiy the problem
• develop options
• to determine the course of action
within a given limit
Fig. 4.2 Directive and delegative leadership

316 4 Leadership
S3 support train S2
high
Participative Integrative
Seconding behavior – relationship orientation

leadership style leadership style
SU: Coach SU: Trainer
EM: Professional EM: Learner
Share ideas and Explain decisions
encourage to take and give the
decisions opportunity to ask
delegate S4 S1 direct
Delegative Directive
leadership style leadership style
SU: Partner SU: Instructor
EM: Expert EM: «Junior»
Hand over Exact instructions
responsibility and monitor
for decisions and performance
implementation
low
low Conducting behavior – task orientation high

SU: Superior high low
Maturity level of the employee
EM: Employee
Fig. 4.3 Situational leadership model (Based on Blanchard, 2015)
maturity of the person being led, made up of the product of performance (ability) and
the willingness to perform (desire), compare also Sect. 3.2. For this level of maturity
of the employee (EM) (see Fig. 4.3) a specify superior’s (SU) leadership style is
necessary to optimally match the employee’s needs: directive, integrating, participa-
tive and delegative.
A great advantage of this leadership model is that the manager can do justice to
the heterogeneity of the team. It is often the case that the personal maturity level in a
project team covers the entire range between very experienced experts to “juniors”.
In this situation, it is not helpful for the project manager to apply only one leadership
style. Rather, it is about finding the appropriate leadership style in the relationship
with the respective individuals.
• Directive leadership style S1: Instructing, directing, steering

– The supervisor gives precise instructions and conscientiously oversees the
performance of the task.
• Integrative leadership style S2: Training, convincing
– The supervisor continues to conscientiously direct and monitor the perfor-
mance of the task, but discusses the decisions with the employee, and asks for
suggestions, he also trains, instructs, and convinces the employee of the
necessity of the task.
• Participative leadership style S3: Advising, supporting
– The supervisor advises and supports the employee in finding solutions and
making decisions. Principle: Helping people to help themselves.
• Delegative leadership style S4: Delegating
– The supervisor delegates to the employee to a large extent the competence and
responsibility for the decisions to be made and the tasks to be solved.
4.4.3 Leadership Without Authority to Issue Directives
The term lateral leadership (Lat. Latus stands for “side”) has also become established
for leadership without authority to issue directives. This style of leadership is
predestined for project coordination because the “project manager” in this project
organisation has no authority to issue directives. Project managers need to therefore
be able to work effectively without institutional power. The essential starting point
for this, in leadership without authority to issue directives, is borrowed power (par.
4.9.4): It is a matter of achieving the best possible coordination with the decision-
makers in the line organisation. An essential success factor of leadership without
authority is the definition of framework conditions for the environment
(organisational framework), the project manager (personal framework), and the
team (team framework) (Radatz, 2009). The following questions need to be
worked out:
4.4.3.1 Organisational Framework

Clarifying the organisational framework ensures that the borrowed power from the
line organisation can have its best possible effect. The project manager must clarify
these points primarily with his project owner:
• What benefits does the organisation want to achieve from the team’s or the
project’s success?
• What are the taboos? Which topics are critical?
• What limits apply to the project work? At what point can the project be consid-
ered as having been completed?
• When and where does the project management have to coordinate, and with
whom, in order to prevent work going into blind alleys or going against the
will of the organisation?
• What human and financial resources are available? Where do the boundaries lie?
4.4.3.2 Personal Framework

Whoever assumes responsibility hast to, in order to protect the ability to act, also
determine which rules of cooperation are to be followed. In addition to this, every
lateral manager needs to also become aware of what goals and motives the team can
achieve in the fulfilment of this task:
318 4 Leadership
• What makes the task attractive in a personal way? Which extrinsic or intrinsic
motivational factors can be met and satisfied by this task? But also: What should
or is not to happen?
• What demands are made on the team? What does the manager need from the team
so that the task can be fulfilled well? How should the rules of cooperation be
defined?
Example
• What form does communication take?

• How are binding agreements made?
• What are the consequences of not meeting deadlines?
• How are absences and delays dealt with? ◄
4.4.3.3 Team Frame

Not only the customer, but also the line managers of the employees delegated to the
project play an essential role in lateral leadership by either lending or not lending
their power. In the sense of the power relations explained above, the project
employees will, in case of doubt, focus on the work that has priority for their line
manager.
Lateral managers who do not have the support of their direct line managers will
have a hard time achieving their goals. For this reason, Sonja Radatz recommends
holding a meeting with all superiors of the future project team in which the following
aspects should be clarified simultaneously:
• What benefits does each individual team leader derive from the targeted project
success (money, reputation, an important step on the career ladder, increase in
knowledge, etc.)?
• If no subjectively formulated benefit can be defined in the project for each
individual line manager, the chances of success for the lateral manager or their
project are very low. Without the concretised benefit, a line manager will, in case
of doubt, prioritise other activities in case of capacity bottlenecks.
• To what extent are there conflicts of objectives between the tasks that the future
project team members will have to perform within the framework of their line
function versus those that are to be aimed for in the project work?
• If line managers do not coordinate the goals and priorities of their employees
themselves, this results in a conflict which they delegate to the system. The
conflict thus manifests itself as a personal or social conflict.
• What time resources are the individual supervisors willing to release? Where are
there bottlenecks or limits that are already foreseeable?
• When the effort has been underestimated and does not match the resources
actually needed—how is this dealt with?
• In addition to this, the points negotiated with the project owner concerning the
boundaries and taboos have to be clarified once again in this committee.
4.4.3.4 Friction Points in Leadership Without Authority to Issue

Directives
If there is a lack of controlling or a poor selection of resources, there is often the
danger of individuals being overburdened or of role conflicts arising. The following
points should help to avoid this kind of friction:
• Work on the expectations of individual project roles early on and together in the
project team. This involves clarification and transparency of and regarding the
different expectations of the role sender on the role holder (Sect. 5.3.2), but also
the communication process within the team.
• Distinguish between roles performed by individuals and those performed by the
project team or parts of it (sub-project teams).
• Define roles on a project-specific basis, even if individuals repeatedly take on the
same project roles.
• Address role specifications (function description, job specifications) to the respec-
tive role holders and their deputies.
Example
Things that a role holder (e.g. project manager). . .
• must do: he must manage the project and lead the team
• should do: treat the team members equally
• can do: organise something together outside the project work
• should refrain from doing, e.g. because it is incompatible with his or
her role ◄
4.4.4 Positive Leadership in Projects
Based on positive psychology and the PERMA model by Martin Seligman (Sect. 5.
4.1), Ruth Seliger developed the leadership model of positive leadership. For
leadership to succeed, I must be able to lead myself. Only those who can lead
themselves are also able to lead other people. This is achieved by reflecting on one’s
own leadership behaviour, one’s own role, but also one’s values and goals.
In the management of people and projects, communication represents the central
management tool and the question arises: “How can I make communication come
across as positive and inspiring?” Systemic theory (Sect. 1.6) teaches us that living
systems are autonomous, relatively inaccessible from the outside and that decisions
are made internally, with the power of self-organisation. In humans, it is the inner
maps that control action.
320 4 Leadership
Involvement:
Focus on and appreciation for
Inclusion into decisions
strengths, resources and
Empowerment:
potentials
Hand over responsibility
Confidence Influence
Principles
Meaning
Past: Motifs
Present: Big picture
Future: Vision
Fig. 4.4 Principles of “positive leadership” (Seliger, 2014)
If the project manager’s task is to induce a certain behaviour in the project

employees, how can he do this if they are internally controlled? The solution lies
in a systemic understanding of communication and interaction:
• We construct our individual world views, our “inner maps”.

• At the same time, our maps are also the “engine” that controls our actions.
• Whatever people do, they do it on the basis of their inner images and assessments,
not on the basis of external reality.
By shaping communication in a positive way, the project manager can exert

influence:
• By creating a positive communication climate, exerting influence by asking

questions and using feedback as a source of energy, the project manager can
positively influence direct communication.
• The project manager can conduct meetings productively and thereby positively
influence organised communication.
• In addition to this, it is also important to make clever use of informal networks.
At the heart of positive leadership are the three principles: confidence, influence, and
meaning. These act as elements for shaping a positive organisational energy (Fig. 4.4).
Energy is generated among project team members when their own activity is
considered meaningful (Sect. 3.7). The better the project manager succeeds in
making the project activity meaningful for the project team, the more will the
employees commit themselves to the project and get involved. As soon as the project
team can fully utilise and experience its strengths, resources, and potential, this then
creates positive energy in the project. The positive energy in the project can be
further increased by involving the project staff in the decision-making process and
handing over responsibility, both in terms of content and in terms of emotion. This
also builds a trusting environment.
The principles serve to generate high positive organisational energy. High energy
is central to the success of a project; i.e. the project manager has the task of
ensuring that:
• The project builds up enough energy and can mobilise it again and again.
• The project energy flows in a good way and there is enough of it, so that all parts
and all environments of the project are energetically well supplied, that there are
no congestions or energy holes.
• The available energy is also used effectively and does not go to waste.
The professional mastery of leadership tools and the creation of role clarity form
further important foundations in the positive leadership model.
4.4.5 Tips for Remote Leadership
The project team working together in one room has many advantages. After all,
questions or problems can be solved promptly and without complications over a
coffee in a direct conversation. Due to the pandemic, working together at a distance
via home office was inevitable. Regardless of the preferred leadership style, the
following rules should be observed when collaborating in this way:
• Frequent contacts: Daily conversation with each project member, without neces-
sarily having a specific agenda.
• Clarify questions in a consultation hour: Set up question time for project
employees.
• Create stability through rituals: Morning check-in; opening sessions with feel-
good rounds.
• Increase security through clear boundaries: Set rules for availability and
absence.
• Problems, not just solutions: Encourage your team to come up with problems
even if they don’t have solutions yet.
• Build capacity through feedback: Proactive feedback every day, for good (not just
great) work.
• In difficult situations: Praise efforts, not results.
322 4 Leadership
4.5 Self-organisation, Specific Characteristics in the Agile

Project
How does self-organisation work? Which specific characteristics or methods should

or can be taken into account when taking on the roles of product owner, scrum
master , and developer?
4.5.1 Principles and Requirements for Self-organisation
Agile project management was developed for projects that are complex, full of
surprises and uncertainties and that have to serve moving objectives. Accordingly,
not only the approach but also the project organisation has to be flexible, agile, and
innovative. Therefore, in agile organisations, leadership is no longer bound to just
one person, rather, it is seen as distributed leadership. For the product owner,
leadership primarily means setting the content framework and shaping contexts so
that teams can work optimally. The scrum master focuses on serving the scrum team
so that it may be able to lead itself optimally.
The scrum team “leads” itself through self-organisation or self-direction: This
happens either distributed, according to the situation, or from the different roles. For
self-organisation to work, there needs to be a limited instability between stable
equilibrium and chaos. Due to the increased complexity, the system to be worked
on enters a critical state. This critical state and the limited instability are important
prerequisites if self-organisation is to succeed, otherwise the organisation and the
system will remain in the previous state.
4.5.2 What Does Self-organised and Agile Working Mean?
Agile working means experimenting, iterating, continuously improving and

learning, actively involving stakeholders and taking responsibility. It is important
to develop an agile mindset. A purely mechanical application of an agile framework
like scrum does not work in practice and is doomed to fail. According to the agile
manifesto (https://agilemanifesto.org/) and derived from practical experience, the
following points are central to the development of an agile mindset:
• Interaction between individuals is more important than strict adherence to pro-

cesses and tools. This is achieved by team members talking to each other and
continuously exchanging ideas. Collective intelligence beats individual
performance.
• Reacting to changes is more important than rigid adherence to a plan. A culture of
openness to change must be developed within the team.
• Shared learning with customers is part of the approach. A culture of continuous
improvement and learning should be developed in the team. Openness to criticism
4.5 Self-organisation, Specific Characteristics in the Agile Project 323
and feedback helps, and it is easier if mistakes are understood as learning

opportunities. Intelligent failure is to be encouraged here (Sect. 5.4.1).
• The customer benefit (Sect. 2.8.2.6) is the focus.
• Experimentation helps the team to find out what works and what does not. This
succeeds when a pragmatic approach is taken and perfection is not a precondition
from the start.
• Through a kanban board (Sect. 2.5.2) and regular stand-up meetings (Sect. 2.5.3),
a team creates transparency for itself and the stakeholders about what is being
worked on and what the progress of the work looks like.
These principles are based on values such as openness, commitment, focus,

courage, willingness to take responsibility (for commitment, productivity, effi-
ciency, and health), and mutual respect. It is also interesting to ask oneself what
interests and qualities lie behind these values for oneself and for the team. Only if the
scrum team succeeds in developing these principles and values into an agile mindset
will the agile approach have a chance of success.
In the process of self-organisation, constructive and sustainable communication
between the team members is needed. The shaping of relationships among these and
their communication is more important than the organisational structure in the team.
The performance of a team is not the sum of the individual performances. The
performance of the team essentially depends on how well it succeeds in shaping the
interaction between the team members. Self-organisation does not mean fewer
structures than in a traditional project organisation. New structures are created by
the team itself and no longer imposed from the outside.
4.5.3 How Does Self-direction and Leadership Work

in Self-organisation?
Teamwork needs leadership. In self-organised teams, leadership is collegial (Sect.

4.2). Collegial leadership is distributed, situational, and temporary. Depending on
skills and temperament, some team members are experts in brainstorming, others at
“doing things”, while yet others have a sensorium for social processes, and so
on. The team has to deal with these different preferences. As a result, the work to
be done is pulled by the individual team members and no longer pushed by the
project manager.
Example
It makes sense for one person with the appropriate skills and interests to take over
the facilitation process, another to organise the infrastructure, someone else to pay
attention to quality, and yet another team member to keep an eye on team
cohesion and address latent conflicts, and so on. It is important to talk about
these leadership or team roles, to organise and reflect on them. In this way, it can
be avoided that the roles get monopolised by one influential person or, con-
versely, that a leadership vacuum is created. ◄
324 4 Leadership
The advantages of collegial leadership are: Rapid adaptation to change, strong

commitment, and sustained high levels of identification and motivation. This leads
to a correspondingly high level of performance. Leadership here simply means that
roles previously embodied by a manager are now seen as distributed. This means that
someone takes the lead in an area in which they have special skills or knowledge.
" A possible aid to suitable staffing is offered by the Belbin team roles
(Sect. 5.3). This model describes which team roles are filled and how. The
Belbin team report shows any deficits in the team and enables them to
be compensated. In the process, the different experiences of a profes-
sional and methodological nature must also be addressed. In short: A
team’s management potential lies in dealing with diversity.
Of course, over time, one-sided hierarchical patterns can emerge which diminish
the diversity of a team. This happens especially in teams that work on projects
remaining the same in composition over and over again. If team members withhold
important information, diversity also suffers. Such rigidities can only be done away
through self-reflection. The primary platform for this is the sprint retrospective
moderated by the scrum master. Here, the cooperation in the team gets critically
reflected.
Self-organised teams are not feel-good oases. They expect their members to
perform as agreed. External control is replaced by self-control. In agile project
management, the project team itself becomes the entrepreneur. This “grassroots
entrepreneurship” means that there is more commitment and responsibility for all
people involved. And because the pressure of time and expectations is high due to
the short sprint intervals, individual team members may well get into stressful
situations, be criticised by the team, or even excluded.
4.5.4 Decide on Procedures and Solutions in Their Own

Competence
In traditional project management, project teams develop proposed solutions and

submit them to the project owner or the project committee for a decision. However,
self-direction is only successful if the teams can decide on the solution themselves
within a defined framework. This can be, for example, the development of an internal
process that the team members then later have to “live” themselves. Or it may be a
product development that the team offers to the internal or external customer without
obtaining the approval of the internal management. This happens before a back-
ground of the team members having at least as much knowledge in their specific field
as their management. If the knowledge in the team is deemed insufficient, the team
can also seek the support of the scrum master or that of other experts at any time. By
being customer-oriented instead of boss-oriented, the team experiences a
corresponding appreciation, is motivated, and takes on full responsibility. And yet
4.5 Self-organisation, Specific Characteristics in the Agile Project 325
the team should not only be able to decide on solutions, but also on the procedure
and the choice of methods. It is important to clarify the framework conditions within
which self-organised work is to take place. This provides orientation and defines
creative freedom:
• Content: What is the vision, the goal, the object of the project and what is it not? Is
this vision meaningful? What is the purpose to be pursued?
• Processual: What are the rules of the game, what is to be observed, and what is
prohibited? (Prohibitions can very well define the free space, because everything
else is permitted) What is still to be preceded by superordinate instances or
guidelines? How is the project team’s scope for decision-making and action
defined?
4.5.5 Important Factors for Self-organisation to Succeed and Be

Effective
Especially in agile project management, trust (Sect. 3.3.5) is a prerequisite without

which a self-organised team cannot work properly. It is advantageous if it is possible
to create an atmosphere of psychological safety (Sect. 5.4.1), in which trust is a
central aspect. The management grants the team an advance of trust by delegating
decision-making competences. And this advance trust is, according to previous
experience, much less likely to be abused than pseudo-trust in a climate of “trust is
good, control is better”. On the contrary: the advance of trust is perceived as an
appreciation and and is rewarded with the corresponding commitment.
It is not very interesting for teams to work on projects where the aim is to work
out and implement a predefined solution. They are committed to “their” solution.
Self-organised teams need creative freedom and need to be able to work and decide
for themselves. Thus, projects or project phases with open problems crystallise,
which are mastered with creativity.
Example
Product development, business process development, change projects, and post-

merger integration are predestined for self-organisation. They are projects in the
potential and pioneer area (Sect. 1.2.1). The focus should be on business value
(values, benefits of the product) rather than on detailed requirements. ◄
Projects that are handled by self-organised teams have to have a certain size or
resource requirement. Such projects have to be able to be completed in a
concentrated manner within a short period of time in such a way that they do not
fail. A project team that is integrated into the line organisation through coordination
(Sect. 2.3.8.8) does not meet these requirements.
Teams must constantly work on their agile mindset with its principles and values
(Sect. 2.3.8.4). This is not a one-off task. It is advisable to question the applied
principles and lived values and to look for constant improvements. This leads to
constructive and inspiring relationships between team members.
326 4 Leadership
Leadership behaviour in the self-organised team must also be questioned regu-

larly. How well does collegial leadership work? Is there clarity regarding roles,
structures, and the methods to be used?
Human behaviour is very much shaped by context. This is also the case with the
behaviour of and within project teams. If the project object is relevant and meaning-
ful to the team members, if they have autonomy, responsibility, as well as scope for
decision-making, and if a result is expected, teams develop a quality of cooperation
that surpasses that of “traditional” project teams. At least that is what previous
experience clearly shows.
Members of self-organised teams have to have specific skills (Fig. 3.1), master
moderation techniques, problem-solving and decision-making methods and be able
to communicate well. Developing these and other self- and social competences
(e.g. giving feedback, conflict management) helps to make cooperation in agile
teams more successful. Team members should develop good sensors to be able to
perceive even non-verbal signals. The better this succeeds, the greater the mutual
empathy will be. Empathy increases team cohesion.
It can also happen that a team gets into difficulties. In this case, it is important that
the team is able to develop a process to consciously identify and address the
dynamics of tension. In holacratic organisations, tensions are addressed in a
standardised process. If the team cannot manage the conflict itself, situational
interventions such as group process analyses or conflict management with the help
of the scrum master or even an outside coach are necessary. These interventions
make valuable learning processes possible.
Furthermore, the team should deal with the use of power. Power can be a resource
and a potential for conflict at the same time. Talents, abilities, motives, or interests
are present in every team member and can be used consciously or unconsciously as
instruments of power to influence and shape the team.
Transparency is a prerequisite in any self-organisation, be it in project teams or in
permanent organisations. Transparency promotes trust and prevents unpleasant
surprises. Transparency is achieved through networking, because this also means
that a self-organised team is obliged to exchange information about its activities,
interim results, questions, etc., with the relevant environment (project owner, project
committee, customer). Transparency also exists within the team, e.g. in the disclo-
sure of all important information, in the visualisation of progress, in the naming of
problems or through honest feedback.
Create an arc of tension. The scrum approach shows how it is done: firmly
scheduled “sprints” or iterations with agreed results. In general terms, this means
building up an expectation. Tight scheduling creates one or more arcs of tension. At
the end of this arc, a meeting is planned at which the results or interim results are
presented to a relevant public for discussion. Depending on the project, different
iterations make sense. For example, in a change project, change iterations take about
2 months, in a product development project a few weeks, similar to scrum. Such
cycles, within which work can be concentrated, keep the tension and energy high and
enable permanent feedback and learning loops (Gellert & Nowak, 2007).
4.6 Leading with Goals 327
With all these points, the overall process needs to always be kept in mind. Are the
competences of the team members used optimally? Who goes into the lead with which
topics and when? Are concrete results being delivered for the client or is the team
preoccupied with itself? What about the performance of the team? In order to keep an
eye on the overall process, it is important to create a space for learning in order to
reflect on the issues that have been identified and to look for ways to improve.
4.6 Leading with Goals
Depending on the corporate and management culture, the operational implementa-

tion of projects is structured differently. A widespread technique is management by
objectives. Leading projects also means achieving goals. Within project implemen-
tation, milestones form intermediate goals that have to be achieved. This technique is
just as suitable in project work. It is also used within the participative and delegative
leadership styles explained above.
4.6.1 Management by Objectives MbO
With the basic attitude of delegating tasks, competence, and responsibility to

employees, the MbO technique provides the substantive framework for setting the
goals to be achieved. Traditionally, this process takes place annually or semi-
annually or when joining the project team. The following aspects are at the forefront
of leadership by objectives:
• Leading through goals (WHAT) and not through solution strategies (HOW)
• Company or project objectives must be broken down along the vertical
organisational structure
• Task performance process (TCR) based on:
– Division of tasks
– Delegation of decision-making and directive authorisation with the associated
responsibility
Leading by objectives offers significant advantages:
• MbO promotes performance motivation, initiative, and a sense of responsibility

• MbO allows delegating tasks and content-related decisions to the technical
experts, who are better qualified in the area of their expertise than the project
manager, who is more of a generalist
• MbO creates freedom in project work for situationally optimal solutions
• MbO involves the people concerned, it promotes and also makes demands
• MbO allows the participants to grow with the tasks and expand their qualifications
• MbO leads to operational relief for leaders
• With MbO, higher-level goals become personal goals
328 4 Leadership
Table 4.2 Differences between target setting and target agreement

Target setting Target agreement
Directive Participative
Sales culture Negotiation culture
Based on acceptance Based on commitment and identification
Boss-driven Boss- and employee-driven
Short-lasting and fast Longer time process
Normal demands on supervisors High demands on superiors
Often win–lose situation More of a win–win situation
Often demotivating Motivating
A key factor in whether MbO can be successful or not is the basic understanding
of MbO. Are mutual expectations negotiated in the sense of a target agreement and
agreed upon if there is mutual agreement? Or are the objectives ordered “top-down”
by the hierarchical levels as targets without taking into account the opinions and
needs of the recipient? Table 4.2 makes the differences clear.
Management by agreement on objectives is of course more time-consuming and
requires good negotiating skills of both sides. But only through a process of
agreement will it be possible to achieve a really high level of commitment and
thus also a high level of motivation and commitment on the part of the people who
are to take on the tasks.
4.6.2 Leading by Objectives and Key Results (Management by OKR)
With the shortening of planning and action times, the previous MbO management
concept now often gets replaced by the OKR approach. This management model,
which is based on objectives and key results, in its basic ideas comes from the MbO
approach and combines today’s working conditions much better (Table 4.3). It takes
into account the digital transformation and the different demands made by today’s
generations (Sect. 3.4.3). A cycle in the OKR process takes 3 months. The goals are
developed together with the employee in a top-down and bottom-up process. During
the implementation phase, a weekly OKR, OKR review, and OKR retrospective is
conducted, similar to agile project management. Essential prerequisites for a func-
tioning OKR are listed in Table 4.3:
The OKR leadership approach fits much better today, this is true in many places
in the normal leadership environment as well as in the traditional and agile project
environment, as it meets today’s circumstances and demands. In rapidly changing
markets and environments, it fits to leading in an agile way. The short leadership
cycles create a maximum of flexibility. Only tasks that are result-oriented are
tackled, which bundles strengths and resources. However, it is important to ensure
that the key results are formulated in a comprehensible and measurable way and that
they comply with the SMART rule (Sect. 2.3.2.4). Similar to the agile project
approach, the result ultimately also depends on how well the cyclical, qualitative
method work steps are carried out. In order for these to become routine, someone
from within the company may also help here as an OKR master.
4.6 Leading with Goals 329
Table 4.3 Prerequisites for a functioning OKR

Aspects Description
Openness Willingness of employees to leave their own comfort zone and take
personal responsibility and to keep working towards ambitious goals.
As a whole company, to orient itself in a high degree of agility and
goal-oriented work.
Transparency The goals of all departments are always disclosed and communicated.
This should be perceived positively and not as pressure, control, or
monitoring.
Not an employee Objectives and results are set very ambitiously. Maximum performance
appraisal tool is aimed for. However, if these cannot be achieved, there are no
sanctions. It is considered a success if 70–80% of the targets get
achieved. In this way, the teams identify with the goals, knowing that
collaboration and not individual performance is necessary to achieve
the goals. If this is not maintained, there is danger of manipulation or of
glossing over the results to promote one’s own success. See also radical
collaboration (Sect. 5.4.4).
Example
Within the framework of a project, market clarifications are planned at various

levels. This task and the corresponding responsibility are implemented differently
in the two different management approaches MbO and OKR. ◄
MbO: leading with goals OKR: leading with goals and key results
The project manager’s annual or biannual In the particular cycle of the OKR process, the
performance mandate lists this task as part of key results are defined.
the overall project.
The project management ensures that the The market research sub-project team helps to
necessary market clarifications and forecasts develop a market analysis over the next
are available by the end of the concept phase. 3 months, conducting:
1. An analysis of the competitors
2. A market analysis of the possible sales
channels
3. Forecasts of possible market
developments
4. Proposals for further action.
330 4 Leadership
4.7 Delegation
Delegation is a big challenge for many project managers. Most of the time, they
qualify for a project role through good work as subject matter experts in the line
organisation. With project management, sub-project management, as scrum master,
product owner, or in the project team, they take on new roles. This involves taking
on many new tasks and responsibilities. In order for these project roles to be fulfilled
at all, those concerned need to free up capacities. The principle of delegation is
helpful for this, whether in terms of line or project tasks. In operational, agile project
management, delegation plays no role, as the team is self-organised and decides very
dynamically who does what and when.
4.7.1 Decision-Making Process in the Delegation
How can delegation be made concrete and as sustainable as possible? Figure 4.5
shows the decision-making process as to whether and how a task is suited for being
delegated. First check whether the task is really necessary for the organisation or the
project. For this clarification, the time management matrix in Sect. 3.8.3 is helpful.
Unnecessary tasks should be eliminated. For the remaining tasks, one tries to find a
I choose
a task and no
… is it necessary? eliminate
ask myself…
yes
… Am I only able to no delegate accor-
fulfill her? ding to checklist
yes
… warum?
not transferable too little available is a management task
why? • Check utilisation • Can the work

• Check deployment be simplified?
planning • Can it be done
He knows or He wants or • Looking for employ- later?
can not now he may not ment for temporary
job
• form • to advise • Loan person
• accompany • explain • New person to adjust
• instruct • clarify hierarchy
Fig. 4.5 Decision-making process in delegation

4.7 Delegation 331
person with the necessary skills. If there is a person who is ready, willing, and able to
do the work, the task can be delegated according to the checklist in Table 4.4.
If at the moment only I can do the job myself, I have to ask:
Is the task non-transferable because. . .
• there is no one who has the relevant knowledge or skills? If there is not, such a
person has to be built up.
• the competences are available, but the person in question cannot take on the
assignment? Then the reasons have to be determined, and the appropriate
resource need to be released via the hierarchy.
If there are too few resources available, check the workload and the assignment
planning. The delegating person hast to look for additional resources. In such
situations, simplify the tasks or fix them for a later date. Specific leadership tasks
cannot be delegated.
4.7.2 Delegation as a Recurring Process in Project Management
In the traditional approach, the project manager must constantly ask himself which
tasks he is going to carry out himself and which of these he intends to delegate to
other people. By definition, he should work on the system and not in the system.
Table 4.4 Checklist for delegation

Focus Description
WHAT • What is the desired outcome?
System objectives • Which subtasks are to be completed in detail?
• What difficulties are to be expected?
WHO • Who is suited to carry out this task or activity?
People and hierarchy levels • Is the person available?
• Who should be involved in the execution?
WHY • What purpose does the task or activity serve?
Purpose, motivation • What happens if the task is not carried out?
WITH WHAT • What must the employee be equipped or
Means, resources authorised with?
• Which documents are required?
WHEN • When must the work be completed?
Deadlines • Which intermediate deadlines have to be met?
RESPONSIBILITY of the delegating • To what extent do I remain part of the solution?
person • What responsibility remains with me towards whom?
• When do I have to check what in order to intervene if
necessary?
Possibly: HOW • How to proceed with the execution?
Process objectives • Which regulations and guidelines must be observed?
• Which positions, departments are to be informed?
332 4 Leadership
Successful delegation first requires the ability to meaningfully delineate tasks

thus separating them from one another. Then these have to be communicated in a
comprehensible way and the different task fields have to then be coordinated.
Finally, the results achieved need to be integrated in an all-encompassing way.
The fact that the recipient of a commission then chooses his own methods of
performing tasks is the risk of that delegation. The employee needs to know the
original strategies in order to deliver what is expected in the overall context.
Delegation is impossible without trust. Those who do not trust their employees
tend to control them, thus becoming micro-managers (Sect. 3.3.5). Simply just
starting a delegation process is more time-consuming as well as riskier than doing
the task yourself. In the medium and long term, however, it is the only way of
developing the team as a whole while keeping its own resources available for the
important tasks. Useful virtues in this process are openness, tolerance, and the
calmness that tasks can be accomplished in ways other than expected.
Example
There are many arguments in favour of delegation, especially in project

management:
• Relieving the burden on those responsible for the project, i.e. more time for the
essential tasks and responsibilities of the respective roles.
• Based on the understanding of their role, the team members have to be more
competent in their field than a project manager.
• Decisions can be prepared and made by professionals where the consequences
are going to have an immediate impact.
• Delegation often opens up the freedom necessary for creativity in the search
for solutions in project work.
• Delegation also means involving the employees. They are challenged and thus
encouraged. By taking on responsibility, the qualification-levels of the
contractors increase. ◄
Qualified employees usually want to be able to use and show their potential. With
the delegation principle, the delegating person emphasises trust in the employees and
at the same time reinforces their independence and ability to act. In addition to these
arguments in favour of the delegation principle, the dangers should be mentioned. It
seems important in this context that the delegating person is concerned that:
• The “right” employees are deployed, i.e. the risk of over- and under-employment
is clarified before employees are scheduled into the project.
• The employees are fully informed, i.e. that they have understood not only the goal
and purpose but also the context.
• Execution and results are monitored systematically and according to plan (status
reports, milestones).
4.8 Task, Competence, Responsibility (TCR) 333
• With the delegation of work tasks, the corresponding competences are granted
and responsibility is transferred (Sect. 4.8).
4.8 Task, Competence, Responsibility (TCR)
The considerations on the subject of power are summarised in the congruence principle
of tasks, authorities, and responsibilities (TCR): Each project body has to also be able
to assume the corresponding responsibility for the tasks that are assigned to it. This is
usually not the problem; the project managers are very aware of their responsibility.
The tricky point lies in the lack of competence, which empowers the project managers
to make decisions themselves and to issue instructions to others (Fig. 4.6).
The design of the area of competence connected to the respective project roles is
an essential factor for the success of the project. No matter how well projects are
managed operationally, if the project organisation does not have the competence for
its tasks and goals, it will not be able to work successfully.
In traditional project management, the power system between the project owner,
project management, and line managers needs to be balanced: The project owner has
to be sufficiently “powerful” in the line organisation to be able to provide the project
manager with the budget and the resources effectively required. The project man-
ager needs a clear project order from the project owner, in which he also clarifies his
Formulate a task
Responsibility and competence
are always task related
Grant competence Transfer responsibility

Authorisation By taking over a task I take over
and freedom of action the commitment, on deliver a result
enable the task to be accomplished
Tasks
If there is no congruence
Competence between the 3 dimensions,
conflicts are likely
Responsibility
Fig. 4.6 The congruence principle TCR

334 4 Leadership
goals, responsibilities, and competencies, among these his competence to issue

directives to the project team. In project coordination and in the matrix organisation,
coordination with line managers is also essential.
In the agile approach, power is shared between the product owner and the
scrum team: The product owner leads the project in terms of content. To do this,
he needs the decision-making authority to okay the team’s sprint results. If this is not
the case—which happens again and again in practice—because he has to consult
with other decision-makers and bodies, the process becomes ineffective. The product
owner is trapped in a task with responsibilities for which he has no competence. The
scrum team itself is empowered in the sense that it can decide independently how
many requirements are to be implemented during a sprint and that it is able to and
needs to organise itself.
To put it provocatively, product owners and project managers without compe-
tence to issue directives and make decisions are “lame ducks”: they have many tasks
and responsibilities, but no competence. To some extent, this can be compensated
for by personal power.
4.9 Power and Authority
4.9.1 Empowerment and Seizure: Power Is Based on Relationship
Man is fundamentally a self-controlled, “non-trivial system”. His feeling, thinking,

and acting are always the result of inner, very complex processes. Whenever a
person’s actions or attitudes do not correspond to his natural, inner development
and he perhaps acts against his own inclination or despite of his intentions, the
phenomenon of power is behind this (Zirkler, 2008, p. 383). Power is neither good
nor bad. Power is a basic prerequisite for achieving common goals. Several
definitions are also used in relation to power:
Power is the ability to cause or influence organisational outcomes (Spisak & Della Picca,
2017).
Power is the ability of individuals or groups to influence the behaviour of other individuals
and groups in their favour. Abuse of power disempowers other people. Good use of power
empowers other people (Beat Hänni & Felix Marti).
Power always and only takes place in relationships. In order for a person to do
something that others demand of him, he has to give up his natural predisposition for
self-direction. If an unknown person suddenly appears at the workplace and demands a
report on the current status of the project, this is hardly likely to happen. It would first be
asked who this person is and what legitimises him to access this information. However,
if the same request comes from the supervisor, it is promptly complied with. A person
who fulfils an expectation from someone else has to always first authorise that other
person to influence personal behaviour. In leadership tasks, however, seizure of power is
4.9 Power and Authority 335
needed in addition to empowerment. The project manager or product owner has to also
demand and exercise the power that their roles require of them.
In the above definition, leadership is an interplay between assuming responsibil-
ity and exercising creative power. The leader has to take responsibility for the
common goals and also take ownership of the leadership task (e.g. as project
manager). However, a project manager only becomes effective when he is given
the power to make decisions having to do with the project order, organisation,
structure, and methods. In order to be able to do this, all persons and bodies involved
in the project need to empower the project manager in his role. The project owner has
to give the project manager decision-making authority in the substantive issues, but
also in relation to the relationship and organisational level. The individual team
members are to align themselves with the common goal and thus consciously
subordinate their own will and personal convictions to the group goals.
Power is always based on the interplay between empowerment and seizure of
power. The self-determined person is in a relationship with other persons through
communication, he is someone who can formulate expectations, instructions, or
demands. Ultimately, however, it is still the person to whom these demands are
communicated, who is to actively assign this power to configure his own actions
towards another person. In one sense or another, leadership always requires the
empowerment of a person who assumes the leading function and the empowerment
of the person on whom this power is exerted.
Agile project management also needs an intact power system. If the product
owner is not authorised by the customer to make decisions on the content of the
sprint reviews, he cannot fulfil his task. The product owner is to then empower
himself by actually making the decisions instead of delegating the decision to
someone else in cases of uncertainty. And the scrum master also needs empower-
ment for his role: the team has to empower him to deal with disturbances or to take
over the moderation of the sprint retrospective. The line organisation needs to
empower the scrum master to quickly deal with all resistance and difficulties that
hinder the team in its work. Exciting and also challenging is the game between
empowerment and seizure of power in the team itself. There are no clear-cut
assignments here. Rather, it is a matter of constantly re-establishing the balance
between the two poles.
4.9.2 Traditional Sources of Power
When the word power is mentioned, many people think of authoritarian power. This
has a correspondingly negative connotation. In Table 4.5, the traditional sources of
power listed here were originally developed by French and Raven (1959) and are
still valid (Spisak & Della Picca, 2017, p. 156 f.)
Positional power, power through reward and punishment as well as informational
power are largely assigned to a person by the organisation (hierarchy) within the
framework of the position he holds. The term “institutional power” is used for this.
A head of department can decide on appointments, and he can at least have a say in
336 4 Leadership
Table 4.5 Traditional sources of power

Power Based on. . .
Legitimate power, positional power • Position or function in the organisation
• Employment contract, project order
Power through reward Ability to give other people something. . .
• To give them what they desire, or
• To take away what they do not desire
Power through punishment Ability to help other people. . .
• Withholding rewards
• Imposing sanctions
Information power • Information advantage over others
• Membership in governing bodies
Power through identification, role model • Attractive personality traits or resources of a person
• Sense of connection and loyalty
Knowledge and expertise • Qualification and expertise in a specific area
• Diplomas, (project management) certifications
wages and bonuses or, through his professional authority, issue directives. He also
decides who gets to take on the more attractive projects and who is likely to do the
hard work. Project officers often do not have access to this power in their informal
leadership role. This is why the role of the project owner is so important in traditional
project management. As the representative of the line hierarchy, he has access to
these sources of power. If the project owner makes these or parts of them available to
the project manager, power is conferred that is based on borrowed power.
This is not the case with power through identification and example. Rather, it
belongs to the individual himself as personal power. A role model is someone who
does what he says (“walk the talk”). Expertise includes interest and continuous
training in the relevant field.
4.9.3 Other Sources of Power in Project Management
In organisations there are other sources of power which are essential for project
organisations (Table 4.6). The better project managers or product owners are able to
tap into these, the more effective they will be in their roles.
Several of these sources of power originate in institutional power: Disposition of
resources, decision-making competences, interface management, and disposition of
technology are to a significant extent linked to the position a person occupies in the
hierarchy. The informal networks and the handling of complexity and uncertainty
are achievements of the individual himself.
Table 4.6 Sources of power in project management (derived from Spisak & Della Picca, 2017,
p. 158 f)
Power Based on. . .
Disposition of resources • Professional authority and direct subordinations
• Budget capabilities
Decision-making power • Position and project role (also in connection with task, authority,
responsibility or RACI)
• Linking the project to the line organisation (in project
coordination these competences remain with the line managers)
Interface management • Authority to issue directives beyond a business unit
• E.g. a sales manager representing a customer’s claim
Disposition of technology • Mastering key technologies such as information—and
communication technology (ICT) in the age of digitalisation
Alliances and informal • Informal relationship building, participation in social events
networks • Networking in social media such as Xing or LinkedIn
Dealing with complexity • Personal resilience
and uncertainties • Self-management, self-reflection skills
Borrowed power • Power delegated by customers and line managers to those
responsible for the project
4.9.4 Projects Always Need Borrowed Power
In the area of personal power, project managers themselves are responsible for
accessing and maintaining these sources of power. In order to achieve results in
organisations, project officers always need access to institutional sources of power.
Therefore, in project work, borrowed power has a special role. Those who have
access to power, whether institutional or personal, can also lend it to others. And this
is the crux of many project managers: in their position in the line organisation (Sect.
5.3.1), they often have little access to institutional power. Whether traditional or
agile, project organisations as a whole and the individual project managers in
particular can only be successful if they are lent power and that includes the
associated authorities from the line organisation. The difference in the two
approaches lies in who receives what kind of power.
The traditional project organisation provides power to be shared between the
project manager and the project owner. The project owner is ideally the representa-
tive of the line hierarchy. With his positional power and the associated decision-
making power, he is the power bearer in the project organisation. The latter
empowers the project manager for the tasks in relation to his process competence.
Practice shows that especially in project coordination (Sect. 2.3.8.8), line
managers hold the principal position of power in the project, which not only reduces
project management to a coordination task. It is also often the case that the project
owner has no authority to issue instructions to the line managers who then make
decisions concerning the release of resources in the project. These specific frame-
work conditions in project coordination are best met by the principles of leadership
338 4 Leadership
without authority to issue directives (Sect. 4.4.3) are best suited to these specific
conditions in project coordination.
In the matrix project organisation, decision-making powers are assigned to the
project manager within the framework of his professional management responsibil-
ity. A project manager experiences the strongest empowerment in the pure project
organisation.
Without the delegation of decision-making power to the project organisation,
agile project management in principlecannot function. Only with far-reaching deci-
sion-making power the product owner can perform his control task at the content
level. The self-organisation of the team can also only work if the decisions regarding
the requirements that are implemented in a sprint can be made autonomously.
Borrowed Power Is Based on Trust

Borrowed power, however, still has an all too human Achilles’ heel. What about you?
Do you always generously confer the personal or institutional power at your disposal
onto others? Do you openly and unreservedly share your expertise and knowledge in
your field? Do you delegate decision-making authority and budgetary responsibility
just like that? Probably not, because you know that by doing so you may lose your
influence or have to answer for someone else’s mistakes. You will only lend power to
another person if you have sufficient trust in that person (Sect. 3.3.5).
4.9.5 Sources of Power: Between Person and Institution
Figure 4.7 summarises the relevant sources of power of project managers and relates
them to their background. Role model function, alliances and networks or expertise
are possessed by and part of the individual himself. To a large extent, each person
can cultivate and develop the power derived from this acting on his own responsi-
bility. Reward or punishment or the power of disposal over resources, however, is to
a large extent dependent on the empowerment of the institution and thus on the
position of a person in the organisational hierarchy. Located in the middle of the two
polarities of “person” and “institution” one finds decision-making powers such as
those over technology or interface management. Borrowed power also lies between
the person and the institution.
4.9.6 Authority
Where there is natural authority there is no need for a show of power (Hannah Arendt).
According to the publicist and philosopher Hannah Arendt, the difference between
power and authority is that authority is granted to a person because of his or her
personal characteristics or role in the organisation. However, authority is only
granted as long as it is respected without question.
Personal Institutional
• Role model • Technology • Position

• Alliance and • Decision • Reward and
informal competence punishment
networks • Interface- • Information
• Dealing with Management • Have resources
Complexity and • Lent power
uncertainty
• Knowledge and
expertise
Empowerment
Authorisation
Fig. 4.7 Sources of power in the project
Authority is described as the basis for a leader’s steadfastness and power to

influence (Spisak & Della Picca, 2017, p. 9). According to this description, authority
lies in three possible influencing factors, namely:
• Personal authority
• Professional authority (expert authority)
• Formal authority (authority based on hierarchy)
Authority, taking into account what has been said about power, is therefore a
consequence of power. Those who have access to the personal and institutional
sources of power as described above also rely on at least one of these three
influencing factors of authority.
Example
It is also possible that managers have access to the sources of power listed above
but are not respected in their roles due to their personal behaviour. Thus, they are
not acknowledged as having authority. ◄
340 4 Leadership
4.10 Negotiation
4.10.1 Negotiations in Project Management
Working in a project with its innovation mandate, goal orientation, and interdisciplin-
ary cooperation for a limited period of time leads to certain natural consequences:
a.o. different interests, requirements, convictions or intentions have to be permanently
coordinated. And all this has to happen within the framework of the magic triangle,
which is made up of the influencing factors “scope”, “time”, and “costs” (Sect. 2.3.4).
At the beginning of a project, one of the essential tasks of the project manager or
product owner is to negotiate a project order that sets up “scope”, “time”, and “costs”
in a realistic relationship to each other. Negotiations are also repeatedly necessary
during project implementation, whether in change request management (Sect. 2.5.8),
in the problem-solving process (Sect. 2.3.14), or in role clarification (Sect. 5.3.1).
Thus, negotiation skills are an important competence in the context of project work:
If you start a project with an illusory project scope, schedule, or budget, you increase
the project risk and thereby also present the team with unrealistic challenges. Those
who are unable to negotiate project roles and responsibilities by this only confirm the
expectations of others and do not live up to standards of personal self-management
(Sect. 3.8).
Negotiations, like project management, thrive on versatility (Sect. 1.7.1). Like in
a chess game, different scenarios are prepared in order to be able to react quickly and
flexibly in the situation itself. This means that preparation is an essential success
factor for negotiations.
4.10.2 What is a Negotiation?

" A situation is called a negotiation when two or more parties, in conversation, try
to come to an agreement on an issue or a set of issues (André Baer). These parties
can. . .
• Hold different views or pursue individual goals

• Be equipped with the competence to act and make decisions
• Have an interest in a solution
• Be under pressure to reach an agreement or an outcome
The reason for negotiation lies in differences assessing views or goals. In

addition, there needs to be a common interest in finding a solution or in reaching
an agreement. The most important prerequisite for a negotiation is the freedom of
action and decision-making of the parties involved. In project work, these depend on
the connection of the project to the line organisation. (Sect. 2.3.8.8) and on the
clarification of roles with the TCR (Sect. 4.8): If the project is integrated into the line,
e.g. through coordination, the project manager is merely a project coordinator. In this
role he has little or no decision-making authority. He is not legitimised to lead
4.10 Negotiation 341
negotiations. Negotiations have parallels to conflicts. For this reason, the topic of
conflict management (Sect. 5.6.9.4) will deal with elements of negotiation.
4.10.3 Negotiation Cycle
A negotiation is a complex process. Therefore, it is important that the approach to

negotiations reflects this complexity. The negotiation cycle described below
(Fig. 4.8) provides a guideline that has proven its practical usefulness many times.
The process consists of the three main phases “preparation”, “negotiation”, and
“evaluation”.
4.10.3.1 Preparation
Preparation is central to conducting negotiations. In complex negotiations, this can
take weeks or even months. The preparation phase consists of the following steps:
Situation: Problems and Needs

Before choosing a negotiation technique and strategy, the situation at hand has to be
analysed. The focus is on immediate problems and needs, or, to say it in the language
of project management methodology, the objectives (Sect. 2.3.2). The following
points or questions need to be clarified:
Preparation
Situation
Goals
Informations
Strategy
Tactics
3 1
Analysis
Measures Contact phase
Core phase
Eva
ion
Agreement
lua
iat
2 phase
ot
ti o
n g
Ne
Fig. 4.8 Negotiation cycle (after André Baer)

342 4 Leadership
• What is it about? Where is there a difference, what is the subject of negotiation?

• Is there any room for negotiation at all? Or does bad news simply have to be
delivered?
• Which people are involved? What freedom of action do they each have?
• For customer projects: Which aspects or framework conditions are specified by
the contract?
• In conflict-laden situations, additional clarification is needed:
• What are the parties really about?
• To what extent can a distinction be made between symptom and cause?
Goals
The goals are developed from the present perspective. They open up the future
perspective. It is often easy to name problems. However, formulating solutions in a
positive way is considerably more difficult. When formulating goals, the negotiating
party has to also be clear about what priority each goal has for them. Moreover, this
step is not only about one’s own priorities and goals. The goals and priorities of the
negotiating partner are to also be included here.
The target pyramid Fig. 4.9 allows one to concretise one’s own goals and their
priorities and to make assumptions about what these look like from the perspective
of the negotiating partner.
Our goals Objectives of the negotiating partner

1. Relationship with the customer 1. Reliable suppliers
2. Secure order situation 2. No production loss

because of late delivery
3. Protect reputation 3. Cost optimisation
4. Do not lose customer 4. No extra effort through

new supplier evaluation
5. Ensure contribution 5.
margin
6. 6.
Date: Responsible:
Fig. 4.9 Example target pyramid for a client project

The personal goals are to be described as concretely as possible. The following

points or questions should be clarified:
• What do I have to achieve (must have), where are my limits? If these minimum
goals are not achieved in the negotiation, this would mean breaking off the
negotiation (walk-away position).
• What goals am I aiming for in a realistic scenario, what can I count on (want-to-
have position)?
• What alternatives are possible? What would be a plan B? The better my
alternatives, the stronger my negotiating position.
We can never know for sure what the negotiating partner’s goals are. But we can
make assumptions or form hypotheses (Sect. 5.6.7.1). To do this, we ought to see
things through the other person’s eyes, change the perspective. The following points
or questions need to be clarified:
• What are the goals of my counterpart?

• For customer projects: What restrictions or conditions is my negotiating partner
confronted with through his organisation?
Information
Based on the concretised objectives, all information that may be relevant in some
way for the negotiation is collected and evaluated:
• What scope is there for negotiation?

• Where are the possible areas of agreement for each point of negotiation?
• Where is the limit? When would a negotiation have to be broken off?
• What legal restrictions need to be taken into account?
• What about the distribution of roles?
Strategies
The choice of negotiation strategy (Fig. 4.10) is based on similar criteria as the
stakeholder analysis (Sect. 2.3.5): Relationships, interests, power, and demands.
The more pronounced the relationships and interests are, the more cooperative the
negotiating parties will behave. The greater the demands and the more the
negotiating parties use the sources of power available to them, the more demanding
they will be.
Cooperative Strategy (Integration)

If the negotiating parties succeed in integrating their common interests into an
overall package or focus on a common, sustainable solution to the problem,
the cooperative strategy makes it possible to find optimal solutions for all parties.
The negotiation result is achieved with the greatest possible efficiency for both sides.
The goal is to achieve the Pareto optimum and not the maximum. The groundwork
344 4 Leadership
cooperative
Adaptation strategy Cooperative strategy

• Sacrifice your own interests • The agreement is the goal
• Submit to the relationship to relax • Focus on creation on both sides
advantageous options
Relationship, interests
Compromise strategy
Do mutual concessions, find a
reasonable agreement
Evasion strategy Enforcement strategy

• I would like to wait until I strengthened • Focus on the difference, not
non-cooperative
my position commonality
• Avoid that relationship is damaged • Focus on worsening foreign and impro-
ving their own alternatives
deep Power, demand high
Fig. 4.10 Negotiation strategies (according to André Baer)
for this is done in the goal pyramid (Fig. 4.9), in which the type of negotiation goals
and their prioritisation have a high degree of congruence.
In the cooperative strategy, common ground is emphasised. An attempt is made to
create a negotiation constellation advantageous to both parties. This strategy thrives
on open and honest communication. There is no use of pressure tactics, but instead
flexibility in the negotiation process and creativity in the search for solutions. This
strategy is the basis of the Harvard concept, which will be dealt with specifically in
the following (Sect. 4.10.4).
Assertion Strategy (Confrontation)

In assertiveness strategy, the main goal is to assert one’s own needs, which can have
the effect of diminishing the position of the other party. The differences are
emphasised. The relationship with the negotiating partner is not considered impor-
tant. Therefore, it is accepted that the relationship will suffer, break down, or stiffen
if the other party is confrontational, too.
Adaptation Strategy
In the adaptation strategy, one’s own interests are sacrificed. This strategy is chosen
when the relationship with the negotiating partner is to be relaxed. Well dosed, this
strategy makes sense in any given situation. However, it must not happen that one
party is permanently exploited due to personal weaknesses in negotiating

procedures.
Compromise Strategy
In the compromise strategy, both parties meet halfway. Both make concessions in
order to reach a mutually acceptable agreement. This strategy also makes sense in
any given situation. In the long run, however, no one is made happy by it. Therefore,
in medium- and long-term working relationships, precaution should be taken that
compromise does not become the standard.
Evasion Strategy
The evasion strategy is chosen when a confrontation would be completely pointless
in the current situation. If the counterpart holds all the trump cards, be it in terms of
content or power factors, negotiating makes no sense. One remains inactive in order
to gain time for further clarification. In this situation, it is better not to risk the
existing relationship and wait for a more favourable moment.
Example
If the customer insists on the contractually fixed delivery date, this would leave no
leeway and thus no possibility of going through a negotiation in the strict sense.
Then, if the project manager cannot meet the deadline, he becomes unable to
negotiate with the customerputting a strain on the customer–supplier
relationship.
It turns into a negotiable situation when the parties involved take a different
stance, when the project manager is able to negotiate with the customer or his
project owner about variants of service delivery. The subject of negotiation might
be that a partial delivery gets made or that a different quality is delivered and that
therefore a price reduction is then granted for this. It can be negotiated with the
project owner to pay the customer a contractually defined claim for damages
(Claim) or to allocate more resources to the project in order to fulfil the contract
on time. The strategy chosen depends on the prioritisation of one’s own goals and
the assessment of the negotiating partner’s goals (goal pyramid). If the customer
relationship and one’s reputation are paramount, an adaptation or cooperation
strategy is more likely to be chosen. If, on the other hand, one’s own financial
interests (contribution margin, order situation) are in the foreground, a compromise
or an enforcement strategy would become acceptable. It is often not within the
project manager’s decision-making authority which strategy primarily gets chosen.
However, through his clever negotiation skills, he can bring about that the parties
decide upon more cooperative strategies in order to solve the problem. ◄
Tactics
Once the most effective strategy and at least one plan B have been worked out, the
tactics for the negotiation can be defined. These tactics also depend on the character
traits of the people involved in the negotiation. Tactics include:
346 4 Leadership
• Having the place, room, and time for the negotiation.

• Determining people to be involved: project managers or product owners are to
ensure that all people who have the freedom of action or of decision for the
negotiation items—are involved in the process, e.g. sales, project owner, or line
managers.
• Demand more than you want: In order to room for manoeuvre in the negotiation,
more usually gets demanded at the beginning than is actually needed.
• How should arguments be made? What justifications ought to be used to support
one’s own negotiating position?
4.10.3.2 Optimal Negotiation Strategy and Tactics: Situational

Negotiations always take place between people. These people are in relationships
with each other. The conduct of negotiations will strongly depend on how the
relationship with the direct negotiating partners (project owner and project manager)
as well as the indirectly affected parties is assessed. If the customer is a non-strategic
one, a possible claim may be the lesser evil than allowing resources to be diverted
from yet another, perhaps strategically important customer project. However, if the
customer is a strategically important reference customer, carrying a high risk of
losing potential follow-up orders, this will significantly influence the negotiation
between the project owner and the project manager.
The relationship between the project owner and the project manager is also
relevant: If the two have been working together for years in a delegative or partici-
pative leadership style, then this is a completely different starting position than if the
project owner leads his project manager in a directive way, unafraid to play out his
institutional sources of power.
In the first case, within the participative management relationship between project
owner and project manager, negotiation according to the Harvard concept (coopera-
tive strategy) becomes appropriate. However, this concept does not work if one party
uses its power inflexibly in the negotiation. In such a case, it is advisable to choose a
negotiation strategy adapted to the situation. The choice of negotiating strategy
should always be guided by the following rule:
The strategy to be chosen should always be one that aims at long-term cooperation while
preserving one’s own reputation.
In principle, the best results can be achieved in the long term with a cooperative
negotiation strategy. However, this requires that the parties manage to integrate their
different interests. Therefore, cooperation in this regard should always be considered
as the best and first choice. Even so, this usually means that it is possible to include
new, additional negotiating items in the negotiation process in addition to what it
was all about in the first place (Fig. 4.11). Figuratively speaking, it is not primarily
about dividing up a cake (confrontational negotiation), but about enlarging it in order
to generate additional benefits for both parties (cooperative, integrative negotiation).
As soon as one party starts to elbow its way through to its own advantage, integration
is no longer possible.
Confrontational negotiation
B
Fight, often unfair
A distribution
Cooperative, inclusive negotiation
B
Fair, just
A distribution
Subject of New, additional Extended, bigger

negotiations items for nego- bargaining chips
tiation
Fig. 4.11 Cooperative strategy through new negotiation items (after André Baer)
4.10.3.3 Negotiation
After preparation, the effective conduct of negotiations can begin. This is based on
the following phases:
1. Contact
First of all, an optimal environment for the negotiation needs to be established.

Above all, the compromise and cooperation strategy depend on whether the
negotiating parties succeed in establishing trust for each other (Sect. 3.3.5).
Then the goal for the negotiation hast to be clarified. Possible non-goals should
also be delineated. The negotiating parties should be able to put forward their
demands and wishes in this step. Finally, the agenda is set: Time frame, agenda,
and procedure. It should also be clear which communication rules apply and who
plays specific roles such as moderator or chair of the meeting.
2. Core phase
The core phase of the negotiation is divided into three sections:

a. Exchange of information
• Presenting the topic, the problem

• Pointing out effects, significance, consequences of the situation for both sides
• Commenting on each other
348 4 Leadership
b. Negotiating leeway
• Identify negotiating leeway for each component

• Investigate whether a common platform for concessions is appropriate
• Expand the negotiating mass by integrating other interests
c. Solution search
• Clarify priorities
• Show scenarios and solution variants
• Exchange possible concessions
• Evaluate the usefulness of the results
• Make a decision
3. Agreement phase
The negotiation phase is concluded by the agreement phase. First, the results and
decisions of the negotiation are summarised. Finally, the binding nature of the
implementation is established through a contract or a protocol.
a. Summary and outlook

• Summarise results
• Check that there are no misunderstandings
• Agree on objectives and a timetable for implementation
• Discuss and initiate measures
b. Agreement, contract
• Record results in writing
• Agree on further steps
• Record what is to happen in the event of non-compliance with the agreement
• Arrange a follow-up appointment
• Thank the negotiating partners
4.10.3.4 Evaluation and Controlling

Like a project, a negotiation also gets evaluated. One’s own conduct of the negotia-
tion, and thus the entire preparation with the definition of strategy and tactics, hast to
be analysed, with possible measures for the future inferred from this. In addition, it
needs to be guaranteed, in the sense of a controlling procedure, that the agreed-upon
measures are implemented accordingly by all negotiating parties.
4.10.4 Conducting a Negotiation According to the Harvard Concept
The negotiation according to the Harvard concept (Fisher et al., 2018) is a coopera-
tive negotiation strategy. With this approach, optimal negotiation results can be
achieved under the following basic conditions:
• The parties have common areas of interest

• The parties refrain from using their power
• The parties have high communicative competence and disclose their information
Under these premises, the Harvard concept is also well suited for dealing with
conflict situations. In Sect. 5.6.9.4, conflict management according to this concept is
presented.
4.10.4.1 Separation Between Person and Topic

The Harvard concept has become known for its slogan “Hard on the subject, soft on
people”. The essence of the model is outlined in Fig. 4.12. As long as all parties to
the conflict meet as equals, the focus is on the integration of interests and no
institutional power factors such as positional power, decision-making power, or
power through punishment (Sect. 4.9) are used, the best possible results can be
achieved (Fisher et al., 2018).
The content of the negotiation has to be clearly separated from the person.
Whether we like the other person or not should have no influence on our negotiation.
As in sport taken seriously, the point is to argue with commitment during the
negotiation. Afterwards, you respectfully shake hands. In negotiations you:
Person Thing
Humans Interests
People and Not positions,
problems treated but interests
separated to put in the center
from one another
Possibilities Criteria
Develop various Build the result on
options before the objective decisi-
decision on-making principles
«Hard on the subject, soft on people»
Fig. 4.12 Key factors in the Harvard concept

350 4 Leadership
• Create trust: A “negotiating space” is needed in which all parties feel safe
• Clarify roles and responsibilities of persons (parties) involved in the process
• Clarify the rules of communication: I-message, active listening, letting people
finish and without making assumptions about the other person’s intentions, but
rather asking questions.
4.10.4.2 Interests Instead of Positions

The next step is to detach the negotiation from positions describing what we pretend
to want. This might be a struggle by project manager with his project owner for more
resources. In a position there is always a weaker party (in this case, the project
manager) and a stronger party (the project owner). In this example-constellation it is
difficult to reach an agreement. If, on the other hand, the project manager succeeds in
getting the project owner to commit to a common interest, the negotiation can be
conducted at eye level. The perspective shifts from the present to the future:
• Focus on common interests and needs: Why do we want something? This may
entail risks needing to be eliminated, qualitative aspects or common interests in
terms of project duration.
• Change of perspective: In order to find common interests, I have to be able to ask
myself what the negotiating partner needs from me and what difficulties or
limitations they are facing.
" In order to bring about a change of perspective from a position (what?)

to interests (why?) and also towards needs, the metamirror suggested by
Robert Dilts or the model of the conflict onion is helpful (Sect. 5.6.9.4).
4.10.4.3 Possibilities
The more variants there are available in a negotiation, the greater the scope for
decision-making. In this phase, the aim is to work out different options that fulfil the
aspects of the interests and needs that have been worked out. One has to:
• Develop realistic options: The best solution is usually obvious to everyone, but it
is not realistic because all organisations delivering projects are always performing
a balancing act between the elements of the magic triangle of “scope”, “time”, and
“cost”. The second-best solution is to develop realistic options.
• Work out other alternatives besides the optimal variant. There needs to be at least
one plan B, better still even more possibilities and variants.
• Actively involve negotiating parties in the development of possible solutions.
This will increase commitment in a later implementation.
• Consider that developing different possibilities needs creativity.
• The better it is possible to find ways of finding the right balance between the
interests of the parties, the more significant the win–win situation for all parties
involved.
4.11 Moderation 351
4.10.4.4 Fair Criteria

Prior to the effective assessment of the variants, the decision criteria are recorded in a
solution-neutral manner following the SMART rule (Sect. 2.3.2.4) as far as possible.
The joint discussion of objective criteria that can be applied to the selection of the
negotiating alternative makes it easier to leave positions. It also removes the basis for
unfair pressure from either side. Common criteria are:
• A cost ceiling which may not be exceeded

• Specific risks that need to be reduced
• Milestones that have to be met
4.10.4.5 Selection According to the BATNA Principle

When these four aspects have been considered, the best alternative solution can be
chosen. This should be done using the BATNA principle: Best Alternative To a
Negotiated Agreement. In decision-making situations, people are always influenced
by their feelings, personal goals, and intuition. To see to it that reason and intellect
are also adequately taken into account, it is advisable to apply decision-making
techniques here (Sect. 2.8.3).
4.11 Moderation
Moderation (from “moderari”, Latin for moderating, guiding, finding the middle) is
one of the central competences for successful projects and is needed when processes
in the team need to be guided and directed, e.g. for creative problem solving, a
decision-making process, opinion forming in the team, conflict resolution, etc. In
such situations, reflection or feedback culture in a group is also often promoted. The
following requirements are important for successful moderation:
• Process competence: The facilitator has to know how to make the group work and
how to achieve the meeting objectives.
• Social competence: The facilitator must understand and be able to respond to the
dynamics of the group; and, if necessary, address these (relationship before
matter).
• Communication competence: The facilitator needs to master the methods of
questioning and directing the conversation. He is to intervene immediately in
the case of assessments (you-messages) and boundary violations (Sect. 3.9).
• Competence for complexity reduction: In order to be able to work on complexity,
it has to be reduced through visualisation techniques, developing scenarios, mind
mapping, and other instruments of structured problem solving.
352 4 Leadership
It
Subject level Facts
- Visible Language
- Conscious 11% Actions
Relationship level 89% Thoughts

- Invisible Emotions
- Unconscious Intentions
Me We
Fig. 4.13 Iceberg model
4.11.1 Iceberg Model
" “On the factual level, only what the relationship level allows is possible”.
Moderation also means analysing and supporting the level of relationships among
the participants. The clarification of roles at the beginning of a meeting should lead
to the result that resistance in the course of a meeting does not get relegated to the
factual level “It” (Fig. 4.13, iceberg model), but that it can be openly addressed on
the relationship level “Me” or “We” and resolved in the group (Ruth Cohn, Theme-
Centred Interaction, 2001).
4.11.2 Phases of Moderation
“Who asks leads”. This is especially true for the facilitator. He uses questions to steer
the process through the various work phases (Table 4.7).
4.11 Moderation 353
Table 4.7 Phases of moderation

Phase Topics to be clarified, questions
Prepare What is to be achieved? (Goals and expectations)
What arrangements and clarifications need to take place before the
meeting?
Opening and Which goals are to be achieved?
orienting What is the planned procedure?
Creating a constructive working atmosphere, building trust
Collect and select Conducting a review of the meeting topics
Collecting further concerns
Setting up a prioritisation of the topics
Edit Actual processing of the selected topics
Plan and finalise Commitment and clarity of order: who does what by when?
Retrospective
Review Protocol and post-processing
Checking agreements and results
Table 4.8 Responsibilities and competences of the moderator

Topic Description
Responsibility • Responsible for the process and not for the result
• Selecting an appropriate course of action
• Clarification of dual roles (e.g. project manager and supervisor)
• To make and keep the group fit for work
• Equal involvement of the participants
• To lead via questions (. . .instead of by guidelines)
• To keep the activities of the group focused on the goal
Skills • Being able to think your way into the meeting content
• Process and methodological skills
• Questioning techniques and social skills
• Meaningful visualisation of the course of the conversation
• Ability to reduce complexity
• Recognising and resolving misunderstandings
4.11.3 Responsibility and Competences of the Moderator
In order to develop one’s own understanding of facilitation, it is essential to be clear

about the responsibilities and competences in the role of the moderator. Table 4.8
shows possible dimensions.
4.11.4 Checklist for the Preparation of a Moderated Session
The following points are helpful for preparing and conducting a moderated meeting,
the moderator:
354 4 Leadership
Start-up phase:
• Pays attention to seating arrangements or even specifies them

• Formulates the meeting objective at the beginning
• Briefly picks up all participants at the beginning
• Defines binding time frame
• Clarifies his and the participants’ roles
• Finds the best possible approach with the group
• Agrees on further rules of the game and ensures that they are observed
• Make sure that there is appropriate protocolling
Basic attitudes the moderator ought to show are:
• An appreciative attitude towards the persons

• A neutral attitude regarding topics and participants
• Being present with head, stomach, and heart
• Giving social interferences priority
• The ability to work with the group instead of fighting against it
• To not be defensive have a self-justifying stance
• Being able to distinguish between perceiving, assuming, and evaluating
Communication, the moderator should:
• Ask instead of tell

• Pay attention to the level of detail
• Visualise the process flow
• Activate “silent” participants
• Intervene with frequent speakers
• Uncover potential for conflict
• Analyse the language habits
• Pay attention to verbal and paraverbal communication
Closing phase, the moderator:
• Recapitulates and summarises results

• Demands concrete decisions and responsibilities
• Formulates the further procedure
• Thanks the participants and closes the meeting
The specific requirements for virtual meetings are described in the following
Sect. 4.12.
4.12 Communicate Effectively with Virtual Teams 355
4.12 Communicate Effectively with Virtual Teams
Leading virtual teams represents an additional challenge for those responsible for the
project. A virtual team is made up of people who work in geographically, tempo-
rally, and organisationally different dimensions. Cooperation is made more difficult
because the team members speak different languages or come from different
cultures.
Communication, in this case, between project members often takes place asyn-
chronously and frequently using a meta-language because they do not share a native
language and skills in the language used alternatively are not sufficient. Example:
French speakers communicate with German speakers in English. It is advisable to
carefully agree on the rules of communication across these boundaries and to clearly
define the communication channels and collaboration platforms to be used.
Digital platforms facilitate collaboration considerably. The following examples
illustrate this: A SWOT analysis can be carried out synchronously with a whiteboard
application on an online platform, but it can also be processed asynchronously with a
corresponding word template in a time frame agreed upon beforehand. Or project
planning can be partially outsourced to the project members with the help of a
kanban board and then always remains up to date compared to a manually tracked
project plan.
In the physical world of work, much information is conveyed verbally. In the
virtual world, on the other hand, the proportion of written communication is much
higher. Written communication in the project takes place less and less by email, but
increasingly via collaboration platforms. This means that rules for the digital
exchange of information are becoming more and more important (Sect. 4.4.5). To
optimise its communication, a project team should agree on a communication codex.
Key points are:
• Meaningful subject line: this determines how quickly the message is read
• No novels: no scrolling, no resentment
• Rapid response: this does not necessarily have to be a substantial response to
an email
• Correct spelling: a minimum of appreciation for the recipient
• Always be polite: “Hello” does not go down well with everyone
• No jungle of abbreviations: brgds, fyi, cu,. . .
• No emojis: not always a good thing in business communication
• Add a signature: Your business card as sender
Virtual meetings have different needs in terms of preparation and implementation

and require that a minimum level of trust already exists in the team. In order to
achieve this, the PERMA model by Martin Seligman (Seligman Martin, 2012)
defines important prerequisites for this (Sect. 5.4.2).
Figure 4.14 shows some aspects that are helpful for preparing and conducting a
virtual meeting.
356 4 Leadership
Check-in Measure pulse Check-out
Prepare Visualise Integrate Agree
• what do I need to know Ensure, that ... Ensure, that ... Everyone knows ...
• what do I want to say • all see the same • all see, hear and have • what the goal is
• what do I want to achieve • all can contribute understood the same • what they have to do
• what does the team need something thing • who needs what by when
• all have access to • all agree • how they work together
important documents • how to escalate
Build trust and stay connected
Fig. 4.14 Sequence of a virtual meeting
Because verbal feedback or a non-verbal reaction as in a face-to-face meeting is

often lacking, the following aspects have to be considered in the individual phases of
a virtual meeting:
Check-in: At the beginning of the meeting
• Build additional trust through a short round of talking about sensitivities; intro-
duce informal topics and see to the mood of people and allow for the appropriate
space (disruptions have priority).
• Share recent experiences in the team: “What did you do well?” “What are you
working on at the moment?” “What are you particularly busy with at the
moment?” etc.
• The question: “Who wants to start?” usually does not work virtually. Clear
announcements are needed, e.g. who speaks in which order.
Time management in topic processing
• Announce and stick to regular breaks

• Keep technical contributions as short as possible, rather distribute this type of
information in advance
• For improved interaction, delegate the participants to supervised breakout
sessions
References 357
Measure the pulse: After completion of the integration phase
• Check whether the results or decisions taken are to everyone’s satisfaction: “Are
you happy with the result?” “Will this decision be well received in your
department?” etc.
Check-out: At the end of the meeting
• Obtain mutual feedback on the procedure or outcome of the completed meeting:

“How did you feel about our work process?” “What did we solve well?” “What
was not satisfying?” “What would you do differently next time?” etc.
References
Blanchard, J. H. (2015). Management of organizational behavior. Pearson India.
Fisher, R., Ury, W., & Patton, B. (2018). Das Harvard-Konzept. Deutsche Verlags-Anstalt.
French, J., Jr., & Raven, B. (1959). The bases of social power. In D. Cartwright (Ed.), Studies in
social power (pp. S. 150–S. 167). University of Michigan.
Gellert, M., & Nowak, C. (2007). Teamarbeit – Teamentwicklung – Teamberatung (3. Auflage
Ausg.). Limmer Verlag.
Martin, S. (2012). Flourish: A visionary new understanding of happiness and well-being. Atria
Books.
Oestereich, B., & Schröder, C. (2020). Agile Organisationsentwicklung. Franz Vahlen GmbH.
Radatz, S. (2009, Januar 28). Führen ohne. In Führungsmacht. ProjektMagazin.
Seliger, R. (2014). Positive leadership – Die revolution in der Führung. Schäffer-Poeschel Verlag.
Spisak, M., & Della Picca, M. (2017). Führungsfaktor Psychologie. Springer.
Zirkler, M. (2008). Konzepte der Macht. In T. Steiger & E. Lippmann (Eds.), Handbuch
angewandte Psychologie für Führungskräfte (Vol. II). Springer.
Further Readings
Baer André. (2018). Unveröffentlichte Seminarmanuskripte.

Breidenbach, J., & Rollow, B. (2019). New work needs inner work (2. Auflage). Franz Vahlen
Verlag.
Frederic, L. (2015). Reinventing organizations. Franz Vahlen Verlag.
Kühl, S. (2015). Wenn die Affen den Zoo Regieren – die Tücken der flachen Hierarchien. Campus
Verlag.
Zirkler, M., & Werkmann-Karcher, B. (2020). Psychologie der Agilität – Lernwege für Individuen
und Teams. Springer.
Teams
5
This chapter deals with the fundamental aspects of teams and groups and the
dynamics that can unfold in them during project work. The focus lies on procedures
facilitating successful role clarifying, on how the principles of positive psychology
can have an effect on a team, and what the characteristics of a high-performance
team are. The chapter concludes by describing change and resistance as well as by
taking a comprehensive in-depth look at conflict management and crises. The topics
are structured according to their relevance for the agile and the traditional approach.
5.1 Aspects of Teams and Groups
5.1.1 What Distinguishes Teams from Working Groups?
Teams differ from work groups in terms of efficiency, values, working culture, and
in how they see themselves as a unit. A team is a group of active individuals whose
overall performance exceeds the sum of the individual performances due to the
nature of their cooperation. This cooperation has to be continuously developed in
order to optimally utilise the performance potential of each individual. This
realisation is often described in the formula 1 + 1 = 3. The team pursues a goal
that can only be achieved by working together.
A key feature is the participation of members in decision-making and the ability
to deal productively with conflict. Teams, unlike working groups, have learned to
deal productively with the diversity of their members and the resulting conflicts. The
goal is delivering good results and not adhering to conformity. The team has the
necessary creative leeway to achieve this.
These differences can be summarised in Table 5.1.

https://doi.org/10.1007/978-3-662-66211-3_5
360 5 Teams
Table 5.1 Differences between teams and working groups

Team Working group
• Understanding as a unit of work • Understanding as a collaborator
• Self-organisation • Organisation by superiors
• Results orientation • Focus on individual task completion
• Error tolerance rather high • Error tolerance rather small
• Professional conflict management • Less risk for conflicts to emerge
• Identification with the group • No common identification
• Coordination • No personal connections
• Group responsibility • Individual responsibility
• Complex work processes • Standardised processes
• Good relations with each other • Relationship with each other not important
5.1.2 Composition of the Project Team
The following guiding principles contribute to the ideal composition of a

project team:
Who Puts Together the Project Team?

The project team is officially appointed and released from responsibility by the
project owner after the project is completed. However, those responsible for the
project need to be able to exert a decisive influence on the selection of the members.
In all organisations, they are therein dependent on the help of the managers. In order
for them to be able to send the right people to the project teams, the project owners
and the project managers have to formulate a requirements profile for the future
project team members.
The Objective of the Project Phase Determines the Team Size

Depending on the project phase, the project team composition can change. For
feasibility studies and process planning, a smaller “mastermind group” is advanta-
geous. If, on the other hand, the broadest possible acceptance is to be achieved, it is
more likely that a large, preferably representative team will be chosen.
For those responsible for the project, this can lead to a dilemma: If all
stakeholders are to be represented or the project owner puts together a large team,
this results in groups becoming far too large and cumbersome. In such a case, the
formation of a project management team (core team) that does the essential prelimi-
nary work ensures mutual coordination and then submits this to the “extended
project team” for further processing.
Changing Skills Are in Demand

Different skills are required in the different phases. For example, a lot of creative
thinking and “tinkering” is needed during the concept phase, whereas organisational
skills and marketing knowledge are required in the implementation phase. These
skills may not all be found to be present and available in the same people, so it may
make sense to change the project team members in the course of the project.
5.1 Aspects of Teams and Groups 361
When changing project team members, the following critical points should be
considered:
• Careful and detailed handovers are to take place between team members.
• This is done to regulate for which problems the predecessors were “susceptible”
and to what extent they have to be available to the successors in solving them.
Depending on the project (Sect. 1.2.1), different skills are required, and these
skills are in varying degrees of strength. For example, a project needing a strong
potential and a character of its own will want innovative and creative free thinkers,
whereas a high acceptance project will need excellent communicators who can
approach people, listen to them, and work out arguments for the project with them.
If You Don’t Have the Time, Then It Is Better You Leave It

Team members who cannot or do not want to devote enough time to the project often
block cooperation and thereby project progress. Specific technical experts with
selective tasks are exempt from this. Therefore, it is important to clarify at the
very beginning:
• How much effort the members will have to expect.

• Whether they will be released from their normal duties to the appropriate extent.
Against Too Much Harmony in the Team

Every project manager wants the “chemistry” in his project team to be “right” and to
see everybody work together harmoniously. This wish is understandable, but not
always reasonable. Tensions that arise from the problem or from some of the
conflicting interests of different organisational units are in themselves not a bad
thing. On the contrary, they can be used as an opportunity to clarify things in the
project team.
Problems that are bypassed or put on hold during project work will later
re-emerge in a much more dramatic way. Dramatic because as the project progresses,
the financial and temporal adjustment effort required to correct such “mistakes”
increases disproportionately.
" Save your need for harmony for after work and bring critics and lateral
thinkers into your teams. Demand a breath of fresh air and realism in
project work. In doing so, make sure that you do not overtax yourself and
the other project team members. If the right balance is lacking, this will
obstruct work to a high degree, resulting in losses instead of gains.
362 5 Teams
5.2 Dynamics in Teams
Independently of whether an agile or a traditional approach is chosen, according to

Bruce Tuckman each team goes through certain phases of a team development
process in a specific way. For the five phases shown in Fig. 5.1 the following
terms have become accepted: Forming, Storming, Norming, Performing, and
Adjourning. Each of these phases contains specific challenges, opportunities, and
also dangers, all of which are described below (Gellert & Nowak, 2007, p. 192 ff).
5.2.1 Forming: Orientation
In teams that are newly formed, e.g. at the project kick-off, there is more or less
uncertainty at the beginning. The members of the group ask themselves what exactly
is in store for them, what their personal role shall be, which rules have to be
observed, or who the other team members are and how they are going to tackle the
tasks. According to their personal characteristics, the team members behave very
differently in this phase: some are curious and expectant, others are more reserved or
even sceptical.
high
Danger of a
Work group conflict Top team
Performance
Team development
Developed group Change

Danger of Conflict
change
small
Forming Storming Norming Performing Adjourning

Orientation Confrontation Familiarity Work in the Farewell and
Opening Regulate Give room system separation
Access Stability To keep the To advise Project review
Security Attention border Controlling Successes
Communication Sticking to goals To recognise Asynchrony
overconfidence
Fig. 5.1 Five development phases of teams according to Bruce Tuckman

5.2 Dynamics in Teams 363
The forming phase is characterised by polite, reserved, and a rather distance-

keeping behaviour of the members. They are not yet a team in the real sense of
the word.
" The most important tasks for team development in this phase are:
• Opening: The project managers should create framework conditions

and implement interventions that allow the individual group
members to get to know each other and develop trust in each other.
• Access: Finding access to the content of the project objective.
Depending on the assignment, the aim is to achieve the willingness
to get involved in something new.
• Security: In order to reduce uncertainty, the ability to work needs to be
established as well as possible. This includes clarifying the project
organisation with the respective roles (agile or traditional), defining
reporting channels and information flow or even explaining the entire
document management. This helps the individuals to find their way in
this first phase.
Careful preparation and implementation of the kick-off represents a valuable

contribution to dealing well with the challenges in this first phase of team
development.
5.2.2 Storming: Discussion
After a team has been formed through the forming process, work begins on the
substantive goals and tasks. The work in the system is in the foreground, the system
itself with its relationship and organisational level is usually still weak. The team
members now cast off their former reserve and show more openness of character.
After the team structure has been regulated on the formal level through the
organisational chart or role assignments in the forming phase, the team must now
also find itself on the informal level. This phase can be quite unproblematic if the
team members already know each other and have already gone through team
development in other projects. But if frictions and animosities from a previous
collaboration are still unresolved, (new) team members pose a challenge to the
formal or informal team organisation. Or a higher-level body delegates a conflict
to the project (Sect. 5.6.2). It is then that disputes and conflicts arise. In the storming
phase, the group is characterised by tense expectations and the hope for good
364 5 Teams
cooperation. At the same time, this young team is still very susceptible to
disruptions.
" The most important tasks in agile and traditional project

management are:
Rules: The rules established at the kick-off are now tested by the team for
their stability. Those responsible for the project have to keep a watch-
ful eye on which rules of cooperation are effective and where
improvements can still be made.
Steadfastness: In this phase, the team members test the different roles
and committees (agile or traditional) for their assertiveness and (fac-
tual) competence. They see themselves as being increasingly
confronted with questions and sometimes also with criticism. Behind
this behaviour also lies the basic need for social recognition in the
group. Good composure and steadfastness will help the managers in
this phase to consolidate their personal roles in the group.
Attention: In this phase, the group dynamics are played out on several
levels. Not everything has to be addressed and dealt with. But wher-
ever the team’s ability to work is impaired, scrum masters or project
managers have got to intervene. In these situations, conflict manage-
ment or dealing with resistance can help.
Communication: In order to control this phase well, a well-developed
communication and feedback culture is needed. Only if communica-
tion and feedback are designed to have a clarifying effect and are not
judgemental can the group members exchange ideas without fear.
Agile project management has a valuable platform for this: the daily
stand-up meeting. The fact that the meeting takes place every day
creates a high degree of transparency, thus helping to deal with
tensions between people or teams before they get out of hand.
In the storming phase, the work on content is often tedious and slow. However,
this work in the system should not be in the foreground here. Much more important
is the work on the system. Every behaviour of the people involved can be examined
in a differentiated way in terms of symptoms and causes. In dealing with the essential
causes lies the great opportunity to develop the work on the system in such a way
that the foundation for a high-performance team is created. By focusing on the work
on the system in this phase, scrum masters and project managers create the starting
point for the next group phase.
5.2.3 Norming: Familiarity
Through dealing with the different friction points, conflicts, or resistances, the fears
of those concerned can be reduced and their roles further clarified. This creates
feelings of security. Addressing difficulties and personal needs openly increases the
inner cohesion of the group so that a group identity can emerge after the individuals
have found their position within the group.
It is specifically thanks to the challenge passed through together in the storming
phase that mutual trust grows (Sect. 3.3.5). This can lead to cohesion in the group.
Cohesion as a sense of community and solidarity that from then on exists in a team.
Cohesion has a significant influence on the stability of a group, making the team
become attractive to its members. New group norms also encourage more an open
and personal behaviour.
Table 5.2 shows cohesion-promoting and inhibiting measures and framework
conditions.
But there is also a downside: the higher the cohesion in a group, the harder it is for
new team members to get accepted into the existing group structure. As a conse-
quence of the newly gained familiarity, the work content itself also moves more into
the background. The relationship level is in the foreground in this phase.
" The most important tasks for team development in this phase are to:
Give space: It does not make sense to put too much pressure on the
content in this phase. The group should be able to relieve the stress of
the confrontation and strengthen the social fabric on its own. The
recommendation is even to offer further confidence-building
measures in this phase.
Maintain a boundary: At this stage it is tempting for project managers to
ingratiate themselves into the familiarity of the group. This tempta-
tion must be resisted: The boundary between the team and the other
role players in the project has to be maintained.
Stick to the goals: The work is no longer tedious as in the storming phase,
but productivity is not very high either. The group has to be oriented
towards goal setting and the performing phase.
Table 5.2 Factors that promote and inhibit cohesion

Promote cohesion Inhibit cohesion
Favourable group size (5–8 persons) Group too small or too large
Common interactions Lone warrior work
Collective performance assessment Individual performance assessment
Open and honest communication Intransparent communication culture
366 5 Teams
To support team development the models for self-recognition (Sect. 3.10.2) and
organisational constellations apply (Sect. 5.4.6). The people now have the confi-
dence to talk to each other about their own strengths and weaknesses.
5.2.4 Performing: Working in the System
A successful completion of each of the previous phases increases the ability and
willingness of the team members to cooperate. Now the focus is on constructive
cooperation, working in the system. The group members are motivated and show
initiative. The performance is not only revealed in good, content-related work, but it
above all becomes apparent in the group members’ own initiative for cooperation,
organisation, and mutual coordination. Only a minimum of formal leadership is now
needed. In agile project teams, the scrum master is at this stage required very little. In
this phase:
• Group rules and norms are openly communicated and supported by all.
• Individual needs and group interest are in balance.
• Essential work processes are carried out effectively, free from coalition-forming
and competition.
The group has now reached a high level of maturity. Relationship work is no
longer in the foreground, energy is no longer absorbed by rivalries and conflicts. The
common goal is in the foreground.
Advising: One needs to ensure that processes are being followed. Provide
advice when needed.
Controlling In traditional project management, it has to be checked
whether the work packages and intermediate objectives have really
been completed in the necessary quality (e.g. 90% syndrome Sect. 2.5.
6.5). In addition, it has to be ensured that the less popular work such
as documentation or configuration management also gets tracked in
accordance with the course of the project. In agile project manage-
ment, the product owner checks the qualitative goals in the sprint
review. For this purpose, the sprint burndown chart is a valuable
source for keeping an eye on the performance of the team remaining
effective.
Recognising overestimation of one’s self: It can get to the point where a
team completely overestimates itself. Those responsible for the proj-
ect are to rein in statements such as “we are the best”, especially when
that happens at the expense of other groups.
Figuratively speaking, scrum masters and project managers can each take on the
role of referee in a football match during this phase. They observe the action from a
certain distance and only intervene if rules are broken. Otherwise, they let the game
continue and prepare for the next phase.
5.2.5 Adjourning: Farewell and Separation
Every project finally has to come to an end. This also means that the project team is
disbanded. In traditional project management, this phase, the final project assess-
ment, unfortunately often gets neglected because the next urgent projects and tasks
are already waiting.
Yet, it is precisely this last phase that holds great potential for personal and
collective development: Here the group process as well as the personal role can be
reflected upon. This is the basis of learning within the organisation: that experiences
are to be reflected upon again and again. A distinction has to be made between
symptom and cause. Finally, new patterns of action and measures derived from these
past projects further the effectiveness of project work.
The process of separation should also avoid that individuals leave the cooperation
either burdened in some way or with feelings of ambivalence, both of which would
place a weight on future projects.
Project closure or retrospective: These platforms need clear structures

ensuring that the focus lies on content and on improvement of future
project developments, and that no one gets personally attacked or
put down. Competent moderation of this occasion is important. In
agile project management, the scrum master is assigned this task. In
the traditional approach, the responsibility basically lies with the
project manager. However, neutral, external moderation is often
recommended for the project review: this allows the project manager
to fully assume the role of a member of the project organisation
during the project review, which avoids him having to play a double
role with the responsibility for the design of the process.
Successes: Social recognition is an essential basic human need. Successes
should be celebrated, the team ought to receive the appreciation it
has earned. A team event always has a very good effect also on the
future commitment of the employees. In addition to this, an article
can be published about this in the internal news channel for the
purpose of project marketing.
Non-simultaneity: Especially in traditional project management, the last
phase is characterised by people being repeatedly withdrawn from
it. It is up to those responsible for the project to keep the threads
together in this phase and also to ensure that everybody involved is
able to be present at the essential events.
368 5 Teams
5.2.6 Dynamics and Interaction
The phases of team development are not always passed through in an orderly,
chronological sequence. The intensity with which a specific phase manifests itself
can also be quite varied. There is also no guarantee that a team that has arrived at the
performing phase will remain in it until it is dissolved. Scrum masters as well as
project managers should be sensitive to all kinds of disturbances that challenge the
team structure anew every time something like this happens: This mainly concerns
changes in the composition of the project organisation, though. When new people
join the group or others leave it, completely new dynamics can develop. A team in
the performing phase can thus fall back into the storming phase and may need to also
briefly go through the norming phase again. The same can happen if the internal or
external project owner makes significant changes to one of the parameters of the
magic triangle, or if the project team cannot be protected well enough from access
from the line organisation. This is often the case when individual team members are
assigned to tasks of an operationally higher-priority, thereby reducing their effi-
ciency for the project.
" The challenge of the team development process is that performing can
only be achieved through storming and norming. The conflict in
storming forms the foundation for the later performing. Teams that
lack conflict management skills will get stuck in this conflict wave,
making work tedious, exhausting and unsatisfying from beginning
to end.
5.3 Roles in the Project Organisation
5.3.1 “Line-up” in Teams: Position and Role
Whoever wants to produce a feature film has to fill very different positions: It needs a
writer for the script, a director, actors, extras, cameramen, studio staff, someone to
arrange the financing, and many others. One of the basic requirements for the work
to turn out successful is to define the necessary positions and to fill these positions
with suitable people.
An Organisation Empowers Positions
Positions describe the formal or informal place in an organisation (Ruth Seliger).
On closer examination, organisations do not empower individuals (line managers),

rather, power is assigned to the positions of the line organisation, which are
hierarchically divided according to areas of responsibility. CEO, CFO, head of
project management or team leader logistics might be position descriptions in this
5.3 Roles in the Project Organisation 369
context. Through these positions, an organisation clarifies its areas of responsibility,

defines its “line-up”, so to speak. An organisation delegates status and decision-
making power to these positions. These authorities are not bound to certain
individuals and continue on even if there is a change of position. They can also be
delegated to other people (Sect. 4.9).
One Position Contains Several Roles

Anyone working in the project management environment always has to play multi-
ple roles within his position, except in pure project organisation. The position of
head of project management includes very different tasks, which are also only
temporary in relation to project management. We refer to these as roles.
Example
For example, the head of project management may be responsible for managing
the project portfolio of the entire organisation and for developing and enforcing
project management guidelines and standards. He nominates the project
managers and leads them in terms of discipline as well as professionally. He is
also responsible for the budget of his team. In addition, he takes on various
temporary roles in specific projects.
The position of the customer project manager involves completely different
roles: In addition to being a project manager, he is, for example, a customer
advisor or provides third level support within the scope of the technical
competences. ◄
Of course, this also applies to the roles in agile project management. The specific
competencies and management tasks in the respective roles are described in detail in
Sect. 2.3.8.3. In Fig. 5.2 an organisation with the positions and roles is depicted.
Roles Reduce Complexity and Create Trust

Through roles we can reduce complexity in a social system: the better we meet the
“behavioural expectations” (Ruth Seliger) of our fellow human beings, the easier it is
for them to classify us. This automatically creates more of a sense of security for
everyone involved. This feeling of security is in turn a basic prerequisite in order for
trust to develop between individuals and, as a consequence, in a team or in an
organisation (Sect. 3.3.5).
Clarifying one’s own roles is part of every employee’s personal responsibility. In
many cases, these roles have to be negotiated because the expectations and demands
of the organisation exceed the possibilities of the individual. The more clearly these
roles are defined and the better they are coordinated according to the congruence
principle TCR (Sect. 4.8), the more effective the work of the individuals and the
organisation is as a whole.
370 5 Teams
Fig. 5.2 Position and roles in organisations
5.3.2 Role Carrier and Role Sender
The Role Senders Determine the Behaviour of the Role Carriers

Our feature film with only an exciting script and clearly defined positions and roles
will not be a box-office hit. Success depends, among other things, on whether the
director finds actors who manage to play the roles so authentically that they are
thereby able to captivate the audience.
Verbal communication, knowing the text by heart, is by far not enough. The star
differs from the normal actor in how credibly and effectively he can embody the role,
especially through non-verbal communication. And this in turn depends on how well
the actor can live up to the expectations of the audience. Be it the hero, the villain or
the clown: The audience has expectations of how, for example, a clown should
behave in specific situations. They send these expectations (role senders) to the role
carrier.
We call the behaviour of a role carrier in a specific situation a lived role. In this
example, the audience with their expectations of the role of the clown are the role
senders. The clown is the role carrier. The phenomenon of the lived role is that the
role carrier has to adapt to the expectations of the role senders in order to be effective
and credible. So, while position and role describe WHAT a job holder has to do, the
lived role of the role carrier describes HOW this is done, i.e. performed.
The Authenticity Hype

Much has been said and written about (leadership) success depending on being
authentic. We would thus be legitimised or even called upon to simply behave in
every situation in a way that would suit us personally. This clearly contradicts the
above statements, which aim to create a sense reliability through the predictable
behaviour of role carriers. Rolf Dobelli also advises us to not go along with the
authenticity hype at work: “Authenticity has its rightful place within a life partner-
ship or a very close friendship, but not vis-à-vis casual acquaintances and certainly
not vis-à-vis the public”. Work is about respect, not love. We respect the people who
keep their promises, whose behaviour towards us we can predict.
5.3.3 The Role as a Link Between Organisation and Person
The Role Lived Depends on the Context

The clown behaves differently at a children’s birthday party than in a cinema film. In
the role of a friend, we behave differently in an intimate setting when there are just
two people present than when there are more than two people around.
The role lived by the role carrier is strongly dependent on the context. Role
carriers usually adapt to the context subconsciously. Without effectively noticing it,
we behave differently depending on the situation and thereby try to meet the
expectations of people involved, the role senders.
Example
In one organisation, a project manager needs to be able to be firm with his project
owner, be entrepreneurial and, in the event of delays, also be able to put pressure
on the line managers who are supposed to release the resources.
In another organisation, exactly this kind of behaviour would be an affront:
Here, the “project manager” is expected to act as a kind of jack-of-all-trades, the
one to ask whatever the issue, but he is in no way to influence the decision-
making powers of superiors.
The scrum master facilitating a sprint retrospective with a scrum team that has
never worked in an agile way before has to intervene more strongly and also be
more patient than when working with a scrum team that has already completed
several projects in the same constellation. ◄
Of course, we are limited in the way we live a role. We cannot take on every role
because we cannot simply disconnect our thinking, feeling, and acting from our
person with our values, abilities, imprints, or character traits.
The Lived Role Is Visible in the Contact Between Role Carrier and Role Sender
Successful project work is based on clearly defined and agreed roles. The role
carriers have to meet the expectations of the other role senders. These role senders
372 5 Teams
Fig. 5.3 Lived role as interface between person and organisation
are part of a surrounding organisational structure and culture, which in turn

influences their expectations. All this creates the context in which the contact
between role carrier and role sender takes place, as shown in the upper part of
Fig. 5.3. It is in this interface that the lived role of the role carrier emerges. This
interface has a high potential for conflict: the greater the discrepancies, the more
likely it becomes for role conflicts to occur (Sect. 5.6.6.4).
Role Adoption
The better the roles are defined, the better the interaction within the team and the less
likely it is that role conflicts will happen. This process of consciously shaping a lived
role is called role adoption (Steiger & Lippmann, 2008, p. 49 ff).
In every organisation, the role senders and also the role carriers have specific
expectations concerning how a project manager or a scrum master should behave in
specific situations. In contrast to the positions and roles, however, this role adoption
is often not explicitly defined, but is shaped by the role understanding anchored
consciously or subconsciously in the organisational culture or by role expectations.
A successful and thus consciously designed role adoption is based on the

following three measures:
Define role: Based on position and role, the first step is to define how a role should
be performed and thus what the expectations of the role sender and the role
carrier are.
Example
The scrum master with a project team of agile novices must be able to clarify for
himself, but also for his stakeholders such as the direct supervisor or the project
owner, to what extent he can and should support the team in its process. ◄
Design the role: Now that the role has been filled, the contact between the scrum
master as the role carrier and the team as the role sender gets shaped by how strongly
the framework conditions are being influenced by the organisation or the managers
of the line organisation. The organisation has a supportive effect, but it can also
create obstacles, such as providing suboptimal tools or team members insufficiently
released from other duties for the project.
Example
The scrum master identifies more or less with the project and its goals, which also
depends on how many other projects he is supervising simultaneously and to
what degree he considers the framework conditions to be optimal. He contributes
his experience and skills, but also his obstacles and limitations. ◄
Asserting a role: Sooner or later we all fall out of a role, no matter how well
defined and designed. This may, for instance, be due to the team development
process (Sect. 5.2), because of a role conflict or because of stress, by which those
concerned as well as the organisational representatives involved are challenged in
this situation to enforce the acting out of respective roles again and again.
Example
The scrum master ought not to start to influence the self-organisation of the
developers. The product owner has to be able to live with the decisions that the
developers make during a sprint. The scrum team, on the other hand, needs to be
able to live with the fact that the product owner does not accept the results of a
sprint as long as the goals have not been 100% achieved. ◄
Defining, shaping and asserting roles is an on-going process that needs constant
attention according to team dynamics. According to the principle of “disturbances
have priority” (Sect. 5.6.11.2), it is important to recognise boundary violations
between the roles and thus possible points of friction at an early stage and to deal
with them on the basis of well-developed competences in personal communication.
If, for example, the scrum master influences the self-organisation of the developers,
it needs to be possible to communicate this to him in a constructive way. All those
374 5 Teams
involved have to therefore be able to give and receive feedback (Sect. 3.9.7) in order
to further develop the assumed roles according to the three steps outlined above. The
Belbin team roles approach (Sect. 5.4.3) or the RACI matrix (Sect. 2.3.8.9) is also
very helpful for this process.
5.4 Influencing Factors for Successful Cooperation
Projects cannot be mastered by individual efforts. Every project owner has to be able
to put together a team for his project that successfully masters the challenges
together. Therefore, it is important for those responsible for the project not to
leave team success to chance, but to know and use different influencing factors
that have a positive impact on teamwork.
5.4.1 Psychological Safety
Organisations today rely on talent, but there are many reasons why talent alone is not
enough. The only way human capacities can truly flourish is in an atmosphere free of fear
(Amy. C. Edmondson)
One of the essential characteristics of successful teams is psychological safety. In

psychologically safe teams:
• Employees feel a sense of safety when taking interpersonal risks and showing
vulnerability in front of each other.
• Thoughts, ideas, mistakes, and criticism can be shared without fear of negative
consequences.
• Sincerity and authenticity are central elements.
• Conflicts are dealt with constructively.
• We are not concerned with protecting our “image” (impression management), but
with delivering the best possible performance.
In psychologically insecure teams:
• We tend to remain silent rather than address difficult things.

• We make personal development and important innovation steps impossible for
ourselves and our colleagues through our silence.
• We are, at least subconsciously, so busy with our “impression management” that
we cannot contribute to the further development of the organisation.
For Amy C. Edmondson, enabling psychological safety is the central element for
successful companies. Edmondson (2018) impressively shows how building a
culture of fear harms large companies (e.g. the diesel scandal at VW, the collapse
of Wells Fargo, the downfall of Nokia).
5.4 Influencing Factors for Successful Cooperation 375
Psychology safety can be promoted in a targeted way in a project or in a company.

For a fear-free and inspiring project organisation, the following factors play a central
role in the management of the organisation:
• Create conditions in which the work is given a frame of reference and an

orientation towards meaningfulness is emphasised.
• Invite employees to speak up and participate. To do this, leaders should demon-
strate humility, practice proactive inquiry, and put in place facilitative structures
and processes.
• Establish continuous learning as an orientation. This is achieved through
expressing appreciation and freeing failure from stigma.
Giving the Work a Frame of Reference

By enabling project managers to see the bigger picture again and again, project
members can develop a more general understanding of what they are dealing with
and what goals they are striving for together. Regularly referring to the project
vision, the roadmap or even the overall benefit of the project is very helpful in this
regard.
Another important aspect in this area is dealing with failure (Sect. 3.8.5). A new
frame of reference for failure and a basis for “safe” failure has to be created. It makes
sense to discuss and formulate common expectations in the project team that have to
do with failure, uncertainty, and interdependence. Failure is a feature of learning and
not a mistake. A distinction can be made between the following types of failure
(Table 5.3):
Intelligent failure should be valued. Project employees ought to be encouraged to
learn from it and make more such mistakes. Intelligent failure is a thoughtful foray
into new territory and can move the project forward on key issues. On the other hand,
avoidable failure and, if possible, complex failure should not be sought out.
Table 5.3 Archetypes of failure (Edmondson, 2018)

Avoidable failure Complex failure Intelligent failure
Deviation from existing Unique and new combination of Novel approaches in
specifications. The several influencing factors lead unfamiliar territory that
knowledge is potentially in to an undesired result lead to undesirable results
place
Deficits in behaviour, skill, Complexity, variability, new Uncertainty,
and attention factors imposed on familiar experimentation, risk-
situations taking
Process deviation System malfunction Unsuccessful attempt
Educate, train Analysis of the influencing Celebrate & reward failure
Expand guides factors Formulate new hypotheses
Sanction Identify risk factors Learning from failure
Further development of the
system
376 5 Teams
As project managers, it is important to explain why it is necessary for members of

the team to speak out. In the project team we need to talk about and share uncer-
tainty, interdependencies and what is at stake. All these points have implications for
failure. The project manager can support this by:
• Setting the direction through the vision (why?)

• Launching a discussion to clarify and, if necessary, adjust the direction.
• Creating the conditions for continuous learning.
• Inviting team members to participate, share important knowledge and valuable
insights.
Active Participation and Invitation to Participate

• No one is going to take an interpersonal risk if the project manager thinks he
knows everything and cannot make any mistakes. For the project manager, it is
essential that he succeeds in inviting participation in an inspiring and honest way.
With situational humility, the project manager admits his own weaknesses and
points out his limitations. This is achieved through an open and curious attitude.
As a project manager, I can always learn something new and develop myself
further.
• By listening intensively and asking good questions, the project manager practices
proactive inquiry. This is achieved by asking open and systemic questions and
formulating I-messages instead of you-messages (Sect. 3.9.6).
• Relationships can only develop through shared experiences. For this, structures
and processes have to be introduced. Regular exchange within the team, bilateral
meetings and structures for processing input help. This also includes common
rules on how to discuss and deal with each other in the team.
Respond Productively and Enable Learning

To create an atmosphere of psychological safety, the project manager should be
present and react quickly and productively. He does this by expressing appreciation
and showing appreciation. Any personal opinion expressed should be appreciated
and in difficult circumstances efforts (not results) should be shown recognition.
Constructive feedback helps in the further development of people. Gratitude towards
project employees also helps to increase appreciation.
Continuous learning as an orientation. For this to work, failure needs to be freed
from stigma. Through mistakes and through failure we can come to a deeper
understanding of complexity and interdependencies. Failure is a natural
by-product of experimentation. The project manager offers help, looks ahead
together with the team and together the next steps are then defined. Effective
performers produce intelligent failure, learn from it, and share its lessons with others.
Avoidable failure as a result of deliberate process deviations have to be sanc-
tioned as a violation. Clear rules delineate what the limits are.
5.4.2 Positive Psychology and What Distinguishes High

Performance Teams from Others
Google Project Aristotle

In the Aristotle project, Google investigated what makes teams successful. The
following success factors were identified:
• Psychological safety: Team members feel safe with each other, dare to take risks,
and show feeling vulnerable in front of each other.
• Reliability: Tasks are completed on time and meet high quality standards.
• Structure and clarity: Team members have clear roles, plans, and goals.
• Meaning: The work is personally meaningful to the team members and they
experience themselves as being competent in engaging in it.
• Impact: Team members think their work is important and makes a difference.
Positive Psychology
As with Amy Edmondson, psychological safety is also an important factor in
Google’s findings and the basis for successful teamwork. Martin Seligman, the
founder of positive psychology, has also identified similar factors. In his PERMA
model he describes the five pillars of positive psychology and personal well-being
(2012):
• Positive Emotions: gratitude, being self-driven.

• Engagement (commitment): Flow, using one’s own strengths.
• Positive relationships: being active and constructive.
• Meaning: transcending the «I».
• Accomplishment (success and achievement of goals): experiencing one’s own
competence.
If we configure these five pillars optimally in ourselves and in the team, then we
become able to flourish and to create the preconditions for top performance.
Positive Leadership
The central elements of positive leadership according to Ruth Seliger (2014) are:
• Confidence: Focus on and appreciation of strengths, resources, and potentials.

• Influence: Involvement (involving project employees in decisions) and empow-
erment (handing over responsibilities to project employees).
• Making Sense: Motifs from the past, the big picture in the current moment and a
specific vision for the future.
These principles serve to generate high positive organisational energy. High

energy is central to the success of a project. Then the project management has the
task of ensuring that:
378 5 Teams
• The project can build up enough energy and mobilise it again and again.
• The project energy flows well and that there is always enough of it, in other
words: that all parts and all environments of the project are well supplied with
energy, that there are no congestions or energy holes.
• The available energy is used effectively, too, and does not, for instance, go to
waste.
These three principles of “positive leadership” permeate the practice and process
of leadership, laying the foundation for a positive and creative mood as well as for
professional teamwork.
High-Performance Teams
The different approaches have a high degree of overlap and complement each other
in an ideal way. If these success factors can be shaped positively, then nothing stands
in the way of a maximum performance by the project team and the project manager.
5.4.3 Belbin Team Roles
In Sect. 5.3.2 it is explained how important clearly defined and agreed-upon roles are
for project work. This definition process can be advantageously supported by the
Belbin team roles. In Sect. 5.4.3 the concept is introduced in principle. The following
section is about using it as a success factor for cooperation.
Unsuccessful Teams: Imbalance in Team Roles

In Belbin’s management games, it might have been expected that the teams com-
posed of people with the highest intellect would also perform best. But this was not
confirmed in the experiment. The teams with the highest individual intellect were not
able to realise their potential and were plagued by role conflict.
Successful Teams: Optimal Balance of Team Roles

According to Belbin, the most successful teams are those that are optimally balanced
in team roles: It would be a great loss for the team if a strong shaper no longer
contributed his qualities for fear of hurting other people. It is much better if this
strong shaper gets the support of a strong team worker who is committed to a good
team atmosphere and to whom the well-being of the team is an important concern.
This team worker has very high communicative competencies and is thus able to
listen and mediate well. No project team can do without the talents of the resource
investigator either. His contributions to networking and communication are
all-important. But he also needs an implementer who can really concretise the
ideas and possibilities, as well as a completer finisher, someone who can reliably
and conscientiously take on tasks of high complexity. It is therefore the combination
of the different behavioural clusters (team roles) that allows individuals to contribute
with their strengths, while at the same time ensuring that their respective weaknesses
are compensated for by the strengths of another team role.
Belbin Team Report

In order to descriptively capture these characteristics in the entire project team per
team role, the individual team roles are summarised in a team report. In Fig. 5.4 the
different employees are assigned to their most noticeable team roles. In relation to
the competence groups, this means:
• Accomplish (shaper, completer finisher, implementer): Well represented.

• Think (specialist, plant, monitor evaluator): Well represented.
• Communicate (team worker, co-ordinator, resource investigator): Not
represented.
The project manager who looks through this team report can in that moment
immediately recognise the current weaknesses of the team in the areas of internal and
external communication, stakeholder management, conflict management, or even
coordination among team members who are most likely to be neglected.
Blind Spot in the Team

As with every human being, every team has a blind spot (Sect. 3.9.7.2). This is often
due to the fact that like attracts like: When it comes to putting together a team,
relationship and sympathy with others play an important role. If you are a strong
shaper or a pronounced completer finisher, you usually have more sympathy for your
New Empl. Empl. 4
Empl. 3
Empl. 2
Empl. 1
Empl. = Employee
Fig. 5.4 Belbin competence groups (Belbin Deutschland e.K.)

380 5 Teams
peers than for the contrary personality type. If the project manager is a shaper, it is
highly likely that he will intuitively bring people into his team who match his values
and competences. These will most likely belong to the “get things done” competence
group. For a shaper, meetings or customer visits are often a waste of time. Action is
of primary importance to him, while reflection for balanced approaches to solutions
(thinking) or well-coordinated communication is relegated more to the background.
This creates a team that is unbalanced in its team roles.
What the team is usually not aware of becomes clear to someone from the outside
relatively quickly, namely when he looks at how the cooperation is going, what work
is being tackled with what priority, and what behaviour is being rewarded or
sanctioned in the team. Thus, every team also has a blind spot that it needs to be
alerted to.
Instinctive Complementation of Team Roles

If by chance a strong team worker were to join the team, what would happen to this
person (New Empl. in Fig. 5.4)? This person would probably have a hard time
because he does not match the self-image of those competence groups who are
“getting things done” whilst “thinking”. There is a danger that this person will
become the group’s scapegoat because his being-different threatens the current
structure of the group. So, if this person wants to have a discussion about a conflict
situation or would like to clarify the rules of cooperation, as is also done in the
“norming” phase (Sect. 5.2.3), then there is a possibility that their needs will not be
taken seriously citing reasons such as: “we don’t have time for that”, “we have to
move forward, not chat”.
Conscious Complementation of Team Roles

The situation would be completely different if the project manager or the team were
aware that of a strong imbalance in the team roles and were to actively look for a
person to cover the unused competence group. It would be clear to the participants as
well as to the new person from the beginning that he is an outsider and that, precisely
because of this difference, he has a very important contribution to make for the team.
It is clear to everyone that this individual will initially cause irritation or even meet
with resistance. But they will deal with it in a completely different way than if the
team role had been added to the team without being much noticed.
Communication, Conflict Management, and Negotiations

In these explanations it ought to become clear that the high ideal of balanced team
roles in a project can only be achieved if their side effects are consciously integrated:
If you fill all team roles, you will have to deal with people having very different
character traits, values, and expectations. This will inevitably lead to differing
convictions, which in turn means: intense debates, disputes, and also conflicts.
A successful, efficient team cannot be a “feel-good oasis”. Rather, it is precisely
the aforementioned debates, disputes, and conflicts that constantly create a new
balance between the positive and negative characteristics of the different team
roles. In order for this to be possible, the relationship level in the cooperation should
be well developed. This means: there have to be high competences of the people
involved in the area of personal communication (Sect. 3.9), role clarification (Sect.
5.3.2), negotiation (Sect. 4.10), and conflict management (Sect. 5.6).
5.4.4 Radical Collaboration
In project work, effective teamwork is increasingly becoming the all-important

utility, and that is because technical problems and the corresponding exchange of
information can be solved. Especially in time-critical projects, hierarchy and
competition-free forms of cooperation are necessary. The basis for this are collabo-
ration cultures with trust-based working relationships, as well as high prevalence of
role flexibility among individuals working in the project, departments, or
organisations. New team constellations thus become quickly to enable, according
to the requirements. What counts above all is the efficiency, productivity, innovative
strength, and the agility of the team. The radical collaboration method is the best way
to achieve a balance in these ever-changing situations. The principle of this approach
is illustrated in Fig. 5.5. The question is what the team members orient themselves
towards: Do they have their own needs in mind or are they interested in optimising
the needs of the whole group? Those who orient themselves only as befitting their
own needs stay in the “red zone”. “This shows that, from a team perspective, this
behaviour is not goal-oriented. The opposite would be to subordinate one’s own
needs to those of colleagues. While this has a calming effect on the group, it may
lead to the subordinate person not positively supporting the group with their ideas
and skills. Therefore, it is not effective and is referred to as the “pink zone”.” (for
many speakers of English this denotes a no parking zone). The optimum is achieved
when the team members succeed in orienting themselves to their own needs and
those of others, and in supporting common success by challenging and encouraging
themselves and others (“Green zone”).
However, this realisation often means redefining essential previous objectives of
one’s own success, i.e. also reinterpreting strengths and attributes previously con-
sidered as strong and independent. It requires a different way of thinking and a
corresponding attitude. Radical collaboration thus requires a different mindset.
Table 5.4 contrasts the behaviour of the “red zone” and the “green zone”.
The radical collaboration approach originated in California in the 1980s and was
initiated by the judge Jim Tamm. Today, Bosch, Toyota, Nasa, and many other
international companies are realigning parts of their organisations along these lines.
Especially areas where innovation, technical developments and customer
requirements are to be realised collectively and across departments. Team structures
are primarily based on the tasks and competencies of the team members and not, as
in the past, on organisational structures and hierarchies. The approach is based on
five central core competencies (Tamm & Luyet, 2005):
382 5 Teams
Orientation to the needs of the other Subordination
Green
Zone
Pink
Zone
Red
Zone
Orientation to my needs
Fig. 5.5 Typology of individual behaviour in teams (Derived from an idea from www.euforia.org,
2018)
Table 5.4 Transformation of the mindset

Red zone behaviour Green zone behaviour
Away from . . . Towards . . .
• Winning • Success
• Hedging • Growth
• Not losing • Connections
• Fighting for posture • Being sincere and frank
• Being right • Collaborating
• Not making a fool of oneself • Practicing mindfulness
• Avoiding risk • Taking risks
• Extrinsic motivation • Having intrinsic motivation
• Seeing work as tedious, unpleasant • Seeing work is pleasant, enjoyable
1. Collaborative intention: Personal success is not the maxim. The focus is on

shared benefits and cooperative success.
2. Sincerity: Building an honest and open relationship in which the individual feels
safe enough to address difficult issues.
3. Self-responsibility: for one’s own actions.
4. Self-awareness: Knowing oneself and others well enough to classify difficult,
interpersonal problems and to solve problems, also in new constellations.
5. Problem solving and negotiation: Negotiating upcoming conflicts and working

out individual interests. Being able to act strong and reinforced through having
clarified relationships.
Radical collaboration therefore describes only the basic team and leadership
requirements that are necessary for the concept of collegial leadership and self-
organisation in the agile approach to work. Of course, radical collaboration can also
make a valuable contribution to traditional project management.
5.4.5 Multicultural Cooperation
Globalisation Demands Multicultural Project Teams

Today multicultural project teams are the rule and no longer the exception. In this
working situation, different cultural influences are likely to collide (Sect. 3.4), which
places additional demands on the design of the relationship in a cooperation (Sect.
1.5). In every contact we experience similarities and differences, be it in terms of
verbal or non-verbal communication, in our behaviour in conflict situations or under
stress, or in problem-solving strategies.
Due to our own cultural imprint, our value system and our view of human nature
and of the world, we generate conscious and unconscious expectations having to do
with our environment and our fellow human beings. Confronted with a difference in
behaviour to what we would expect, we react with irritation, which is exactly what
happens in multicultural cooperation. Here we are confronted again and again with
behaviour patterns in other people that are unusual and unexpected for us.
Of course, not only the project teams are multicultural, but also the markets and
the customers. Very few companies can still thrive off a monocultural customer base.
The aim has to be able to be successful in interregional or international markets and
therefore also in different cultures. Project organisations that are not capable of
constructive multicultural cooperation will not be able to participate in the increas-
ingly networked markets in the medium and long term. Thus, multicultural coopera-
tion ought not to be seen as an obstacle or a source of problems, but as an absolute
prerequisite for future success.
Monochronic and Polychronic Organisational Cultures

Organisational cultures can be differentiated using various categories. One approach
is to distinguish between planning and organisational styles. At the extreme ends,
these may tend to be shaped according to monochronic or polychronic criteria.
Table 5.5 contrasts the two approaches (Zaninelli, 2005).
Of course, these are extremes of the monochronic and polychronic expressions.
But the differences, depending on their characteristics, have a significant influence
on cooperation. Central and Northern Europe and the Anglo-Saxon cultures tend to
favour the monochronic planning and organisational style. The Romanic, Hispanic
and, as a tendency, the Russian and Arabic cultural areas, on the other hand, are more
influenced by the polychronic style of working.
384 5 Teams
Table 5.5 Monochronic and polychronic planning styles

Monochron Polychron
Prefers to do one thing at a time Feels good to work on several projects at the
same time
Is focused on accurate planning, avoids Is good at improvising, lives with constant
interruptions interruptions
Believes in facts and figures Juggles with facts and figures
Punctuality and deadlines are taken seriously Punctuality and deadlines are handled flexibly
Rules are observed Rules are circumvented
Matter before relationship Relationship before matter
Example
What do these differences mean for project work? The more polychronic the
members of a project organisation are, the more important it is to invest in the
development of the relationship level or to leave room for future development.
Polychronic does not mean that the work content is not relevant. Rather, it means
that a relationship and a level of trust need to first be developed before the matter
can be addressed. Whereas the monochronic culture sees a benefit in rules and
observes them, the polychronic approach tends to leave them aside. Punctuality at
meetings and keeping appointments can cause controversy: Monochronically,
these are taken seriously; polychronically, they are more likely to be observed as a
point of reference. ◄
In Fig. 5.6 the differences between the two planning styles are shown graphically.
The monochronic culture is characterised by a structured, sequential approach. In
contrast to this, the polychronic organisational form is much more “agile” and
always adapts its approach to the current situation. This representation can be easily
related to the mechanistic and systemic world view (Sect. 1.6.2): Monochronic is
more mechanistic and oriented towards “truth”, while polychronic is more systemic
and oriented towards constructed “reality”.
Chances and Dangers of Monochronic and Polychronic Organisational

Cultures
Most of us feel more comfortable with one or the other of these expressions. And this
is probably also connected with a corresponding conviction as to which form is
better. As explained above both different cultures are associated with certain large
geographical areas and economic regions. All internationally oriented companies
ought to at least be able to deal with their customers coming from various different
cultures. Often, in order to be truly successful, they will have to even internalise the
cultural characteristics of a target market, or at least in part. This means that it is not
possible to remain in an “either-or” situation, but rather to develop a “one as well as
the other” approach; both contain opportunities and dangers, as Table 5.6 shows
(Zaninelli, 2005).
Monochronic Polychronic
Goal Goal
3.
2.
1.
Start Start
Truth Reality
Fig. 5.6 Monochronic and polychronic culture
Table 5.6 Opportunities and threats of monochronic and polychronic organisational cultures
Monochronic Polychronic
Opportunities Reliable in terms of facts Reliable in terms of relationships
Smooth processes Flexible adjustment to changing
conditions and disruptive factors
Good at creating and implementing Good at performing under unexpected
plans circumstances
Dangers Little contact with a reality that Can be chaotic due to constant inclusion
may be changing of changing circumstances
Rigid and inflexible in the extreme Projects can get bogged down
Can lead to neglect of the Time and deadlines difficult to calculate
relationship level
Attitude and Mindset

For groups or people dealing with extremes, these different expressions also contain
significant potential for conflict. In order that cooperation might be successful, all the
people involved have to develop a basically open attitude towards other cultures,
allowing for appreciation to be shown even in the face of unusual behaviour. This is
386 5 Teams
Table 5.7 Dealing with Consistency , Innovation

polarities
Discipline , Creativity
Control , Trust
Work in the system , Work on the system
Knowledge creation , Value creation
Independent conclusions , Empirical evaluation
Acting quickly , Thorough analysis
Mechanistic world view , Systemic world view
made possible whenever a distinction is made in communication between effect and

value. Those who see verbal or non-verbal signals as an assessment directed at them
or of a situation having to do with them quickly feel attacked or hurt, which can then
escalate into conflict. This is why multicultural project teams also need high
competences in conflict management.
Finally, the people involved need to also be able to develop their thinking,
shifting it from an attitude of “either-or” to one of “as well as”. The complexity
and dynamics in which project teams move no longer allow the work to be managed
with rigid thought patterns, norms, and guidelines. Instead, project teams should
learn to manoeuvre between polarities and opposites, as shown in Table 5.7 is
illustrated.
There are project situations in which creativity and trust have to be the absolute
focus. Later, discipline and control can stay in the foreground in the same project. At
one time the focus is on value creation, at another time on knowledge creation.
Sometimes decisions are based on empirical evaluations and in another situation
independent conclusions are to be drawn. The value square (Sect. 5.6.10.8) also
provides good approaches on how to deal with polarities.
Reflected Personal Perception

In multicultural cooperation, differences in individual expectations always become
apparent. This requires a high degree of self-reflection on the part of those involved.
Those concerned with the project have to always be aware of the fact that personal
perception is selective and based on an individual evaluation of circumstances. How-
ever, it is also important to be conscious of the external impact of personal actions
(Sect. 3.10.2). Those who have been sensitised to their external impact are able to learn
step by step to adapt their behaviour as flexibly as possible to the given situation.
Cultural Knowledge
The project manager needs a basic understanding of the culture he is or will be
confronted with. It is all about being aware of the expected gestures as well as the
meanings of customs and observances, of preventing taboos and also being informed
about religious framework conditions. This requires curiosity and openness when
confronting something unknown.
Language and Communication Skills

English has established itself as the working language used in most multicultural
project teams. However, this is often the mother tongue for only a few of the
participants, sometimes even for none of them. If one or more team members cannot
express themselves in their mother tongue, what is needed above all is a high degree
of reciprocal tolerance in verbal communication. Those who put every word onto a
scale will have a difficult time. It is much more a matter of all people being aware of
the error-prone nature of the communication process, from coding to decoding. The
best tool when aiming to avoid irritations and misunderstandings is active listening
in direct conversation and, of course, giving regular feedback.
Leadership Competence
In traditional project management, an awareness of which specific leadership styles
are applicable in a particular culture is needed. In the agile approach, on the other
hand, it is essential to be sensitised to how different people can be introduced to self-
organisation. These competences help across many problem situations in a multicul-
tural project team.
Example
• How can I convince?

• How do I plan meetings in terms of expectations, preparation, agenda, leader-
ship, consensus building, punctuality, or language?
• Who is involved and what about aspects such as work ethics, qualifications,
and networking in the other culture? ◄
Negotiation
Especially in many different regions of Asia, very different laws apply in how one
conducts negotiation talks. The methods of decision-making are sometimes fairly
unfamiliar to Western Europeans. An overly direct approach can quickly lead to a
loss of face. Those responsible for a project need to know exactly which negotiation
methods can be used and when, which entry or conclusion is promising and who it is
that ought to generally chair meetings. Read more at Sect. 4.10.
Example
The Western style of communication is characterised more by directness, “getting

to the point”, taking a clear stand, being predominantly verbal. The Asian
communication style is more subtle, circular, illuminating the context, mainly
non-verbal. Western cultures usually still have their prejudices here and interpret:
We are direct, open, honest, the others talk around the bush. Through this positive
interpretation, however, Asians are in line with the trend: their communication
style is now recommended to modern management. This difference has to be
made transparent in a project team. If this succeeds, a therein well-prepared team
is able to work on more complex problems than a team that represents only one
cultural group. ◄
388 5 Teams
In multicultural project teams, it is therefore more important to not only work

together online. The full benefit of these resources can only be realised through
occasional “face-to-face” sequences. Especially at the start of a project, a “physical”
encounter is almost indispensable.
5.4.6 Organisational Constellations
With organisational constellations, hidden mechanisms of action, hidden

relationships, systemic background dynamics, or unrecognised patterns can be
made visible in a simple and efficient way. Valuable impulses and insights for
organisational, team and personnel development in projects can be gained from
organisational constellations. It is recommended that the project manager is
supported by a coach for organisational constellations.
What Is an Organisational Constellation?

Organisational constellations offer a new and different approach, characterised by a
mindset that focuses on solutions. In addition to this, systemic connections are taken
into account and business and working relationships are included, too. This way of
arriving at results also breaks new ground. With spatial and visual impressions as
well as linguistic and physical forms of expression, a more complex picture emerges.
Through organisational constellations, complex relationships are made visible,
understandable, and explained. This helps to improve people’s relationships in
organisations and makes it easier to change the attitudes of individuals.
Organisational constellations are also a valuable support when it comes to improving
cooperation between people from different cultures. For example, through this form
of constellation, conflicts between organisational units or project teams in different
countries can be re-enacted, and thus the behavioural dynamics at work can be
understood at a deeper level of consciousness. The so-called gut feeling, the intuitive
perception or the “inner knowledge”, can be supported by translating it into visible
images on the outside. On this basis, managers and project managers can attain a
higher level of certainty for their decisions and effectively check their underlying
attitudes (Klein & Limberg-Strohmaier, 2012, p. 40).
What Happens in an Organisational Constellation?

“In system constellations, aspects of a complex situation are presented in space with the
help of representatives, in a kind of role play. This leads to clarification in two ways: on
the one hand, the situation is visualised, staged, and on the other hand, creative solution
options can be successively worked out” (Rosselet & Senoner, 2010, p. 20).
The representatives serve as a sounding board for tacit knowledge. Underlying
knowledge, though it exists, is not readily accessible to conscious reflection. The
selected representatives are, to their advantage, in no close relationship to the person
constellating and the topic of the system constellation. This ensures that these
persons approach the constellation in an unbiased way. A constellation is usually
supported by a group of 5–15 people. If the hidden mechanisms of action in a team
are to be visualised for the whole team, it is also possible to work directly with those
affected within the team.
Procedure of an Organisational Constellation

Say, for instance, a product owner, scrum master, project manager, or other decision-
maker has a question, a goal or a topic that they would like to look at in depth and
gain new insights into for possible areas of action. For example, it might be that a
project manager wants to analyse the dynamics of his project team and find out the
reasons for an underlying conflict.
Then, in a first step, the constellation facilitator will discuss the goal of the
constellation and the questions derived from it with the project manager. Together
with the project manager, he will then determine the representatives for the constel-
lation. The project manager thereupon intuitively chooses the representatives from a
group of people and places them in the room according to his gut feeling. This
visualises the relationship structures of the project team. The initial image usually
reflects the current situation of the project team. First conclusions can already be
drawn from this. The constellation facilitator will at that stage bring about targeted
interventions, e.g. he might rearrange representatives or bring further elements
(representatives) into the constellation. During each intervention, the constellation
facilitator, representatives, and project manager observe how the intervention affects
the constellated system and what changes become visible. From these findings,
development potentials and solution paths can be identified. In this way, it becomes
possible to visualise hidden or concealed issues that would otherwise remain hidden.
An organisational constellation takes one to one and a half hours. The system
constellation process is effective, fast, and unconventional. For a product owner, a
scrum master, or a project manager, it is advisable to call in an external constellation
facilitator for an organisational constellation who is not part of the system under
consideration.
Possible Applications of Organisational Constellations in the Project

Environment
There are many possible applications for organisational constellations in the project
environment (based on Weber: Basics of Constellations of Organisations and Work-
ing Relationships, Fundamentals and Procedures in Weber and Rosselet (2016),
Organisational Constellations—Fundamentals, Settings, Fields of Application):
• Make structural “clamps” visible and analyse them.

– Structural contradictions in the project or line organisation.
– Unclear organisational structures, e.g. inappropriate allocation of competence
and areas of responsibility.
– Unclear role assignments and role descriptions.
– Making hidden stakeholder interests and claims visible.
– In case of poor communication and coordination.
• Prepare and accompany measures (analysis and trial action).
390 5 Teams
– Goal-setting processes, orientation of the project.

– Anticipating the impact of possible actions in the development of
organisations, teams, project groups, etc.
– Preparation of negotiations.
• Prepare personnel decisions and personnel development.
– Personnel selection.
– Filling key positions in the project.
– Within the framework of personnel development measures.
– How does someone in the project organisation come into a position of power.
• Review leadership quality and behaviour.
– Adequate staffing and adequate filling of management functions in the project.
• Generating meaningful hypotheses and promoting solutions for conflictual
relationships.
– Causes and ways of resolving conflicts.
– Lack of respect and appreciation.
– Coalition building and triangulation.
– Context mixing between private and business sphere.
– Assumed behaviour and denial.
– Places not taken, project roles not taken up, internal resignation, tendency to
withdraw.
– Exclusion, bullying dynamics.
• Project culture and working atmosphere.
– The energy level of the project.
– (De)motivation, boycotts
– Community spirit, cohesion.
– Backgrounds and correlations for persistent staff turnover or high sickness
rates.
• Gaining information about lack of backing and support.
• Align project organisations (employees) with tasks, goals, and customers.
• Support in decision-making.
These and other possible applications naturally also apply outside of project work
in all questions of organisational and personnel development.
5.5 Change and Resistance
Almost every project inevitably leads to minor or major changes within the line
organisation. Change project management includes all projects that aim at radical,
comprehensive, and interdepartmental changes in the organisation. This could have
to do with the introduction of new processes or products, mergers, implementation of
new strategies, etc. Such changes always require adjustments for the people
involved, adjustments in their activities, behaviours, and cultures
(e.g. communication culture, error culture) and even in their attitudes.
5.5 Change and Resistance 391
5.5.1 Change and Transformation
A change can have different causes. Illustrated by a general business model in

Fig. 5.7 for example, the impetus can come from changes in strategy, corrections
and adjustments in structures and processes, or the need to develop the
organisational culture. Wherever the initial impulse is set, there is always going to
be an impact on the other two dimensions of the business model.
5.5.1.1 Change: Solving Problems

We speak of “change” when the current situation needs to be altered: Processes and
methods have to be improved or replaced to meet current or future requirements.
Example
• The production costs are too high. New production processes are to be found
in order to reduce costs by which means a higher contribution margin then
becomes possible.
• The effort estimates for the projects were repeatedly too low by 20%. The
reference values of the analogue estimation method ought to be reviewed. In
addition to this, for projects with a high degree of complexity, the planning
poker (Sect. 2.4.6.2) is to be introduced. ◄
Strategy
Management
Structure Culture
Fig. 5.7 Change in strategy, structure, and culture

392 5 Teams
5.5.1.2 Transformation: Finding Solutions

We speak of “transformation” when new strategies are to be developed on the basis
of a vision or future requirements.
Example
• Our products should be able to be produced largely by means of robots. Which

processes, structures, and procedures need to be used in order to be able to
switch for the most part to automation?
• An organisation wants to work more following the agile approach. A project
for organisational development is started, based on “Radical Collaboration”
(Sect. 5.4.4). This is done in order to lay the foundation for self-organisation in
the agile teams. ◄
5.5.2 Mind Change
Changes to Strategy and Structure Influence Culture

The business model in Fig. 5.7 suggests that any change in strategy or structure has
an impact on the culture and therefore on the individuals in particular and the
organisation as a whole. In many projects, benefits and profitability only become
apparent the moment the people involved adjust their behaviour, be it for instance
innovative technological solutions, to more effective processes or new products.
Targeted project activities and appropriate project management are necessary so
that those affected can change their behaviour. The need for this to happen becomes
increasingly pressing as change times become shorter and shorter. The on-going,
coordinated measures to bring this about are called change management. It is not
only change projects that involve change. It is more encompassing and affects all
projects on a larger or smaller scale.
Two Levels of Change

Figure 5.8 shows the two levels of change. At the level of the “hard factors”, new
structures, processes, or systems are developed in change or transformation. The
management and control of this physical process are referred to as management and
controlling. Equally important are the psychological and spiritual changes. Here the
focus is on the “soft factors”, which are used to develop the culture, skills, and
behaviour of the individuals and the organisation. Leadership and communication
skills are required for this part of project management.
5.5.3 The Human Being and Change
Do you change? How do you personally feel about aspects of change in your
private life? Most of us are probably not happy with life around us permanently
hard factors structures

systems
Physical change
processes
is controlled by:
– Management
– Controlling
Change / Transformation
redeployed inherent logic
vision
strategy success
organisation
change
Mind Change
psycho logic
Psychic change is
controlled by:
– Leadership
culture – Communication
skills
soft factors behaviour
Fig. 5.8 Two levels of change
changing. Why is that? First of all, we have acquired all of the knowledge, learnt all
the procedures and skills we need to go through our lives. Acquiring something new
is a demanding process that requires a lot of effort and energy. What we had to learn
cognitively once with a lot of effort over time becomes the sum of our routines, our
implicit and intuitive behaviour patterns over the years. Calling up these patterns
costs us only little energy, as these are anchored in fixed neuronal networks in our
brain (Sect. 3.3.1). Since humans have had to learn to survive in a world of scarcity
for most of their evolution (for many, unfortunately, this is still the case today), our
brain has also developed an efficient “stand-by” mode: thus, our brain always tries to
keep its energy consumption as low as possible.
The familiar and stable has other advantages for us: we feel safe. As project
managers, we have acquired a lot of knowledge and experience over the years. We
have built up a reputation in the organisation or even in a specific sector, thereby
having created a valuable formal and informal network. Through all this, we can
consciously or instinctively meet our individually important basic personal needs
(Sect. 3.3.2).
Changes in our processes, tasks, or responsibilities for us imply having to let go of
security and even parts of our identity. Depending on the character traits of persons
with their basic needs, and their specific competences or personal resilience (Sect. 3.
8.4), everybody applies a different, personal coping strategy (Sect. 3.5.6). For many,
394 5 Teams
change also means uncertainty, sometimes even fear. Those who cannot overcome
this uncertainty or fear will cling to the status quo.
5.5.4 “Formula” of Change
Those who think that the change of people or organisations can be derived from a
simple formula would make it seem trivial (Sect. 1.6.3). Organisations and people
are much more complex. Nevertheless, a formula can be used as a supplement to the
change formula (Sect. 5.5.10):
In a change process the fear of learning and the fear of existence are opposites.
Learning anxiety means that people or organisations lack confidence in their ability
to build up the same competence anew. This “basement wandering” can result in
becoming temporarily inefficient or even to losing part of one’s identity, status, or
group membership. Existential anxiety includes the loss of livelihood: the loss of
market position or even the organisation’s ability to survive, the disintegration of a
team or, on a personal level, the loss of expertise, employment, or one’s health.
Which fear is the stronger in us? Even if many don’t want to hear it: It is the fear
of learning. Lifelong development and further learning of organisations and people
is very demanding, exhausting and also associated with an array of uncertainties and
risks. Existing habitual patterns, on the other hand, provide security. In most
organisations it takes a lot of energy to go through a sustainable change process.
Change has a high price and requires a significant commitment from all people
involved, requiring risk-taking abilities.
Example
Humans are very good at suppression. Many people try to live on for as long as
possible along the paths of familiar ways, be it organisations or individuals. These
familiar paths are only abandoned when things really don’t work out any more:
People fear to lose their jobs if they don’t familiarise themselves with a new
technology. Or they suffer so much stress that the psychosomatic symptoms can
no longer be ignored. Or maybe even an organisation is afraid of suffering a drop
in turnover due to the market entry of a competitor if it cannot achieve a surge in
innovation. ◄
In these situations, existential anxiety increases, often accompanied by a higher

stress level. The increased existential anxiety then causes the learning anxiety to
fade into the background. Suppression is no longer an option. On a personal level,
one’s own behaviour can be changed or the situation gets re-evaluated (Sect. 3.5.6).
Organisations initiate change through a new strategy or structure.
5.5.5 Readiness for Change in Organisations
People who connote change positively and turn to it with curiosity and pleasure are
the exception to the “formula” of change described above. Rogers distinguishes the
following user groups in change processes (Rogers, 2003):
Innovators
Visionary thinkers, these people are enthusiastic, sometimes also uncritical and
have a one-sided attitude towards innovations.
Early transferees
Having a positive attitude towards change, taking into account the pros and cons,
which is why they enjoy high acceptance in the organisations.
Early majority
Initially indifferent to change, these people participate, but without great enthusi-
asm. They get excited about quick successes, which mainly benefit these people
themselves (quick wins).
Late majority and latecomers
Getting them on board is difficult, as they tend to react with resignation or show
active resistance. If the group is too large, this can mean the failure of the change
process. Figure 5.9 shows, on the one hand, the percentage distribution of people
among the groups and also indicates when these groups enter the change process.
What does this mean for the design of change processes?
According to Rogers, there can also be too much enthusiasm for change
(innovators). Change needs to never be an end in itself. It should always be a
means to an end and directed towards specific goals. It should also be carefully
weighed in terms of risks and the human and financial resources it absorbs. It is a true
statement that it is never all of the people who are involved that will enthusiastically
embrace change. Change will always generate resistance. The majority wants to see
results first before they show support for the change process. To win them over, the
successes achieved by the change have to be quantified. The latecomers remain
sceptical. Not too much attention should be paid to this group.
5.5.6 Psychology and Factual Logic in Projects
For a differentiation of change on the two levels of factual logic (change or

transformation) and psychology (mind change), Table 5.8 compares a few focal
points and areas of competence.
396 5 Teams
early late
majority majority
Number of transferees
34% 34%
innovators
early
transferees latecomer
2.5% 13.5% 16%
Period
Fig. 5.9 Distribution of user groups (Rogers, 2003)
Table 5.8 Psychology and factual logic in projects

Factual logic Psychology
Scope, objective, and requirements Dealing with power and leadership
Strategies Coping with conflict and resistance
Milestones and sprint goals Development of the organisational culture
Costs and resources Motivation and meaning
Project priority (project portfolio) Personal communication
Project planning and execution Team development
Project organisation Perception and awareness
Problem-solving methodology Developing skills and attitude
5.5.7 Willingness to Shape and Cooperate
Essential prerequisites for a supported and effective change are having the full
identification and commitment of the management. Many change projects fail
because commitment from the top is missing and the necessity of the changes is
not repeatedly communicated and confirmed. When management is actively
involved in the change process, it exemplifies the shared learning process. The
changes sought by the organisation are thus (more likely) to be adopted.
strong
high conflict high change
dynamics dynamics
Leadership‘s will to shape

Without credible,
broad-based change
work, only little moves
failure limited
preprogrammed change range
weak
weak strong
Willingness of the employee to cooperate
Fig. 5.10 Will to shape and cooperate
Figure 5.10 shows that the dynamics of change are highest when a high degree of
determination to shape things in the management organisation can be combined with
a strong willingness to cooperate on the part of the employees.
If the will to shape is strong, but the willingness to cooperate is weak, a high level
of conflict dynamics can be expected in project implementation. Employees without
the support of the company leadership can achieve little. If both sides show little
commitment, failure is pre-programmed.
5.5.8 Change Process Model
5.5.8.1 Phases of Change

Virginia Satir originally developed the “phases of change” model for family therapy.
Her model therefore also describes the development of people, groups, and
organisations in dealing with change through implementing five phases
(Fig. 5.11). These are worked through with varying degrees of readiness and with
different time restraints.
398 5 Teams
Existing balance New balance

“Social systems” tend
to maintain the status 5
quo for as long as
possible Confusion uncertainty
Chaos and chance
Only the positive experience
2 of this phase leads to a real
1
change 4
Introduce 3
something new Integrate the new
As soon as the first
success of the change
begins to emerge, the
new becomes more
attractive
Fig. 5.11 States in change processes (Satir et al., 1991)
Phase 1: Status Quo or Existing Balance

This phase (usually the starting position) of stable equilibrium and continuity
conveys security. A well-rehearsed routine gives people the feeling of being effi-
cient. In order not to endanger this equilibrium, a need for change is often avoided in
real life for as long as possible by wilfully looking away. The longer this phase lasts,
the more difficult it becomes for those affected to accept change.
Phase 2: Departure, Introduce Something New

In this phase, awareness grows that changes are necessary. Usually, it is only a small
circle, e.g. the management, that plans and initiates something new based on a
perceived need for change. A readiness for change has to be established in this
“thawing phase”.
Phase 3: Confusion, Uncertainty, Chaos, and Chance

When something new gets introduced, confusion at first arises. Often the employees
only see the change process in this phase. They have to jump onto a train that is
already moving and then try to cope with the change and try out the new with more
or less willingness. Most of the time, this is done using previously described
methods and behaviours but that are hardly suitable to meet new demands. Situations
arise in everyday life in which nothing works anymore because the tried and tested
no longer applies and the new is still unfamiliar or unknown.
As a result, chaos ensues, both for the people and for the whole organisation.
Only positive living through this phase leads to real change. However, this phase is
not allowed to last too long, because it is connected to feelings of fear, uncertainty,
and costly resistance. It is often not clear whether the old still applies or whether the
new already applies.
Phase 4: Integrate the New

People’s ability to approach phases of confusion and crisis positively despite all the
difficulties is a key factor in reaching phase 4. As soon as the first successes of the
change become apparent, the new becomes more attractive. An integration phase
occurs in which the new reality is practised and the new ways of behaving are tried
out until a sense of security gradually emerges again. The new state is then “frozen”
once again. Mistakes are also part of the learning process. These should be recorded
and reflected upon, but need not immediately lead to corrections of the taken path. If
the leaders do not succeed in dealing with mistakes in this tolerant way, they will
slide back into phase 3 instead of making progress.
Phase 5: Stability and New Balance

The integration phase is followed by the new equilibrium phase. This phase of
consolidation is important for deepening the experience and anchoring the newly
acquired knowledge and skills. In the VUCA world (Sect. 1.1.2), these phases
become increasingly shorter because they are caught up to or are overtaken by
further changes.
The five phases are not passed through linearly. With every major difficulty there
are relapses into the chaos phase. Fear and resignation then once more gain the upper
hand. Over time, however, both the number and the duration of these relapses
decrease. The process of change begins to take hold.
5.5.8.2 Non-simultaneity of Change

The phases of change occur in the organisation for certain groups in a kind of stagger
(Fig. 5.12), which means that not all people or hierarchical levels involved are in the
same phase at the same time. This can introduce additional dynamics to the project.
This non-simultaneity arises from the knowledge advantage of those responsible.
They have already been dealing with the change for a long time and have progressed
accordingly. Now they impatiently expect quick results and increase the tension
among the staff with their demands. This disparity places high demands on the
project management in particular.
5.5.9 Dealing with Resistance
5.5.9.1 Positive and Negative Connotation

There is no change without resistance. It is not the occurrence of resistance but its
absence that ought to be a cause for concern. Resistance must neither have only
negative connotations nor be reduced to deniers, conservatives, or die-hards resisting
all change. Resistance is an important asset in people who want to protect something
that is valuable to them.
If a project changes something that you personally consider to be valuable and
worth protecting, you would also offer resistance. If change processes meet with no
resistance, there is obviously nothing (any longer) worth protecting. Or the affected
stakeholders are already in despair or inner resignation. Figure 5.13 summarises
positive and negative aspects of resistance and change.
400 5 Teams
Top management is
involved in the change be-
Executives
fore everyone else. That‘s

why they move through
the change curve first
After that management

will be informed and they
Management
start to move through the

change curve
When the employees are

informed, executives and
Employees
management are already in

the integration phase and
they can be impatient with
the employees
Time
Fig. 5.12 Non-simultaneity of change phases
Resistance contains a coded No change

message without resistance
• Insert a pause for thought • No resistance is a reason
• Reassess opinions for concern
Without change
the human development
comes to a stand still
Permanent change without
resistance leads to arbitrariness,
chaos and dissolution
Every human being has only
a limited capacity
for change
The art of dealing with resistance The disregard of resistance leads

• Go with the resistance, not to blockages
against it • It is a fair offer if you try to find a
• Explain reasons, lead dialogues solution by other approaches
• Align a procedure plan together
Fig. 5.13 Aspects of resistance and change

Change means departure and the chance to develop further. However, it also
means letting go, saying goodbye to what has become dear. Ignoring resistance leads
to blockages. Social pressure leads to counter-pressure. Every carefully handled
resistance (Sect. 3.5.6) can bring forth new resources and abilities. How does
this work?
• Involve stakeholders and those affected, build in feedback loops.

• Transparency and openness can be seen as an essential basic attitude.
• Communicate disadvantages.
• Making advantages and long-term benefits understandable.
• Carefully prepare and empower staff for new situations.
5.5.9.2 Is Resistance a Synonym for Conflict?

If a person resists, does that inevitably mean conflict? Resistance is often used as a
synonym for conflict (Kreyenberg, 2005, p. 97). In our understanding, resistance,
when it first occurs and is not yet fully expressed, is not yet a conflict. However, a
conflict may well arise if one party insists on its position and if this leads to another
party feeling diminished in its freedom to act because of this.
5.5.9.3 Forms of Resistance

Resistance always contains a coded message. The causes often lie in the emotional
sphere. The resistance of a person affected by change can show itself in very
different forms. An existing order, structure, relationship gets questioned. This
threatens the inner balance, which can then lead to taking on a defensive attitude.
In Fig. 5.14 different forms of resistance are listed. No matter what form the
resistance takes, ultimately the causes are hidden in individual or social needs.
Resistance usually contains an energy potential that can be used constructively.
How can the project management deal with resistance? The project employees or
other affected persons are more willing to change if:
• Change is perceived and lived as an opportunity and not as a threat.

• A good relationship of trust and open communication are maintained.
• They feel safe, i.e., if they do not have to expect sanctions and abuse of power
should they uncover or address possible grievances.
• The changes are meaningful to them and something positive results for them.
• Their previous achievements are recognised.
• They are involved in the change process at an early stage.
• They are well informed and receive the necessary support.
• Their resistance is addressed (if the “subliminal emotional energy” is taken
seriously, it can be channelled in a meaningful way).
402 5 Teams
Pretended incompetence
«I do not understand what we
are up to!»
Quality Resignation
«I am the best! Why should I «It does not make sense
change?» anyway!»
Pretended engagement Resistance Praying healthy

«I‘m working full time in the against «We have no problems!»
project anyway!» changes
Proxy wars Lack of time

«Others have no idea about our «I have to generate sales, I have
problems!» no time for that!»
Active resistance Passive resistance

«With us the clocks run «I just do what I‘m told to do, they
differently!» will see what comes of it!»
Fig. 5.14 Forms of resistance
They are less likely to be actively involved in shaping change if:
• Fear and uncertainty overshadow the working atmosphere.

• Patterns of action have become automated.
• Ignorance or disregard prevails.
• Lack of awareness, understanding, and isolation are present.
• Things are not openly communicated within the team.
• Changes are seen as senseless and meaningless.
5.5.9.4 Dealing with Resistance

In the dialogue aimed at clarifying resistance, it is important to ensure that positions
are not negotiated. The true interests behind the resistance have to be uncovered.
These underlying causes are usually not obvious and need to be worked out step by
step. For this purpose, a three-stage procedure is recommended according to
Fig. 5.15.
Step 1
Assume factual doubts as the cause of resistance. Ask what your vis-à -vis has
understood. Then provide information to explain the facts. If the concerns are indeed
real, clarify them in terms of content, weigh the arguments. However, if the
arguments are pre-textual because there are other underlying causes for the
Ursache
Cause ofvon
resistance
Widerstand Umgangwith
Dealing mit Widerstand
resistance
- informieren
inform
Step 1:1:
Stufe
- argue
argumentieren
Sachliche
Factual doubts
Bedenken
- clarify
aufklären
- understand
verstehen statt
instead
erklären
of explain
Step 2:2:
Stufe
- listen
zuhöreninstead
statt argumentieren
of argue
Ängsteand
Fears undconcerns
Befürchtungen
- ask
nachfragen
and mirror
und spiegeln
- clear
klare Ansprache
address andund
compromise
Kompromiss
Step 3:3:
Stufe
- Konfrontation
confrontation and
und giving
Einlenken
in
Eigeninteressen
Self interests
- Klärung
clarification
überabout
die Hierarchie
the hierarchy
Fig. 5.15 Causes and dealing with resistance
resistance, the discussion will be circular in a bogus way. Go to step 2 to leave the
intellectual exchange of blows behind.
Step 2
It is assumed that far more than half of all resistance is due to fears and concerns. If
you have to assume fears, change the conversation strategy: listen instead of arguing
back and forth, understand instead of trying to explain. It is at this stage that
questioning techniques help. A space is created for your conversation partner in
which he feels safe. On the basis of trust, you can address fears (Sect. 5.6.9.3). Ask
questions. Make sure you have understood your dialogue partner correctly by
reproducing his statements in your own words. Paraphrase and listen actively
(Sect. 3.9.8.2). Only when your counterpart has the impression that you have really
understood his fears or anxieties and that you take them seriously, is it possible to
look for solutions together. Ask the person what might help them and what might
still be needed, instead of offering quick solutions too soon.
The surest way of not finding out about the other’s fears and anxieties in the
process of giving yourself a chance to resolve the issues is to reassure, comfort,
placate, or explain matter-of-factly that there is “no reason to worry at all”. If the
resistance is really based on fears, the person will respond to the empathetic
approach and look for viable ways together with you. If even several such
conversations do not lead anywhere, the resistance is probably not based on fears.
Go to the third stage.
404 5 Teams
Step 3
At the lowest level, it is self-interest that is causing resistance. Before the interview,
form hypotheses about this person’s interests and drivers: what favours could he
lose, what hard-won rights or advantages, what incentives, what status or prestige,
what benefits and freedoms regarding working time?
Enter into this conversation by clearly addressing these interests: What benefits or
privileges could the person maybe lose or have to give up as a result of the changes?
You cannot assume that every person will be open about this kind of thing and thereby
willing to negotiate a solution. If there is no willingness to talk, sometimes a clear
confrontation is necessary. In the bilateral conversation, the person has to be made
aware of his egoistic behaviour and made aware also that by doing so, he is hindering
important changes. Then often only a decision by someone higher up in the hierarchy
leads to a solution of such a situation. Even here, a careful approach is called for. Give
the person the chance to relent and return to cooperation before going this route.
Especially if you want or need to work with this person after the change.
Concluding Reflections on the Three Stages

Proceeding in this order is recommended, as you will not do any “harm”. If you
insinuate that someone who has factual concerns has fears, they may not feel properly
taken care of or taken seriously. Insinuating that a person with fears has self-interests
often leads to offending him making it impossible to talk about the fears.
5.5.9.5 Interventions in Case of Resistance

Table 5.9 summarises possible interventions in case of resistance.
Table 5.9 Interventions for resistance

• Collect information
• Find out the best alternatives for yourself
• Identify the best alternatives for the counterparty
• Develop options for mutual benefit
• Formulate objective criteria
• Evaluate possible negotiation solutions
Inform about: Listening to and looking for:
• Actual situation: value-free • Statements of the employees
• Planned changes and goals: be timely • Exceptional behaviour
and transparent in manner • Rumours etc.
• Consequences for employees: • Different forms of resistance
comprehensive and continuous
Participate in: Address:
• Discussion meetings • Needs of those affected
• Assessment of the actual situation • Wishes and opinions
• Decision-making processes • Good ideas
• Hearings and presentations • Cases of hardship
Negotiating over: Training and education:
• Points of contention • As early as possible
• Disagreements: in a cooperative and • As needed, both for content on the subject level
consensual manner and on the relationship level
When team members signal resistance, they expect it to be noticed and dealt with.
If the project management does not pay attention to the resistance, the team members
feel inferior, hurt, or not taken seriously. Their discomfort and dissatisfaction
increase. They withdraw and behave passively. The negative emotions are projected
onto others. The resistance becomes personalised. This can grow into a social
conflict of great magnitude such as “the project management is to blame that . . .!”.
5.5.10 Procedure in Change Projects
The procedure in change projects depends very much on the context in which the
change or transformation takes place. In order to understand this context, it is
advisable to carry out a context analysis as a first step. In doing so, the elements
according to Fig. 5.16 should be examined:
Since in change projects, one’s own efforts have to be made by way of the acting
system itself, they are particularly delicate due to the affectedness of the
organisational members, on the one hand, and due to the following, often
overestimated approach, on the other hand: namely that hardened structures have
to be broken down, fears and resistance, too, but also unrealistic expectations, have
to be reckoned with. For these projects, one therefore orients oneself towards
transformation management, which uses social processes to achieve the objective
goals.
Ecosystem
- Industry trends
- Stakeholders Objective,
Organisation topic of change
- Culture Employees
- Purpose - Energy of change
- Diversity - Arrogance of success
- Resources - Labour markets
Leadership
- Type
- Team
- Readiness
- Load
- Preferences
Initial
situation
Fig. 5.16 Elements of a context analysis according to Claßen (2019)

406 5 Teams
A prerequisite for a change project is a certain active awareness of change,

otherwise the preserving forces are going to be too strong. An orientation is given
by the formula:
D×V ×M >R
The individual parameters are defined as follows:
D = Dissatisfaction with the actual state.

V = Vision, attractiveness of the target state.
M = Measures, concrete implementation steps, achievable, first successes.
R = Resistance against change, energy to preserve what exists.
According to Doppler and Lauterburg (2014), the following key factors should be
considered in change projects:
• Awaken energy and create trust.

• Thinking in processes instead of structures.
• Aligning the company with its environment.
• Networking through communication.
• Organise from the outside in.
• Ensure learning.
It is therefore important for change projects to have a vision, clear goals, transparent
information and communication, and a process approach that allows for shared
learning to take place and new experiences to be made. Depending on the context
and the change awareness, a procedure in the change project needs to be chosen.
Different approaches from traditional to agile are available for this. A well-known
approach is the eight-step model by John P. Kotter (2012) according to Fig. 5.17.
John P. Kotter’s model is based on Lewin’s basic cycle of change management:
unfreeze (initiate change), move (shape the transition process), and refreeze (institu-
tionalise the new state).
Change projects often do not run in a linear fashion and can therefore only be
planned in advance to a limited extent. In order to counter this, a more agile approach
with an iterative and incremental approach is recommended, such as the lean change
cycle according to Jason Little (2014) (Fig. 5.18). In this approach, the reaction of
the stakeholders to the change is recorded via rapid feedback and integrated into the
further course of the change project. The focus is on dealing with people’s reactions
to the change and less on leading the change. As in the iterative procedure according
to scrum, experiments are conducted and feedback is gathered. The starting point for
the experiments are hypotheses that need to be tested. In this way, the organisation
can be transformed in small steps.
Technocratic models focus very much on direct control of change. Even when
applied consistently and put into practice, however, this approach often falls short:
the organisation proves resistant; entrenched organisational knowledge is difficult to
unlearn; existing walls are defended.
Anchor change in corporate culture 8 Anchor new approaches in the culture
7 Consolidate success and initiate changes
Introduce new
6 Achieve fast results
behavioural patterns
5 Empower employees on a broad basis
4 Communicate the vision of change

Unfreeze the
hardened
status quo
3 Develop vision and strategy
2 Build a leadership coalition
1 Create a sense of urgency
Fig. 5.17 Eight-stage model according to Kotter
2. Options
1. Prepare
1. Insights 3. Experiments 2. Introduce
3. Review
Fig. 5.18 Lean change cycle according to Jason Little (2014)

408 5 Teams
Holistic approaches are also based on systemic insights. They focus on the
reflexive dynamics of the organisation, which, when used in a targeted way, can
achieve far greater leverage for fundamental change than focusing exclusively on
people. This puts the focus on the macro level, i.e. on working on the system instead
of working in the system, as well as on indirect control, on shaping the project
context and its relationship to the world of the line organisation. These prerequisites
and conditions stimulate the organisation to change itself in a certain direction.
In any case, companies and organisations contemplating change would do well to
consciously decide on an approach and to use a neutral outsider (or an external
system) as a consultant or change agent. It is very difficult for an organisation to
“pull itself out of the swamp”. According to the model of complementary
counselling, this can also be a counselling team consisting of a process counsellor
and a specialist counsellor who understand each other and work together.
5.6 Conflict Management and Crises
The existence of differences is not the problem. Differences do not in themselves constitute a
conflict. The only thing that matters is how people experience the differences and how they
deal with them (Friedrich Glasl).
Conflicts are fundamentally part of human interaction. Human beings are expansive
by nature. That means man wants to shape his environment and follow his
convictions. With this attitude, he inevitably gets in the way of his fellow human
beings. Thus, in project work with interdisciplinary teams, ambitious goals have to
be achieved under time pressure and with limited resources. Especially in teams
where people work with great dedication and passion, different convictions clash
again and again. This results in divergence. Seen in this light, the origin of conflicts
in projects is often something positive: in stakeholders for instance, or project
managers who are committed to their convictions or to their project owner. These
framework conditions virtually always cause differences to arise and create tension
between the elements of the magic triangle: “Scope”, “time”, and “resources” (Sect.
2.3.4) making conflict management one of the core competences in project work.
According to Glasl, it is not the difference but the way it is dealt with that is the
problem. In order to be able to deal with conflicts constructively, these ought not to
be evaluated as threatening or as a consequence of mistakes, but as a natural result of
the framework conditions of the project work. The conflict is diagnosed from the
perspective of this attitude. The conflict has to be recognised and understood in its
complexity. In this way it can be dealt with constructively (Lippmann, 2008, p. 316).
Conflict management aims at making people capable of once again acting in their
objectives, which is only possible if the parties involved manage to leave their
possible affect behind and move into cognition. Most of this chapter applies to
both traditional and agile project management. Only the topic of conflict types is
considered in a differentiated way.
5.6 Conflict Management and Crises 409
5.6.1 What Is Conflict?
In the German-speaking world, the definition by Friedrich Glasl (2008, p. 24) is

widely cited:
Social conflicts are tensions where two or more mutually dependent parties vigorously try to
realise apparently or effectively incompatible plans of action, while conscious of their
opposition.
In this definition, Glasl refers to social conflict. He thus implies that conflicts
always occur between at least two people or groups. In it, at least one party
experiences differences in its thinking, feeling, or desire vis-à-vis another party, so
that the latter feels impaired. For comparison, here is the definition by Karl Berkel
(2014, p. 11):
A conflict exists when two elements are simultaneously opposed or incompatible.
The neutral term “elements” expresses that different contents can cause a conflict
situation:
• Thoughts: Why don’t I get any recognition from my project manager?

• Desires: I would like to take on the role of a product owner and still have a
friendly relationship with the scrum team.
• Behaviour: I expect regular support from my project owner, but I am not very
supportive of my team.
• Assessments: The project committee finds that the project manager of an accep-
tance project needs a high level of social competence. The project owner finds
that project experience and subject matter expertise are more important.
• People: Two members of the project team feel a strong antipathy towards each
other and refuse to work together.
• Groups: The account managers are at odds with the project manager because they
cannot meet the deadlines. The project manager accuses the account managers of
including unrealistic deadlines in the contracts.
The conflict definitions of Berkel and Glasl agree on the following points:
Conflicts Are Disturbances

Conflicts tear us out of our usual patterns of thinking, feeling, and acting. We at first
perceive conflicts as a disruption. Something is not as we expected it to be. We feel
impaired in our actions.
Conflicts Are Emotional

Feeling affected by a disturbance leads to an emotional reaction in us. We find the
situation unpleasant, feel disappointed, or perhaps hurt. Tension mounts,
accompanied by fear or anger.
410 5 Teams
Conflicts Require Intervention

Differences of opinion are the most natural thing in the world. Disagreements can be
argued and debated. Conflicts are situations in which there is an inherent compulsion
to reach an agreement. Intervention has to then take place so that the harm done to at
least one party can be resolved to such an extent that their ability to resume normal
behaviour is once again given.
5.6.2 Origin and Symptom: The Systemic Phenomenon
Most conflicts initially manifest themselves as personal (psychological) or interper-

sonal conflicts. In the case of personal conflict, the responsibility lies within the
person involved in it. His thoughts or desires are in conflict with each other. In
interpersonal conflict, the disorder manifests itself in the behaviour or peculiarity of
another person or group: one feels an aversion to another person, possibly rooted in
different values, beliefs, or attitudes. Sometimes the reason is not even apparent. It is
then simply the interpersonal chemistry that is not well attuned. Or the perceived
fault is not in the other person himself, but in his behaviour. We feel affected by it.
In project work, disruptions can occur at many points, if only because the
influencing factors of scope, time, and costs in the project are in conflict with each
other. There are also different convictions regarding that which constitutes optimal
project methodology (traditional, hybrid, agile). Or perhaps personal project and line
work cannot be reconciled. All these incompatible elements do not remain simply just
theory, something written down on paper: they lead to each person aligning their
feelings, thoughts, or actions according to their personal beliefs and judgements. This
shifts the conflict away from its origin, the incompatibility between lines and project
work, to the symptom: the relationship one has with oneself or with other people.
" A project manager has discussed the tasks in detail with the expert
responsible for the work package and has reached an agreement on
the effort to be made and the deadlines. Repeatedly, the expert is unable
to meet his obligations. Again and again, his line manager assigns him to
other projects having a higher priority. At the beginning it is an
organisational conflict: the line manager does not stick to the agreement
with the project manager and there is no resource planning between line
and project. After the second or third postponement, the project man-
ager is likely to take his being left out as an expert “personally”. He feels
disrespected in his role, maybe even betrayed. This does something to
his feelings towards his project collaborator. The project manager might
incite a fierce emotion against his co-worker, thus damaging the rela-
tionship. In a different work situation, the two people might have been
able to cooperate very well. But now the expert becomes the symptom
bearer of an organisational conflict.
This example is based on the levels of cooperation. Most causes of conflict in

projects result from the content or occur at an organisational level. An essential
purpose of the entire project management methodology related in Chap. 2 is that
possible conflict potentials are actively recognised and clarified: Tasks and
authorities are defined via the project organisation. A RACI matrix (Sect. 2.3.8.9)
defines who has to do what in which work package. An information concept shows
who is informed about what by whom and in what form, etc. All this serves to
prevent possible disruptions in the project organisation.
Phase 1 of the Systemic Phenomenon

The less well the methodological approach is applied, the higher the potential for
conflict. The unclarified tasks and authorities represent a failure at the organisational
level. However, they will manifest themselves in disruptions at the relationship level
because there are different expectations between the project participants or among
their line managers. In a first phase, the conflict shifts from content and organisation
to relationship. See Fig. 5.19.
The conflict is thus “delegated” from the line manager to the relationship between
the project manager and the expert. If those involved and responsible in projects are
not aware that they can be symptom bearers of delegated conflicts, they will
increasingly think of these disturbances as having to do something with themselves.
This is called a “systemic phenomenon”.
" System
" The word “system” comes from the Greek. In German it means “to stand” and
“together”. A basic systemic attitude tries to grasp a whole always in the interaction
of the individual parts (Königswieser & Hillebrand, 2004, p. 22).
Those who are familiar with the systemic phenomenon do not hastily focus on the
relationship level as the cause of conflict in cases of conflict, but understand the point
Content
Relation
Organisation
Fig. 5.19 First phase of the systemic phenomenon in conflict

412 5 Teams
of friction as a symptom. It uncovers the dynamics, fields of forces, contradictions,

and deficits that causally drive the conflict.
Phase 2 of the Systemic Phenomenon

On the relationship level, two options are possible: The tension either manifests itself
externally in the relationship with the employees, namely as a social conflict, or
internally as a personal conflict.
Example
If there is no established change request management process in an organisation

(Sect. 2.5.8.2), the project manager will always be faced with the intrapsychic
conflict of how to deal with a gradual change of scope (Scope creeping)). Without
having done anything wrong, the project manager finds himself in an avoidance–
avoidance conflict (Sect. 5.6.6.6). If he rejects the request, he snubs the stake-
holder who is making the request. This is very difficult or even unrealistic with a
project owner or customer. If the request is accepted without the consequences of
the request being adequately reflected in the project planning and budget, the
project manager and his team are confronted with additional costs, higher risks,
and new dilemmas because other tasks have to be postponed in terms of
priority. ◄
In this situation, two different options are available:
1. Conflict management takes place.
The conscious confrontation between symptom and cause takes place. The
relationship level is protected, the conflict is rejected. This means that the delegation
is not taken over and is rejected back to its origin, where the causes are dealt with as
best as possible.
Example
The project manager does not adopt the attitude of “anticipatory obedience” and
strives to change the situation. He specifies the change request according to the
rules of change request management (Sect. 2.5.8.2). In doing so, he challenges his
project owner to take a clear position and of course also runs the risk that his
intervention will be sanctioned in some way. ◄
2. Conflict management does not take place.
In this case, the conflict cannot usually be addressed at the relationship level
because the parties are already facing each other in a state of emotion. There is great
danger that the conflict will be suppressed at the relationship level. However, since
the feelings between the parties concerned remain, they will always engage in
debates on issues of content or organisation.
Example
The project manager does not dare to intervene with the project owner. He tries to
realise the additional requirements within the existing time and resource budgets.
In this way, he avoids the risk of getting into a dispute with the supervisor.
However, the project risks as a whole increase because more complexity has to be
managed. In addition, the risks increase that there will be tensions within the
project team (social conflicts), as well as that personal self-management will
suffer under this situation. ◄
5.6.3 Conflict Syndrome
Conflicts usually do not suddenly arise in their full intensity. The longer they
manifest themselves on the relationship level and are not dealt with, the more they
intensify. In Fig. 5.20 the following influencing factors are shown, which are also
known as conflict syndrome.
Communication
diminishes or is
insincere 1
Common goal Perception is

is lost out of distorted or
sight polarised
2
3 Attitude is
dominated by
mistrust
Fig. 5.20 Conflict syndrome (Berkel, 2014, p. 65)

414 5 Teams
1. Communication diminishes or is insincere.

(a) Information is hardly ever exchanged or, if it is, exchanged incorrectly.
(b) There is more talk about each other than about the subject matter.
(c) Covert threats and open pressure take the place of arguments and persuasion.
2. Perception is distorted and polarised.
(a) Different interests, opinions, and convictions are seen as being more distinct.
(b) The differences among themselves are thought to be more significant than the
(still) existing commonalities.
(c) Conciliatory gestures are interpreted as being hypocritical, humorous
remarks as cynical and factual intentions as hostile.
3. Attitude is dominated by mistrust.
(a) The willingness to support others decreases.
(b) The ability and willingness to understand and empathise with others
diminish.
(c) The tendency to hurt each other on a personal level increases.
4. The common goal is lost from sight.
(a) Everyone tries to achieve their goals at the expense of others.
(b) Reciprocal obstructions increase.
(c) There is no coordination and division of labour, so there is no synergy.
5.6.4 Conflict Symptoms
According to the systemic phenomenon, contradictions and dysfunctionalities shift

from the content and organisational project level to relationships. This causes a
change in people’s feelings, thoughts, and actions as symptom bearers of the
conflicts. For others, it is primarily the actions that are perceptible. The symptoms
listed in Table 5.10 can indicate that there are conflicts.
Table 5.10 Conflict symptoms

Symptom Examples
Rejection, resistance Constant contradicting, “yes, but” behaviour, bad-tempered reactions
Aggressiveness, Hurtful speeches, giving “evil” looks, derogatory remarks, deliberate
hostility mistakes, “stonewalling”, sabotage
Stubbornness, Opinionated behaviour, “sticking” to rules, “it doesn’t work like that for
intransigence us, . . .”
Making escapes Avoiding contact, staying out of the way, taciturnity, inner withdrawal,
averting of other topics
Over-conformity Not contributing one’s own ideas, avoiding criticism, going along with
other opinions
Disinterest Formal politeness, withdrawing, passive working attitude, ignorance
Formality Doing things by the book, following instructions painstakingly,
committing everything to paper and expecting others to do the same
5.6.5 Potential of Conflicts
Often conflicts only have a negative connotation and are perceived as a disruption
that prevents or delays the achievement of project objectives. If this is the case, they
become a threat or violation and can cause anxiety. It is then that conflicts become
more intense. Their potential is not used and the people involved cannot (further)
develop.
The primary benefit of conflicts is that they indicate that two elements are opposed
or incompatible and thus need the attention of all involved. Anything else would be
detrimental: if there is a “peaceful” atmosphere in a project team or in its line
organisation, where people are nice to one another, different points of view will
not be addressed. In the high complexity and under the demanding framework
conditions that characterise project work today, it is impossible for a “master
mind” to oversee everything and have a kind of “magic code” to solve all problems.
Project work depends on differences and conflicts being dealt with constructively,
dealt with furthering the project objectives in order to grow together through tackling
the challenge. Of course, everyone has at some time in his life had negative
experiences with conflicts. Of course, negative consequences can always be
attributed to conflicts. But they also contain a lot of positive potential, as can be
seen in Table 5.11.
5.6.6 Types of Conflict in Project Management
There is always the danger in conflicts that they get taken personally to soon, which
means that the parties to the conflict are also perceived as being the cause of the
conflict. This does not do justice to the complexity of conflicts. Most of the time, the
conflict parties are symptom carriers and the causes are kept to the background.
Types of conflict that often occur in project management are described below.
Table 5.11 Positive and negative characteristics of conflicts (Derived from Lippmann, 2008,
p. 318)
Positive Negative
Allows to develop one’s own personality Violates basic personal needs
Helps to protect one’s own boundaries Leads to isolation
Refers to problems Promotes resistance
Prevents stagnation, is the root cause for Takes focus away from the main task, blocks
change energy
Stimulates ideas Ties up valuable resources
Stimulates interest and curiosity Arouses fear, anger, frustration, pain, stress, and
dissatisfaction
Helps find solutions Confuses employees
Enables a comparison of self-image and Favours blame
external image
Leads to self-knowledge Leaves behind winners and losers
416 5 Teams
5.6.6.1 Goal Conflict and Conflict of Interest

A goal conflict occurs when two or more parties pursue different goals and interests
(Kreyenberg, 2005, p. 27). Possible goal conflicts in project work are manifold:
• Goal conflicts occur in projects when the objectives with the corresponding
weightings have not been comprehensively worked out, negotiated, and approved
of by the project owner.
• In the magic triangle, the interdependent influencing factors “scope”, “costs”, and
“time” are mutually dependent, which can also generate conflicts. Every customer
or project owner expects as much quality or functionality as possible as a project
result. However, this needs to be achieved within a limited time frame and at
small cost.
• Different interests and expectations of stakeholders.
Agile project management is less prone to conflicting goals, because these

projects are defined much more by a shared vision than by having specific goals.
The prerequisite, however, is that the product owner is granted all decision-making
authorities. If this is not the case, there will be goal conflicts and interests between
the product owner and the decision-making bodies of the line organisation.
5.6.6.2 Distribution Conflicts and Resource Conflicts

Every project requires personal, financial, or technical resources. The parties agree
on the importance of a project. However, because the personal, financial, and
technical resources are limited, a conflict may arise regarding the allocation of
resources (Kreyenberg, 2005, p. 29), a distribution conflict.
Whether agile or traditional project organisation, in both approaches there are
distribution conflicts when:
• The estimates for the effort necessary are not realistic or too small a budget has
been released.
• The effort estimates are not updated over the course of the project.
• The projects are integrated into the line organisation through coordination and the
line managers repeatedly make changes to the priorities.
• The projects are not consolidated in a multi-project plan.
• There is no project portfolio at the strategic level through which the management
can transparently set and control priorities.
Often, only strategically important projects are well protected from these
conflicts. For all other projects, the struggle for resources is a recurring challenge
for project managers and scrum masters.
5.6.6.3 Structural and Organisational Conflict

Another major source of conflict is the integration of the project organisation into the
line organisation. Projects are always temporary forms of organisation which are
incorporated in a specific way into the permanent line organisation. It is especially
the integration forms of project coordination and matrix organisation that are prone
to conflict. In project coordination, the project manager is a mediator and decision-
maker and is heavily dependent on the decisions of line managers. In the matrix
organisation, the project manager has technical authority over his employees, but the
consequence is that all employees have two superiors who often do not coordinate
their priorities well. If it is also a client project and a client representative is
integrated into the project organisation or even acts as its formal project owner, a
structural conflict is almost guaranteed. Structural and organisational conflicts
occur when:
• It is not explicitly clarified and discussed how a project is to be integrated into the
line organisation and if, based on this, the decision-making authorities and the
management style (e.g. lateral management) are not coordinated.
• Project roles and committees are defined, but they do not so what they are
supposed to do (e.g. if the project owner is not visible in the project).
• In client projects, the responsibilities and information flows between the internal
and the client organisation are not coordinated.
Agile project teams are well protected against interventions from the line
organisation with the concept of self-organisation. Of course, conflicts can always
arise within the team because each team member has to take on tasks related to
productive work (work in the system) as well as work on the system, depending on
the situation. If no personal willingness or flexibility, both serving as the basis of
self-organisation, is present, or if solutions are given to the scrum team by the
product owner or the line organisation, structural or organisational conflicts are
pre-programmed.
5.6.6.4 Evaluation Conflict and Procedure Conflict

Evaluation conflicts often go back to the different previous experiences, levels of
knowledge and also levels of information of the parties involved. In this case, the
parties agree on what goals are being pursued, but there are different convictions
about the ways and methods required in order to achieve these goals. The effective-
ness and impact of the approaches are assessed differently (Kreyenberg, 2005, p. 27
f). Agile or traditional or hybrid, and in what form? What does the milestone plan
look like? What can be binding milestones during project implementation?
The potential for evaluation conflicts is also high in traditional projects. Project
work is not repetitive work as line work often is. Every project is unique in some
sense. As a result, there will always be different opinions and convictions concerning
the methods and ways of achieving these goals. Evaluation conflicts occur when:
• The project order has been neither clearly formulated nor negotiated.
• The objectives of the project are not SMART or not well defined.
• No transparent criteria for decision-making have been established.
• Decision-making authorities and models are not regulated between the project
committee and the project owner.
418 5 Teams
In the agile approach, the product owner has the sole decision-making authority to
accept sprint results. What he rejects has to be worked on again. The teams
themselves are challenged in this type of conflict when:
• Different convictions exist about the requirements that are implemented within a
sprint.
• There is a different perception of who contributes how much to the team’s
performance.
• the work in the system has a higher value than the work on the system,
• the scrum master does not intervene quickly enough in the event of discrepancies.
5.6.6.5 Role Conflict

The different roles in the agile and traditional project organisation are explained in
Sect. 2.3.8, the distinction between position and role in Sect. 5.3.1. Project work is
highly exposed to role conflict because most project participants, except in the pure
project organisation, fulfil several roles at the same time. The less clearly these roles
are defined and the less clearly the roles are assumed, the greater the potential for
conflict.
The traditional approach often suffers from role conflicts. In contrast to agile
project management, the responsibilities between team, sub-project manager, project
manager, project owner, and project committee are often less clearly defined. The
human factor is similar in both approaches, which means that role conflicts are
always possible. Role conflicts occur in traditional project management when:
• The responsibilities of the roles and committees are not clearly defined.
• The specific responsibilities and decision-making authorities are not made trans-
parent via a RACI matrix or a function diagram.
• The leadership style of the project manager is not aligned with the integration of
the project into the line organisation (e.g. lateral leadership).
• The congruence principle TCR is not reasonably balanced at all project levels.
• The team development process (Sect. 5.2) is not led from the storming phase into
a constructive norming phase.
In the agile approach, role conflicts are likely when:
• The product owner is not given decision-making powers regarding prioritisation

or acceptance of the sprint results.
• The scrum master actively participates in the scrum team.
• The developers are not granted decision-making authority when it comes to
requirements or self-organisation.
• The developers are not sufficiently on par in their abilities and hence a few top
performers have to manage the overall performance of the team.
Approach-Approach-Conflict
The person is caught between two goals
that are considered to be equally valuab-
le, but cannot be achieved simultaneously
Avoidance-Avoidance-Conflict
The person has to decide between two
conditions, both of which are considered
to be evils
Approach-Avoidance-Conflict
The person is faced with the decision
that brings her both valuable and evil
Fig. 5.21 Mental conflicts (After Berkel, 2014, p. 15 f)
5.6.6.6 Personal Conflict

When personal conflicts (also called psychological conflicts) take place, people feel
a variety of different decision-making or behavioural tendencies within themselves
(Kreyenberg, 2005, p. 30). The more contradictory or unclear the requirements for
the project are, the stronger the personal conflicts of those involved in the project.
These inner decision-making conflicts can be categorised according to the options
that are realistically available to a person. Figure 5.21 summarises the three conflicts.
Approach–Approach Conflict
Someone has two options open to him, both of which are attractive. This sets up the
dilemma of finding both similarly interesting. However, as it is impossible to realise
both goals at the same time, a decision has to be made for one of the two options and
against the other and therein lies the conflict.
"
• The scrum master notices tensions in the scrum team. He has to
decide whether he should intervene directly or whether he should
risk that the scrum team manages the problems itself thereby
continuing to grow together.
420 5 Teams
• The project manager has to decide whether to take on a team

leadership role in the line organisation or whether to continue on to
lead projects.
Avoidance–Avoidance Conflict
In the case of the avoidance–avoidance conflict, a choice has to be made between
two options, both of which will have negative consequences. The decision then has
to be made in favour of the lesser evil.
" A well-tried project manager is a month behind schedule with his client
project. The project owner now has the choice of either coming down
hard on him (which he is reluctant to do), allocating additional resources
to this project (which he in turn has to compensate for elsewhere) or
informing the client that there will be a delay in project completion.
Whatever the project owner does leads to trouble.
Approach–Avoidance Conflict
Approach–avoidance conflicts are characterised by ambivalence: Each choice has
both positive and negative consequences.
" Someone is nominated for the role of product owner in a strategic

development project. This would put him in a higher income level and
he would also finally have more management and decision-making
powers. However, he would be obliged to pass the product owner
certification within just 1 year. He doubts whether the demanding task
of being the product owner, combined with having to study for the
certification, is compatible with his role as a young family father.
5.6.6.7 Relationship Conflict (Social Conflict)

Relationship conflicts are present when there are subliminal or open disturbances in
the relationship between people. Because two or more people are involved in
relationship conflicts, they have a completely different dynamic than personal
conflicts (Berkel, 2014, p. 18 ff).
Two-Person Conflicts or Couple Conflicts

We experience couple conflicts not only in our private relationships. Very often we
also experience conflict-laden situations between two people in the work sphere:
Supervisors, co-workers, negotiating partners, etc. Possible causes for two-person
conflicts are:
• Closeness vs. distance: The need for closeness and distance always changes in
people. Too much distance or too much closeness increases tension in the other
person. The other person feels either abandoned or constricted.
Example: If a work colleague is appointed project manager, the proximity-distance

relationship changes. The person promoted will tend to keep his distance in order
to fulfil his new leadership role. The former colleague, however, still expects the
same closeness as before the promotion.
• Preserve vs. change: Every person has his or her own developmental dynamics:
one person is very open to change, curious and constantly on the lookout for new
possibilities. The other seeks more stability in his life, wants to preserve what he
has achieved and finds stability and satisfaction in recurring rituals and processes.
Example: If a colleague comes back to the company full of enthusiasm from a
training course, he wants to apply what he has learned immediately and change
existing procedures. This is sure to lead to conflicts with the people who want
things to stay as they are.
• Communication: Interpersonal verbal as well as non-verbal communication has a
lot of conflict potential (Sect. 3.9).
Triple Conflicts or Triangular Conflicts

With a third party, new phenomena occur in conflicts that are not possible in a
two-person relationship:
• Coalition: Two people ally against a third.

• Rivalry: A supervisor plays two of his employees off against each other. They
now compete to win the boss’s favour.
• Relationship: In a couple, the personalities determine the relationship. The
personality is then the main factor influencing the conflict. In a three-way conflict
it is the other way round: the personalities of the people involved are not the main
factor, but the relationship that the conflict parties have with each other. For
example, the supervisor has a separate relationship with each of his two
employees.
Group Conflicts
In the group, further potential for conflict may come to light, this can involve:
• Territory: Each group considers a certain territory as its home ground and defends
it against intruders. The individual in the group is not only sensitive when spatial
boundaries are disregarded, but is also irritable when dealing with perceived
transgressions of responsibilities and authorities.
• Ranking order: Every group consciously or subconsciously establishes a ranking
order. Well-known is the ranking according to:
– Leader (Alpha)
– Expert (Beta)
– Group Member (Gamma)
– Outsider (Omega)
422 5 Teams
In case a group does not establish the hierarchy, it remains unable to work. New
organisational units or even projects inevitably cause ranking struggles.
According to Karl Berkel, a group is not successful because of the formal
organisational chart, but because the internal hierarchy best meets the functional
requirements. If the organisation is not seen as purposeful or is not accepted, this
leads to a state of permanent friction. Recurring conflicts are often an indication
of an organisational hierarchy that is not accepted by its members.
• Leadership: Every group, be it a project team or a line organisation, has to fulfil

two basic requirements: It needs to be able to achieve its goals and guarantee at
least a minimal degree of cohesion. Except in a pure project organisation, every
person in project work has two or more superiors: the line manager and the project
manager. The methods employed by the leadership as well as the possible
discrepancies and clashes among these leaders contain further potential for
conflict.
5.6.6.8 Conflict of Values

Values form the core of the identity of social systems, be they the values of
individuals, groups, or entire organisations. Values symbolise what we consider
important and right and what we feel bound to. Values do not come into conflict with
each other; it is always the people who identify with specific values. Those who fear
that their own values are being questioned feel that their personal identity is under
attack. This is why people often react so violently to conflicts at this level (Berkel,
2014, p. 93).
These can be personal values as well as values in an organisational culture.
Values are dynamically related to each other. In paid work, the tension is mainly
between the values of performance (organisation) and satisfaction (individual). The
more the company management focuses on performance, the more do values of
individual satisfaction, as for instance well-being or health, recede into the back-
ground (Berkel, 2014, p. 23). Interdisciplinary and often also intercultural project
work is exposed to such value conflicts. These occur in both the agile and the
traditional approach.
At the individual level, differences can occur in the expectations of how priorities
are set, of how the culture of communication is shaped, or even how decisions
are made.
At the organisational level, differences mostly occur between subsystems such as
sales, production, and development. These pursue different and also contradictory
values in their tasks: Sales focuses on customer proximity, flexibility, and competi-
tive prices, production wants efficiency in the processes and low inventory levels,
and in development the focus is on innovation and high quality.
5.6.7 Conflict Diagnosis
Conflicts are like a visit to the doctor: If the diagnosis is wrong, the treatment will not
be effective either. Conflict diagnosis is meant to avoid an unreflective
personification of conflicts or even a rash apportioning of blame. Only when we
have understood the causes behind the conflict symptoms we can deal with conflicts
in a goal-oriented way.
5.6.7.1 Forming Hypotheses Instead of Wanting to Know

Each human being is a non-trivial system (Sect. 1.6.3). Therefore, we can never
know what a person feels, how he thinks, or how he acts. The only thing we can do in
relation to other people or groups is to form assumptions and by these come to form
hypotheses. However, whether a hypothesis is right or wrong is always determined
by the party for which it was made. The hypothesis only becomes a fact when it has
been confirmed by all the parties involved.
5.6.7.2 Forms of Expressions of Conflicts

The object of conflict is expressed in the types of conflict described above. Stepping
back from this, the way in which conflict is expressed can differ a lot (Lippmann,
2008, p. 327 et seq.).
Latent and Open Conflict

With latent conflicts, there are differences between parties that have not yet led to
hostile activity. This would be the case in an open conflict. It can be valuable for a
project manager or scrum master to recognise latent conflicts in order to be able to
deal with them at an early stage and thus prevent them from escalating.
" For example, the project manager may feel substantial differences to
exist with one of his sub-project managers. However, because the project
manager knows that the sub-project manager has a close relationship
with the project owner, he will not let the conflict escalate. Should the
project owner hand over the project to a colleague, the latent conflict
would erupt into open conflict.
Hot and Cold Conflict

In hot conflicts interaction is strikingly active, the parties tend to overreact. Attack
and defence are recognisable to all and are conducted impulsively and emotionally.
The forcefulness of the parties is fed by their exaggerated positive self-images.
In cold conflicts (Fig. 5.22), interaction is inactive. Disappointment, frustration,
and feelings of hatred are suppressed and continue to have a destructive effect for
those caught up in these emotions. A confrontation does not take place except
indirectly, as the parties avoid each other and deflect direct contact. Interactions
are also possible in a scenario containing both a hot and a cold conflict. A cold
conflict, as an example, can suddenly escalate into a hot conflict months or years
424 5 Teams
formally informal
• static • dynamic
• inward-oriented • outward-oriented
• according to rules • spontaneous
• reactive versus • provocative
• indirect communication • direct communication
• avoid risk • risk taking
• backward-looking • forward-looking
cold hot
Lost faith in constructive goals Heating up for own goals

Frustration, sarcasm Over- motivation
Not taking responsibility for actions Beyond all doubt
Wihdrawal, avoidance Rejecting criticism
Attack, confrontation
Fig. 5.22 Hot and cold conflicts (Based on Schwarz, 2014)
later. But the opposite is also possible: If a hot conflict is not managed, the conflict
parties can withdraw into a cold conflict (Glasl, 2004).
" In meetings it is easy to observe whether there is a hot or cold conflict

culture. Is there open debate and argumentation? Do people defend
their convictions even if these are not shared by the majority? This could
initiate a hot conflict. However, if the participants in the meeting avoid
each other and try to badmouth and defame the other party “behind the
scenes”, this would be a cold conflict.
Displaced Conflict (Substitute Satisfaction)

A further differentiation in the form of expression is to examine whether the actual
issue in dispute is being fought out between the parties at all. It is also possible that
the issue seemingly at the centre of the discussion is only meant to distract from an
underlying, real issue. When the brain finds that it does not get what it needs, it tries
to find a substitute (Ballreich & Hüther, 2009).
" A project manager repeatedly demands from his employees to do things

as quickly as possible, as if these tasks had a profound urgency compared
to other unresolved issues. There is a high probability that the project
manager is not at all concerned with the effective activities: he wants to
experience his status and influence again and again.
On the surface, this is a good strategy because it at least gives the brain a rest.
However, the actual longing or basic need behind it is not satisfied. Conflicts may
also arise over a topic or concern that is considered very important from a subjective
perspective. A displaced or hidden conflict can be recognised by the fact that:
• The dispute has no compelling reason and appears to be “wanted”.

• The subject matter of the dispute is disproportionate to the strength of the conflict.
• No real interest is discernible.
• Obvious solutions are avoided.
• The conflict is fought out tenaciously and pettily.
Displaced conflicts can actually only be resolved sustainably if the underlying

real conflict is addressed.
5.6.7.3 Conflict Styles

Figure 5.23 represents the different styles that people use in conflicts. These are
distinguished in relation to the self-assertion or the consideration of the respective
conflict parties (Berkel, 2014, p. 60 ff). Evolution has given humans three conflict
styles, which they share with all animal species:
Absolute Self-assertion: Attack

I want to get my way and the other party should lose (win-lose). Open confrontation
(hot conflict) or indirect resistance (cold conflict).
Absolute Consideration: Escape

The other party gets its way, I submit and obey (lose-win). Give right of way to a
strong desire for harmony and cohesion.
Neither-nor: Playing Dead

Both parties try to avoid the confrontation. Both lose (lose-lose). The conflict is
denied or played down as irrelevant. It is also possible that contact is broken off or
that the parties are content with the current state. As long as the intensity of the
conflict is not too strong for those affected, they can use their trained behaviour
patterns from childhood. In a best case scenario, they develop conflict styles via their
cognitive abilities that are only possible for people having their specific mode of
reasoning.
426 5 Teams
high - altruistic
Orientation to the goals and concerns of the other party
Integrate (Win/Win)
Escape (Lose/Win)
• Expand resources
• Demand of the other side
• Clarify needs
• Subordinate, obey
• Explore new options
• Strong desire for harmony
(Consideration)
Negotiate (Compromise)
Making mutual concessions
Differentiate points of contention
Attack (Win/Lose)
Play dead (Lose/Lose) • Open (direct)
• Avoid conversation confront, attack
• Deny conflict • Covered (indirect)
• Talk around the topic process control, resistance
low
low high – egoistic

Orientation towards my goals and concerns
(Self-assertion)
Fig. 5.23 Typology of conflict styles (Berkel, 2014, p. 60)
Negotiate (Compromise)
The points of contention can be differentiated. Both parties deviate from the maxi-
mum demand. Concessions are granted to each other.
Integrate
The real causes of the conflict can be identified. It is possible to manage the conflict
in a way that is a win-win for all parties involved. The specific conflict style of
integration is dealt with in detail in the Harvard Concept in Sect. 5.6.9.4.
Effectiveness of Conflict Styles

The bad news is that there is no such thing as the most effective conflict style.
Depending on the type of conflict, duration, intensity, and the people involved, a
different style is required in each case. Nevertheless, the effectiveness and appropri-
ateness of conflict styles can be assessed (Fig. 5.24). Effectiveness: Can the goals be
achieved, one’s own and the others’? Appropriateness: Can violating relationships or
valid rules be avoided?
The illustration makes it clear that the goal of any conflict management is always
integration or cooperation (negotiation). These two conflict styles are cognitive.
Yielding, avoiding, and fighting, on the other hand, are characterised by affect.
Conflict situations are always stressful situations for people, especially with
large
Integrate
(Win/Win)
Fight
(Win/Lose)
Negotiate
(Compromise)
Effectiveness
Avoid Submit
(Lose/Lose) (Lose/Win)
small
unreasonable conduct appropriate
Fig. 5.24 Effectiveness of conflict styles (Berkel, 2014, p. 62)
increasing intensity and duration. Conflict styles can also change over time: A
dispute once begun with an open attitude of integration or compromise can lead to
the affective styles of fighting, avoidance, or giving in as stress increases or when the
basic emotions of fear and anger become more prominent. The conflict styles of
fighting, avoiding, and giving in often conceal fears:
• Fighting: I don’t want to be perceived as insecure or as a weakling.

• Playing dead: I am afraid of taking a concrete position and thus also being held
responsible.
• Escape: I am afraid that acting as befits my needs might be perceived as
aggressive, uncaring, or cold.
5.6.8 Models for Conflict Diagnosis
5.6.8.1 Conflict Escalation Levels

The model of conflict escalation stages by Friedrich Glasl (Fig. 5.25) helps to
identify the degree of intensity of a conflict. The phenomenon behind this is that
unresolved conflicts increasingly activate people’s destructive forces over time. The
behaviour of the conflict parties becomes increasingly emotional and unpredictable.
Hence, the ability to control is lost over time. It becomes increasingly difficult for the
conflict parties to differentiate between objective actuality and perception and to be
able to resolve a conflict independently and neutrally.
428 5 Teams
Major phases
1 Hardening
Cooperation
2 Debate
and competition
3 Actions
4 Coalition
Self fulfilling
5 Loss of face prophecy
6 Strategy of threat
7 Limited destruction strikes
Degradation
8 Fragmentation
and reification
9 Together into the abyss
Fig. 5.25 Escalation stages and their main phases (Glasl, 2004, p. 218 f)
Table 5.12 Phase I: cooperation and competition (win-win)

Level How can the escalation level be recognised?
1 Hardening • Points of view crystallise, harden and clash
• Noticing tensions itself leads to cramping symptoms. Nevertheless, there is
the conviction that the tensions can be solved through conversations
• No rigid parties or groups
2 Debate • Polarisation in thinking, feeling, and desire
• View of superiority and inferiority
• Arguments are used to hurt the other party in the emotionally
3 Actions • A conviction that “talking no longer helps” gains ground
• A fait accompli strategy
• Empathy for the “other” is lost. Misinterpretations increase because
non-verbal behaviour is no longer corresponds in line with verbal behaviour
Phase I: Cooperation and Competition (Win-Win)

As shown in Table 5.12 phase I, the parties involved still focus on the well-being of
all. The parties concerned are convinced that everyone can emerge from the conflict
as a winner. Everyone has a constructive attitude regarding the conflict. The conflict
style of integration (win-win) is in the foreground.
Phase II: The Self-fulfilling Prophecy (Win-Lose)

The belief in constructive conflict resolution gets lost among the parties involved.
The focus is now on differences and on gaining advantages. Self-assertion is in the
foreground (win-lose). Table 5.13 describes the three stages of phase II.
Phase III: Degradation, Reification (Lose-Lose)

The conflict has escalated to such an extent in phase III that the parties realise that no
one will be able to win any more (lose-lose). Both parties are now still trying to incur
less damage than the other. Relations between the conflict parties have at this stage
become completely functionalised. Participants treat each other as objects, doing so
without sympathy. Table 5.14 shows the three final stages of mutual destruction.
For conflict management in the project, the following conclusions can be drawn
from the model of escalation levels:
• The longer you wait to deal with the conflict, the more difficult it becomes.
• Up to level 3, a conflict resolution is possible from which all parties involved
profit.
• In conflicts that escalate to level 6, there is still a winner–loser solution at best.
• After that, in principle, both parties lose.
Table 5.13 Phase II: self-fulfilling prophecy (win/lose)

4 Coalitions (“rope • The parties manoeuvre each other into negative roles and fight each
teams”) other
• People try to confirm their own prejudices
• Supporters are recruited by each party for itself
5 Loss of face • There are public and direct (prohibited) attacks intended at making
the opponent lose face
• The counterparty is seen as the intrinsically bad
6 Threat strategy • Threats and counter-threats increase
• The pressure is increased, therefore stress increases, too
• Those involved no longer get to think about what they are doing
Table 5.14 Phase III: degradation, reification (lose-lose)

7 Limited destruction • The opponent is no longer seen as a person
strikes • Limited destructive attacks become the “appropriate” response
• Lying becomes almost a virtue, as long as it harms the opponent
8 Fragmentation • Relationships are systematically cut off
• Important functions become immobilised
• Regeneration seems no longer possible
9 Together into the • Overall confrontation
abyss • Overcoming the opponent becomes acceptable even if the price is
harming oneself
430 5 Teams
Limits of Self-help
As soon as a social conflict gets to level 3, the people involved begin, at level
4, (coalitions) to win over as many supporters as possible for their own party.
Conflict resolution is thereby intended to be established by means of the larger
coalition. If, from this stage onwards, a project manager, scrum master or line
manager intervenes with the well-meant intention of mediating the conflict, the
parties will try to draw even the intervening person into their respective coalition.
By giving in to this he loses his neutrality and becomes a party to the conflict
himself. Therefore, from escalation level 4 onwards, it is imperative to involve a
moderator or mediator. If this is an internal person, he or she should not come from
the same hierarchical level, but, e.g., from a staff unit or from HR. It is even better if
this is done by an independent person from outside the company. Figure 5.26
represents the limit of self-help and also summarises recommendations for interven-
tion in conflicts.
5.6.8.2 Layer Model

How do we proceed when a conflict is identified? What can give us orientation so
that we do not fall into a foolhardy stance of seeing the conflict as something
personal instead of retaining an ability to separate the symptoms from the causes?
The layer model in Fig. 5.27 provides valuable support for this (Schmidt & Berg,
Main phases ►from here on support is necessary
Winner – Winner Winner – Loser Loser – Loser
Possible roles ►from here on support is necessary
Level 3 - 6
External process support
Level 6 - 7
Level 1 - 3 Mediation
Moderation Level 6 - 8
Arbitration
Level 7 - 9
Power intervention
Meaningful interventions ►from here on support is necessary
Ask what it is Encourage Conduct indivi- Reappraise self- Revisit history of

image / external Separate parties
about listening dual interviews image
polarisation
Recognise and
Support Make aware Analyse critical
point out Role assignment Offer alternatives to exit
conversations of behaviour incidents
patterns
Address
Become aware Support Record unvalue,
of inner drivers non-verbal conversations show coalition
behaviour
Fig. 5.26 Meaningful roles and interventions in conflict situations

1. Work organisation (factual conflict)

Infrastructure, structuring of working time,
external working conditions,
recognition, processes, information flow, resources (people, finance)
2. Role
Distribution of tasks, responsibility
Intervention from top to bottom
and competences, organisational chart

matching roles and skills
3. Behaviour
Communication and behavioural patterns
leadership style, cooperation, conflict skills
4. Norms and values

Personal attitude to life
view to human nature
organisational culture
5. Personality profile
Characteristics of a
person, identity of
organisation
Fig. 5.27 Layer model
2008, p. 158 ff). Conflict management according to the layer model needs adherence
to two principles:
• Making changes begins at the top.

• Conflict management should only be extended to the lower levels as far as
necessary. It is not about deepening every conflict to the lowest level.
The model assigns the norms and values of the organisation and the person as
well as character traits and personality profiles to the two lowest layers. This is to
prevent a premature personification of the conflict. According to this model, the
influencing factors from the work organisation are to be examined first, followed by
role clarification and role assumption (behaviour).
Assignment of the Conflict Types to the Layer Model

In a next step, Fig. 5.28 the conflict types are assigned to the layer model. This is of
course a simplification, because often the conflicts concern several influencing
factors (and layers). Nevertheless, this assignment makes us aware that the causes
of most conflicts can be relegated to the top level of a work organisation: Goal and
interest conflicts, distributional conflicts, structural and organisational conflicts, and
evaluation conflicts. These conflict types can be subsumed as factual conflicts. Role
conflicts are then arranged at the next lower level.
432 5 Teams
1. Work organisation (factual conflict)

Conflicts of interests and goals, distribution and resource conflict,
structural and organisational conflict, assessment conflict
2. Role
Intervention from top to bottom
role conflict
3. Behaviour
relationship conflict
personal conflict
4. Norms and values

conflict of values
5. Personality
profile
Fig. 5.28 Assigning the conflict types to the layer model
The most frequent types of conflict are arranged on levels 1 and 2. If the
methodological approaches of agile and traditional are applied appropriately in the
project organisation, many conflicts can be avoided or managed after they occur
without people playing a role. They are only symptom carriers.
From level 3 (behaviour) downwards the person has an influence over the
conflict. If neither the work organisation nor the roles explain the disruption, the
analysis is taken to the deeper behavioural level (relationship conflict or personal
conflict), descending to the next level lies the conflict of values. Especially in
intercultural cooperation, discrepancies can occur here. No type of conflict gets
assigned deliberately to the personality profile. In a professional context, a person’s
identity should be respected and protected as much as possible. Of course, it may be
that a conflict in a project becomes a projection surface for a disruption on the
personality level. Even if that is the case, the disturbance would nonetheless have to
be dealt with at the behavioural level.
5.6.8.3 Questions for Conflict Diagnosis

Now all the basics for a comprehensive conflict diagnosis have been discussed.
Whether as a directly affected party, as an involved supervisor, as a conflict
moderator, or as a mediator, it is always a matter of stepping away from emotions
whilst activating rational, cognitive abilities. To this end, formulating questions
helps at considering the conflict soberly. Following Karl Berkel (2014, p. 45 ff), the
following questions should be worked on:
1. The points of contention: What is at stake?

(a) What do the parties bring against each other?
(b) What are they asking of each other? What is the intention behind it?
(c) Do they see the points of contention the same way? How do they know?
(d) How do the parties experience the conflict personally? How important is it
for them?
(e) To what extent are the points of contention objectively based or subjectively
conditioned?
2. The course: How did the conflict develop?
(a) What caused the conflict?
(b) Which critical outcomes have exacerbated or mitigated it?
(c) What is the state of affairs at the moment?
(d) Which conflict escalation level according to Glasl can the conflict be
assigned to?
(e) What is the form of expression of the conflict: “hot” or “cold”, latent or open,
displaced or real?
3. The behaviour: How do the parties act?
(a) How is each party trying to influence the other?
(b) Are they manipulating each other? Or are they arguing honestly?
(c) What patterns (stimulus-response) occur repeatedly between them?
(d) What is the preferred style—rigid or flexible—of each party?
(e) Are the opposing parties debating with each other, reacting to each other, or
are they already fighting with each other?
(f) Can a specific conflict style be assigned to the conflict parties?
(g) What does a continuation of the conflict mean for the parties involved in
terms of outcome? What would the benefits of a settlement be?
(h) What price (what concession) are the parties willing to pay?
4. The parties: Who is in conflict with each other?
(a) Who are the parties: individuals? Groups? Organisations? Collectives?
(b) In the case of individuals: Are there (interest) groups backing them?
(c) For groups: Who is in charge? Where and how does is the person in charge
intervening in the conflict?
(d) For organisations: What is the internal communication, power, and decision-
making structure?
(e) How are the parties hierarchically organised? Is one superior or subordinate
to the other? Are they equals in this regard?
(f) How does each party feel about the other: as superior or inferior? As stronger
or weaker?
(g) What principle should apply in the relationship: Equality? Fairness?
Necessity?
(h) What can each side demand based on its position?
434 5 Teams
5. The expectations: What do the parties hope to achieve or fear from this conflict?
(a) Is the conflict unavoidable or avoidable for the parties? Is it possible or
impossible for them to reach an agreement?
(b) Who benefits from the conflict: Just one party? A third party? The
organisation?
(c) Who is disadvantaged by the conflict: One of the parties? A third party? The
organisation?
(d) Who benefits from the on-going, unresolved conflict?
(e) How do the regulatory mechanisms in the system work?
(f) How do the parties assess the attempts to end the conflict so far? What has
each done to reach resolution? With what effect?
(g) Do the parties hope to be able to settle the conflict? Or have they given up
all hope?
5.6.9 Conflict Resolution
5.6.9.1 The Aim of Conflict Management

What is the purpose of conflict management? Can we claim to “solve” all of the
types of conflict listed above? After all, that would mean that all the different beliefs,
perspectives, needs, and feelings that have led to the deadlock can be dissolved?
Since conflicts always have a personal and emotional component, resolving them
becomes a challenging goal. Conflicts are always a challenge that has to be actively
dealt with. Karl Berkel describes the goal of conflict management as follows:
Conflict management aims at getting a grip on and mastering a conflict in such a way that the
person (party) is (no longer) restricted in his or her experience and is (again) fully capable of
acting (Berkel, 2014, p. 72).
Conflicts are always disturbances that first manifest themselves in our relationships
with other people. At first glance, a conflict is always unpleasant: On the one hand,
conflicts impede the personal, goal-oriented striving of the person. On the other hand,
conflicts also always activate the basic feelings of fear or anger. Human feelings come
faster and therefore long before a rational response. People who immediately act out
their basic emotions in conflicts quickly become destructive. This prevents the
unfolding of the positive potential of conflicts described in Sect. 5.6.5.
5.6.9.2 Restoring Self-control

In a conflict, our brain is stimulated because the situation it is confronted with does
not correspond to what it expects. In the excitement, people lose their ability for
reflective self-control. When the brain is literally “running hot”, it has to be cooled
down again to enable reflected self-control once more. This can only be achieved in
the same way in which the excitation came about.
The challenge here is that our attitudes and evaluations in the prefrontal cortex
(Sect. 3.3.1) are based on a coupled network having cognitive and emotional
components. Every position or demand in a conflict can therefore be rationally
justified while being emotionally biased.
Often an attempt is made to reach a new agreement in a discussion between the
parties to the conflict and thereby come to lay down rules for an altered behaviour.
Even if this agreement may make a lot of sense in terms of content, it often happens
that the parties fall back into their former behavioural patterns soon or immediately
afterwards. The reason why many conflicts are not successfully managed lies in a
person’s behaviour being based on his or her attitude, an attitude shaped by the
cognitive and emotional elements described above; conflict management that does
not include these cannot therefore be successful.
Conflict parties can only regain control over the situation and themselves if they
at the same time emerge from their emotional foment. In order for this to happen, a
space of trust must be created in which the parties involved feel safe. The feeling of
security then allows emotions to cool down. In this newly created space of trust,
people should next be encouraged or even inspired to have new experiences with
strategies and patterns of behaviour the effectiveness they had before considered
impossible in comparable situations given their attitude (Ballreich & Hüther, 2009).
5.6.9.3 Conflict Resolution Process
Example
A man wants to hang up a picture. He has the nail, but not the hammer. The
neighbour has one. So, our man decides to go over and borrow it. But then he has
a doubt: what if the neighbour doesn’t want to lend me the hammer? Yesterday he
only greeted me in passing. Maybe he was in a hurry. Maybe he was only
pretending to be in a hurry, and he has something against me. What’s that? I
didn’t do anything to him; he’s imagining things. If someone wanted to borrow a
tool from me, I’d give it to him right away. And why not him? How can you
refuse a fellow human being such a simple favour? People like this guy poison
your life. And then he imagines I’m dependent on him. Just because he’s got a
hammer. I’ve had enough of this. So he storms over, rings the bell, the neighbour
opens the door, but before he can say hello, our man shouts at him: “Keep your
hammer, you bully!”
(Paul Watzlawick, 2004, p. 37 f) ◄
The hammer story by Paul Watzlawick shows: Man, preoccupied with his own
thoughts and ideas, soon gets himself into a vicious circle. The longer we carry
difficult situations around with us, the greater the danger that we become unneces-
sarily involved in something. Figure 5.29 summarises the prerequisites for success-
ful conflict management.
Each of the following steps illustrates the process as described by Karl Berkel
(2014) in his cooperative conflict resolution (Fig. 5.29). It starts with the person,
436 5 Teams
Stage 3 Work on the problem

Topic Make an agreement
Stage 2
Build up trust
Relation-
Communicate openly
ship
Stage 1
Recognise disturbance
Person
control excitement
Willingness to deal with conflict
Fig. 5.29 Process of conflict resolution (Derived from Berkel, 2014, p. 111 ff)
then moves to the relationship, so that effective problem-solving can finally take
place at the topic level.
Recognise Disturbance
Since people take conflicts personally, conflict resolution starts with people. First,
the conflict or the subjectively observed disturbance needs to be seen for what it is.
" Either the conflict parties themselves report to the project manager. Or
the project manager intervenes on the basis of his own personal percep-
tion or assumptions. The focus here is on the form of expression of the
conflict, which can be quite different depending on the person and the
situation. Knowledge of the conflict syndrome and conflict symptoms
provides valuable help in this phase. It is important to note that the
project manager can never know whether a disturbance exists and what
the reasons may be. He can only form hypotheses about it and address
the people involved. It is important that this discussion takes place
bilaterally. No pressure should be built up. If the person addressed denies
a conflict (because it is true or because the person is not yet in a position
to talk about it), he has to accept this as long as the team’s performance
is not affected. Otherwise, the project manager needs to intervene.
Control Excitement
A constructive conflict resolution is not possible in a state of agitation. The parties
concerned have to succeed in activating the “lift to the top” again, i.e. to get out of
archaic emergency programmes and early childhood survival strategies and back
into a state of self-control. Suppressing these feelings only escalates them.
Starting off from affect, it is conversation which best leads best to reason. In
conversation, feelings are put into (rational) words. By talking about one’s feelings
and needs and also by paraphrasing statements made by other (conflict) parties, the
brain is forced to think rationally. If talking is not possible, writing helps. Writing,
like talking, activates people’s rational behaviour patterns and thus allows them to
develop a certain distance from their own feelings.
The project manager, or in more difficult cases a neutral coach or mediator, can
create a space in which people concerned can describe how they are feeling and what it
is they are feeling, and what is is, from their point of view, that has led to this specific
provocation. The person responsible for the project has to be able to listen well and
should be familiar with different question-asking techniques (Sect. 3.9.8). This step is
neither about diagnosis nor about developing solutions. It is much more important to
be able to describe one’s own and others’ emotions, since conflicts are multi-layered.
At this stage the basis for a conflict diagnosis is created.
" The earlier the conflict is dealt with, the easier it is for the parties involved to
understand their own feelings and to classify them. The more a conflict
escalates, the more difficult it becomes for the people caught up in it. It is
important that the people concerned can be convinced that their feelings
are not to be fought. This makes them even more intense, as Watzlawick’s
hammer story shows. The person in charge ought to create a space
wherein he feels safe. Depending on the situation and the level of escala-
tion, it may be useful to involve a neutral third person in the conversation
at this stage. The following questions should be answered together:
• What caused the malfunction?

• Which basic emotions (fear or anger) are activated?
Willingness to Deal with Conflict

The essential prerequisite for conflict transformation is that all parties involved show
the willingness and readiness to manage the conflict. Even if only one party is
unwilling or unable to do so, conflict resolution will not be able to deliver the desired
results. The challenge in conflict is that, according to Glasl’s definition of conflict, it is
always about subjectively perceived differences in feeling, thinking, or acting.
438 5 Teams
" Conflicts disrupt the progress of the project. Therefore, project managers
should want to resolve these problems as quickly as possible. However,
the people involved have very different needs. They may also have
different abilities and ways of dealing with these situations. Therefore,
scrum masters or project managers need enough patience in a conflict to
meet the needs of those affected. They have to succeed in creating
enough urgency for the issue as well. The longer the conflict therefore
lasts, the more it intensifies and the more people are affected.
Build up Trust
Now the space of trust described above (Sect. 5.6.9.1) has to be established. If you
want to maintain trust, you have to be and reveal yourself, you have to be able to
open up and share your ideas and feelings. However, this opening up is always
comes at a risk: Openness and honesty can get exploited. That is why it is so
important to be able to create framework conditions in which all parties feel safe.
" A neutral third party has a great influence on the perceived security in
conflict resolution. Whether it is the person responsible for the project, a
coach, or mediator: if the parties have confidence in this person, they
become able to engage in the process. It is important that the third party
is accepted in his or her role by all parties to the conflict. Furthermore,
rules should be laid down that are binding for all involved in the process.
It is helpful to accommodate the other side with realistic proposals and
to ensure that their personal motives and intentions are understood.
Communicate Openly
Directly linked to trust is openness of communication. This, too, takes place at the
relationship level. Good personal communication skills (Sect. 3.9) are essential for
this, which includes:
• Communication without judgement.

• I-messages instead of you-statements.
• Communication square: Revealing oneself and stating one’s concerns in a com-
plete message.
• Avoiding interpretations: Clarify discussion points through active listening and
other questioning techniques.
Work on the Problem

The preconditions for effective problem solving at the substantive level have now
been created. The concrete approaches to this are listed in Sect. 5.6.10.
Make an Agreement
Starting points for sustainable conflict resolution are concrete measures and
activities, personal behaviour, or also a change in personal evaluation (Sect. 3.5.6).
The more clearly (or “SMART”) the agreements can be defined, the greater the
likelihood that conflict resolution will be successful. In this phase, small steps are to
be appreciated as successes. However, the parties should not be hastily satisfied with
specific results, but ought to continually ensure that perceptible and sustainable
improvements can be achieved.
5.6.9.4 Harvard Concept in Conflict Management
Behind every conflict there is a negotiation. Either it failed or it never took place (Michael
Bullinger).
If we see a conflict as two elements that are incompatible or opposed, the question
arises as to how these two elements can be connected or reconnected. Negotiation,
according to the Harvard concept, can make a valuable contribution to this (Sect. 4.
10.4). The clear separation between people and problems makes it possible to argue
intensely about content while maintaining respect for the person. The focus lies on
the interests and allows for a balance to be established between the parties to the
conflict. In Fig. 5.30 the process of conflict resolution is presented, oriented towards
the Harvard concept.
Choose the best possible alternative Separate people and things

Implementation and Protect relationship
control 6 building up trust
5 1
Criteria
Evaluate ideas,
build up results on
objective decision- What is it about?
making principles 4 2
Basic conflict diagnosis:
what is clear? unclear?
Possibilities agreement/ difference
Creative choices for the 3
common interests,
New solutions Interests and needs
Do not remain in positions, give space to feelings,
self-image and a external image
Fig. 5.30 Conflict management according to the Harvard concept

440 5 Teams
Separate the Person from the Issue

Depending on the escalation level of a conflict (Sect. 5.6.8.1), the conflict parties are
still exposed to their basic emotions of anger or fear. It is therefore important to first
(re-)create a space in which the parties feel safe and in which they can develop trust
in the other side and possibly in the neutral mediator. Every person needs different
amounts of time for this process.
"
• The conditions described above for constructive conflict resolution
have to be created before the process itself can begin.
• All parties to the conflict are able to state their needs and impose
conditions on the process.
• Roles need to be clarified: Which conflict parties are actively involved
in the process? Who is responsible for the process? What tasks,
authorities, and responsibilities does this person have?
• Rules for the process of conflict resolution have to be agreed upon:
What rules apply to communication? How do we deal with breaches
of the rules? Who is the referee? Who makes which decisions?
• Depending on the level of escalation of the conflict, the conflict
parties need to choose a neutral third party to moderate through
the process, or even an authority that separates the opposing parties.
What Is It About?
The vast majority of conflicts are not characterised by dissent about simply every-
thing. The first step in this phase is therefore to first identify and subsequently protect
areas of agreement. In a second step, the effective differences and thus sources of
conflict are either worked out or confirmed. Ideally, in this situation a conflict
diagnosis (Sect. 5.6.7) has already been carried out. Otherwise, the diagnosis has
to now be carried out at the same time.
"
• Discuss the results of the conflict diagnosis. Identify the effective
differences.
• Do not be satisfied too quickly with a realisation: Complaining about
the situation, the framework conditions or other (absent) persons
such as the superior, the project owner, or the supplier is usually
easy. In every conflict, those involved have their own part to play as
well. It is usually much more difficult to shed light on this.
• Moving from symptoms to causes: The systemic phenomenon (Sect.
5.6.2) and the displaced are in conflict with substitute satisfactions
(Sect. 5.6.7.2).
Interests and Needs

In many cases, parties to a conflict are so preoccupied with their anger at the other
party or with a fear that they no longer feel themselves. They can hardly say what’s
missing and what they need. In this phase, the parties ought to be able to take the big
step of freeing themselves from their ego-centredness and of complementing their
own self-image with that of others. If the parties involved can see points of contact in
common interests and needs, the prerequisite for a viable conflict resolution is
thereby created. They can step back from their present position and open up to
future interests and needs.
Example
Robert Dilts has developed the meta-mirror for this purpose. You can use it alone
or with a coach. In a nutshell, it works like this: You put two chairs face to face:
Chair 1 for you, chair 2 for your conflict partner. You imagine that your
counterpart is sitting on chair 2. You sit down on chair 1 and tell your counterpart
what you appreciate about him or her and what you expect and want to be
different in the future. Then you get up and stand behind chair 1 and describe
your own behaviour in relation to your conflict partner. Then you sit down on
chair 2 and ask yourself: How do your words feel when heard by your opponent?
What do you feel? What good intentions do you discover behind the behaviour of
the conflict partner? Now stand sideways to the two chairs. From this meta-
position, describe the interaction between the two people. What do you think of
your own behaviour? How do you judge the behaviour of your conflict partner?
How are they both dealing with each other? Which metaphor might describe this
interaction? What ideas do you have from being in this position: What would you
like to do differently in the future? What skills can you use to achieve this? Now
go back to the second position. Evaluate the solution idea from this perspective.
Back to the first position, determine how you see the communication. What has
changed and how? Change your position between chairs 1 and 2 until you are
satisfied with your new perception. Using a concrete situation, imagine how you
are going to communicate with this person in the future. ◄
The conflict onion shown in Fig. 5.31 illustrates this differentiation. It works
directly with the people involved in the conflict on far-reaching conflict situations.
"
• Through solution-oriented questions, a positive picture can be drawn
on the basis of which an improvement of the situation might be
achieved: “How are we able to recognise that the conflict has been
managed? What would be different then compared to the current
situation?”
• Circular questions can ask one party to see things from the other’s
perspective: “If I were to ask colleague M, what do you think he really
442 5 Teams
cares about?” Or: “What interests is he pursuing with this project, what
is really important to him?”
• The “miracle” question can also open up new perspectives: “Imagine
that the conflict has been overcome. You are, in this imagined situa-
tion, motivated and committed to your project again: What would
indicate to you that that is the case?”
• Paraphrasing or active listening can always be used to mirror and
clarify the answers.
Possibilities
The more choices that are available, the better the decision that is made. This phase
thrives on the participants being able to break free from their existing patterns of
thinking and behaviour in order to develop approaches to solutions that may not yet
correspond to the common organisational culture. All approaches that make it
possible to come a little closer to the common interests should be quickly grasped.
Only diligence and pressure will make it difficult to develop these possibilities. What
it takes is a surplus of attention enabling there being space for creativity (Sect. 1.7.2).
Positions
Things that a party pretends to WANT TO HAVE
► Short-term focus
Interests
Things a party really WANTS
► Medium-term desires
Needs
Things that a party
NEEDS TO HAVE.
► Long-term central
Fig. 5.31 Conflict bulb

" • Creative solutions are scarcely possible under time pressure. It often
takes several attempts to develop viable or even high-quality options.
The parties and the facilitator then have to admit that they need
more time.
• Ideas for solutions from external people can be valuable in this phase.
Criteria
The joint discussion of objective criteria that can be applied to the selection of the
negotiating alternative facilitates the abandonment of positions and reduces there
being a basis for exerting unfair pressure.
"
• In case of real conflicts, those responsible for the project have to
ensure that the decision-making criteria are in line with the
requirements of the project order or product vision.
• For solutions outside the existing requirements, consult the product
owner or the project owner.
Choose the Best Possible Alternative

The BATNA principle is suitable for selecting the best possible alternative (Sect. 4.
10.4.5). Once a decision has been made, the most important thing for project
managers is to then demand commitment to the chosen solution from all parties
concerned.
" A kind of action plan determines who has to do what by when in order to
realise the chosen solution. Controlling this is also a responsibility of
those in charge of the project: if those affected fall behind with their
contributions or even relapse into old behaviour patterns, this needs to
be noticed early on. Corrective measures need to then be initiated.
5.6.10 Conflict Resolution Depending on the Type of Conflict
The basic approach to conflict resolution outlined above is elaborated here with
recommendations for managing specific types of conflict as specified in Sect. 5.6.6.
5.6.10.1 Goal Conflicts and Conflicts of Interest

Conflicting Goals
At an early stage in the project, conflicting goals can be clarified by means of written
goals formulated as SMART as possible. These objectives should also, in the spirit
of MbO, be agreed upon and not simply specified (Sect. 4.6.1). If a goal conflict
arises in a later phase of the project, it has to be dealt with using the change request
procedure. The different levels of authority of the project committees are to always
444 5 Teams
be taken into account (Sect. 2.3.8). Often, in the case of goal conflicts or conflicts of
interest, the systemic phenomenon has an effect because the orders are unclear or
contradictory. The shortcomings of an unclear order manifest themselves sooner or
later in the project team as conflicts.
It is part of the project manager’s task to point out differences or contradictions in
the project objectives as formulated and to suggest solutions to those responsible for
the project. If the contradictions are not addressed by the project owner, project
manager, and project committee (decision-makers), but are rather delegated to the
project organisation, they then tend to become evident among the employees.
Conflicts of Interest
It is very difficult to bring all the different stakeholder interests in a project down to a
common denominator. With a sound stakeholder analysis, the diverging interests of
the stakeholders become visible. This way they can be dealt with. Especially for
acceptance and pioneer projects (Sect. 1.2.1), the on-going management of stake-
holder interests is an important task that needs to be attended to in order to identify
potential conflicts at an early stage.
5.6.10.2 Distribution Conflicts and Resource Conflicts

Every project therefore faces the challenge to achieve its goals with human, finan-
cial, and technical resources. The tension this causes cannot, in principle, be
resolved. Within the project, the project manager has to anticipate, point out
divergences, and propose solutions to the decision-makers. Often, however, project
managers need to also learn to put pressure on their project owners in order to receive
the allocated resources they are entitled to according to the project order.
In resource conflicts, the systemic phenomenon (Sect. 5.6.2) has its effect: If
insufficient resource planning is made for employees in the line organisation, this
also finds its reflection in the project teams. Those who do not know their available
resources may start many more projects than they can handle. If resource planning
and allocation are not decided at the level of decision-making authority in the
project, the conflict is delegated to the project team. The consequences arising
from this are:
• Relationship conflict: The conflict manifests itself between people in the project
team, e.g. between project manager and sub-project manager.
• Personal conflict: The project manager tries to compensate for the deficit. This
increases the workload and leads to a loyalty dilemma or motivation problems.
In larger organisations, multi-project management (Sect. 2.7) and a project

portfolio can defuse major points of friction. Over-allocations of individuals become
apparent in multi-project management and can only be solved, or at least mitigated,
by prioritising them in the project portfolio. The prerequisite for this, however, is that
the responsible bodies also take responsibility for multi-project management and, in
case there are over-allocations, make the necessary decisions. This means that
on-going projects are then stopped, slowed down, or cancelled.
5.6.10.3 Structural Conflicts and Organisational Conflicts

Structural conflicts mainly concern project organisations that are linked to the line
organisation via a matrix or coordination form (Sect. 2.3.8.8). The project manager
can make this problem transparent. It is very difficult to bring about a change,
though, as this would influence the management system of the line organisation.
The most the project manager can do is to obtain optimal framework conditions for
his project work through his project owner. In addition, he needs to adapt his
leadership style accordingly: In a project coordination he leads laterally (Sect. 2.3.
8.5). If structural or organisational conflicts are not negotiated and decided, but
solved with “lazy compromises” or with “work-arounds”, conflicts only get shifted
or delegated to other bodies.
5.6.10.4 Evaluation Conflicts and Procedure Conflicts

Man as a non-trivial system is unpredictable. Each individual has different points of
view, different convictions, and is able to change his mind. Evaluation conflicts can
be avoided if the decision-making mode is determined in advance before any
decision is made. A consensus decision is indeed a worthy goal. Since everyone
involved rarely has the same opinion as everyone else, a consensus or even a
majority decision has to be a possible scenario. In certain situations, project
managers or project owners need to also reserve for themselves a right of veto.
The most important measure to avoid evaluation conflicts is the project order. The
project manager is responsible for negotiating it until it is completely clear and he
knows against which objectives he will be judged. The project organisation with the
RACI matrix or the function diagram helps to determine at an early stage who is
responsible for which deliverable or work package. These tables also make it clear
which decision-making competences the project owner claims for himself and what it
is he delegates to the project team. For the project manager, the process competence is
in the foreground. He has to be able to delegate requests for technical decisions to his
experts in the team because he does not himself have the expertise to do so.
If different convictions and points of view become more acute in a scrum team, it
is the task of the scrum master to intervene and mediate. A retrospective serves as the
means by which possible discrepancies are made visible and dealt with.
5.6.10.5 Role Conflict

Role conflicts exist on two levels:
• Formal level to define the roles: WHAT are the tasks and responsibilities of the
project manager or product owner (Sect. 5.3.1)?
• Informal level of the lived role: HOW is this role fulfilled? HOW is the interface
between organisation and person designed (Sect. 5.3.3)?
Formal Level
The formal structure of the project roles in the traditional approach is well known
(Sect. 2.3.8.2), but this structure varies greatly depending on the connection of the
project to the line organisation: If the project is integrated into the line organisation
446 5 Teams
via coordination, the project manager has almost no decision-making authority. As

coordinator, he is responsible for ensuring that the relevant line managers receive the
relevant information and so have a basis for decision-making. In matrix integration,
coordination with line managers is challenging, too, especially when the project plan
is in flux and resources have to be re-planned. In principle, formal role conflicts can
be prevented through a well-founded project order or clarified afterwards. The RACI
matrix or the Belbin team role concept also provides valuable services here.
The formal roles in agile project teams are clearly defined. Agile project manage-
ment is ideally handled in a pure project organisation. Self-organisation works best
when forces are fully concentrated on the project. It is difficult for the product owner
to accept the sprint results of the developers if he is not equipped with the decision-
making authority to do so. If he is dependent on some committee of the line
organisation for his decisions, this slows down the progress of the project, too.
The product owner also loses his status vis-à-vis the scrum team. He has to see to it
that he has enough resources for his task. Both aspects have to be clarified with the
decision-makers in the line organisation.
Informal Level
The lived role takes place at the point of contact between the organisation and the
person (Sect. 5.3.3). The organisation is composed of several role senders. As a role
carrier, each person brings his unique persona, character and imprint to the project
role, in whichever way it is defined in terms of content. Sometimes we send out
messages to people that we are not aware of. Moreover, we can never know how we
come across to other people.
If we want to clarify conflicts in relation to the lived role, we depend on being able
to constantly compare our self-image with the images of others. Therefore, our
communication skills are of fundamental importance. We depend on receiving feed-
back from our colleagues again and again (Sect. 3.9.7) and must deal with it construc-
tively. In order to get a better picture of how we are seen by other people, the Belbin
team roles are helpful here as well. The approach emphasises that very different
competences are needed in a team. In addition, it allows us to recognise differences
by comparing self-assessment and assessments made by others and to work on them.
5.6.10.6 Personal Conflict

In Sect. 5.6.2 it is explained that conflicts as a consequence of the systemic
phenomenon manifest themselves superficially as personal and social conflicts.
Lack of resource planning, unclarified project priorities (project portfolio), and the
coordination between those responsible for the project and the line managers (project
coordination and matrix organisation) are often causes for conflicts being delegated
from the organisation to the project, thus challenging the individuals.
This conflict can be managed if the person responsible for the project recognises
that he or she is a symptom bearer and is able to refer the conflict back to the body that
caused it. The best outcome would be that the project owner or the line manager
recognises that there is a requirement for action in the area of change request manage-
ment. The quality of the project work has to be guaranteed, and those involved in the
project need to be protected from conflict. In order to achieve this optimal result, the
project manager needs high competences in the area of negotiation Sect. 4.10.
The challenge in this situation is that in a delegated conflict, the responsibility for
action is with the symptom bearer and not with the party responsible for the cause of
the conflict. This means that the symptom bearer still has to take time for this
delegated conflict under the operational pressure of project implementation. This
starts an avoidance–avoidance conflict. The more time a person takes for fighting the
cause, the less time they have for other obligations.
" In the avoidance–avoidance conflict, the people involved face a dilemma.

This can often neither be resolved, nor can those concerned have any
expectation that there might be a good solution to it all. If the external
situation cannot be changed (e.g. if no structured change request man-
agement is set up), the following options remain (Sect. 3.5.6):
• One might change one’s own behaviour and no longer accept change
requests after a certain project phase. In doing this, the project
manager naturally takes a risk because it does not correspond to the
usual project management culture and could therefore be sanctioned
by line managers or employees.
• One might change the assessment and thus accept that permanent
changes in the scope are part of everyday life in this organisation, with
all the consequences for the project itself as well as for oneself.
• Of course, one can also try to suppress the whole thing. Most of the
time, this only works in the short term in project work, because all
kinds of omissions and deficits have an influence on the magic
triangle and thus become visible through time delays, budget
overruns, or changes in scope.
" In the worst case, if personal stress increases more and more despite the
attempt to reassess, the affected person has to even protect himself from
an uncontrollable stress reaction (Sect. 3.5) and give up project responsi-
bility or even change jobs.
5.6.10.7 Relationship Conflict (Social Conflict)
Communication
Within a social conflict, verbal and non-verbal communication always have friction
potential. The well-known phrase “I only know what I have said when I know the
message that has reached the receiver”, challenges us again and again to open
ourselves to the subjective truth of the other person.
448 5 Teams
The best way to manage a communication conflict is through direct discussion. A

distinction needs to be made between effect and evaluation. As shown in the conflict
syndrome (Sect. 5.6.3), communication always suffers in conflicts, which also makes
it an effective intervention. Developing communication skills should be a matter of
course for all project participants. Those responsible for the project are also called
upon to ensure that regular communication opportunities are installed in the teams.
Proximity Versus Distance

Project managers assume a leadership function. As a result, they are dependent on
having authority to issue directives and take decisions vis-à-vis their team. The better
the role is clarified and the better the project order is formulated, the lower the
potential for friction should be. However, all those involved ought to always be
aware of who is in which role and when. Especially if project managers used to be
work colleagues, they need to develop a good instinct for when they can still be
colleagues and in which cases they need to distance themselves more in order to do
justice to their responsibility and role.
Territory
In its interdisciplinary cooperation, a project team always has the task of connecting
different areas of competence and thus territories. Often the project objective has
consequences for existing territories, be it production in the case of development
projects or the processes of the line organisation in the case of change projects. This
always questions existing power structures. Project managers often do not have the
power to deal with these tensions themselves. Rather, they have to secure the support
of the decision-makers within the framework of the mandate.
Ranking
Often project managers do not have the same status as managers in the line
organisation. There may also be people in the team who are higher up in the line
organisation than the project managers. If project managers are not acknowledged in
their roles, they become ineffective. Again, it is important that they are supported by
their decision-makers and that all people involved in the project are aware of which
line managers are behind the project. Clarifying the hierarchy is best achieved at the
kick-off: If the project owner is present and officially assigns the project manager or
product owner to his role in front of the assembled project team, these roles are far
more effective than if this does not happen.
Leadership
Product owners and project managers fill exacting management positions. They have
often shown themselves as being qualified for these tasks through their expert roles.
Their competences in this situation are largely of a technical-content nature. How-
ever, this is not enough in view of the challenges that product owners and project
managers have to overcome. Here, process and decision-making competencies are
required. Project owners who cannot let go of technical details demotivate their
teams and create confusion. This then often manifests itself in relationship conflicts.
" How do we deal with the chemistry not being right? What if the project
manager dislikes one of his sub-project managers and has negative
feelings every time he meets him? In such situations, the ability to self-
reflect helps (Sect. 3.3.4): Our own feelings have much more to do with
ourselves than with other people. The reasons why a sub-project man-
ager appears unlikeable to the project manager can be manifold, here is
a list of some the possible reasons:
• The sub-project manager has very different character traits compared
to the project manager. If the project manager is a strong shaper in
the sense of the Belbin team roles and the sub-project manager is a
completer finisher, there is potential for conflict (Sect. 3.10.2).
• Project managers and sub-project managers show different
expressions of their basic needs. For example, a high need for status
and recognition can clash with a strong need for security (Sect. 3.3.2).
• It is also possible that it is a projection: The project manager projects
something he does not like about himself onto the sub-project man-
ager. If the project manager is not able to do solid project planning
and accepts this as being his own weakness, he could accuse the
sub-project manager of being unreliable and of not fulfilling his
obligations. But perhaps the sub-project manager has the wrong
face, the wrong name or it may just be some other quirk that on a
subconscious level reminds the project manager of a person with
whom he has once had a bad experience.
" In all situations, feelings need to first be allowed and not fought. Then,
after self-reflection, they can later be classified and evaluated. Since the
project manager “only” has to work with his sub-project manager on a
professional level, sympathy is not absolutely necessary. It is sufficient if
there is respect and as long as the goals that have been agreed upon are
achieved. This requires role clarification and an adequate leadership
style. The essential needs for affection, sympathy, and love are met by
the world of relationships and the world of self (Sect. 3.10.1). It would be
an undue demand to try to satisfy these needs in the professional
environment. One has to stop questioning oneself and be able to accept
that the chemistry is not right with a specific person. If, in the sense of
personal change strategies (Sect. 3.5.6), repression of antipathy and
reassessment of the situation are not possible, there is always the possi-
bility of changing the situation by reducing or breaking off contact with
this person.
5.6.10.8 Conflict of Values

Values are an essential part of our personality. This explains why it is so difficult to
manage conflicts of values. Every virtue is opposed by a sister virtue. Such value
pairs are, for example, trust and caution, assertiveness and consideration, or structure
and flexibility. To be in balance with both virtues, to be able to live both qualities, is
what constitutes professionalism.
450 5 Teams
Values Become Unvalues

Every value also has a negative exaggeration, as shown in the square of values
according to Friedemann Schulz von Thun Fig. 5.32. As an example, the value of
structured work, which stands in the foreground in monochronic organisational
cultures is discussed (Sect. 5.4.5). Being able to work in a structured way is
important in project management. All project management, whether agile or tradi-
tional, is based on this. But there is also “too much of a good thing”, which is called
(devaluing) exaggeration. However, it is just as important to be able to deviate from
plans or to be able to take “detours” in the event of changes or problems, i.e. to be
flexible. Here, the exaggeration would lie in leaving out all planning in order to then
proceed chaotically.
Example
Anyone who plans activities in detail in a traditional project that are to take place
in 10 months is pedantic. The planning effort is enormous. The risk that some-
thing will change is very high. ◄
The opposite of structured work is flexible work. For this, chaotic work is the
direct opposite form of exaggeration to pedantic work. Thus, there are two new pairs:
structured work being in a state of positive tension with flexible work. The respective
Network of relations between the four poles of the value square
positive tension ratio

structured flexible
devaluing exaggeration
devaluing exaggeration
Development
pedantic chaotic
overcompensation
Fig. 5.32 Example of value square for structured working method

exaggeration results in the negative value pair described by the terms pedantic and
chaotic.
The development is that one can use both values as virtues, though there is the
danger of getting lost in the exaggeration of the sister virtue. This is done in an effort
to fulfil the other virtue, which one is not so familiar with, as well as possible
(overcompensation). The constructive handling of such value conflicts means the
simultaneous development of both sister virtues. This brings the human qualities into
balance.
5.6.10.9 Summary of Conflict Resolution

The overview in Fig. 5.33 summarises a small selection of strategies and approaches
that can be helpful in dealing with specific types of conflict.
5.6.11 Conflict Prevention

Since project work is usually also prone to conflict, possibilities for the best possible
prevention are shown here.
Connection of the project to

Multiproject management
Clarify expectations with
the line organisation
Agree on common
Manage dilemma
decision makers
rules of conduct
project portfolio
Clarify roles
RACI Matrix
Negotiate
Goals and interests
Distribution and resources
Structure and organisation
Evaluation
Rolle
Relationship
Person
Values
Fig. 5.33 Conflict management strategies per conflict type

452 5 Teams
5.6.11.1 Project Management Methodology
Either you look for the conflict at the beginning of the project, or it finds you during the
process.
By far the most effective prevention at the root cause level is careful application of
project methodology. If goals or visions are clear, stakeholder interests analysed, the
project structure plan and detailed planning supported by the effort estimates, the
project organisation defined, the availability of resources clarified, and communica-
tion platforms established, then conflicts have less of a chance of coming up. If
contradictory or irreconcilable elements are found in the documents, they have to be
dealt with in a methodically transparent manner. If not, the potential for conflict will
not simply dissipate, but will instead unfold with greater intensity in a later project
phase.
5.6.11.2 Disruptions Have Priority

The conflict syndrome (Sect. 5.6.3) enables us to initiate preventive measures where
conflicts might escalate: communicate openly, confront and correct distorted
perceptions, take confidence-building measures, and reinforce common goals.
Changes in the behaviour of people in the project team and thus symptoms of
conflict (Sect. 5.6.4) are early indicators of disruption. Project managers and
scrum masters must sensitise themselves to these early indicators of conflict. A
postulate of Theme-Centred Interaction (TCI) according to Ruth Cohn is:
“Disruptions have priority”: The earlier these are dealt with, the easier it will be to
develop coping strategies that are satisfactory for all parties involved. The longer one
waits, the higher the intensity of the conflicts are going to be, as explained in the
escalation levels in Sect. 5.6.8.1.
The primary means of preventing these escalations as they emerge is the infor-
mation and communication concept (Sect. 2.4.10.2). Once all internal and external
stakeholders have been identified and assessed, target-oriented platforms for com-
munication have to be installed. These are supplemented with the competences of
personal communication (Sect. 3.9) and thus form the foundation of cooperation.
Meetings also bolster communication, relationship building, and relationship main-
tenance. Trust is built through relationship. Trust enables open dialogue and a
culture in which the best solution can be argued for in the spirit of “hard on the
issue, soft on the person”.
5.6.11.3 Conflict Skills and Frustration Tolerance

Two areas of competence at the personal level conclude this chapter.
Conflict Skills
A person’s ability to deal with conflict is reflected in the extent to which he or she
can endure conflicts and manage them fairly. Conflict capacity is based on the
personal attitude that any situation, no matter how difficult, can somehow be worked
through and that benefits can come from any conflict. This attitude is closely related
to resilience (Sect. 3.8.4). Conflict-capable people are convinced that the energy
developed in the conflict can be used positively. Differences and disagreements are
seen as integral parts of life. Conflicts are managed profitably with the conviction
that working on differences moves people and organisations forward. This is not
possible in an “either-or” way of thinking. In dealing with polarities, people must be
able to engage with the “as well as” (Sect. 5.4.5). Table 5.15 presents the ability to
deal with conflict as a link between conflict aversion and belligerence.
The exaggerated good becomes evil (F. Glasl).
Frustration Tolerance
Frustration tolerance as a competence is assigned to people who do not always have
to assert their own goals (Kreyenberg, 2005, p. 219). The sister virtue of conflict
ability is frustration tolerance. Even young children have to learn that they can’t have
everything, that things don’t always go the way they want them to. It is the same in
professional life. There are customers, superiors, and organisational cultures that do
not correspond to our ideal. We must always be able to realise that we are limited in
our possibilities and abilities, on the one hand, and that the project organisation will
not work perfectly, on the other.
5.6.12 Dealing with Crises
Crises are sudden and unexpected events that cannot be handled with the usual and more or
less standardised management methods (Wastian et al., 2015, p. 292).
Crises can arise in any project. A project crisis is a situation in which the progress of
the project is blocked or severely restricted and the achievement of the project
objective is at risk. A crisis therefore requires immediate intervention. This is a
non-delegable management task of the project manager. A crisis can have its origin
in the (project) organisation itself. However, they are often caused by conditions
from outside the organisation.
Table 5.15 Basic assumptions on conflict capacity (Glasl, 2008, p. 13)

Conflict aversion Conflict skills Belligerence
Conflicts only cost energy, so Aggression is energy: I In conflicts I experience
keep your hands off them! redirect it positively! myself, they increase vitality!
Open conflicts destroy many Conflicts help to break Only from chaos does
things unnecessarily! away from old habits! something new really
emerge!
Conflicts only deepen the Differences are vital, Consensus is often illusion,
differences. Differences are working on differences because: “War is the father of
basically not solvable! enriches everyone! all things!”
454 5 Teams
5.6.12.1 Internal Causes of Crisis

There are a number of warning signals or indicators of impending crises. Examples are:
cumulative cost overruns, unfinished partial results, lack of decisions, dwindling moti-
vation and lack of commitment of those involved in the project, cries for help from the
project. Crises are exceptional situations and therefore require a special procedure and
adequate organisation. Crises are dealt with in different phases. The following measures
can help to identify and deal with internal causes of crises as early as possible:
• Careful and periodic risk management and controlling of “scope”, “time”, and
“costs”.
• Identifying indications for the conflict syndrome (Sect. 5.6.3) and for conflict
symptoms (Sect. 5.6.4) and aspects of group dynamics (Sect. 5.2).
• Cultivating an open culture of discussion, regular, personal agreements as well as
measures relating to conflict prevention.
5.6.12.2 External Causes of Crisis

In spite of all caution and professionalism, project crises can hit project teams
unexpectedly from the outside. Reasons for this may, for instance, be that project
participants are at that moment suffering a crisis in their personal environment. This
can paralyse their ability to work as required of them and also affect the team as a
whole. However, an important supplier can also fail, a customer might go bankrupt
or a hacker attack occurs that may paralyse the entire infrastructure. Large
organisations operate crisis teams in preparation for worst-case scenarios. However,
project organisations are too small for this. The following measures can help to
identify and deal with external causes of crises as early as possible:
• Regular and active stakeholder management.

• Risk management measures such as credit checks or second source suppliers.
• Rapid intervention and assistance when project participants experience a personal
crisis.
" The moment a crisis gets noticed, the current state at that moment
should be documented as well as possible. Just as the police immediately
take photographs of evidence in the event of a car accident. If, for
example, a product owner is no longer available and is replaced by
another person, just at the moment of taking over a comprehensive
as-is recording of the product concept, the product backlog, a release
plan and also of the costs incurred need to be established.
5.6.12.3 Leadership and Communication

Crises are a matter for the boss. Project managers, scrum master, and product
owners are to deal with crises immediately. They need to also inform their superiors
in the line organisation instantly. A task force has to be set up that takes on
responsibility for managing the crisis. Depending on the assessment of the situation,
References 455
Table 5.16 Guiding principles in crisis communication (Alter, 2008, p. 120)

As a manager, inform . . . Provide concrete information about . . .
Active and not reactive Victims
Rapid and continuous Damage
Always first the directly affected Consequences
Truthfully and empathetic Immediate measures
Never say: “no comment”! Investigations
the accountable hierarchical levels have to be represented in it. Crises are unsettling.
They generate fears. That is why communication is central in crisis situations. Base
your communication in crises on the guiding principles in Table 5.16.
5.7 Finally. . .
There is nothing good unless you do it (Erich Kästner).
The complexity and dynamics to which projects are exposed today place very
high demands on those responsible for projects. With this handbook on project
management, we have endeavoured to elaborate all critical success factors for
project work in a differentiated manner. Many different competences are required
for the success of complex, interdisciplinary projects. That is why we have here
connected the methodological foundations to the people who work in project teams,
teams that have to be led. These levels interact with each other.
We hope that you will always be able to derive new, creative impulses from it in
order to cope constructively and successfully with the challenges in your project
work. Projects are social systems in a permanently changing environment. This
repeatedly challenges everyone involved. So, you yourself are also challenged and
invited again and again—and in the spirit of Erich Kästner—to do good for your
projects.
References
Alter, U. (2008). Informieren als Führungsaufgabe. In T. Steiger & E. Lippmann (Eds.), Handbuch
Ballreich, R., & Hüther, G. (2009). Du gehst mir auf die Nerven! Neurobiologische Aspekte der
Konfliktberatung. Concadora Verlag.
Berkel, K. (2014). Konflikttraining. Windmühle Verlag GmbH.
Claßen, M. (2019). Spannungsfelder im Change Management. Handelsblatt Fachmedien GmbH.
Doppler, K., & Lauterburg, C. (2014, Auflage 13). Change Management, den
Unternehmenswandel gestalten. Campus.
Edmondson, A. C. (2018). The fearless organisation (1st ed.). Wiley.
Gellert, M., & Nowak, C. (2007). Teamarbeit – Teamentwicklung – Teamberatung (3rd ed.).
Limmer Verlag.
Glasl, F. (2004). Konfliktmanagement. Ein Handbuch für Führungskräfte (8th ed.). Haupt Verlag.
456 5 Teams
Glasl, F. (2008). Selbsthilfe in Konflikten. Haupt Verlag.

Klein, P., & Limberg-Strohmaier, S. (2012). Das Aufstellungsbuch – Familienaufstellung,
Organisationsaufstellung und neuste Entwicklungen. Braumüller Verlag.
Königswieser, R., & Hillebrand, M. (2004). Einführung in die systemische Organisationsberatung.
Carl-Auer-Systeme Verlag.
Kreyenberg, J. (2005). Konflikt-Management. Cornelsen Verlag.
Lippmann, E. (2008). Konfliktmanagement. In T. Steiger & E. Lippmann (Eds.), Handbuch
Little, J. (2014). Lean change management. Happy Melly Express.
Rogers, E. M. (2003). Diffusion of innovations. Free Press.
Rosselet, C., & Senoner, G. (2010). Management macht Sinn – Organisationsaufstellungen in
Managementkontexten. Carl-Auer-Systeme Verlag.
Satir, V., et al. (1991). The Satir model. Science and Behavior Books.
Schmidt, E. R., & Berg, H. G. (2008). Beraten mit Kontakt. Gabal Verlag.
Schwarz, G. (2014). Konfliktmanagement. Springer.
Seliger, R. (2014). Positive Leadership – Die Revolution in der Führung. Schäffer-Poeschel Verlag.
Seligman, M. (2012). Flourish: A visionary new understanding of happiness and well-being. Atria
Books.
Steiger, T., & Lippmann, E. (Eds.). (2008). Handbuch angewandte Psychologie für Führungskräfte
(Vol. I&II, 3rd ed.). Springer.
Tamm, J., & Luyet, R. (2005). Radical collaboration. Harper Collins.
Wastian, M., et al. (2015). Applied psychology for project managers. Springer.
Watzlawick, P. (2004). Anleitung zum Unglücklich sein. Piper Verlag.
Weber, G., & Rosselet, C. (2016). Basics des Aufstellens von Organisationen und
Arbeitsbeziehungen, Grundlagen und Vorgehensweisen. In G. Weber & C. Rosselet (Eds.),
Organisationsaufstellungen – Grundlagen, Settings, Anwendungsfelder. Carl-Auer-Systeme
Verlag.
Zaninelli, S. (2005). Chancen und Herausforderungen weltweiter Zusammenarbeit über die
Entfernung. In Wissensmanagement in der IHK-Organisation. Geschäftsfeld International.
Further Readings
Doppler, K. (2017). Change – wie Wandel gelingt. Campus Verlag GmbH.

Euforia. (n.d.). From inspiration to impact. https://www.euforia.org
Hüther, G. (2016a, 2001). Bedienungsanleitung für ein menschliches Gehirn (12th ed.).
Hüther, G. (2016b, 1997). Biologie der Angst. Wie aus Stress Gefühle werden (13th ed.).
Reference List for the Individual
Competence Baseline (ICB) from IPMA 6
(International Project Management
Association)
Section 1.8 describes the standards and certification models in project management.
Like IPMA, this Project Management Handbook covers the various competences for
project management and is not designed for a defined process-oriented framework.
The basis for IPMA certification is the Individual Competence Baseline (ICB).
IPMA structures the necessary competences on the basis of the “Eye of Compe-
tence” (Fig. 6.1).
Table 6.1 lists references between the Swiss Individual Competence Baseline
(Version 4.0) for Project Management and this Project Management Handbook and
in that way supports people preparing for IPMA certification.
The referencing can also be used analogously for the two Swiss ICB for
programme management, and portfolio management can also be applied mutatis
mutandis. However, the adaptation to programme management and portfolio man-
agement needs to be made by the reader.

https://doi.org/10.1007/978-3-662-66211-3_6
458 6 Reference List for the Individual Competence Baseline (ICB) from. . .
People Practice
People Practice
Perspective
Perspective
Fig. 6.1 Eye of competence from IPMA (International Project Management Association)
6 Reference List for the Individual Competence Baseline (ICB) from. . . 459
Table 6.1 Swiss individual competence baseline (ICB) version 4.0

Competence Competence indicators Section in the book
Competence area context (perspective)
1.01 Strategy 1.01.01 Align the project with the 1.2.3, 2.3.2, 2.3.4, 2.7.3, 2.
mission and vision of the organisation 8.3, 2.8.4
1.01.02 Identify and exploit 1.2.3, 1.4.2, 2.2.2, 2.2.3, 2.
opportunities that influence the 3.9
organisation’s strategy
1.01.03 Develop justification for the 1.9, 2.2.2, 2.2.3, 2.3.2, 2.
project and ensure that the business 3.10, 2.5.6, 2.5.7, 2.7.1, 2.
and/or organisational reasons that led to 7.4
the project still exist.
1.01.04 Determine, assess, and review 2.2.1, 2.3.1, 2.7.1, 2.9.2
critical success factors
1.01.05 Determine, assess, and review 2.3.1
key performance indicators (KPI)
1.02 Governance, 1.02.01 Know the basics of project 1.1–1.4, 2.1, 2.3.8
structures, and management and its implementation
processes 1.02.02 Know the basics of programme 1.3.1, 1.9, 2.7.3
management and their implementation
1.02.03 Know the basics of portfolio 1.3.1, 1.9, 2.7.1, 2.7.2
management and its implementation
1.02.04 Align the project with the 2.7.4, 2.7.5
support functions
1.02.05 Align the project with the 2.3.5, 2.3.6, 2.4.11, 2.5.6
decision-making and reporting structures
and quality requirements of the
organisation.
1.02.06 Align the project with HR 2.3.5, 2.3.8, 2.5.7, 2.6.4, 2.
processes and functions 7.1.6, 2.3.8.8
1.02.07 Align the project with finance 2.3.5, 2.5.6, 2.5.7
and controlling processes
1.03 Compliance, 1.03.01 Identify and comply with the 2.3.3.2, 2.3.7, 2.3.9.4, 2.3.
standards, and legislation applicable to the project. 9.5, 2.9
regulations 1.03.02 Identify and comply with all 2.3.3.2, 2.3.7, 2.3.9.4, 2.3.
safety, health, and environmental (SHE) 9.5
regulations relevant to the project.
1.03.03 Identify and comply with all 2.3.3.2, 2.3.9.4, 3.2
codes of conduct and professional rules
relevant to the project
1.03.04 Identify and adhere to 2.3.2, 2.3.3.2
sustainability principles and objectives
relevant to the project.
1.03.05 Evaluate, use, and further 1.4, 1.8, 2.3.9.4, 2.7.1, 2.
develop professional standards and tools 7.4, 2.7.5
relevant to the project.
1.03.06 Evaluate, compare, and improve 1.8, 2.7.4, 3.10
the organisation’s project management
competence.
(continued)

1.04 Power and 1.04.01 Assess personal ambitions and 2.3.5, 2.3.9.1, 4.9, 5.5
interests interests of third parties and their
potential impact on the project and use
this knowledge for the benefit of the
project.
1.04.02 Assess the informal influence of 2.3.5, 2.3.8, 4.9, 5.2.2, 5.5
individuals and groups of people and
their potential impact on the project, and
use this knowledge for the benefit of the
project.
1.04.03 Assess personalities and working 3.1, 3.2, 3.4.3, 3.10.2
styles of third parties and use them for the
benefit of the project
1.05 Culture and 1.05.01 Assess culture and values of 1.6, 2.3.5, 2.3.9.1, 3.4, 4.1,
values society and their impact on the project 5.2
1.05.02 Align the project with the formal 2.3.5, 2.3.9.1, 2.3.9.4, 3.4,
culture and values of the organisation 4.1, 5.2
1.05.03 Assess the informal culture and 2.3.5, 2.3.9.1, 3.4, 4.1, 5.2
values of the organisation and their
impact on the project.
Competence area people
2.01 Self-reflection 2.01.01 Identify and reflect on the 3.3, 3.4, 3.8.1, 3.9, 3.10
and self-management influence of own values and personal
experiences on the work
2.01.02 Build self-confidence based on 3.5, 3.8.2, 3.10.2.2
personal strengths and weaknesses
2.01.03 Identify and reflect on personal 3.3.3, 3.5, 3.7, 3.8, 3.10.2
motivations in order to set and focus on
personal goals
2.01.04 Organise own work depending 3.2, 3.5, 3.8, 3.9, 3.10.2
on the situation and own resources
2.01.05 Take responsibility for personal 3.8, 3.10
learning and development
2.02 Personal 2.02.01 Recognise and apply ethical 3.4, 3.9, 5.6.10.8
integrity and values in all decisions and actions
reliability 2.02.02 Promote sustainability of outputs 2.3.4, 2.6.5, 3.8.4, 4.10.3,
and outcomes 5.5
2.02.03 Taking responsibility for one’s 2.8.3, 3.8.4, 3.10, 4.8
own decisions and actions
2.02.04 Act, make decisions and 2.3.14, 2.8.3, 3.5.6, 3.9
communicate without contradictions
2.02.05 Perform tasks carefully to build 3.2, 3.3.5, 5.2.3, 5.3.1, 5.
trust with others 4.1
2.03 Personal 2.03.01 Communicate clear and 2.6.4, 3.9, 3.10.3, 4.11
communication structured information to others and
ensure their equal understanding
(continued)

2.03.02 Enable and promote open 3.3.5, 3.9, 5.2, 5.4.1
communication
2.03.03 Select communication types and 2.3.5, 2.3.6, 2.4.10, 3.9
channels to meet the needs of the target
group, situation, and management level
2.03.04 Communicate effectively with 3.9.8.2, 4.12
virtual teams
2.03.05 Use humour and change of 2.3.5, 3.3.3, 3.3.6, 3.5, 3.
perspective appropriately 9.5, 3.9.8, 3.10.5
2.04 Relationships 2.04.01 Establish and maintain personal 1.5.2, 2.3.6, 2.4.10, 3.3.6,
and engagement and professional relationships 3.4, 3.10, 4.12
2.04.02 Build, moderate, and participate 1.5.2, 1.6.3, 4.11
in social networks
2.04.03 Show empathy through listening, 3.4, 3.9.8
understanding, and support
2.04.04 Show confidence and respect by 1.6.2, 3.3.5, 3.4, 4.4.4, 4.6,
encouraging others to express their 4.7, 5.4
opinions and concerns
2.04.05 Communicate own visions and 3.7, 3.9, 4.4.3, 5.2.3, 5.4
goals to achieve third-party engagement
and commitment
2.05 Leadership 2.05.01 Taking initiative and proactively 2.3.7, 3.8.1, 3.8.4, 3.9.3, 3.
providing advice and support 10.3, 3.10.4, 4.2
2.05.02 Take ownership and show 4.2, 4.5
commitment
2.05.03 Lead and improve the work of 2.3.2, 2.3.6, 3.7, 3.10.3, 3.
individuals and teams through setting 10.4, 4.4.4, 4.6
direction, coaching, and mentoring
2.05.04 Exercise power and influence 2.3.5, 2.3.8, 4.9
appropriately over third parties to achieve
the objectives
2.05.05 Making, enforcing, and 2.3.5, 2.3.14, 2.8.3, 3.9, 4.
reviewing decisions 4.2, 5.3
2.06 Teamwork 2.06.01 Assemble and develop the team 1.5, 2.3.8, 3.1, 3.4, 3.7, 4.6,
4.10, 5.3
2.06.02 Promote cooperation and 1.5, 2.3.9.1, 3.9.8, 4.2,
networking between team members 5.3.1, 5.3.2, 5.3.3, 5.4.1
2.06.03 Enable, support, and review the 2.5.4, 2.5.5, 2.6.6, 3.7, 3.8,
development of the team and team 3.10
members
2.06.04 Strengthen teams by delegating 3.9.7, 4.4–4.7
tasks and responsibilities
2.06.05 Recognise mistakes to enable 2.5.5, 2.5.6, 2.6.6, 3.8.5,
learning from mistakes 5.4
2.07 Conflicts and 2.07.01 Anticipate conflicts and crises 2.5.5, 3.5, 4.7, 5.6.11
crises and prevent them if possible
(continued)

2.07.02 Analyse causes and effects of 5.6.2, 5.6.3, 5.6.6–5.6.9
conflicts and crises and select appropriate
responses
2.07.03 Resolve or mediate in conflicts 3.3.5, 3.9, 5.2, 5.6.9
and crises and/or their effects
2.07.04 Identify and share learning from 2.5.5, 5.2, 5.6
conflicts and crises to improve future
work
2.08 Versatility 2.08.01 Create and support an open and 1.5–1.7, 2.8, 3.3.5, 5.1.2,
creative environment 5.4
2.08.02 Apply conceptual thinking to 1.3.3, 1.6.3, 1.6.4, 1.7.1–1.
analyse situations and define solution 7.3, 2.3.14
strategies
2.08.03 Apply analytical techniques to 2.3.9, 2.3.14, 2.8.2
analyse situations, information, and
trends.
2.08.04 Promote and use creative 2.3.14, 2.8
techniques to find alternatives and
solutions
2.08.05 Promote holistic view of the 1.3.3, 2.3.5, 2.3.10
project and its context to improve the
decision-making process
2.09 Negotiations 2.09.01 Identify and analyse interests of 2.3.5, 4.10.1, 4.10.2, 4.10.
all parties involved in negotiations 3.1, 5.6.9.4
2.09.02 Develop and evaluate options 4.10.1, 4.10.2, 4.10.3.1–4.
and alternatives that have the potential to 10.3.3, 4.10.4
meet the needs of all stakeholders
2.09.03 Define negotiation strategy that 4.10.3.2, 4.10.3.3, 4.10.4
is in line with own objectives and
acceptable to all parties involved
2.09.04 Reach agreements with other 4.10.3.2, 4.10.3.3, 4.10.4
parties that are in line with own goals
2.09.05 Discover and exploit additional 1.2.3, 2.3.6, 2.4.11, 2.9
sales and acquisition opportunities
2.10 Result- 2.10.01 Evaluate all decisions and 2.3.2–2.3.4, 2.3.10, 2.4.3
orientation actions for their impact on the success of
the project and the organisation’s
objectives.
2.10.02 Align needs and resources to 2.3.3.4, 2.3.5, 2.3.10, 2.4.3
optimise results and successes
2.10.03 Create and maintain a healthy, 2.3.8, 2.3.10, 2.4.3, 2.5.2,
safe, and productive working 4.2, 5.4
environment
2.10.04 Promote and “sell” the project, 2.3.5, 2.3.6
its processes and results
2.10.05 Delivering results and gaining 2.5.4, 2.5.6, 5.5
acceptance
(continued)

Competence area practice
3.01 Project design 3.01.01 Recognise, prioritise, and review 2.3.1–2.3.3, 2.3.5, 2.3.10
success criteria
3.01.02 Review, apply, and share lessons 2.5.5, 2.5.6, 2.6.6
learned from and with other projects.
3.01.03 Determine project complexity 1.2.1, 1.2.2, 1.4, 2.1
and its consequences for the project
management approach
3.01.04 Select and adapt general project 1.4, 2.1
management approach
3.01.05 Design, monitor, and adapt 1.4, 2.1, 2.3.12, 2.5.4, 2.
concept for project implementation 5.6
3.02 Requirements 3.02.01 Define and develop hierarchy of 2.3.2, 2.3.3
and goals project objectives
3.02.02 Identify and analyse needs and 2.3.3, 2.3.5, 2.3.10, 2.4.2,
requirements of project stakeholders 2.4.3
3.02.03 Prioritise and decide on 2.3.3, 2.3.5, 2.3.10, 2.4.2,
requirements and acceptance criteria 2.4.3
3.03 Scope of 3.03.01 Define deliverables 2.3.10, 2.4.3, 2.5.2
services and delivery 3.03.02 Structure scope of services 2.3.10, 2.4.3, 2.5.2
items 3.03.03 Define work packages 2.3.10, 2.4.3, 2.5.2
3.03.04 Create and maintain scope of 2.3.3, 2.3.8, 2.3.10, 2.4.3,
service configuration 2.5.2, 2.5.6, 2.5.7
3.04 Procedure and 3.04.01 Define activities that are 2.3.10, 2.4.7, 2.5.2
deadlines necessary to deliver the project
3.04.02 Determine workload and 2.4.6, 2.4.7, 2.5.2
duration of activities
3.04.03 Determine procedure for 2.4.4, 2.4.7, 2.5.2
deadlines and phases or sprints
3.04.04 Determine the sequence of 2.4.4, 2.4.7, 2.5.2
project activities and prepare a process
and schedule.
3.04.05 Monitor progress against 2.5.3, 2.5.4, 2.5.6, 2.5.7
schedule and make necessary
adjustments
3.05 Organisation, 3.05.01 Assess and determine 2.3.5, 2.3.6, 2.4.10
information, and stakeholder needs for information and
documentation documentation
3.05.02 Define structure, roles, and 2.3.8, 2.3.8.8, 5.3.1–5.3.3
responsibilities in the project
3.05.03 Build infrastructure, processes, 2.3.5, 2.4.10
and information systems
3.05.04 Implement, monitor, and, if 2.3.8, 5.3.1–5.3.3
necessary, adjust the organisation of the
project.
(continued)

3.06 Quality 3.06.01 Develop quality management 2.4.11
plan for the project, monitor
implementation, and revise as necessary.
3.06.02 Review the project with its 2.4.3, 2.4.11, 2.5.4, 2.5.6,
deliverables to ensure that they continue 2.6.3
to meet the requirements of the quality
management plan.
3.06.03 Verify achievement of the 2.4.3, 2.5.6, 2.5.8, 2.6.3
project’s quality objectives and
recommend necessary corrective and/or
preventive actions.
3.06.04 Plan and organise validation of 2.4.11, 2.6.3
project results
3.06.05 Ensure quality in the course of 2.4.11
the project
3.07 Costs and 3.07.01 Estimate project costs 2.4.4, 2.4.6, 2.4.9
financing 3.07.02 Create project budget 2.4.9
3.07.03 Secure project funding 2.2, 2.7.2
3.07.04 Develop, establish, and maintain 2.5.6, 2.5.7, 2.7.1.8
financial management and reporting
system for the project
3.07.05 Monitor finances to identify and 2.5.6, 2.5.7, 2.7.1.8
correct deviations from project plan
3.08 Resources 3.08.01 Develop strategic resource 2.4.8
planning to be able to deliver the project
results
3.08.02 Define quality and quantity of 2.4.4, 2.4.7
resources needed
3.08.03 Identify potential resource 2.4.8, 2.9
sources and negotiate their procurement
3.08.04 Allocate and distribute resources 2.4.7, 2.4.8, 2.5.2, 5.6
according to defined needs
3.08.05 Evaluate resource consumption 2.5.6, 2.5.7, 3.10
and take necessary corrective action
3.09 Procurement 3.09.01 Agree procurement needs, 2.9
options, and processes
3.09.02 Contribute to evaluation and 2.9
selection of suppliers and partners
3.09.03 Contribute to negotiations and 2.9, 2.3.9.4
agreements of contractual provisions to
bring them in line with project objectives
3.09.04 Monitor contract performance, 2.5.6–2.5.8
address problems, and claim
compensation if necessary
3.10 Planning and 3.10.01 Start project, develop project 2.3.5, 2.3.8, 2.3.11–2.3.13
control management plan, and obtain approval
(continued)

3.10.02 Initiate and manage transition to 2.2.1, 2.2.5, 2.3.1, 2.3.15,
a new project phase 2.4.1, 2.4.12, 2.5.1, 2.5.9,
2.6.1, 2.6.7
3.10.03 Compare project performance 2.4.7, 2.5.2, 2.5.4, 2.5.6, 2.
with the project plan and take corrective 5.7
action if necessary.
3.10.04 Report on the progress of the 2.2.5, 2.3.15, 2.4.12, 2.5.4,
project 2.5.6, 2.5.7, 2.5.9, 2.6.7
3.10.05 Assess, obtain approval for and 2.5.8
implement project changes.
3.10.06 Complete and evaluate a phase or 2.2.5, 2.3.15, 2.4.12, 2.5.5,
the project 2.5.9, 2.6.6
3.11 Opportunities 3.11.01 Develop and implement 2.3.7, 2.3.9.2
and risks opportunities and risk management
structure
3.11.02 Identify opportunities and risks 2.3.7, 2.3.9.2
3.11.03 Analyse probability and impact 2.3.7, 2.3.9.2
of opportunities and risks
3.11.04 Select strategies and implement 2.3.7
measures to address opportunities and
risks
3.11.05 Evaluate and monitor 2.3.7
opportunities, risks, and implemented
measures
3.12 Stakeholders 3.12.01 Identify stakeholders and analyse 2.3.5, 2.5.7, 3.3.3, 4.9
their interests and influence
3.12.02 Develop and maintain 2.3.5, 2.3.6, 2.4
stakeholder strategy and communication
plan
3.12.03 Engage executive, project owner, 2.3.5, 2.3.8.8
and senior management to achieve
commitment and to manage interests and
expectations
3.12.04 Engage users, partners, and 2.3.5, 2.9
suppliers to achieve cooperation and
commitment
3.12.05 Establish, maintain, and 2.3.5, 4.9.3
terminate networks and alliances
3.13 Change and 3.13.01 Assess the adaptive capacity of 1.4.4, 3.5, 5.5
transformation the organisation(s) to change
3.13.02 Identify change requirements 2.3.5, 5.5
and transformation opportunities
3.13.03 Develop a change or 1.4.4, 2.5.5, 2.6.6, 5.5
transformation strategy
3.13.04 Implement change or 2.3.6, 2.6.2, 2.6.4
transformation management
Index
A Backward scheduling, 158

Ability, 250, 251 BANI model, 2
Acceptance, 82, 166, 201, 228, 281, 314, 332, Basic needs, 251
364 BATNA principle, 355, 447
criteria, 144 Belbin, 31, 303, 382
project, 6, 9 blind spot, 383, 384
Accuracy of estimate, 53 team report, 383
Acknowledgment, 199 team role, 303, 328, 382, 450, 453
Active listening, 298 team role report, 305
Activity, 125 Belonging, 274
Adherence to deadlines, 157 Best‐in‐market, 79
Adjourning, 371 Bionics, 231
Agile Blind spot, 295, 383, 384
approach, 14 Body, 92, 112, 339
manifesto, 15 Brain, 233, 248
model, 27 Brainstorming, 224
project management, 14, 27, 49, 94, 141, Brainwriting, 226, 227
142, 145, 148, 172, 175–177, 238, 326, Break‐even analysis, 159, 191
339, 342 Buffer, 153
Analogy method, 231 Burndown chart, 175, 370
Anticipatory obedience, 416 Burnout, 268
Appreciation, 84, 292, 328, 329, 379–381, Business case, 56, 59, 60, 137
389 Business handover, 203
Appreciative inquiry, 136, 231 Business organisation, 203
Archetypes of failure, 379
Assertion, 348
Assessment of one’s effort, 187 C
Attitude, 389 Capacity planning, 157
Audit, 168, 185 Catalogue of requirements, 146
Authenticity, 375 Cause-effect analysis, 115–117
Authority, 338, 342 Certification, 461
Award criteria, 242 Certification model, 41
Axiom theory, 286 Change, 24, 191, 326, 394, 395
formula, 398
level, 396
B management, 192
Backlog process model, 401
product, 142 project, 24, 394
sprint, 172 readiness, 399

https://doi.org/10.1007/978-3-662-66211-3
468 Index
Change request, 195 cold conflict, 427

Change request management, 192 conflict of interest, 420, 448
Character strength, 306, 307 conflict of values, 426, 453, 454
Check, 168 diagnosis, 427, 431
Circle of competence, 277 displaced, 428
Claim management, 191, 195, 349 distribution, 420, 448
Coaching, 299, 308, 316 escalation stage, 431
Coherence, 274 evaluation, 421, 449
Cohesion, 369 goal, 420, 447
Cold conflict, 427 Harvard concept, 443
Collegial leadership, 327, 387 hot, 427
Commissioning phase, 201 latent, 427
Committee, 95, 97, 101, 204, 289, 422 layer model, 434
Communication, 165, 451 management, 412, 438, 443
codex, 359 organisational, 420, 449
concept, 9, 30, 81, 139, 166 personal, 423, 450, 451
cycle, 289 prevention, 455
matrix, 166 procedure, 449
square, 286 relationship, 424, 451–453
Communication square resolution, 447, 455
appeal, 286 resource, 420, 448
content, 286 role, 422, 449
relationship, 286 skills, 456
self-revelation, 286 social, 451–453
Compass, 50 structural, 420, 449
Competence, 94 symptom, 418
leadership, 245 syndrome, 417, 418
methodological, 245 Conflict style, 429
moderation, 357 Confrontation, 429
negotiation, 245 Constellation, 372, 392
self-competence, 245 Context, 10
technical, 246 Context analysis, 113
Competence area, 10 Contract by private treaty, 241
context, 10 Controlling, 102, 178, 215, 353, 370
people, 11 Control of results, 216
practice, 11 Cooperation, 3, 22, 29, 33, 34, 313, 378
Competence model, 100, 245 level of cooperation, 29, 31, 81, 309, 415
Competence profile tool, 166
agile project, 94 Cooperative conflict resolution, 439
traditional project, 100 Coping strategy, 267, 268
Competence regulation, 109 Cost control, 187, 189
Complexity, 5, 373 Cost plan, 53, 163
Compliance, 10, 114, 118 Cost transparency, 190
Composition of team, 364 Courage, 267, 307, 327
Concept phase, 21, 138 CR, 192
Concurrent engineering, 24 Creativity, 37, 223
Conduct negotiations, 344, 351 domain, 38
Confidence, 281, 324, 381 field, 38
Configuration portfolio, 209, 210 human, 38
Conflict, 199, 412 technique, 37, 73, 223
approach-approach, 423 Credit, 273
approach-avoidance, 424 Crisis, 457
avoidance-avoidance, 424 Critical path, 153
Index 469
Critical success factor (CSF), 64 Elimination criteria, 71

Critical thinking appraisal, 303 Empowerment, 338, 372
Culture, 259 End review, 186
Cynefin framework, 27 Environment analysis, 113, 184
Epic, 143
Escalation stages, 431
D Estimate, 53
Daily stand-up/daily scrum, 52, 145, 175, 368 Estimation accuracy, 155
Data protection, 118 Evaluation conflict, 421, 449
Deadline control, 187, 189 Exclusion criteria, 235
Decision, 305 Existential anxiety, 398
Decision making, 60 Expert estimation, 150
Definition of done, 144 External assessment, 305
Delegation, 334 External control, 33, 34, 36, 273
Delegative leadership style, 320 Extreme programming, 14
Deliverable, 53, 121, 125, 130, 152, 201, Extrinsic motivation, 272
449 Eye of competence, 10, 42, 461
Delphi-method, 150
Deming circle, 136
Design thinking, 136, 228 F
Design‐to‐cost, 79, 159 Facilitation, 355
Detailed objective, 69, 71 Fail fast, 285
Detailed planning Failure, 283
cost plan, 53 Failure mode and effects analysis (FMEA), 86,
resource plan, 53 88
schedule, 53 concept, 90
Deutsche Gesellschaft für Projektmanagement design, 90
(GPM), 42 process, 90
Developer, 326 product, 90
Development project, 9 production, 90
Dialogue procedure, 237 system, 90
Dilemma, 267, 268, 275, 364, 423, 451 Feedback, 293
DIN 69901, 46 Feedback rules, 295
Directive leadership style, 320 Final project appraisal, 203
Displaced conflict, 428 Find consensus, 314
Disruption, 456 Fishbone method, 115
Distribution conflict, 420, 448 Focus, 8, 12, 16, 50, 74, 141, 171, 175, 218,
Documentation, 165 322, 327, 419, 443
Downside strategy, 311 customer’s view, 230
Draft contract, 242 topic, 143
Dynamic payback method, 191 user focus, 27
Dynamics in teams, 366 Follow-up, 186
adjourning, 371 Forming, 366
forming, 366 Framework condition, 70, 74, 235
norming, 369 Frustration tolerance, 457
performing, 370 Future orientation, 283
storming, 367
G
E Gantt chart, 153
Earned‐value‐analysis, 180 Generations Y, Z, and alpha, 262
Economic efficiency, 60, 190, 204 Global objective, 68, 69
Economic viability, 137, 169, 185 Goal conflict, 420, 447
Efficiency, 102 Goal orientation, 3
Effort estimation, 147, 150, 151, 279 Going live, 201
470 Index
Golden profiler of personality (GPOP), 302, Kano model, 75

305 Key performance indicators (KPIs), 64
Governance, 5, 10, 118, 217, 221 Kick-off, 34, 131–133
Grooming, 176 Knowledge, 250, 251
H L
Harmony, 365 Large Scale Scrum (LeSS), 14, 18
Harvard concept, 350, 353, 443 Latent conflict, 427
Hazard analysis and critical control points Lateral leadership, 321
(HACCP), 86 Layer model, 434
Hermes, 41, 45, 70 Leadership, 314, 317, 327, 400, 452
Hierarchies in project management competence, 95, 100, 245, 315, 316
product management, 10 continuum, 111
programme management, 9 different forms of leadership, 316, 317
project portfolio, 9 lateral leadership, 321
High performance team, 381 skills, 391
Hot conflict, 427 work, 317
Hybrid model, 27 Leadership model
Hybrid project management, 23, 27, 49, 102 collegial leadership, 327
delegative leadership, 319
directive leadership, 319
I lateral leadership, 321
Iceberg model, 356 leading with goals, 331
Impact analysis, 195 positive leadership, 323
Improvement project, 9 remote leadership, 325
Inclusion, 262 self-organisation, 326
Increment, 16, 173, 176 situational leadership model, 319, 321
Individual competence baseline (ICB), 41, Leadership style, 317
461 delegative leadership style, 320
Influence organisation, 105 directive leadership style, 320
Information, 165 integrative leadership style, 320
Information security, 118 participative leadership style, 320
Initialisation phase, 20, 61 Lean
Innovation project, 9 change cycle, 410
Integrative leadership style, 320 management, 16
Integrity, 11, 38, 118 portfolio management, 217, 218
Interaction, 31, 459 six sigma, 136
International Project Management Association Learning, 25, 37, 68, 171, 177, 326, 331, 379,
(IPMA), 10, 41 380, 410
certification, 461 Learning anxiety, 398
competence area, 10 Legislation, 118
Intrinsic motivation, 272 Level of change, 396
Introduction phase, 21, 197 Level of cooperation, 29, 31, 81, 309, 415
INVEST characteristics, 144 Life‐cycle‐cost, 159, 190
Invitation procedure, 241 Line organisation, 47, 92, 104, 248, 313, 339,
Ishikawa diagram, 116 344, 372, 420, 449, 452
ISO 21500, 46 Lived role, 374, 450
Living world, 301
Logic
K factual, 399
Kanban, 14, 17, 155 psycho, 399
Kanban board, 23, 173 Lose-lose, 433
Index 471
M Negotiation, 11, 66, 78, 161, 344, 391, 408, 443

Magic triangle, 78 competence, 245
cost, 78 Harvard concept, 353
scope, 78 skills, 95, 100
time, 78 strategy, 347, 350, 353
Management by objectives (MbO), 331 tactics, 350
Management task, 94 Net present value method, 190
Mandatory objective, 71 Network orientation, 282
Matrix project organisation, 107 Neuroplasticity, 245, 248
Maturity level Nice-to-have objective, 72
employee, 320 Non-objective, 67
project management, 4 Non-recurring costs, 190
Meaning, 141, 262, 271, 273, 283, 307, 324 Non‐trivial system, 34
in life, 274 Norming, 369
of life, 274
Mechanistic world view, 33
Meta communication, 290 O
Meta mirror, 354, 445 Obedience
0/100 method, 187 anticipatory, 416
Methodological competence, 95, 100, 245 Objective, 66, 113, 118, 125, 146, 184, 219,
Milestone, 53 457
plan, 120, 121 contradictive, 71
Milestone trend analysis (MTA), 181 detailed, 69
Mind change, 396 essential, 71
Mind mapping, 226 global, 69
Mindset, 385, 389 mandatory, 71, 235
Mission, 219, 220, 236 must-have, 71
Moderation, 355, 356 nice-to-have, 72
Moderation competence, 357 non-objective, 67
Moderation phases, 357 optimisation, 72, 235
Moderation preparation, 358 process, 70
Moderation responsibility, 357 rough, 69
Monochronic organisation culture, 387 SMART, 71, 447
Morphological box, 230 system, 69, 125
MoSCoW prioritisation, 76 OKR, 332
Motivation, 246, 271, 335, 400 Openness, 283, 326, 333, 390, 405
extrinsic, 272 Open procedure, 241
intrinsic, 272 Operating processes, 203
Multicultural cooperation, 387 Opportunity, 84
Multiple interaction, 33 Optimisation criteria, 72, 235
Multiple roles, 112 Optimisation objective, 72
Multiplier method, 149 Optimism, 281
Multi-project management, 47, 161, 206, 448 Oral communication, 166
element, 207 Order clarification, 114
problem field, 207 Order processing project, 9
task field, 207 Organisational conflict, 420, 449
Must-have objective, 71 Organisational constellation, 392
Myers-Briggs Type Indicator (MBTI), 31, 305 Organisational culture, 259, 260
Organisational form
matrix project organisation, 107
N project coordination, 105
Needs, 228 pure project organisation, 106
Negotiated procedure, 241 Organisational framework, 321
472 Index
Organisation culture Potential of conflicts, 419

monochronic, 387 Potential project, 6
polychronic, 387 Power, 338, 400
Orientation, 274 borrowed, 341
Overall project, 123 institutional, 340
personal, 340
user, 202
P Practical examples, 53
1-pager, 59 Practice, 11
Participative leadership style, 320 Prefrontal cortex, 249
PDCA circle, 136 Preparing operation, 203
People, 11 Prevention, 455
Percentage method, 149 PRINCE2, 44
Performing, 370 Priority classification, 210
PERMA model, 323, 359, 381 Probability of occurrence, 85
Personal communication, 400 Problem solving process, 133
Personal conflict, 423, 450, 451 Procedural principle, 12
Personal framework, 321 agile, 27
Personality typology, 302 hybrid, 27
Personal responsibility, 282 from rough to detailed, 12
Personal self-knowledge, 303 traditional, 27
Perspective, 10 variant formation, 13
Phase Procedure conflict, 449
concept, 18, 21, 138 Procedure principle
initialisation, 20, 61 phase structure, 120
introduction, 21 problem solving process, 133
plan, 121, 178 Process objective, 70, 335
project commissioning, 19, 56 Procurement, 237
realisation, 21 Product backlog, 16, 49, 68, 72, 74, 97, 138,
report, 140 142, 145, 147, 171, 175, 191, 200, 203,
Pilot series, 201 238, 458
Pilot test, 201 Product concept, 65, 68, 138, 141, 458
Pink zone, 385 Product goal, 17
Pioneering project, 6, 9 Product management, 10
Planned and actual costs, 163 Product owner, 16, 94, 95, 97, 142, 146, 276,
Planning, 120, 145, 155 326, 344, 447, 458
horizon, 118 Product vision, 29, 49, 132, 141
poker, 148 Profitability, 190, 211, 396
style, 387 Programme evaluation and review technique
Plus and minus list, 196 (PERT), 151
PMBOK® Guide, 43 Programme management, 9, 47, 218, 461
Polarity, 390 Programme manager, 41
Polychronic organisation culture, 387 Progress monitoring, 216
Portfolio, 214 Project assessment, 184, 186
board, 60, 178, 209 Project change, 191
configuration, 209, 210 Project body, 313
management, 167, 206, 216, 217, 221, 461 Project characteristics, 5
manager, 41 acceptance project, 6
mix, 207 pioneering project, 6
planning, 60 potential project, 6
Position, 372 standard project, 6
Positive leadership, 323, 325, 381 Project classification, 5
Positive psychology, 306, 381 Project commissioning phase, 19, 56
Index 473
Project committee, 71, 95, 98, 101, 178, 182, Project structuring, 120
184, 186, 328, 330, 421, 422 Project team, 95, 102
agile project, 97 Project types, 7, 365
traditional project, 101 Project typology, 5
Project communication, 166, 167 Projekt Management Austria (PMA), 42
Project completion, 203 Protection needs analysis, 118
Project control, 21, 178, 179 Psychological safety, 258, 378, 381
Project coordination, 105 Psychological stress, 264
Project culture, 260, 261 Pure project organisation, 106
Project definition, 3 Purpose, 250, 329, 335, 379, 381, 400
Project director, 41
Project documentation, 166
Project factsheet, 20, 56, 59, 60 Q
Project information, 166, 167 Quality gate review, 186
Projection, 453 Quality management, 167, 168
Project list, 210 Quality of the relationship, 289
Project management, 8 Quality planning, 168
agile project management, 14, 27, 49, 94, Question
141, 142, 145, 148, 172, 175–177, 238, active listening, 298
326, 339, 342 circular, 300
dimensions in project management, 10 closed, 297
hybrid project management, 23, 27, 49, 102 goal-oriented, 300
traditional project management, 18, 27, 49, heart, 300
341 hypothetical, 300
Project management compass, 50 open, 297
Project management guideline, 221 resource-oriented, 300
Project management handbook, 221 scale, 300
Project Management Institute (PMI), 43 Questioning technique, 297
Project management methodology, 456
Project management office (PMO), 220, 221
Project management plan, 129 R
Project management standard, 41 RACI matrix, 109, 415, 449
Project manager, 41, 94, 95, 101, 337, 344, 458 Radical collaboration, 385–387
Project manual, 129 Ranking, 452
Project marketing, 82, 166 Realisation phase, 21, 170
Project objective, 66, 70, 71 Realistic assessment of economic efficiency,
Project order, 20, 29, 35, 60, 62, 69, 71, 94, 190
101, 113, 128, 141, 184, 276, 317, 340, Recognition, 30, 301, 368, 371, 413, 453
344, 421, 447, 448 Red zone, 385
Project organ, 93, 317 Refinement, 176
Project organisation, 90, 100 Refreeze, 24
Project owner, 15, 97, 101, 196, 337, 447 Reiss motivation profile, 303
Project phase, 53 Relationship, 338
Project planning, 120, 145, 155 Relationship conflict, 424, 451–453
Project portfolio, 9, 35, 42, 47, 56, 61, 89, 206, Release plan, 49, 138, 145, 458
209, 210, 215, 216, 220, 373, 400, 420, Remote leadership, 325
448, 450 Reporting, 166, 179, 181, 317
Project proposal, 56, 60 Reporting in multi-project management, 215
Project request, 21, 59, 190 Request for information (RFI), 241
Project staff, 41 Request for proposal (RFP), 241
Project steering, 184 Request for quotation (RFQ), 241
Project strategy, 79 Requirement, 66, 69, 72, 400
Project structure plan (PSP), 125 catalogue, 69, 138
474 Index
Requirement (cont.) S
engineering, 72 Scaled Agile Framework (SAFe®), 14
framework condition, 74 Scamper, 227
functional requirement, 73 Scenario‐technique, 118
non‐functional requirement, 73 Schedule, 152
prioritisation of requirements, 74 Scheduling, 157
specification, 69, 146 Schulz von Thun, F., 286, 299
Reserves, 151 Scope, 15, 29, 73, 78, 130, 146, 195, 198, 220,
Resilience, 280 344, 400, 412
Resilience factor, 281 Scope creeping, 416
acceptance, 281 Scrum, 16, 49, 141, 142, 145, 172, 175–177,
future orientation, 283 326
network orientation, 282 Scrum alliance, 41, 46
optimism, 281 Scrum master, 16, 36, 94, 95, 97, 173, 175, 177,
personal responsibility, 282 276, 317, 326, 339, 371, 376, 422, 449,
self-efficacy, 282 458
solution orientation, 283 Scrum team, 31, 36, 94, 142, 147, 172, 177,
Resistance, 3, 172, 199, 394, 399, 403, 410, 270, 286, 326, 338, 423, 449
418, 429 Selective perception, 254, 289
dealing with resistance, 406 Selective procedure, 241
forms, 405 Self
Resource availability, 213 assessment, 305
Resource conflict, 420, 448 competence, 95, 100, 245
Resource control, 189 control, 34, 338, 438
Resource coordination, 159 development, 252
Resource dependency, 213 direction, 33, 34
Resource deployment plan, 159 efficacy, 276, 282
Responsibility, 97, 109 esteem, 253
moderation, 357 leadership, 327
project committee, 97 management, 275, 276
project manager, 101 organisation, 17, 33, 34, 94, 95, 170, 326
project owner, 97, 101 Serial production, 197, 201
scrum master, 97 Severity, 85
Retrospective, 177, 199 Significance, 274
Return on Investment (ROI), 190 Simultaneous engineering, 24
Review, 112, 123, 168, 185, 199, 216 Situational leadership model, 319, 321
Review board, 101 Situation analysis, 113
Risk, 85 Slack, 153
impact, 195 Small project, 9
list, 88 SMART, 71
management, 84, 285 Social competence, 95, 100
management tool, 88 Social conflict, 451–453
probability of occurrence, 85 Solution
process, 84 concept, 138, 146
severity, 85 finding, 223
Role, 92, 95, 97, 101, 372, 375, 422 orientation, 283
adoption, 376, 422 selection, 223
carrier, 374 variant, 138
conflict, 422, 449 Sounding board, 101
lived role, 374, 450 Sources of power, 339
sender, 374 Specification, 69, 146
Rough objective, 69 Sprint backlog, 173
Rough planning, 120, 145, 157 Sprint implementation, 175
Index 475
Sprint planning, 145, 172, 173 Team, 98, 363, 364

Sprint review, 16, 97, 176, 339, 370 agile project, 326
Stacey matrix, 27 competence, 95, 100
Stakeholder, 228 development, 96, 293, 366, 370, 372,
analysis, 79 400
management, 79 frame, 322
Standard project, 6 report, 383
Steering committee, 101 role, 172, 303, 382, 450, 453
agile project, 97 role report, 305
traditional project, 101 work, 29
Steering group, 101 Technical competence, 246
Storming, 367 Technical specification, 138
Story points, 148 Tender, 239
Strategy implementation, 218 Testing, 168
Stress amplifier, 265 Timebox, 16
Stress competence, 265, 266 Time management, 278–280
instrumental, 266 Time management matrix, 279
mental, 266 Time‐to‐market, 79
regenerative, 266 T-profile, 229
Stressor, 255, 263, 265 Traditional project management, 18, 27, 94,
Stress response, 263, 264, 268, 451 100, 138, 146, 152, 159, 167, 178, 191,
Stress traffic light, 265 239, 339, 341
Structural conflict, 420, 449 Transformation, 395
Sub-project, 120, 123 Transparency, 84, 129, 165, 174, 175, 217, 316,
Sub-project manager, 102 323, 327, 330, 333, 368, 405
Substitute satisfaction, 428 Triple constraint, 78
Success factor, 64, 216, 303 Trivial system, 34
Suggestions for improvement, 177 Trust, 329, 336, 342, 351, 369, 373, 390, 410,
Suitability criteria, 242 439, 442, 456
Swiss ICB, 461 T-shirt sizing, 149
SWOT analysis, 114 Tuckman, B., 366
Synectics, 231 Type of conflict, 419
Systemic approach, 35 Type of introduction, 200
Systemic phenomenon, 414
Systemic world view, 33
System objective, 69, 125, 335 U
Unfreeze, 24
Upside strategy, 311
T User manual, 202
Target agreement, 332 User training, 202
Target costing, 159 Utilisation phase, 22
Target pyramid, 346
Target setting, 332
Task, 101, 123, 125, 317 V
Task force, 106 Value-risk matrix, 76
Task performance process (TCR), 331 Verein zur Zertifizierung von Personen im
Tasks, authorities and responsibilities (TCR), Management (VZPM), 42
337 Versatility, 37
Tasks of the project committee, 184 Version concept, 25
Tasks of the project manager, 184 VIA character strength, 303, 306, 307
Tasks of the project owner, 184 Virtual team, 359
Taylorism, 1, 32, 245 Vision, 29, 49, 68, 78, 132, 136, 141, 219, 220,
Taylor tub, 1 236, 329, 410, 420
476 Index
V‐model, 24 Work on the system, 30, 34, 36, 280, 316, 368,
VUCA, 3, 262, 403 390
organisation, 30
relationship, 30
W Work package, 121, 123, 130, 152, 449
Willingness to cooperate, 400 Workplace big five, 303
Willingness to shape, 400 Work technique, 278–280
Win-lose, 433 World view
Win-win, 432 mechanistic, 32
Wish objective, 72 systemic, 32
Work breakdown structure, 53, 120, 121, 125 WPB5, 303
Work group, 363, 364 W-questions, 298
Work in the system, 29, 33, 316, 367, 370,
390
content, 29 Z
Workload, 162 Zone of strength, 308

Project Management Handbook - Agile - Traditional - Hybrid-Springer (2023)

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

Project Management Handbook - Agile - Traditional - Hybrid-Springer (2023)

Uploaded by

Copyright:

Available Formats

Management for Professionals

Jürg Kuster · Christian Bachmann ·

Mike Hubmann Robert Lippmann

ISSN 2192-8096 ISSN 2192-810X (electronic)

# Springer-Verlag GmbH Germany, part of Springer Nature 2015, 2023

This second, entirely revised edition of the “Project Management Handbook” is

Structure of This Book

Various structural elements simplify the application of this comprehensive work in

1. Introduction: Project management at a glance and in a leadership context

Zürich, Switzerland Jürg Kuster

1.7.3 Interplay Between Human, Field and Domain . . . . . . . . 38

2.4.4 Release Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

3.10 Personal Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

4.9.5 Sources of Power: Between Person and Institution . . . . . 338

5.5.3 The Human Being and Change . . . . . . . . . . . . . . . . . . . 392

Jürg Kuster, Graduate Engineer ETH Zurich

Christian Bachmann, Business Economist FH

(in industry and in educational organisations). Process

Mike Hubmann, Engineer FH, EMBA HSG, Integral

Robert Lippmann, Lic. oec. publ., NDU SNU

E. (ed.), Coaching (3rd ed. 2013) published by Springer

Patrick Schneider, graduate engineer ETH, EMBA,

1.1 Project Management, What for?

1.1.1 The Taylor Tub

In the industrial age of Taylorism, traditional project management helped to create

# Springer-Verlag GmbH Germany, part of Springer Nature 2023 1

Share of value added

Who? How? Who?

tight local markets wide global markets tight global markets

Fig. 1.1 Taylor tub

1.1.2 BANI Is the New VUCA

• Volatility: Fluctuations and rapidity in the digitalised world

• A ﬂexible and quickly reactive temporary organisation ensures the optimal

1.2 What are Projects?

The team of authors deﬁnes a “project” as follows:

• one-off special assignments that can essentially be fulﬁlled by one person,

• Personnel expenses internal/external

Table 1.1 Example of a project classiﬁcation

Table 1.2 Project characteristics

1.2.1 Project Characteristics

Fig. 1.2 Project characteristics

• Standard projects can draw on a wealth of experience and can therefore be

1.2.2 Project Types

Another way of classifying projects is to arrange them according to their purpose.

1.2.3 Emergence of Projects

Projects can arise in different ways as shown in Fig. 1.3.

Fig. 1.3 Emergence of projects

1.3 What Is Project Management?

• Subdividing the procedure as a whole into phases and work packages

In the agile approach, the focus of the elements is slightly different:

• Empowered, self-organised teams are to continuously review and adapt

1.3.1 Hierarchies in Project Management

Product management encompasses all strategic and operational activities of a

1.3.2 Dimensions in Project Management

1.3.2.1 Competence Area Perspective

1.3.2.2 Competence Area People

• Self-reﬂection and self-management

This area of competence is key to the success of a project. A project is successful

1.3.2.3 Competence Area Practices

To master a project successfully, mastering the craft is an indispensable prerequi-

1.3.3 Principles of Procedure

The following principles and attitudes have proven effective in practice:

• From the general sketch to more detail