<?page no="0"?> ISBN 978-3-381-13481-6 www.uvk.de What has been supported by advocates of professional project work for years has now become a reality in the daily routines of many employees and managers: highly project-oriented work structures. Consequently, professionalised project management competence is becoming increasingly vital to business success. Following the five project management phases of DIN 69901: 2009 and supplemented by chapters on cross-phase competencies and agile methods, this book o ers a clear and professionally sound presentation of the modernised ICB 4.0 framework (e ective from January 1, 2024). Its structured content, illustrated by a consistent project example, not only guides readers but also ensures they are well-prepared to meet the IPMA ICB 4.0 examination requirements. This book equips anyone seeking to engage in professional project management with the knowledge and tools needed to successfully apply current best practices. Schulz / Meier Project Management 3. Ed. Marcus Schulz / Tinka Meier Project Management A Practical Guideline for Today’s Project Managers 3 rd Edition ICB 4.0 <?page no="1"?> Project Management A Practical Guideline for Today’s Project Managers <?page no="2"?> Important information The authors do not guarantee that the processes, programs, or other content described are free from third-party intellectual property rights. The use of common names, trade names, product designations, or similar terms in this book, even without special labeling, does not imply that they are freely available. The authors have made every effort to ensure that the information in this book is complete and accurate. The content reflects the state of knowledge as of the editorial deadline of April 30, 2024. While all information and data have been compiled to the best of our ability, there is no guarantee of completeness or accuracy. Any use not expressly permitted by copyright law requires prior consent from the authors. This includes, but is not limited to, duplication, editing, translation, microfilming, database evaluation, and storage or processing in electronic systems. Disclaimer on gender-neutral language Throughout this book, gender-neutral language is used as much as possible. Gender-specific terms may be used in certain instances to enhance readability and ensure the text flows smoothly. Whenever such terms are used, they should be interpreted as inclusive of all genders, unless explicitly stated otherwise. The use of gendered language in these cases is purely for the sake of linguistic simplicity and should not be construed as intentional bias or exclusion. No offense or sexism is intended, and we fully support the importance of gender-neutral language in promoting equality and respect. Marcus Schulz is a project management trainer with heart and soul, and as an independent consultant and coach, he supports companies on their way into the agile world of project management. After graduating from the Duale Hochschule Stuttgart in 1992 with a degree in Business Administration, he worked as a consultant and project manager in various companies in Germany and abroad. He founded the Mannheim Training Centre in 2013. Marcus Schulz is a certified senior project manager (PMP ® , IPMA ® Level B), scrum master, agile coach (IHK), certified business trainer (BDVT), and has been a project management trainer (IPMA ® Level B Certified Senior Trainer) since 2009. He has been named a benchmark trainer by the German Association for Project Management (GPM) multiple times (GPM). In addition to his work as a trainer and consultant, he has taught project management at various universities and volunteers as a support instructor in the leadership and communication section of the Heidelberg chapter of the Federal Agency for Technical Relief (THW). Tinka Meier gained her experience as a project manager after graduating in comparative linguistics in 1997, initially in event management. She then spent over ten years working as a project and programme manager in international projects in supply chain management, with a focus on England, the USA, Singapore, China, Japan and India. She has been working as a freelance trainer, consultant and coach for international companies in both German and English since 2017. She also applies her passion for knowledge transfer and the personal development of her course participants in the social sector, for example in the training and further education of refugees and migrants. Tinka Meier is a certified senior project manager (IPMA ® Level B), scrum master, certified intercultural trainer (dgikt) and systemic solution-oriented coach (DGfC) and, since 2019, an accredited trainer for project management (IPMA ® Level B Certified Senior Trainer) of the German Association for Project Management (GPM). She is also a lecturer in project management and intercultural communication at various German universities. <?page no="3"?> Marcus Schulz, Tinka Meier Project Management A Practical Guideline for Today’s Project Managers Terms, methods and procedures of ICB 4.0 for ‘Basic Certificate in Project Management (GPM)’ and ‘Certified Project Management Associate (IPMA ® Level D)’ 3 rd Edition <?page no="4"?> Umschlagmotiv: © iStockphoto · wragg Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http: / / dnb.dnb.de abrufbar. 3 rd Edition 2025 Die ersten beiden Auflagen erschienen nur in deutscher Sprache. DOI: https: / / doi.org/ 10.24053/ 9783381134823 © UVK Verlag 2025 - Ein Unternehmen der Narr Francke Attempto Verlag GmbH + Co. KG Dischingerweg 5 · D-72070 Tübingen Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Alle Informationen in diesem Buch wurden mit großer Sorgfalt erstellt. Fehler können dennoch nicht völlig ausgeschlossen werden. Weder Verlag noch Autor: innen oder Herausgeber: innen übernehmen deshalb eine Gewährleistung für die Korrektheit des Inhaltes und haften nicht für fehlerhafte Angaben und deren Folgen. Diese Publikation enthält gegebenenfalls Links zu externen Inhalten Dritter, auf die weder Verlag noch Autor: innen oder Herausgeber: innen Einfluss haben. Für die Inhalte der verlinkten Seiten sind stets die jeweiligen Anbieter oder Betreibenden der Seiten verantwortlich. Internet: www.narr.de eMail: info@narr.de Druck: Elanders Waiblingen GmbH ISBN 978-3-381-13481-6 (Print) ISBN 978-3-381-13482-3 (ePDF) ISBN 978-3-381-13483-0 (ePub) <?page no="5"?> Foreword to the 3 rd edition Globalisation has brought about profound changes in the economic system; markets are becoming increasingly dynamic, and social systems must adapt to a VUCA (volatile, uncertain, complex, and ambiguous) world. Project-based, results-driven collaboration has proven to be highly effective for both contributors and stakeholders. In fact, there is growing discussion of the 'projectification' of society, as the project economy has now become a reality. As a result, the demands on those working in projects are increasing, leading to a growing need for qualified specialists. In addition to having the right mindset and organisational structures, project work requires decisiveness, skills, and competencies at every level. A solid education, particularly in the fundamentals of systematic project management based on standardised approaches such as the ICB 4.0 from the IPMA (International Project Management Association), plays a crucial role in meeting these demands. There is now a wide range of essential literature on project management available.This publication, now in its third and expanded edition, focuses on the core principles of managing individual projects, covering all key areas of expertise: practice (methodology), perspective (context), and people (personal and social skills). It stands out for its thorough treatment of topics, relevance, and well-designed structure to guide the reader effectively. The author, an experienced project manager and trainer, draws on years of practical experience to offer all the relevant topics for a solid foundation in project work. The content is organised in a didactically sound manner and follows a well-established approach through the competence elements. Upon closer examination, even seemingly minor topics prove to be crucial for success. As such, this book serves as both an educational resource and a practical tool for everyday project work. This book provides an excellent foundation for those new to systematic project management. I wish the current edition much success and encourage readers to explore it with great interest! Soest, in April 2024 Prof. Dr. Florian E. Dörrenberg, Department of International Project Management and Knowledge Transfer, Fachhochschule Südwestfalen, Soest, Germany. <?page no="7"?> Content overview 0 About this book .....................................................................................................15 1 Basics of Project Management .............................................................................19 2 Initialisation phase.................................................................................................33 3 Definition phase ....................................................................................................45 4 Plannning phase ...................................................................................................91 5 Controlling phase ................................................................................................139 6 Closure phase .....................................................................................................155 7 Cross-phase competences .................................................................................161 8 An overview of the Agile world ............................................................................229 9 Overview ICB4 elements and mapping to chapters ............................................241 10 Abbreviations ......................................................................................................247 11 Tables and figures...............................................................................................249 12 Index of keywords ...............................................................................................255 <?page no="9"?> Page | 9 Table of Contents Foreword to the 3 rd edition..............................................................................................5 0 About this book...................................................................................................15 0.1 Target group and foundation ............................................................................15 0.2 How to read this book .......................................................................................15 0.3 Literature...........................................................................................................17 1 Basics of Project Management ..........................................................................19 1.1 Terminology ......................................................................................................20 1.2 Project management office ...............................................................................21 1.3 Project types .....................................................................................................22 1.4 Project success / Project management success ..............................................23 1.5 Project management approaches and process models....................................24 1.6 Standards in project management ....................................................................27 1.7 Literature...........................................................................................................30 2 Initialisation phase..............................................................................................33 2.1 Selection of projects .........................................................................................33 2.2 Project definition ...............................................................................................38 2.3 Literature...........................................................................................................42 <?page no="10"?> 10 | Page 3 Definition phase ..................................................................................................45 3.1 How does a project begin? Project start ...........................................................45 3.2 Project environment and stakeholders .............................................................47 3.2.1.1 Environmental factors - legal conditions ........................................50 3.2.1.2 Hazard analysis ..............................................................................53 3.2.1.3 Environmental factors - culture and values....................................53 3.2.1.4 Environmental factor - sustainability ..............................................55 3.2.1.5 SWOT analysis ...............................................................................57 3.3 Requirements and objectives ...........................................................................67 3.3.2.1 Objective definition, target values...................................................69 3.3.2.2 Objective functions, objective types ...............................................70 3.3.2.3 Objective formulation, objective relationships ................................73 3.4 Project phases..................................................................................................75 3.5 Organisation and information ...........................................................................78 3.5.1.1 Functional or influential project organisation ..................................78 3.5.1.2 Matrix project organisation .............................................................79 3.5.1.3 Autonomous or pure project organisation.......................................80 3.5.1.4 Steering committee.........................................................................81 3.5.2.1 Project roles....................................................................................82 3.5.2.2 TCA matrix......................................................................................82 3.5.2.3 Responsibility matrix.......................................................................83 3.6 Literature ..........................................................................................................87 4 Plannning phase .................................................................................................91 4.1 Scope ...............................................................................................................92 4.2 Time................................................................................................................102 4.3 Resources ......................................................................................................110 4.4 Cost and finance.............................................................................................116 <?page no="11"?> Page | 11 4.5 Contractual aspects of project work................................................................120 4.5.1.1 Make-or-buy decision ...................................................................121 4.5.1.2 Types of requests .........................................................................122 4.6 Risk and opportunity .......................................................................................125 4.7 Quality.............................................................................................................131 4.8 Literature.........................................................................................................136 5 Controlling phase..............................................................................................139 5.1 Project controlling ...........................................................................................139 5.1.2.1 Earned Value Analysis (EVA) .......................................................143 5.1.2.2 Milestone trend analysis (MTA) ....................................................146 5.1.2.3 Cost trend analysis (CTA).............................................................147 5.2 Reporting in the project - the status report.....................................................149 5.3 Configuration management and change management...................................150 5.4 Literature.........................................................................................................152 6 Closure phase ...................................................................................................155 6.1 Project closure ................................................................................................155 6.2 Literature.........................................................................................................159 7 Cross-phase competences ..............................................................................161 7.1 Self-reflection and self-management ..............................................................161 7.2 Personal integrity and reliability ......................................................................166 7.2.3.1 Descriptive and normative ethics ..................................................169 7.2.3.2 Ethics and project management ...................................................170 <?page no="12"?> 12 | Page 7.3 Personal communication ................................................................................172 7.3.4.1 Question types and techniques ....................................................177 7.3.4.2 Active listening..............................................................................178 7.3.4.3 Feedback ......................................................................................179 7.4 Relationships and engagement ......................................................................182 7.5 Leadership......................................................................................................188 7.5.1.1 Typology according to K. Lewin....................................................188 7.5.1.2 Leadership continuum according to Tannenbaum & Schmidt ......189 7.5.1.3 Managerial Grid Modell (Blake & Mouton)....................................191 7.5.1.4 Situational Leadership II (K. Blanchard) .......................................192 7.6 Teamwork.......................................................................................................198 7.7 Conflict and crisis ...........................................................................................204 7.8 Negotiation .....................................................................................................210 7.9 Resourcefulness.............................................................................................213 7.9.1.1 Cause-effects diagram .................................................................214 7.9.1.2 Pareto analysis .............................................................................215 7.9.1.3 FMEA............................................................................................216 7.9.2.1 The 635 method ...........................................................................217 <?page no="13"?> Page | 13 7.9.2.2 Brainstorming................................................................................218 7.9.2.3 Morphological matrix.....................................................................218 7.9.2.4 Brainstorming paradox..................................................................219 7.10 Results orientation.........................................................................................219 7.11 Change and transformation...........................................................................220 7.12 Literature .......................................................................................................223 8 An overview of the Agile world........................................................................229 8.1 Scrum .............................................................................................................230 8.1.3.1 Sprint ............................................................................................232 8.1.3.2 Sprint Planning .............................................................................233 8.1.3.3 Daily Scrum ..................................................................................233 8.1.3.4 Sprint Review................................................................................233 8.1.3.5 Sprint Retrospective .....................................................................233 8.1.4.1 Product Backlog............................................................................235 8.1.4.2 Sprint Backlog...............................................................................237 8.1.4.3 Increment ......................................................................................237 8.2 Kanban ...........................................................................................................238 8.3 Literature.........................................................................................................239 9 Overview ICB4 elements and mapping to chapters.......................................241 10 Abbreviations ....................................................................................................247 11 Tables and figures ............................................................................................249 11.1 Tables...........................................................................................................249 11.2 Figures .........................................................................................................251 12 Index of keywords.............................................................................................255 <?page no="15"?> Page | 15 0 About this book 0.1 Target group and foundation This book is aimed at project staff and people who encounter project management, the relevant standards or the general conditions in the company in the course of their work. It serves to supplement existing knowledge and to support daily work by presenting methods and examples. In addition to the compact summary of the topic of project management, this book offers practical teaching and working material. All chapters also fulfil the requirements for preparation for the written examination for the "Basic Certificate in Project Management (GPM)" as well as the written examination and the project report to be prepared as part of the qualification for the “Certified Project Management Associate” IPMA ® Level D. 0.2 How to read this book 0.2.1 Structure and layout The content of the chapters corresponds to the competence elements of the Individual Competence Baseline 4.0 for project management (ICB 4.0). The structure of the book follows the process model of DIN 69901-2: 2009 and the five project management phases contained therein ‒ initialisation, definition, planning, control, completion [DIN20a]. The overall competences (e.g. personal communication, motivation, leadership, versatility) and a look at the Agile world make up the final chapters. Each main chapter opens with an overview of the elements contained in the Individual Competence Baseline 4.0. In addition, the individual ICB elements are briefly summarised and presented at the beginning of each chapter. In addition, the relevant bibliographic references are provided at the end of each main chapter. Chapter 9 contains a referential mapping of the individual book chapters to the ICB elements. This book is completed by a list of figures and tables as well as a detailed index. 0.2.2 Application and didactical concept The book is intended to accompany the Level D IPMA ® qualification and basic qualification (GPM) according to ICB 4.0. The results, methods and terminology used in the respective course can be easily understood with the help of the book. The topics are supplemented with useful information from the IPMA ® Level C knowledge area where the author deemed it necessary to complement the content. <?page no="16"?> 16 | Page The taxonomy 1 for IPMA ® Level D to A and for the "Basic Certificate in Project Management (GPM)" according to ICB 4.0 was originally categorised according to the six levels of BENJAMIN S. BLOOM [UIBK16] for the individual competence elements. In the revised version of the taxonomy, the six levels were consolidated into three competence levels. Competence level Bloom level Explanation 1 1 - Know Remembering specifics and generalities, remembering methods and processes or remembering patterns, structures or definitions. 2 - Understand The individual understands what is being communicated ("talked about") and can use the material or idea referred to without necessarily relating it to other material or recognising its fullest meaning. 2 3 - Apply Use of abstractions and application of the method or element in specific and concrete situations. The abstractions can be in the form of general ideas, rules about procedures or generalised methods. The abstractions can also be technical principles, ideas and theories that need to be memorised and applied. 4 - Analyse Deconstructing a message into its basic elements or parts so that a hierarchy of ideas is clarified and/ or the relationships between the ideas expressed are emphasised. 3 5 - Combine Combining elements and parts into a whole. This includes the process of working with pieces, parts, elements, etc., as well as organising and assembling them in such a way that they form a pattern or structure that was previously not clearly recognizable. 6 - Assess Making assessments about the value of materials and methods given for a specific purpose. Quantitative and qualitative judgements about the extent to which materials and methods fulfil certain criteria. The criteria may be self-determined or predetermined. Table 1 - GPM Competence levels In accordance with the taxonomy released by PM-ZERT (GPM certification body) in January 2024, the topics within the ICB competence elements are categorised into one of the three competence levels. The competence levels relevant for IPMA ® Level D and the "Basic Certificate in Project Management" are 1 and 2. A corresponding mapping of the ICB elements to the chapters of the book is provided in the last chapter. 1 Taxonomy = a systematic and hierarchically organised structure of terms <?page no="17"?> 0.3 Literature [DIN20a] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. DIN 69901-5 Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH [UIBK16] Leopold-Franzens-Universität Innsbruck (Hrsg.). (o.J.). Arbeitsmaterialien - Universität Innsbruck. Abgerufen am 03.10.2023 von Information zur Lernzielbeschreibung: https: / / www.uibk.ac.at/ bologna/ curriculumsentwicklung/ dokumente/ taxonomie.pdf <?page no="19"?> Page | 19 1 Basics of Project Management Figure 1 - ICB Elements in project management basics The terms explained below ‒ project, project management, process, task, project portfolio, project management office and project types ‒ are the content of the ICB elements Governance, structures and processes and Project design. Governance, structures and processes (4.3.2) ‘The competence G OVERNANCE , STRUCTURES AND PROCESSES defines the understanding of and alignment with the organisation's established structures, systems and processes that provide support for projects and influence their organisation, implementation and management.’ [GPM17a, page 47, translated] Project design (4.5.1) ‘The competence P ROJECT DESIGN defines how the needs, wishes and influences of the organisation(s) are interpreted and weighted by individuals and transferred to the highest level of project design to ensure the highest probability of success.’ [GPM17a, page 106, translated] <?page no="20"?> 20 | Page 1.1 Terminology 4.3.2 Governance, structures and processes | 4.5.1 Project design / Competence level 1 Term Explanation Project DIN 69901 defines a project as a ‘project that is essentially characterised by the uniqueness of its conditions’ [DIN20a]. According to ICB 4.0, a project is ‘a one-off, time-limited, interdisciplinary, organised undertaking to achieve specified work results within the framework of predefined requirements and framework conditions’. [GPM17a] The characteristics of a project derived from this are  defined beginning and end  at least one goal  professional (interdisciplinary) and socially complex  project-specific organisation  limited resources  unique, new Project management DIN 69901 defines project management as ‘the entirety of management tasks, organisation, techniques and resources for the initialisation, definition, planning, control and completion of projects’ [DIN20a] . ICB 4.0 adds ‘Project management is concerned with the application of methods, tools, techniques and competences for a project in order to achieve objectives.’ [GPM17a] Project management is a temporary task over the course of a project. Programme Time-limited project that includes several related projects that all aim to achieve an overarching (strategic) goal Programme management The totality of management tasks, organisation, techniques and resources for the selection, definition, initialisation, definition (integrated) planning and control of projects that have an overarching (strategic) objective and are combined in a programme. Programme management is a temporary task over the course of a programme. Multi-project management (MPM) Application of project management methods and procedures in multiproject situations, e.g. by coordinating deadlines, resource utilisation, delivery objects etc. between several projects in order to exploit synergy effects and avoid mutual disruptions. MPM provides an organisational and procedural framework for the management of several individual projects. Depending on the type and scope of the project situation, it can be divided into the areas of programme management and project portfolio management [SEID19] [MOTZ17]. Project portfolio A project portfolio bundles projects in a defined area of responsibility for the purpose of overarching planning and control. It is based on the overarching objective (e.g. from the strategy) of the company, selects projects taking into account scarce resources and initiates their implementation [DIN20d, PATZ17]. <?page no="21"?> Page | 21 Term Explanation Project portfolio management In contrast to project and programme management, project portfolio management is a permanent task. Like project management, project portfolio management also encompasses the entirety of management tasks, organisation, techniques and resources, but here for the overarching planning and control of an organisation's project portfolios [DIN20d, MOTZ17]. Process Generally speaking, a process is a series of activities that generate a defined result (output) from a defined input, which makes this simple definition more precise [MOTZ17]. It describes a process as a ‘sequence of related and/ or interrelated process steps that have a beginning and an end in time and are converted into results by the inputs.’ Project management processes can be found in DIN 69901, which defines a minimum standard for project management [DIN20a]. Task In the project context, tasks are ‘requests derived from objectives to individuals, groups of people or organisations to complete a certain task ... under given conditions and using certain means and to achieve the specified objectives.’ [MOTZ17] Table 2 - Terminology 1.2 Project management office 4.3.2 Governance, structures and processes / Competence level 1 A project management office (PMO) is a mostly permanent cross-project support function which provides the methodological framework and PM standards for the projects on the one hand and accompanies the introduction and optimisation of the company's project management system on the other. Another key task is to provide operational support to project managers and other project participants. The following table shows examples of the tasks, competences and accountabilities (TCA - see also section 3.5.2) of the PMO (based on [PFET20] and [PATZ17]) Task  Classify and review project applications  Prepare meetings of the steering committee  Maintain the project portfolio  Advise and train project participants in the use of the PM manual / procedure model  Maintain and further develop the PM manual / procedure model  Organise the exchange of experience between project managers Competence (Authority)  Demand compliance with the specified guidelines for project management (PM manual / procedure model)  Request project status reports <?page no="22"?> 22 | Page Accountability  For informing the applicant about the status of their project application  For transparency about critical developments in the project portfolio or in the event of resource overload Table 3 - TCA of a PMO (example) 1.3 Project types 4.3.2 Governance, structures and processes | 4.5.1 Project design / Competence level 1 Projects are categorised into different dimensions in common practice. Project types are often classified according to their object (project content) [GPM17b]  Investment project  Research and development project  Organisational project Project type Explanation Investment project Require a high degree of planning and control according to their plan Examples: Construction of roads, exhibition halls or the procurement of aeroplanes, ships or large machinery Research and development project (R&D) Relationship between input and output is often uncertain, solutions are usually reproducible Examples: Development of drugs, concepts and products Organisational project (change project) Require variable planning, as the foundations of the project change as a result of the project. This circular relationship between cause and effect requires continuous adaptation of the approach. Examples: Developing or improving the performance or effectiveness of an organisation and / or the organisational implementation of specific projects (trade fairs, congresses) Table 4 - Project types according to content There are numerous other ways of classifying projects, for example according to the project organisation (see section 3.5.1, page 78), the type of project management (technocratic or agile project), project volume (i.e. budget amount), risk class, complexity or strategic importance. Depending on the categorisation, this generally has an impact on the classification of the project (ABC project). <?page no="23"?> Page | 23 1.4 Project success / Project management success 4.5.1 Project design / Competence level 1 According to DIN 69901-5, project success is the ‘summarised result of the assessment of the project with regard to the achievement of objectives.’ On the one hand, this is based on compliance with the contractually defined parameters ‒ costs, deadline, performance as a directly measurable result. On the other hand, the recognition and positive assessment of the project results by the client and customer, but also by the project staff and the project manager [DIN20a]. The original dimensions of the project's success are as follows  meeting the planned costs and deadlines  the expected performance or quality of the (technical) solution  the satisfaction of those involved In addition to this, further factors that make a project successful can be found in the literature [KERZ22].  Minimal change to the project objective, i.e. changes to the framework conditions were kept to a minimum and agreed between the project manager and the client.  the company continued to work without disruption, i.e. the project was carried out within the guidelines, processes, rules and specifications of the organisation  the corporate culture was not changed, i.e. even if every project is unique by definition, the project manager should not expect the members of the project team to deviate from the company norms. Depending on when it is analysed, project success can be divided into business success (referring to the impact or success on the market, i.e. the client's benefit objectives) and implementation success (referring to the successful delivery of the of the project in time, scope and budget) [MOTZ17]. Figure 2 - Examples of project management success factors Project management success is closely linked to project success but should not be regarded as identical. Professional project management has proven to increase project success in many cases. A decisive factor for project management success is the effec- <?page no="24"?> 24 | Page tive and efficient combination of project requirements, activities and results in order to realise the objectives and achieve successful project completion. Project management success is also considered to be a positive assessment by the most important stakeholders with regard to their satisfaction with the handling of the project [PATZ17]. Project management success already starts with the selection of the right process model for handling the project. 1.5 Project management approaches and process models 4.5.1 Project design / Competence level 1 1.5.1 Sequential PM approach A sequential approach structures projects into phases that are worked through one after the other. Strictly speaking, one phase must be successfully completed before the next phase can begin. This means that the results of a previous phase are often the necessary prerequisites for the subsequent phase [TIMI24, GPM17b]. Other terms used for this are ‘plan-driven or forecasted PM approach’, because most of the planning is done in advance and then executed or implemented. Typical representatives are the waterfall model (see chapter 3.4 Project phases for an example) and the V-Model XT. The latter is a German standard for the planning and implementation of system development projects. It is used in companies, public authorities and in the military sector. 1.5.2 Iterative PM approach The iterative PM approach is one of the so-called ‘repetitive process models’. To improve the respective work results, feedback is obtained from the client after each iteration in order to continuously improve the unfinished work and ultimately achieve the defined goal. From a management perspective, an iterative approach is a way of dealing with uncertainties in complex situations. A typical representative of this approach is Design Thinking. 1.5.3 Incremental PM approach Like the iterative PM approach, the incremental PM approach is a ‘repetitive process model’. The individual steps are run through sequentially from the requirement to the first partial result, i.e. for each increment, the requirements for the intermediate goal are formulated, then developed, implemented and tested. This is repeated until the finished overall result is available at the end [TIMI24, GPM17b]. This procedure is suitable for  Project work with high uncertainties  a lack of experience in processing  volatile 2 requirements Typical representatives of this approach are the spiral model and Rational Unified Process (RUP). 2 in the sense of: mobile, inconstant, changeable <?page no="25"?> Page | 25 1.5.4 Agile PM approach The iterative-incremental approach of the agile approach provides the customer with a functional system as quickly as possible. The system is improved in short iteration loops and expanded with additional functions [GPM17b]. Further features of this PM approach are  Timeboxing: The individual iterations are run through in fixed time intervals, meaning that all participants can rely on the deadlines set. In the event of problems, the deadline is not postponed, but the scope of the version to be created is adjusted (see also section 8.1.1 Timeboxing).  Self-organised teams: The members of the team are basically equal. The team has the autonomy to organise itself in such a way that it can fulfil the work requirements in the best possible way.  Change-friendly project culture: In contrast to the classic waterfall model, requirements and technologies are not placed under change control in a ‘design freeze’. Changes are seen as a friend, not an enemy of the project and are therefore part of the product development cycle. When designing the agile PM approach, various framework conditions such as the Agile Manifesto with its four value pairs and 12 principles that specify these value pairs must be taken into account. As these value pairs are repeatedly referred to in the Agile world, they are briefly described here. The founders of the Agile Manifesto considered  … Individuals and interactions more important than processes and tools  … Functioning software more important than comprehensive documentation  … Collaboration with the customer more important than contract negotiation  … Responding to change more important than following a plan In the agile world, the focus is on the left-hand side of the statement, but the right-hand side is not neglected. 3 Typical representatives of this approach include Scrum, Crystal, eXtreme Programming (XP), Feature Driven Development (FDD) and Kanban. 1.5.5 Hybrid PM approach The hybrid project management approach refers to the use of methods, roles, processes and phases of different standards or process models. In most cases, classic project management is used as a basis and agile elements are added in various approaches [TIMI24, MOTZ17]. In a study of over 1000 participants at the University of Konstanz (Germany), 37% of respondents stated that they work on projects / development processes using a ‘hybrid form’. They utilise the strengths of the different approaches by combining them. The study also shows that the tools most frequently used in a hybrid environment come from the agile method box [KOMU17]. Similar to the fable of the monkey and the elephant, there is therefore increasingly an "as well as" instead of an "either or" [BOEH04]. 3 See http: / / agilemanifesto.org/ iso/ de/ manifesto.html <?page no="26"?> 26 | Page An elephant supplies a village with food through his strength, discipline and reliability. After the cooks in the village demand increasingly exotic ingredients that the elephant had heard of but could not find along its path, the elephant loses popularity and reputation (classical methods). At the same time, there was a monkey in a nearby village that had the same task as the elephant. Unlike the elephant, the agile monkey searched for food all over the jungle. His search meant that he was not always punctual in his deliveries, but he always brought back exotic foods and ingredients. His problem began with the steadily growing population in his village and his limited transport capacity. The villagers became impatient, and the monkey doubted his ability to fulfil his mission (agile methods). Fortunately, one day the discouraged elephant and the resigned monkey meet. Both proud of their respective abilities but also impressed by the other's expertise. They quickly realised the benefits of working together and decided to join forces. From then on, the monkey took care of the exotic wishes of the two villages, while the elephant took over the supply of sufficient quantities of basic food supplies (combination of classic and agile methods). Typical representatives of this approach are Reliable Scrum (Scrum and Critical Chain), the Water Scrum Fall Model, the V-Scrum-Modell (Agile V) and Scrumban (Scrum and Kanban). 1.5.6 Evolutionary PM approach Evolutionary project management builds on what already exists, reacts immediately to changes, incorporates experience directly, utilises freedom and tries out further innovations in the sense of ‘trial and error’ based on the status achieved. Evolutionary PM is characterised by step-by-step target development and refinement [LITK05]. Prototyping is a typical representative of this approach. 1.5.7 Bottleneck-orientated PM approach The bottleneck-oriented PM approach or critical chain project management (CPM) is based on a system-orientated management approach for identifying and eliminating bottlenecks founded by E LIYAHU G OLDRATT . The aim is to shorten the project duration and increase adherence to deadlines [TECH10]. In critical chain PM, a project is seen as a network of different processes. The performance of the network is limited by a bottleneck process. To increase efficiency, G OLD - RATT proposes a thinking process with five steps [BEA19b, ANDE12] 1. identify the bottleneck 2. (optimal) utilisation of the bottleneck 3. align all processes with the bottleneck 4. eliminate the bottleneck 5. control and continue with step 1 (based on a bon mot from S EPP H ERBERGER : ‘After the bottleneck is before the bottleneck’) A typical representative of this approach is the Theory of Constraints (ToC). <?page no="27"?> Page | 27 1.6 Standards in project management 4.3.2 Governance, structures and processes | 4.3.3 Compliance, standards and regulations / Competence level 1 In this chapter on the basics ‒ Compliance, standards and regulations ‒ we look at the current national and international standards for project management. These include  the DIN 69900, 69901 and 69909 series of standards known in Germany  the international counterpart ISO 215xx  the PMBoK Guide of the Project Management Institute  PRINCE 2  PM2  the basis for this book, the Individual Competence Baseline 4.0 Compliance, standards and regulations (4.3.3) ‘The competence C OMPLIANCE , STANDARDS AND REGULATIONS defines how the individual interprets the external and internal restrictions in a particular area ... and harmonises them.’ [GPM17a, page 53] 1.6.1 Series of norms DIN 69900, 69901 and 69909 A whole series of project management norms exist in Germany. One of the oldest is DIN 69900 ‘Project management ‒ Network planning techniques; descriptions and terminology’ from 1987. The scope of this standard is limited to network planning techniques and other methods for scheduling and scheduling and defines the associated terminology [DIN20e]. DIN 69901 ‘Project management ‒ Project management systems’ with its five parts from 2009 is newer and more up to date.  Basics  Processes, process model  Methods  Data, data model  Terms DIN 69901-2 (Project management ‒ Project management systems ‒ Part 2: Processes, process model) describes five process groups, the five project management phases ‘initialisation, definition, planning, control and closure’, 11 process subgroups (e.g. process and deadlines, changes, organisation, quality) and 59 processes. With its process descriptions, it provides a good basis for managing projects. However, as with most models, these processes need to be customised for specific projects. This is often done company wide as part of project management standardisation (e.g. by drawing up and implementing a project management manual, see chapter 1.6.7) or it is done by the project manager according to the individual requirements of their project. DIN 69901-5 defines basic project management terms and regulates the nomenclature for many technical terms in project management. This part is, so to speak, the glossary of the standard [DIN20a]. <?page no="28"?> 28 | Page The latest addition to this series is DIN 69909 ‘Multi-project management ‒ Management of project portfolios, programmes and projects’ with currently four parts (basics, processes, methods and roles) from 2013 [DIN20d]. 1.6.2 The ISO 21500 family The international project management standard series ISO 21500 has since been revised following its first publication in 2012. The original ISO 21500: 2016 (Guidelines for project management) became DIN ISO 21502: 2020 ‘Guidelines for project management’ in 2020. ISO 21500: 2021 is now the ‘parent standard’ of the ISO 215xx family and is known as ‘Project, programme and portfolio management - Context and concepts’ ISO 21502 also describes five process groups (initiation, planning, implementation, controlling, closure). Compared to DIN 69901, it has ten process subgroups (e.g. integration, stakeholders, scope of services) and 38 processes. It provides a generally valid overview of the essential contents of project management and thus enables easy adaptability to the respective company-specific framework conditions [DIN20b]. This standard now has a number of supplements, such as ISO 21503: 2022 ‘Guidelines on programme management’ and ISO 21505: 2018 ‘Guidelines on governance’. 1.6.3 PMBOK ® Guide A Guide to the Project Management Body of Knowledge (PMBOK ® Guide) from the Project Management Institute (PMI) has been available in its seventh edition since 2021 and contains the official standard of the American National Standards Institute (ANSI) for project management (ANSI/ PMI 99-001-2021). With the seventh edition of this standard work, the PMI is taking a new approach. The guide now provides a system-orientated view of project management. The five process groups (initiating, planning, executing, controlling, closing) and the associated knowledge areas of the previous editions have been replaced by eight so-called performance domains. These are stakeholder, team, development approach and life cycle, planning, project work, delivery, measurement, uncertainty [PMI21a]. 1.6.4 PRINCE2 ® PRINCE2 ® - Projects In Controlled Environments (7 th Edition 2023) is a cross-industry project management system consisting of four integrated building blocks. These are seven basic principles (e.g. learning from experience, defined roles and responsibilities), topics (e.g. business case, organisation, quality), processes and the project environment. The seven processes can be divided into three management levels:  Steering - preparation, control  Manage - initiation, control, managing a phase transition, completion  Deliver - managing the product delivery PRINCE2 ® is published and further developed by AXELOS, a British company that is also responsible for the widely used IT Service Management ITIL ® (IT Infrastructure Library) [AXEL17]. <?page no="29"?> Page | 29 1.6.5 PM 2 The PM 2 Project Management Methodology Guide is a project management methodology developed and supported by the European Commission's Centre of Excellence in Project Management (CoEPM 2 ). It focuses on bringing together the different project management approaches within the EU administration by establishing a standardised terminology and collective procedures. The phase model consists of five phases - initiation, planning, implementation and completion. The fifth phase - monitoring and control - is overarching from the beginning (initiation) to the end of the project (completion). The model is based on proven standards in project management, ICB 4.0, PMBOK ® Guide, PRINCE2 ® and PRINCE2 ® Agile [CEPM21]. 1.6.6 ICB 4.0 The Individual Competence Baseline Version 4.0 of the International Project Management Association (IPMA ® ) is a competence-based standard. It does not contain any process descriptions, but instead represents a comprehensive catalogue of individual competences. ICB 4.0 is divided into three domains - project, programme and portfolio management. The competence elements contained in these three standard works are in turn divided into three areas:  Context competences (Perspective) Methods, tools and techniques with which an individual can interact with their environment  Personal and social competences (People) Attributes that an individual needs in order to successfully lead or participate in projects  Technical competences (Practice) Specific methods, tools and techniques used in project management Figure 3 - Eye of Competence (IPMA ® ) This ‘Eye of Competence’ represents a (competence) spectrum that people who work in or manage projects, programmes or portfolios should have. ICB 4.0 makes no distinction in terms of sectors or industries [GPM17a]. The focus of this book is on the domain of project management. 1.6.7 Project management manual management manuals or PM policies to ensure a uniform approach to project management throughout the organisation. The PM manual can be part of the organisational manual or, if applicable, the company's quality management manual. In the simplest case, the PM manual is a compilation of e.g. checklists and forms for project management. In most cases, it contains a company-specific process model for planning, monitoring and controlling projects [MOTZ17]. <?page no="30"?> 30 | Page Project management manual vs. Project manual The project management manual is an internal company guideline or project management guide and usually contains a company-specific process model as well as a compilation of e.g. checklists and forms for project management [MOTZ17]. The project manual is a project-specific compilation of information, regulations, standards and tools for planning and implementation as well as monitoring and control. It is usually created at the start of the project and continuously updated [MOTZ17]. Contents: project definition and performance planning, project organisation, project information system and communication, project planning, project monitoring and control, project closure. 1.7 Literature [ANDE12] Anderson, D. J. (2012). Kanban. Evolutionäres Change Management für IT-Organisationen. Heidelberg: dpunkt.Verlag [AXEL17] AXELOS (Ed). (6 th Edition 2017). Managing Successful Projects with Prince2. Norwich: The Stationery Office Ltd. [BEA19a] Bea, F. X., Scheurer, S., & Hesselmann, S. (3., vollst. überarb. u. erweit. Aufl. 2019). Projektmanagement. Konstanz: UVK Verlagsgesellschaft [BOEH04] Boehm, B., & Turner, R. (2004). Balancing Agility and Discipline. A Guide for the Perplexed. Boston: Addison Wesley Professional [CEPM21] Centre of Excellence in Project Management. (2021). PM² Project Management Methodology Guide 3.0.1 (European Commission, Hrsg.) Brüssel [DIN20a] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. DIN 69901-5 Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH [DIN20b] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. ISO 21500 Leitlinien Projektmanagement (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH [DIN20d] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. DIN 69909-1 Multiprojektmanagement - Management von Projektportfolios, Programmen und Projekten - Teil 1: Grundlagen (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH <?page no="31"?> Page | 31 [DIN20e] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. DIN 69900 Projektmanagement - Netzplantechnik; Beschreibungen und Begriffe (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH [GPM17a] Deutsche Gesellschaft für Projektmanagement e.V., (Hrsg.). (1., aktual. Aufl. 2017). Individual Competence Baseline für Projektmanagement, Version 4.0 / Deutsche Fassung (Bd. 1). Nürnberg: Deutsche Gesellschaft für Projektmanagement e.V. (GPM) [GPM17b] GPM, SPM, & Gessler, M. (Hrsg.). (8. Aufl. 2017). Kompetenzbasiertes Projektmanagement (PM3): Handbuch für die Projektarbeit, Qualifizierung und Zertifizierung auf Basis der IPMA Competence Baseline Version 3.0. Nürnberg: GPM Deutsche Gesellschaft für Projektmanagement e.V. [KERZ22] Kerzner, H. (13. Aufl. 2022). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. Hoboken, New Jersey: Wiley [KOMU17] Komus, A., et. al. (2017). Abschlussbericht: Status Quo Agile 2016/ 2017 - 3. Studie über Erfolg und Anwendungsformen von agilen Methoden. Koblenz: Hochschule Koblenz University of Applied Science [LITK05] Litke, H.-D. (Hrsg.). (2005). Projektmanagement - Handbuch für die Praxis. Konzepte - Instrumente - Umsetzung. München: Hanser Fachbuchverlag. [MOTZ17] Motzel, E., & Möller, T. (3., überarb. u. aktual. Aufl. 2017). Projektmanagement Lexikon: Referenzwerk zu den aktuellen nationalen und internationalen PM-Standards. Weinheim: Wiley-VCH Verlag [PATZ17] Patzak, G., & Rattay, G. (7., überarb. Aufl. 2017). Projektmanagement: Leitfaden zum Management von Projekten, Projektportfolios und projektorientierten Unternehmen. Wien: Linde Verlags GmbH [PFET20] Pfetzing, K., & Rohde, A. (7., vollst. überarb. Aufl. 2020). Ganzheitliches Projektmanagement. Wettenberg: Verlag Dr. Götz Schmidt. [PMI21a] Project Management Institute Inc. (7 th Edition 2021). A guide to the Project Management Body of Knowledge (PMBOK Guide) und Der Standard für das Projektmanagement. Pennsylvania: PMI Inc. [SEID19] Seidl, J. (2019) Grundlagen und Begriffe des Multiprojektmanagements. In Hüsselmann, C. / Seidl, J. (Hrsg.) (2019). Multiprojektmanagement: Herausforderungen und Best Practices, o.O: Lehrbuchverlag [TECH10] Techt, U. (4. Aufl. 2010). Goldratt und die Theory of Constraints. Moers: Editions La Colombe. [TIMI24] Timinger, H. (2. Aufl. 2024). Modernes Projektmanagement. Mit traditionellem, agilem und hybridem Vorgehen zum Erfolg. Weinheim: Wiley- VCH Verlag <?page no="33"?> Page | 33 2 Initialisation phase Figure 4 - ICB elements in in the initialisation phase A project is initiated either by the internal environment of a company (e.g. management's reaction to an identified problem, request from a specialist department) or by the external environment (e.g. a tender won, customer request / order, changed market conditions) [GPM17b]. 2.1 Selection of projects Strategy (4.3.1) "The competence S TRATEGY defines how strategies are understood and broken down into manageable elements with the help of projects. This competence defines a powerful management system in which projects are considered and managed in terms of their alignment with the strategy and vision to ensure that they correlate as strongly as possible with the mission and sustainability of the organisation" [GPM17a, page 42] 2.1.1 Vision, mission, strategy 4.3.1 Strategy / Competence level 1 Projects are usually not implemented for their own sake, but to support the company's business purpose. For this reason, the project objectives are derived from the company's vision, mission and strategy. <?page no="34"?> 34 | Page Figure 5 - Objectives‘ pyramid of the organisation Vision At the top of the goal hierarchy is a general and fundamental idea of the future role of the company. This vision is usually formulated using ambitious terms and describes an ideal state in the future [BEA19b]. The vision is a decisive component of corporate management, as it makes it clear to all employees in a concise and descriptive form what is at stake. It can also include and name specific elements on the way to this ideal state. The most important corporate goals and strategies can be derived from the corporate vision. The vision marks a longterm, directional orientation towards the future [FLEI22]. A good vision expresses:  Why we do what we do.  Where we want to be in five to ten years.  What is important to us, even in difficult economic times.  What values we would pursue even if the company were exposed to turbulent times.  What we would uphold even if it appeared to be an (apparent) disadvantage in competition. The vision embodies the corporate philosophy. Mission The mission of a company describes the main purpose or task that the company is pursuing. It explains why the company, or an organisational unit exists and what it wants to be for its stakeholders - customers, owners, employees or partners [FLEI22, BEA17]. <?page no="35"?> Page | 35 The mission corresponds to the corporate policy and expresses the company's own mandate to realise its vision. Strategy A strategy is a long-term, planned endeavour to pursue a specific (corporate) goal. The corporate strategy shows how a medium-term (approx. 2 to 4 years) or long-term (ap-prox. 4 to 8 years) corporate goal is to be achieved. Strategic goals substantiate the vision / mission and set the basic framework for the organisation's actions. The success of the organisation can be measured on the basis of these objectives [SZTU, BEA17]. Example - Deutsche Post DHL Group 4 (translated) Our Vision We are THE Logistics company for the world Our Mission Connecting people, improving lives. Excellence. Simply Delivered. Our Strategy 2025 Top performance in a digital world. 2.1.2 Evaluation of the project idea Companies usually have limited resources - money, human and material resources must be used in such a way that they efficiently and effectively support the company's goals [BEA11]. Since projects require and consume resources to be implemented, it is only logical that only projects that optimally contribute to achieving these business goals should be carried out. In addition to their own strategic planning process as a source of project ideas, projects are increasingly being triggered by changes in the company's environment - e.g. new technologies, changes in legislation or the market entry of a new competitor [PATZ17]. Selecting the right projects in the company is the task of strategic project management. This involves checking whether the project is fundamentally feasible. This initial ‘preselection’ is to ensure that unsuitable projects are not tackled in the first place. ”You can do the wrong thing incredibly efficiently.” unknown author Examples of selection criteria for suitable projects include  customer benefit  cost reduction potential  strategic significance  improved responsiveness  risk  urgency (must-have project - concerns urgent topics, such as legal changes) However, the assessment of economic efficiency is becoming increasingly important. From an economic point of view, projects can be categorised according to the  amortisation period (time required to recover the investment) 4 https: / / www.dpdhl.com/ de/ ueber-uns/ strategie.html, accessed on 11.08.2023 <?page no="36"?> 36 | Page  net present value method (project is profitable if the sum of all incoming and outgoing payments is positive)  risk assessment (variants calculation, sensitivity analysis) evaluated and selected [KERZ22, PATZ17]. For external customer orders, the criterion for measurement is the result after costs, i.e. the contribution margin to be earned with the project. 2.1.3 Success factors 4.3.1 Strategy | 4.5.1 Project design / Competence level 1 Success is not only based on actions and the combination of different approaches, but also on external ‘circumstances’. These external circumstances manifest themselves in the success factors for the project. Success factors are key factors that are of central importance for achieving the overall goals of a project. If the sum of these factors is right, the project as a whole will be successful. If there are deficits, this will directly affect the overall success. Project management success factors are therefore courses of action and situations that can increase the success of a project [GABL18, MOTZ17]. A distinction is made between standard success factors and critical success factors (CSF). According to the annual survey by Standish Group International Inc. (CHAOS report), critical success factors are, for example: management attention, realistic expectations, competent team members, clear vision and goals, customer availability and stakeholder management. Success factors vs. Success criteria Success factors are key variables or frame conditions that are of central importance for achieving the overall objectives of a project [GABL18]. Success criteria are characteristics, properties and evaluation standards that can be used to measure and assess the success of a project. The project success criteria must be specifically identified, analysed and evaluated for each project. They should be clearly understandable and measurable. In particular, the objectives and benefits for the client, the various project participants and the users of the project results should be considered [MOTZ17]. It is useful to find out the subjective success criteria of the important stakeholders and take them into account. <?page no="37"?> Page | 37 2.1.4 Benefit analysis 4.3.1 Strategy / Competence level 1 In addition to the ‘hard’ cost criteria, the qualitative selection criteria mentioned above, such as strategic importance, customer benefit and urgency, can also be taken into account. The benefit analysis allows the combination of ‘hard’ and ‘soft’ criteria and thus an overall assessment of the project. A point value is determined for all projects under consideration [NAGE95]. Procedure 1. Determine and weight the criteria (total of the weights = 10 or 100%). 2. Award points for the fulfilment of the criteria by the individual projects (values from 1 - 10). 3. Multiply the weights (W) by the points (P). 4. Add up the results for each criterion and project. 5. Assign the total for each project to an attractiveness scale and make the appropriate selection Project A Project B Project C Mandatory Project no no yes Criteria W P W * P P W * P P W * P Rentability 3 7 21 10 30 Urgency 1 9 9 4 4 Customer benefit 2 10 20 7 14 Risk 5 1 9 9 4 4 Strategy 3 5 15 9 27 Total 10 74 79 implement Table 5 - Benefit analysis (example) According to the utility analysis, project B would be the first choice for implementation after project C (mandatory project). This method can also be used in the further course of the projects, for example, when prioritising goals or evaluating alternative solutions. In this way, strategic project management can ensure that the right projects are selected (effectiveness), while operational project management then implements them correctly (efficiency). 5 Note: high score = low risk, low score = high risk <?page no="38"?> 38 | Page 2.2 Project definition 2.2.1 Business case 4.3.1 Strategy / Competence level 1 The business case or proof of economic viability is a documented feasibility study that presents the reason for the project and thus the benefits for the organisation, including the business benefits (→ benefit objectives). As a rule, the responsibility for preparing this document lies with the client. The business case also sets out the objectives for project initialisation and can therefore be used as a measurement criterion for project closure [GPM17a, PMI21a]. There is no standardised template for creating a business case. However, the PRINCE2 PM method provides a guideline with the following sections [TURL]: Executive summary Brief overview of the business case Reasons Motivation for realising the project Business options Options for implementing the project with quantitative and qualitative evaluation Expected benefits Listing of benefits with reasons and measurements Expected dis-benefits Results that are viewed negatively by stakeholders and/ or have negative side effects Timescale When the project starts and finishes and when it will break even Costs Project costs and costs incurred after completion Investment appraisal Information on return on investment (ROI), net present value, cost-benefit analyses Major risks Summary of major risks for the project Table 6 - Guideline Business Case 2.2.2 Project profile 4.5.2 Requirements and objectives / Competence level 2 Another document used to describe the scope of services of the project is the project profile (see Figure 6). It presents the essential key data of the project briefly and concisely. This includes  project name and project number  a description of the content  the project objectives  information on duration, start and end  a statement on the budget <?page no="39"?> Page | 39  information on the client and/ or customer  persons involved (project manager, project team)  an overview of the planned project phases The project profile does not replace the detailed description of the scope of services and deliverables, but rather provides an overview of the project and its special features. Usually, an attempt is made to limit this document to a single A4 page. Depending on the language used and the company's specifications, the project profile is also referred to as a project definition sheet, project description, project application, project order or project charter [PATZ17, MOTZ17]. 2.2.3 Project canvas 4.5.2 Requirements and objectives / Competence level 2 (Level C) Another way to present a project in a clear way is to use the project canvas. This tool is used to create a collective understanding of the project. Originally developed as the business model canvas by A LEXANDER O STERWALDER and Y VES P IGNEUR , this method aims to establish a common language for describing, visualising, evaluating and adapting business models. The complex structure of a business model is broken down into nine key components and structured using predefined questions [OSTE11]. A similar approach, probably the best known, is the ‘7-S Framework’, which was developed by McKinsey in the 1970s for business analysis. When applied, it provides a checklist for the most important elements of an organisation [ASSE14]. The Project canvas applies a similar principle to projects by breaking down a complex undertaking into eleven key components (see Figure 7). As with the original, there are supporting questions for these components to facilitate understanding. Presenting them on a canvas provides a visual overview of the project, the collective ‘big picture’ HABE18]. <?page no="40"?> 40 | Page PROJECT PROFILE Project no.: CT-22 Project description Installation of a new climbing tower on the S UMMIT S EEKERS ’ clubhouse site. Project client / sponsor Ben Boulder, chairman of the S UMMIT S EEKERS A SSOCIATION . Project manager Percy Peakson, full-time CEO of the S UMMIT S EEKERS A SSOCIATION Brief description of the project Dismantling of the old climbing tower and construction of a new (extended, modernised) climbing tower to provide more climbing and training opportunities. Project start event Resolution at the Annual General Meeting, Nov. 2021 Project start date Oct 30 th , 2021 Project duration 29 months Project end event Handover to the association Project end date Mar 24 th , 2024 Project objectives − The old climbing tower is dismantled and the area is ready for the new tower. − The new tower has been erected and approved. − The required number of routes with the corresponding difficulty levels according to UIAA are installed. Milestones M1 Oct 30, 2021 Project manager appointed M2 Feb 20, 2022 Project approved by the board, positive resolution of the AGM is available M3 Sep 17, 2022 Specialist supplier selected M4 Nov 02, 2023 Demolition carried out; area cleaned up M5 Mar 01, 2024 Acceptance of new tower M6 Mar 24, 2024 New climbing tower handed over to the association Project resources and project budget Resource type Amount / unit Budget (in €) Personnel budget 40.000.- Material costs 360.000.- Risk budget 0.- Total budget 400.000.- Major risk(s) Planning permission is not granted or is granted late. Project team members Percy Peakson, PM / Jenny Leftfoot, branch office / Reginald Rockwell, chairman of Boulder Ltd./ Craig Mountjoy, climbing instructor / Abe Moneypenny, CFO Project client Project manager ________________________________ Date, Signature _______________________________ Date, Signature Figure 6 - Sample project - Project profile <?page no="41"?> Page | 41 Figure 7 - Project canvas 6 6 Source: https: / / ipma.world/ project-canvas-defining-projects-in-a-structured-way/ , unchanged <?page no="42"?> 42 | Page 2.3 Literature [ASSE14] van Assen, M., van den Berg, G., & Pietersma, P. (2. Aufl. 2009). Key Management Models. Harlow: Pearson Education. [BEA11] Bea, F. X., Friedl, B., & Schweitzer, M. (10., neubearb. u. erweit. Aufl. 2011). Allgemeine Betriebswirtschaftslehre. Band 2 Führung. Stuttgart: UTB / Lucius & Lucius [BEA19b] Bea, F. X., & Haas, J. (10. Aufl. 2019). Strategisches Management. Konstanz: UVK Verlagsgesellschaft mbH [FLEI22] Fleig, J. (29. Juli 2022). Was Vision und Mission im Unternehmen bewirken. Abgerufen am 08. August 2023 von business-wissen.de: https: / / www.business-wissen.de/ hb/ was-vision-und-mission-im-unternehmen-bewirken/ [GABL18] Szczutkowski, A. (19. Februar 2018). Definition kritische Erfolgsfaktoren. Abgerufen am 08. August 2023 von Gabler Wirtschaftslexikon: https: / / wirtschaftslexikon.gabler.de/ definition/ kritische-erfolgsfaktoren- 38219/ version-261645 [GPM17a] Deutsche Gesellschaft für Projektmanagement e.V., (Hrsg.). (1., aktual. Aufl. 2017). Individual Competence Baseline für Projektmanagement, Version 4.0 / Deutsche Fassung (Bd. 1). Nürnberg: Deutsche Gesellschaft für Projektmanagement e.V. (GPM) [GPM17b] GPM, SPM, & Gessler, M. (Hrsg.). (8. Aufl. 2017). Kompetenzbasiertes Projektmanagement (PM3): Handbuch für die Projektarbeit, Qualifizierung und Zertifizierung auf Basis der IPMA Competence Baseline Version 3.0. Nürnberg: GPM Deutsche Gesellschaft für Projektmanagement e.V. [HABE18] Habermann, F., & Schmidt, K. (2018). Over the Fence: Projekte neu entdecken, neue Vorhaben besser durchdenken und gemeinsam mehr Spaß bei der Arbeit haben. Berlin: Becota. [KERZ22] Kerzner, H. (13 th Edition 2022). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. Hoboken, New Jersey: Wiley [NAGE95] Nagel, K. (6. Aufl. 1995). 200 Strategien, Prinzipien und Systeme für den persönlichen und unternehmerischen Erfolg. Landsberg / Lech: verlag moderne industrie [OSTE11] Osterwalder, A., & Pigneur, Y. (2011). Business Model Generation: Ein Handbuch für Visionäre, Spieleveränderer und Herausforderer. Frankfurt a.M.: Campus Verlag. [PATZ17] Patzak, G., & Rattay, G. (7., überarb. Aufl. 2017). Projektmanagement: Leitfaden zum Management von Projekten, Projektportfolios und projektorientierten Unternehmen. Wien: Linde Verlags GmbH <?page no="43"?> [PMI21a] Project Management Institute Inc. (7 th Edition 2021). A guide to the Project Management Body of Knowledge (PMBOK Guide) und Die Norm für Projektmanagement. Pennsylvania: PMI Inc. [TURL] Turley, F. (o.J.). PRINCE2 Business Case Template. Abgerufen am 08. Aug. 2023 von PRINCE2 Business Case Template - PRINCE2 wiki: http: / / prince2.wiki/ PRINCE2_Business_Case_Template [SZTU] Sztuka, A. (o.D.). Normatives Management: Vision, Mission und Strategische Ziele. Abgerufen am 08. August 2023 von manager wiki: http: / / www.manager-wiki.com/ strategie-grundlagen/ 5-normatives-management-vision-mission-und-strategische-ziele#Strategische%20Ziele <?page no="45"?> Page | 45 3 Definition phase Figure 8 - ICB elements in the definition phase In the definition phase, the first step is to put together a core team for the project, which initially clarifies the following questions in this phase: [BERG21] Why? Why is the project carried out (definition of objective)? Where? Where is the project being worked on? In which environment (environment analysis)? Who? Which persons and companies are involved in the implementation and financing, and who is affected (stakeholder analysis and project organisation)? What? What needs to be done and when (phase plan and milestones)? Table 7 - Questions during the definition phase 3.1 How does a project begin? Project start 4.5.10 Plan and control / Competence level 1 „Show me how your project starts, and I will tell you how it ends.” Gero Lomnitz, founding member of IPO, Cologne (Germany) As already stated in chapter 1, an essential characteristic of a project is its time limit, i.e. its defined start and end. While project closure is clearly defined in the German DIN 69901 or the American ANSI/ PMI 99-001-2021, there is no clear statement regarding the start of the project [DIN20a, PMI21a]. This is all the more surprising given that it is common knowledge that the opportunities to influence the results of a project decrease rapidly as the project progresses, while the costs of changes increase to the same extent [GPM17b, KERZ22, BEA19b]. <?page no="46"?> 46 | Page Figure 9 - Options for influence and costs There are two different definitions for the term project start - an event or a phase or process. The project start event can be marked at different points, for example  First thought about the project by a responsible decision-maker  Client sends out the invitation to tender / specifications  Date of the project application  Response with the specifications for the invitation to tender / client's specifications  Approval of the project application (internal) or assignment (external) by the client  Date of opening a cost centre for the project  Kick-off meeting or start workshop  Date of the start milestone Figure 10 - Project start <?page no="47"?> Page | 47 Considering the different views, it is better to treat the project start as a separate phase. This phase or process can be divided into a section that is not yet solution-oriented and the subsequent conceptual part. The first section is referred to as the project start in the narrower sense, while the two together are considered the project start in the broader sense [GPM17b]. The project start in the narrower sense includes the initial clarifications for the project, such as clarification of the assignment, initial risk assessment, success factors and initial cost and effort estimates. This ultimately leads to the development of the project profile. This section is concluded by the project start workshop. This workshop serves to integrate the employees who are necessary for the definition and planning phase (core team). Preliminary decisions regarding the project organisation are also made here, and the provision of infrastructure and work equipment is organised. The project start in the broader sense includes additional analyses and many conceptual planning steps. Stakeholders and risks are analysed in more detail, plans are drawn up up to and including the schedule and schedule, and the required resources as well as costs and financial resources are determined and checked for availability. This section is concluded with the project kick-off, an ‘official event after successful planning, which brings together at least all members of the project team and, if necessary, representatives of the client side, in order to convey a collective understanding of the project to them and to initiate the work to be carried out’ [DIN20a, p. 153]. In this context, the 0 th commandment for project managers should not go unmentioned - ‘Never start an innovative task before you have seriously answered the following question: Who has already worked on a similar task, dealt with the topic and can contribute positive or negative experiences? ’ [SCHE16, page 55] This is not about ‘reinventing the wheel’ or ‘making every mistake yourself’, but about benefiting from existing knowledge and both positive and negative experiences. Nevertheless, caution is advised, because ‘experience does not necessarily always make you wise; experience can also make you stupid.’ [DÖRN11, page 257]. „We should be careful to get out of an experience only the wisdom that is in it - and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one anymore.“ Mark Twain (1835-1910), US-American writer, i.a. ‘The Adventures of Tom Saywer“ Practice shows that the project start phase has an enormous influence on the course of the project. Investing time in this phase lays important foundations for the later success of the project. 3.2 Project environment and stakeholders Stakeholders (4.5.12) ‘The competence element S TAKEHOLDERS includes the identification, analysis, inclusion and management of the attitudes and expectations of all relevant stakeholders’.... ‘Stakeholder participation is a continuous process that extends over the entire life cycle of the project.’ [GPM17a, page 155] <?page no="48"?> 48 | Page 3.2.1 Environment analysis 4.5.12 Stakeholders | 4.3.1 Strategy / Competence level 2 Before starting to plan the project, it is necessary to take a critical look at the project environment. The project environment is the environment in which a project is created and implemented, which influences the project and is affected by its effects. Project influences can result from social and factual environmental factors [BEA19a]. In terms of the extent of the project environment, a distinction can be made between  the immediate (direct) project environment, e.g. framework conditions, parallel projects,  the indirect project environment, e.g. company management, labour market. The terms ‘internal’ for company-internal and ‘external’ for company-external influencing factors are also often used [BEA19a]. The PESTEL acronym is a useful tool for identifying the factors in a project's factual environment. Among other things, the project manager can use it to show the relationships between the project and its environment. The acronym PESTEL stands for Acronym Explanation Examples P OLITICAL Current and potential influences from the political environment Regional, federal and European policy, media E CONOMIC Local, national and global economic factors Labour market, competitors, capital market, customs duties S OCIAL The socio-cultural environment and the effects of social change Corporate culture, project culture, working conditions, organisational form, migration, sustainability T ECHNOLOGICAL Influence / impact of technology Technical infrastructure, technological change E NVIRONMENTAL Local, national and global environmental influences Weather, environmental regulations, limited natural resources, waste disposal L EGAL Impact of local, national and international laws and regulations Laws, standards, regulations Table 8 - PESTEL Within the social factors, persons and/ or institutions are identified who can influence the project positively or negatively (see chapter 3.2.2 ‘stakeholder management’). A corresponding graphical representation of the collected environmental factors can look like this: An early analysis of the project environment as a systematic consideration of the positive (supportive) and negative (disruptive) influences on the project helps to identify opportunities and risks and to define an adequate communication strategy. The environment analysis is thus an important starting point for further analyses and the measures to be derived from them in the course of the project. <?page no="49"?> Page | 49 Factual environmental factors Social environmental factors internal Location of the association's land (in a conservation area) (FF1) Opportunities for self-contributions (FF2) Articles of association of the association S UMMIT S EAKERS (FF3) Chairman B. Boulder S UMMIT S EAKERS (SF1) Members of S UMMIT S EAKERS (SF2) J. Leftfoot, (office) (SF3) C. Mountjoy, climbing instructor (SF4) external Construction and inspection regulations: − Bavarian Building Code (BayBO) (FF4) − DIN EN 12572 (FF5) − DGUV Information 202-018 (FF6) − Product Safety Act (ProdSG) (FF7) Environmental protection: − Bavarian Nature Conservation Act (BayNatSchG) (FF8) − Federal Nature Conservation Act (BNatSchG) (FF9) − Regulation for the Implementation of the Bavarian Nature Conservation Act (AVBayNatSchG) (FF10) D. Molition, (Office for Building Law and Monument Protection) (SF5) W. Birdspotter, (Lower Nature Conservation Authority) (SF6) G. Makepeace, (Nature Conservation Officer) (SF7) Management of the CLEVER Union (SF 8) K. Hightop, (specialist tower construction company) (SF9) M. Checker, (TÜV-Süd) (SF10) Figure 11 - Sample project: Environment analysis Opportunities include all conditions that may arise during the project period that could help to achieve the project objectives more effectively. By contrast, risks include all conditions and situations that could potentially have a negative impact on the project. No distinction is made here between direct / indirect or internal / external. Factual environment factors Impact on the project Explanation Interaction with other factual environmental factors Risk Chance Neutral Location of the association's site (in a conservation area) (FF1) X The site is located in a landscape conservation area.  Restrictions imposed by the UNB and the building authority BayNatSchG (FF8), BNatSchG (FF9) Opportunities for selfcontributions (FF2) X Members can actively participate in the redesign  member involvement and binding Charter (FF3), BayBO (FF4) <?page no="50"?> 50 | Page Articles of association of the association Summit Seakers (FF3) X The statutes permit voluntary work. Self-contributions of members (FF2) Bavarian Building Code (BayBO) (FF4) X DIN EN 12572 (FF5) X Standard for artificial climbing structures DGUV Information 202-018 (FF6) X Recommendations for the safe construction and operation of artificial climbing walls Product Safety Act (ProdSG) (FF7) X Law on the provision of products on the market Bavarian Nature Conservation Act (BayNatSchG) (FF8) X Guidelines for construction projects in landscape and nature reserves Site location (FF1) Federal Nature Conservation Act (BNatSchG) (FF9) X Site location (FF1) … Table 9 - Sample project: Possible initial risk-opportunity assessment of the factual environmental factors The detailed analysis and the definition and implementation of appropriate measures are carried out for the social environmental factors in the stakeholder (see chapter 3.2.2 ‘stakeholder management’) and for the objective environmental factors in risk management (see chapter 4.6 ‘risk and opportunity’). 3.2.1.1 Environmental factors - legal conditions 4.3.3 Compliance, standards and regulations / Competence level 1 The PESTEL checklist includes legal (legal) environmental factors that the project manager has to take into account depending on the project, company and industry. Note: In some industries, the acronym HSSE or HSE - ‘Health, Safety, Security, and Environment’ is used to emphasise the importance of health, occupational safety, the security of operating facilities (in the broadest sense) and environmental protection. Health - refers to ensuring the physical and mental health of employees in the workplace.  Workplace regulations (ArbStättV) - the German Ordinance on Workplaces specifies what employers must observe when setting up and operating workplaces with regard to the safety and health of employees.  Working hours act (ArbZG) - sets out the basic standards for when and how long employees in Germany may work. The law thus ensures the health and safety of employees. <?page no="51"?> Page | 51  Maternity protection act (MuSchG) - protects pregnant women and mothers in principle against dismissal and in most cases also against a temporary reduction in income. It also protects the health of the (expectant) mother and the child against hazards in the workplace.  Youth employment protection act (JArbSchG) - is a law for the protection of children and young people in the world of work. It is one of the laws of social occupational safety and health.  Protection against infection act (InfSG) - is a law against dangerous or communicable diseases in humans and regulates the necessary cooperation and collaboration for this. It is intended to prevent communicable diseases, detect infect-ions at an early stage and prevent their spread. As the COVID pandemic has shown, this law also has an impact on occupational safety. For example, the ‘AHA-L’ formula (German for ‘distance, hygiene, respiratory protection, ventilation’) was introduced during the COVID-19 pandemic 7 Occupational safety and health (safety) - relates to the prevention of accidents and injuries at work.  Labour protection act 8 (ArbSchG) - regulates the fundamental occupational safety obligations of the employer, the obligations and rights of employees, and the monitoring of occupational safety in accordance with this law for all areas of activity. The ArbSchG stipulates in §5 the implementation of a risk assessment (see chapter ‘Risk assessment’). 9  Occupational safety act (AsiG) - According to this, the employer must appoint company doctors and occupational safety specialists. These are to support the employer in occupational safety and accident prevention.  Rules and regulations of the statutory accident insurance - The accident prevention regulation (UVV) describes how to provide first aid in the workplace and how to behave in the event of an accident, as well as the resulting obligations for employers and insured persons. Security - refers to the protection of operating systems, information and resources from internal and external threats Data protection  Data protection - protection of the individual from infringement of their right to informational self-determination, by virtue of which every citizen may, in principle, determine the disclosure and use of their personal data 10 . The legal basis for this is the Federal Data Protection Act.  The German Federal data protection act (Bundesdatenschutzgesetz - BDSG), together with the data protection laws of the federal states and other sector-specific 7 https: / / www.bmas.de/ DE/ Arbeit/ Arbeitsschutz/ Gesundheit-am-Arbeitsplatz/ Betrieblicher-Infektionsschutz/ betrieblicherinfektionsschutz.html#linkicon, accessed on 9 August 2023 8 The official translation of the 'Arbeitschutzgesetz' is: 'Act on the Implementation of Measures of Occupational Safety and Health to Encourage Improvements in the Safety and Health Protection of Workers at Work’. 9 Other health and safety regulations in addition to the Occupational Safety Act include: • Construction Site Ordinance = Baustellenverordnung (BaustellV) • Industrial Safety Regulation = Betriebssicherheitsverordnung (BetrSichV) • Hazardous Substances Ordinance = Gefahrstoffverordnung (GefStoffV) • Ordinance on Occupational Health Prevention = Verordnung zur arbeitsmedizinischen Vorsorge (ArbMedVV) 10 With reference to a judgment of the Federal Constitutional Court of 15 December 1983. This judgment, popularly known as the ‘Population Census Judgment’ (Volkszählungsurteil), is considered a milestone in data protection. (BVerfGE 65, 1) <?page no="52"?> 52 | Page regulations, governs the handling of personal data that is processed in information and communication systems or manually, as well as the rights of the data subjects. The revised version of the BDSG from 2018 continues to apply in conjunction with the General Data Protection Regulation (GDPR11).  According to the General data protection regulation (GDPR), which has been in force since 25 May 2018, personal data is defined in Article 4 as ‘...any information relating to an identified or identifiable natural person...’ It also states that ‘an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person...’. Data security  In the context of company data processing, data security refers to all technical and organisational measures for protecting data from being tampered with, destroyed or unlawfully passed on. Environment - refers to the protection of the environment and the minimisation of negative effects of operating activities on air, water, soil and natural resources  Federal emission control act (BImSchG) - aims to protect humans, animals and plants, the soil, water, the atmosphere, as well as cultural and other material goods from harmful environmental impacts.  Environmental liability act (UmweltHG) - is a means of environmental precaution. It regulates liability for damage caused by an environmental impact, e.g. by substances, gases, vapours, etc. that have spread into the soil, air, water or other carriers. Outside the HSSE acronym, but definitely worth checking for relevance, are the regulations on co-determination or participation:  Works constitution act (BetrVG) - is the fundamental order of cooperation between the employer and the employee representatives elected by the employees. It provides the legal basis for the work of the works council. Its scope extends only to private sector companies.  Staff representation acts (PersVG) - for employees of institutions of the federal states, municipalities and municipal associations, as well as for other public corporations, institutions and foundations under the respective state. The BPersVG applies to employees of federal administration institutions and those working for social insurance companies operating nationwide.  Regulated public participation - e.g. the Federal Building Code (Baugesetzbuch - BauGB), the Environmental Impact Assessment Act (Umweltverträglichkeitsprüfung - UVPG)  The ninth book of the social code (SGB IX) - is intended to promote the self-determination and equal participation in society of people with disabilities and people at risk of disability in Germany, and to prevent and counteract discrimination. 11 German: Datenschutzgrundverordnung (DSGVO) <?page no="53"?> Page | 53 3.2.1.2 Hazard analysis 4.3.3 Compliance, standards and regulations / Competence level 1 Further input for the environmental analysis can be collected as part of a hazard analysis 12 . Hazard analysis is the systematic identification and evaluation of relevant hazards to employees with the aim of defining the necessary occupational health and safety measures [GNAK17]. The ‘Act on the Implementation of Occupational Safety and Health Measures to Improve the Safety and Health of Employees at Work’, or Occupational Safety and Health Act (ArbSchG) for short, stipulates in § 5 ‘Assessment of Working Conditions’ that the employer must carry out a risk assessment. In addition to physical hazards, it explicitly includes mental hazards (Section 5 (3) ArbSchG) 13 . Support for determining mental workload is provided by the standard DIN EN ISO 10075-1: 2018-01 ‘Ergonomic principles related to mental workload ‒ Part 1: General aspects and concepts and terminology’. An assessment is carried out in five steps based on the specifications of the BAuA (Federal Institute for Occupational Safety and Health) 1. Identify hazards 2. Assess hazards 3. Define (occupational safety and health) measures 4. Implement and document measures 5. Check the effectiveness of measures 3.2.1.3 Environmental factors - culture and values 4.3.5 Culture and values (Level C) The ICB element C ULTURE AND VALUES is considered part of the environment analysis because, in the author's view, corporate culture and values represent an environmental factor that should not be underestimated for a project (PESTEL  Social - the sociocultural environment). This topic is also addressed in the ICB elements L EADERSHIP , T EAMWORK , C HANGE AND TRANSFORMATION , among others. Culture and values (4.3.5) ‘The competence C ULTURE AND VALUES defines the approach of the individual to understand and influence the culture and values of the organisation and the rest of society in which the project is based.’ [GPM17a, page 61] Model of corporate culture It is important for cooperation to be aware of cultural differences in order to avoid misunderstandings. In his three-level model of corporate culture, E DGAR H. S CHEIN defines artefacts, values and norms, and basic assumptions that arise from the personal learning history of a team or organisation [SCHE18]. 12 The term ‘risk analysis’ is also used synonymously. 13 According to the AOK Absenteeism Report 2022, the frequency of absenteeism due to mental illness rose by 53.2% between 2012 and 2021. With an average of 29.7 sick days, they lasted more than twice as long in 2021 as an average sick leave. <?page no="54"?> 54 | Page Figure 12 - Model of corporate culture according to E. Schein Visible patterns of action and symbols lie on the surface, known as artefacts. These artefacts or symbol systems are easy to grasp on the surface, but the meaning behind them is difficult to access. Elements of a symbol system can be [BEA17, SZTUb, SCHE18]  Rites and rituals (e.g. celebrations, anniversaries, promotions)  Myths and stories (e.g. founders, past successes)  Corporate identity (e.g. fleet, printed matter, logo, clothing)  Perceived atmosphere and services (language, punctuality, visitor reception) Values and norms form the middle level. They determine what is considered right and wrong by the members of the company. Examples of this are  leadership principles  behavioural guidelines  standards  documented corporate goals / strategy  formal and informal rules Originally, these are solutions that individuals have found for problems. If such reaction patterns prove successful in many cases, they gradually become common knowledge and thus the values of the company. The basic assumptions, which are the deepest level of corporate culture, include convictions that are taken for granted and no longer questioned. These assumptions about relationships with the environment, about human nature and in the social sphere are considered to be without alternative and are no longer consciously reflected upon. However, without knowledge of these assumptions, understanding of the levels above them is only partially possible [SZTUb, SCHE18]. <?page no="55"?> Page | 55 Example of basic assumptions - The five monkeys experiment 1. Five monkeys are sitting in a cage. Bananas are hanging above them. There is a ladder to get to the bananas. 2. Every time the monkeys try to get to the bananas, cold water is sprayed into the cage. The monkeys quickly learn that they can forget about the bananas. 3. The cage culture contains a very clear guideline: hands off the bananas! 4. New setting: no more water is sprayed into the cage, and one monkey is replaced by a new one. The new monkey comes up with the idea of using the ladder to get to the bananas. But the others stop him to avoid the cold shower. 5. One by one, the monkeys are replaced until there are no more of the original monkeys in the cage. The game remains unchanged. Again and again, the new monkey is prevented from using the ladder and then immediately adopts the behaviour of its fellow inhabitants. 6. In the end, all five monkeys obey the same rules, although none of them knows why.  Their behaviour is based on a basic assumption that has been shaped by society and is no longer questioned. Fact or fiction? For the moral of the story, it is irrelevant whether the monkeys really performed their cage drama… 14 Differentiation Culture and Values Corporate culture - The organisational culture forms the totality of collective values, norms and attitudes within an organisation. These shape the decisions, actions and behaviour of the organisation's members. It can be regarded as an unwritten code of rules. The organisational culture acts as a guiding principle that influences communication, interaction with each other and with external partners, and the external image of the organisation [BEA19b]. Corporate values - Corporate values represent the overarching individual value system of an organisation. These values form the fundamental principles and convictions that define and guide the behaviour and decision-making processes of a company. These values influence the way employees, managers and the company act as a whole. 3.2.1.4 Environmental factor - sustainability 4.3.3 Compliance, standards and regulations | 4.4.2 Personal integrity and reliability / Competence level 1 The term ‘sustainable development’ has deep historical roots. It was used as early as the 18 th century in relation to forestry, emphasising the importance of using resources in a way that preserves them for future generations. 14 See https: / / www.mimikama.at/ allgemein/ das-affen-experiment-ein-echtes-experiment/ (translated) <?page no="56"?> 56 | Page Triple-Bottom-Line In the 1990s, J OHN E LKINGTON coined the term ‘triple bottom line’. He suggested that companies should define their success not only in terms of profit, but also in terms of their social and environmental contributions. His theory is based on the three pillars of sustainability:  Profit (profit),  People (social responsibility) and  Planet (environmental sustainability). Because these three aspects interact with each other, a balanced approach should always be taken. „Sustainable development is development that meets the needs of the present without compromising the ability of future generations to meet their own needs.“ Gro Harlem Brundtland (*1939, former Norwegian Prime Minister) UN Global Compact In the context of the UN Global Compact, E LKINGTON 's three Ps (Planet, People, Profit) were expanded or adapted to five. They now include  People (social responsibility),  Planet (environmental compatibility),  Prosperity (prosperity),  Peace (peaceful and just society) and  Partnership (cooperation). The UN Global Compact is a voluntary initiative of the United Nations that was launched in 2000. It aims to encourage companies and organisations to adopt sustainable and socially responsible business practices. To this end, 10 principles 15 have been developed that support the pursuit of sustainable and ethical growth. ISO 26000 Almost parallel to the UN Global Compact, work began in 2005 on an ISO standard for corporate social responsibility (CSR). The aim was to provide all types of organisations with guidance on the topic of ‘social responsibility’. The result was the ISO 26000 standard, the ‘Guidance Standard on Social Responsibility’, which was published in 2010. As a result, the standard can be used both as an introduction to the topic and to improve and integrate existing procedures. The standard was deliberately designed as a guideline and does not contain any requirements. Sustainable development In 2012, the UN member states decided to substantiate the 10 principles of the UN Global Compact. Three years later, the 17 Sustainable Development Goals (SDGs ‒ Sustainable Development Goals) and 169 explanatory sub-targets were adopted. In Germany, the term Agenda 2030 is used for this. It is universally valid and forms the framework for environmental and development policy until 2030. 15 https: / / www.globalcompact.de/ ueber-uns/ united-nations-global-compact, accessed on 11 August 2023 <?page no="57"?> Page | 57 Figure 13 - Agenda 2030: the 17 global sustainability goals In principle, all SDGs are relevant for companies. However, the 2030 Agenda in its current form is more of a voluntary commitment. In the meantime, the framework conditions have been set by the German government with the Supply Chain Due Diligen-ce Act (SDG 8 ‒ Decent Work and Economic Growth) and on the reporting obligation (CSR Directive Implementation Act). German Sustainability Code To support the reporting obligation, the German Sustainability Code (DNK) provides a framework for reporting on non-financial performance. This can be used by organisations and companies of any size and legal form. 3.2.1.5 SWOT analysis 4.4.1 Self-reflection and self-management / Competence level 1 The analysis of the objective environmental factors (PESTEL and, in more detail, legal framework, culture and values, and risk analysis) described in the previous chapters can be combined with the possibilities of the project using a SWOT analysis (in addition to or as a replacement for it). Factual environment factors Impact on the project Explanation Interaction with other factual environmental factors Risk Chance Neutral Location of the association's site (in a conservation area) (FF1) X The site is located in a landscape conservation area.  Restrictions imposed by the UNB and the building authority BayNatSchG (FF8), BNatSchG (FF9) <?page no="58"?> 58 | Page Opportunities for selfcontributions (FF2) X Members can actively participate in the redesign  member involvement and binding Charter (FF3), BayBO (FF4) Articles of association of the association Summit Seakers (FF3) X The statutes permit voluntary work. Self-contributions of members (FF2) Bavarian Building Code (BayBO) (FF4) X DIN EN 12572 (FF5) X Standard for artificial climbing structures DGUV Information 202-018 (FF6) X Recommendations for the safe construction and operation of artificial climbing walls Product Safety Act (ProdSG) (FF7) X Law on the provision of products on the market Bavarian Nature Conservation Act (BayNatSchG) (FF8) X Guidelines for construction projects in landscape and nature reserves Site location (FF1) Federal Nature Conservation Act (BNatSchG) (FF9) X Site location (FF1) … The PESTEL analysis looks at the ‘big picture’, i.e. the environmental factors that could have an influence on the project. The SWOT analysis examines the opportunities / possibilities (opportunities) and risks / threats (threats) identified within the environmental factors and compares these with the strengths (strengths) and weaknesses (weaknesses) of the project, revealing possible gaps. It is helpful to be aware of the project-related success factors (see also the chapter 2.1.3 ‘Selecting projects - success factors’), the project's objectives and the project requirements when considering strengths and weaknesses [ASSE14, MART16]. <?page no="59"?> Page | 59 Environment factors Opportunities Threats Example questions • What possibilities are there? • What future opportunities are foreseeable? • What changes in the environment could be advantageous? Example questions • What are the risks arising from the identified objective environmental factors? • Which environmental factors could have an unfavourable impact on the project implementation? Project Strengths Weaknesses Example questions • What went well in our projects in the past? • Which factors were crucial for a successful project closure? • What can we be proud of in / with our project culture? Example questions • Where do we regularly experience difficulties in the implementation of the project? • What did we regularly find difficult in the project? • What is missing compared to projects of our competitors? • What has demotivated us in the past? Table 10 - SWOT matrix - outer and inner view of the project The combined SWOT matrix reveals relationships between strengths and weaknesses on the one hand and opportunities and risks on the other. From this, general approaches can be derived for the project and presented in the four fields of the matrix [FLEI22]. Environment factors Project Threats Opportunities Strengths Secure • Which strengths can avert the occurrence of which risks? • Which success factors can we build on? Expand • Which strengths match an environmental factor that we consider an opportunity? • Which opportunities for improvement do we see? Weaknesses Avoid • Which of our weaknesses is exposed to an environmental factor that we consider a risk? • What danger does this pose to the project? Catch up • How can we turn a weakness into an opportunity? • Which of our weaknesses can we reduce? Table 11 - Combined SWOT matrix A SWOT analysis is no substitute for a thorough risk analysis for the project. It is a way of dealing more intensively with one's own strengths / the strengths of the project in <?page no="60"?> 60 | Page connection with the environmental factors. The detailed analysis and the definition and implementation of appropriate measures for risks and opportunities are applied in the risk management process (see chapter 4.6). 3.2.2 Stakeholder management 4.5.12 Stakeholders / Competence level 2 | 4.3.4 Power and interests / Competence level 1 According to the ICB 4.0, stakeholders are ‘all individuals, groups or organisations that are involved in the project, influence it, are influenced by it or are interested in the implementation or the result of the project.’ [GPM17a, page 155] The interest does not necessarily have to be positive; stakeholders can also have a harmful influence on the achievement of the project goals. Stakeholders can be categorised as primary or secondary. Primary stakeholders have a direct effect, while secondary stakeholders have an indirect effect through their relationships and influence. Within this classification, Witte's promoter model can be used to distinguish between project proponents (promoters) and project opponents (opponents) [WITT73]. W ITTE defines promoters as roles that actively promote and influence processes. His model recognizes power promoters and technical promoters. This was later expanded to include relationship or social promoters and opponents. 16 Power promoter Supports or influences due to their position in the company hierarchy Due to this hierarchically legitimised power, he or she is able to influence opponents Main task for the project: Persuasion and enthusiasm in the project's interest Expert promoter Supports and influences by their specific technical and methodological knowledge They are often found in line positions with an affinity for technical innovations Main task for the project: to advance the project work by passing on knowledge and developing solutions to problems raised by opponents Relationship or social promoter Has a strong network of personal contacts across all hierarchical levels of the organisation (and outside) Is recognized and respected Main task for the project: to build new networks and thereby indirectly support the project Opponent People who want to delay or prevent a project. Table 12 - Promoters and opponents Promoters and opponents derive their authority from different sources of power or abilities [WUND11]. In sociology, there are a wide range of definitions of the concept of power. M AX W EBER (1922), for example, describes power as ‘... every opportunity to 16 M OTZEL also includes the business promoter (with financial resources) [MOTZ17]. <?page no="61"?> Page | 61 assert one's own will within a social relationship, even against resistance.’ H EINRICH P OPITZ (1986) defines power ‘... as the ability to assert oneself as a person against other forces.’ Both definitions emphasise the idea of asserting oneself against others. This ‘asserting oneself’ can, on the one hand, be based on the position of the individual within a hierarchy, i.e. through organisational authority to issue instructions, or it can be negotiated between individual actors. Based on the typology of F RENCH / R AVEN (1968), five or six bases of power can be distinguished [OLFE19]:  Expert power - expertise with regard to certain tasks and/ or problems. Basis of power for expert promoters, opponents  Information power - access to and control of information, situation-related specific knowledge. Basis of power for expert promoters, opponents  Referend power - role model / identification function. Basis of power for relationship or social promoters, opponents  Legitimate power - established and accepted powers, hierarchical order within the company. Basis of power for power promoters, opponents  Reward power and coercive power - the power to impose sanctions in both a positive (reward) and negative (punishment) sense. Basis of power for power promoters. Differentiation Power vs. Authority Power is a basic political and sociological concept that is used for relationships of dependency or superiority. The person in power has the ability to achieve their own goals by using means of power (e.g. reward, punishment) without the consent of the person being controlled, against their will or despite resistance. Power can be based on different power bases (see above), and its exercise involves effort (e.g. ongoing control) [WUND11].  unstable leadership Authority is the ability of a person, group or institution to exert influence over others and, if necessary, to enforce their own will on them. This creates a relationship of superiority and subordination. Types of authority − personal authority: The claim to authority is based on personal characteristics (e.g. physical strength, performance, age, knowledge, experience). − functional authority (professional authority): is based on superior and demonstrable expertise or knowledge. − positional authority: is derived from the position, office or rank and exists independently of the person holding the position [GABL18].  stable leadership <?page no="62"?> 62 | Page Process Figure 14 - Stakeholder management process I DENTIFY the stakeholders A first step towards identifying the stakeholders has already been taken with the environmental analysis (social environmental factors). Now it is important to verify these again and to supplement or update the list of stakeholders with the help of one or other creativity technique. Sorting them into promoters, opponents and undecided parties can be helpful here. It can also be helpful to consider who will have requirements of the project and/ or provide input (upstream) and who will deal with the results of the project after its completion (downstream). A NALYSE and A SSESS the stakeholders All project stakeholders must be analysed and evaluated. This includes questions about their expectations / concerns, influence and potential for conflict. Of course, the analysis can also be extended to other areas. Examples include ‘attitude towards the project’, ‘degree of involvement’ and ‘support potential’. Key questions for identifying expectations / concerns and evaluating influence and potential for conflict can be as follows: Expectations / Concerns  What are the person's / group's motives for supporting / not supporting the project?  What are their expectations of the project / project outcome?  What are their concerns regarding the course of the project and the project outcome?  What personal goals does the person / group have in relation to the project? Influence (power)  Is the stakeholder a power promoter (position in the hierarchy)?  Can they support / advance / scupper the project?  Can they influence the opinions of others? <?page no="63"?> Page | 63 Conflict potential  Is the stakeholder an opponent of the project?  Do the personal goals of the stakeholder deviate from the project goals? How much do they deviate?  Is the stakeholder strongly affected by the project result from their point of view? Rather positively or rather negatively? It is recommended that no figures be used to assess influence and potential for conflict, as this is a subjective assessment by the project manager or project team based on their experience. A proven way to categorise this assessment is into high and low. The stakeholder analysis is presented in a table. No. Name and Function Interests / Expectations / Concerns Influence Conflict potential SF1 Chairman S UM- MIT S EAKERS Project client I: success ful project, active support E: regular information, wants to be involved high low SF2 Members of S UMMIT S EAKERS I: want to be asked and informed E: The opportunity for active participa-tion, a high-quality end product high low SF3 Jenny Leftfoot, office E: Information on the project and its progress low low SF5 D. Molition, Office for Building Law … E: all the documents required for the approval procedure high high SF6 W. Birdspotter, Lower Nature Conservation Authority I: Support associations E: No conspicuous installations in the landscape protection area high high SF9 K. Hightop, specialist tower construction E: good management of the construction site environment low low SF n … … … … Table 13 - Sample project: stakeholder table (excerpt) Once the stakeholders have been evaluated, they can be visualised in a simple portfolio with four quadrants. The advantage of this representation is that it immediately shows which stakeholders the project manager should focus on (usually in the upper right quadrant, high influence and high conflict potential). <?page no="64"?> 64 | Page Figure 15 - Sample project: Stakeholder portfolio (excerpt) M ANAGE (plan and implement measures) The stakeholder management measures that need to be planned make use of the instruments of project marketing and project communication. While project communi-cation is aimed more at internal stakeholders, project marketing is concerned primarily with external stakeholders and aims to increase awareness of the project and improve its image within the company and in the public eye [PATZ17]. Depending on the assessment of the stakeholder groups, a suitable communication strategy should be chosen to address and inform the individual stakeholders and to foster a positive attitude towards the project. It makes sense to maintain individual communication with important stakeholders, while other stakeholders can be informed with less effort. The measures are planned for each quadrant of the stakeholder portfolio. It should be noted that the stakeholders in the quadrant of high influence / high conflict potential require the most attention and thus the most time of the project manager, since these must be individually managed for the desired success 1: 1 (project manager directly with the stakeholder). The effort for the support of the stakeholders in the quadrants low influence/ high conflict potential and high influence/ low conflict potential is substantially lower, since they are either positively disposed towards the project anyway or have little influence and thus do not pose a major threat to the project. Here, one-to-many support (e.g. via meetings) is sufficient. The stakeholders listed in the quadrant low influence / low conflict potential are usually served via impersonal media (m: n), e.g. via newsletters or information events. Accordingly, one of the following strategies should be chosen [RÖSS08] [GPM17a].  participative - stakeholders as partners The participative strategy aims to involve the stakeholders in the project in a spirit of partnership to varying degrees. Involvement ranges from providing information, communicating and discussing objectives, tasks and the project status, to active partici- <?page no="65"?> Page | 65 pation and the transfer of responsibility by involving stakeholders in the decisionmaking process. True to the motto ‘turning those affected into participants’:  discursive - (from the Latin discursivus, ‘progressively discussed’) the objective discussion with stakeholders (can also mean conflict management)  restrictive - the provision of information is deliberately reduced. The resulting measures may differ depending on the stakeholder. The restrictive strategy adheres to the motto ‘as much as necessary, as little as possible’.  repressive - in contrast to the first three strategies, the approach here is to influence and control stakeholders through other actors, e.g. power promoters. This can be done, for example, through direct instructions and guidelines from the management.  informative - regular information via newsletters, e-mails, information events. The measures derived from the respective strategies are then reflected in a communication plan. This plan can be built on the basis of H AROLD D. L ASSWELL 's communication formula: „Who says what in which channel to whom with what effect? “ Harold Dwight Lasswell (1902-1978), political scientist and communication theorist On the basis of the stakeholder analysis, it is possible to determine who is to be provided with information, what they are to be provided with, when, how and by whom, in order to ensure smooth and seamless communication with the stakeholders. The stakeholders can also be grouped here according to the chosen strategies. The project manager should not forget himself in all this planning: those who are to provide information must first receive it … No. Who What When How by Whom SF1 Chairman, project client General information about the project at all milestones Meeting, F2F conversation, status reports Project manager SF2 Association members Update on project progress; requests for support, if necessary monthly Newsletter Project team SF3 J. Leftfoot, office Update information monthly F2F conversation Project manager SF5 D. Molition, Office for Building Law Application documents, construction plan enquiries interim result one-time monthly per email, personal handover, via phone Project manager and chairman board SF6 W. Birdspotter, Lower Nature Conservation Authority Application documents, construction plan enquiries interim result one-time monthly per email, personal handover, via phone Project manager and chairman board <?page no="66"?> 66 | Page SF9 K. Hightop, specialist tower construction Necessary information on infrastructure upon acceptance of the offer per email Project manager SFx Project manager Construction progress Problems encountered weekly, adhoc if required per email, via phone K. Hightop, specialist tower construction … … … … … … Table 14 - Sample project: Communication table (excerpt) All these measures serve to involve the stakeholders in the course of the project, even to integrate them in order to obtain important information and suggestions. The ICB 4.0 uses the term commitment strategy [GPM17a] for this, while others speak of stakeholder engagement [APM17b] or stakeholder stewardship [GRIF15]. Behind each term is active engagement, not passive waiting, to keep stakeholders informed about the project in a timely, regular, honest and proactive manner. Figure 16 - Sample project: Stakeholder portfolio after measures (excerpt) M ONITOR AND C ONTROL the process Both the effectiveness of the measures taken, and the situation of the stakeholders must be regularly monitored and analysed. Only then can it be determined whether the expectations / fears and/ or the power situation of the stakeholders has changed and whether new stakeholders have entered the project arena. This and the usual dynamics of the project environment make it necessary to go through the entire process regularly, at least at the end of each phase. The change of stakeholders can also be displayed in a portfolio [GPM17b]. Despite all the planning and foresight, ‘secret technique’ ‒ common sense ‒ should always be the guiding principle in stakeholder management. <?page no="67"?> Page | 67 3.3 Requirements and objectives Requirements and objectives (4.5.2) ‘The competence R EQUIREMENTS AND OBJECTIVES defines the “why” for the project - which goals must be achieved, which benefits must be realised and which stakeholder requirements must be met.’ [GPM17a, page 111] 3.3.1 Requirements 4.5.1 Project design / Competence level 1 | 4.5.2 Requirements and objectives / Competence level 1 “Would you be so kind as to tell me which way I should go here? ” asks Alice. “That depends to a large extent on where you want to go,” said the cat. “It doesn't matter to me where -” said Alice. “Then it doesn't matter which way you take,” said the cat. “- If I just get somewhere,” Alice added by way of explanation [CARR69]. This excerpt from Alice's conversation with the Cheshire Cat in the book ‘Alice in Wonderland’ makes the dilemma in many a project clear. We don't know exactly where the journey should go, but we then do it highly efficiently and are surprised when in the end the costs are exceeded and the service is not accepted by our client. The reasons for these irritations are complex [EBER22, HRUS23]:  unclear, open to interpretation requirements  wrong requirements  implicit requirements  missing requirements  changing requirements Without clear and approved requirements, it is difficult to define the performance targets of the project and their measurement criteria. Requirements management, or better, requirements engineering, lays the foundation for this. According to ISO 10006 (Quality Management Systems - Guidelines for QM in projects), ‘the fulfilment of the requirements of the customers and other interested parties is necessary for the project to be a success.’ [DIN20c] What are requirements? The IEEE (Institute of Electrical and Electronic Engineers) defines a requirement in the ISO/ IEEE 29148 standard as ‘a statement which translates or expresses a need and its associated constraints and conditions.’ [IEEE11] In our project, we ideally receive the ‘need’ in the form of a user requirements specification (Ger.: Lastenheft). The user requirements specification is the ‘set of requirements for the deliveries and services of a contractor within a (project) order, as specified by the client.’ [DIN20a] However, this does not always mean that this document actually contains all the requirements. The project manager and the project team must check the specifications against the objective environmental factors for further, previously undocumented requirements. The specifications must also be checked for unclear or interpretable requirements. An important source of requirements are also the social environmental factors, i.e. the stakeholders of the project. These represent the ‘voice of the customer’ (VoC). The VoC reflects needs, desires, demands and expectations regarding the services to be provided or the product to be created in the project [SCHM15]. <?page no="68"?> 68 | Page Requirements are thus the link between the client (‘wants something’) and the contractor (‘can deliver it’). A distinction is made between functional and non-functional requirements. Figure 17 - Functional and non-functional requirements The requirements must be documented and described accordingly. The following rules can be used for this purpose [HRUS23]:  short, simple sentences  one requirement per sentence  describe needs, not solutions  abbreviations only if absolutely necessary  no generalities (some, many, all, …)  formulate liabilities clearly (what must be done, what can be done? )  formulate actively (who does what? )  verifiable fulfilment (measurability, acceptance criteria)  set priorities One thing should always be kept in mind here: never make your own assumption in the sense of ‘the person I'm interviewing must have meant it that way’ when something is unclear. Or, to quote E RIC B OGOSIAN in the film Under Siege 2: Dark Territory (1995): ‘Assumptions are the mother of all fuck ups! ’ 17 The specified requirements are usually summarised in a functional or technical specification (Ger.: Pflichtenheft). The functional specification represents the ‘realisation plan developed by the contractor based on the customer's requirements specification’ [DIN 20a]. It supplements the requirements specification with initial solution ideas, information on the expected costs and initial time estimates. The functional specification document, 17 … or in other words: to assume makes an ass out of you and me <?page no="69"?> Page | 69 often also referred to as a technical concept or system description, thus represents the contractor's view and is the basis for further steps in the project [VDI01]. 3.3.2 Objectives 4.5.2 Requirements and objectives / Competence level 2 Projects pursue at least one goal and deliver relevant results for the company. They are thus at the centre of the conflict between the corporate goals to be achieved, the success factors of the company and the required or demanded quality that is to be provided by them. The corporate goals are derived from the company's business strategy. The operational goals are then defined based on these. As already mentioned, projects provide useful results for the company. Project goals therefore result from the strategic (strategic projects) or operational goals of the company. 3.3.2.1 Objective definition, target values Objectives are one of the characteristics of a project. The project objective and objective definition are described as follows in DIN 69901-5: 2009 and ICB 4.0: ‘Project objective - the totality of individual objectives to be achieved by the project‘ [DIN20a, page 160] ‘Objective definition - quantitative and qualitative definition of a project content and the realisation conditions to be adhered to, e.g. costs, duration, in the objective characteristics with mostly different objective weights (e.g. must-have and nice-to-have objectives)’ [DIN20a, page 163] ‘The competence requirements and objectives define the ‘why’ for the project - which objectives must be achieved, which benefits must be realised and which stakeholder requirements must be met.’ [GPM17a, page 111] The project objectives of performance (scope), costs, and deadlines (time) represent a condensed, clear overview of the totality of the project objectives. They are often illustrated in the form of a triangle, the so-called ‘magic triangle’ of project management. 18 Figure 18 - The ‘magic triangle’ „Fast - Cheap - Good: You can have any two.“ Project management proverb, unknown author 18 Note: the terms ‘triple constraint’, ‘iron triangle’ or ‘project triangle’ are often used in the English-speaking world. <?page no="70"?> 70 | Page 3.3.2.2 Objective functions, objective types In addition to their control function (keyword: measurement criterion), project objectives have other important functions: Function Explanation Control Benchmark for the overall success of the project Orientation Directional information - ‘Where is the journey headed? ’ Coordination Consistent alignment with the objectives facilitates the project team's relationships with other organisational units. Selection Coherent goals make it easier to select and decide on alternatives. Connection Well-formulated goals bring the project members together - a sense of unity Table 15 - Functions of objectives Objectives are categorised into classes. In the ‘magic triangle’, three classes can already be identified: time targets, scope-related targets and cost targets. Another way of differentiating is to consider result targets and procedural targets (also process targets). The result targets include project targets that relate to the project object, such as financial targets, performance targets, social targets and ecological targets. In contrast, procedural targets describe the way to achieve the project result. This includes all requirements and constraints that need to be met during the course of the project, such as schedule and budget targets. The benefit objectives or usage objectives occupy a special position. They represent the later use of the project result, although they are not yet available when the project is completed. The project manager is therefore not directly responsible for their achievement. Nevertheless, they must not be lost sight of during the project, as they represent potential starting points for opportunities in the project [MOTZ17]. Despite a comprehensive formulation of objectives, it may happen that the client demands a service or deliverable during the project implementation that is not considered part of the project by the project team. To prevent this from happening, it is helpful to clearly define out-of-scope non-objectves. They express which aspects are explicitly not addressed by the project. Defining what is out-of-scope is also an important component of the project managers and client clarifying the assignment [PATZ17]. Once the goals and non-goals have been defined, they still need to be categorised. The classification is usually done into must-have goals (not achieving them means the project will fail), should-have goals (not achieving them prevents overall satisfaction of the stakeholders with the project) and can-have goals (rather secondary, only to be pursued if the effort is reasonable). Non-goals are not categorised. Within the categories, a prioritisation can be done additionally, depending on the respective goal relationships. <?page no="71"?> Page | 71 Class Objective description Measurement criteria Category Main goal The new climbing tower on the site of S UMMIT S EAKERS is built and usable by 24/ 03/ 2024 with a budget of 400,000 €. Scope The old climbing tower has been dismantled and the area is ready for the new construction. (S1). Surface free and usable for new construction (visual inspection) M Planned climbing height and area has been reached (S2). Climbing height ≥ 16 m, climbing area ≥ 500 m 2 (measured) M The required number of routes with the corresponding level of difficulty according to UIAA are mounted. (S3). ≥ 25 routes / the geometry allows climbing up to UIAA grade 10 S Acceptance and approval for use by TÜV has been granted (S4). Acceptance report M S n … …. Time Positive decision by the board to implement the project is available 30 Oct 2021 (T1). Board resolution as of 30 October 2021 (minutes) M Adoption / approval of the project by the general meeting on 17 Sep 2022 (T2). Voting result on 17 Sep 2020 (minutes) M TÜV inspection will take place on 01/ 03/ 2024 (T3). Acceptance on 01/ 03/ 2022 (acceptance report) M T n … … Costs The budget of € 360,000 for the new tower has been met (C1). Cost suppliers ≤ 360.000 € M The budget of € 40,000 for the planned self-contribution has been met (C2). Cost self-contribution ≤ 40.000 € S C n … … Social The association's climbing trainers have been instructed on the new tower (So1) > 10 trainers are present  attendance list S So n … … Non-goals Recruit new members (N1) N n Category: M = Must-goal, S = Should-goal, C = Can-goal Table 16 - Sample project: Objectives table <?page no="72"?> 72 | Page The graphical representation of the goal hierarchy (main goal, overarching goal, subgoal) is displayed in the form of a goal tree, depending on the selected goal type. Figure 19 - Sample project: Goal hierarchy based on scope, time, cost <?page no="73"?> Page | 73 Figure 20 - Sample project: Goal hierarchy based on result-oriented and process-oriented goals 3.3.2.3 Objective formulation, objective relationships When formulating objectives, the following rules should be observed: 1. They should be entirely formulated, i.e. all the essential project objectives, including the non-objectives, should be formulated. 2. They should be quantified, i.e. with criteria that can be used to check / measure whether the objective has been achieved. They should be unambiguous, i.e. clearly formulated so that no alternatives are permitted. Words such as ‘as far as possible’, ‘could’, ‘should’, ‘faster / less than’ are to be avoided 3. positive, i.e. the path to something is described. Words such as ‘without’, ‘not’, ‘none’ are to be avoided. For non-targets, it is therefore sufficient to mention the service to be excluded, i.e. ‘user training’ instead of ‘user training is not part of...’ 4. solution-neutral, i.e. the goal is defined from the use of the project result, not from a technical point of view. So no predefining or excluding of possible solutions. 5. in result-oriented language, i.e. concise and in the present perfect (e.g. … is achieved, … is ready for occupancy, … is ready for operation, … is in use, … is met, … is opened). „The slowest person who does not lose sight of his goal still walks faster than the one who wanders around without a goal.“ Gotthold Ephraim Lessing (1729 -1781), German poet <?page no="74"?> 74 | Page The acronym SMART is a good way to check the objective definition: S PECIFIC Simple and understandable, not general but specific. M EASURABLE Operationalised (including output and costs), i.e. what clear indicators are there to show that the objective has been achieved? A CCEPTED Goal achievement can be influenced and is socially accepted (  ethics). R EALISTIC Factually achievable and significant, i.e. neither a state that occurs on its own nor an unattainable vision in the given time. T IME - BOUND Creates a liability for a defined point in time. Table 17 - SMART If several objectives are identified for a project, the relationships between the objectives must be analysed. In doing so, a distinction is made between different objective compatibilities or objective relationships. The scale ranges from objective identity to objective neutrality to objective antinomy. Figure 21 - Objectives‘ relationships The relationship between the objectives is described in detail in the following table. Relationship Definition and action Identity When objectives are completely congruent, we speak of objective identity. One of the identical objectives is to be deleted. Complementarity (Support) Goal complementarity occurs when the pursuit of one goal simultaneously supports the achievement of another goal (‘the more one, the more the other’). Neutrality If different goals can be achieved completely independently of each other, this is referred to as goal-neutrality. Competition Goal competition refers to the interference with one goal when another goal is achieved. Prioritisation is necessary here (‘the more of one, the less of the other’). Antinomy If objectives are completely mutually exclusive, this is called an objective contradiction. In this case, the client has to make a decision. Table 18 - Definition of objectives‘ relationships <?page no="75"?> Page | 75 On the basis of a compatibility matrix, the developed objectives can be checked for their mutual effect (pairwise comparison). Figure 22 - Objectives‘ compatibility matrix Note: The most common competitive relationships are between the individual target objects of time, costs and performance. For example, between time vs. budget or costs, time vs. scope and/ or budget or costs vs. scope. 3.4 Project phases 4.5.1 Project design / Competence level 1 | 4.5.4 Time / Competence level 2 Depending on the chosen project design or the company's specifications based on a process model, the project is divided into individual sections, the project phases. The topic of project phases is part of the ICB element Time and is described in more detail in chapter 4.2. Project phases are the first planning step in dividing up the overall project. They divide a project into chronological sections that are distinct from one another in terms of content. These phases have a clear objective, use resources to create important deliverables and also contain decisions as a basis for the following project phase. The sequence of phases in a project together is also referred to as the project life cycle [DIN20a]. In contrast to the project phases, which reflect the content-related activities of the project, the phase classification for project management is based on the logically related activities of project management - initialisation, definition, planning, control, completion - the project management phases [DIN20a]. The creation of the phase plan provides an initial rough planning and thus a feasibility check for the project objectives specified by the client. At this point, a go/ no-go decision for the project can be made. Elements of the phase plan: The phase plan contains main activities that are summarised in the individual phases. The project phases usually begin with a milestone and end with a decision point or an event of particular significance [DIN20a]. These events can be:  inspections or acceptances  ‘milestones’  decisions, e.g. on the start of the next phase <?page no="76"?> 76 | Page Milestones have a duration of zero and are usually displayed with a diamond in the phase plan. For better understanding and readability, the milestones are listed in a table together with a description of the associated event. In order to check whether the client's objectives (deadlines and costs) are feasible, the expected durations and costs of the main activities are estimated roughly and aggregated into project totals. This is done, sensibly, on the basis of empirical values from similar completed projects or expert estimates. In all estimates, the project manager must clearly point out their preliminary nature to the client in the subsequent communication in order to avoid undesirable and factually incorrect final mental fixations. Project management is not included in the phase plan as a separate phase, since the PM activities are cross-sectional functions that accompany the phases and extend across all project phases. In terms of budget, it is taken into account in this planning stage with 10 to 15% of the estimated costs (unless higher or lower assumptions are justified by logical reasons). 1. List of project phases with objectives and main activities Project phase Phase goal Main activities Duration (weeks) Estimated cost (€) Pre-planning and examination phase (P1) Board resolution & positive resolution of the AGM have been obtained  Obtain building permission  Acquire funding  Survey members 15 5.000.- Quotation phase (P2) Offers selected, specialist company commissioned  Select contractors  Request quotations 28 4.500.- Preparation phase (P3) Old tower demolished, area prepared for new construction  Dismantle old tower  Dispose of materials  Prepare area for new construction 58 28.000.- Construction phase (P4) New tower is standing, TÜV approval granted  Assemble tower  TÜV inspection 16 360.000.- Completion phase (P5) Climbing trainers instructed, climbing tower handed over  Finishing work  Instructing the climbing trainer 4 2.500.- Total (estimation) 121 400.000.- Table 19 - Sample project: Project phases and main activities <?page no="77"?> Page | 77 2. Milestone list with deliverables Milestone Deliverable Date and Status M1 - Project manager assigned Project order received, project start has taken place 30.10.2021 / completed M2 - Project approved by the management board Board resolution has been passed, positive resolution of the AGM has been passed 20.02.2022 / completed M3 - Contractor selected for tower construction Offers selected, contractor commissioned 17.09.2022 / completed M4 - Demolition complete and area cleared Old tower demolished, area prepared for new construction 02.11.2023 / completed M5 - Acceptance of new building completed New tower is standing, TÜV approval granted 01.03.2024 / planned M6 - New climbing tower handed over to association Climbing trainers instructed, climbing tower handed over 24.03.2024 / planned Table 20 - Sample project: Milestone list 3. Phase plan Figure 23 - Sample project: Phase plan Agile elements can also be used in phase planning. The transitions between phases, i.e. to a milestone, can also be designed with a retrospective. A retrospective (see also chapter 8.1.3.5) deals with cooperation within the team and identifies specific improvements for collaboration and the work process. These improvements are implemented in the next phase [PREU20, DRÄT23]. <?page no="78"?> 78 | Page 3.5 Organisation and information Organisation and information (4.5.5) ‘The competence O RGANISATION AND INFORMATION includes the definition, introduction and management of the temporary project organisation. Organisation and information also includes the definition of the necessary roles and responsibilities as well as an effective exchange of information for the temporary organisation. The competence also includes the creation and storage of documentation, structures for reporting and the project-internal communication processes.’ [GPM17a, page 122] 3.5.1 Project organisation 4.5.1 Project design | 4.5.5 Organisation and information / Competence level 2 A project is always carried out within a certain framework. This implies that the people carrying out the project are integrated into an organisational structure - the project organisation. According to DIN 69901-5: 2009, this represents the ‘structural and procedural organisation of a specific project’ [DIN20b, page 159]. ISO 10006 is somewhat more specific; it differentiates between the host organisation or parent organisation and the project organisation. The host organisation is the organisation that decides to carry out the project and assign it to a project organisation. The project organisation, in turn, carries out the project [DIN20c]. Project organisations are temporary due to the specific lifespan of a project and are created specifically for the project. The structural organisation is used to define the framework that represents the hierarchical structure of the project organisation. The process organisation, on the other hand, regulates the spatial and temporal interaction of people, operating and working resources and information to fulfil the work tasks (process view). The classic and longest-known project organisation forms are:  Functional or influential project organisation  Matrix project organisation  Autonomous or pure project organisation 3.5.1.1 Functional or influential project organisation B In the influential project organisation, the project manager is embedded as a staff unit in the unchanged master organisation of the company. The project manager has no authority to issue instructions or make decisions and thus also no responsibility for results (which in practice turns out to be a fallacy in most cases). He merely performs an advisory function. The project staff continue to remain in their line functions [PATZ17]. <?page no="79"?> Page | 79 Figure 24 - Influential project organisation 3.5.1.2 Matrix project organisation The matrix project organisation divides the competencies between the line and project organisation. During the project, the project manager is released from the line organisation and is given the technical decision-making and managerial authority for projectrelated activities. The project members remain in their line functions and, in disciplinary matters, report to their superiors. The dashed lines show superordination and subordination with only technical management authority, while solid lines show superordination and subordination with both technical and disciplinary management authority. The steering committee shown acts as a temporary, overarching steering unit for the project. It serves as a reporting, decision-making and escalation body for the project manager and will be dissolved after the project has been completed [GPM17b]. There are different types of matrix project organisation: strong (pure), balanced and weak matrix. The strong matrix project organisation (PO) is more oriented towards the autonomous project organisation in the position of the project manager. In the balanced matrix PO, the project manager remains in the line, while the weak matrix PO tends more towards an influential PO. In this form of matrix PO, there is no designated project manager, only a project coordinator. <?page no="80"?> 80 | Page Figure 25 - Matrix project organisation 3.5.1.3 Autonomous or pure project organisation Figure 26 - Autonomous project organisation <?page no="81"?> Page | 81 In an autonomous project organisation, the project is taken out of the line organisation and thus becomes an independent element in the parent organisation. The project manager takes on technical and disciplinary responsibility for the project staff. The project staff are removed out of their line functions, assigned to the project and work exclusively for the project. Special forms of autonomous project organisation (no longer part of the core organisation) are:  Project companies (legally independent, project manager is also managing director), e.g. Projektgesellschaft Landesgartenschau Rheinland-Pfalz mbH, Projektgesellschaft Neue Messe GmbH & Co. KG  Joint ventures (ARGE) - a consortium of several companies for a collective project, e.g. ARGE Fahrbahn Transtec Gotthard (Alpine Bau Schweiz GmbH and Balfour Beatty Rail GmbH), ARGE Heben und Bewegen (Wiesbauer GmbH & Co. KG and SCHOLPP Kran & Transport GmbH) „Organisation is a means of multiplying the powers of the individual.“ Peter F. Drucker (1909-2005), US economist 3.5.1.4 Steering committee 4.3.2 Governance, structures and processes / Competence level 1 The steering committee (also known as the steering group, project advisory board) is a higher-level reporting, control, decision-making and escalation body and usually consists of senior employees from the company units affected by the project. The SC is usually the highest escalation since its composition can strike a balance between the interests of the client and the contractor [TIMI24]. The following table shows examples of the tasks of the steering committee (based on [PFET20, PATZ17]) Tasks  Decision-making in critical project situations  Supporting the project manager in implementing project decisions  Provision of the required resources  Approval of change requests (specifically for specifications)  Conducting project reviews  Regularly obtaining information about the project status  ... Competence (Authority)  Definition of the project manager's specific competences  Approval of milestones  Decision on proposed solutions  ‘Downward adjustment’ of red lights  ... Accountability  for the release / signing of the project order (e.g. by the representative of the LA)  for the discharge of the PL by releasing the project completion report  for making timely decisions on applications from the projects  ... Table 21 - TCA of a steering committee (example) <?page no="82"?> 82 | Page 3.5.2 Congruence principle in corporate governance 4.5.5 Organisation and information / Competence level 1 H ENRI F AYOL , the founder of French management theory, developed fourteen management principles as guidelines for corporate governance in the 1920s. One principle, namely ‘authority and responsibility’, is considered one of the best-known organisational principles and states that alignment (congruence) between tasks, competencies and acountability is required. Only if the job holder has the necessary (permission) and managerial (ability and willingness) competences to carry out the tasks, as well as the necessary information, can he or she be held responsible for the results of his or her work [MOTZ17, BEA11]. When developing the project organisation, the required roles and their TCAs (tasks, competencies, responsibility) must be described in the project. Ideally, the project manager already has people in mind for these roles during this phase. However, the roles are usually filled during resource planning. 3.5.2.1 Project roles A role describes a position in the project organisation for which a person is responsible. At the same time, it is the sum of expectations directed at the role owner. A role is assigned a) tasks b) competences c) authority and d) responsibility [GPM17b]. While tasks (What must the role owner do? What are their duties in fulfilling the task? ) and responsibility (What is the role owner technically and/ or disciplinarily responsible for? ) are clearly defined, competences and authority are often lumped together or used synonymously. Separately, authority stands for the ‘right to (legally effective) action in the name of and within the framework of organisations and/ or projects.’ [MOTZ17, page 39] in the sense of ‘What is the role owner allowed to do? ’ Competence on the other hand describes the ‘ability that an individual has in a specific field or in defined areas.’ [MOTZ17, page 106] in the sense of ‘What can the role owner do or what should they be able to do? ’ Competences can be differentiated, for example, into professional, methodological, social and personal competence. 3.5.2.2 TCA matrix 4.5.5 Organisation and information / Competence level 2 In a TCA matrix, the Tasks, Competences (in the sense of authorities) and Accontabilities of a role are set in relation to each other. It thus describes the project roles [MOTZ17]. The following table shows a possible role description (TCA) of a project manager (based on [PFET20, PATZ17]). <?page no="83"?> Page | 83 Tasks  Clarifying the assignment and coordinating with the client  Creating a framework schedule  Carrying out capacity and budget planning for the project  Defining the project team in coordination with the line managers  Monitoring the project goals with a focus on the agreed performance, costs and deadlines  Identifying risks and solutions  Ensuring a regular flow of information to all project participants (stakeholder management)  Preparing, coordinating and conducting project team meetings  Preparing and conducting status meetings with the steering committee  ... Competence (Authority)  Setting project-specific targets for team members  Calling project team meetings to coordinate content  Evaluating the project status on the basis of available information and defined measures  Demanding the provision of capacity and requesting additional capacity as part of risk management  Escalation to a higher decision-making body  Evaluating the work results  Demanding information about the absence of team members  Requesting the defined figures, data and facts for the respective milestone  ... Accountability  to ensure project success (performance, costs, deadlines)  for accountability to the clients and the steering committee  for the availability of a continuous, reliable project status  for the timely escalation of deviations or delays  for the implementation and communication of lessons-learned workshops or similar to improve project work  for the evaluation of change requests  for the coordination of communication and documentation in connection with the project  ... Table 22 - Excerpt from a role description (TCA) of a project manager (example) 3.5.2.3 Responsibility matrix 4.5.5 Organisation and information / Competence level 1 The responsibility matrix is an important organisational regulation in the project and shows the connection between tasks (work packages) or processes and the roles within the project team. For this purpose, the roles are listed in the columns of the matrix and the tasks in the rows. One way to create this precise assignment is the so-called RACI matrix. The acronym stands for [SCHM15] <?page no="84"?> 84 | Page  Responsible for the roles that complete a work package  Accountable for the role with decision-making authority  Consulted for the roles that are consulted before a decision is made  Informed for the roles that are notified (must be notified) after a decision is made. Figure 27 - RACI matrix (example) The RACI matrix is also used in an extended form - RASCI. The addition of an ‘S’ stands for  Supportant (supporting), is given the role of providing resources, information or mentoring In any case, the ‘Highlander principle’ applies here for ‘R’ (Responsible) or ‘A’ (Accountable) for each work package or process: There can be only one (‘Highlander: There can be only one’, US film, 1986). 3.5.3 Information management 4.5.5 Organisation and information / Competence level 1 According to the Brockhaus encyclopedia, ‘information’ is ‘intelligence, news, teaching, formulated instruction’. The information about the project and the project documentation should be available to the members of the project organisation and other stakeholders in a suitable form so that they are able to perform the tasks required of them. The design, collection, selection, storage, retrieval and provision of project data (in formatted, unformatted, graphical, electronic or paper form) is the content of information management. Information management has the choice between two basic types of information channels - via people as the bearers of information and by means of various media. Information can be provided via media in auditory, written or pictorial (visual) form. Interested stakeholders then have the option of collecting this information independently (pull principle) or receiving it automatically, for example as an electronic newsletter (push principle). Written communication includes reports, articles, reports and documents. Sound and images are often used simultaneously. ‘Social media’ is the keyword here. Facebook, WhatsApp, Youtube, Doodle and Co are increasingly being used to disseminate information and coordinate appointments. With all the disadvantages, such as the risk of misuse of information and the mixing of private and business information [PFET20]. In the project, it is important to determine who needs what information or what information need (information need matrix) has. The starting point for this is the stakeholder <?page no="85"?> Page | 85 analysis with the interests, attitudes, etc. of the individual stakeholders that have been worked out (outside-in approach) [FREI16]. 3.5.4 Document management 4.5.5 Organisation and information / Competence level 1 A document is defined in DIN EN ISO 9000: 2015 as ‘information and its carrier medium’. The obligation for ‘documentation to a useful extent’ is set out in DIN EN ISO 9001: 2015. The sum of all documents, as well as the knowledge and insights gained during the course of the project, and their use and application, represent the project documentation or project file [DIN20a, TIMI24]. A documents matrix or document overview list is useful for organising the project documentation. At a minimum, it shows which documents are to be created in the project or have already been created, who is responsible for them, the status (e.g. draft, released) of the respective document, the currently valid version number and where it is stored [FELK15, TIMI24]. Document Content Version Status responsible Phase stored Project profile … 1.00 released PM Pre-planning and examination Drive H: / Risk plan … 1.20 completed PM Quotation phase Folder QM Plan … 0.80 in progress PM Quotation phase … … … … withdrawn … … … Table 23 - Documents table (example) Document versioning is an important success factor in terms of change management. Without the version number of a document, it is no longer possible to determine after a short (project) period which of the circulating documents with the same name is the current and thus the valid document. It also proves helpful to determine at the beginning of the project how the documents are labelled (documentation standard) and which requirements (document standards) are to be met. The company may have documentation guidelines as part of ISO 9001 certification that specify the labelling, i.e. the naming. Otherwise, they are determined by the project manager at the beginning of the project. The document standards are divided into formal and content-related requirements. Formal requirements refer to information about the document, such as the structure of the document header with document name, number, project name, creation date, author and distribution list. The content-related requirements refer to the structure of the document (e.g. the objective of the document, summary, main body). <?page no="86"?> 86 | Page The need for documents can be recorded in a document requirement matrix. Based on the defined project subject, the typical document types for the project (e.g. requirement specification, status report, user manual) are checked for relevance and, if applicable, entered into the matrix with a reference to an existing template [TIMI24]. In companies certified according to ISO 9001: 2015, specific requirements apply with regards to documentation. 1. Documented information on the quality management system: The organisation must create and maintain documented information about its quality management system to ensure the effectiveness of the system. 2. Documented information required for process operation: It is necessary to provide documented information to ensure the operation of the processes within the quality management system. This may include procedural instructions, work instructions, specifications or other relevant documents. 3. Records: The organisation must create records to provide evidence of the effectiveness of the quality management system. These records may include reports, audit reports, training records, customer assessments, internal audits and other relevant documents. ISO 9001: 2015 deliberately makes the documentation requirements flexible. It is therefore crucial for each organisation to define and maintain its documentation requirements based on its type, size, the products and services offered, and the risks and opportunities. Important project documents In the course of a project, a large number of documents are produced, stored in electronic form on drives or conventionally filed in folders. Examples are listed in the following table [GPM17b, PATZ17, RÖSS08] Document Content Project profile includes the result of the project definition Project order contract for the realisation of the project Service description/ Functional specifications (Ger.: Pflichtenheft) the implementation plan developed on the basis of the customer's requirements specifications (Ger.: Lastenheft) Objective description contains the results to be delivered, which are to be formulated in a complete, unambiguous, positive, result-oriented and solution-neutral manner Contracts Service, work and/ or purchase contracts as documentation of who has to provide what to whom, under what conditions. Project organisation with the project participants and their roles describes the organisational and operational structure for the execution of the project Work breakdown structure incl. changes is the complete hierarchical representation of all elements of the project structure as a diagram or list <?page no="87"?> Page | 87 Document Content Phase plan organises the project timeline into objectively distinct sections (phases) with the most important activities Project schedule incl. changes is the graphical representation of the project process in the form of a Gantt chart or network diagram. Resource plan Overview of the resources planned for the project Risk action plan List of corrective or preventive countermeasures to avoid, reduce or transfer risks Status reports summarising project report on the current state of the project Minutes Documentation of ideas, insights and decision-making processes to record the meaningfulness and transparency of an approach. Closure report A summarising, concluding presentation of the tasks and the results achieved in terms of time, costs and personnel expenses, as well as, if applicable, information for follow-up projects. Table 24 - Examples for project documents 3.6 Literature [APM17b] APM (Association for Project Management) (Hrsg.). (2022). 10 key principles of stakeholder engagement | APM. Abgerufen am 08. August 2023 von https: / / www.apm.org.uk/ resources/ find-a-resource/ stakeholder-engagement/ key-principles/ [ASSE14] van Assen, M., van den Berg, G., & Pietersma, P. (2. Aufl. 2009). Key Management Models. Harlow: Pearson Education [BEA11] Bea, F. X., Friedl, B., & Schweitzer, M. (10. neubearb. und erweit. Aufl. 2011). Allgemeine Betriebswirtschaftslehre. Band 2 Führung. Stuttgart: UTB / Lucius & Lucius [BEA19a] Bea, F. X., Scheurer, S., & Hesselmann, S. (3., vollst. überarb. und erweit. Aufl. 2019). Projektmanagement. Konstanz: UVK Verlagsgesellschaft GmbH. [BEA19b] Bea, F. X., & Haas, J. (10. Aufl. 2019). Strategisches Management. Konstanz: UVK Verlagsgesellschaft mbH [BERG21] Bergmann, R., & Garrecht, M. (3., aktual. und erweit. Aufl. 2021). Organisation und Projektmanagement. Wiesbaden: Springer Gabler <?page no="88"?> 88 | Page [CARR69] Carroll, L. (1869). Alice im Wunderland (Digitale Volltext-Ausgabe bei Wikisource Ausg.). (A. Zimmermann, Übers.) Leipzig: Johann Friedrich Hartknoch. Abgerufen am 15.02 2017 von https: / / de.wikisource.org/ w/ index.php? title=Seite: Alice%E2%80%99s_Abenteuer_im_Wunderland_083.jpg&oldid=2804696 [DIN20a] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. DIN 69901-5 Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH [DIN20c] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. ISO 10006 - Qualitätsmanagementsysteme - Leitfaden für QM in Projekten. Berlin: Beuth Verlag GmbH [DÖRN11] Dörner, D. (14. Aufl. 2011). Die Logik des Mißlingens. Strategisches Denken in komplexen Situationen. Reinbek: Rowohlt Taschenbuchverlag. [DRÄT23] Dräther, R., Koschek, H., & Sahling, C. (3. Aufl. 2023). Scrum - kurz & gut. Köln: O’Reilly Verlag [EBER22] Ebert, C. (7., überarb. u. aktual. Aufl. 2022). Systematisches Requirements Engineering: Anforderungen ermitteln, spezifizieren, analysieren und verwalten. Heidelberg: dpunkt.verlag GmbH. [FELK15] Felkai, R., & Arndt, B. (3. Aufl. 2015). Projektmanagement für technische Projekte. Wiesbaden: Springer Fachmedien GmbH [FLEI22] Fleig, J. (15. November 2022). SWOT-Analyse: So wird eine SWOT- Analyse erstellt - business-wissen.de. Abgerufen am 08. August 2023 von business-wissen.de: https: / / www.business-wissen.de/ artikel/ swotanalyse-so-wird-eine-swot-analyse-erstellt/ [FREI16] Freitag, M. (2016). Kommunikation im Projektmanagement: Aufgabenfelder und Funktionen der Projektkommunikation. Wiesbaden: Springer Fachmedien [GABL18] Gabler Wirtschaftslexikon. (19. Feb. 2018). Gabler Wirtschaftslexikon. Abgerufen am 08. August 2023 von Definition | Autorität: https: / / wirtschaftslexikon.gabler.de/ definition/ autoritaet-31414/ version-254971 [GNAK17] Geschäftsstelle der Nationalen Arbeitsschutzkonferenz (Hrsg.). (2017). Leitlinie Gefährdungsbeurteilung und Dokumentation. Berlin: Bundesanstalt für Arbeitsschutz und Arbeitsmedizin. [GPM17a] Deutsche Gesellschaft für Projektmanagement e.V., (Hrsg.). (1., aktual. Aufl. 2017). Individual Competence Baseline für Projektmanagement, Version 4.0 / Deutsche Fassung (Bd. 1). Nürnberg: Deutsche Gesellschaft für Projektmanagement e.V. (GPM) [GPM17b] GPM, SPM, & Gessler, M. (Hrsg.). (8. Aufl. 2017). Kompetenzbasiertes Projektmanagement (PM3): Handbuch für die Projektarbeit, Qualifizierung und Zertifizierung auf Basis der IPMA Competence Baseline Version 3.0. Nürnberg: GPM Deutsche Gesellschaft für Projektmanagement e.V. <?page no="89"?> Page | 89 [GRIF15] Griffiths, M. (2015). PMI-ACP Exam Prep. RMC Publications Inc. [HRUS23] Hruschka, P. (3. Aufl. 2023). Business Analysis und Requirements Engineering: Produkte und Prozesse nachhaltig verbessern. München: Carl Hanser Verlag [IEEE11] International Organization for Standardization (Hrsg.). (2011). ISO/ IEC/ IEEE 29148 Systems and software engineering ‒ Life cycle processes ‒ Requirements Engineering. Genf [KERZ22] Kerzner, H. (13. Aufl. 2022). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. Hoboken, New Jersey: Wiley [MART16] Martinelli, R., & Milosevic, D. (2. Aufl. 2016). Project Management ToolBox: Tools And Techniques For The Practicing Project Manager. New Jersey: Wiley [MOTZ17] Motzel, E., & Möller, T. (3., überarb. u. aktual. Aufl. 2017). Projektmanagement Lexikon: Referenzwerk zu den aktuellen nationalen und internationalen PM-Standards. Weinheim: Wiley-VCH Verlag [OLFE19] Olfert, K. (Hrsg.). (17., aktual. Aufl. 2019). Kompendium der praktischen Betriebswirtschaft - Personalwirtschaft. Herne: NWB Verlag. [PATZ17] Patzak, G., & Rattay, G. (7., überarb. Aufl. 2017). Projektmanagement: Leitfaden zum Management von Projekten, Projektportfolios und projekt-orientierten Unternehmen. Wien: Linde Verlags GmbH [PFET20] Pfetzing, K., & Rohde, A. (7., vollst. überarb. Aufl. 2020). Ganzheitliches Projektmanagement. Wettenberg: Verlag Dr. Götz Schmidt. [PMI21a] Project Management Institute Inc. (7 th Edition 2021). A guide to the Project Management Body of Knowledge und Die Norm für Projektmanagement. Pennsylvania: PMI Inc. [PREU20] Preußig, J. (2. Aufl. 2020). Agiles Projektmanagement. Agilität und Scrum im klassischen Umfeld. Freiburg: Haufe-Lexware [RÖSS08] Rößler, S., Mählisch, B., Voigtmann, L., Friedrich, S., & Steiner, B. (2. Aufl. 2008). Projektmanagement für newcomer. Dresden: RKW Sachsen GmbH [SCHE16] Scheuring, H. (7., überarb. und erg. Aufl. 2016). Der www-Schlüssel zum Projektmanagement: Eine kompakte Einführung in alle Aspekte des Projektmanagements und des Projektportfolio-Managements. Zürich: Orell Füssli [SCHE18] Schein, E. H., & Schein, P. (5. Aufl. 2018). Organisationskultur und Leadership. München: Verlag Franz Vahlen. [SCHM15] Schmitt, R., & Pfeifer, T. (5., aktual. Aufl. 2015). Qualitätsmanagement - Strategien - Methoden - Techniken. München: Carl Hanser Verlag [SZTUb] Sztuka, A. (o.J.). Unternehmenskultur - Analyse und strategische Veränderung. Abgerufen am 08. August 2023 von manager wiki: http: / / www.manager-wiki.com/ strategieumsetzung/ 6-unternehmenskultur <?page no="90"?> [TFME13] Team FME. (2013). PESTLE Analysis - Strategy Skills. O.O.: www.free-management-ebooks.com [TIMI24] Timinger, H. (2. Aufl. 2024) Modernes Projektmanagement. Mit traditionellem, agilem und hybridem Vorgehen zum Erfolg. Weinheim: Wiley- VCH Verlag [VDI01] VDI Verein Deutscher Ingenieure e.V. (2001). VDI 2519 Blatt 1: Vorgehensweise bei der Erstellung von Lasten-/ Pflichtenheft. Berlin: Beuth Verlag GmbH [WITT73] Witte, E. (1973). Organisation für Innovationsentscheidungen. Das Promotoren-Modell. Göttingen: Verlag Otto Schwarz & Co. [WUND11] Wunderer, R. (9., neu bearb. Aufl. 2011). Führung und Zusammenarbeit. Köln: Wolters Kluwer GmbH <?page no="91"?> Page | 91 4 Plannning phase Figure 28 - ICB elements in the planning phase In the planning phase, the essential conditions for the project are defined. The planning should determine realistic values for output, costs and deadlines. This helps to reduce errors, prevent a lack of coordination and avoid undesirable developments at an early stage of the project. Project planning includes, among other things, planning the project structure, the project effort, the use of resources and the costs. Depending on the specific requirements of the project, the contract contents are also agreed with the suppliers at the end of the planning phase [GPM17b]. In principle, the following questions should be answered during the planning in order to obtain a concept or planning approval as the result of this PM phase [BERG21]. What? What needs to be done in detail (work breakdown structure)? How? How should the procedure be carried out (schedule of operations)? What means and resources will be used (resource plan)? When? When will the project start? When should / must it be finished (schedule)? How much? How much will the project cost and how will it be financed (cost and finance planning)? Which? Which risks and opportunities can be identified (risk plan)? How well? Which quality objectives must be achieved and how is their achievement ensured (quality plan)? Table 25 - Questions during the planning phase <?page no="92"?> 92 | Page The planning phase contains various ICB elements from the P RACTICE area. However, they appear in a different order. In the author's opinion, it makes more sense to deal with resource requirements first and then to carry out cost planning based on these. The topics of risks and opportunities and quality are processes that run alongside the project and can also be started or carried out in an earlier project management phase. 4.1 Scope Scope (4.5.3) ‘The [project] S COPE defines the specific focus or content of the project. It describes the results, the services and the benefits and thus the work required to produce them. [...] Essentially, the S COPE describes the boundaries of the project.’ [GPM17a, page 114] Project structures create order within a project. In addition to dividing the overall task into manageable units, this also includes phase planning (see chapter 3.4), defining the project organisation (see chapter 3.5), planning costs (see chapter 4.4) and planning communication. The project structure thus provides all stakeholders with a clear orientation and makes communication easier for the project manager [DIN20b]. 4.1.1 Structuring the scope 4.5.3 Scope / Competence level 2 Work breakdown structure The work breakdown structure (WBS) is a key instrument that forms the basis for all further project plans and is therefore also referred to as a ‘bill of materials for the project’ or ‘plan of plans’ [BEA19b, GPM17b]. In other words, the WBS is a structuring of the work to be carried out by the project team in order to fulfil the project objectives and create the required deliverables. It organises and defines the entire content and scope of the project [PMI21a]. The work breakdown structure thus provides  a good overview by systematically recording the individual tasks across the project in its entirety  a basis for the subdivision of the deliverables into smaller components (work packages) with clear responsibilities  a complete overview of the project content  all services to achieve the project goal, which have an impact on costs  a basis for the necessary coordination at interfaces between the work packages [PATZ17, KERZ22] Structure of the WBS A hierarchical tree structure is used for the WBS. It consists of  root element  subprojects  subtasks  work packages <?page no="93"?> Page | 93 Figure 29 - Elements of the WBS The work package is by definition the ‘smallest non-divisible unit’ in the WBS. However, it can be broken down into individual activities if this is necessary in the further course of planning. The relationship between the work package and the activity can be as follows  1: 1 (one work package = one activity)  1: n (one work package = several activities)  rather theoretical - m: 1 (several work packages = one collective activity) The work packages should not be too small, otherwise the structure plan will become very confusing and difficult to manage. In practice, a structure with three to four levels of detail has proven to be useful. However, this always depends on the  information needs of the decision-makers  level of detail of already existing information (e.g. similar projects)  information needs of the recipients of the WBS Orientation principles of the WBS When creating work breakdown structures, four different structure principles are distinguished: [DIN20a]  phaseor process-oriented  object-oriented  functionor activity-oriented  mixed-oriented Phase or process-oriented The structuring of the subtasks is based on the selected phase model or the time sequence of the individual activities necessary for the realisation of the project (when will the work be done? ). <?page no="94"?> 94 | Page Figure 30 - Sample project: phase-oriented WBS Pro Con  The rough time frame for the project can be seen from the WBS.  Clearly structured project sections  Prerequisite for a purely sequential processing of all subtasks  Mixing of structure planning with aspects of subsequent process planning <?page no="95"?> Page | 95 Object oriented The structuring of the subtasks is done according to the technical structure of the object or the individual components that are to be created in the project (What needs to be done? What needs to be worked on? What does the delivery item consist of? ). Figure 31 - Sample project: object-oriented WBS Pro Con  The structure can be derived directly from the design documents.  Synergies from the execution of similar subtasks for different objects remain unused, e.g. procurement  Some work packages cannot be traced back to any object, e.g. securing project financing <?page no="96"?> 96 | Page Functionor activity-oriented The structuring of the subtasks is done according to different functions or according to the individual activities (roles) that are necessary for the realisation of the project (who carries out the work or where is it carried out? ). Figure 32 - Sample project: function-oriented WBS Pro Con  Synergy benefits through specialisation are utilised  Immediate assignment of function-oriented work packages (AP) to the units of the company organisation  Fixing the functional organisational form, no consideration of overarching requirements  Not all functions apply to all project parts <?page no="97"?> Page | 97 Mixed-oriented The structure is created by combining the above-mentioned procedures as appropriate. Figure 33 - Sample project: Mixed-oriented WBS (1 st level: object-oriented, 2 nd level: function-oriented) Pro Con  flexible use of the various structuring options  no distinct system for the project structure Usually, the WBS structure is defined in the level below the root element, and the work packages to be executed are listed in the levels below that. There is no ‘correct’ work breakdown structure either. What is important is that the project benefits from the structure, that the team members can work with it, and that the project work packages are fully mapped. The principle ‘As precise as necessary, not as precise as possible’ applies. Project management in the WBS The activities and processes of project management, like the other processes, are services that are provided and usually compensated. To make the PM activities and the associated effort visible to all parties involved, ‘project management’ is to be listed as a separate element with the corresponding subdivisions in the second level of each WBS [GPM17b]. <?page no="98"?> 98 | Page Figure 34 - Project management in the WBS (example) The element ‘project management’ is independent of the chosen structuring principle - object-, function-, phaseor mixed-oriented - of the WBS [PATZ17]. A simplified variant can also be represented with the three work packages - project planning, project control and project completion. Here, the principle ‘As precise as necessary, not as precise as possible’ also applies. Coding in the WBS To identify the WBS elements - root element, subproject, subtask, work package - it is necessary to label them unambiguously. To do this, the elements are coded, i.e. given a WBS code number. In most cases, the root element is given the project number under which the project was created in the company. The WBS code for all further elements is now to be selected so that they can be unmistakably assigned to the project. For the coding, an identifying and classifying key system is distinguished. The identifying coding only allows the direct location of the WBS element without additional information. It can be … <?page no="99"?> Page | 99  numerical,  decadal (special form of numerical coding with fixed length),  alphabetical or  alphanumerical Figure 35 - Example for numerical (left side) and alpha-numerical coding (right side) The classifying WBS code is used when more than just the assignment of elements is to be displayed [GPM17b]. Figure 36 - Classifying coding Note: As with the design of the work breakdown structure, the same applies here: “Not as much information as possible, but only as much as necessary.“ Differentiation Objectives system vs. work breakdown structure Objectives define the ‘why’ for the project, its purpose - what needs to be achieved, what benefits need to be realised, and which stakeholder requirements need to be met?  Goal status The WBS defines the specific focus or content of the project. It describes the results, the performance and the benefits and thus the work required to generate them.  How to achieve the goal <?page no="100"?> 100 | Page 4.1.2 Procedure for creating the WBS 4.5.3 Scope / Competence level 2 When creating the work breakdown structure, the core team is involved in addition to the project manager. This ensures that all project participants record all tasks and develop a common understanding of the project. The following procedural steps are recommended [PATZ17, GPM17b]  Top down (deductive approach or decomposition method) Starting from the root element, the project is broken down into its individual levels until the work packages are available. The elements are then coded.  Bottom up (inductive approach or assembly method) Using creativity techniques (e.g. brainstorming), the work packages are identified and summarised in ascending order. A WBS code is then assigned to the elements. In both approaches, care must be taken to ensure that no work steps are forgotten and that no duplicate work is planned. The ‘completed’ work breakdown structure is discussed in the extended project team and, if necessary, coordinated with experts. The resulting adjustments are incorporated and documented for the further planning steps (scheduling and scheduling, resource planning, cost planning, risk analysis) and defined as a basis. 4.1.3 Definition of work packages 4.5.3 Scope / Competence level 2 Once the structuring principle for the work breakdown structure has been defined, it is further detailed. The work packages, as ‘self-contained tasks to be completed by a specified point in time with a defined result and effort’ [DIN20a, page 151], are to be described and assigned accordingly. The minimum scope of the work package description includes the following points [GPM17b]  Project number and name  Title of the work package and WBS code  Work package manager  Activities or service description  Objective or expected result(s)  Prerequisites (e.g. resources, advance payments)  Deadlines, costs  Effort  Measurement of progress  Work package status (e.g. open, started or in progress, completed)  Risk (is the work package a (preventive) measure from the risk list? Does the work package contain a risk? )  Date and signature of the work package manager (WPO) The following figure shows an example of a possible work package form. <?page no="101"?> Page | 101 Work Package Form Project no. CT-22 WP Owner C. Mountjoy, climbing instructor Project name New climbing tower Project phase Preparation phase WBS-Code WP CT-22-D3 WP designation Prepare the ground Predecessor (WBS code) Start of WP (date) Duration of WP (weeks) End of WP (date) Successor (WBS code) CT-22-D1 Feb 08, 2023 30 Oct 30, 2022 CT-22-E1 Preconditions for the WP WP Risk / opportunity (incl. explanation) A specialised company must be hired to meet the deadline. Reason: Not enough members are volunteering for the work to be done. The old tower must be completely dismantled. Deliverables of the WP / Activities: All groundwork necessary to prepare the designated area for the new tower, including a fall-protection floor (225 sqm), so that it is level, free of contamination and has a stable foundation. Resources & costs / participating project members No. executing persons effort (PD) further resources personnel cost (€) investments €) material cost (€) 1 P. Peakson (PM) 40 rental van 4.800. - 0.- 1.000. - 2 Mountjoy (WPO) 40 materials 4.000. - 0.- 3.200. - 3 Club members 60 catering 1.380. - 0.- 800. - Total 140 10.180. - 0.- 5.000. - Specifics Progress measurement quantity-based, in percentage of the prepared area to the total area of 225 sqm. WP Owner Project manager _________________________________ Date, signature ________________________________ Date, signature Figure 37 - Sample project: Work package description <?page no="102"?> 102 | Page 4.2 Time Time (4.5.4) ‘The competence element T IME comprises the identification and structuring (sequencing and scheduling) of all components of a project in chronological order in order to optimise implementation.’ [GPM17a, page 118] On the basis of the project content as defined in the work breakdown structure, the logical and chronological sequence of the work packages and the resulting processes is determined with the help of creating a detailed schedule. An important tool for this is the network planning technique, also called PERT (Program Evaluation and Review Technique). With the help of a network plan, the tasks to be processed, including their dependencies, can be displayed. The most common representation is the activity-onnode network diagram (AON) or AON diagram [PMI21a]. 4.2.1 Process 4.5.4 Time / Competence level 2 The creation of a schedule (network diagram) takes place in four steps. Figure 38 - Process of creating the project schedule Activity list The work packages identified in the work breakdown structure form the basis of the activity list. Depending on the requirements, it may be necessary to break down individual work packages into the activities they contain (1: n). It is important that all work package managers affected provide the necessary information for the ‘unbundling’ of their work packages or do so themselves [GPM17b]. The motto here should be ‘as rough as possible, as detailed as necessary’. Logical relationships (LR) The processes are now examined for their temporal and logical dependencies. In addition to the dependencies of the processes of a work package on each other, there are <?page no="103"?> Page | 103 often logical relationships beyond the work package boundary. The following relationships can be used:  normal sequence (finish-to-start relationship; FS),  start sequence (start-to-start relationship; SS),  end sequence (finish-to-finish relationship; FF) and  jump sequence (start-to-finish relationship; SF) [PATZ17]. (see also Figure 41 - Relationships.) It is recommended to start with normal sequences first and to use start and finish sequences in the further course of planning (e.g. for optimisation). Duration The aim of this step is to realistically estimate the duration of the individual activities.  Estimation methods: see chapter 4.3.3 Estimation methods. The following table shows an example of the results of the three steps: activity list, relationships (LR) and activity duration. WBS Code Activity Duration WBS Code Successor LR … … … … … M3 Quotations selected, contractor commissioned 0 days CT-22-D1 normal (FS) CT-22-D Preparation phase …-D1 Dismantle old tower 104 days CT-22-D3 CT-22-D2 normal (FS) start (SS) …-D2 Dispose of material 98 days M4 normal (FS) …-D3 Prepare the ground 189 days M4 normal (FS) M4 Old tower dismantled, ground prepared for new construction 0 days CT-22-E1 normal (FS) … … … … … Table 26 - Sample project: Activity list (excerpt) Project duration & deadlines The network plan is now created from the activity list. It is important to note that each activity must have at least one predecessor and one successor. The only exceptions are the start event (no predecessor) and the end event (no successor). Based on the start event, the total duration of the project can be determined using the duration of the activities. This analysis also provides information on the earliest and latest dates of the processes, how much buffer time exists between the processes and which sequence of processes requires particular attention (critical path). In the subsequent calendaring <?page no="104"?> 104 | Page process, the schedule is linked to the project calendar. This allows for the consideration of predefined deadlines, weekends, holidays and working hours [PATZ17]. To understand the various calculations, it is important and useful to be able to follow them manually in outline. In project practice, no one will calculate a complex project ‘by hand’. This is usually done by planning tools such as Microsoft ® Project, ORACLE ® Primavera, OpenProject, InLoox or similar. 4.2.2 Elements in the network diagram The most important elements of the network diagram - activity nodes and relationships - are presented and explained here with the associated terms. A detailed description can be found in DIN 69900: 2009 [DIN20e]. Activity nodes Figure 39 - Activity node in an AON network diagram ES and EF indicate the start and end times of the earliest stage, i.e. the stage of the operation that cannot be moved forward further, taking into account the conditions contained in the network plan. LS and LF are thus the key times for the latest stage (cannot be moved back further). The total buffer time or total float (TF) denotes the period between the earliest and latest start time of an activity (LS-ES or LF-EF) and is also the period by which the activity can be shifted until it reaches the latest start time of its successor [GPM17b]. In practice, exceeding this buffer affects the project's end date. Free buffer time or free float (FF) indicates the time by which the operation can be shifted with respect to its earliest position without affecting the ES of its successor [DIN20e]. Figure 40 - Free float and total float <?page no="105"?> Page | 105 Logical relationships - overview Every activity has a start and an end time. The relationship between the activities is always expressed in terms of the start or end time. This results in four possible links. A relationship always describes the relationship between exactly two activities (1: 1). However, an activity can have several of these relationships. Figure 41 - Logical relationships (LR) of activites The following examples will clarify the LR structure. The examples show the network plan with activity nodes and the bar chart or Gantt chart, as displayed in Microsoft ® Project. The length of the bars in the Gantt chart or diagram is proportional to the duration of the process. Example normal sequence (FS) Figure 42 - Example normal sequence (FS) <?page no="106"?> 106 | Page Example Start sequence (SS) Example End sequence (FF) Example Jump sequence (SF) (very rare) Positive and negative time intervals To show necessary delays or overlaps between operations, fixed time intervals can be defined. These can be assigned a positive (delay) or negative value (overlap), as shown below. In this example, the paint must dry for three days before work can begin on the film set. This fixed time interval could also be integrated into the ‘painting the set’ process as a drying time. However, since no resources are assigned to this ‘activity’ and it would unnecessarily extend the process, the fixed interval to the successor is the better choice. Figure 43 - Example Start sequence (SS) Figure 44 - Example End sequence (FF) Figure 45 - Example Jump sequence (SF) Figure 46 - Delay, positive time interval <?page no="107"?> Page | 107 A negative time interval brings forward the start of the successor. In the example, the process ‘setting up props’ can start two days before its predecessor ends. This type of overlap is already part of the fine-tuning of the network diagram. A few simple rules apply when calculating the network plan [DIN20e]. 1. Defining the duration for all activities 2. Forward calculation (progressive calculation) a. For the first activity (start milestone), ES = 0 is inserted b. Then the EF is determined: EF = ES + duration c. If there is no time interval between the end of the process and the next process, ES S = EF P . Otherwise, the time interval is included: ES S = EF P + time interval d. When activities are combined, the highest EF P is used as the ES S Figure 48 - Forward calculation 3. Backward calculation (retrograde calculation) a. LF = EF is inserted in the last activity b. Then the LS is determined  LS = LF - duration c. If there is no time interval for the previous activity, LFP = LSS; otherwise, the time interval is included: LFP = LSS - time interval d. When activities are combined, the lowest LS S is used as LF P Figure 49 - Backward calculation Figure 47 - Overlap, negative time interval <?page no="108"?> 108 | Page 4. Determining the reserves a. The total float is calculated for each activity  TF = LS - ES or TF = LF - EF b. The free float for each activity is then calculated as follows: FF = ES S - EF P . If there is a time interval between the activities, this is included in the calculation: FF = ES S - time interval - EF P Figure 51 - Free float c. Identifying the critical path. The critical path is i. The longest path through the project, and ii. the path in which all buffers (TF and FF) are zero for all activities. This means that any delay within this chain will also delay the project completion date. 4.2.3 Calendaring In the above procedure of the critical path method, only relative time units were used, and it was assumed that all activities can follow each other without gaps. In practice, it must be taken into account that  only a limited number of working hours are available in a working day  and that the time to be planned is extended by weekends, holidays, bridge days, vacations, company holidays, etc. Thus, in order to be able to make specific statements about deadlines, a calendar must be defined. In contrast to duration, which represents a time span between the start and finish of an activity, a deadline is an exact point in time that is expressed by a calendar date. This ‘imposition’ of a calendar over the previous planning is called calendaring [GPM17b]. In this process, an original duration of 20 days can become a duration of 40 days, for example, taking into account the above-mentioned framework conditions (see Fig. 52). If you are working in an international context, country-specific holidays (e.g. national holidays, religious holidays) or climatic peculiarities (e.g. rainy season) may further extend the duration of the project. Figure 50 - Total float <?page no="109"?> Page | 109 Figure 52 - Transfer of the project duration into the calendar (example) <?page no="110"?> 110 | Page 4.2.4 Optimising the network diagram 4.5.4 Time / Competence level 2 (Level C) After setting up the network plan and calculating the expected total duration, it may become apparent that a final deadline demanded by the client cannot be met in this constellation. An iterative process now begins with all parties involved, with the aim of optimising the schedule without reducing the content and scope of the project [PMI21a]. 1. Fast Tracking (shortening) a. Overlapping By using negative time intervals (e.g. NF -2), two activities are no longer processed sequentially but overlap. b. Parallelisation By starting two or more activities at the same time or by changing the relationship from normal sequence to initial sequence, where this is sensible and possible, activities are no longer processed sequentially but in parallel. 2. Crashing (compression) The duration of activities can be shortened by capacity measures. For example, increasing resources, using more qualified resources, assigning overtime, assigning resources from non-critical activities to activities on the critical path. The ‘iron triangle’ (scope, costs, time) must be taken into account in all these measures. Most compression measures have an immediate effect on costs. „Adding manpower to a late software project makes it later.“ 19 Frederick P. Brooks, computer scientist, author of ‘The Mythical Man-Month. Essays on Software Engineering’ Note: Changes to the project content and scope (reduction in scope) can only be implemented with the consent of the client and are subject to change management. 4.3 Resources Resources (4.5.8) ‘The competence R ESOURCES includes the definition, procurement, control and development of resources that are required to achieve the project result. Resources include personnel, expertise, facilities, equipment, materials, infrastructure, tools and other assets that are required for the targeted execution of the activities.’ [GPM17a, page 136] Once an understanding of the duration of the project has been established on the basis of the schedule and the schedule of deadlines, the next step is to reconcile the determined plan with the real resources by means of resource planning. The work breakdown structure, with its subtasks and work packages, and the activity list derived from it, forms the basis for resource planning. 19 Also known as ‘Brook’s Law’. <?page no="111"?> Page | 111 4.3.1 Resource types 4.5.8 Resources / Competence level 2 There is no standardised system for resource types. In general, a distinction is made between  personnel (with a specific qualification)  material (with certain characteristics)  financial resources. In addition, knowledge, know-how, licences and patents can also be considered resources and summarised under the generic term ‘abstract resources’ [ANGE12]. The four ‘M’s are common in the project environment - Man, Machine, Material, Money (finances). 4.3.2 Resource planning process Figure 53 - Resource planning process Identify demand 4.5.8 Resources / Competence level 2 In the first step, the demand for person-days can be estimated ‘overall’ for the entire project, although this means that no distinction is made between the different qualifications required. In order to be able to compare the demand with the available capacities at a later stage, the project planning must be refined and the various necessary resources must be assigned to the work packages or activities [BEA19a]. Resources Amount Effort (PD) Project manager (PM) 1 120 Chairman (CH) 1 65 Chief Finance Officer (CFO) 1 35 Climbing instructor (CN) 1 80 Office staff (OF) 1 60 Volunteers (VL) 10 80 Table 27 - Sample project: Resource demand (personnel) <?page no="112"?> 112 | Page The following questions help to plan the resources [PATZ17]  Which qualifications are required?  How many of them (number) are needed?  Which are bottleneck resources?  From when (point in time) and how long (period of time) are they needed?  How can it be ensured that these resources are also available?  Estimation methods, see chapter 4.3.3 Estimation methods To cover as many aspects as possible in the estimation, it is advisable to involve all parties concerned. The result is a list of the required resources by type and number, without reference to specific persons. WBS Code Activity Duration (days) Effort (PD) Amount … … … … … M3 Quotations selected, contractor commissioned 0 CT-22-D Preparation phase …-D1 Dismantle old tower 104 40 40 50 1 PM 1 CN 5 VL …-D2 Dispose of material 98 20 20 50 1 PM 1 CN 5 VL …-D3 Prepare the ground 189 40 40 60 1 PM 1 CN 10 VL M4 Old tower dismantled; ground prepared for new construction 0 … … … … … Table 28 - Sample project: Resource demand plan (excerpt) Determine capacity The calculation can be carried out in a general or detailed manner. In the general approach, the available net working time (net capacity) is calculated after deducting all weekends, holidays, vacation, training and average sick days [BEA19a]. With the general planning, around 10 person months of available working time could be estimated per resource. However, this does not reflect the reality of the project. Depending on the project organisation, employees have to complete routine tasks in their line function or are also involved in other projects. The detailed planning provides more clarity in this case [GPM17b]. <?page no="113"?> Page | 113 Calendar days 365 Weekends -105 Public holidays -10 Gross capacity 250 Annual leave -30 Sick leave, further education -10 Net capacity 210 Table 29 - Net capacity (example) Net capacity 210 Administration / meetings -25 Regular work (line activities) -20 Project capacity 165 Work in other projects -95 Free capacity 70 Table 30 - Free capacity (example) This planning should be done at least once per month for each resource, and the more precisely (to the day) the better. Synchronise demand and capacity 4.5.8 Resources / Competence level 2 Now that it is clear which resources should be used for the project, when and for how long, these findings must now be compared with the capacities that are actually available. To do this, take the activities in the networked Gantt chart that are to be carried out by the planned resource and define the resource planning for them in the form of a resource histogram [BEA19a]. In doing so, you must not ‘compare apples and oranges’, i.e. only resources with the same qualifications may be grouped and analysed. The resource histogram (also known as the utilisation diagram) allows you to quickly determine when the capacity limit is exceeded (shortage) or when the resource is not fully utilised (surplus). While a surplus is only critical from an economic point of view, a shortage can endanger the success of the project (e.g. tasks are not completed or are completed with poor quality, illness-related absence of the resource due to overwork leads to further bottlenecks). Therefore, under-coverage must always be resolved, i.e. the project plan is to be optimised to that effect. <?page no="114"?> 114 | Page Figure 54 - Sample project: Resource histogram project manager (excerpt; preparation phase) Optimise the resource plan 4.5.8 Resources / Competence level 2 The aim of resource optimisation is to exploit all possibilities under the given availabilities in order to ensure the feasibility of the project. There are two basic approaches to this [LITK05]: Schedule effectiveness optimisation In this method, the schedule and schedule are adhered to, and activities may only be rescheduled within the buffer times. Availability is increased by the use of qualified personnel. Measures may include, for example, the redeployment of resources within the company in favour of the project, the outsourcing of services or multi-shift operation. The budget plays a subordinate role here. Capacity-adherence optimisation This method regards the given capacity as unchangeable. Optimisation can only be achieved here by shifting and/ or stretching activities, whereby shifts in project deadlines are accepted. <?page no="115"?> Page | 115 Concrete optimisation measures can be [BEA19a]:  Shift - the resource problem is solved by moving the activity. However, this is only possible if the temporal and logical relationships to the other activities / work packages allow it.  Stretch - more time is scheduled for the activity. The effort remains the same but is distributed over a longer period.  Substitute - the resource used so far is replaced by a more efficient resource.  Split - the activity or work package is broken down into several parts, which are rescheduled to resolve the resource bottleneck.  Compress - the activity is shortened in time, but this leads to an increased resource requirement and may require additional optimisation measures at other activities / work packages. The sixth measure, performance reduction by deleting work, is, as already stated in chapter 4.2 the subject of change management and not an optimisation tool. 4.3.3 Estimation methods 4.5.4 Time | 4.5.7 Cost and finance / Competence level 2 Estimating the cost and effort involved is an important basis for fundamental decisions and is therefore the second feasibility check for the project goals specified by the client, after the phase plan. At this point, a go/ no-go decision for the project can be made again, taking into account the given framework conditions regarding personnel, materials and equipment. Examples of miscalculations that have led, among other things, to damage to a company's image and/ or high contractual penalties include Introduction of the ‘lorry toll in Germany’ by the operating consortium Toll Collect 2006 - multiple postponement of the start date from 31 August 2003 to 2 November 2003, then to 1 January 2005. Ultimately, the system was fully operational in January 2006. The delay was due not only to technical issues but also to an underestimation of the effort involved in the project. Construction of Terminal 5 at London Heathrow in 2008 - baggage chaos after commissioning: at times, up to 28,000 suitcases piled up, and 431 flights had to be cancelled in the first four days. The cost of testing the new baggage handling system was underestimated and, due to time constraints (the opening date had been announced), was not corrected. Similarly, the costs for training the baggage handling staff were underestimated. The following methods can be used for this [BEA19b, GPM17b, DIN20a] Methods Explanation Expert estimation Individual estimation Access to the specialised knowledge of a single expert. The process is straightforward, but the quality of the estimate depends on the professionalism of the person consulted. Estimation meeting This approach emphasises group-dynamic processes. The experts (usually the project team) plan and estimate the activities / work packages collectively. This helps to establish a collective basis and understanding for the project. <?page no="116"?> 116 | Page Planning Poker ® A variant of the estimation meeting - consensus-based technique for estimating relative size or relative effort using story points for user stories in which elements of similar size are grouped or summarised. The estimation scale is often based on a modified form of the Fibonacci sequence - 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. Delphi method Individual survey of several (usually) geographically separate experts with the aim of achieving the greatest possible consensus among experts through a series of multiple rounds of independent estimates or forecasts [MOTZ17]. Analogy methods The project to be estimated is compared with one or more similar, completed projects. The estimated effort for the new project is derived from the known effort. This is of interest to companies that carry out projects with a high degree of repetition. Experience databases and key figure systems are helpful when evaluating analogous projects. Range estimation Three-point-estimate Complementary estimation and forecasting methods to increase their reliability. Three estimates are made in each case: optimistic, likely and pessimistic estimate An average value is then formed from these three values à (o + l + p) / 3 If the beta distribution is included, the formula looks like this: (o + 4 * l + p) / 6 (also PERT value taken from the network planning technique PERT = Program Evaluation and Review Technique) Parametric methods (mainly used in software development) COCOMO III (Constructive Cost Model) COCOMO III - Algorithmic model that uses mathematical functions to take into account the various parameters and factors in order to estimate the effort, duration and costs of a software development project. Very complex. Function Point Method On the basis of the required functionality, the evaluation of the functions, the quality to be provided and the necessary effort, an analogous conclusion is drawn from known, similar projects to the new project. Table 31 - Estimation methods “Work expands in direct proportion to the time available for its completion.” Cyril Northcote Parkinson (1909-1993), British sociologist who discovered Parkinson's laws 4.4 Cost and finance Cost and finance (4.5.7) ‘The competence of C OST AND FINANCE includes all activities related to estimating, planning, procuring, using and controlling financial resources, both inflows and outflows of the project.’ [GPM17a, page 131] <?page no="117"?> Page | 117 Cost planning is another task in the project planning process, in which the costs for materials, personnel, equipment and capital for the completion of the individual project tasks are determined on the basis of resource planning [MOTZ17]. Costs Unit of measurement for the consumption of production factors to create an output within a planning period, valued in money. Monetary values of the use of goods (including intangible rights and services) to create operational services or (in project management) to process specific tasks (e.g. project portfolios, programmes, projects, subtasks, work packages) [MOTZ17]. Budget Accounting or balance-sheet-related recorded amount of money needed to cover the costs. A limit to be observed of different types and different amounts for a project or a part of a project [MOTZ17]. Financial resources The total funds made available for a project. Financial (primarily liquid) funds to cover the costs of processing project tasks (e.g. project portfolios, programmes, projects, work packages, activities) [MOTZ17]. Expenses Outflow of liquid funds as well as all debt additions that arise from invoices received and lead to an increase in liabilities. Effort In project management, ‘effort’ refers to the consumption of funds and resources required to complete a task (e.g. project, subtask, work package, activity) [MOTZ17]. Table 32 - Definition of financial terms: costs, budget, effort… 4.4.1 Cost type, cost centre, cost unit 4.5.7 Cost and finance / Competence level 1 Cost type, cost centre and cost unit accounting are consecutive steps in cost accounting. The aim is to determine the prime costs per cost unit per unit or per order [WÖHE10]. Cost types Cost centres Cost units What costs have incurred? Where did the costs occur? For what were the costs incurred? For example: Material costs Personnel costs Service costs Capital costs … For example: Sales Storage Project … For example: Products Articles … Table 33 - Cost types, cost centres, cost units <?page no="118"?> 118 | Page 4.4.2 Cost planning 4.5.7 Cost and finance / Competence level 1 Cost planning has three objectives: to provide a basis for calculating the price of the product to be sold, to provide a basis for project-related controlling (plan / actual comparison) and to provide a basis for planning time-related payments. At the same time, however, the assumptions made during project selection are also verified, since project work, like any entrepreneurial activity, is subject to the primacy of economic efficiency and should thus at least contribute to ensuring the profitability of the company [PATZ17]. As mentioned at the beginning of the chapter, cost planning is based on resource planning. The costs are determined for each resource and then assigned to the work packages or activities. The total (planned) costs for the project, distributed over the project duration, are obtained in this way. Resources Amount Costs (€) Personnel Project manager (PM) 1 120.- / day Chairman (CH) 20 1 2.30 / day Chief Finance Officer (CFO) 20 1 2.30 / day Climbing instructor (CN) 1 100.- / day Office staff (OF) 1 600.- / day Volunteers (VL) 20 10 23.- / day Materials New climbing tower 360.000.- Tools, mixed calculation (average) 85.- / day Equipment Rental van 55.- / day Catering (total) 150.- / day Table 34 - Sample project: Costs of resources The costs of the resources are assigned to the individual activities. In addition, for financial planning purposes, it is determined whether the costs incurred are initially distributed (due at the start of the activity), finally distributed (due at the end of the activity) or equally distributed (due evenly during the activity. WBS Code Activity Duration (days) Effort (PD) Amount Cost (€) Distribution … … … … … M3 Quotations selected, contractor commissioned 0 20 An allowance for volunteers of € 840 per year, which has been in use in Germany since 2021, is applied here. <?page no="119"?> Page | 119 CT-22-D Preparation phase …-D1 Dismantle old tower 104 40 40 50 1 PM 1 CN 5 VL 4.800.- 4.000.- 575.- equal …-D2 Dispose of material 98 20 20 50 1 PM 1 CN 5 VL 2.400.- 2.000.- 575.- equal …-D3 Prepare the ground 189 40 40 60 1 PM 1 CN 10 VL 4.800.- 4.000.- 1.380.- equal … … … … … Table 35 - Sample project: Overview cost plan (excerpt, preparation phase) 4.4.3 Cost histogram and total cost curve 4.5.7 Cost and finance / Competence level 2 There are two types of graphical representation of the expected cost curve: the cost histogram (costs incurred per time period) and the total cost curve (cumulative costs incurred at each point in time). <?page no="120"?> 120 | Page Figure 55 - Sample project: Cost histogram and total cost curve (excerpt; preparation phase) Both types of diagrams can be used in practice as a stand-alone diagram or in conjunction with a Gantt chart. The cost histogram and the total cost curve can also be displayed simultaneously in the same diagram (with the appropriate scale) [MOTZ17]. 4.5 Contractual aspects of project work In the ICB 4, contractual aspects of project work are represented within the competence ‘procurement’. One inherent characteristic of procurement, provided it is carried out legally, is contracts (see chapter 4.5.2). Procurement (4.5.9) ‘P ROCUREMENT is an activity in which goods and/ or services are purchased or obtained from external parties. ... Since procurement is mainly aimed at suppliers outside the core organisation, resources (personnel, tools, materials and partial deliveries) are procured that are not available within the organisation.’ [GPM17a, page 140] 4.5.1 Procurement 4.5.9 Procurement / Competence level 1 Procurement or rather procurement management includes all measures to determine the consumer goods, capital goods or services required for the project and to obtain or provide them at the right time and at the best price. The basis for this can be, for example, a requirements specification, individual specifications or even the foreseeable unavailability (obsolescence) of components. The procurement process can be broken down into the following steps 1. Determining the need in the project 2. Searching for suitable suppliers 3. Requesting and obtaining offers 4. Comparing the offers received 5. Contract negotiations and conclusion 6. Placing the order <?page no="121"?> Page | 121 7. Monitoring the order process and delivery 8. Invoice processing 9. Evaluating the supplier Procurement takes place in a legal context. The procurement process can be divided into three phases: the preparation phase (the legally binding action is prepared, steps 1 to 3), the contract conclusion phase (defining the contractual conditions and concluding the contract, steps 4 to 6) and the execution phase (execution of the contractually agreed contents, steps 7 to 9). Depending on the type of contract, legal problems with different effects can occur in all three phases. 4.5.1.1 Make-or-buy decision 4.5.9 Procurement / Competence level 1 When determining the demand, it can be checked whether the demand can be purchased (‘Buy’) or produced in-house (‘Make’) (make-or-buy decision) [PATZ17]. The decision between external procurement and in-house production is a strategic consideration that depends on various factors. Criteria for a make-or-buy decision can be: Criteria Explanation Core competencies The production of the product or the provision of the service is not one of the company's core competences. Cost In-house production can be more expensive than outsourcing (due to economies of scale, specialisation, efficiency in the supply chain). Quality High quality standards may be required which the company itself cannot ensure. Resources, expertise Internal resources (e.g. labour, machine capacities, special skills) are only available to a limited extent, if at all. Flexibility, scalability Flexibility in terms of product variations or quantity changes is required. Time factors If time is of the essence, buying or adding to an existing portfolio can be the faster option. Regulatory requirements Regulatory requirements and compliance demands can influence the decision. Table 36 - Make-or-buy criteria (examples) The weighting of these criteria depends on the industry, the type of product or service and the specific circumstances of the company. A careful analysis that takes these factors into account can help with the make-or-buy decision. <?page no="122"?> 122 | Page 4.5.1.2 Types of requests 4.5.9 Procurement / Competence level 2 (Level C) The following request types are used in procurement [GUBE17, page 133] Request type Explanation RFI (Request for Information) Based on the tender documents, potential suppliers are asked whether they can provide the required services or products in general. This request is suitable for getting an overview of the potential suppliers. RFQ (Request for Quotation) After the potential suppliers have been reduced to those who can deliver the required services by means of an RFI, they receive the RFQ. This request asks for precise prices. RFP (Request for Proposal) In practice, the RFP is the most common form of request. It already contains all the information needed to conclude a contract. If a supplier / partner submits an offer based on an RFP, it is possible to conclude a contract by means of an acceptance declaration. However, there is no obligation to accept the offer. RFF (Request for Feature) This less common type of request is a request to expand an existing system or offer / contract. Table 37 - Types of request in the procurement process 4.5.2 Contracts, types of contracts 4.5.9 Procurement / Competence level 1 A contract is a multilateral legal transaction that comes about through corresponding declarations of intent by the parties involved (offer and acceptance). It contains a legally binding agreement between the parties as to which services they wish to provide and under which conditions in order to achieve the project objective. In principle, freedom of contract applies in Germany. As an integral part of general freedom of action (Art. 2 para. 1 of the German Constitution), this is protected under constitutional law. In civil law, freedom of contract means that the parties can freely determine the conclusion and content of a contract (freedom of contract and freedom of organisation). Freedom of contract is limited by the general prohibitions of unlawfulness (§ 134 BGB) and unethical behaviour (§ 138 BGB), as well as by mandatory legal provisions for consumer protection. In the course of project work, the project manager may come into contact with the following types of contract:  Sales contract (Sections 433 ff. BGB)  Works contract (Sections 631 ff. BGB)  Service contract (Sections 611 ff. BGB)  Rental contract (Sections 535 ff. BGB), which also applies to leasing contracts <?page no="123"?> Page | 123 Contract type Purpose Obligations of buyer Obligations of seller Sales contract Objects of purchase, goods • Payment of sales price • Acceptance of goods • Defect-free provision of property (goods or rights) • Handover Works contract Success, (the ‚work‘) • Acceptance • Remuneration • Production of an agreed result / work within an agreed timeframe and (mostly) at agreed cost Service contract Service, time • Remuneration • Provision of agreed services Rental contract temporary transfer for use in return for payment • Payment of the agreed rent / fee • Granting the use of the rented object Leasing contract temporary usage rights • Responsibility for maintenance and care • Payment of the agreed leasing instalments • Granting the use of investment good Table 38 - Types of contract and the resulting obligations According to DIN 69901, contract management in the context of projects includes the control [DIN20a]:  of the design,  of the conclusion,  of the updating and  of the execution of contracts 4.5.3 Default of services and performance 4.5.9 Procurement / Competence level 2 (Level C) The client and the contractor must each provide their respective services or performance within the scope of the contract, in full, on time and in the agreed quality. If one of the contracting parties fails to do so, their performance is disrupted. A default of performance corresponds to a breach of duty. This includes all forms of default of performance, e.g. non-performance, poor performance, late performance (default). In the event of a default in performance, both the client and the contractor have statutory or contractually agreed rights. Performance disruptions cannot be claimed indefinitely. Claims have an expiry date, the statute of limitations. In Germany, the regular limitation period (§195 BGB) is three <?page no="124"?> 124 | Page years, for purchase contracts two years (§634a (1) BGB) and for construction defects five years (§634a (2) BGB). The regular limitation period begins with the acceptance of the work. However, the cut-off date is always 31 December, regardless of when in the current year the claim arose (§199 (1) BGB). Figure 56 - Types of breach of contractual duties Figure 57 - Rights in the case of default 4.5.4 Acceptance 4.5.9 Procurement / Competence level 1 In both the sales contract and the works contract, the word ‘acceptance’ appears under the client's obligations. The German Civil Code (Bürgerliches Gesetzbuch, BGB) differentiates as follows: Sales contract - The client (buyer) is obliged to accept the purchased item (§ 433 para. 2 BGB). There is an obligation to accept the purchased item if it is free of third-party rights and material defects. If there is an obligation to accept the purchased item and the client does not accept the item, the buyer is in default of acceptance according to § 293 ff. BGB. A distinction is made between significant defects and insignificant defects. The client is not obliged to accept a recognizably defective item with a significant defect. Works contract - Acceptance is mandatory for works contracts (§ 640 BGB). By accepting the work, the client confirms that the services provided have been carried out in accordance with the contract and that the work ordered by the client corresponds to the contractual agreements. Once acceptance has taken place, there are numerous legal consequences: Client / Buyer  Original claim for performance expires  Remuneration falls due (§ 641 (1) BGB)  Buyer is obliged to pay interest (§ 641 (2) BGB) <?page no="125"?> Page | 125  Transfer of risk - transfer of liability to the client for the loss or damage of the item through no fault of their own (§ 644 (1) BGB)  The commencement of the limitation period for certain claims for defects  Reversal of the burden of proof - after acceptance, the onus is on the client to prove that the work is actually defective. Contractor / Seller  The commencement of the liability period for defects (§§ 634, 634a BGB) 4.6 Risk and opportunity Risk and opportunity (4.5.11) ‘The competence Risk and opportunity comprises the identification, analysis, the resulting planning and implementation as well as the control of opportunities and risks of a project. ... The management of opportunities and risks is an ongoing process that extends over the entire life cycle of the project.’ [GPM17a, page 150] 4.6.1 Risk and opportunity - basics 4.5.11 Risk and opportunity / Competence level 2 In addition to the necessity of implementing risk management due to legal (e.g. KontraG, US-GAAP, BASEL III), standardised (e.g. ISO 9001) and company-specific requirements (e.g. Corporate Governance), it is also one of the project management tasks within the project life cycle. Risk management helps to avoid, reduce or limit project risks. This range of tasks also includes promoting project opportunities, i.e. positive development possibilities. Risk management ...  improves the project manager's room for manoeuvre.  identifies and manages risks in the project.  provides an early warning system that minimises and controls risks.  recognizes opportunities for the project and shows ways to exploit them.  improves communication and the way risks and opportunities are dealt with. The word ‘risk’ is derived from the early Italian ris(i)co - a cliff that needs to be circumnavigated. DIN 69901-5: 2009 describes a risk as ‘Possible negative deviation in the course of the project (relevant hazards) compared to the project planning due to the occurrence of unplanned events or the non-occurrence of planned events or circumstances (risk factors).’ [DIN20a, page 159] The standard DIN ISO 31000: 2018 Risk Management - Guidelines is shorter. It describes a risk as ‘impact of uncertainty on objectives’ [DIN18, page 7] <?page no="126"?> 126 | Page 4.6.2 Process 4.5.11 Risk and opportunity / Competence level 2 Risk management follows the process of Identifying - Analysing - Planning - Controlling. This process is repeated at each milestone at the latest in order to determine the status of known risks and to identify new ones. Figure 58 - Risk management process I DENTIFY RISKS This is where the close connection with the environment analysis becomes apparent. Components that have already been identified in the categories of factual and direct / indirect or internal / external can be transferred directly into the risk table. The stakeholders identified during the environment analysis (categories of social and direct / indirect or internal / external) are also transferred to the risk table via the stakeholder analysis, where necessary. Various creativity techniques (e.g. brainwriting, mind mapping, headstand method, FMEA), checklists and a systematic trawl through the project plans created so far (WBS, resource plan, process and schedule plan, cost plan) are recommended for identifying further risks. Categorisation by risk type according to the PESTEL acronym already introduced in the environment analysis (  chapter 3.2.1 Environment analysis) is also helpful  Political (political risks)  Economical (economic or commercial risks)  Social (societal risks)  Technological (technical risks)  Environmental (ecological or sustainability-related risks)  Legal (laws, regulations) At this stage, all identified risks must be taken seriously - no ‘we'll manage that’ mentality - every identified risk is important enough to be considered. The identified risks are collected and structured in a table. All risks must be named and described precisely. <?page no="127"?> Page | 127 # Risk Cause(s) Classification 1 Building permit is not issued or is issued late (FF1, FF3, FF8) The lower nature conservation authority or the city's building authority has refused permission due to concerns about nature conservation or building law. Schedule risk 2 Planned self-contribution is not provided (FF2) Fewer than the planned 10 members of the association are available to help with the demolition and preparation of the site. Cost risk 3 Parts for finishing the tower are not available Delivery problems due to the COVID pandemic. Schedule risk n … … … Table 39 - Sample project: Risk table or risk register (excerpt) For better visualisation, the risks can be displayed in a portfolio. As such, they are categorised according to the damage extent (DE) and the probability of occurrence (RP) and arranged accordingly in the portfolio. For example, a qualification of the risks can be made according to ‘very high, high, low, very low’. It is recommended not to use the ‘medium’ level in order to obtain a clear statement from those involved. # Risk Cause(s) Effects RP DE 1 Building permit is not issued or is issued late (FF1, FF3, FF8) The lower nature conservation authority or the city's building authority has refused permission due to concerns about nature conservation or building law. The new construction is delayed. The fulfilment of possible requirements on the part of the authorities exceeds the project budget. low very high 2 Planned self-contribution is not provided (FF2) Fewer than the planned 10 members of the association are available to help with the demolition and preparation of the site. Internal work must be contracted out. The completion date is delayed, the project budget is exceeded. high high 3 Parts for finishing the tower are not available Delivery problems due to the COVID pandemic. Acceptance cannot take place as planned; tower will not be ready for the start of the 2022 season. high very high n … … … … … Table 40 - Sample project: Qualified risk table with RP and DE (excerpt) <?page no="128"?> 128 | Page Another possibility for a qualified assessment is the calculation of the risk priority number (RPN) as used in the FMEA. The RPN combines the assessment of the probability of occurrence with that of its impact (damage level) for each risk. The probability of occurrence and the extent of the damage are rated on scales of, for example, 1 to 10, where 1 stands for very low and 10 for very high. The higher the RPN, the higher the priority of the risk. Figure 59 - Sample project: Qualified risk portfolio (excerpt) D ESCRIBE AND ANALYSE RISKS Once the risks have been identified, they are analysed and evaluated in this phase and thus quantified. Considerations regarding the impact, the extent of the damage and the probability of occurrence must be taken into account. The risk table already in use can be supplemented with the necessary fields for this purpose. The risk value (RV) is the product of the probability of occurrence (RP) and the damage extent (DE) of the risk. RV (€) = RP (%) * DE (€) The probability of occurrence is usually determined on a scale of 0 (excluded) to 100% (certain). Regardless of whether it is determined individually or in a group, it is always a subjective value that reflects the risk preference (risk-seeking, risk-neutral or riskaverse) of the decision-makers. # Risk Cause(s) Effects RP in % DE in € RV in € 1 Building permit is not issued or is issued late (FF1, FF3, FF8) The lower nature conservation authority or the city's building authority has refused permission due to concerns about nature conservation or building law. The new construction is delayed. The fulfilment of possible requirements on the part of the authorities exceeds the project budget. 20 5.000.- 1.000. - <?page no="129"?> Page | 129 2 Planned selfcontribution is not provided (FF2) Fewer than the planned 10 members of the association are available to help with the demolition and preparation of the site. Internal work must be contracted out. The completion date is delayed, the project budget is exceeded. 30 20.000. - 6.000. - 3 Parts for finishing the tower are not available Delivery problems due to the COVID pandemic. Acceptance cannot take place as planned; tower will not be ready for the start of the 2022 season. 30 1.000. - 300. - n … … … … … … Σ Risk values 7.300. - Table 41 - Sample project: Quantified risk table with RP and DE (excerpt) The graphical representation is done with the help of a graphic similar to that of a risk portfolio. Figure 60 - Sample project: Quantified risk representation (excerpt) The risk value (expected monetary value) makes it possible to prioritise risks by providing a quantitative assessment of potential losses. By considering all relevant risks and their risk values, the project team can better decide which risks they want to address and what risk mitigation or avoidance measures should be taken. M ANAGE (plan and implement risk actions) Once the risks have been identified, their causes adequately described and the respective risk value determined, the appropriate risk strategy and the corresponding measures must be defined. <?page no="130"?> 130 | Page The risk strategy refers to the handling and design of risk management in projects. In principle, various alternative actions are available [DIN18]. A distinction is made between preventive (cause-related), corrective (effect-related) and self-supporting action alternatives. Preventive measures take effect before the risk occurs, i.e. they influence the probability of occurrence. Corrective measures reduce the impact or extent of the damage after the risk has occurred. In general, measures cost time and/ or money, so they take up resources that are only available to a limited extent. They must therefore be planned according to the chosen risk strategy. Strategy Procedure preventive measures avoid The risk is not even taken (e.g. new, unproven technology is not used). mitigate Includes all activities for directly influencing the risk by reducing the probability of occurrence (RP). Risks can be reduced by technical, organisational or personnel-related measures. corrective measures limit The consequences of a loss event are minimised. The measures only take effect when the risk has materialised (e.g. providing for redundancy). transfer The risk is transferred to third parties, for example to insurance companies, suppliers, customers, the state (e.g. an export guarantee). This transfer usually takes place by contract and is not free of charge. (e.g. risk premium for insurance). selfsupporting measures accept The risk is accepted by management and no measures are defined. These are mostly risks with a low level of damage and a low probability of occurrence. Table 42 - Risk measures and strategies Depending on the risk measure selected, either the probability of occurrence (preventive) or the amount of damage (corrective) is reduced. Both cases are also possible if both preventive and corrective measures can be applied to a risk. Figure 61 - Risk strategies <?page no="131"?> Page | 131 RP new (%) * DE(€) = RV new (€) resp. RP (%) * DE new (€) = RV new (€) A useful pointer to which of the planned measures should be implemented is that the sum of the new risk value (RV new ) plus the costs of the measure should be smaller than the old risk value. RV new (€) + costs of risk measure (€) < RW old (€) However, if the risks are deemed to be intolerable, measures must be taken in any case, even if, in extreme cases, this means not going ahead with the project. Intolerable risks are those that  pose a threat to life and limb  can cause significant environmental damage  can endanger the economic existence of the company M ONITOR AND C ONTROL (the implementation and success of risk measures) Once the measures have been planned and initiated, they must be monitored and, if necessary, controlled. Risk control is often part of project control. It is an indispensable tool for the project manager throughout the entire course of the project. The control points set by the measures (e.g. milestone, occurrence of an event, 14-day jour fixe) ensure that the risk or risks are analysed and evaluated again. The results of this review can be reflected in all project plans (e.g. resource planning, cost planning, scheduling and scheduling) and may lead to their adjustment. The current risk situation is also part of the regular project status report. “Risk management is project management for adults.” Tom DeMarco (*1940), author of (a.o.) “The Deadline” and “Waltzing with Bears” 4.7 Quality Quality (4.5.6) ‘Q UALITY in a project is based on two decisive factors. On the one hand, it is about the quality of the process, i.e. the way in which the project is organised. On the other hand, it is about managing, ensuring and controlling the quality of the project's results and performance.’ [GPM17a, page 126] The quality of a project refers to the extent to which its characteristics meet those of the project requirements. Accordingly, quality management of a project runs through all phases and project parts, from the initial project definition, management of the project team, and delivery objects to project closure. ISO 9000: 2015 takes the easy way out by defining quality as the degree to which a set of inherent characteristics fulfils requirements [DIN20f]. In this context, requirements are understood to mean the expectations of customers / interested parties, which are often recorded in a specification sheet, rough concept or catalogue of requirements. These requirements contain special characteristics that can be assigned to them (inherent characteristics). 4.7.1 Principles of quality management 4.5.6 Quality / Competence level 1 Quality management in projects addresses both the project management (project management quality) and the product to be created (product quality) and the related processes <?page no="132"?> 132 | Page (process quality). It is based on the seven principles of ISO 9000: 2015 [DIN20f]  Customer focus - Meeting the requirements of customers / interested parties is necessary for project success.  Leadership - A project manager should be appointed as early as possible. They are the person with defined responsibility and authority to manage the project and to establish, implement and maintain the project's own quality management system.  Involvement of individuals - The project team should have clearly defined tasks, competencies and responsibilities for their work on the project.  Process approach - The project processes should be defined and documented.  Improvement - The project organisation is responsible for continuously seeking improvements in the efficiency and effectiveness of the processes within its area of responsibility.  Fact-based decision making - Progress and performance reviews should be carried out to assess the status of the project.  Relationship management - The project organisation should work with its suppliers to obtain external products. “Quality means that the customer returns, not the goods.“ Hermann Tietz (1837-1907), German merchant 4.7.2 Process (tasks of quality management) Figure 62 - Quality management process Quality planning Quality planning begins with the specification of the project objectives from the requirements. The requirements can come from different sources  Customer requirements (e.g. specifications, complaints, market research and analysis)  Standards (e.g. ISO/ IEC 25000 ‘Software engineering - Quality criteria and evaluation of software products (SQuaRE) - Guidelines for SQuaRE’, DIN EN 50126 ’ Specification and demonstration of reliability, availability, maintainability and safety (RAMS)’, ISO 9000 series of standards, ISO 29993 “Learning services beyond formal education - service requirements”)  Maturity models (e.g. CMMI, SPICE) <?page no="133"?> Page | 133 Ultimately, the customer, as the project client, defines, more or less specifically, how they imagine the product and in what quality, with their specifications. Translating the customer's view into a set of specifications, i.e. the project team's perspective, is the ultimate challenge in practice. Quality Function Deployment (QFD) can provide support here. A matrix is used in the application of QFD, the ‘House of Quality’. This matrix can be used to determine and weight customer requirements, translate them into technical features and compare them with the quality characteristics [BEA19a]. Another component of quality planning is the definition of quality gates. These can be linked to milestones or represent milestones of their own, with which the achievement of certain quality requirements is associated. Quality control The purpose of quality control is to successfully implement customer requirements in the planned quality. To verify this, product quality metrics must be defined in order to carry out plan-actual comparisons as part of project controlling and to initiate appropriate measures. The ‘seven traditional tools’ from Kaoru Ishikawa offer support here - causeand-effect diagram (see chapter 7.9 ‘Versatility’), Pareto analysis, data tables, trend analysis, histograms, scatter plots and control charts [KERZ22]. Product testing can be carried out in two ways: validation 21 in the sense of ‘Does the product actually meet customer needs? ’ and verification 22 in the sense of ‘Does the product meet the specified requirements from the specifications? ’ In both cases, objective evidence must be provided [BEA19a]. Other useful quality tools for detecting errors and analysing problems are:  7W checklist (KAIZEN tool) helps to identify and eliminate unproductive and nonvalue-adding activities (waste). It is based on the seven question words who, what, where, when, why, how and why: o Who is doing it? o What is being done? o Where is it being done? o When is it being done? o Why are they doing it? o How are they doing it? o Why aren't they doing it differently?  Quality circle PDCA (Plan - Do - Check - Act). The PDCA cycle or Deming quality circle describes an iterative four-phase problem-solving process for continuous improvement (see chapter 4.7.3 ‘Deming Cycle’)  FMEA (Failure Mode and Effects Analysis) - FMEA is a largely formalised analytical method for the systematic recording and analysis of possible failures with the aim of preventive quality assurance (see chapter 7.9 ‘Resourcefulness’). 21 DIN ISO 9000: 2015 ‘Confirmation through the provision of objective evidence that the requirements for a specific intended use or a specific intended application have been fulfilled.’ 22 DIN ISO 9000: 2015 ‘Confirmation through the provision of objective evidence that specified requirements have been fulfilled.’ <?page no="134"?> 134 | Page Quality assurance Quality assurance is not exclusively a project matter, but is closely linked to the processes of the company's quality management system. The development of appropriate structures must be accompanied by the anchoring of the topic ‘quality’ in the corporate and project culture [BEA19a]. Project reviews and project audits can be used as quality assurance tools.  Project review Analytical quality assurance measure that determines the project's status in terms of performance, deadlines and costs. In the project review, the achieved project results are analysed, the course of the project is evaluated and influencing factors and problems are discussed. The current project status is subjected to a critical review. The target-actual comparison is based on the project specifications (contracts and specifications), the project planning and the project update (project file); it is intended to identify deviations and possible control measures [GPM17b].  Project audit Project analysis on a specific date, carried out by an independent auditor. The subject, objective and content are defined in advance. It is used in problem cases to check results, risks or weak points [GPM17b]. Quality improvement Quality improvement involves the continuous improvement of the ability to meet quality requirements. An important part of this is the safeguarding of experience at the end of the project or after each milestone has been reached (lessons learned, alternatively  chapter 8.1.3.5 Retrospective) and the corresponding access to the information. Project management audits can be carried out to improve the project management system of the project-leading organisation and to support organisational learning.  Project management audit Systematic and independent examination, usually at the end of the project, to determine whether the procedure and the associated results correspond to the planned processes and specifications (basis: PM manual). Furthermore, it should be determined whether the planned processes are suitable for achieving the objectives. The PM audit shows the o appropriateness, adequacy and sufficient effectiveness of the PM system, o sufficient documentation of the PM measures, o fulfilment of the requirements of the PM manual, o organisational weaknesses and defines measures for system improvement. Auditing project management as such is also the subject of maturity models, such as  Capability Maturity Model Integrated (CMMI),  Software Process Improvement and Capability Determination (SPICE)  Project Management Maturity Model (PMMM), or  Organisational Project Management Maturity Model (OPM3) In practice, quality management produces costs in order to reduce overall costs. These (quality) costs must be taken into account in the cost planning and must be tracked and specifically controlled as part of the project controlling. <?page no="135"?> Page | 135 4.7.3 Deming cycle 4.5.6 Quality / Competence level 1 The PDCA cycle (Plan - Do - Check - Act) or Deming cycle, named after W ILLIAM E DWARDS D EMING , describes an iterative four-phase problem-solving process for continuous improvement [AS-SE14, SCHM15]. Term Meaning Plan Analysis of the current situation; definition of specific goals and selection of suitable methods and strategies for achieving these goals. Do Implementation of the defined methods and strategies to achieve the objectives and to fulfil the quality requirements. Check Review of the current situation in comparison to the defined objectives from the planning phase (Plan) ̶ ̶ Evaluation of progress towards achieving objectives. Act Based on the new data, decide whether the objectives have been achieved or whether the Do and Check steps need to be repeated to enable continuous (quality) improvement. Table 43 - PDCA explanation Continuous improvement process vs. Lessons Learned CIP 23 is a principle of continuous improvement. It involves the recurring search for the causes of problems and their elimination in order to continuously improve all systems in a company. In terms of project management, the focus is on the permanent improvement of PM processes and activities within the organisation [MOTZ17]. A lessons learned workshop is used to ensure that the experience gained in the project (e.g. technical knowledge, process experience) and the knowledge acquired are made available for future projects [PATZ17, PFET20]. 4.7.4 Acceptance criteria 4.5.6 Quality | 4.5.2 Requirements and objectives / Competence level 1 Acceptance criteria are a set of conditions agreed between the client and the contractor that must be met before the deliverables are accepted. Meeting all acceptance criteria implies that the stakeholders' needs have been met [IEEE90, PMI21a, MOTZ17]. 23 German: KVP = Kontinuierlicher Verbesserungsprozess Figure 63 - Deming cycle (PDCA) <?page no="136"?> 136 | Page Release vs. Acceptance A release is the ‘permission to carry out subsequent work with defined content.’ [DIN20a, page 152]. It represents the confirmation of an event by an authorised person (e.g. project manager, client) or group of persons (e.g. steering committee). The acceptance marks the completion of project steps. According to DIN 69901-5, acceptance testing represents a business decision by the client that a result meets the agreements and can therefore be used for subsequent processes [DIN20a]. ‘Acceptance criteria’ are also used in an agile environment. They are defined from the stakeholder's perspective for each user story and describe a desired behaviour. The Definition of Done is often confused with the acceptance criteria. The DoD is a checklist of the steps that must be successfully completed at the end of a sprint for the work to be declared potentially shippable. The DoD must therefore be completed before acceptance based on the acceptance criteria is carried out (see also chapter 8.1.4) [RUBI 14]. 4.8 Literature [ANGE12] Angermeier, G. (9. Nov. 2012). Ressource, Definition im Projektmanagement-Glossar des Projekt Magazins. Abgerufen am 28. Mai 2018 von Projekt Magazin - Das Fachportal für Projektmanagement: https: / / www.projektmagazin.de/ glossarterm/ ressource [ASSE14] van Assen, M., van den Berg, G., & Pietersma, P. (3. Aufl. 2014). Key Management Models. Harlow: Pearson Education. [BEA19a] Bea, F. X., Scheurer, S., & Hesselmann, S. (3., vollst. überarb. u. erweit. Aufl. 2019). Projektmanagement. Konstanz: UVK Verlagsgesellschaft GmbH. [BERG21] Bergmann, R., & Garrecht, M. (3., aktual. und erweit. Aufl. 2021). Organisation und Projektmanagement. Wiesbaden: Springer Gabler. [DIN20a] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. DIN 69901-5 Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH [DIN20b] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. ISO 21500 Leitlinien Projektmanagement (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH [DIN20e] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. DIN 69900 Projektmanagement - Netzplantechnik; Beschreibungen und Begriffe (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH <?page no="137"?> Page | 137 [DIN20f] DIN Deutsches Institut für Normung e.V. (11. Aufl. 2020). Qualitätsmanagement. QM-Systeme und -Verfahren. DIN EN ISO 9000: 2015 Qualitätsmanagementsysteme - Grundlagen und Begriffe (Bd. DIN Taschenbuch 226). Berlin: Beuth Verlag GmbH [DIN18] DIN Deutsches Institut für Normung e.V. (2018). DIN ISO 31000: 2018- 05 Risikomanagement - Leitlinien. Berlin: Beuth Verlag e.V. [GPM17a] Deutsche Gesellschaft für Projektmanagement e.V., (Hrsg.). (1., aktual. Aufl. 2017). Individual Competence Baseline für Projektmanagement, Version 4.0 / Deutsche Fassung (Bd. 1). Nürnberg: Deutsche Gesellschaft für Projektmanagement e.V. (GPM) [GPM17b] GPM, SPM, & Gessler, M. (Hrsg.). (8. Aufl. 2017). Kompetenzbasiertes Projektmanagement (PM3): Handbuch für die Projektarbeit, Qualifizierung und Zertifizierung auf Basis der IPMA Competence Baseline Version 3.0. Nürnberg: GPM Deutsche Gesellschaft für Projektmanagement e.V. [IEEE90] Institute of Electrical and Electronics Engineers (Hrsg.). (1990). IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology. New York. [KERZ22] Kerzner, H. (13. Aufl. 2022). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. Hoboken, New Jersey: Wiley [LITK05] Litke, H.-D. (Hrsg.). (2005). Projektmanagement - Handbuch für die Praxis. Konzepte - Instrumente - Umsetzung. München: Hanser Fachbuchverlag. [MOTZ17] Motzel, E., & Möller, T. (3., überarb. u. aktual. Aufl. 2017). Projektmanagement Lexikon: Referenzwerk zu den aktuellen nationalen und internationalen PM-Standards. Weinheim: Wiley-VCH Verlag [PATZ17] Patzak, G., & Rattay, G. (7., überarb. Aufl. 2017). Projektmanagement: Leitfaden zum Management von Projekten, Projektportfolios und projektorientierten Unternehmen. Wien: Linde Verlags GmbH [PFET20] Pfetzing, K., & Rohde, A. (7., vollst. überarb. Aufl. 2020). Ganzheitliches Projektmanagement. Wettenberg: Verlag Dr. Götz Schmidt. [PMI21a] Project Management Institute Inc. (7 th Edition 2021). A guide to the Project Management Body of Knowledge und Die Norm für Projektmanagement. Pennsylvania: PMI Inc. [RUBI14] Rubin, K. S. (2014). Essential Scrum - Umfassendes Scrum-Wissen aus der Praxis. Frechen: mitp Verlag. [SCHM15] Schmitt, R., & Pfeifer, T. (5., aktual. Aufl. 2015). Qualitätsmanagement - Strategien - Methoden - Techniken. München: Carl Hanser Verlag [WÖHE23] Wöhe, G., & Döring, U. (28. Aufl. 2023). Einführung in die Allgemeine Betriebswirtschaftslehre. München: Verlag Franz Vahlen. <?page no="139"?> Page | 139 5 Controlling phase Figure 64 - ICB elements in the controlling phase With regard to the project content, the kick-off marks the start of the realisation phase. During this event, the project, its objectives, planning and the chosen organisational form are presented to the participants. After a discussion, everyone commits to implementing the project according to the specifications. During the kick-off, the first steps towards team building and development are already being taken [GPM17b]. At the same time, the project is now being managed at the ‘project management’ level. This includes, among other things, the instruments of project controlling and change management. 5.1 Project controlling Plan and control (4.5.10) ‘On the basis of the design, all elements are brought together in a balanced plan, the execution of which is monitored. Based on changes that arise in the course of the project or in the project context, the P LAN should be regularly updated. The C ONTROL is also regularly adapted and improved so that individuals retain control.’ [GPM17a, page 144] Controlling the project is a permanent task of the project manager. To achieve the project goals, they must be informed about the respective project status, recognize risks in good time and, if necessary, initiate appropriate measures. They are supported in this by the project controller, who ensures the necessary transparency of the data [LITK05, FIED20]. <?page no="140"?> 140 | Page Figure 65 - Task division between project manager and project controller Project controlling, as a subtask of project management, begins at the project planning stage, as does quality management. There, it sets the course for effective subsequent project monitoring and control and thus for ‘ensuring the achievement of all project objectives.’ [DIN20b, page 156] The following work steps are part of project controlling, in accordance with the controlling cycle [MOTZ17]:  Objective - corresponds to the definition of the project's objectives  Planning - corresponds to the project planning (phase plan, WBS, resources, costs, etc.)  Recording the actual data  Comparing and evaluating the actual data with the planned or target data, creating forecasts, identifying trends  Conducting the deviation analysis and creating proposals for correction,  Planning, implementing and controlling the corrective measures  Monitoring success to determine whether the measures taken have actually solved the problem 5.1.1 Progress measurement 4.5.10 Plan and control / Competence level 1 When recording the progress of the performance, the work status of those activities or work packages that  have not yet been started  have already been completed  are in progress on the key date must be determined. For the first two, this is quite simple - 0% or 100% - for the third case, progress must be determined using measures. The following methodological tools can be used for this [PATZ17]. <?page no="141"?> Page | 141 Method of progress measurement Explanation Remarks rather objektive 0 - 100 The progress rate remains at ‘0%’ until the work package is completed. There are no intermediate steps. Simple, inaccurate, only suitable for tasks of relatively short duration (< than reporting cycle) with low project risk; little effort required to record progress. 50 - 50 The work package receives a progress rate of 50% from the start. The remaining 50% are only booked after completion. There are no intermediate steps. Simple, suitable for tasks with extensive preparatory work and low project risk; little effort required to record progress. Quantity proportionality The progress rate is determined according to the quantity consumed, the number of units completed, etc. Suitable for measurable or countable performance content or results, therefore of limited use. Status step method Measuring progress on the basis of previously defined partial delivery objects of the work package to which corresponding values for the progress rate are assigned. Also known as micro-milestones, these can be specified in as much or as little detail as you like, depending on the definition and number of status steps. Secondary proportionality Suitable for work packages whose progress rate cannot be determined, or only to an insufficient extent, due to dependencies on other project tasks. Complex, suitable for accompanying ‘overhead’ (e.g. QA, tests, machine use), specially applicable. rather subjective Time proportionality The progress rate is determined based on the elapsed time in relation to the planned duration of the work package. Only of limited use, as it is independent of the power supplied. Estimation Estimates are always based on the subjective assessment and judgement skills of the person making them. They are therefore not recommended as a general progress rate measurement technique. Only conditionally applicable  90% syndrome Table 44 - Methods for progress measurement <?page no="142"?> 142 | Page The actual progress rate (often also referred to as the degree of completion, or Percentage of Completion PC) is then calculated as the quotient of the actual performance and the total performance. It serves as a neutral measure of the result at the reporting date and is independent of the time and effort required for it [DIN20a]. Actual progress rate (PC act ) = actual output / total planned output * 100 Rather than just estimating past performance, it is better to determine the performance still to be delivered in a prospective manner. Actual progress rate (PC act ) = actual output / (actual output + estimate to complete) * 100 The estimated total output is determined by realistically estimating the remaining work for the work packages still to be completed and adding the work already completed. Remaining work is the effort still required to fully complete the work package or activity (Estimate to Complete). 5.1.2 Integrated project controlling Integrated project controlling involves a holistic approach to the project's target figures - time, costs and scope - and their analysis as a good basis for decision-making for the project manager. This avoids isolated measures being taken to achieve one target figure, with correspondingly negative effects on the others. The reason for taking an integrated approach to the figures in the magic triangle is to  obtain a picture of the actual project status on a specific date  allocate the corresponding costs to the progress of the work  determine deviations from the plan  take appropriate control measures  be able to identify changes to the project objectives if necessary Figure 66 - Integrated project controlling The main methods: Earned Value Analysis, Milestone Trend Analysis and Cost Trend Analysis are presented in the following chapters. <?page no="143"?> Page | 143 5.1.2.1 Earned Value Analysis (EVA) 4.5.11 Plan and control / Competence level 1 Earned Value Analysis (EVA) is a method that takes all three target values (dates, costs, scope) into account at the same time, thus providing a differentiated picture of the project as of the reporting date. In this process, the performance is expressed in costs and recorded in relation to time [BEA19b, PMI21a, WANN20]. Earned Value Analysis refers to the following variables:  Plan costs (PC) or Planned Value (PV) - correspond to the costs of the current planning. They apply for the entire duration of the project and are only adjusted if there is a change to the project scope, e.g. via a change request.  Actual costs (AC) - these are the actual costs incurred up to the reporting date. Actual costs are therefore based on past data.  Earned value (EV) - this is the value of the work performed as of the reporting date based on the planned (budgeted) costs. The following formulas are used for the calculation: Progress rate or percentage of completion (POC) - ratio of the work completed on a particular day to the total planned work, for example of a process, work package (WP) or project. The work can be specified in person-hours, person-days or quantities. The corresponding methods from chapter 5.1.1 are used to determine the progress rate per work package / process. The project's progress rate (with the weighted degree of completion of the work packages) is calculated as follows POC project = Σ (POC work package * BAC work package ) / BAC project *100 or POC project = Σ (EV work package ) / BAC project *100 Earned Value (EV) - Value that results from the extent of completion of the project on a specific reporting date. Earned value (EV) = Budget at completion (BAC) * POC project With the given variables (planned total costs, actual costs) and the calculated earned value, a forecast of the potential total costs of the project at the planned end of the project or of a subtask, work package or activity upon its completion can be calculated as of the reporting date (Estimate completion). The Estimate at Completion (EAC) or can be forecast in three ways - additive, linear and plan-based. These each imply a prediction or assumption about the further course of the execution of the project work [PATZ17, GPM17b]. Additive forecast - it is assumed that the deviation originates from a clearly identified work package, but that the rest of the project is on track and will continue to be so, i.e. future performance will proceed according to plan. Additive Estimate at Completion (EAC add ) = BAC + AC - EV <?page no="144"?> 144 | Page Linear forecast - it is assumed that the deviation was caused not only by one work package, but by several, and that the project will continue in the same way until the end of the project. Linear Estimate at Completion (EAC lin ) = BAC * AC / EV Plan fulfilment - it is assumed that, despite cost overruns, the planned costs can ultimately be adhered to by means of suitable control measures. Plan Estimate at Completion (EAC plan ) = BAC The following example (reporting date: day 20) shows how the calculations are applied. Table 45 - Planned and actual costs as per reporting date (example) Progress rate (percentage of completion) POC project = Σ (POC work package * BAC work package ) / BAC project  41.500.- € / 117.800 € = 35 % Earned Value Earned value (EV) = BAC project * POC project  117.800.- € * 35% = 41.500.- € Forecasts Linear forecast EAC lin = BAC * AC / EV  117.800.- € * 50.000.- € / 41.500. - € = 141.928.- € Additive forecast EAC add = BAC + AC - EV  117.800.- € + 50.000.- € / 41.500.- € = 126.300.- € Due date 5 10 15 20 PC 0 € 6.000 € 13.500 € 20.000 € PC (cumulated) 0 € 6.000 € 19.500 € 39.500 € AC 0 € 9.000 € 16.500 € 24.500 € AC (cumulated) 0 € 9.000 € 25.500 € 50.000 € <?page no="145"?> Page | 145 Figure 67 - Earned Value Analysis (example) Key abbreviations and definitions for the Earned Value Analysis: Abbr. Definition Calculation scheme German abbr. BAC Budget at completion PGK (Projektgesamtkosten) AC Actual costs IK PC/ PV Planned costs (on reporting date) Planned value (on reporting date) PK POC Percentage of completion - the ratio of the work performed as of the reporting date to the total work in an activity or project, expressed as a percentage (%) POC = actual output / total output FGR (Fortschrittsgrad) EV Earned value - the costs of an activity or project corresponding to the degree of completion. EV = POC * BAC FW (Fertigstellungswert) EAC Estimate at completion - the expected total costs. Usually, three values are calculated to back up the forecast: the pessimistic (linear), the planned (additive) and the optimistic (plan fulfilment) value. Linear forecast: EAC lin = BAC * (AC / EV) Additve forecast: EAC add = BAC + AC - EV Plan fulfillment: EAC = BAC EGK (erwartete Gesamtkosten) <?page no="146"?> 146 | Page Schedule analysis SPI Schedule performance index - a measure of the time variance between the work completed to date and the planning. SPI > 1 means ahead of schedule; SPI < 1 means behind schedule (How efficiently are we using time? ) SPI = EV / PV ZK (Zeitplan- Kennzahl; Termintreue) SV Schedule Variance - ahead of or behind schedule; SV > 0 ahead of schedule, SV < 0 behind schedule (Are we ahead of schedule or behind? ) SV = EV - PV In percent: SV % = SV / PV PA (Planabweichung) Cost analysis CPI Cost performance index - indicates the efficiency of the services provided to date. CPI > 1, the costs for the services provided are lower than originally planned. CPI < 1, the costs are higher than originally planned. (How efficiently are we using our resources? ) CPI = EV / AC EF (Effizienz- Faktor); Kostentreue CV Cost variance - over or under budget; CV > 0 under budget, CV < 0 over budget (Are we over or under budget? ) CV = RV - AC In percent: CV % = CV / EV KA (Kostenabweichung) Table 46 - Earned value analysis: abbreviations, definitions, calculation formulas 5.1.2.2 Milestone trend analysis (MTA) 4.5.10 Plan and control / Competence level 1 While networked Gantt charts or network diagrams provide a static snapshot of the project situation, the MTA can be used to show how a planned date changes over time. The milestone trend analysis is therefore an important tool for analysing the milestone dates of the project or a project phase. The basis for this is the regular recalculation of the project plan on a key date basis, based on the progress rate of the work packages [PATZ17, PFET20]. The aim is to make trend statements about whether the planned milestone dates can be met, whether delays are to be expected, or whether the milestones may be reached ahead of schedule. The results are displayed in the milestone trend diagram, with the reporting dates on the horizontal axis and the planned end dates of the milestones on the vertical axis [MOTZ17]. <?page no="147"?> Page | 147 Figure 68 - Milestone trend diagram The planned dates of the individual milestones are updated on the reporting dates. The resulting progressions can be used to draw conclusions about the possible course of the project  horizontal progression - adherence to the deadline  rising progression - indicator for missing the deadline  falling progression - indicator for possibly missing the deadline [BEA19b, PATZ17, PFET20] 5.1.2.3 Cost trend analysis (CTA) 4.5.10 Plan and control / Competence level 1 The cost trend analysis (CTA) complements the milestone trend analysis (MTA) by considering the estimate at completion (EAC) for the project at defined reporting times. The aim is to be able to make trend statements about whether the original planned total costs (BAC) are likely to be met at the end of the project, or whether cost overruns or underruns are to be expected [GPM17b]. The expected total costs (EAC) are either estimated or determined using an Earned Value Analysis and displayed over time with the help of a cost trend diagram. The interpretation corresponds to the system already presented for the milestone trend analysis  horizontal line - adherence to the originally planned costs  rising line - indicator for exceeding the originally planned costs  falling line - indicator for falling below the originally planned costs [BEA19a] <?page no="148"?> 148 | Page Figure 69 - Cost trend diagram (example) 5.1.3 Control measures Once the corresponding trends have been interpreted and future values have been forecast based on the preceding analyses, corrective measures for the deviation can now be planned, decided on and implemented. Since measures are usually associated with costs, it is important to ensure that their success is greater than the associated effort. In this case, knowledge of possible control variables and their effects prevents ‘blind’ actionism. Figure 70 - Measures of project controlling The variables in the project can be [GPM17b]  Resources - Increasing or changing the resources in the form of additional or betterqualified employees leads to an increase in costs  Effort - Reducing your own efforts by eliminating unnecessary effort leads to an improvement in the schedule and possibly reduces costs <?page no="149"?> Page | 149  Productivity - Measures have a delayed effect, require additional effort, and can be taken in parallel with other measures  Scope of services - rescheduling, reprioritisation and/ or cancellation of planned services, must be carefully planned and agreed with the client  Process quality - ‘improved climate’ through communication and project marketing to improve relations with the project environment and cooperation among project participants. 5.2 Reporting in the project - the status report 4.5.10 Plan and control / Competence level 1 A report on the progress of the project gives the stakeholders, in particular the project client, an overview of the progress and the current status of the project. In addition, it draws attention to project-relevant developments. This report is often referred to as a project status report [GUBE17]. Depending on what was planned as part of the stakeholder communication or requested by the client, the project must create corresponding reports in weekly, monthly or quarterly cycles. The content of the status report includes, for example:  statements on project progress  the schedule (if necessary also as a traffic light display)  the development of costs (if necessary also as a traffic light display)  pending and necessary decisions  overview of the status of the most important project risks  overview of the quality objectives  status of the corrective measures implemented  dependencies on topics / results outside the project  requests, e.g. change requests The so-called header data such as project name and number, report date, report number (if applicable) and author should not be forgotten. If traffic lights are used to indicate the status, the meaning of the colours should be clear to all parties involved. Deadlines Costs The project is at high risk of missing the deadlines. The planned costs will be significantly exceeded. Individual deadlines cannot be met; measures have been defined to ensure that the final deadline is still met. The planned costs are currently being exceeded; measures have been defined to ensure that the overall project budget is sufficient. The deadlines can be met with the available resources. The costs can be met with the available resources. Table 47 - Traffic light explanation in a status report for deadlines and costs (example) <?page no="150"?> 150 | Page The escalation process for the overall project must also be clearly defined: Overall project Project plan and/ or project objectives are not met, results cannot be used, deviations cannot be resolved by the team Escalation to steering committee, management or line management. The project plan and/ or project objectives are not met, project results are of limited use; deviations can only be regulated by additional special measures in the team. No need for action, project plan and/ or project goals are being met. Table 48 - Traffic light explanation for overall project status in a status report (example) However, status reports are no substitute for a personal conversation. Regular bilateral status discussions with the project client and the project team are therefore essential. 5.3 Configuration management and change management 4.5.10 Plan and control / Competence level 1 The areas of configuration management (CM) and project management have increasingly merged in recent years. Configuration management is often associated with the creation of products or IT services 24 , but less so with project management. However, it is important to understand that configuration management is a crucial tool in project management. It ensures through a systematic process that incompleteness and errors in technical documentation and approval in technical planning are minimised. During the course of a project, changes are subjected to a formal approval process with the help of configuration management. This process makes the effects of changes on time, costs and performance transparent. Change management is an integral part of configuration management and includes the steps of identification, assessment, approval, documentation, introduction and control of a change [DIN20c, GPM17b]. An essential prerequisite for this is a predefined configuration baseline. Before a change is approved, its purpose, scope and effects (e.g. on deadlines, costs, performance, contracts, risk, etc.) should be analysed. Changes can be approved at different levels. For example, changes at the work package level can be coordinated between the person responsible for the work package (WPO) and the project manager (PM). If the overall project is affected (e.g. a postponement of 4 weeks, 10% higher project costs), the project manager must inform the steering committee (SC) and obtain approval from them. 24 e.g. IT Infrastructure Library (ITIL), Service Transition Process: Service Asset and Configuration Management <?page no="151"?> Page | 151 If changes have a significant impact on the agreed objectives, the project organisation or the end date (e.g. a delay of more than three months) and the planned total costs (e.g. more than 25%), approval must be obtained from the management or the corresponding client [BEA19a]. Since changes can have a negative impact on the project, it is crucial to recognize them as early as possible.The basic assumption should be that only what has been approved beforehand is implemented or changed. A completed and signed change request has proven useful for this [PATZ17]. Project Change Request No. Product change Process change Documentation change *Applicant Date: Change description (current status, change proposal, reason): Target date: Estimated cost: Request review Project manager: Effect on product features, deadlines, cost yes no Date / signature: Date / signature: Information to customer required yes no Comments requested Date / signature: Change decision no change (denied) execute change Change date (plan): Date / signature: Change cost (plan): Budget (current): New total (plan): Change date (plan): Date / signature: <?page no="152"?> 152 | Page Change execution Date / signature: Product documentation revised Date / signature: Process documentation revised Date / signature: Project documentation updated Date / signature: Customer release available Date / signature: Change takes effect: Confirmation of effectiveness yes, effective Date / signature: no, correctve action required Table 49 - Change request (example) 5.4 Literature [BEA19a] Bea, F. X., Scheurer, S., & Hesselmann, S. (3., vollst. überarb. und erweit. Aufl. 2019). Projektmanagement. Konstanz: UVK Verlagsgesellschaft GmbH. [DIN20a] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. DIN 69901-5 Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH [DIN20b] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. ISO 21500 Leitlinien Projektmanagement (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH [DIN20c] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. ISO 10006 - Qualitätsmanagementsysteme - Leitfaden für QM in Projekten. Berlin: Beuth Verlag GmbH. [FIED20] Fiedler, R. (8., aktual. und überarb. Aufl. 2020). Controlling von Projekten: Mit konkreten Beispielen aus der Unternehmenspraxis. Wiesbaden: Springer Vieweg. [GPM17a] Deutsche Gesellschaft für Projektmanagement e.V., (Hrsg.). (1., aktual. Aufl. 2017). Individual Competence Baseline für Projektmanagement, Version 4.0 / Deutsche Fassung (Bd. 1). Nürnberg: Deutsche Gesellschaft für Projektmanagement e.V. (GPM) <?page no="153"?> Page | 153 [GPM17b] GPM, SPM, & Gessler, M. (Hrsg.). (8. Aufl. 2017). Kompetenzbasiertes Projektmanagement (PM3): Handbuch für die Projektarbeit, Qualifizierung und Zertifizierung auf Basis der IPMA Competence Baseline Version 3.0. Nürnberg: GPM Deutsche Gesellschaft für Projektmanagement e.V. [GUBE17] Gubelmann, J., Scherler, H., & et al. (4., kompl. überarb. Aufl. 2017). Projektmanagement - Zertifizierung nach IPMA (ICB4)-Ebenen D und C. Zürich: Compendio Bildungsmedien. [LITK05] Litke, H.-D. (Hrsg.). (2005). Projektmanagement - Handbuch für die Praxis. Konzepte - Instrumente - Umsetzung. München: Hanser Fachbuchverlag. [MOTZ17] Motzel, E., & Möller, T. (3., überarb. und aktual. Aufl. 2017). Projektmanagement Lexikon: Referenzwerk zu den aktuellen nationalen und internationalen PM-Standards. Weinheim: Wiley-VCH Verlag [PATZ17] Patzak, G., & Rattay, G. (7., überarb. Aufl. 2017). Projektmanagement: Leitfaden zum Management von Projekten, Projektportfolios und projektorientierten Unternehmen. Wien: Linde Verlags GmbH [PFET20] Pfetzing, K., & Rohde, A. (7., vollst. überarb. Aufl. 2020). Ganzheitliches Projektmanagement. Wettenberg: Verlag Dr. Götz Schmidt. [PMI21a] Project Management Institute Inc. (7 th Edition 2021). A guide to the Project Management Body of Knowledge und die Norm für Projektmanagement. Pennsylvania: PMI Inc. [WANN20] Wanner, R. (V1.1, 2020). Earned Value Management: Die wichtigsten Methoden und Werkzeuge für ein wirkungsvolles Projektcontrolling. Luxembourg: Amazon Media EU S.à.r.l. <?page no="155"?> Page | 155 6 Closure phase Figure 71 - ICB elements in the project closure phase Project closure is part of the ICB element P LAN AND CONTROL , which has already been described in chapter 5, the control phase. This chapter also includes a competence element from C OMPLIANCE , STANDARDS AND REGULATIONS (see chapter 1.6 Standards in project management), which thematically complements project closure. 6.1 Project closure 4.5.1 Project design | 4.5.10 Plan and control / Competence level 1 Projects are temporary ventures. It is therefore important to bring a project to a visible conclusion for all stakeholders. The completion phase should follow certain formalities and have the following objectives: [KERZ22]  to bring the project to an end in accordance with the contractual agreements  to analyse the project performance (post-calculation, profitability analysis)  to collect and analyse experiences during the project (lessons learned)  to return the resources (people, machines, material)  to dissolve the project organisation  to create a final report Unfortunately, experience shows that project closure tends to be neglected. Projects ‘fray out’, they are finished for some employees but not for others. Cost centres are not closed, so that hours and expenses can continue to be booked to the project [PATZ17]. This ‘behaviour’ can often be observed in unsuccessful projects. In this case, neither the project manager nor management wants to face the truth that the project has failed. It is better to let it ‘fade out’. However, the failure to systematically complete a project also happens to projects that can be described as successful. Reasons for this may be: <?page no="156"?> 156 | Page  the project team postpones the end of the project with all kinds of additional tasks because they don't know what will happen to them after the project ends  there is no interest in systematic project closure because the benefits are not seen and the process is perceived as mere formalism  no clear definition of objectives was set out at the beginning of the project, and thus the conditions for project closure are missing  that management's interest in the project wanes with the delivery of the project results, it no longer enjoys the original priority and thus the final meeting is pushed further and further back until the project dissolves by itself, so to speak, because all employees are already busy with new projects [BEA19a]. Process Figure 72 - Project closure process Acceptance The product acceptance phase is divided into the activities of handing over the product, its review, clarifying the support after the project ends and the actual takeover. In this context, the product is understood to be the project result formulated in the project order. The documentation is provided in the product acceptance report [GPM17b]. This report marks the legal end of the project. The resulting consequences can be found in chapter 4.5.4 Acceptance (definition) Final analysis During the final analysis, a post-calculation and a profitability analysis are carried out. By means of a deviation analysis, the causes of any deviations identified with regard to costs, deadlines, scope and quality are analysed. The actual costing is used to determine the economic success of the project by compiling all relevant commercial data and comparing it with the planning specifications. This information is part of the final project report and also provides input for the experience feedback phase [DIN20a, PATZ17]. The profitability analysis in this phase is a target / actual comparison with the profitability calculation at the beginning of the project. This involves collecting all expenses for planned and unplanned services and presenting the deviations from the original plan. The focus can be on the return on investment, the rationalisation effect achieved or the <?page no="157"?> Page | 157 increase in productivity. However, the comparison can only be successful if the target values are defined at the beginning of the project and the corresponding actual data is then collected continuously [GPM17b]. The following questions provide support for post-calculation and profitability analysis [KERT03]  What did the project actually cost?  How many employees were actually involved?  How long did it actually take?  When did the employees actually start and when did they stop or leave the project?  How much work did the team actually do?  What level of quality did the project actually achieve?  How do costs and deadline estimates compare to the actual results? All deviations uncovered are examined in the deviation analysis for their causes. The division of causes into technical, organisational and personnel (TOP), as well as into avoidable, hardly avoidable and unavoidable causes, has proven useful [BEA19a]. Table 50 - Causes for deviations (example) All results are compiled in the analysis report. Knowledge preservation (lessons learned) In the lessons-learned phase, experiences should be systematically collected, documented, processed and made available for use in future projects. This also includes the key figures collected during the analysis and the documents created in the course of the project, which must be archived in a suitable form. These lessons learned, or retrospectives, are the basis for avoiding mistakes in future projects. The results are presented in the lessons learned report. The following questions can be helpful for collecting project experiences [PATZ17]:  What has each participant learned from the project for themselves?  Which results are important for the organisation as a whole?  Which positive experiences can be applied to other projects?  What should be done differently in future projects? Causes Technical Organisational Personnel Avoidable causes Infrastructure not available in time Conflicts of competence Lack of qualification Hardly avoidable causes Missing test cases Competition from other projects Fluctuation Unavoidable causes Fire in a part of the building Change in company management Accident <?page no="158"?> 158 | Page In order for the experience to be secured successfully and effectively, a secure basis in terms of trust must exist. Only in such an atmosphere will the project participants be able to discuss their work and possibly better ways of doing it. The project manager should create and live this culture of trust during the project. A prerequisite for this would be a constructive culture of error and learning in the company, in which errors are part of learning and do not lead to the end of a career or to sanctions. Lessons learned process Figure 73 - Lessons learned As already mentioned, the lessons learned from the project experience will exclusively benefit future projects. From the company's point of view, it is therefore an important resource for the further development of company-wide project management and input for organisational learning [BEA19a]. Project closure The last step in the closure phase and thus in the entire project process is project termination. The activities of project closure are [GPM17b]:  Create the final report and make it available to the client and the members of the established project committees (e.g. steering committee, expert and working groups)  Conduct final meeting(s) with the established project committees and presentation of the project results incl. final analysis  Transfer project personnel to new tasks  Dispose, recycle or utilise project resources  If necessary, have the project removed from the project portfolio The project closure report integrates the product acceptance report, the analysis report and the experience report, as well as the results of the last phase of project closure. <?page no="159"?> Page | 159 6.2 Literature [BEA19a] Bea, F. X., Scheurer, S., & Hesselmann, S. (3., vollst. überarb. u. erweit. Aufl. 2019). Projektmanagement. Konstanz: UVK Verlagsgesellschaft GmbH. [CARB18] Carboni, J. B., & Duncan, W. (2. Aufl. 2018). Sustainable Project Management: The GPM Reference Guide. Novi (MI): GPM Global [DIN20a] DIN Deutsches Institut für Normung e.V. (4. Aufl. 2020). DIN-Normen im Projektmanagement. DIN 69901-5 Projektmanagement - Projektmanagementsysteme - Teil 5: Begriffe (Bd. DIN Taschenbuch 472). Berlin: Beuth Verlag GmbH [GPM17b] GPM, SPM, & Gessler, M. (Hrsg.). (8. Auf. 2017). Kompetenzbasiertes Projektmanagement (PM3): Handbuch für die Projektarbeit, Qualifizierung und Zertifizierung auf Basis der IPMA Competence Baseline Version 3.0. Nürnberg: GPM Deutsche Gesellschaft für Projektmanagement e.V. [KERT03] Kerth, N. L. (2003). Post mortem. Projekte erfolgreich auswerten. Frechen: mitp [KERZ22] Kerzner, H. (13. Aufl. 2022). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. Hoboken, New Jersey: Wiley [PATZ17] Patzak, G., & Rattay, G. (7., überarb. Aufl. 2017). Projektmanagement: Leitfaden zum Management von Projekten, Projektportfolios und projektorientierten Unternehmen. Wien: Linde Verlags GmbH [PFET20] Pfetzing, K., & Rohde, A. (7., vollst. überarb. Aufl. 2020). Ganzheitliches Projektmanagement. Wettenberg: Verlag Dr. Götz Schmidt. [PMI21a] Project Management Institute Inc. (7 th Edition 2021). A guide to the Project Management Body of Knowledge und die Norm für Projektmanagement. Pennsylvania: PMI Inc. <?page no="161"?> Page | 161 7 Cross-phase competences Figure 74 - ICB elements in cross-phase competences The cross-phase competencies mostly relate to the People competency area. It covers the personal and social competencies needed in the project to achieve project success. The personal competencies start with the ability for self-reflection and end with a focus on results. This chapter is supplemented by the competency element C HANGE AND TRANSFORMATION , since, in the opinion of the author, most cross-phase competencies are required in change management. 7.1 Self-reflection and self-management Self-reflection and self-management (4.4.1) ‘S ELF - REFLECTION is the ability to recognize, reflect on and understand one's own emotions, behaviour, preferences and values, as well as their influence. S ELF - MAN - AGEMENT is the ability to set personal goals, monitor and adjust progress, and carry out daily work systematically.’ [GPM17a, page 66] 7.1.1 Reflection of one’s own team role 3.3.4 Power and interests / Competence level 2 (Level C) In 1955, the two psychologists J OSEPH L UFT and H ARRY I NGHAM developed a simple psychological model that illustrates how a person's perception of themselves and others changes during a self-reflection process. The ‘Johari’ window presents information about a person - feelings, experiences, views, knowledge, attitudes, abilities, intentions, motivation, etc. - from four perspectives. <?page no="162"?> 162 | Page Open (public self) Behaviour known to ourselves and others Blind spot Lack of self-perception. This area contains the part of behaviour that one knows little or nothing about oneself, but which is clearly perceived by others. Hidden (my secret) Area of our behaviour which we hide from others Unknown (unconscious) Neither for ourselves, not for others directly accessible. Hidden talents and gifts can slumber here. Table 51 - The four quadrants of the Johari window Figure 75 - The Johari window Making the collective scope of action more transparent and expanding it is what L UFT and I NGHAM describe as one goal of using the model. In the Johari window, the area of ‘public person’ (known to others / known to me) is constantly growing, while the areas of ‘my secret’ (unknown to others / known to me) and ‘blind spot’ (known to others / unknown to me) are constantly shrinking. There are two possibilities for this:  Self-revelation - By sharing personal secrets with others, the effort required to keep them secret is reduced and freedom and scope for action in public life are increased.  Feedback - By communicating observations about blind spots directly to the person concerned, they gain insights into themselves and can thus perceive and act on their scope for action more consciously. Both approaches complement each other and also help to make the unconscious conscious and thus manageable [GPM17b, TIMI17]. 7.1.2 Self-management 4.4.1 Self-reflection and self-management / Competence level 2 An important and widespread technique in time management is the Eisenhower matrix (also Eisenhower method, Eisenhower principle). It is attributed to former US President D WIGHT D. E ISENHOWER , although there is no evidence that he applied and/ or taught this method [SEIW14]. The basic idea of the Eisenhower matrix is a targeted categorisation of tasks. The classification is based on two parameters: <?page no="163"?> Page | 163  Importance: A task is considered important if it serves the achievement of the goal. A task that does not serve the achievement of the goal is considered unimportant.  Urgency: A task is urgent if it loses its meaning on a specific date in the near future. If it does not matter when this task is completed (in the near future), it is not urgent. Figure 76 - The Eisenhower matrix According to the Eisenhower matrix, you should deal with the tasks in each quadrant as follows: [SEIW14, GUBE17]  Important / urgent: These tasks are of the highest value in achieving your goals. You should therefore take care of them immediately. Only by dealing with these tasks yourself can you be sure that they will actually be completed.  Important / not urgent: Since these tasks are also important for achieving your goals, you take care of them yourself. However, their completion is not tied to a specific time frame in the near future. It is therefore sufficient to set yourself a precise time for completing these tasks.  Urgent / not important: These tasks should be completed promptly, but it is usually not necessary for you to take care of them yourself. You should delegate these tasks.  Not urgent / not important: Tasks that do not help you achieve your goals and for which it does not matter when they are completed have the least value and do not need to be dealt with. Critical note: How do you define ‘important’ and ‘urgent’ for yourself? The Eisenhower Matrix does not help with this classification. And why should I worry about tasks that are neither important nor urgent for me? They won't be dealt with anyway. 7.1.3 Dealing with stress 4.4.1 Self-reflection and self-management / Competence level 1 Definition of stress The definition of stress can vary in different scientific contexts. In general, stress is considered to be a complex response that occurs in response to various challenges, pressures or demands and may be perceived as overwhelming or threatening. This natural physiological response has been evolutionarily developed to prepare the organism for ‘fight or flight’. <?page no="164"?> 164 | Page Transactional stress model The subjective experience of stress can vary depending on individual perceptions, stress management skills and personal circumstances, as explained by psychologist R ICHARD L AZARUS in his transactional stress model. According to this model, it is not the situation itself that determines whether it is experienced as stressful, but rather the affected person's assessment and decision based on their available personal resources. Figure 77 - Transactional stress model acc. to R. Lazarus (author’s representation) Stress ‘traffic light’ according to Kaluza Level Stressors ... are stimuli that trigger a stress response. Stressors can be, for example, time pressure, noise, conflicts or high demands. Guiding principle: I get stressed when ... Stress intensifiers ... are our own thoughts and evaluations, which can intensify or weaken the effect of stressors. Stress intensifiers can be, for example, perfectionism, negative expectations or low self-confidence. Guiding principle: I put myself under stress by ... Stress reaction ... are reactions to stressors and stress intensifiers. Stress reactions can include tachycardia, fear, anger or flight. Guiding principle: When I am stressed, then ... Table 52 - Stress ‚traffic light‘ acc. to G. Kaluza <?page no="165"?> Page | 165 The psychologist G ERT K ALUZA , building on Lazarus' transactional stress model, has designed a model that shows the different levels of stress. The so-called stress traffic light consists of the three levels - stressors (red), stress amplifiers (yellow) and stress reactions (green) [KALU12].According to K ALUZA , stress reactions can be categorised into several levels  Physical level - changes in biochemical processes in the body (e.g. tachycardia, muscle tension, headaches, sweating)  Behavioural level - changes in behaviour (e.g. social withdrawal, aggression, irritability, foot tapping)  Cognitive-emotional level - changes in thoughts and feelings (e.g. anxiety, helplessness, anger, inability to think, lack of concentration) „It’s not stress that kills us; it’s our reaction to it.“ Hans Selye (1907-1982), Hungarian-Canadian physician, ‘father of stress research’ Stress management Corresponding to the levels of the stress indicator, there are three ways of managing stress individually [KALU12]: Instrumental stress management Tackles the stressors with the aim of minimising or completely eliminating them, e.g. through time management (  Eisenhower matrix), self-assertion (setting limits), project planning (à project management), systematic problem solving (  Resourcefulness) Cognitive stress management Targets the stress amplifier with the aim of changing personal motives, attitudes and evaluations, e.g. by changing one's attitude (reflecting on one's own beliefs), looking at the positive, and orienting oneself towards one's own strengths (  SWOT analysis) Regenerative stress management Targets the stress reactions with the aim of regulating and controlling them, e.g. through mindfulness training, network maintenance, exercise, relaxation (breathing exercises, yoga, meditation), ‘DR strategy’ (pause - distance - regenerate). Self-exploitation / burnout Biological stress research defines the fairly stereotypical reaction to persistent stressors as general adaptation syndrome (GAS). This model, developed by the physician H ANS S ELYE , includes three phases:  Alarm reaction, which serves to quickly provide energy sources. The body enters a state of increased activity and readiness to perform.  Resistance phase, which serves to restore balance. The organism tries to reduce the high level of activity by eliminating the stressors or by adapting to permanent stress conditions.  Exhaustion stage, which prevents further adaptation by giving up resistance. The resistance phase can only be maintained for a limited time. If the organism is constantly exposed to phases of high activation without the possibility of recovery - as in <?page no="166"?> 166 | Page the case of permanent professional or private stress, for example - serious long-term consequences can occur. Therefore, it is not the level of activation that is crucial for maintaining the health of the organism, but the duration and intensity of the recovery phase (healthy self-regulation). Figure 78 - Development of stress (author’s representation) Long-term effects (impaired self-regulation) can, among other things, lead to burnout, which occurs as a reaction to prolonged stress and overwork. The term ‘burnout’ was coined by the psychotherapist H ERBERT J. F REUDENBERGER in 1974 and describes specific personal crises. Health consequences such as high blood pressure, tachycardia, exhaustion, alienation from one's job and reduced performance can be considered indicators of this. „Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it.“ Alan Alexander Milne (1882-1956), English writer and author of children's books, including ‘Winnie-the-Pooh’ 7.2 Personal integrity and reliability Personal integrity and reliability (4.4.2) ‘To benefit from projects, numerous personal commitments must be made to complete the work. P ERSONAL INTEGRITY means that individuals act in accordance with their own moral and ethical values and principles. R ELIABILITY [sic! ] means acting in accordance with expectations and/ or agreed behaviour.’ [GPM17a, page 70] <?page no="167"?> Page | 167 7.2.1 Personal approach to mistakes (error culture) 4.4.2 Personal integrity and reliability / Competence level 1 Mistakes are any deviation from an expected state or behaviour, and they happen to everyone. They are part of the human condition and cannot be avoided, even with the utmost care [GUBE17]. The question is how the project team deals with mistakes. Do they punish, cover up, pass them on to others or review them and learn from them? Constructive handling of mistakes has a positive effect on the performance of the project team (see Reliability, trust, leap of faith). A few rules help the project manager to establish such an error culture 1. Mistakes are addressed, not covered up. 2. Search for the causes of the error, not for the guilty party. 3. Collective analysis of errors, identification and implementation of measures to minimise damage. 4. Learning from errors in the spirit of continuous improvement. 5. Maintaining a factual level of discussion; accusations and emotions are unhelpful here. 6. As a project manager, adhering to these rules. The last point is not always easy, so the project manager should reflect on their own error tolerance. “Mistakes are part of life; you can't avoid them. You can only hope that they don't cost you too much and that you don't make the same mistake twice.” Lee Iacocca (1924-2019), former US automotive manager and author 7.2.2 Reliability, trust, and a leap of faith 4.4.2 Personal integrity and reliability / Competence level 1 Reliability In general terms, reliability is a measure of how reliably and safely, i.e. without danger, a unit under observation (component, system) fulfils the requirements placed on it under defined conditions. Thus, reliability is an umbrella term that covers different aspects, in particular reliability, availability and safety. A team member is considered to be reliable if one can rely on them to keep their promises regarding the results of their actions and their behaviour. However, this also increasingly applies to the fulfilment of unspoken behavioural expectations that are simply expected in line with the values / culture, i.e. unspoken behavioural expectations that are simply expected in line with the values / culture [GPM17b]. For the project manager, this means that he or she has the necessary expertise, experience and the associated methodological and practical skills to manage projects. Furthermore, he or she must have the necessary authority to carry out the projects and have decision-making authority (make decisions and assess their impact). <?page no="168"?> 168 | Page Trust According to the Gabler Economic Lexicon, trust is ‘the expectation of not being disadvantaged by the actions of others; as such, it is the indispensable basis for any cooperation.’ [LINH18] The American business author, P. L ENCIONI , expands on this and describes trust as the basis for a functioning, cohesive team. For the individual team members, this means being certain that their teammates' intentions are good and that there is no reason for caution and restraint. Such trust requires openness towards teammates regarding problems, mistakes and requests for support, and in return the certainty that this openness will not be used against them personally [LENC14]. It is therefore important for the project manager to build a relationship of trust with and between the project team members in order to reduce uncertainty and improve communication and conflict resolution. Trust arises from the conviction that the other person is both professionally and personally competent and reliable [GPM17b]. “Trust is the foundation of every successful team.“ Alexander Huber (born 1968), German professional mountaineer and extreme climber A leap of faith Trust is built up little by little, developing on the basis of lived reliability. Reliability without preconditions causes the other party's level of trust in the partner to rise, but at the same time this is experienced as an obligation to prove oneself as reliable and to behave trustingly. One person in the team, usually the project manager, has to start by giving the others a leap of faith, i.e. opening up in the confidence that the openness will not be used against them [GPM17b]. 7.2.3 Ethics and personal values 4.4.2 Personal integrity and reliability / Competence level 1 (Level C) | 4.3.5 Culture and values / Competence level 1 Ethics (from the Greek ethos = custom, habit, practice) is the study of correct human thought and action, as well as the actually valid norms and values (= morals) of a society and individual lifestyle. Ethics deals with the clarification of the questions of what constitutes good or evil action, or how a person should or should not act. Ethical behaviour is thus the basis of all social systems [WORLD]. Moral describes what people consider to be right according to social consensus or what they do according to their moral principles of right behaviour or action. It is cultureand society-dependent and cannot claim to be universally valid. However, there would be no ethics without morals, and it would then be without practical significance. In addition, there is the conviction as the moral mindset of the individual. It gives direction and purpose to our actions and thoughts and, unlike morals, cannot be culturally inherited. Conviction develops in childhood. Conscience also develops at this stage of life, from criteria that are both instilled and chosen, as well as from accumulated knowledge. Before a person makes a decision - whereby the reason for doing so is a sensation from outside - a pre-selection of possible options is made by the conviction. A person's conviction can therefore be recognized by their speech, gestures and actions. Conviction (or intention) gives a person's actions meaning, regardless of the success of the action [GPM17b]. <?page no="169"?> Page | 169 The basic principle of ethics can be traced back to a sentence, the so-called Golden Rule. “Treat others as you would want them to treat you.” The so-called Golden Rule, traced back to (i.a.) Luke 6: 31 and Matthew 7: 12 This rule can be found in a similar form in almost every world religion 25 and is an indication that ethics sets general, i.e. cross-cultural, standards. The first collection of basic ethical rules, which have shaped the prevailing moral concept in (western) society since the Middle Ages, were the 10 Commandments. 7.2.3.1 Descriptive and normative ethics Ethics can be divided into two sub-disciplines: descriptive and normative ethics. Descriptive ethics, also known as moral science, is the branch of ethics that studies the psychological, biological, social and historical foundations of moral phenomena. It describes the answers found and explains the behaviour, customs and values of cultures and groups. By contrast, normative ethics is future-oriented. It compares the actual state with the future state to be aspired to. Normative ethics reacts to an actual or presumed deficit and attempts to eliminate it. It tests and assesses the prevailing customs and morals and provides instructions for action (  ethics of action). One approach of normative ethics can be traced back to the German philosopher I MMANUEL K ANT . He coined the concept of the categorical imperative: “Act only according to that maxim by which you can, at the same time, will that it become a universal law.“ Immanuel Kant (1724-1804), German philosopher His assumption was that the thoughts behind the action alone must be morally ‘good’ in order to be the basis for good action. This ulterior motive in the moral context corresponds to the conviction explained above (  ethics of conviction). H ANS J ONAS formulated the ecological imperative, the more recent approach in normative ethics: “Act in such a way that the effects of your actions are compatible with the permanence of genuine human life on earth.“ Hans Jonas (1903-1993), German-American philosopher Here, the focus is on responsibility for actions with regard to their consequences. H ANS J ONAS was particularly concerned with issues that have long-term and not readily foreseeable effects on people, society and nature (  consequentialism) . The German sociologist M AXIMILIAN W EBER argued that an action can be characterised as responsible if, in addition to being convinced of the moral correctness of the desired goal, the calculation and ethical evaluation of the consequences of the action are also included in the legitimation of the action (  ethics of responsibility). 25 An overview can be found at Wikipedia, de.wikipedia.org/ wiki/ Goldene_Regel and Forum Geistige Nahrung, www.geistigenahrung.org/ ftopic85.html, both accessed on 30 October 2018 <?page no="170"?> 170 | Page Figure 79 - Ethics of acti on (summary) 7.2.3.2 Ethics and project management As described in the previous chapter, ethics attempts to provide people with rules to help them make decisions. This initially concerns the individual and their personal ethical standards, but it also serves as a yardstick for professions, trade associations and companies. Figure 80 - Ethical guidelines for project managers <?page no="171"?> Page | 171 In recent years, professional responsibility for project managers has become increasingly important. Fundamental values such as integrity, loyalty and solidarity, a professional ‘Code of Ethics’ or even a company's internal Code of Conduct or laws (e.g. acceptance of benefits, bribery, corruption) and standards (e.g. ISO 26000: - Guidelines for social responsibility, SA8000 - Standard for socially responsible corporate governance) can be the basis for ethical behaviour [PATZ17]. Company-internal codes of conduct have become standard in business. Globally active companies can hardly do without them. For the profession of project management, the GPM has developed a code of ethics that requires project managers, and in a broader sense all those working in project management, to align their actions and decisions with the core values of responsibility, competence and integrity. A similar code of professional ethics can be found at the Project Management Institute. PMI has established and declared binding ethical guidelines and standards of professional conduct (PMI's Code of Ethics and Professional Conduct) for all those working in a project. According to PMI, this code contains the ‘four most important values of project management’ - responsibility, respect, fairness and honesty [KERZ22]. GPM (Excerpt) PMI (Excerpt) Responsibility Every project manager prioritises the common good, as well as the health and safety of each individual. Responsibility We consider the best interests of society, public safety and the environment when making decisions and taking action. We only accept tasks for which we are qualified and suited according to our background, experience and skills. We protect proprietary or confidential information entrusted to us. Competence The project manager only takes on projects whose complexity and consequences s/ he has a good grasp of. In order to improve his/ her own abilities and to keep up to date, the project manager is constantly educating him/ herself. Integrity The project manager observes the laws and generally recognized social values wherever they operate in the world. Respect We keep ourselves informed about the norms and customs of others and avoid engaging in behaviour that others might consider disrespectful. <?page no="172"?> 172 | Page They maintain the confidentiality of information and protect copyrights. Fairness Fairness requires that we approach decisionmaking and actions with an open mind and objectively. Our behaviour must not be influenced by self-interest, prejudice or favouritism. Honesty Honesty is our duty to understand the truth and to act truthfully in our communication and behaviour. Table 53 - Comparison of ‘Code of Ethics’ of GPM and PMI Taking ethical and moral principles into account in project management does not make it easier, but more complex and therefore more difficult. As a project manager, you are not only responsible for the measurable project results, but also have to justify or take responsibility for the possible consequences of your actions. A LBERT S CHWEITZER comes straight to the point: “Ethics is an infinitely expanded responsibility.” Albert Schweitzer (18751-1965), physician and philosopher 7.3 Personal communication Personal communication (4.4.3) ‘The competence P ERSONAL COMMUNICATION encompasses the exchange of appropriate information that is communicated accurately and completely to all relevant parties.’ [GPM17a, page 73] 7.3.1 Communication models and types 4.4.3 Personal communication/ Competence level 2 Sender-receiver model Figure 81 - Sender-receiver model (simplified) <?page no="173"?> Page | 173 One of the oldest communication models is the sender-receiver model by C LAUDE E. S HANNON and W ARREN W EAVER . This model was the basis for the development of electronic information exchange and is therefore rather unsuitable for explaining human communication, as it neglects the diverse human possibilities for communication [GPM 17b]. The condition for the communication process is the establishment of an appropriate communication channel (e.g. eye contact, dialling a telephone number). This model, in its simplicity, represents a widespread view of communication and is therefore an important starting point for the fact that a simplified understanding of communication can be the source of many typical communication problems [GPM17b]. The iceberg model When we talk to others and exchange information, we focus on the content rather than on the way we communicate it. When we listen, however, we only partially focus on the content; we also evaluate how the information is received. We feel taken seriously, offended, hurt or similar. This unconscious part of communication leads to communication disorders on the relationship level, even if we understand each other on the factual level. This insight is confirmed by communication researchers such as P AUL W ATZLAWICK - conscious communication is only the tip of the iceberg. Just 10 to 20% of communication takes place on the factual level (content level). To use the metaphor of the iceberg, this part is ‘above the water’, while the remaining 80-90% is hidden below the surface at the relationship level. However, what happens underwater has a major influence on what happens above water. The relationship level supports and shapes the content level [EGLE21]. Figure 82 - Content and relationship level (Iceberg model) Message square F RIEDEMANN S CHULZ VON T HUN 's message square (also known as the communication square or four-ears model) takes Watzlawick's communication model (‘iceberg model’) and expands it to four communication levels - the factual level, the relationship level, the self-manifestation level and the appeal level. This is based on the realisation that in every message we send, four messages are always sent simultaneously: <?page no="174"?> 174 | Page  a factual message (what am I talking about)  a self-revelation (what do I reveal about myself)  a relationship reference (what do I think of you and how do I feel about you)  an appeal or request (what do I want to achieve with you) In addition, the person we are talking to also listens with four ears. The quality of the conversation depends on how harmoniously the four messages meet the four ears [THUN03]. Figure 83 - Message square (author’s representation) The following table provides an overview of these interactions. Sender Receiver Content level ... communicates: the facts clearly and comprehensibly ... listens to: the facts and figures, has a correspondingly large range of options to engage with. Self-revelation level ... reveals: what is going on inside me, what I stand for, how I see my role. I-messages ... takes in: What does it tell me about the other person? What kind of person are they? What mood are they in? Relationship level ... reveals: What do I think of them? How do I feel about the other person? You-messages ... decides: How do I feel about the way the other person speaks to me, treats me? What does the other person think of me and how do they feel about me? Appeal level ... wants to achieve something, to get something done, to motivate. ... asks themselves: What should I do, think or feel now? Table 54 - Four levels of the message square <?page no="175"?> Page | 175 However, we cannot influence which ear the recipient listens with, and even less their inner reaction to it. This depends on the recipient's inner map as well as on the conversation situation and the environment [THUN11]. Axioms of communication P AUL W ATZLAWICK developed five axioms 26 for human communication based on insights into disruptions in interpersonal communication. These axioms enable us to recognize and avoid such disruptions [BEND14, SIMO 06]. Axiom Explanation 1. One cannot not communicate. For W ATZLAWICK , all behaviour and action is communication. But even non-action has a communicative character for him. Therefore it is impossible not to communicate. 2. Every communication has a content and a relationship aspect. Every message that a sender sends to a receiver has content. At the same time, however, the message contains further information that goes beyond the content. This relates to the relationship with the communication partner (  Iceberg model) 3. The punctuation of the event sequence defines the relationship. (cause and effect) Each participant in an interaction gives the relationship a structure. Each stimulus is followed by a reaction (behavioural chain), i.e. both communication partners see the cause of their behaviour in the behaviour of the other. Each stimulus is also communication at the same time, since communication is circular. There is no starting point. 4. Human communication uses analogue and digital modalities. Interpersonal communication takes place in precisely identifiable (digital) or similar (analogue) form. When the signs (letters, words, numbers) have a clear objective or conceptual meaning for both conversation partners, we speak of digital information. If, on the other hand, the information can only be interpreted indirectly or approximately (gaze, facial expressions, gestures, tone of voice), we speak of analogue communication. 5. Communication is either symmetrical or complementary If both parties assume that their relationship is of equal standing, communication is symmetrical. In the case of complementary communication, the two parties are in a complementary relationship (superior  employee). Table 55 - Five axioms of communication acc. to Watzlawick 7.3.2 Communication channels 4.4.3 Personal communication/ Competence level 2 The project manager has the choice between two types of communication channels or two carriers of information and communication - media and people. 26 An axiom is a principle that does not require proof. <?page no="176"?> 176 | Page Figure 84 - Communication channels Information can be provided acoustically, in writing or visually via media channels. These basic forms can be expanded by setting up technical communication channels (telecommunication, communication networks, communication technology). Stakeholders then have the option of accessing this information independently (e.g. intranet, internet with login on the company website) or receiving it automatically (e.g. electronic newsletter). Written communication takes place, for example, via status reports, articles (e.g. company newspaper, local press), project flyers and documents. Newer platforms such as Facebook (e.g. with closed or secret groups) and Twitter (e.g. via protected tweet) are opening up interesting possibilities for project communication. Oral communication, i.e. communication with or about people, can be formal or informal. The most important formal forms of communication are meetings (e.g. weekly jour fixe) and workshops (e.g. project launch workshop). A structured agenda including a schedule and consistent follow-up in the form of minutes or minutes of proceedings are helpful and useful. Informal communication takes place between individuals in the form of unplanned conversations, e.g. in the coffee corner. These conversations are used to establish and maintain social relationships. But be careful, informal conversations are often the starting point for rumours. This is due to the ‘Chinese whispers effect’, in which each message is continuously changed by one's own subjective perception as it is passed on. To prevent this as much as possible, it is important to define who in the project team communicates with the outside world and what information may be officially distributed. Disclosing insider knowledge without authorisation endangers the basis of trust within the team, ties up resources (primarily those of the project manager) to extinguish the resulting fires and possibly ultimately jeopardises the success of the project. Ultimately, apart from the possible negative effects of informal communication, it is irrelevant which channel is used for communication. What is crucial is the content, structure and format - in other words, what is communicated, how, and in a way that is short and concise but also convincing and correct, in order to keep stakeholders informed about the progress of the project early, regularly, honestly and proactively. <?page no="177"?> Page | 177 7.3.3 Perceptual disorder 4.4.3 Personal communication/ Competence level 2 (Level C) The perception disorders described here are not disorders in the medical sense. It is therefore not about disorders in the processing of sensory impressions in the central nervous system, but about perception within communication with others. Communication is influenced by many factors - place, time, situation. We filter information because our perception strives for meaningfulness and freedom from contradictions and also depends on our accumulated experience [SCHI14]. What we perceive is thus the result of a complex processing procedure and is always selective and subjective.  Experiences and feelings provide a selection - we only perceive what we want to perceive (assimilation)  Structure and wholeness - if we lack information, we make subjective additions, but we interpret and do not question the interpretation (accommodation)  Negative emotional states, which are triggered by incompatible or mutually exclusive perceptions (cognitions). These can be contradictory feelings, ideas, desires, goals, attitudes, opinions, intentions or thoughts (cognitive dissonance) This individuality in perception also affects our behaviour. If we experience a situation positively and in a friendly way, we act differently than if we experience it negatively and threateningly. Our behaviour is not only influenced by our perception, but also influences the perception of others (see also table 55 - Five Axioms according to Watzlawick, especially Axiom No. 3). The person we are interacting with will perceive our words and actions and, without questioning them, will interpret them based on their own experience [SCHI14]. S CHULZ VON T HUN addresses this issue in his communication model and shows that every statement can be meant and understood on four different levels (see figure 83 - The message square). 7.3.4 Facilitate open communication 4.4.3 Personal communication / Competence level 1 7.3.4.1 Question types and techniques The questioning technique, or: the art of asking, involves two main aspects: firstly, using questions to create a dialogue and, secondly, asking the right questions. To avoid ambiguity and understand relationships, it is important to ask a lot of questions, because asking questions is how you obtain information. Asking questions also shows an interest in the person you are talking to. Asking questions gives you time to think during the conversation and whoever asks can steer a conversation in the desired direction. The motto is: ‘He/ she who asks, leads.’ [BLIC05, SIMO06]. “If you want a wise answer, you have to ask sensibly.“ Johann Wolfgang von Goethe (1749-1832), German poet, among other works ‘Götz von Berlichingen’, ‘Faust’ There are different types of questions for this. In principle, a distinction is made between open and closed questions. In contrast to closed questions, the conversation partner <?page no="178"?> 178 | Page cannot answer open questions with ‘yes’/ ‘no’ or only from given answer options. Even the shortest answer will usually consist of a complete sentence. Open questions are also referred to as ‘W-questions’ because the initial word of the question always (mostly) begins with a ‘W’ - who, what, where, when, why, how. This type of question encourages the flow of information and tends to be cooperative. Closed questions demand or encourage decisions and tend to be directive. A few examples of these two types of questions: open questions provocative question ‘Can't you or won't you give me a straight answer? ’ counter question ‘What do you mean? ’ motivational question ‘How did you come up with this excellent idea? ’ focus question ‘What do you consider the most important point in our conversation today? ’ closed questions control question ‘So, we're agreed on the approach to solving the problem? ’ permission question ‘May I use the flipchart? ’ alternative question ‘Are we starting the project in Q1 or Q2? ’ suggestive question ‘You agree with me, don't you? ’ Table 56 - Types of questions (examples) 7.3.4.2 Active listening Types of listening The ability and willingness to listen is part of successful communication. We can listen in different ways: active grasp the internal connections between statements, do not make your own additions, respond to the person you are talking to. perceptive Showing attention, commenting eye contact, empty phrases like: aha, so, yes, mhm, ... descriptive Summarise what you have heard in your own words, provide feedback on how what was said was understood, expand on and elaborate on what you have heard. pseudo Just ‘waiting’ to start speaking for yourself, using phrases like ‘Yes, you're right about that, but...’ or ‘I understand, but...’ Table 57 - Types of listening <?page no="179"?> Page | 179 Active listening Active, recording and paraphrasing can be found in a corresponding form in active listening. Active listening (originally developed by C ARL R OGERS in client-centred therapy) is the most demanding form of listening and represents an important skill for improving interpersonal communication [THUN11, KNIL10]. According to R OGERS , there are three basic characteristics that lead to successful communication: empathy (empathic understanding), congruence (authenticity) and positive emotional appreciation [RÖHN20]. Active listening means empathising with the person you are talking to, thinking along the same lines as them and showing attention and interest in the person you are talking to. In other words, ‘listening is an activity, sometimes even hard work.’ [BLIC05, page 24] “Very few people are truly able to listen.” Michael Ende (1929-1995), German author, among others of ‘Momo’ and ‘The Neverending Story’“ The basic rules for active listening are [THUN03, BLIC05, KREY05]: Relationship listen and watch Silence and eye contact signal to the conversation partner that he/ she should continue speaking. acknowledge by means of a behavioural echo, e.g. an encouraging gesture, nodding, ‘aha’, ‘hmm’ Content question Express interest, ask comprehension questions repeat and reframe Verbalisation: put what you have heard into your own words Feelings address the unspoken Verbalise what is between the lines, i.e. to address aspects that may not yet have been explicitly mentioned or that do not yet appear clear enough. Formulated as I-messages. This is mainly used in conflict mediation and coaching. Table 58 - Basic rules of active listening 7.3.4.3 Feedback Feedback is a fundamental part of communication. The feedback recipient must be willing and able to listen. Receiving feedback means that one's own behaviour and actions are presented from the perspective of another. It helps us to gain a better under-standing of ourselves and supports personal development (see also the chapter 7.1.1 ‘Reflecting on one's own team role - the Johari window’). <?page no="180"?> 180 | Page Feedback rules The following basic rules are a prerequisite for a positive and beneficial effect of feedback:  Feedback must be desired.  The feedback provider uses I-messages.  Feedback should be honest.  Feedback is factual.  Feedback addresses changeable issues.  Feedback is provided promptly. The acronym PIEB is suitable as a ‘procedural model’ for structured feedback:  my perception  my interpretation  which emotion(s) were triggered in me?  my request for you to change your behaviour PIEB can also be represented using the message square. The following table shows the relationships [THUN11]. Example Create empathy ‘With you, I hear...’ ‘Did I understand you correctly...’ P Comments on the subject (personal assessment) ‘This includes the following topics...’ ‘This is about...’ I Relationship (you-message) ‘You affect me...’ ‘I experience you...’ E Self-revelation (I-message) ‘I feel...’ ‘I know it...’ B Appeal ‘My wish for you...’ Table 59 - Feedback and the message square Two further feedback variants are, for example:  The feedback burger (also ‘feedback sandwich’), which packs the objective, constructive criticism into two ‘bread roll halves’. The lower half of the bread roll is the positive introduction (praise, encouragement), the filling is the constructive criticism (What did I perceive? How did it affect me? What would I like to see? ) and the upper half of the roll concludes the feedback with a positive outlook.  Non-violent communication (NVC), a communication method developed by Marshall Rosenberg that focuses on fostering empathy and understanding by expressing needs and feelings without blame or criticism. It follows the steps: 1. Stating your observation in a situation, focusing on facts without judgment or interpretation (When I saw / heard ...); 2. Expressing how the observation makes you feel (...it made me <?page no="181"?> Page | 181 feel...); 3. Formulating your need that is connected to your feelings (...because I need…); 4. Make a clear, specific request for action that would meet your need (Could you please …). Differentiation Feedback vs. Answer Feedback is the general response given to an action or performance without a specific question being asked. It is used to convey information, opinions or evaluations in order to promote improvements or express appreciation. An answer to a question is a direct response. It aims to provide the specific information or clarification that the questioner is seeking. The answer is closely tied to the context of the question and aims to convey a specific piece of information or eliminate a doubt. 7.3.5 Virtual teams 4.4.3 Personal communication/ Competence level 1 Virtual teams interact across locations, often across countries and time zones, to work on collective or interdependent tasks. They rarely communicate in person and therefore rely heavily on various collaboration tools for communication and collaboration, such as instant messengers, video and audio conferencing services, etc. The team members are usually strangers [BOHI11, MOTZ17]. A collaboration tool or software offers various functions for managing projects. For example, such a tool can support the following content and features:  Idea generation and collective creative work  Sharing documents and other data with other users  Real-time communication  Planning and overview of work processes They create the conditions for virtual teams to carry out their work at different locations and at different times and thus be able to react to contributions at the same time (synchronous communication). Examples are: 27  Collecting ideas (e.g. Webspiration, MindMeister, Mind42)  Project management (e.g. Planio, Basecamp, Projectplace, Trello)  Collaborative writing tools (e.g. Google Docs, Miro, Collaboard)  File sharing (e.g. Dropbox, box, File Dropper, Next Cloud)  Instant messengers for quick communication (e.g. Yammer, MS Teams)  Audio and video conferencing (e.g. MS Teams, Zoom, GoTo Meeting, WebEx)  Wiki tools (e.g. MediaWiki, Google Sites) In contrast to this is asynchronous (time-delayed) communication, i.e. there is a time lag between the individual contributions (e.g. letter, e-mail, discussion forum). 27 Disclaimer: These are not product recommendations! Any use of such a tool requires a precise analysis of your needs and a review of the legal situation. <?page no="182"?> 182 | Page For virtual collaboration to be positive and successful, it is necessary not only to choose the collaboration tools, but also to establish rules of conduct for collective project work in the team and to ensure that these are adhered to during the project. These rules also include netiquette, a portmanteau 28 of the English word ‘net’ and the French word ‘étiquette’ (etiquette). This refers to (good) behaviour in virtual communication with the aim of enabling all team members to communicate comfortably. One of the best-known documents on this topic is RFC 1855, a paper written in 1995 by an Intel employee called S ALLY H AMBRIDGE . The document contains 20 pages full of guidelines for emails, chats, and one-on-one and group communication. 29 These include the socalled robustness rule: ‘Be conservative in what you send and liberal in what you receive.’ However, the paper has not been updated, so some of the rules are rather amusing today [BÖS18]. The rules concern, among other things:  Interpersonal matters (e.g. wording and content should be appropriate for the target audience)  Technology (e.g. compliance with the standards for transmitting messages)  Readability (e.g. writing in UPPERCASE or persistent bold type is usually interpreted as aggressive shouting)  Security (e.g. omitting information that is not intended for third parties)  Legal (e.g. compliance with applicable law when using texts and images) 7.4 Relationships and engagement Relationships and engagement (4.4.4) ‘Personal relationships form the basis for productive co-operation, personal commitment and the commitment of others. ... Investing time and attention in building lasting and stable relationships with individuals is essential.’ [GPM17a, page 77] 7.4.1 Motivation and motivating 4.4.4 Relationships and engagement / Competence level 1 | „Sprenger motivating techniques“ und „Herzberg Two-factor theory “ / Competence level 2 (Level C)“ Motivation stands for the inner driving force and willingness to act in a certain way, or rather, the behaviour is for its own sake. No ‘techniques’ are necessary for the project employees to successfully implement their tasks. They are intrinsically motivated because the task is perceived as exciting, challenging and meaningful, i.e. they are acting on their own initiative. The employees regard working on the task as valuable and enriching (activity-centred motivational structure). In this context, the term ‘self-motivation’ is also often used [RHEI18]. The situation is different with motivating. Motivating addresses the questions ‘How do I get my employees to do what they don't want to do? ’ and ‘How do I get my employees to want what I want? ’ Motivating is manipulation. 28 A portmanteau is a word that is formed from two or more existing words that are morphologically or semantically related. 29 Wording of RFC 1855: https: / / www.heise.de/ netze/ rfc/ rfcs/ rfc1855.shtml <?page no="183"?> Page | 183 R EINHARD S PRENGER has compiled five techniques (5B) 30 for motivation [SPRE21]. Strategy Representation (example) Motivation techniques threaten coerce ‘You're going to do this, otherwise ...’ punish ‘... otherwise you will only harm yourself.’ bribe lure ‘A bonus would be possible if ...’ praise seduce ‘You are the backbone of the project.’ reward Vision ‘You are one of us, if ...’ Table 60 - Motivation techniques acc. to Sprenger Motivating is extrinsic, i.e. the employee acts only to avoid negative consequences (threats, punishment) or to achieve positive consequences (bribes, rewards, praise). The reason for the behaviour lies, unlike with intrinsic motivation, outside the actual action. The implementation of the task thus becomes a means to an end (purpose-centred motivation structure). “Every external motivation destroys the internal motivation.” Reinhard Sprenger (born 1953), author and management trainer 7.4.2 Maslow’s hierarchy of needs 4.4.4 Relationships and engagement / Competence level 1 (Level C To understand the motivation of your project team members, it is useful to know their needs. In the 1950s and 1960s, the American psychologist A BRAHAM M ASLOW , among others, studied the motives of people. M ASLOW observed that needs have different priorities, which creates a kind of order for them. For example, if a person lacks food, security, love and appreciation, the motivation to satisfy the need for ‘hunger’ is much stronger than for the other needs [MASL43]. This ‘hierarchy of needs’ published by M ASLOW at the time was later interpreted by W ER- NER C ORRELL , a German psychologist, into a pyramid model that is still tenaciously held today. Another widespread misconception is the assumption that a need level must first be 100% fulfilled before the need of the next level can have a motivating effect. M ASLOW himself writes about this: ‘We have spoken in such terms as the following: “If one need is satisfied, then another emerges. This statement might give the false impression that a need must be satisfied 100 per cent before the next need emerges.” [MASL43, p. 388] 30 Translator’s note: In German, these techniques are called “5B”, because all five verbs start with ‘B’: bedrohen, bestrafen, bestechen, belobigen, belohnen. <?page no="184"?> 184 | Page Figure 85 - Maslow’s hierarchy of needs The model illustrates that people have different needs and therefore also pursue different interests. M ASLOW differentiates between deficit and growth needs. Deficit needs must be satisfied for a person to be satisfied. Once these are fulfilled, more of the same will not lead to any further motivation. Growth needs, on the other hand, can never really be fully satisfied; there is no personal limit to which self-actualisation stops. 7.4.3 Herzberg’s two-factor theory 4.4.4 Relationships and engagement / Competence level 1 (Level C) F REDERICK H ERZBERG pursued a similar interest with his two-factors theory. However, in contrast to Maslow, he did not focus on the basic human needs, but on satisfaction or dissatisfaction at work. He differentiates between motivators and hygiene factors. Motivators represent triggers for satisfaction, while hygiene factors prevent dissatisfaction. However, a lack of dissatisfaction does not automatically equate to satisfaction and vice versa. In general, success, recognition, interesting tasks, taking on responsibility and career opportunities or development opportunities tend to be motivators (related to the work content). Good working conditions, cooperative relationships, fair superiors, a functioning organisation and fair pay tend to prevent dissatisfaction and are therefore hygiene factors (related to the work environment). If you look at the description given above for motivators and hygiene factors, then hygiene factors can be assigned to extrinsic motivation and motivators to intrinsic motivation. An equivalent of this theory can be found in N ORIAKI K ANO 's model. His model looks at the relationship between product features and customer satisfaction [SCHM15]. He essentially differentiates between <?page no="185"?> Page | 185  Basic features - are often taken for granted. Their absence leads to dissatisfaction, while their presence does not, however, cause any particular satisfaction  hygiene factors)  Performance features - are directly proportional to customer satisfaction. They are explicitly expected and often used as a comparison criterion for different products.  Excitement features - exceed customer expectations. They generate a high degree of satisfaction, even if they were not expected (  motivators) In addition, there are rejection features and irrelevant features, but these are not relevant for this comparison. Both models consider factors that influence satisfaction and dissatisfaction. However, the context is different. H ERZBERG looks at the work environment and content, while K ANO looks at products and services. 7.4.4 Self-determination theory according to Deci & Ryan 4.4.4 Relationships and engagement / Competence level 1 E DWARD L. D ECI and R ICHARD M. R YAN developed the Self-Determination Theory (SDT), which states that humans have an innate need for autonomy, competence and social inclusion (relatedness). According to D ECI and R YAN , human motivation is essentially guided by these three basic human needs. If these needs are met, a person is intrinsically motivated and happy [GPM17b]. Need Characteristics Autonomy ... means being able to make and act on decisions independently and under your own control. External control, e.g. due to a political situation or personal circumstances, can restrict a person's freedom. Competence ... refers to the fact that we feel competent and effective in what we do. For example, we also want to manage challenging situations with confidence. Persons who acts competently or self-effectively are convinced that they can perform tasks well and believe themselves and in their abilities. Relatedness ... is the extent to which individuals are connected to social groups. This concept has been studied in social psychology and sociology and refers to the way in which people are connected to others through social relationships; for example, how close we feel to our family, friends and colleagues. Table 61 - Basic human needs acc. to Deci & Ryan Referring to M ASLOW 's hierarchy of needs, these basic needs can be categorised as follows [GPM17b]: <?page no="186"?> 186 | Page Maslow Deci & Ryan Growth needs Self-realisation Autonomy (feeling of voluntary choice or self-determination) Competence (self-effectiveness; feeling of being able to achieve something) Deficit needs Social recognition Relatedness (feeling of having a meaningful relationship with others) Social needs Safety and security needs Physiological needs Table 62 - Comparison Maslow’s hierarchy of needs vs. Self-determination theory acc. to Deci & Ryan The two lowest levels of deficit needs in Maslow's hierarchy have no equivalent in D ECI and R YAN ' S model. Physical well-being and safety can certainly be interpreted as necessary prerequisites for the three basic needs to be able to guide behaviour at all. Note: Similar ideas are also described by D ANIEL P INK , for example. His studies on the topic of ‘what motivates people’ led him to the three needs [PINK11]: • Self-determination (autonomy) in the sense of what I do, when, how and where • Meaningful fulfilment (purpose) in the sense of why I do something (see also chapter 3.3.2.2 Objective functions) • Perfecting (mastery) in the sense of constantly improving one's own abilities In the context of self-determination theory, D ECI & R YAN describe a scale of low selfdetermination (external motivation) to high self-determination (intrinsic motivation) based on autonomy. Their six-level motivational continuum (see figure 86) describes the ‘quality’ of a motivated action [STAN23]. <?page no="187"?> Page | 187 Figure 86 - Motivational continuum acc. to Deci & Ryan <?page no="188"?> 188 | Page 7.5 Leadership Leadership (4.4.5) ‘L EADERSHIP means setting an example and guiding individuals and groups. The competence includes the ability to apply appropriate leadership styles in different situations’ [GPM17a, page 81] 7.5.1 Leadership styles 4.4.5 Leadership / Competence level 1 Leadership theory provides a variety of models for categorising leadership styles. These models are based on different dimensions, including task and employee orientation as well as participation orientation [WUND11]. Typology according to Dimensions Leadership styles L EWIN not explicitly known authoritarian democratic laissez-faire T ANNENBAUM & S CHMIDT Decision participation authoritarian patriarchical informative consultative cooperative partizipative democratic B LAKE / M OUTON Task orientation (concern for production) Employee orientation (concern for people) Impoverished Management Task Management Middle of the Road Management Team-Management Country Club Management B LANCHARD Supportive behaviour Directive behaviour Maturity of the employee directing coaching supporting delegating Table 63 - Selected leadership style typologies “Management means doing things right. Leadership means doing the right things.” Peter Drucker (1909-2005), pioneer of modern management theory 7.5.1.1 Typology according to K. Lewin 4.4.5 Leadership / Competence level 1 The social psychologist K URT L EWIN (1890 - 1947) is considered the father of the classic <?page no="189"?> Page | 189 leadership styles. In the IOWA study 31 , he examined the effect of his leadership styles on the individual and group behaviour of children and adolescents. His focus was on productivity, satisfaction, group cohesion and efficiency. Leadership style Characteristics authoritarian All information is concentrated with the manager Rules and instructions determine the processes The needs of the employees do not matter Tasks are delegated without discussion No room for initiative democratic, resp. cooperative Open communication Permitting of ideas and criticism Opportunity for employees to have a say and participate in decision-making A culture of mutual respect laissez-faire Lack of interest in work processes Statements and instructions often unclear Impersonal treatment of employees Employees are left to their own devices Table 64 - Leadership styles acc. to Lewin The results of the study showed that the group without leadership (‘laissez-faire’) performed significantly worse in terms of interest in tasks, team spirit and satisfaction compared to the groups with authoritarian or cooperative leadership. Author’s note Laissez-faire is predominantly referred to in the literature as ‘non-leadership’. ‘... laissez-faire no longer has any relation to the concept of leadership.’ [WUND11, page 210] ‘Laissez-faire managers have little to offer their employees (‘non-leadership’). They avoid decisions, hesitate to act and are often not there when they are needed.’ [JONA14, page 497] This ‘leadership style’ also contradicts ICB 4.0, which defines leadership as ’... setting an example and guiding individuals and groups’. 7.5.1.2 Leadership continuum according to Tannenbaum & Schmidt 4.4.5 Leadership / Competence level 1 The best-known one-dimensional approach is the leadership model developed by R OB- ERT T ANNENBAUM and W ARREN H. S CHMIDT in 1958. This leadership continuum distinguishes seven different leadership styles depending on the degree of employee participation in decision-making [TANN58]. 31 In 1939-1940, Kurt Lewin and his colleagues conducted experiments at the IOWA University Elementary School on authoritarian and democratic leadership behaviour. <?page no="190"?> 190 | Page Figure 87 - Leadership continuum T ANNENBAUM and S CHMIDT identified three influential factors that are important when choosing a leadership style. Depending on the given constellation, a different leadership style is then to be applied in each situation [TANN58]: <?page no="191"?> Page | 191 Influential factors Superiors Employees Situation − Their value system − Their trust in their employees − Their desire or will to lead − How they deal with uncertain situations (tolerance of ambiguity) − Need for independence − Willingness to take responsibility for decision-making − Tolerance of ambiguity − Commitment to the problem − Qualifications and experience − Organisation's values − Teamwork − Nature of the problem − Time pressure Table 65 - Influential factors for the choice of leadership style The model reduces the leadership style to the decision-making behaviour of the leader. Although this addresses the important factor of power in the relationship between superiors and employees, aspects of relationship building are not considered. However, it is particularly the social quality of this relationship that has a central influence on decisionmaking [WUND11]. 7.5.1.3 Managerial Grid Modell (Blake & Mouton) 4.4.5 Leadership / Competence level 2 (Level C) The basis of the Managerial Grid Model developed by R OBERT R. B LAKE and J ANE S. M OUTON in 1964 is a two-dimensional grid with the axes ‘concern for production’ and ‘concern for people’. The two axes are each divided into nine levels. This results in 81 theoretically possible combinations. Blake and Mouton have described the five essential combinations that enable project managers to recognize their leadership behaviour [WUND11, PATZ17]. Figure 88 - Managerial grid (Blake & Mouton) <?page no="192"?> 192 | Page Leadership behaviour Explanation Impoverished Management (1.1) The project manager is not concerned with the performance of the employees, nor with the satisfaction of the employees, which leads to minimal effort with regard to the tasks to be performed.  ‘neutrality of doing nothing’ Country Club Management (1.9) The lack of pressure to perform and the emphasis on employee interests lead to a leisurely pace of work and a pleasant working atmosphere. However, productivity is neglected.  comfortable and pleasant Middle of the Road Management (5.5) Compromise-oriented leadership behaviour of the project manager, which ensures a balance between the necessity to get the work done and a pleasant working atmosphere.  adaptation and compromise Task Management (9.1) This behaviour ignores the concerns of employees. The result is placed in the foreground. The influence of personal factors is kept to a minimum (authoritarian leadership style).  produce or perish Team-Management (9.9) Best possible combination, in which the highest level of work performance in terms of the project goal is achieved by committed employees.  mutual support, high degree of (personal) responsibility Table 66 - Leadership behaviour in the managerial grid 7.5.1.4 Situational Leadership ® II (K. Blanchard) 4.4.5 Leadership / Competence level 1 P AUL H ERSEY and K ENNETH H. B LANCHARD developed Situational Leadership ® in 1968. They characterised the leadership style according to the type and extent of support that project managers give to their employees. Similar to B LAKE and M OUTON in their behavioural grid, they distinguish between directing and supporting leadership behaviour. The basis of the leadership behaviour is the individual maturity level of the employee (1-4). In the original model, they described the leadership styles as telling, selling, participating and delegating. Over time, however, it became apparent that important aspects of the original model could not be implemented in practice. Based on this feedback from users and based on the experience and research of his colleagues, K EN B LANCHARD developed Situational Leadership ® II. The underlying assumptions of the model are  Leadership means partnership (‘It's something you're doing with people, not to people’)  Participation and communication are very important to people  Everyone can and wants to develop From this point of view, the four situational leadership styles - directing, coaching, supporting, delegating - were (further) developed and described. <?page no="193"?> Page | 193 (1) directing - a strong directing and little supporting behaviour. The project manager defines the roles and tasks and supervises the employee. Decisions are made by the PM; communication is rather one-sided. Descriptive attributes for this leadership style are, for example,  defining, instructing / explaining, checking / monitoring, giving feedback. (2) coaching 32 (= training) - highly directive, highly supportive behaviour. The project manager continues to define the roles and tasks but listens to ideas and suggestions. Decisions remain with the project manager, communication is reciprocal. Descriptive attributes for this leadership style are, for example,  exploring / asking, explaining / clarifying, encouraging, praising. (3) supporting 33 (= coaching) - little directing, strong supporting behaviour. The project manager is available, listens and encourages the employee to make suggestions, make own decisions and solve problems independently. Descriptive attributes for this leadership style are, for example,  questioning / listening, confirming, appreciating, encouraging feedback. (4) delegating - little directing, little supporting behaviour. The project manager encourages their employee to act independently, providing the necessary resources. The majority of decisions are made by the employee. Descriptive attributes for this leadership style are, for example,  allowing / trusting, confirming, appreciating, affirming. Figure 89 - Situational Leadership ® II Just like the management style, the maturity levels of employees are also situationand task-related. The model identifies four maturity levels: (1) Enthusiastic beginner Low competence - high commitment: the employee lacks the skills required for the task but is motivated to tackle the task anyway. Descriptive attributes for this level are  confident, inexperienced, eager to learn, enthusiastic. 32 Coaching is to be understood here in the American sense and corresponds to the European form of training. 33 Supporting corresponds here to the European understanding of coaching. <?page no="194"?> 194 | Page (2) Disillusioned learner Some competence - low commitment: has relevant skills for the task, but cannot complete the task without help. Descriptive attributes of this level are  overwhelmed, confused, frustrated, demotivated. (3) Capable but cautious contributor High proficiency - variable engagement: experienced and capable, possibly lacking in confidence to take on work independently or lacking in motivation to complete tasks thoroughly. Descriptive attributes of this level are  self-critical, cautious, contributing, capable. (4) Self-reliant achiever High competence - high commitment: experienced expert who is convinced to be doing a good job. Higher technical expertise than the project manager. Descriptive attributes of this level are  Inspired / inspires others, autonomous, self-confident, competent. Figure 90 - Leadership style according to maturity level of the employee The project manager needs a high degree of flexibility in the application of the four leadership styles (style flexibility) and a good sense (diagnostic ability) of which leadership style to use for the maturity level of the employee in the respective task. In the medium term, this leads to the further development of the employee - one of the basic assumptions of the SL II model [BLAN10, KERZ22]. <?page no="195"?> Page | 195 7.5.2 Lateral leadership 4.4.5 Leadership / Competence level 1 Lateral leadership 34 , also known as horizontal leadership, is a modern form of leadership practice that differs from traditional hierarchical vertical leadership. In lateral leadership, the focus is not on an authoritarian power structure, but on collaboration and cooperation between team members at the same hierarchical level. This type of leadership is seen by an increasing number of companies as an effective approach to tackling complex challenges [GPM17a]. Characteristic Explanation Cooperation instead of control Instead of exercising authority or giving orders, lateral leadership fosters a cooperative working environment. Team members work together and share their knowledge with others. Flat hierarchy In a laterally managed team, hierarchies are less pronounced. Every member is heard and has the opportunity to influence decisions. Self-organisation (self-management) As part of the lateral management approach, teams are encouraged to organise themselves and take responsibility for their tasks and projects. This increases the motivation of team members. Open communication Open and transparent communication is a crucial part of lateral leadership. Team members can exchange ideas, provide feedback and solve problems collectively. Table 67 - Characteristics of lateral leadership 7.5.3 Leadership roles 4.4.5 Leadership / Competence level 2 (Level C) The Circumplex Model of Leadership was developed by R OBERT E. Q UINN in 1988 on the basis of a study on organisational effectiveness. The dimensions identified, flexibility / stability and internal / external focus, represent the way in which organisations align their internal processes while simultaneously addressing external challenges such as competition, adaptation and growth. The flexibility / stability dimensions describe organisational efforts to meet the need for change while maintaining continuity. Q UINN refers to this two-dimensional model as a Competing Values Framework (CVF) due to the contrasting values [QUIN88, QUIN11]. From the perspective of leadership theory, it is crucial that Q UINN extends his model, which was originally at the organisational level, to the leadership level by integrating eight leadership roles that are arranged in the two dimensions - flexibility / stability and external / internal focus [QUIN88]. 34 also ‘leading without power’, ‘leading without a superior function’, ‘leading without hierarchy’ <?page no="196"?> 196 | Page Figure 91 - Leadership roles in the Competing Values Framework (CVF) The eight leadership roles are presented from an interaction-centred perspective as the fulfilment of role behaviour that should enable the parallel achievement of the actually contradictory goals of stability / flexibility and external / internal focus. Leadership role Dimension Explanation Innovator flexible - external creative. Welcoming, facilitating and outlining changes Broker politically astute, exerts influence externally, acquires resources Producer external - focused task-oriented, work-focused, strives for results Director plans, defines the division of tasks, sets goals and formulates clear expectations Coordinator focused - internal maintains structures, creates timetables, coordinates, solves problems, ensures compliance with rules and standards Monitor collects and distributes information, checks performance, ensures continuity and stability Facilitator internal - flexible encourages teamwork, strives for consensus, negotiates compromises, moderates conflicts Mentor listens actively, is fair, supports legitimate desires, supports personal development of team members Table 68 - Leadership roles acc. to Quinn According to Q UINN , good leadership behaviour is when all roles are fulfilled to a high degree. This includes the role-immanent conflict that a project manager must sometimes fulfil opposing roles at the same time. The aim is therefore not to be an innovator or supervisor or mentor, but to fulfil all these roles at the same time [QUIN88]. <?page no="197"?> Page | 197 7.5.4 Management concepts 4.4.5 Leadership / Competence level 1 Management concepts are designed to provide the project manager with efficient behaviours and guidelines and promote stable, reliable cooperation. They usually only take into account one aspect of management (e.g. delegation), but they show the effect on the entire (project) organisation. The essential components of these concepts are assignment of tasks, action control and the degree of participation of employees. In practice, ‘management by’ techniques have been widely adopted in a wide range of forms. However, they all rest on the three essential core techniques [THOM16]: Management by Objectives (MbO) - Managing by agreement on objectives A collective process in which the project manager and project staff identify objectives and determine who will take responsibility for which objectives. The project manager largely confines himor herself to setting objectives and monitoring them. It is not the way in which the objectives are achieved that is monitored, but whether they are achieved.  Objective: The optimal execution of the assigned tasks.  Prerequisite: The objectives must be clearly and realistically formulated so that success can be verified (à SMART). Appropriate leeway for project staff. Management by Delegation (MbD) - Leading through task delegation MbD refers to the transfer of task responsibility to project members. Within defined limits, the completion of a task is transferred to project members. Implementation is the responsibility of the project staff.  Objective: to promote initiative and shared responsibility, task orientation.  Prerequisite: delegation of tasks, competencies and responsibility. Management by Exception (MbE) With this principle of management by exception, routine decisions generally lie in the hands of the project staff. The project manager only intervenes in the event of extraordinary decisions or deviations from the project plan.  Objective: This model aims to transfer full responsibility to the project team. This lightens the project manager's workload and strengthens the project team's sense of responsibility.  Prerequisite: It must be clearly defined who has which competencies and responsibilities. In addition, it must be precisely defined what is meant by ‘exceptional deviation’. A common problem with this management technique is the fixation on negative deviations from the project plan. 7.5.5 Management responsibilities and duties of the project manager 4.3.3 Compliance, standards and regulations / Competence level 1 (Level C) For the project manager, management responsibility means having selected the right person for the delegation of work packages and tasks, and having instructed, informed and supported them properly. Depending on the role description, management responsibility may also include responsibility for the right project organisation, achieving the <?page no="198"?> 198 | Page project goal and identifying deviations at an early stage and responding to them [KREM16]. Three duties can be derived from this for the project manager: a duty of care, a duty of supervision and a duty of oversight [SICK10]. For the project manager, the duty of diligence (Ger.: Sorgfaltspflicht) means analysing the project environment systematically, thoroughly and prudently with regard to possible risks for employees. For example, as part of protective regulations (see the section on legal framework conditions - safety and health), a risk assessment would be one measure that would be taken as part of the duty of care. The duty of care (Ger.: Fürsorgepflicht) requires the project manager to a) protect the project team members from physical harm (e.g. by complying with safety regulations), b) ensure that they have the tools they need to carry out their work (e.g. a suitably equipped workplace) and c) provide a healthy working environment (e.g. ergonomic workplaces). Supervisory duty (Ger.: Aufsichtspflicht) - The project manager is responsible for checking the effectiveness of the measures taken, ensuring that the work equipment provided is used appropriately and that the legal framework, standards and specifications are adhered to. 7.6 Teamwork Teamwork (4.4.6) ‘The competence T EAMWORK is about bringing people together to achieve a collective goal. ... Project teams are often cross-disciplinary. ... Teamwork is about building a productive team by shaping, supporting and guiding it. Communication and relationships within the team are among the most important aspects of teamwork.’ [GPM17a, page 85] 7.6.1 Team concept 4.4.6 Teamwork / Competence level 1 A team is a working group of individuals who work together to produce a specific product or offer a specific service and who are mutually accountable for the quality of this service. Team members have shared goals, for the achievement of which they are collectively responsible. They are mutually dependent on the performance of the other team members and influence their results through interaction [DICK13]. From this, it can be concluded that successful project management not only depends on the project manager's knowledge of methods and leadership skills, but also to a large extent on how the project team members act as a team, how they see themselves as a project team and how they take responsibility for one or more tasks to achieve the project goal [DIN20b]. A project team can thus be characterised as <?page no="199"?> Page | 199  a certain number of people  who, as a group,  pursue collective project goals  communicate and interact with each other  form group-specific roles, norms and values  and develop a sense of unity through this. This sense of unity develops into a pronounced sense of community and a strong feeling of belonging (group cohesion) [BERG21]. Team rules It is clear that this form of cooperation does not always run smoothly, after all, people are working together. With a few team rules, listed here as examples, this cooperation can be improved:  clear, collective objectives  clear distribution of roles and tasks  appreciative, constructive handling of conflicts  open communication and feedback  Information is available to everyone in the team (  transparency)  taking responsibility for one's own tasks (  reliability)  Loyalty to the team and the project  Tolerance, respect, honesty  celebrating successes collectively “Ultimately, all business activity can be reduced to three words: people, products, and profits. People come first. If you don't have a good team, you can't do much with the other two.” Lee Iacocca (1924-2019), former US automotive manager and author Team roles according to Belbin R AYMOND M EREDITH B ELBIN was already using business games to examine the performance of diverse teams in the 1970s. After evaluating a large number of such experiments, Belbin identified nine roles. His concept of roles encompasses the type of social behaviour and the contribution to task accomplishment, whereby each team member can assume several roles [BELB10, BANK17]. These roles can be categorised into three main orientations:  3 action-oriented roles: shaper, implementer, completer-finisher  3 communication-oriented roles: co-ordinator, teamworker, resource investigator  3 knowledge-oriented roles: plant (innovator), monitor-evaluator, specialist Each team role includes positive characteristics (team role contribution) and ‘permissible’ weaknesses and contributes in its own way to productive group work [BELB18]. <?page no="200"?> 200 | Page Team role Contribution acceptable weaknesses Action-oriented Shaper Dynamic, works well under pressure, has the drive and courage to overcome problems. Tends to provoke, pays too little attention to the feelings of others. Implementer Disciplined, reliable, conservative, efficient, turns ideas into action. Somewhat inflexible, slow to respond to new opportunities. Completerfinisher Meticulous, conscientious, anxious, finds errors and omissions, meets deadlines. Tends to be overly concerned, does not like to delegate. Communication-oriented Co-ordinator Self-confident, good leader, sets goals, encourages decision-making, good delegation skills. Can be seen as manipulation, tendency to delegate personal tasks. Teamworker Cooperative, gentle, empathetic, diplomatic, listens, relieves tension. Undecided in critical situations Ressource investigator Extroverted, enthusiastic, communicative, finds new options, develops contacts. Overly optimistic, easily loses interest after the initial enthusiasm has worn off. Knowledge-oriented Plant (innovator) Creative, imaginative, unorthodox thinking, good problemsolving skills. Ignores trivialities, tends to focus on personal matters. Monitor evaluator Rational, strategic, critical, considers all options, good judgement. Low drive, lack of ability to inspire the team. Specialist Determined, committed, has abilities and skills that are rarely available. Only contributes within a narrow scope. Table 69 - Team roles acc. to Belbin Note: In practice, the Belbin team roles are an excellent overview and orientation for allocating work packages and tasks. It should be noted, however, that scientific research shows that it is rare for a single person to perform all the tasks associated with a role. Rather, these are task spectra that are distributed among several people in the team. Different talents, abilities and characteristics should be combined in the best possible way for each project [BORN15, BECK16]. <?page no="201"?> Page | 201 7.6.2 Team development 4.4.6 Teamwork / Competence level 1 Formally, the project team is formed by appointing members. However, in order to release the potential of each individual, the interpersonal relationships between the team members must develop. According to B RUCE T UCKMAN , teams go through four typical development phases to achieve optimal cooperation and thus optimal performance - forming, storming, norming, performing. In the fifth phase - adjourning - the team is dissolved [DICK13]. The following table contains a description of the individual team phases. Phase Content Role of the project manager Relationship level in the team Forming Getting to know the task (project) and the other team members Host (guiding, explaining) Contact  finding orientation, setting boundaries Storming Difficulties with the task. Self-assertion, everyone finding their own position in the team. Catalyst Conflict  conflicts and polarisation, opinions are openly expressed, trust is built, emergence of leadership Norming Exchange of information, setting of rules Moderator Contract  develop a team identity; behaviour towards each other is adjusted; agreements are made Performing The group is structured and stable Supporter Cooperation  acting as single unit; clear understanding of what is required; mutual support, conflicts are resolved Adjourning Team is dissolved Coach Sense of loss; uncertainty about the future Table 70 - Team phases (Tuckman) and role of the project manager The discovery and clarification processes described can be accelerated by targeted supportive measures to help a team quickly enter the productive phase. In practice, the phases of the team clock cannot always be clearly distinguished from one another. However, all phases are passed through by a team, but they can overlap Figure 92 - Team phases (‘team clock’) <?page no="202"?> 202 | Page or vary in duration. Failure to complete individual phases will result in a drop in performance at a later stage. The project manager should actively shape these phases in his or her role and not leave team building to chance, especially during the forming phase [BERG21]. 7.6.3 Success factors in team work 4.4.6 Teamwork / Competence level 1 In addition to the success factors already mentioned in previous chapters - collective vision / goals (  chapter 3.3.2.2 Objective funtions), trust (  chapter 7.2.2 Reliability, trust, etc.), feedback (  chapter 7.3.4 Facilitate open communication) and clear role allocation (  chapter 3.5.2 Congruence principle) - there are a few other factors that help make teamwork a success. These include, for example:  a defined team structure and clear processes  motivation and recognition create a positive working environment  a positive error culture and constructive handling of conflicts  diversity and inclusion provide different perspectives and creative solutions 7.6.4 Specific team effects 4.4.6 Teamwork / Competence level 1 A strong sense of unity does not only have positive effects. Problems can arise when this high level of cohesion develops a momentum of its own. Four phenomena can be observed here - groupthink, group shift or risk shifting, social loafing and the Abilene paradox [DÖRN11, BERG21]. Preconditions Symptoms Groupthink  strong sense of belonging,  isolation of the team through a sense of superiority towards outsiders (e.g. bundled expert knowledge),  stress and time pressure (e.g. in a critical situation),  charismatic, trend-setting leader  stereotyping (black-and-white thinking)  self-censorship (team consensus is not challenged)  filtering of information by socalled ‘opinion leaders’ in the team  alternatives, especially if they are brought to the team from outside, are not examined or only examined superficially Groupshift respectively Risk shifting  see Groupthink  Responsibility is distributed among the team members (not the one who makes the decision is responsible for the consequences, but the team as a whole) <?page no="203"?> Page | 203  Risks are taken and individual sanctions for wrong decisions are not feared Social Loafing  The larger the group, the less individual performance is noticed.  The task is not experienced as demanding.  Assumption that one's own performance contributes more to the group output than the performance of others  decreasing motivation and thus decreasing personal commitment in the team Abilene Paradox 35  Team communication failure  Each team member mistakenly believes that their own attitude is contrary to those of the other people  Related to groupthink  Group members are often reluctant to go against the group's opinion  Therefore, no objections are raised Table 71 - Team effects: Groupthink, groupshift, social loafing, Abilene Paradox Examples and results of these phenomena are:  Explosion of the space shuttle Challenger in 1986  Team worked under pressure, ignoring important information and instructions (sealing rings on the solid fuel rockets become porous at < 12°C, on the day of launch the thermometer showed 3°C) [BERG21]  Chernobyl nuclear disaster in 1986  team worked under pressure, highly professional, officially excellent team, ignore warnings and safety regulations [DÖRN11]  Deepwater Horizon oil rig fire 2010  team worked under (cost) pressure, ignore applicable standards, ignore expert opinions from outside the company 36 7.6.5 Team learning 4.4.6 Teamwork / Competence level 1 There is no doubt that teamwork forms the basis for the implementation of a project. By combining different knowledge and different qualifications, teams can develop solutions more easily, quickly and creatively than individuals. Or as Aristotle already put it: ‘The whole is more than the sum of its parts’. The opportunity to learn from and with each other in a team means that mistakes can be identified more quickly, and synergies can be realised more easily [OELS09]. 35 The term was coined in 1974 by Jerry B. Harvey, a professor of business administration at George Washington University. 36 cf. the course of the Deepwater Horizon accident at de.wikipedia.org/ wiki/ Deepwater_Horizon#Unfallhergang, accessed on 30 October 2023 <?page no="204"?> 204 | Page A common form of team learning and knowledge management is a lessons learned workshop or a retrospective (see also chapter 6.1 Project closure - safeguarding experience and chapter 8.1.3.5 Sprint retrospective). Both are designed to collect positive and negative experiences, to process them at a specific point in time and to implement improvements for further (collaborative) work with the insights gained [BANN14]. 7.7 Conflict and crisis Conflict and crisis (4.4.7) 'The competence C ONFLICT AND CRISIS includes mitigating or resolving conflicts and crises by paying close attention to the environment and being able to recognize and offer a remedy for differences of opinion. Conflict and crisis can include events and situations, character conflicts, stress levels and other potential dangers.’ [GPM17a, page 89] 7.7.1 Definition 4.4.7 Conflict and crisis / Competence level 1 Conflict A conflict exists when at least one person feels that their needs have been violated or fears that their needs will be violated by the actions of another person or institution [GPM17b, SCHI14]. Crisis The word ‘crisis’ comes from the Greek and literally means ‘difficult situation’. Crises can have different dimensions. They can affect a single person or a group, such as a project team. A crisis in the classical sense refers to a massive disruption of the social, political or economic system that lasts for a certain (longer) period of time [BPB20]. In terms of a project, crises represent a special form of conflict and are nothing more than an extreme project situation in which those involved and/ or affected find themselves in a feeling of hopelessness because crises  cause a serious deviation from the plan and  are seen as threatening the existence of the project and the project organisation. Crises always have two aspects:  an objective aspect (the success of the project is objectively at risk or can no longer be realistically achieved) and  a human / personal aspect (pressure, stress, fear, insecurity, perceived hopelessness among the people involved) [MOTZ17]. However, crises also offer opportunities for improvement. “Crisis is a productive state. You just have to take away the flavour of disaster.” Max Frisch (1911-1991), Swiss writer and architect <?page no="205"?> Page | 205 7.7.2 Causes of conflict 4.4.7 Conflict and crisis / Competence level 1 Conflicts in projects are 'part and parcel' of everyday life; they are part of human cooperation. They usually arise when different expectations collide. In most cases, the parties involved in the conflict fear that they will have to accept disadvantages. These feared disadvantages can be the cause of conflicts in various areas. The following figure shows the possible causes and their interactions [GUGE10]. Figure 93 - Causes of conflict As a project manager, it is not easy to recognize conflicts, as they are usually not dealt openly. With one exception: we are part of the conflict. We usually notice the effects (declining work performance, information not being passed on) or the symptoms (withdrawal to formal communication, excessive break times, clique formation). If relations on the emotional level are good, most conflicts can be resolved on the factual level (objectives, methods, resources). It becomes difficult when personal role or relationship conflicts cover up or negatively influence the other causes of conflict and thus possibly endanger the success of the project [GPM17b]. “No one doubts that you can live in conflict with the environment and especially with your fellow human beings.” Paul Watzlawick (1921-2007), (a.o.) communication scientist, psychotherapist and author Conflicts do not necessarily have to be destructive; they can also have a positive effect. They are an indicator of necessary changes, can reveal opportunities, resolve unpleasant situations and enable collective solutions. 7.7.3 Conflict escalation 4.4.7 Conflict and crisis / Competence level (Level C) If destructive conflicts are not resolved, they cause decreasing productivity, high costs and possibly sick leave of employees. Conflicts go through certain stages of escalation. <?page no="206"?> 206 | Page The further they progress, the more impossible it becomes to resolve them. Based on the 9-step model of conflict researcher F RIEDRICH G LASL , this conflict escalation can be illustrated as follows [GLAS17]. Figure 94 - Conflict escalation acc. to Glasl As can be seen from the figure, the model can be divided into three levels. In the first level, both parties to the conflict can still win (win-win situation), in the second only one party wins (win-lose situation) and in the third both ultimately lose (lose-lose situation). The individual stages are as follows [GLAS17, KREY05]: Win-win 1. Tension / hardening Conflicts begin with differences of opinion and hardening positions. Both parties believe that the situation can be defused through discussion. 2. Debates Both parties consider strategies to convince the other with arguments. However, polarisation is taking place on an emotional level. An argument is possible. Nevertheless, both parties believe that the problem can be solved through communication. 3. Actions The conflicting parties increase the pressure on each other in order to get their opinion or demand accepted. Conversations are broken off, the conviction that talking is no longer enough gradually gains the upper hand. Any empathy that may have existed with the other side up to this point dissolves. The risk of misinterpretation increases. The conflict intensifies; a third, neutral person for conflict resolution can already be useful at this point. <?page no="207"?> Page | 207 Win-lose 4. Coalition Building up images of the enemy, which consist mainly of clichés. Sympathisers are sought and courted as potential coalition partners. The objective level is lost sight of; the aim now is to win the conflict. 5. Loss of face At this stage, direct and, in most cases, public attacks are made on the other party to the conflict. The loss of trust on both sides is complete. There is a loss of face in the sense of a loss of moral credibility. 6. Threat strategy Escalation is further accelerated by mutual threats and the setting of deadlines. The power of the parties involved is manifested in the level of the threatened sanctions and the potential for harm to the opponent. The means (threats and deadlines) represent the attempt to control the escalation. Lose-lose 7. Limited destruction The opponent is no longer perceived as a human being. As long as the opponent is hit, even own losses are considered a gain in limited destruction strikes. 8. Fragmentation Every means that serves the destruction and dissolution of the opponent appears legitimate to the parties to the conflict. 9. Total (self-)destruction The chance for a last resort has been squandered, there is no going back. The only thing left to do is to minimise the damage to oneself while destroying the opponent. In an escalated conflict, the parties to the conflict no longer have any way of controlling or influencing the negative signs of their value judgements and emotions. As a consequence, the relationship level must be positively shaped in order to prevent and deescalate conflicts. In particular, cooperative behaviour promotes mutually positive value judgements and emotions. 7.7.4 Action strategies in the case of conflict 4.4.7 Conflict and crisis / Competence level 2 (Level C) The TKI, the Thomas-Kilmann Conflict Mode Instrument, can be used for conflict situations. In such situations, a person's behaviour is described on the basis of two fundamental dimensions - assertiveness (my interests) and co-operation (the interests of others). Five conflict management modalities can be assigned to these fundamental behaviours [KILM75, GPM17b]: 1) avoiding or suppressing a confrontation, 2) yielding to the opponent (accomodate), 3) asserting one's own goals, <?page no="208"?> 208 | Page 4) developing a cooperative solution (win-win), 5) developing a compromise. Figure 95 - Conflict styles (TKI) The following table shows an overview of the conflict styles, the underlying personal attitude and some advantages and disadvantages [KREY05]. Conflict style Attitude Advantage  / Disadvantage  Avoidance (flight) ‘I'd better be out of here.’  aggravated subsequent conflict Accomodation Giving up on my own needs and positions  minor conflict topic  mitigate damage  leads to subsequent conflicts Competition (assertion) ‚Victory or defeat‘  to break through standstill  for quick decisions  risk of escalation Compromise (haggle) ‚You always meet twice…‘  temporary solution for re-negotiation  good as intermediate solution when under time pressure  risk of a ‚shabby‘ compromise  Unsuitable as a positive start for longterm sustainable relationships <?page no="209"?> Page | 209 Cooperation (win-win) ‘To argue in order to come together.’  commitment and shared responsibility among those involved  sustainable, long-term solution  finding a solution can take a long time Table 72 - Conflict behaviours “Remember: every rotten compromise continues to rot.” Hans-Jürgen Quadbeck-Seeger (born 1939), former head of research at BASF The choice of conflict style also depends on who the conflict is with - a superior, a subordinate or a colleague at the same hierarchical level. 7.7.5 Cooperative conflict resolution as a strategy for action 4.4.7 Conflict and crisis / Competence level 1 Cooperative conflict resolution is a form of mediation in which a neutral third party, the mediator, supports the parties in resolving a conflict. Although the mediator is impartial, they are not uninvolved. They structure the conversation between the conflicting parties, help to identify underlying interests by asking targeted questions, clarify misunderstandings and support the conflicting parties in finding collective solutions [KREY05]. Figure 96 - Phases of cooperative conflict resolution Process  Opening mediation Information about the conflict, motivating the parties to find a solution, explaining the approach and rules of moderation  Collecting information Different perspectives are collected, positions are presented  Clarifying needs Fears are expressed, needs are uncovered, the conflict is broken down into objective and social components, and a collective description of the current situation is developed by the parties involved  Agreeing upon solutions Alternative target states are developed, scopes of action are presented, and a target state that is acceptable to all (target state) is described. <?page no="210"?> 210 | Page  Secure success Consequences for those involved are highlighted, binding rules of conduct are established, who does what by when is determined, and the result is formulated in a legally secure manner (complete, comprehensible, targeted) 7.8 Negotiation Negotiation (4.4.9) The competence N EGOTIATION defines the process of two or more parties to achieve a balance between different interests, needs and expectations in order to reach a collective agreement and commitment while maintaining a positive working relationship.’ [GPM17a, page 97] 7.8.1 Negotiation - concept and situation 4.4.9 Negotiation / Competence level 1 Definition Negotiation The classic negotiation technique ‘The Harvard Concept’ describes a negotiation as ‘a basic way of getting what you want from other people.’ And further as ‘two-way communication with the aim of reaching an agreement when you have both collective and conflicting interests with the other side.’ [FISH06, page 19] Negotiations are usually bilateral or multilateral (multi-party) discussions about a contract yet to be concluded or about the adaptation or modification of an existing contract [SIGM16]. Negotiation situations in projects Typical negotiation situations Every conversation can lead to a negotiation. Dealing with issues, differences of opinion and conflicts through communication with the aim of finding a solution are also nothing more than negotiation situations. Examples  Contract negotiations  Negotiations with the client about changes, additional claims, etc.  Negotiations about the provision of resources  Negotiations to resolve scheduling and resource conflicts In most cases, the project manager is not taken by surprise in such situations and can prepare for these discussions accordingly. In contrast to the hidden negotiation situations in which the project manager finds himself every day, usually without consciously perceiving them as negotiations. Examples [GPM17b]:  Conversations in the hallway that suddenly take on a binding character ‘I just have a quick question. (...) Good, so you'll bring me...’ <?page no="211"?> Page | 211  E-mail requests that are answered with an agreement ‘I'll send you an overview tomorrow, that's enough for the meeting.’  Assigning tasks just before leaving for an important appointment, leaving no time for discussion  Project team members delivering work so late that no review or rework is possible It is important for project managers to recognize that, on the one hand, they are almost always in a negotiation situation, and on the other, they should remain aware of who holds the problem in any given scenario. This awareness can significantly enhance the effectiveness of the communication process. 7.8.2 The Harvard concept 4.4.9 Negotiation / Competence level 1 (Level C) The Harvard concept is an important, almost indispensable, component in solutionoriented negotiations. It allows a positive outcome to be achieved even in difficult negotiations. The aim of the Harvard principle is to separate the factual and relationship levels, to recognize and balance interests and to seek decision-making alternatives using neutral assessment criteria in order to create a win-win situation for all parties involved. In everyday negotiations, we strive for viable solutions in the shortest possible time. Even children negotiate and want to achieve their personal goal quickly. For example, a daughter wants more pocket money, or a married couple negotiates when they have different ideas about where to go on holiday. In practice, it is often difficult to separate the personal level from the factual level. Negotiation is a good way of achieving a win-win situation or finding a solution that allows both sides to save face. The Harvard concept, mentioned at the beginning, is an excellent, results-oriented model. This concept deliberately distinguishes between two levels of communication, namely the factual content (i.e. the agreement to be negotiated itself) and the conduct of the negotiation (the meta-level), thus prioritising the result to be achieved (factual content) over personal sensitivities, while keeping the greatest possible mutual benefit in mind [FISH06]. The four essential negotiation criteria for an agreement in a win-win context are  treating people and problems separately  focusing on interests rather than positions  insisting on objective assessment criteria  developing mutually beneficial options for decision-making. The fifth criterion - fairness in dealing with each other and in the outcome of the agreement - is implicitly observed in most cases. The negotiating parties are satisfied with the result (win-win) or the solution is immediately apparent to both sides [GPM 17b]. <?page no="212"?> 212 | Page Figure 97 - The four negotiation criteria of the Harvard concept Separating the people from the problem People and their interests are separated from the factual problem. This means that a partner is initially respected and not criticised for their attitude or demands. Since the relationship level must support the factual level, negotiating partners should perceive and respond to the signals sent at the relationship level. At the relationship level, it is important to respect the self-concept of the other person; one could also say their ‘construct of reality’. Showing respect to the negotiating partner does not mean giving in on the matter - one recommendation is: ‘Be tough on the matter, but gentle on the people involved.’ [FISH06] Focus on interests and not on positions Behind irreconcilable positions, there are often personal interests and needs that enable a solution to be found that benefits both negotiating partners. The interests and needs relate to the benefits that the negotiating partners derive from the outcome of the negotiation. The position, on the other hand, is the statement of how the respective negotiating partner will act under certain conditions. It expresses a decision that has already been made. Interests and needs are the reasons behind the position. It is what a party wants or what it wants to avoid at all costs. If the needs are presented or can be identified, solutions may be possible that go beyond a simple compromise. Active listening and, where possible, gathering information in advance of the negotiation are helpful in identifying interests and the underlying needs [GPM17b]. Insist on objective assessment criteria Instead of wrestling with positions, the negotiating partners should first negotiate which criteria could be described as fair for the negotiation process and the negotiation results. Fair and objective criteria, such as universal norms, values or laws, are a solid basis for decision-making, as they are independent of the subjective interests of the parties in <?page no="213"?> Page | 213 conflict and pave the way for a solution. For example, market value or costs incurred can be objective criteria. Criteria that are perceived as fair by both sides are helpful. If an agreement is reached, the negotiating partners would not bow to the other side, but to the agreed criteria. Developing mutually beneficial decision options According to this principle, the negotiating partners do not focus on dividing up a given cake. Instead, they collectively develop as many ideas as possible for how the cake can be made bigger. This is what opens up new dimensions in terms of decision-making options and choices. In many cases, solutions can be found that are more advantageous for both partners than a compromise. Creativity is required when searching for options that ideally bring the greatest possible benefit to both sides [GPM17b]. The aim is to reach an agreement that meets the following requirements:  the good relations between the parties are maintained  both sides take what they need - or, if both need the same thing, share it fairly (e.g. according to the ‘one divides-one chooses’ principle)  time is saved in the negotiations (since positions are not held to the end) Another element of the concept discourages bad agreements and recommends that, even during the preparation for the negotiations, a comparison be made between the ‘best alternative’ outside of an agreement with a ‘bad agreement’ and thus avoid the compulsion to reach an agreement in any case (BATNA - best alternative to a negotiated agreement) [FISH06].  Non-negotiation as a more attractive alternative to negotiation: Assessing the likelihood of success of the negotiation  Assess whether the negotiating partner is allowed and willing to take alternative positions or take alternative actions. 7.9 Resourcefulness Resourcefulness (4.4.8) The competence R ESOURCEFULNESS defines the ability to apply different techniques and ways of thinking to define, analyse, prioritise and search for alternatives for dealing with or solving challenges and problems.’ [GPM17a, page 93] 7.9.1 Problem solving - process and methods 4.4.8 Resourcefulness / Competence level 1 Problems arise from the discrepancy between target and actual. In complex project environments, the paths to a solution are rather unknown, so methods are used to solve problems. Problems can be categorised into different types (e.g. objective problems, knowledge problems, factual problems, resource problems, personnel problems, team problems). However, solving a problem is only part of the solution. Rather, the cause must be determined in order to minimise the impact of the problem and, if necessary, to prevent the problem from reoccurring. <?page no="214"?> 214 | Page Figure 98 - Relationship between cause, problem and effect The first consideration when a problem arises is the effect. The greater the effect (in terms of intensity, type and scale) the more intensively project managers have to address the solution of the problem and the elimination of the cause. Figure 99 - Problem solving process The roles to be filled in the problem-solving process are, in addition to the problem owner, the moderator and the problem-solving group. 7.9.1.1 Cause-effects diagram 4.4.8 Resourcefulness / Competence level 1 The cause-and-effect diagram (also known as a fishbone diagram or Ishikawa diagram), as a quick and easy-to-implement problem-solving method, facilitates the search for causes using predefined categories. This method was originally developed by K AROU I SHIKAWA as part of quality management for the analysis of quality problems and their causes. Ishikawa originally provided for six categories (6Ms) - Man, Management, Machine, Material, Method, Milieu (or: Mother Nature). In a fishbone diagram, these 6 Ms represent the possible causes, and the header represents the effects or the problem. These six categories can be adapted to specific problems, so that five Ms are used in a basic version (man, machine, material, method, milieu). In the process environment, for example, a seventh M - measurement - can be added to the bones [KERZ22, SCHM15]. <?page no="215"?> Page | 215 Figure 100 - Cause-effects diagram (Ishikawa) In business literature, you will often also find 4P (Place, Procedures, People, Policies) and 4S (Surroundings, Suppliers, Systems, Skills) as categories of cause. 7.9.1.2 Pareto analysis 4.4.8 Resourcefulness / Competence level 1 The Pareto analysis, also known as a Pareto diagram, named after the welfare economist V ILFREDO P ARETO , states that 80% of a problem can be traced back to only 20% of the possible causes and influencing factors (Pareto effect or 80/ 20 rule) or that 80% of the effects are caused by only 20% of the problems. The Pareto diagram is an effective method for examining the influence of all causes of a problem on the problem and for identifying the main causes of the problem [SCHM15, GPM17b]. Procedure: 1. Define and formulate the problem to be solved 2. Define the category of causes or effects 3. Define the measured variable 4. Define the period under review 5. Analyse the cause or effect categories 6. Systematisation of the effect categories and creation of a bar chart 7. Interpretation of the results <?page no="216"?> 216 | Page Figure 101 - Pareto diagram with cumulative curve (example) 7.9.1.3 FMEA 4.4.8 Resourcefulness | 4.5.6 Quality / Competence level 1 The Failure Mode and Effect Analysis (FMEA) 37 is a quality management method for preventive risk analysis in the examination of products and processes. With its help, possible weak points and causes of failure are to be detected in advance. However, an FMEA can also be carried out reactively in response to problems that arise. An FMEA is usually carried out in interdisciplinary teams [SCHM15, DREW10]. Procedure: 1. Preparation of the FMEA (scoping) a. Composition of the team b. Scheduling c. Purpose d. Tool e. Assignment of tasks 2. Description of the object of analysis (structure analysis) 3. Description of the functions of the system elements (function analysis) 4. Identification of potential failure modes (failure analysis) 37 DIN EN 31010: 2010 ‘Risk management - Procedures for risk assessment’ and DIN EN 60812: 2006 ‘Analysis techniques for the operability of systems’ also refer to the FMEA as a ‘failure condition type and impact analysis’. <?page no="217"?> Page | 217 5. Evaluation of the a. defects (risk assessment 38 based on probability of occurrence, probability of detection and severity) b. Action analysis (action plan) 6. Deadline monitoring and success control “The problem is not the problem. The problem is your attitude about the problem.” Johnny Depp aka Captain Jack Sparrow (2003), „Pirates of the Caribbean: The Curse of the Black Pearl“ 7.9.2 Creativity methods 4.4.8 Resourcefulness / Competence level 1 Creativity is the ability to think productively and to form new combinations from more or less known information. To ensure project success, it is important for the project manager to utilise both the individual creativity and the collective creativity of the project team. Various creativity methods are available to support the corresponding approach to finding new ideas and innovative solutions. 7.9.2.1 The 635 method The 635 method is a brainwriting technique developed by B ERND R OHRBACH in 1968. This creativity method is ideally suited for finding ideas based on a specific question. 635 refers to six participants who formulate three ideas on a sheet of paper divided into three columns and six rows and then simultaneously pass their sheet of paper clockwise to the next person in the group. The whole thing is repeated five times, so that everyone has the opportunity to be inspired by the ideas of their predecessor and develop them further [DREW10]. Procedure: 1. Preparation: Each participant receives a prepared worksheet (problem stated in the title, three columns, six lines) 2. Implementation: The participants write down their three ideas and pass the sheet on to the next person in a clockwise direction. This person takes up the ideas, adds to them or develops them further. Five rounds. 3. Conclusion: Evaluate ideas, delete multiple entries, discuss results The most important rules:  Every contribution is important  Expand on and develop existing ideas  Ideas can be taken up and added to as you like  Criticism only in the collective discussion 38 Risk Priority Number (RPN) = probability of occurrence (O) * probability of detection (D) * severity (S) <?page no="218"?> 218 | Page 7.9.2.2 Brainstorming Brainstorming is the classic among creativity methods. Invented by A LEX F. O SBORNE in 1939, the method promotes the generation of new unusual ideas in a group. Through spontaneous expression of ideas without negative criticism, this method is used to develop and collect a large number of ideas for a given problem. During group brainstorming, participants can inspire each other to create new combinations of ideas through their contributions, which means that more results are produced overall than if everyone worked alone [DREW10]. Procedure: 1. Preparation: The moderator presents the problem / topic to the participants 2. Implementation: The participants come up with ideas for finding a solution and inspire each other in the process. 3. Conclusion: All ideas are written down, sorted and evaluated The most important rules:  The more ideas the better  Expand on and improve existing ideas  The more unusual the idea, the better (thinking outside the box)  Do not criticise 7.9.2.3 Morphological matrix According to its inventor F RITZ Z WICKY , the morphological matrix should enable a complete solution to a given problem. The technique first breaks down a problem or challenge into distinct sub-aspects, which can then lead to new solutions through targeted recombination [SCHM15]. Procedure: 1. Preparation: The determining characteristics are defined and listed with respect to a problem (= WHAT). Then, all possible forms of the respective characteristic are noted on the right (= HOW). The matrix that is created contains every combination of forms of all characteristics that theoretically represents a solution. 2. Implementation: One characteristic is selected from each line, resulting in a combination of characteristics 3. Conclusion: The combinations are evaluated and discussed. This is followed by an evaluation of the alternatives and the selection of a solution The most important rules:  Restriction to a maximum of 10 independent characteristics (= WHAT)  Restriction to a maximum of 10 characteristics (= HOW) per characteristic <?page no="219"?> Page | 219  The combination of the best partial solutions does not necessarily lead to the best overall concept 7.9.2.4 Brainstorming paradox The 'paradox' method is a creativity technique for solving problems and finding ideas. It is based on reversing the original task, which is why it is also referred to as a reversal technique or flip-flop technique. It exploits the natural human tendency to criticise. Procedure: 1. Preparation: Turn the challenge on its head - reformulate the challenge, i.e. not ‘What do we have to do to be successful? ’ but ‘What do we have to do to fail successfully? ’ 2. Implementation: Collect ideas on how not to do it (e.g. brainstorming, brainwriting). Summarise and sort the negative ideas. 3. Conclusion: Turn the negative ideas into positives and use them as inspiration for the ‘right’ ideas. The most important rules:  The rules of brainstorming apply (see above) 7.10 Results orientation Results orientation (4.4.10) ‘R ESULTS ORIENTATION means that individuals maintain a critical focus on the project's results. ... The results are always at the forefront of discussions, and the team strives for these results.’ [GPM17a, page 101] A focus on results is the orientation of the thoughts and actions of the project team members towards achieving the project goal. This is also reflected in the two perspectives on this topic - project and project management [PATZ17, GPM17b]. 7.10.1 Perspective: project 4.4.10 Results orientation / Competence level 1 At the project level, the focus is on creating the product or implementing the project in terms of content. More specifically, it is about  drawing the team's attention to the key objectives  observing ethical, legal and ecological requirements. 7.10.2 Perspective: project management 4.4.10 Results orientation / Competence level 1 At the project management level, the focus is on the implementation of the project, which is divided into methodological (schedule, costs, change management, risk manage- <?page no="220"?> 220 | Page ment, etc.) and social aspects (conflict management, (stakeholder) communication, motivation, (team) leadership, etc.). This includes, for example:  Managing approved changes  Identifying risks and utilising opportunities to generate additional successes  Taking into account legal and regulatory requirements  Satisfying the most important interested parties  Managing and motivating the team and taking its expectations into account A focus on results is therefore a key competence with links and interfaces to all the other competence elements of the ICB 4. Differentiation Efficiency vs. Effectiveness Efficiency describes the relationship between the means used (costs) and the success achieved (benefits) and thus provides information about the economic viability of an action or measure. A high level of efficiency is achieved when a given goal is reached with the least possible effort or when the highest possible yield is achieved with the given means [SCHU21]. ‘Doing things right’ Effectiveness refers to the degree to which an action or measure achieves its goal. A high degree of effectiveness is achieved when there is a high correlation between the desired goal and the actual result [SCHU21]. Synonyms: efficacy, efficiency ‘Doing the right things.’ 7.11 Change and transformation Change and transformation (4.5.13) ‘C HANGE (meaning: modification, improvement of a current situation, taking into account the past) and T RANSFORMATION (development arising from new situations, based on a vision of the future) provide the processes, tools and techniques that can help individuals and organisations to make successful transitions in terms of personnel and organisation, resulting in the acceptance and adoption of change.’ [GPM17a, page 160] Change management can be understood in two ways: organisational change or changes to the time, scope and cost of the project. This competence element is concerned with change management in the sense of ‘management of change’ (organisational change). Change management in the sense of ‘change control’, is part of competence element 4.5.1 Plan and control (  chapter 5.3 Configuration management and change management). <?page no="221"?> Page | 221 7.11.1 Techniques for change management 4.5.13 Change and transformation / Competence level 1 Lewin’s three-phases-model The relatively simple model of psychologist and social scientist K URT L EWIN helps to understand the change process in terms of ICB4 with its structured approach. L EWIN recognized that two fundamental forces operate in social systems - driving forces that provoke change and resistant forces that promote the preservation of the status quo and cannot be easily overcome [GPM17b, LAUE14]. In his model, he identifies three phases in which changes take place: Phase Explanation Unfreeze Preparing for change - communicating the plans and objectives, involving those affected by the change in the discussion, conducting analyses to motivate the organisation for the change. Change Implementing the changes - generating solutions, trying out new things, developing ways of reacting, leaving the status quo. This is reinforced by training those involved and monitoring the processes by those responsible. Refreeze ‘Re-familiarisation’ of the organisation - by stabilising and implementing the new structures, a relapse should be avoided and a new balance established. Table 73 - Phases of change acc. to Lewin Note A more popular approach is the eight-step model developed by J OHN P. K OTTER . He divides the change process into eight phases, which in turn can be categorised into three main categories [KOTT11]:  Create climate for change - (1) Sense of urgency | (2) Build a (leadership) coalition | (3) Create a vision and strategy  Engage and enable (mobilise) - (4) Communicate the vision | (5) Empower others, remove barriers | (6) Create quick wins  Implement and sustain - (7) Build on the change, derive further changes | (8) Embed the change In contrast to Lewin's model, Kotter describes a continuous process, which is evident in phase seven (derive further changes). <?page no="222"?> 222 | Page 7.11.2 Choice of approach The appropriate involvement of affected employees concerns not only factual but also cultural aspects. Acceptance of change does not come about through the mere presentation of finished concepts. Rather, it is achieved through the clear communication of the meaning and purpose of the change (  chapter 3.3.2.1 Objectives) and through planned stakeholder management (  chapter 3.3.2 Stakeholder management). It is important to involve the people affected in the design process in an appropriate way - an approach that aims to ‘turn those affected into participants’ (  chapter 7.4.4 Self-determination theory). In addition, the influence of corporate culture (  chapter 3.2.1.3 Environmental factors - culture and values) should not be underestimated. For the people involved, the process of change extends over several phases along a change curve. This phase model was originally developed in the 1960s by the Swiss American psychiatrist E LISABETH K ÜBLER -R OSS to explain the grieving process of a terminally ill patient. Since the 1980s, this change curve has been an integral part of change management. The emotions associated with it can be used to predict how the performance of the people affected will (probably) be influenced after a change has been announced and implemented [STOL13, PMI13]. The seven phases of the perceived personal competence to manage a challenging and novel change are described as follows 1. Shock Uncertainty; ‘What is happening here? ’; rumours arise. The person affected is inclined to redouble their efforts. 2. Disbelief The extent of the change is denied; blame; solidarity with the victims. 3. Self-doubt and the desire for a quick end. There is a risk of pseudo-solutions. Uncertainty about one's own abilities; lack of decision-making and fear of responsibility. Figure 102 - Emotional phases of change <?page no="223"?> Page | 223 4. Acceptance Glorification of the past; ‘We tried everything.’; Valley of tears; zone of loss; threshold to inner opening and reorientation. 5. Experimentation concentrating on new tasks; desire for manageable goals; willingness to learn. Success - failure - anger - frustration 6. Realisation why certain procedures and behaviours lead to success and others do not. 7. Integration of successful approaches into one's own repertoire of actions. Consolidation and starting point for new challenging changes. The ‘perceived self-competence’ refers to the factors of wanting to (motivation), being able to (ability) and being allowed to (authorisation). However, the conflicts that arise in different ways despite the early involvement of those affected should not be underestimated (  chapter 7.2.2 Conflict and crisis). “The best way to start a change process is with an inspiring vision of the future that awakens curiosity and fascination.” Peter Kruse (1955-2015), former Senator for Education and Science of the Free Hanseatic City of Bremen and author of ‘Successful Management of Instability’ (a.o.) 7.12 Literature [BANK17] Bank, S. (2017). Das ideale Projektteam: Fähigkeiten, Motivation und Teamzusammenstellung. Wiesbaden: Springer Gabler [BANN14] Bannick, S. (06. April 2014). Lessons Learned: Die Kunst, aus Erfahrungen nachhaltig lernen zu können. Abgerufen am 08. August 2023 von on operations: http: / / on-operations.com/ 2014/ 04/ 06/ lessons-learned-die-kunstaus-erfahrungen-nachhaltig-lernen-zu-konnen/ [BECK16] Becker, F. (2016). Teamarbeit, Teampsychologie, Teamentwicklung: So führen Sie Teams! Berlin: Springer Verlag [BELB10] Belbin, R. M. (3. Aufl. 2010). Management Teams. Why they succeed or fail. New York: Routledge [BELB18] BELBIN Deutschland e.K. (2018). Teamrollen. Abgerufen am 08. August 2023 von BELBIN Deutschland: https: / / www.belbin.de/ teamrollen/ [BEND14] Bender, S. (Juni 2014). Die 5 Axiome der Kommunikationstheorie von Paul Watzlawick. Abgerufen am 08. August 2023 von Kommunikation von Paul Watzlawick: https: / / www.paulwatzlawick.de/ axiome.html [BERG21] Bergmann, R., & Garrecht, M. (3., aktual. und erweit. Aufl. 2021). Organisation und Projektmanagement. Wiesbaden: Springer Gabler <?page no="224"?> 224 | Page [BLAN10] Blanchard, K. (2.. überarb. und erweit. Aufl. 2010). Leading at a Higher Level: Blanchard on Leadership and Creating High Performance Organizations. New Jersey: Financial Times Press [BLIC05] Blickhan, C. (2. Aufl. 2005). Die sieben Gesprächsförderer: Miteinander reden lernen. Paderborn: Junfermann Verlag [BOHI11] Bohinc, T. (12. Juli 2011). Kommunikation in virtuellen Teams. Teil 2: Medien richtig einsetzen | Projekt Magazin. Abgerufen am 08. August 2023 von Projekt Magazin - Das Fachportal für Projektmanagement: https: / / www.projektmagazin.de/ artikel/ kommunikation-virtuellen-teams-teil- 2_918956 [BORN15] Bornewasser, M., Schlick, C. & Bouncken, R. (2015). Teamkonstellation und betriebliche Innovationsprozesse. Wiesbaden: Springer Verlag [BÖS18] Bös, N. (31. Januar 2018). Beruflich online: Netiquette - nur nettes Etikett? Abgerufen am 08. August 2023 von Frankfurter Allgemeine - FAZ.NET: http: / / www.faz.net/ aktuell/ beruf-chance/ beruf/ beruflich-online-netiquettenur-nettes-etikett-15417416.html [BPB20] bpfish06b: Bundeszentrale für politische Bildung. (2020). Abgerufen am 08. August 2023 von Krise | bpb: https: / / www.bpb.de/ kurz-knapp/ lexika/ politiklexikon/ 17759/ krise/ [DICK13] van Dick, R., & West, M. A. (2., überarb. und erweit. Aufl. 2013). Teamwork, Teamdiagnose, Teamentwicklung. Göttingen: Hogrefe Verlag [DÖRN11] Dörner, D. (14. Aufl. 2011). Die Logik des Mißlingens. Strategisches Denken in komplexen Situationen. Reinbek: Rowohlt Taschenbuchverlag. [DREW10] Drews, G., & Hillebrand, N. (2. Aufl. 2010). Lexikon der Projektmanagement-Methoden. Freiburg: Haufe [EGLE21] Egle, G. (28.01.2021). Eisbergmodell. Abgerufen am 08. Auguast 2023 von teachSam - Lehren und Lernen online: http: / / www.teachsam.de/ psy/ psy_pers/ psy_pers_freud/ psy_pers_freud_5.htm [FISH06] Fisher, R., Ury, W., & Patton, B. (2006). Das Harvard-Konzept. Der Klassiker der Verhandlungstechnik. Frankfurt: Campus Verlag. [FREI16] Freitag, M. (2. Aufl. 2016). Kommunikation im Projektmanagement: Aufgabenfelder und Funktionen der Projektkommunikation. Wiesbaden: Springer Fachmedien. [GLAS17] Glasl, F. (11. Aufl. 2017). Konfliktmanagement: Ein Handbuch für Führungskräfte, Beraterinnen und Berater. Stuttgart: Freies Geistesleben. [GPM17a] Deutsche Gesellschaft für Projektmanagement e.V., (Hrsg.). (1., aktual. Aufl. 2017). Individual Competence Baseline für Projektmanagement, Version 4.0 / Deutsche Fassung (Bd. 1). Nürnberg: Deutsche Gesellschaft für Projektmanagement e.V. (GPM) [GPM17b] GPM, SPM, & Gessler, M. (Hrsg.). (8. Aufl. 2017). Kompetenzbasiertes Projektmanagement (PM3): Handbuch für die Projektarbeit, Qualifizierung <?page no="225"?> Page | 225 und Zertifizierung auf Basis der IPMA Competence Baseline Version 3.0. Nürnberg: GPM Deutsche Gesellschaft für Projektmanagement e.V. [GUBE17] Gubelmann, J., Scherler, H., & et al. (4., kompl. überarb. Aufl. 2017). Projektmanagement - Zertifizierung nach IPMA (ICB4)-Ebenen D und C. Zürich: Compendio Bildungsmedien [GUGE10] Gugel, G. (2010). Praxisbox Streitkultur. Konflikteskalation und Konfliktbearbeitung. Tübingen: Institut für Friedenspädagogik Tübingen e.V. [JONA14] Jonas, K., Stroebe, W., & Hewstone, M. (Hrsg.). (6., überarb. Aufl. 2014). Sozialpsychologie. Heidelberg: Springer Verlag [KALU12] Kaluza G. / Siebecke, D. (2012) Stressmanagement. In Hallenberg, F. & Lorei, C. (Hrsg.). (2012). Grundwissen Stress. Frankfurt: Verlag für Polizeiwissenschaften [KERZ22] Kerzner, H. (13. Aufl. 2022). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. Hoboken, New Jersey: Wiley [KKK06] Kaufmännische Krankenkasse (Hrsg). (2006). Stress? : Ursachen, Erklärungsmodelle und präventive Ansätze (Weißbuch Prävention), Heidelberg: Springer Verlag [KILM75] Kilmann, R. H., & Thomas, K. W. (01. Dez. 1975). Interpersonal Conflict- Handling Behavior as Reflections of Jungian Personality Dimensions. Psychological Reports, Volume 37 (Number 3), S. 971 - 980. Abgerufen am 08. August 2023 von https: / / www.kilmanndiagnostics.com/ interpersonalconflict-handling-behavior-reflections-jungian-personality-dimensions [KNIL10] Knill, H. (2010). Hoeren, Hinhoeren, Zuhoeren. Abgerufen am 08. August 2023 von rhetorik.ch: http: / / rhetorik.ch/ Hoeren/ Hoeren.html [KOTT11] Kotter, John P. (2011). Leading Change: Wie Sie Ihr Unternehmen in acht Schritten erfolgreich verändern. München: Vahlen Verlag [KREM16] Krems, B. (25. November 2016). Verantwortung, Verantwortungsarten. Abgerufen am 08. August 2023 von Online-Verwaltungslexikon für gutes öffentliches Management: https: / / www.olev.de/ uv/ verantwortung.htm [KREY05] Kreyenberg, J. (2. Aufl. 2005). Handbuch Konfliktmanagement. Berlin: Cornelsen Verlag [LAUE14] Lauer, T. (2. Aufl. 2014). Change Management: Grundlagen und Erfolgsfaktoren. Heidelberg: Springer Gabler [LENC14] Lencioni, P. (2014). Die 5 Dysfunktionen eines Teams. Weinheim: Wiley- VCH [MASL43] Maslow, A. (1943). A Theory of Human Motivation. Psychological Review Vol. 50, S. 307-396. Abgerufen am 08. August 2023 von Classics in the History of Psychology: http: / / psychclassics.yorku.ca/ Maslow/ motivation.htm [MOTZ17] Motzel, E., & Möller, T. (3., überarb. und aktual. Aufl. 2017). Projektmanagement Lexikon: Referenzwerk zu den aktuellen nationalen und internationalen PM-Standards. Weinheim: Wiley-VCH Verlag <?page no="226"?> 226 | Page [OELS09] von der Oelsnitz, D., & Busch, M. W. (2009). Teamlernen: Ansatzpunkte und Erfolgsvoraussetzungen. In Hünerberg, R. & Mann, A. (Hrsg.) (2009), Ganzheitliche Unternehmensführung in dynamischen Märkten (S. 249- 271). Wiesbaden: Springer [PINK11] Pink, Daniel H. (2011). Drive: The Surprising Truth About What Motivates Us. New York: Penguin Publishing Group [PMI13] Project Management Institute, Inc. (2013). Managing Change in Organizations: A Practice Guide. Pennsylvania: PMI Inc. [QUIN88] Quinn, R. E. (1988). Beyond Rational Management: Mastering the Paradoxes and Competing Demands of High Performance. San Francisco: Jossey-Bass [QUIN11] Quinn, R. E., & Cameron, K. S. (3. Aufl. 2011). Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework. San Francisco: Jossey-Bass [RHEI18] Rheinberg, F., & Vollmeyer, R. (9., erweit. und überarb. Aufl. 2018). Motivation (Bd. Grundriss der Psychologie Band 6). Stuttgart: Verlag W. Kohlhammer [RÖHN16] Röhner, J., & Schütz, A. (2. Aufl. 2016). Psychologie der Kommunikation. Wiesbaden: Springer Fachmedien. [SCHI14] Schildt, T. (2014). Wundertüte Konflikt: Der Praxisleitfaden für den erfolgreichen Umgang mit Konflikten. Berlin: Gerd Schilling [SCHM15] Schmitt, R., & Pfeifer, T. (5., aktual. Aufl. 2015). Qualitätsmanagement - Strategien - Methoden - Techniken. München: Carl Hanser Verlag [SCHU21] Schubert, K. & Klein, M. (8., überarb. Aufl. 2021.) Das Politiklexikon: Begriffe. Fakten. Zusammenhänge. Bonn: Dietz Verlag. [SEIW14] Seiwert, L. (2014). Das 1x1 des Zeitmanagement: Zeiteinteilung, Selbstbestimmung, Lebensbalance. München: Gräfe und Unzer Verlag [SICK10] Sicking, M. (05. Oktober 2010). Die Pflichten des Arbeitgebers. Abgerufen am 08. August 2023 von heise online: https: / / www.heise.de/ resale/ artikel/ Die-Pflichten-des-Arbeitgebers-1096367.html [SIGM16] Sigma Alpha Global Exchange Ltd. (Hrsg.). (2016) www.dasWirtschaftslexikon.com. Abgerufen am 08. August 2023 von Verhandlungskonzepte - das Wirtschaftslexikon.com: http: / / www.daswirtschaftslexikon.com/ d/ verhandlungskonzepte/ verhandlungskonzepte.htm [SIMO06] Simon, W. (2. Aufl. 2006). GABALs großer Methodenkoffer. Grundlagen der Kommunikation. Offenbach a.M.: Gabal [SPRE21] Sprenger, R. (Sonderausgabe 2021). Mythos Motivation: Wege aus einer Sackgasse. Frankfurt a.M.: Campus Verlag [STAN23] Stangl, W. (2023). Selbstbestimmungstheorie der Motivation. Online Lexikon für Psychologie & Pädagogik. Abgerufen am 13.08.2023 von https: / / lexikon.stangl.eu/ 28413/ selbstbestimmungstheorie-der-motivation. <?page no="227"?> Page | 227 [STOL13] Stolzenberg, K., & Heberle, K. (3. Aufl. 2013). Veränderungsprozesse erfolgreich gestalten - Mitarbeiter mobilisieren. Vision, Kommunikation, Beteiligung, Qualifizierung. Heidelberg: Springer Medien Verlag. [TANN58] Tannenbaum, R., & Schmidt, W. H. (1958). How to Choose a Leadership Pattern. Harvard Business Review (36), S. 95-101 [THOM16] Thommen, J.-P., Achleitner, A.-K., Gilbert, D. U., Hachmeister, D., & Kaiser, G. (8. Aufl. 2016). Allgemeine Betriebswirtschaftslehre. Umfassende Einführung aus managementorientierter Sicht. Wiesbaden: Springer Gabler [THUN03] Schulz von Thun, F., Ruppel, J., & Stratmann, R. (2003). Kommunikationspsychologie für Führungskräfte. Reinbek: Rowohlt Taschenbuch Verlag [THUN11] Schulz von Thun, F. (Sonderausgabe 2011). Miteinander Reden. Störungen und Klärungen. (Bd.1). Reinbek: Rowohlt Taschenbuch Verlag [TIMI24] Timinger, H. (2. Aufl. 2024). Modernes Projektmanagement. Mit traditionellem, agilem und hybridem Vorgehen zum Erfolg. Weinheim: Wiley-VCH Verlag [WELT] Stiftung Weltethos (Hrsg.). (0.J.). A Global Ethic Now - Eine Lernplattform der Stiftung Weltethos. Abgerufen am 08 August 2023 von https: / / www.weltethos.org/ ueber-die-stiftung/ faqs/ [WUND11] Wunderer, R. (9., neu bearb. Aufl. 2011). Führung und Zusammenarbeit. Köln: Wolters Kluwer <?page no="229"?> Page | 229 8 An overview of the Agile World Agile approaches to work are a response to an increasingly complex project environment. This environment, often referred to as the VUCA world (VUCA stands for volatility, uncertainty, complexity, ambiguity), requires a flexible way of working. V Volatility - Changes in the project and corporate environment are becoming more frequent, more rapid and more extreme. U Uncertainty - Predictions about future events are hardly possible anymore. C Complexity - Our environment is becoming increasingly interconnected, and the interdependencies between topics are becoming increasingly opaque. A Ambiguity - It is becoming increasingly difficult to make accurate assessments; facts can be interpreted in different ways. Table 74 - The VUCA world The basic idea of agile working and the starting point for a response to the challenges of the VUCA world is the Agile Manifesto, formulated in 2001 by 17 renowned software developers. This manifesto defines, along with 12 principles, four well-known value pairs:  individuals and interactions are more important than processes and tools  working software is more important than comprehensive documentation  customer collaboration is more important than contract negotiations  responding to change is more important than following a fixed plan This means that although the values on the right are important, the values on the left are more important. Each value is only fully effective when it is in balance with its counterpart [BRAN14]. The Agile Manifesto, although originally developed in software development, represents a significant milestone in the Agile movement. In the sense of the so-called Sinatra test (‘If I can make it there, I'll make it anywhere’) 39 , the experience gained in the complex world of software development is increasingly being applied to other industries, such as automotive (vehicle development at companies like TESLA, MAN, e.GO Mobile), pharmaceutical (product development at companies like Roche Diagnostics) and services (development of services at companies like DB Fernverkehr). 39 ‘An example passes the Sinatra Test when one example alone is enough to establish credibility in a given domain. For instance, if you've got the security contract for Fort Knox, you're in the running for any security contract (even if you have no other clients).’ [HEAT10, page 151] Figure 103 - Basis of empiricism <?page no="230"?> 230 | Page Agile working is not a rigid process chain with input-process-output and a clearly defined process owner. Agility means continuously developing and adapting. The basis for this is the theory of empiricism. This means that knowledge is gained from experience and targeted observations, and decisions are made on the basis of these findings. The core of the empirical approach is transparency, review and adaptation [SUTH20]. “An empirical scientific system must be able to fail based on experience.” Sir Karl Raimund Popper, Austrian-British philosopher Differentiation complicated vs. complex Complicated - all components of a system and the possibilities that arise from their links are known, cause and effect can be understood and estimated. Example: assembly instructions for a LEGO ® Star Wars™ Millennium Falcon™ (7541 parts) Complex - it is no longer possible to grasp the interplay of cause and effect intuitively and there is no way to make exact predictions. The same action can have a different effect than planned / expected in the short term. Long-term consequences of interventions are not foreseeable. Example: autonomous driving Agile methods can provide an effective framework for initiating change. Nevertheless, this process does not happen overnight. The transformation of corporate culture - the lengthy path from the application of agile practices and tools to the firm establishment of an agile mindset 40 in the organisation - requires a lot of time, persistence and determination. This journey is never complete; evolution is a continuous process [LALO15]. Figure 104 - Agility - from ‘doing’ to ‘being“ Two widely used agile methods are Scrum (J. S UTHERLAND & K. S CHWABER ) , and Kanban (T AIICHI O HNO ), which will be explained in more detail in the following chapters. 8.1 Scrum Scrum is a framework for developing, delivering, and maintaining complex products. The definition of Scrum and the associated roles, events, and artefacts are defined and explained in the Scrum Guide™. 40 Certain logic of thought and action based on basic assumptions, values and principles. <?page no="231"?> Page | 231 Scrum is based on empirical principles and a personal attitude, which are represented by the five agile values in the current Scrum Guide: commitment, courage, focus, openness, and respect [SUTH20]. 8.1.1 Timeboxing 4.5.4 Time / Competence level 1 Timeboxing is a fundamental technique in agile methods. Strict adherence to predefined deadlines is particularly important in an agile approach. This applies to meetings (e.g. events like the Daily Scrum) and iterations (sprints). The principle of timeboxing is: Before the fixed duration (timebox) for a meeting is exceeded, the agenda will be reduced [PREU20, RUBI14]. Examples of timeboxes in Scrum can be found in the following table, based on [BAHL21]. Sprint length  Event  4 weeks 3 weeks 2 weeks 1 week Sprint Planning 8 hours* 6 hours* 4 hours* 2 hours* Daily Scrum 15 minutes* 15 minutes* 15 minutes* 15 minutes* Sprint Review 4 hours* 3 hours* 2 hours* 1 hour* Retrospective 3 hours* 135 minutes* 90 minutes* 45 minutes* * Recommended timebox based on sprint length Table 75 - Recommended timebox per event based on sprint length 8.1.2 Roles 4.4.6 Teamwork | 4.5.5 Organisation and information / Competence level 1 The Scrum team consists of the product owner, the developers and the scrum master. It is responsible for implementation and accountable for results. A scrum team usually consists of 10 or fewer people. [SUTH20]. Product Owner (PO) − is responsible for the product and the effective management of the product backlog (creating entries, defining the priority, ensuring transparency) − represents the client − ensures maximum value of the product Developers are responsible for: − creating the sprint backlog − adhering to the definition of done − achieving the sprint goal − holding each other to account Scrum Master (SM) − is responsible for promoting Scrum in accordance with the Scrum Guide − helps all participants to understand the theory, practices, rules and values <?page no="232"?> 232 | Page − ensures that events come about − helps to optimise collaboration − coaches the developers and the organisation during the introduction of Scrum Table 76 - Roles in Scrum Figure 105 - Sprint with events, artefacts and roles 8.1.3 Scrum Events Scrum uses mandatory events. All events are time-boxed. With the exception of the sprint as a container for all other events, each Scrum event is a formal opportunity for inspection and adaptation. 8.1.3.1 Sprint 4.5.1 Project design | 4.5.4 Time / Competence level 1 A sprint is a short, time-limited iteration (= independent cycle) in which all work is carried out to achieve a valuable result. The typical timebox for a sprint varies between one and four weeks [RUBI14]. A sprint includes the sprint planning, the daily scrums, the sprint review and the sprint retrospective. Sprints can be cancelled at the instruction of the product owner if they consider the sprint goal to be obsolete [SUTH20]. <?page no="233"?> Page | 233 8.1.3.2 Sprint Planning During the sprint planning, the work for the upcoming sprint is planned. The basis for this is the evaluated and prioritised contents of the product backlog (  section 8.1.4.1). The sprint planning is divided into two parts: in the first part, it is determined what is developed in the sprint and the sprint goal is defined. In the second part, the development team considers how the requirements are implemented. The sprint goal manifests what the team commits itself to in the sprint. It thereby represents the commitment of the developers for this sprint [SUTH20]. Part 1 Participants: Product Owner, Developers Timebox: 2 hours per week of sprint length Part 2 Participants: Developers (Product Owner, Scrum Master, if required) Timebox: 2 hours per week of sprint length 8.1.3.3 Daily Scrum The Daily Scrum takes place every day of the sprint. The developers plan the work for the next 24 hours and review the work done since the last Daily Scrum [SUTH20]. Usually, but not mandatory, the participants answer the following questions 1. What have I done since the last Daily Scrum? 2. What will I have done by the next Daily Scrum? 3. Is there an obstacle that prevents me from doing what I planned? Participants: Developers Timebox: 15 minutes daily, during the sprint 8.1.3.4 Sprint Review 4.5.5 Organisation and information | 4.5.10 Plan and control / Competence level 1 The Sprint Review is held at the end of the sprint. During the review, the developed product increment is checked and, if necessary, the Product Backlog is adjusted. In addition to the developers, the Product Owner and other stakeholders are present. The review is not a status report, but an informal meeting. It offers the opportunity for suggestions and feedback from those present and thus provides input for the upcoming Sprint Planning [SUTH20]. Participants: Product Owner, Developers, Stakeholders Timebox: Timebox: 1 hour per week of sprint length 8.1.3.5 Sprint Retrospective 4.5.1 Project design | 4.5.10 Plan and control / Competence level 1 The Retrospective offers the Scrum team an opportunity to review itself and its collabo- <?page no="234"?> 234 | Page ration (relationships, processes). The goal is to identify possible improvements and to develop a plan for implementing these improvements in the upcoming sprint. A retrospective is conducted in five phases [DERB24, DRÄT14, KERT01]: 1 Set the Stage (preparation) To Do: Welcome participants, pick them up, give them the opportunity to arrive at the meeting, focus on a common goal. If no rules have yet been set, formulate a collective ‘agreement for cooperation’. Two helpful ground rules: • Vegas Rule - ‘What happens in Vegas, stays in Vegas’ - the confidentiality agreement • Golden Rule - ‘All participants show mutual respect and appreciation. The emphasis is not on blaming or knowing-it-all, but on collective teamwork in which everyone contributes their best.’ - no blaming 2 Gather Data To Do: Collective reflection on the past sprint, e.g. what was positive / negative? Create a timeline of the period under review, e.g. with 4L questions (love, learned, lacked, longed for) 3 Generate Insights To Do: Find the causes (observe the golden rule) as a basis for improvements  e.g. 5W questions, the 4 core questions 41 , cause-and-effects diagram 4 Decide What to Do (Action plan) To Do: Define measures for the improvements identified  e.g. ‘Starfish’; Who-What-By When; SMART goals 5 Closure To Do: Thank the participants for their commitment and cooperation; Inspect and Adapt for the next retrospective, document results, get feedback on the moderation Table 77 - Phases of the retrospective A simple format for phase four of the retrospective is the ‘Starfish’ method. Participants: Product Owner, Scrum Master, Developers Timebox: 45 minutes per week of sprint length 41 According to [KERT01]: What do we need to remember that went well so we don't forget it? | What have we learned? | What should we do differently next time? | What still surprises us? <?page no="235"?> Page | 235 Figure 106 - The ‘starfish’ as a method in the retrospective 8.1.4 Scrum Artefacts Artefacts in Scrum represent work or value and, through the information they contain, create a high degree of transparency for all parties involved. This facilitates the possibility for inspection and adaptation. Each artefact contains a commitment that ensures that information is provided to improve transparency and to measure progress [SUTH 20]. 8.1.4.1 Product Backlog 4.5.1 Project design | 4.5.2 Requirements and objectives | 4.5.3 Scope | 4.5.6 Quality / Competence level 1 The product backlog is an ordered list of all product functionalities that are to be implemented in the current project. The individual functionalities are prioritised and formulated as user stories. The backlog is dynamic and is continuously developed (emergent) to identify requirements that improve the product, make it more useful and increase its competitiveness [FOEG16, RUBI14]. Commitment: The long-term product goal describes a future state of the product and serves as a planning target for the Scrum team. The key attributes of a good product backlog are listed in the acronym ‘DEEP’ [DRÄT23] D ETAILED APPROPRIATELY The requirements for the product are clearly recognizable and comprehensibly described. E MERGENT (= flexible, variable) The Product Backlog is never complete. It is continuously updated based on new information. User Stories are continuously added, removed or re-prioritised. <?page no="236"?> 236 | Page E STIMATED Each user story has been estimated by the developers, e.g. in a refinement meeting. P RIORITISED The user stories are ranked in order of their economic viability and necessity or urgency for their processing. Table 78 - DEEP criteria for product backlogs A user story (also known as a product backlog item) is written in a way that can be understood by both commercial and technical staff. It is simply structured and is usually expressed in the following format:  I as (role)  want (function, goal)  so that (benefit, advantage). The last part (benefit, advantage) is of great importance because it represents the reason for the requirement and is potentially the starting point for alternative considerations [RUBI14]. In addition, an acceptance criterion is defined that can be used to check whether the function has been successfully developed or whether the objective has been achieved. Well-formulated user stories follow the INVEST criteria [DRÄT23]. This means that user stories are … I NDEPENDENT ... of each other or at best loosely connected. Intertwined stories make estimating, prioritising and planning more difficult. N EGOTIABLE They do not constitute a written contract but serve as a basis for negotiating details. V ALUABLE They must have value for the customer / user, otherwise their implementation makes no sense. E STIMABLE They must be estimable by those who implement them. Estimates provide an indication of the size and thus the effort and costs. S IZED APPROPRIAT - ELY , S MALL They must be large enough to represent a (business) value in terms of the planned implementation time, but small enough to be implemented in the planned time. T ESTABLE They must have verifiable acceptance criteria. Table 79 - INVEST criteria for user stories A story map is useful for visualising the entire project. A story map presents a usercentred perspective of a certain number of user stories. Users' activities are broken down into a workflow (theme) and then into further detailed tasks (user stories). A theme thus represents a collection of related user stories. A so-called epic can be placed one level higher. An epic is a synonym for a large requirement that is refined at an appropriate time [RUBI14]. <?page no="237"?> Page | 237 Figure 107 - Story map 8.1.4.2 Sprint Backlog The sprint backlog represents the selection of product backlog items to be implemented for the current sprint (what). It serves as a prediction by the developers of which functionalities will be included in the next increment of the product. This creates transparency regarding the work deemed necessary by the developers to achieve the sprint goal (why). Ideally, the sprint backlog also integrates improvement measures that have emerged from the last retrospective to ensure continuous development. [SUTH20, RUBI14]. In addition, the Definition of Ready (DoR) is an important part of the agile development process. It defines the criteria that must be met for a user story to be included in the sprint. A user story must be clearly defined, estimated and prioritised in order to be included in the sprint. The DoR ensures that the development team has clear guidelines on when a user story can be considered ready for implementation, thus promoting efficiency and clarity during the sprint planning process. Commitment: Sprint goal - The goal for the sprint, creates cohesion and focus, encourages the scrum team to work together. 8.1.4.3 Increment A product increment is the result of a sprint and is understood as a finished piece of the overall product that adds independent new functionalities. Each increment is cumulative of all previous increments. Thorough testing before delivery ensures that all increments work together [SUTH20, DRÄT23]. Commitment: Definition of Done - the formal description of the required quality characteristics of the increment. <?page no="238"?> 238 | Page The Definition of Done (DoD) is a checklist of sorts, listing all the work that the development team must successfully complete before declaring their work as potentially shippable. It ensures that all the necessary aspects, such as quality, documentation and functionality, are covered to ensure a smooth delivery [RUBI14]. Example of a (simplified) Definition of Done:  Design reviewed  Code completed  User documentation updated  Tests executed  Acceptance tested  Live on production server Another relevant concept is the description of the Minimum Viable Product (MVP). This is the basic version of a product or application that offers sufficient functionality to demonstrate real value to users. The MVP helps to quickly obtain feedback and make improvements based on that feedback. 8.2 Kanban 4.5.1 Project design | 4.5.4 Time | 4.5.10 Plan and control / Competence level 2 Kanban (Japanese for signal card) was originally developed in 1947 by T AICHI O HNO as part of the Toyota production system to control production processes. Although it does not have the same roots as most agile methods, it is often associated with them. Kanban is characterised by four basic principles and six core properties [ANDE12, EISE22]. The four basic principles are: 1. Start with what you have at the moment. 2. Agree with others to strive for incremental, evolutionary change 3. Respect the existing process, roles, responsibilities and job titles 4. Promote leadership at all levels in the organisation These include the six core characteristics: 1. Visualise the workflow 2. Limit the amount of work in progress (WIP) 3. Measure and control the workflow 4. Make the rules for the process explicit 5. Use models 42 to identify opportunities for improvement 6. Establish feedback loops (e.g. daily stand-ups, review meetings) 42 Practical models proposed by D. Anderson [ANDE12]: − Theory of Constraints (ToC) → examination of bottlenecks − System of Profounded Knowledge (E. Deming) → examination of deviations and their effects − Lean economic model → based on the idea of waste (muda, mura, muri) <?page no="239"?> Page | 239 Kanban is neither a software development method nor a project management approach. The method builds on an existing process in order to incrementally change it. A central aspect for the implementation of Kanban is the Kanban board. It contains at least three columns (e.g. ‘Open’, ‘In progress’, ‘Done’) that represent the phases of the process. Figure 108 - Kanban board (example) Kanban boards can be either physical (e.g. two by three metres [NOWO18A]) or digital (e.g. Kanban tools, Trello, Jira). The basic idea is to visualise the path of tasks from request (‘Open’) to completion (‘Done’) and, if necessary, to identify and react to bottlenecks. In addition to visualisation, the second core characteristic is the limitation of the amount of work started, known as work in progress (WIP). The aim of WIP is to avoid taking on too much work at once and to prevent getting tangled up in a lot of parallel tasks. The size of WIP is not fixed. Typically, each employee should have no more than two items in progress. However, there is no ‘magic formula’ for WIP limits; the numbers can be repeatedly adjusted based on empirical observations [NOWO18A, ANDE12]. 8.3 Literature [ANDE12] Anderson, D. J. (2012). Kanban. Evolutionäres Change Management für IT-Organisationen. Heidelberg: dpunkt.Verlag [BAHL21] Bahlow, J., & Kullmann, G. (2021). Agile Teams: Neue Herausforderungen fokussiert meistern. Göttingen: BusinessVillage GmbH <?page no="240"?> 240 | Page [BRAN14] Brandes, U., Gemmer, P., Koschek, H., & Schültken, L. (2014). Management Y: Agile, Scrum, Design Thinking & Co.: So gelingt der Wandel zur attraktiven und zukunftsfähigen Organisation. Frankfurt a.M.: Campus Verlag [DERB24] Derby, E., Larsen, D., & Horowitz, D. (2. Aufl. 2024). Agile Retrospectives: A Practical Guide for Catalyzing Team Learning and Improvement. Dallas: The Pragmatic Bookshelf [DRÄT14] Dräther, R. (2014). Retrospektiven - kurz & gut. Köln: O’Reilly Verlag [DRÄT23] Dräther, R., Koschek, H., & Sahling, C. (3. Aufl. 2023). Scrum - kurz & gut. Köln: O’Reilly Verlag [EISE22] Eisenberg, F. (2., aktual. Aufl. 2022). Kanban - mehr als Zettel: Wie die Methode Ihnen zu echtem Mehrwert verhilft. München: Carl Hanser Verlag [FOEG16] Foegen, M., & Kaczmarek, C. (3. Aufl. 2016). Organisation in einer digitalen Zeit. Darmstadt: wibas GmbH [HEAT10] Heath, C. & Heath, D. (2010). Made to Stick: Why Some Ideas Survive and Others Die. London: Random House Trade Paperbacks [KENT03] Kent, B. (2003). Extreme Programming - Das Manifest. München: Addison-Wesley Verlag [KERT01] Kerth, N. (2001). Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing [LALO15] Laloux, F. (2015). Reinventing Organizations: Ein Leitfaden zur Gestaltung sinnstiftender Formen der Zusammenarbeit. München: Verlag Franz Vahlen [NOWO18a] Nowotny, V. (4. Aufl. 2018). Agile Unternehmen. Nur was sich bewegt, kann sich verbessern. Göttingen: BusinessVillage GmbH. [NOWO18b] Nowotny, V., & Lasnia, M. (2018). Agile Evolution. Eine Anleitung zur agilen Transformation. Göttingen: BusinessVillage GmbH [PREU20] Preußig, J. (2. Aufl. 2020). Agiles Projektmanagement. Agilität und Scrum im klassischen Umfeld. Freiburg: Haufe-Lexware [RUBI14] Rubin, K. S. (2014). Essential Scrum - Umfassendes Scrum-Wissen aus der Praxis. Frechen: mitp Verlag [SUTH20] Sutherland, J., & Schwaber, K. (2020). The Scrum Guide - 2020- Scrum-Guide-German. Abgerufen am 08. August 2023 von https: / / www.scrumguides.org/ docs/ scrumguide/ v2020/ 2020-Scrum- Guide-German.pdf <?page no="241"?> Page | 241 9 Overview ICB4 elements and mapping to chapters ICB element Chapter / page Comp. level Cert. level Perspective 4.3.1 Strategy 2.1.1 2.1.3 2.1.4 2.2.1 3.2.1 Vision, mission, strategy / 33 Success factors / 36 Benefit analysis / 36 Business case / 38 Environment analysis / 48 1 1 1 1 2 D 4.3.2 Governance, structures and processes 1.1 1.2 1.3 1.6 3.5.1.4 Terminology (project, PM, process, task) / 20 Project management office / 21 Project types / 22 Standards in PM / 27 Steering committee / 81 1 D 4.3.3 Compliance, standards and regulations 1.6 3.2.1.1 3.2.1.2 3.2.1.4 7.5.5 Standards in PM / 27 Legal conditions / 50 Hazard analysis / 53 Sustainability / 55 Management responsibilities and duties of the project manager / 197 1 1 1 1 1 D D D C C 4.3.4 Power and interests 3.2.2 7.1.1 Stakeholder management / 60 Reflection on one’s own team role / 161 2 2 D C 4.3.5 Culture and values 3.2.1.3 7.2.3 Environment - culture and values / 53 Ethics and personal values / 168 1 D/ C People 4.4.1 Self-reflection and self-management 3.2.1.5 7.1.1 7.1.2 7.1.3 SWOT analysis / 57 Reflection of one’s own team role (  Johari window) / 161 Self-management (  Eisenhower matrix) / 162 Dealing with stress / 163 1 2 2 1 D C Basis/ D <?page no="242"?> 242 | Page ICB element Chapter / page Comp. level Cert. level 4.4.2 Personal integrity and reliability 3.2.1.4 7.2.1 7.2.2 7.2.3 Environment - sustainability / 55 Personal error culture / 167 Reliability, trust, … / 167 Ethics and personal values / 168 1 D C 4.4.3 Personal communication 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 Communication models / 172 Communication channels / 175 Perceptual disorder / 177 Facilitate open communication / 177 Virtual teams / 181 2 1 2 1 1 Basis/ D D C Basis/ D Basis/ D 4.4.4 Relationships and engagement 7.4.1 7.4.2 7.4.3 7.4.4 Motivation and motivating / 182 Maslow’s hierarchy of needs / 183 Herzberg’s two-factor theory / 184 Self-determination theory / 185 1 D 4.4.5 Leadership 7.5.1 7.5.2 7.5.3 7.5.4 Leadership styles / 188 Lateral leadership / 195 Leadership roles / 195 Management concepts / 197 1 D 4.4.6 Teamwork 7.6.1 7.6.2 7.6.3 7.6.4 7.6.5 8.1.2 Team concept / 198 Team development / 201 Success factors / 202 Specific team effects / 202 Team learning / 203 Roles (agile) / 231 1 Basis/ D 4.4.7 Conflict and crisis 7.7.1 7.7.2 7.7.3 7.7.4 7.7.5 Definition / 204 Causes of conflict / 205 Conflict escalation / 205 Action strategies / 207 Cooperative conflict resolution / 209 1 D 4.4.8 Resourcefulness 7.9.1 7.9.2 Problem solving / 213 Creativity methods / 217 1 Basis/ D <?page no="243"?> Page | 243 ICB element Chapter / page Comp. level Cert. level 4.4.9 Negotiation 7.8.1 7.8.2 Negotiation - concept and situation / 210 The Havard concept / 211 1 D 4.4.10 Results orientation 7.10 Results orientation / 219 1 D Practice 4.5.1 Project design 1.1 1.3 1.4 1.5 2.1.3 3.3.1 3.4 3.5.1 6.1 8.1 8.2 Terminology / 20 Project types / 22 Project success / project management success / 23 PM approaches and process models / 24 Success factors / 36 Requirements / 67 Project phases / 75 Project organisation / 78 Project closure / 155 Scrum / 232 Kanban / 238 1 Basis/ D 4.5.2 Requirements and objectives 2.2.2 2.2.3 3.3.1 3.3.2 4.7.4 8.1.4.1 Project profile / 38 Project canvas / 38 Requirements / 67 Objectives / 69 Acceptance criteria / 135 Product Backlog / 235 2 1 2 Basis/ D 4.5.3 Scope 4.1.1 4.1.2 4.1.3 8.1.4.1 Structuring the scope / 92 Procedure / 100 Work package definition / 100 Product Backlog / 235 2 2 1 Basis/ D <?page no="244"?> 244 | Page ICB element Chapter / page Comp. level Cert. level 4.5.4 Time 3.4 4.2 4.3.3 8.1.1 8.1.3.1 8.2 Project phases / 75 Time (scheduling) / 102 Estimation methods / 115 Timeboxing / 231 Sprint / 232 Kanban / 238 2 2 2 1 1 2 Basis/ D 4.5.5 Organisation and information 3.5.1 3.5.2 3.5.2.2 3.5.2.3 3.5.3 3.5.4 8.1.2 8.1.3.4 Project organisation / 78 Congruence principle / 82 TCA matrix / 82 RACI matrix / 83 Information management / 84 Document management / 85 Roles (agile) / 231 Sprint Review / 233 2 1 1 1 2 Basis/ D 4.5.6 Quality 4.7.1 4.7.3 4.7.4 7.9.1.3 8.1.4.1 Process (principles of quality management) / 131 Deming cycle / 135 Acceptance criteria / 136 FMEA / 216 Product Backlog / 237 1 Basis/ D 4.5.7 Cost and finance 4.2.2 4.3.3 4.4.1 4.4.3 Cost planning / 118 Estimation methods / 115 Cost type, -centre, -unit / 117 Cost histogram, total cost curve / 119 2 1 2 D D Basis/ D 4.5.8 Resources 4.3.1 4.3.2 4.5.1.2 4.5.3 Resource types / 111 Resource planning / 111 Types of request / 122 Defaults of request / 123 2 Basis/ D 4.5.9 Procurement 4.5.1 4.5.1.1 4.5.2 4.5.4 Procurement / 120 Make-or-buy / 121 Contracts, contract types / 122 Acceptance / 124 1 D <?page no="245"?> ICB element Chapter / page Comp. level Cert. level 4.5.10 Plan and control 3.1 5.1.1 5.2 5.3 6.1 8.1.3.4 8.1.3.5 8.2 Project start / 45 Progress measurement / 140 Reporting - status report / 149 Configuration management and change management / 150 Project closure / 155 Sprint review / 233 Sprint retrospective / 233 Kanban / 238 1 Basis/ D 4.5.11 Risk and opportunity 4.6.1 4.6.2 Risk & opportunity - basics / 125 Process / 126 2 Basis/ D 4.5.12 Stakeholders 3.2.1 3.2.2 Environment analysis / 48 Stakeholder management / 59 2 Basis/ D 4.5.13 Change and transformation 7.11.1 Techniques for change management / 221 1 D <?page no="247"?> Page | 247 10 Abbreviations A AC - Actual Cost ANSI - American National Standards Institute ArbSchG - Arbeitsschutzgesetz ArbStättV - Arbeitstättenverordnung ArbZG - Arbeitszeitgesetz ARGE - Arbeitsgemeinschaft AsiG - Arbeitssicherheitsgesetz B BAC - Budget At Completion BATNA - Best Alternative To a Negotiated Agreement BauA - Bundesanstalt für Arbeitssicherheit und Arbeitsmedizin BDSG - Bundesdatenschutzgesetz BetrVG - Betriebsverfassungsgesetz BGB - Bürgerliches Gesetzbuch BImSchG - Bundes-Immissionsschutzgesetz BpersVG - Bundespersonalvertretungsgesetz BverfGE - Bundesverfassungsgericht C CIP - Continuous Improvement Process CM - Configuration Management CoEPM - Centre of Excellence in Project Management CPI - Cost Performance Index CSR - Corporate Social Responsibility CTA - Cost Trend Analysis CV - Cost Variance D DE - Damage Extent DEEP - Detailed appropriately, Emergent, Estimated, Prioritised DIN - Deutsches Institut für Normung DNK - Deutscher Nachhaltigkeitskodex DoD - Definition of Done DoR - Definition of Ready E EAC - Estimate At Completion EF - Early Finish time ES - Early Start time EV - Earned Value EVA - Earned Value Analysis F FF - Finish-to-Finish FF - Free Float (buffer) FMEA - Failure Mode and Effects Analysis FS - Finish-to-Start G GLOBE - Global Leadership and Organizational Behaviour Effectiveness Research Program GPM - Deutsche Gesellschaft für Projektmanagement e.V. H HSSE - Health, Safety, Security and Environment I ICB - Individual Competence Baseline IEEE - Institute of Electrical and Electronical Engineers INVEST - Indipendent, Negotiable, Valuable, Estimable, Sized appropriately, Testable IPMA - International Project Management Association ISO - International Organization for Standardization J JarbSchG - Jugendarbeitsschutzgesetz K KonTraG - Gesetz zur Kontrolle und Transparenz im Unternehmensbereich <?page no="248"?> 248 | Page KVP - Kontinuierlicher Verbesserungsprozess L LF - Late Finish time LR - Logical Relationship LS - Late Start time M MTA - Milestone Trend Analysis MuSchG - Mutterschutzgesetz MVP - Minimum Viable Product N NVC - Non-Violent Communication P PC - Planned Cost PDCA - Plan, Do, Check, Act PERT - Program Evaluation and Review Technique PESTEL - Political, Environmental, Social, Technological, Economical, Legal PM - Project Manager, also (rarely): Project Management PMBok - Project Management Body of Knowledge PMI - Project Management Institute PMO - Project Management Office PO - Product Owner POC - Percentage Of Completion PRINCE 2 - Projects In Controlled Environments Version 2 PV - Planned Value R RACI - Responsible, Accountable, Consulted, Informed RAMS - Reliability, Availability, Maintainability, Safety RASCI - Responsible, Accountable, Supportant, Consulted, Informed RFF - Request for Feature RFI - Request for Information RFP - Request for Proposal RFQ - Request for Quotation ROI - Return on Investment RPN - Risk Priority Number RP - Risk Probability RV - Risk Value S SC - Steering Committee SDG - Sustainable Development Goal SDT - Self-Determination Theory SF - Start-to-Finish SM - Scrum Master SMART - Specific, Measurable, Accepted, Realistic, Timed SS - Start-to-Start SV - Schedule Variance T TCA - Task, Competence, Accountability TF - Total Float (buffer) TKI - Thomas-Kilmann Conflict Mode Instrument ToC - Theory of Constraints TOP - Technical, Organisational, Personnel U UVV - Unfallverhütungsvorschrift US-GAAP - United States Generally Accepted Accounting Principles V VDI - Verband Deutscher Ingenieure VoC - Voice of Customer VUCA - Volatility, Uncertainty, Complexity, Ambiguity W WBS - Work Breakdown Structure WIP - Work in Progress WP - Work Package WPO - Work Package Owner (also: WPM, Work Package Manager) X XP - Extreme Programming <?page no="249"?> Page | 249 11 Tables and figures 11.1 Tables Tab. 1 GPM Competence levels ..................................................................................... 16 Tab. 2 Terminology......................................................................................................... 21 Tab. 3 TCA of a PMO (example) .................................................................................... 22 Tab. 4 Project types according to content....................................................................... 22 Tab. 5 Benefit analysis (example)................................................................................... 37 Tab. 6 Guideline Business Case .................................................................................... 38 Tab. 7 Questions during the definition phase ................................................................. 45 Tab. 8 PESTEL............................................................................................................... 48 Tab. 9 Sample project: Possible initial risk-opportunity assessment of the factual environmental factors .......................................................................................... 50 Tab. 10 SWOT matrix - outer and inner view of the project ............................................. 59 Tab. 11 Combined SWOT matrix...................................................................................... 59 Tab. 12 Promoters and opponents ................................................................................... 60 Tab. 13 Sample project: stakeholder table (excerpt) ........................................................ 63 Tab. 14 Sample project: Communication table (excerpt) .................................................. 66 Tab. 15 Functions of objectives ........................................................................................ 70 Tab. 16 Sample project: Objectives table ......................................................................... 71 Tab. 17 SMART ................................................................................................................ 74 Tab. 18 Definition of objectives‘ relationships ................................................................... 74 Tab. 19 Sample project: Project phases and main activities............................................. 76 Tab. 20 Sample project: Milestone list .............................................................................. 77 Tab. 21 TCA of a steering committee (example) .............................................................. 81 Tab. 22 Excerpt from a role description (TCA) of a project manager (example) ............... 83 Tab. 23 Documents table (example)................................................................................. 85 Tab. 24 Examples for project documents ......................................................................... 87 Tab. 25 Questions during the planning phase .................................................................. 91 Tab. 26 Sample project: Activity list (excerpt) ................................................................. 103 Tab. 27 Sample project: Resource demand (personnel) ................................................ 111 Tab. 28 Sample project: Resource demand plan (excerpt)............................................. 112 Tab. 29 Net capacity (example) ...................................................................................... 113 Tab. 30 Free capacity (example) .................................................................................... 113 Tab. 31 Estimation methods ........................................................................................... 116 Tab. 32 Definition of financial terms: costs, budget, effort…........................................... 117 Tab. 33 Cost types, cost centres, cost units ................................................................... 117 Tab. 34 Sample project: Costs of resources ................................................................... 118 Tab. 35 Sample project: Overview cost plan (excerpt, preparation phase)..................... 119 Tab. 36 Make-or-buy criteria (examples) ........................................................................ 121 Tab. 37 Types of request in the procurement process.................................................... 122 <?page no="250"?> 250 | Page Tab. 38 Types of contract and the resulting obligations ................................................. 123 Tab. 39 Sample project: Risk table or risk register (excerpt) .......................................... 127 Tab. 40 Sample project: Qualified risk table with RP and DE (excerpt) .......................... 127 Tab. 41 Sample project: Quantified risk table with RP and DE (excerpt)........................ 129 Tab. 42 Risk measures and strategies ........................................................................... 130 Tab. 43 PDCA explanation ............................................................................................. 135 Tab. 44 Methods for progress measurement.................................................................. 141 Tab. 45 Planned and actual costs as per reporting date (example)................................ 144 Tab. 46 Earned value analysis: abbreviations, definitions, calculation formulas............. 146 Tab. 47 Traffic light explanation in a status report for deadlines and costs (example) ... 149 Tab. 48 Traffic light explanation for overall project status in a status report (example) .. 150 Tab. 49 Change request (example) ................................................................................ 152 Tab. 50 Causes for deviations (example) ....................................................................... 157 Tab. 51 The four quadrants of the Johari window........................................................... 162 Tab. 52 Stress ‚traffic light‘ acc. to G. Kaluza ................................................................. 164 Tab. 53 Comparison of ‘Code of Ethics’ of GPM and PMI .............................................. 172 Tab. 54 Four levels of the message square.................................................................... 174 Tab. 55 Five axioms of communication acc. to Watzlawick ............................................ 175 Tab. 56 Types of questions (examples).......................................................................... 178 Tab. 57 Types of listening............................................................................................... 178 Tab. 58 Basic rules of active listening ............................................................................ 179 Tab. 59 Feedback and the message square .................................................................. 180 Tab. 60 Motivation techniques acc. to Sprenger............................................................. 183 Tab. 61 Basic human needs acc. to Deci & Ryan........................................................... 185 Tab. 62 Comparison Maslow’s hierarchy of needs vs. Self-determination theory acc. to Deci & Ryan ...................................................................................................... 186 Tab. 63 Selected leadership style typologies.................................................................. 188 Tab. 64 Leadership styles acc. to Lewin......................................................................... 189 Tab. 65 Influential factors for the choice of leadership style ........................................... 191 Tab. 66 Leadership behaviour in the managerial grid..................................................... 192 Tab. 67 Characteristics of lateral leadership................................................................... 195 Tab. 68 Leadership roles acc. to Quinn .......................................................................... 196 Tab. 69 Team roles acc. to Belbin .................................................................................. 200 Tab. 70 Team phases (Tuckman) and role of the project manager ................................ 201 Tab. 71 Team effects: Groupthink, groupshift, social loafing, Abilene Paradox.............. 203 Tab. 72 Conflict behaviours ............................................................................................ 209 Tab. 73 Phases of change acc. to Lewin ........................................................................ 221 Tab. 74 The VUCA world................................................................................................ 229 Tab. 75 Recommended timebox per event based on sprint length................................. 231 Tab. 76 Roles in Scrum .................................................................................................. 232 Tab. 77 Phases of the retrospective ............................................................................... 234 Tab. 78 DEEP criteria for product backlogs.................................................................... 236 Tab. 79 INVEST criteria for user stories ......................................................................... 236 <?page no="251"?> Page | 251 11.2 Figures Fig. 1 ICB Elements in project management basics .................................................... 19 Fig. 2 Examples of project management success factors............................................ 23 Fig. 3 Eye of Competence (IPMA) ............................................................................... 29 Fig. 4 ICB elements in in the initialisation phase ......................................................... 33 Fig. 5 Objectives‘ pyramid of the organisation ............................................................. 34 Fig. 6 Sample project: Project profile........................................................................... 40 Fig. 7 Project canvas ................................................................................................... 40 Fig. 8 ICB elements in the definition phase ................................................................. 45 Fig. 9 Options for influence and costs ......................................................................... 46 Fig. 10 Project start ....................................................................................................... 46 Fig. 11 Sample project: Environment analysis............................................................... 49 Fig. 12 Model of corporate culture according to E. Schein ............................................ 54 Fig. 13 Agenda 2030: the 17 global sustainability goals................................................ 57 Fig. 14 Stakeholder management process .................................................................... 62 Fig. 15 Sample project: Stakeholder portfolio (excerpt)................................................. 64 Fig. 16 Sample project: Stakeholder portfolio after measures (excerpt) ........................ 66 Fig. 17 Functional and non-functional requirements...................................................... 68 Fig. 18 The ‘magic triangle’ ........................................................................................... 69 Fig. 19 Sample project: Goal hierarchy based on scope, time, cost .............................. 72 Fig. 20 Sample project: Goal hierarchy based on result-oriented and processoriented goals .................................................................................................... 73 Fig. 21 Objectives‘ relationships .................................................................................... 74 Fig. 22 Objectives‘ compatibility matrix.......................................................................... 75 Fig. 23 Sample project: Phase plan............................................................................... 77 Fig. 24 Influential project organisation ........................................................................... 79 Fig. 25 Matrix project organisation................................................................................. 80 Fig. 26 Autonomous project organisation ...................................................................... 80 Fig. 27 RACI matrix (example) ...................................................................................... 84 Fig. 28 ICB elements in the planning phase .................................................................. 91 Fig. 29 Elements of the WBS ........................................................................................ 93 Fig. 30 Sample project: phase-oriented WBS................................................................ 94 Fig. 31 Sample project: object-oriented WBS ................................................................ 95 Fig. 32 Sample project: function-oriented WBS ............................................................. 96 Fig. 33 Sample project: Mixed-oriented WBS (1 st level: object-oriented, 2 nd level: function-oriented)............................................................................................... 97 Fig. 34 Project management in the WBS (example)...................................................... 98 Fig. 35 Example for numerical and alpha-numerical coding .......................................... 99 Fig. 36 Classifying coding.............................................................................................. 99 Fig. 37 Sample project: Work package description...................................................... 101 <?page no="252"?> 252 | Page Fig. 38 Process of creating the project schedule......................................................... 102 Fig. 39 Activity node in an AON network diagram ....................................................... 104 Fig. 40 Free float and total float................................................................................... 104 Fig. 41 Logical relationships (LR) of activites .............................................................. 105 Fig. 42 Example normal sequence (FS) ...................................................................... 105 Fig. 43 Example start sequence (SS) .......................................................................... 106 Fig. 44 Example end sequence (FF) ........................................................................... 106 Fig. 45 Example jump sequence (SF) ......................................................................... 106 Fig. 46 Delay, positive time interval ............................................................................. 106 Fig. 47 Overlap, negative time interval ........................................................................ 107 Fig. 48 Forward calculation ......................................................................................... 107 Fig. 49 Backward calculation....................................................................................... 107 Fig. 50 Total float......................................................................................................... 108 Fig. 51 Free float ......................................................................................................... 108 Fig. 52 Transfer of the project duration into the calendar (example) ........................... 109 Fig. 53 Resource planning process ............................................................................. 111 Fig. 54 Sample project: Resource histogram project manager (excerpt; preparation phase) ............................................................................................................. 114 Fig. 55 Sample project: Cost histogram and total cost curve (excerpt; preparation phase) ............................................................................................................. 120 Fig. 56 Types of breach of contractual duties.............................................................. 124 Fig. 57 Rights in the case of default ............................................................................ 124 Fig. 58 Risk management process .............................................................................. 126 Fig. 59 Sample project: Qualified risk portfolio (excerpt) ............................................. 128 Fig. 60 Sample project: Quantified risk representation (excerpt)................................. 129 Fig. 61 Risk strategies ................................................................................................. 130 Fig. 62 Quality management process .......................................................................... 132 Fig. 63 Deming cycle (PDCA)...................................................................................... 135 Fig. 64 ICB elements in the controlling phase ............................................................. 139 Fig. 65 Task division between project manager and project controller ........................ 140 Fig. 66 Integrated project controlling ........................................................................... 142 Fig. 67 Earned Value Analysis (example).................................................................... 145 Fig. 68 Milestone trend diagram .................................................................................. 147 Fig. 69 Cost trend diagram (example) ......................................................................... 148 Fig. 70 Measures of project controlling........................................................................ 148 Fig. 71 ICB elements in the project closure phase ...................................................... 155 Fig. 72 Project closure process ................................................................................... 156 Fig. 73 Lessons learned .............................................................................................. 158 Fig. 74 ICB elements in cross-phase competences .................................................... 161 Fig. 75 The Johari window........................................................................................... 162 Fig. 76 The Eisenhower matrix.................................................................................... 163 Fig. 77 Transactional stress model acc. to R. Lazarus ............................................... 164 <?page no="253"?> Page | 253 Fig. 78 Development of stress ..................................................................................... 166 Fig. 79 Ethics of acti on (summary) ............................................................................. 170 Fig. 80 Ethical guidelines for project managers ........................................................... 170 Fig. 81 Sender-receiver model (simplified) .................................................................. 172 Fig. 82 Content and relationship level (Iceberg model) ............................................... 173 Fig. 83 Message square .............................................................................................. 174 Fig. 84 Communication channels ................................................................................ 176 Fig. 85 Maslow’s hierarchy of needs ........................................................................... 184 Fig. 86 Motivational continuum acc. to Deci & Ryan.................................................... 187 Fig. 87 Leadership continuum ..................................................................................... 190 Fig. 88 Managerial grid (Blake & Mouton) ................................................................... 191 Fig. 89 Situational Leadership ® II ................................................................................ 193 Fig. 90 Leadership style according to maturity level of the employee.......................... 194 Fig. 91 Leadership roles in the Competing Values Framework (CVF)......................... 196 Fig. 92 Team phases (‘team clock’)............................................................................. 201 Fig. 93 Causes of conflict ............................................................................................ 205 Fig. 94 Conflict escalation acc. to Glasl....................................................................... 206 Fig. 95 Conflict styles (TKI) ......................................................................................... 208 Fig. 96 Phases of cooperative conflict resolution ........................................................ 209 Fig. 97 The four negotiation criteria of the Harvard concept ........................................ 212 Fig. 98 Relationship between cause, problem and effect ............................................ 214 Fig. 99 Problem solving process ................................................................................. 214 Fig. 100 Cause-effects diagram (Ishikawa) ................................................................... 215 Fig. 101 Pareto diagram with cumulative curve (example) ............................................ 216 Fig. 102 Emotional phases of change ........................................................................... 222 Fig. 103 Basis of empiricism.......................................................................................... 229 Fig. 104 Agility from ‘doing’ to ‘being“ ............................................................................ 230 Fig. 105 Sprint with events, artefacts and roles ............................................................. 232 Fig. 106 The ‘starfish’ as a method in the retrospective ................................................ 235 Fig. 107 Story map ........................................................................................................ 237 Fig. 108 Kanban board (example) ................................................................................. 239 <?page no="255"?> Page | 255 12 Index of keywords acceptance 136 acceptance criteria 236 active listening 179 activity list 102 activity-on-node (AON) 102 Agile Manifesto 229 Agile value pairs 229 Agile values (Scrum) 231 authority 61 B ELBIN , R.M. 199 benefit analysis 36 B LAKE , R.R. 191 B LANCHARD , K.H. 192 B LOOM , B.S. 16 B ROOK ’s Law 110 buffer free float 104 total float 104 business case 37 calendaring 104, 108 cause-effects diagram 214 change and transformation change curve 222 emotional phases 222 three-phase model 221 change management baseline 150 process 150 change request 151 closure phase 155 coding the WBS classifying 99 identifying 98 communication active listening 179 asynchronous 181 axioms 175 collaboration tool 181 feedback 179 formal 176 informal 176 netiquette 182 question types 177 questioning technique 177 synchronous 181 communication channels 175 communication models axioms (Watzlawick) 175 iceberg model 173 message square 173 sender-receiver model 173 complex 230 complicated 230 configuration management 150 conflict 204 causes 205 escalation (Glasl) 205 resolution 209 symptoms 205 congruence principle 82 contract acceptance 124 default of service 123 rental contract 122 sales contract 122 service contract 122 works contract 122 controlling phase 139 corporate culture culture 55 model (S CHEIN ) 53 values 55 cost planning 118 cost histogram 119 total cost curve 119 cost trend analysis 147 creativity methods 6-3-5 217 brainstorming 218 brainwriting 217 morphological matrix 218 paradox 219 crisis 204 critical path 108 daily Scrum 233 data protection 51 data security 52 D ECI , E.L. 185 definition multi-project mgt. 20 process 21 programme 20 programme mgt. 20 project 20 project mgt. 20 project portfolio 20 project portfolio mgt. 21 task 21 definition of done 238 definition of ready 237 definition phase 45 D EMING , W.E. 135 deviation analysis 157 documents matrix 85 <?page no="256"?> 256 | Page earned value analysis 143 budget at completion 145 estimate at completion 145 POC 145 effectiveness 220 efficiency 220 E ISENHOWER , D.D. 162 Eisenhower matrix 162 E LKINGTON , J. 56 empiricism 230 epic 236 estimation methods 116 ethics 168, 169 consequentialism 169 Conviction 168 descriptive ethics 169 GPM Code of ethics 171 normative ethics 169 F AYOL , H. 82 feedback 179 FMEA process 216 risk priority number 128 F REUDENBERGER , H.J. 166 functional specification (Pflichtenheft) 68, 86 Gantt chart 105 G LASL , F. 206 G OLDRATT , E. 26 Harvard concept 212 hazard analysis 53 H ERSEY , P. 192 H ERZBERG , F. 184 HSSE 50 hygiene factors 184 increment 237 I NGHAM , H. 161 initialisation phase 33 integrated project controlling 142 INVEST 236 I SHIKAWA , K. 214 Ishikawa diagram 214 Johari window 161 K ALUZA , G. 165 Kanban, work in progress 239 K ANO , N. 184 kick-off meeting 47 knowledge preservation lessons learned process 158 K OTTER , J.D. 221 K ÜBLER -R OSS , E. 222 L ASSWELL , H.D. 65 lateral leadership characteristics 195 definition 195 laws and regulations (DE) 50 L AZARUS , R. 164 leadership continuum 189 leadership roles (Q UINN ) 195 leadership style 188 leap of faith 168 L ENCIONI , P. 168 lessons learned 157, 204 retrospective 157 L EWIN , K. 188, 221 logical relationships 103 end sequence 106 jump sequence 106 normal sequence 105 start sequence 106 L UFT , J. 161 management by delegation 197 exception 197 objectives 197 management responsibility duty of care 198 duty of diligence 198 supervisory duty 198 managerial grid model 191 M ASLOW , A. 183 milestones, definition 76 milestone trend analysis 146 mindset (agile) 230 minimum viable product 238 mission 34 moral 168 motivating 182 motivation 182 motivational continuum 186 M OUTON , J.S. 191 MVP 238 needs deficit needs 184 growth needs 184 negotiation definition 210 Harvard principle 211 hidden situations 210 typical situations 210 netiquette 182 network diagram 102 network planning backward calculation 107 forward calculation 107 free float 108 <?page no="257"?> Page | 257 total float 108 network planning technique 102 norms DIN 69901 27 ISO 21502 28 PMBOK guide 28 objectives categories / classes 70 language 73 must / should / can 70 out-of-scope 70 SMART 74 O HNO , T. 238 O SBORNE , A.F. 218 P ARETO , V. 215 Pareto diagram 215 perception accomodation 177 assimilation 177 cognitive dissonance 177 PERT technique 102 P INK , D. 186 planning phase 91 power 60, 61 process models 24 procurement make-or-buy 121 process 120 product backlog 235 DEEP 235 profitability analysis 156 project canvas 38 project closure 155 acceptance 156 final analysis 156 lessons learned 157 termination 158 project controlling 140 PESTEL 48, 126 project documentation 85 project environment 48 project file 85 project manual 30 project mgt. approaches agile 25 bottleneck-oriented 26 evolutionary 26 hybrid 25 incremental 24 iterative 24 sequential / plandriven 24 project mgt. manual 30 project mgt. office (PMO) 21 project mgt. phases 20, 27 project mgt. success 23 project organisation autonomous PO 81 influential PO 78 matrix PO 79 steering committee 81 project profile 38 project schedule 102 project success 23 application success 23 implementation success 23 project team 198 project type change project 22 investment project 22 organisational project 22 R&D project 22 quality 131 acceptance criteria 136 definition of done 136 PDCA cycle 135 tasks of QM 133 validation 134 verification 134 quality management 131 Q UINN , R.E. 195 RACI matrix 83 release 136 reliability 167 requirements specification (Lastenheft) 86 resource histogram 113 shortage 113 surplus 113 resource planning 110 optimisation 114 results orientation project level 219 project mgt. level 219 retrospective 77, 233 risk damage extent 127 risk probability 127 risk value 129 risk management 125 risk measures corrective 130 preventive 130 risk strategies 130 R OGERS , C. 179 R OHRBACH , B. 217 roles 82 RACI matrix 83 RASCI matrix 84 TCA matrix 82 R OSENBERG , M. 180 R YAN , R.M. 185 <?page no="258"?> S CHEIN , E.H. 53 S CHMIDT , W.H. 189 S CHULZ VON T HUN , F. 173 S CHWABER , K. 230 self-determination theory 185 S ELYE , H. 165 S HANNON , C.E. 173 situational leadership 192 SMART 74 S PRENGER , R. 183 sprint 232 sprint backlog 237 sprint planning 233 sprint review 233 stakeholders 59 communication plan 65 opponents 60 portfolio 63 process 62 promotors 60 strategies 64 standards ICB4.0 29 PM 2 29 PRINCE2 28 Starfish 234 status report 149 story map 236 strategy 34 stress burnout 165 definition 163 management 165 reaction 165 transactional stress model 164 success criteria 36 success factors 36 sustainability agenda 2030 56 CSR 56 DNK 57 S UTHERLAND , J. 230 SWOT analysis 57 T ANNENBAUM , R. 189 TCA matrix 82 team, definition 198 teamwork success factors 202 team development 201 team effects 202 team learning 204 team phases 201 team roles 199 team rules 199 timeboxing 25, 231 trust 168 T UCKMAN , B. 201 two-factors theory 184 UN Global Compact 56 user requirements specification (Lastenheft) 67 user story 236 versioning 85 virtual teams 181 vision 34 VUCA world 229 W ATZLAWICK , P. 173, 175 W EAVER , W. 173 work breakdown structure 92 coding 98 function-oriented 96 mixed-oriented 97 object oriented 95 phase-oriented 93 subtask 92 work package 100 Work package 100 Z WICKY , F. 218 <?page no="259"?> ISBN 978-3-381-13481-6 www.uvk.de What has been supported by advocates of professional project work for years has now become a reality in the daily routines of many employees and managers: highly project-oriented work structures. Consequently, professionalised project management competence is becoming increasingly vital to business success. Following the five project management phases of DIN 69901: 2009 and supplemented by chapters on cross-phase competencies and agile methods, this book o ers a clear and professionally sound presentation of the modernised ICB 4.0 framework (e ective from January 1, 2024). Its structured content, illustrated by a consistent project example, not only guides readers but also ensures they are well-prepared to meet the IPMA ICB 4.0 examination requirements. This book equips anyone seeking to engage in professional project management with the knowledge and tools needed to successfully apply current best practices. Schulz / Meier Project Management 3. Ed. Marcus Schulz / Tinka Meier Project Management A Practical Guideline for Today’s Project Managers 3 rd Edition ICB 4.0