Project Management Handbook: Agile – Traditional – Hybrid [2 ed.] 3662662108, 9783662662106

Table of contents :
Preface to the Second Edition
Structure of This Book
Contents
About the Authors
1: Introduction
1.1 Project Management, What for?
1.1.1 The Taylor Tub
1.1.2 BANI Is the New VUCA
1.2 What are Projects?
Definition
1.2.1 Project Characteristics
1.2.2 Project Types
1.2.3 Emergence of Projects
1.3 What Is Project Management?
1.3.1 Hierarchies in Project Management
1.3.2 Dimensions in Project Management
1.3.2.1 Competence Area Perspective
1.3.2.2 Competence Area People
1.3.2.3 Competence Area Practices
1.3.3 Principles of Procedure
1.3.3.1 From a Rough Sketch to a More Detailed Depiction
1.3.3.2 Variant Formation
1.4 Process Models in Projects
1.4.1 Agile Approach
1.4.1.1 Scrum
1.4.1.2 Kanban
1.4.1.3 Scaled Agility
1.4.2 Traditional Approach: Phase Concept
1.4.2.1 The Project Commissioning Phase
1.4.2.2 The Initialisation Phase
1.4.2.3 The Concept Phase
1.4.2.4 The Realisation Phase
1.4.2.5 The Introduction Phase
1.4.2.6 The Utilisation Phase
1.4.3 Hybrid Project Management
1.4.4 Procedure in Change Projects
1.4.5 Further Process Models
1.4.5.1 V-Model
1.4.5.2 Simultaneous Engineering
1.4.5.3 Version Concept
1.4.6 Choice of a Process Model: Traditional, Agile or Hybrid?
1.5 Projects are Based on Teamwork
1.5.1 Content: Working in the System
1.5.2 Organisation and Relationship: Working on the System
1.5.3 Interactions
1.6 Projects are Social Systems
1.6.1 Taylorism in our Heads
1.6.2 Mechanistic and Systemic World View
1.6.3 People and Teams Are Non-Trivial Systems
1.6.4 Systemic Approach to Project Management
1.7 Versatility and Creativity
1.7.1 Versatility
1.7.2 Creativity as a Surplus of Attention
1.7.3 Interplay Between Human, Field and Domain
Example
1.7.4 Framework Conditions for Creativity
1.8 Standards and Certification Models in Project Management
1.8.1 IPMA: International Project Management Association
1.8.2 PMI: Project Management Institute
1.8.3 PRINCE2
1.8.4 Hermes
1.8.5 Scrum Alliance
1.8.6 DIN 69901 and ISO 21500
1.9 Project Portfolio, Multi-Project and Programme Management
References
Further Readings
2: Methodology
2.1 Introduction
2.1.1 Traditional, Agile and Hybrid
2.1.2 Accuracy of Estimates
2.1.3 Practical Examples
2.2 Project Commissioning Phase
2.2.1 What Is Important in the Commissioning Phase?
2.2.2 Project Factsheet
2.2.3 Business Case
2.2.4 Project Request
2.2.5 Checklist Completion Project Commissioning
2.3 Initialisation Phase
2.3.1 What is Important in the Initialisation Phase?
2.3.2 Setting Objectives
2.3.2.1 Setting Objectives Along the Project Phases
2.3.2.2 Global Objective and Detailed Objectives
Example: Practical Example BLS Project Sales Back-End
Example: Practical Example Metrohm OMNIS Titration System Project
2.3.2.3 System Objectives and Process Objectives
2.3.2.4 Criteria for Appropriate Project Objectives
2.3.2.5 Mandatory and Optimisation Objectives
2.3.3 Requirements, Requirements Engineering
2.3.3.1 Requirement Engineering Activities
2.3.3.2 Types of Requirements
2.3.3.3 Criteria for the Quality of Requirements and Requirements Documents
2.3.3.4 Prioritisation of Requirements
2.3.3.5 Feasibility Check
2.3.4 The Magic Triangle
2.3.5 Stakeholder Management
2.3.6 Project Marketing
2.3.7 Risk Management
2.3.7.1 The Concrete Steps in the Risk Process
2.3.7.2 Failure Mode and Effects Analysis (FMEA)
2.3.8 Project Organisation, Roles, Committees
2.3.8.1 Line and Project: Two Different Worlds
2.3.8.2 Roles and Bodies
2.3.8.3 Competences and Management Tasks in the Project Organisation
2.3.8.4 Project Organisation in the Agile Approach
2.3.8.5 Project Organisation in the Traditional Approach
2.3.8.6 Project Organisation in the Hybrid Approach
2.3.8.7 Project Organisation in Customer Projects
2.3.8.8 Linking the Project Organisation to the Line Organisation
2.3.8.9 The Competence Regulation
2.3.8.10 Formation of the Project Organisation
2.3.9 Information Gathering and Situation Analysis
2.3.9.1 Context Analysis
2.3.9.2 SWOT Analysis
2.3.9.3 Cause-Effect Analysis
2.3.9.4 Analysis of the Legal Basis and Compliance Requirements
2.3.9.5 Information Security and Protection Needs Analysis
2.3.9.6 Planning Horizon
2.3.9.7 Scenario Technique
2.3.10 Project Structuring
2.3.10.1 Procedure for Project Structuring
2.3.10.2 Setting Milestones in the Project: The Phase Plan
2.3.10.3 Projects, Sub-projects, Work Packages, Deliverables, and Activities
2.3.10.4 The Work Breakdown Structure WBS
2.3.11 Project Order
2.3.12 Project Manual, Project Management Plan
2.3.13 Kick-Off
2.3.14 Problem-Solving Process
2.3.15 Checklist Completion Initialisation Phase
2.4 Concept Phase
2.4.1 What Is Important in the Concept Phase?
2.4.2 Product Goal (Product Concept)
2.4.3 Product Backlog
2.4.4 Release Plan
2.4.5 Requirements Specification: Solution Concept
2.4.6 Effort Estimation
2.4.6.1 Importance of Effort Estimation in the Traditional Approach
2.4.6.2 Planning Poker, Story Points
2.4.6.3 T-Shirt Sizing
2.4.6.4 Multiplier Method
2.4.6.5 Percentage Method
2.4.6.6 Analogy Method
2.4.6.7 Expert Estimation (Delphi Method)
2.4.6.8 PERT (Programme Evaluation and Review Technique)
2.4.6.9 Reserves
2.4.6.10 Typical Errors in Effort Estimation
2.4.7 Schedule and Timetable
2.4.7.1 Create Procedure and Schedule
2.4.7.2 Termination, Critical Path, and Slack
2.4.7.3 Accuracy in the Process and Scheduling
2.4.7.4 Procedures for Planning
2.4.7.5 Adherence to Deadlines and Capacity Planning
2.4.7.6 How Detailed Should a Plan Be?
2.4.7.7 Further Planning Variants: Target Costing, Design-to-Cost
2.4.8 Resource Deployment Plan and Resource Coordination
2.4.8.1 Resource Planning in the Project: Line and Project Manager as Partners
2.4.8.2 Resource Coordination in Multi-project Management
2.4.9 Cost Plan
2.4.10 Information, Communication, and Documentation
2.4.10.1 Principles of Information and Communication
2.4.10.2 Scope of an Information and Communication System
2.4.11 Quality Management
2.4.12 Checklist Completion Concept Phase
2.5 Realisation Phase
2.5.1 What Is Important in the Realisation Phase?
2.5.2 Sprint Planning, Sprint Backlog
2.5.3 Sprint Implementation, Daily Scrum
2.5.4 Sprint Review
2.5.5 Retrospective
2.5.6 Project Controlling
2.5.6.1 Project Control
2.5.6.2 Reporting
2.5.6.3 Project Steering
2.5.6.4 Project Assessment
2.5.6.5 The 90% Syndrome
2.5.6.6 The 0/100 Method
2.5.7 Deadline, Cost and Resource Control
2.5.7.1 Deadline and Cost Control
2.5.7.2 Resource Control
2.5.7.3 Cost Transparency and Realistic Assessment of Economic Efficiency
2.5.8 Project Changes, Change Request Management, Claim Management
2.5.8.1 Project Changes
2.5.8.2 Change Request Management
2.5.8.3 Claim Management
2.5.9 Checklist Completion Realisation Phase
2.6 Introduction Phase
2.6.1 What Is Important in the Introduction Phase?
2.6.2 Types of Introduction
2.6.3 Acceptance and Commissioning
2.6.3.1 Acceptance
2.6.3.2 Commissioning
2.6.3.3 Going Live in the Agile Approach
2.6.3.4 Pilot Test, Pilot Series
2.6.3.5 From Pilot Series to Serial Production
2.6.4 User Training and Education
2.6.4.1 User Training Concept
2.6.4.2 Types of User Training
2.6.5 Transfer to the Operational Organisation
2.6.5.1 Preparing Operation
2.6.5.2 Business Organisation
2.6.5.3 Business Handover
2.6.6 Project Completion
2.6.7 Checklist Conclusion Introductory Phase
2.7 Project Portfolio and Programme Management
2.7.1 Project Portfolio and Multi-project Management
2.7.1.1 Multi-project Management: Problem Areas, Tasks and Elements
2.7.1.2 Multi-project Management Process
2.7.1.3 Configuration of the Portfolio
2.7.1.4 Prioritised Project List
2.7.1.5 Content Dependencies
2.7.1.6 Resource Availability and Dependencies
2.7.1.7 The Project Portfolio
2.7.1.8 Reporting
2.7.1.9 Steps Towards an Excellent Portfolio Management
2.7.2 Lean Portfolio Management
2.7.3 Programme Management
2.7.3.1 What Characterises a Programme?
2.7.3.2 Added Value of the Programme Organisation
2.7.3.3 Distinction Between Project and Programme Management
2.7.4 Project Management Office: PMO
2.7.5 Project Management Handbook
2.8 Creativity and Innovation
2.8.1 What is the Difference?
2.8.2 Finding Creative Solutions
2.8.2.1 The Creativity Process
2.8.2.2 Brainstorming
2.8.2.3 Mind Mapping
2.8.2.4 Brainwriting
2.8.2.5 Scamper
2.8.2.6 Design Thinking
2.8.2.7 Morphological Box
2.8.2.8 Analogy Method
2.8.2.9 Appreciative Inquiry
2.8.3 Evaluate and Decide on Solution Ideas
2.8.3.1 Analyse and Optimise Solutions
2.8.3.2 Decide
2.8.3.3 Utility Analysis and Sensitivity Analysis
2.8.4 Innovation Management
2.8.4.1 Innovation Strategy
2.8.4.2 Innovation Process
2.8.4.3 Innovation Traps
2.9 Procurement
2.9.1 Procurement Procedure in the Agile Approach
2.9.1.1 Clarify Procurement Needs
2.9.1.2 Select Suitable Providers
2.9.1.3 Implementation of a Pilot Project
2.9.1.4 Negotiate Contract and Finalise Procurement
2.9.2 Procurement Procedure in the Traditional Approach
2.9.2.1 Clarify Procurement Needs
2.9.2.2 Create Procurement Plan
2.9.2.3 Create Tender Documents
2.9.2.4 Carry Out Tendering and Evaluation
2.9.2.5 Negotiate Contract and Finalise Procurement
References
Further Readings
3: Human
3.1 Competence Model
3.2 Conditions for Good Performance
Example
3.3 Human Phenomenon
3.3.1 The Brain Is a Miracle
Example
Example
3.3.2 Basic Needs Determine Our Lives
3.3.3 Human Perception
3.3.4 Awareness and Self-Reflection
Example
3.3.5 Trust
3.3.6 Humour
3.4 Culture and Values
3.4.1 What Is Culture?
3.4.2 Organisational Culture
3.4.3 Project Culture
Example
3.4.4 Generations Y, Z, and Alpha in the World of Work
3.4.5 Becoming Aware of One´s Own Cultural Imprint
3.5 Stress and Change
3.5.1 Fight or Flight
3.5.2 Psychological Stress
3.5.3 Stress Traffic Light
3.5.4 Stress Competence
3.5.5 Life Means Change
3.5.6 Personal Coping Strategies and Dilemmas
Examples
3.5.7 Burnout
3.6 Flow
Example
3.7 Motivation and Meaning
3.7.1 Goal Orientation of the Human Being
3.7.2 What Is Motivation?
3.7.2.1 Gallup: Commitment and Motivation at Work
3.7.2.2 Intrinsic and Extrinsic Motivation
3.7.2.3 Motivation Through Working on the Demotivating Factors
3.7.3 Meaning as an Intrinsic Motivator
3.7.3.1 What Is Meaning?
3.7.3.2 Meaning in Life Meaning of Life
3.7.3.3 Our Way of Life Systematically Destroys Meaning
Example
3.7.3.4 Meaningful Fulfilment at Work
3.8 Self-Management
3.8.1 Human Self-Efficacy
3.8.2 Personal Competence Circle: Strengths and Weaknesses
3.8.3 Time Management and Work Technique
3.8.4 Resilience
3.8.4.1 What Is Resilience?
3.8.4.2 Resilience Factors
Optimism
Acceptance
Self-Efficacy
Personal Responsibility
Network Orientation
Solution Orientation
Future Orientation
3.8.5 Dealing with Failure
3.8.5.1 Failure at Roche and Dyson
Example
3.8.5.2 Personal Assets: Attitude
3.8.5.3 Organisational Aspects
3.8.5.4 Fail Fast
3.9 Personal Communication
3.9.1 What Is Communication?
3.9.2 Axiom Theory
3.9.3 Communication Square
Example
3.9.4 Communication Cycle
Example
3.9.5 Meta-Communication
Example
3.9.6 I and You Message
3.9.7 Feedback
3.9.7.1 Structure of the Feedback
3.9.7.2 Feedback as a Team Development Tool
Examples
Example
3.9.7.3 Feedback Rules
3.9.8 Questioning Techniques
3.9.8.1 Open and Closed Questions
Example
Example
3.9.8.2 Active Listening
Technique and Method
Example
Active Listening as a Basic Attitude and Development Support
Stage 1: Establish Relationship
Stage 2: Formulate Core Statement
Stage 3: Verbalise Emotions
3.9.8.3 Other Question Types
3.10 Personal Development
3.10.1 The Three Living Worlds
3.10.2 Self-Knowledge
3.10.2.1 Personality Typologies
3.10.2.2 Psychometric Methods
3.10.2.3 Belbin
3.10.2.4 Belbin Basics
3.10.2.5 What Is a Team Role?
3.10.2.6 Each Team Role Has Positive and Negative Characteristics
3.10.2.7 Belbin Team Roles to Increase Self-Knowledge
Example
3.10.2.8 MBTI
3.10.2.9 VIA Character Strengths
3.10.3 Coaching
3.10.4 Intervision
3.10.5 Upside or Downside Strategy?
Example
References
Further Readings
4: Leadership
4.1 Leadership and Cooperation
4.2 Leadership: What Is It?
4.3 Different Forms of Leadership
4.4 Leadership Styles and Models
4.4.1 Directive Versus Delegative Leadership Style
4.4.2 Situational Leadership Model
4.4.3 Leadership Without Authority to Issue Directives
4.4.3.1 Organisational Framework
4.4.3.2 Personal Framework
Example
4.4.3.3 Team Frame
4.4.3.4 Friction Points in Leadership Without Authority to Issue Directives
Example
4.4.4 Positive Leadership in Projects
4.4.5 Tips for Remote Leadership
4.5 Self-organisation, Specific Characteristics in the Agile Project
4.5.1 Principles and Requirements for Self-organisation
4.5.2 What Does Self-organised and Agile Working Mean?
4.5.3 How Does Self-direction and Leadership Work in Self-organisation?
Example
4.5.4 Decide on Procedures and Solutions in Their Own Competence
4.5.5 Important Factors for Self-organisation to Succeed and Be Effective
Example
4.6 Leading with Goals
4.6.1 Management by Objectives MbO
4.6.2 Leading by Objectives and Key Results (Management by OKR)
Example
4.7 Delegation
4.7.1 Decision-Making Process in the Delegation
4.7.2 Delegation as a Recurring Process in Project Management
Example
4.8 Task, Competence, Responsibility (TCR)
4.9 Power and Authority
4.9.1 Empowerment and Seizure: Power Is Based on Relationship
4.9.2 Traditional Sources of Power
4.9.3 Other Sources of Power in Project Management
4.9.4 Projects Always Need Borrowed Power
4.9.5 Sources of Power: Between Person and Institution
4.9.6 Authority
Example
4.10 Negotiation
4.10.1 Negotiations in Project Management
4.10.2 What is a Negotiation?
4.10.3 Negotiation Cycle
4.10.3.1 Preparation
Example
4.10.3.2 Optimal Negotiation Strategy and Tactics: Situational
4.10.3.3 Negotiation
4.10.3.4 Evaluation and Controlling
4.10.4 Conducting a Negotiation According to the Harvard Concept
4.10.4.1 Separation Between Person and Topic
4.10.4.2 Interests Instead of Positions
4.10.4.3 Possibilities
4.10.4.4 Fair Criteria
4.10.4.5 Selection According to the BATNA Principle
4.11 Moderation
4.11.1 Iceberg Model
4.11.2 Phases of Moderation
4.11.3 Responsibility and Competences of the Moderator
4.11.4 Checklist for the Preparation of a Moderated Session
4.12 Communicate Effectively with Virtual Teams
References
Further Readings
5: Teams
5.1 Aspects of Teams and Groups
5.1.1 What Distinguishes Teams from Working Groups?
5.1.2 Composition of the Project Team
5.2 Dynamics in Teams
5.2.1 Forming: Orientation
5.2.2 Storming: Discussion
5.2.3 Norming: Familiarity
5.2.4 Performing: Working in the System
5.2.5 Adjourning: Farewell and Separation
5.2.6 Dynamics and Interaction
5.3 Roles in the Project Organisation
5.3.1 ``Line-up´´ in Teams: Position and Role
Example
5.3.2 Role Carrier and Role Sender
5.3.3 The Role as a Link Between Organisation and Person
Example
Example
Example
Example
5.4 Influencing Factors for Successful Cooperation
5.4.1 Psychological Safety
5.4.2 Positive Psychology and What Distinguishes High Performance Teams from Others
5.4.3 Belbin Team Roles
5.4.4 Radical Collaboration
5.4.5 Multicultural Cooperation
Example
Example
Example
5.4.6 Organisational Constellations
5.5 Change and Resistance
5.5.1 Change and Transformation
5.5.1.1 Change: Solving Problems
Example
5.5.1.2 Transformation: Finding Solutions
Example
5.5.2 Mind Change
5.5.3 The Human Being and Change
5.5.4 ``Formula´´ of Change
Example
5.5.5 Readiness for Change in Organisations
5.5.6 Psychology and Factual Logic in Projects
5.5.7 Willingness to Shape and Cooperate
5.5.8 Change Process Model
5.5.8.1 Phases of Change
5.5.8.2 Non-simultaneity of Change
5.5.9 Dealing with Resistance
5.5.9.1 Positive and Negative Connotation
5.5.9.2 Is Resistance a Synonym for Conflict?
5.5.9.3 Forms of Resistance
5.5.9.4 Dealing with Resistance
5.5.9.5 Interventions in Case of Resistance
5.5.10 Procedure in Change Projects
5.6 Conflict Management and Crises
5.6.1 What Is Conflict?
5.6.2 Origin and Symptom: The Systemic Phenomenon
Example
Example
Example
5.6.3 Conflict Syndrome
5.6.4 Conflict Symptoms
5.6.5 Potential of Conflicts
5.6.6 Types of Conflict in Project Management
5.6.6.1 Goal Conflict and Conflict of Interest
5.6.6.2 Distribution Conflicts and Resource Conflicts
5.6.6.3 Structural and Organisational Conflict
5.6.6.4 Evaluation Conflict and Procedure Conflict
5.6.6.5 Role Conflict
5.6.6.6 Personal Conflict
5.6.6.7 Relationship Conflict (Social Conflict)
5.6.6.8 Conflict of Values
5.6.7 Conflict Diagnosis
5.6.7.1 Forming Hypotheses Instead of Wanting to Know
5.6.7.2 Forms of Expressions of Conflicts
5.6.7.3 Conflict Styles
5.6.8 Models for Conflict Diagnosis
5.6.8.1 Conflict Escalation Levels
5.6.8.2 Layer Model
5.6.8.3 Questions for Conflict Diagnosis
5.6.9 Conflict Resolution
5.6.9.1 The Aim of Conflict Management
5.6.9.2 Restoring Self-control
5.6.9.3 Conflict Resolution Process
Example
5.6.9.4 Harvard Concept in Conflict Management
Example
5.6.10 Conflict Resolution Depending on the Type of Conflict
5.6.10.1 Goal Conflicts and Conflicts of Interest
5.6.10.2 Distribution Conflicts and Resource Conflicts
5.6.10.3 Structural Conflicts and Organisational Conflicts
5.6.10.4 Evaluation Conflicts and Procedure Conflicts
5.6.10.5 Role Conflict
5.6.10.6 Personal Conflict
5.6.10.7 Relationship Conflict (Social Conflict)
5.6.10.8 Conflict of Values
Example
5.6.10.9 Summary of Conflict Resolution
5.6.11 Conflict Prevention
5.6.11.1 Project Management Methodology
5.6.11.2 Disruptions Have Priority
5.6.11.3 Conflict Skills and Frustration Tolerance
5.6.12 Dealing with Crises
5.6.12.1 Internal Causes of Crisis
5.6.12.2 External Causes of Crisis
5.6.12.3 Leadership and Communication
5.7 Finally
References
Further Readings
6: Reference List for the Individual Competence Baseline (ICB) from IPMA (International Project Management Association)
Index

Citation preview

Management for Professionals

Jürg Kuster · Christian Bachmann · Mike Hubmann · Robert Lippmann · Patrick Schneider

Project Management Handbook Agile – Traditional – Hybrid Second Edition

Management for Professionals

The Springer series Management for Professionals comprises high-level business and management books for executives. The authors are experienced business professionals and renowned professors who combine scientific background, best practice, and entrepreneurial vision to provide powerful insights into how to achieve business excellence.

Jürg Kuster • Christian Bachmann • Mike Hubmann • Robert Lippmann • Patrick Schneider

Project Management Handbook Agile – Traditional – Hybrid Second Edition

Jürg Kuster Zürich, Switzerland

Christian Bachmann Rapperswil-Jona, Switzerland

Mike Hubmann Liebefeld, Switzerland

Robert Lippmann Männedorf, Switzerland

Patrick Schneider Nussbaumen TG, Switzerland

ISSN 2192-8096 ISSN 2192-810X (electronic) Management for Professionals ISBN 978-3-662-66210-6 ISBN 978-3-662-66211-3 (eBook) https://doi.org/10.1007/978-3-662-66211-3 # Springer-Verlag GmbH Germany, part of Springer Nature 2015, 2023 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer-Verlag GmbH, DE, part of Springer Nature. The registered company address is: Heidelberger Platz 3, 14197 Berlin, Germany

Preface to the Second Edition

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

vi

Preface to the Second Edition

the contents of this book and also the Beratungs- und Weiterbildungsinstitut BWI AG in the field of project management.

Structure of This Book Various structural elements simplify the application of this comprehensive work in practice. The Project Management Compass serves as a detailed orientation guide for project management and presents two different process models for agile and traditionally managed projects. The success of complex, interdisciplinary projects requires an increasingly wide range of competences, especially from the project manager. That is why we link the methodological foundations to the people who implement the project with a team. The domains “methodology”, “people”, “leadership,” and “team” interact with each other. That is why the content of this book is divided into the following chapters: 1. Introduction: Project management at a glance and in a leadership context 2. Methodology: Models and working methodology for handling agile, traditional, and hybrid projects 3. Human: Essential characteristics of people as designers of projects 4. Leadership: Models and methods of leading projects 5. Teams: Aspects of successful team development and cooperation This work has also been updated with a view to IPMA certification and offers a comprehensive reference table for all competence elements of the Individual Competence Baseline of IPMA® (ICB4) in Chap. 6. We wish you many new insights through reading this book and the success you desire for your future projects. Zürich, Switzerland Rapperswil-Jona, Switzerland Liebefeld, Switzerland Männedorf, Switzerland Nussbaumen TG, Switzerland February 2023

Jürg Kuster Christian Bachmann Mike Hubmann Robert Lippmann Patrick Schneider

Contents

1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Project Management, What for? . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 The Taylor Tub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 BANI Is the New VUCA . . . . . . . . . . . . . . . . . . . . . . . 1.2 What are Projects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Project Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Project Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Emergence of Projects . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 What Is Project Management? . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Hierarchies in Project Management . . . . . . . . . . . . . . . . 1.3.2 Dimensions in Project Management . . . . . . . . . . . . . . . . 1.3.3 Principles of Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Process Models in Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Agile Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 Traditional Approach: Phase Concept . . . . . . . . . . . . . . 1.4.3 Hybrid Project Management . . . . . . . . . . . . . . . . . . . . . 1.4.4 Procedure in Change Projects . . . . . . . . . . . . . . . . . . . . 1.4.5 Further Process Models . . . . . . . . . . . . . . . . . . . . . . . . 1.4.6 Choice of a Process Model: Traditional, Agile or Hybrid? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Projects are Based on Teamwork . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Content: Working in the System . . . . . . . . . . . . . . . . . . 1.5.2 Organisation and Relationship: Working on the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6 Projects are Social Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Taylorism in our Heads . . . . . . . . . . . . . . . . . . . . . . . . 1.6.2 Mechanistic and Systemic World View . . . . . . . . . . . . . 1.6.3 People and Teams Are Non-Trivial Systems . . . . . . . . . 1.6.4 Systemic Approach to Project Management . . . . . . . . . . 1.7 Versatility and Creativity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.1 Versatility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.2 Creativity as a Surplus of Attention . . . . . . . . . . . . . . . .

1 1 1 2 3 5 7 7 8 9 10 12 14 14 18 23 24 24 27 29 29 30 31 32 32 32 34 35 37 37 37 vii

viii

2

Contents

1.7.3 Interplay Between Human, Field and Domain . . . . . . . . 1.7.4 Framework Conditions for Creativity . . . . . . . . . . . . . . . 1.8 Standards and Certification Models in Project Management . . . . . 1.8.1 IPMA: International Project Management Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.2 PMI: Project Management Institute . . . . . . . . . . . . . . . . 1.8.3 PRINCE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.4 Hermes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.5 Scrum Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.6 DIN 69901 and ISO 21500 . . . . . . . . . . . . . . . . . . . . . . 1.9 Project Portfolio, Multi-Project and Programme Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Further Readings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38 40 41

47 48 48

Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Traditional, Agile and Hybrid . . . . . . . . . . . . . . . . . . . . 2.1.2 Accuracy of Estimates . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Practical Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Project Commissioning Phase . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 What Is Important in the Commissioning Phase? . . . . . . 2.2.2 Project Factsheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Project Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Checklist Completion Project Commissioning . . . . . . . . 2.3 Initialisation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 What is Important in the Initialisation Phase? . . . . . . . . . 2.3.2 Setting Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Requirements, Requirements Engineering . . . . . . . . . . . 2.3.4 The Magic Triangle . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 Stakeholder Management . . . . . . . . . . . . . . . . . . . . . . . 2.3.6 Project Marketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.7 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.8 Project Organisation, Roles, Committees . . . . . . . . . . . . 2.3.9 Information Gathering and Situation Analysis . . . . . . . . 2.3.10 Project Structuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.11 Project Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.12 Project Manual, Project Management Plan . . . . . . . . . . . 2.3.13 Kick-Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.14 Problem-Solving Process . . . . . . . . . . . . . . . . . . . . . . . 2.3.15 Checklist Completion Initialisation Phase . . . . . . . . . . . 2.4 Concept Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 What Is Important in the Concept Phase? . . . . . . . . . . . . 2.4.2 Product Goal (Product Concept) . . . . . . . . . . . . . . . . . . 2.4.3 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49 49 49 53 54 56 57 59 60 60 61 61 62 66 72 77 79 83 84 91 111 118 127 128 129 130 134 135 136 139 140

41 43 44 45 46 46

Contents

ix

2.4.4 2.4.5 2.4.6 2.4.7 2.4.8

Release Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requirements Specification: Solution Concept . . . . . . . . Effort Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedule and Timetable . . . . . . . . . . . . . . . . . . . . . . . . Resource Deployment Plan and Resource Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.9 Cost Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.10 Information, Communication, and Documentation . . . . . 2.4.11 Quality Management . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.12 Checklist Completion Concept Phase . . . . . . . . . . . . . . 2.5 Realisation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 What Is Important in the Realisation Phase? . . . . . . . . . . 2.5.2 Sprint Planning, Sprint Backlog . . . . . . . . . . . . . . . . . . 2.5.3 Sprint Implementation, Daily Scrum . . . . . . . . . . . . . . . 2.5.4 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.5 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.6 Project Controlling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.7 Deadline, Cost and Resource Control . . . . . . . . . . . . . . 2.5.8 Project Changes, Change Request Management, Claim Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.9 Checklist Completion Realisation Phase . . . . . . . . . . . . 2.6 Introduction Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 What Is Important in the Introduction Phase? . . . . . . . . . 2.6.2 Types of Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3 Acceptance and Commissioning . . . . . . . . . . . . . . . . . . 2.6.4 User Training and Education . . . . . . . . . . . . . . . . . . . . . 2.6.5 Transfer to the Operational Organisation . . . . . . . . . . . . 2.6.6 Project Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.7 Checklist Conclusion Introductory Phase . . . . . . . . . . . . 2.7 Project Portfolio and Programme Management . . . . . . . . . . . . . . 2.7.1 Project Portfolio and Multi-project Management . . . . . . 2.7.2 Lean Portfolio Management . . . . . . . . . . . . . . . . . . . . . 2.7.3 Programme Management . . . . . . . . . . . . . . . . . . . . . . . 2.7.4 Project Management Office: PMO . . . . . . . . . . . . . . . . . 2.7.5 Project Management Handbook . . . . . . . . . . . . . . . . . . . 2.8 Creativity and Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.1 What is the Difference? . . . . . . . . . . . . . . . . . . . . . . . . 2.8.2 Finding Creative Solutions . . . . . . . . . . . . . . . . . . . . . . 2.8.3 Evaluate and Decide on Solution Ideas . . . . . . . . . . . . . 2.8.4 Innovation Management . . . . . . . . . . . . . . . . . . . . . . . . 2.9 Procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9.1 Procurement Procedure in the Agile Approach . . . . . . . . 2.9.2 Procurement Procedure in the Traditional Approach . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Further Readings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

142 143 144 149 157 160 162 164 166 167 167 169 172 173 174 175 184 188 193 194 194 196 197 198 199 200 202 203 203 214 215 216 218 219 219 219 228 232 234 234 235 240 240

x

3

Contents

Human . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Competence Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Conditions for Good Performance . . . . . . . . . . . . . . . . . . . . . . . 3.3 Human Phenomenon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 The Brain Is a Miracle . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Basic Needs Determine Our Lives . . . . . . . . . . . . . . . . . 3.3.3 Human Perception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Awareness and Self-Reflection . . . . . . . . . . . . . . . . . . . 3.3.5 Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.6 Humour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Culture and Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 What Is Culture? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Organisational Culture . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Project Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Generations Y, Z, and Alpha in the World of Work . . . . 3.4.5 Becoming Aware of One’s Own Cultural Imprint . . . . . . 3.5 Stress and Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Fight or Flight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Psychological Stress . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Stress Traffic Light . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.4 Stress Competence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.5 Life Means Change . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.6 Personal Coping Strategies and Dilemmas . . . . . . . . . . . 3.5.7 Burnout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Motivation and Meaning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 Goal Orientation of the Human Being . . . . . . . . . . . . . . 3.7.2 What Is Motivation? . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.3 Meaning as an Intrinsic Motivator . . . . . . . . . . . . . . . . . 3.8 Self-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1 Human Self-Efficacy . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.2 Personal Competence Circle: Strengths and Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.3 Time Management and Work Technique . . . . . . . . . . . . 3.8.4 Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.5 Dealing with Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Personal Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.1 What Is Communication? . . . . . . . . . . . . . . . . . . . . . . . 3.9.2 Axiom Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.3 Communication Square . . . . . . . . . . . . . . . . . . . . . . . . 3.9.4 Communication Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.5 Meta-Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.6 I and You Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.7 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.8 Questioning Techniques . . . . . . . . . . . . . . . . . . . . . . . .

241 241 242 244 244 247 250 252 253 254 255 255 255 256 258 259 259 259 260 261 262 263 263 264 265 267 267 267 269 271 272 273 274 276 279 281 281 282 282 285 286 287 288 293

Contents

xi

3.10

Personal Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10.1 The Three Living Worlds . . . . . . . . . . . . . . . . . . . . . . . 3.10.2 Self-Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10.3 Coaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10.4 Intervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10.5 Upside or Downside Strategy? . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Further Readings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

296 297 298 304 306 307 307 308

Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Leadership and Cooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Leadership: What Is It? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Different Forms of Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Leadership Styles and Models . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Directive Versus Delegative Leadership Style . . . . . . . . 4.4.2 Situational Leadership Model . . . . . . . . . . . . . . . . . . . . 4.4.3 Leadership Without Authority to Issue Directives . . . . . . 4.4.4 Positive Leadership in Projects . . . . . . . . . . . . . . . . . . . 4.4.5 Tips for Remote Leadership . . . . . . . . . . . . . . . . . . . . . 4.5 Self-organisation, Specific Characteristics in the Agile Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Principles and Requirements for Self-organisation . . . . . 4.5.2 What Does Self-organised and Agile Working Mean? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 How Does Self-direction and Leadership Work in Self-organisation? . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.4 Decide on Procedures and Solutions in Their Own Competence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.5 Important Factors for Self-organisation to Succeed and Be Effective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Leading with Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Management by Objectives MbO . . . . . . . . . . . . . . . . . 4.6.2 Leading by Objectives and Key Results (Management by OKR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1 Decision-Making Process in the Delegation . . . . . . . . . . 4.7.2 Delegation as a Recurring Process in Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Task, Competence, Responsibility (TCR) . . . . . . . . . . . . . . . . . . 4.9 Power and Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.1 Empowerment and Seizure: Power Is Based on Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.2 Traditional Sources of Power . . . . . . . . . . . . . . . . . . . . 4.9.3 Other Sources of Power in Project Management . . . . . . . 4.9.4 Projects Always Need Borrowed Power . . . . . . . . . . . . .

309 309 310 312 313 315 315 317 319 321

4

322 322 322 323 324 325 327 327 328 330 330 331 333 334 334 335 336 337

xii

Contents

4.9.5 Sources of Power: Between Person and Institution . . . . . 4.9.6 Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10.1 Negotiations in Project Management . . . . . . . . . . . . . . . 4.10.2 What is a Negotiation? . . . . . . . . . . . . . . . . . . . . . . . . . 4.10.3 Negotiation Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10.4 Conducting a Negotiation According to the Harvard Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Moderation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11.1 Iceberg Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11.2 Phases of Moderation . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11.3 Responsibility and Competences of the Moderator . . . . . 4.11.4 Checklist for the Preparation of a Moderated Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Communicate Effectively with Virtual Teams . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Further Readings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Aspects of Teams and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 What Distinguishes Teams from Working Groups? . . . . 5.1.2 Composition of the Project Team . . . . . . . . . . . . . . . . . 5.2 Dynamics in Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Forming: Orientation . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Storming: Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Norming: Familiarity . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.4 Performing: Working in the System . . . . . . . . . . . . . . . . 5.2.5 Adjourning: Farewell and Separation . . . . . . . . . . . . . . . 5.2.6 Dynamics and Interaction . . . . . . . . . . . . . . . . . . . . . . . 5.3 Roles in the Project Organisation . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 “Line-up” in Teams: Position and Role . . . . . . . . . . . . . 5.3.2 Role Carrier and Role Sender . . . . . . . . . . . . . . . . . . . . 5.3.3 The Role as a Link Between Organisation and Person . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Influencing Factors for Successful Cooperation . . . . . . . . . . . . . . 5.4.1 Psychological Safety . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Positive Psychology and What Distinguishes High Performance Teams from Others . . . . . . . . . . . . . . . . . . 5.4.3 Belbin Team Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.4 Radical Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.5 Multicultural Cooperation . . . . . . . . . . . . . . . . . . . . . . . 5.4.6 Organisational Constellations . . . . . . . . . . . . . . . . . . . . 5.5 Change and Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Change and Transformation . . . . . . . . . . . . . . . . . . . . . 5.5.2 Mind Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

338 338 340 340 340 341 348 351 352 352 353 353 355 357 357 359 359 359 360 362 362 363 365 366 367 368 368 368 370 371 374 374 377 378 381 383 388 390 391 392

Contents

5.5.3 The Human Being and Change . . . . . . . . . . . . . . . . . . . 5.5.4 “Formula” of Change . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.5 Readiness for Change in Organisations . . . . . . . . . . . . . 5.5.6 Psychology and Factual Logic in Projects . . . . . . . . . . . 5.5.7 Willingness to Shape and Cooperate . . . . . . . . . . . . . . . 5.5.8 Change Process Model . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.9 Dealing with Resistance . . . . . . . . . . . . . . . . . . . . . . . . 5.5.10 Procedure in Change Projects . . . . . . . . . . . . . . . . . . . . 5.6 Conflict Management and Crises . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 What Is Conflict? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.2 Origin and Symptom: The Systemic Phenomenon . . . . . 5.6.3 Conflict Syndrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.4 Conflict Symptoms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.5 Potential of Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.6 Types of Conflict in Project Management . . . . . . . . . . . 5.6.7 Conflict Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.8 Models for Conflict Diagnosis . . . . . . . . . . . . . . . . . . . . 5.6.9 Conflict Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.10 Conflict Resolution Depending on the Type of Conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.11 Conflict Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.12 Dealing with Crises . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 Finally. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Further Readings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

xiii

392 394 395 395 396 397 399 405 408 409 410 413 414 415 415 423 427 434 443 451 453 455 455 456

Reference List for the Individual Competence Baseline (ICB) from IPMA (International Project Management Association) . . . . . . . . . . 457

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

About the Authors

Jürg Kuster, Graduate Engineer ETH Zurich Studied electrical engineering and information technology at ETH Zurich. Worked for many years as a manager and project manager in different companies. Trainer and expert for the Swiss professional examinations for IT project manager and business IT specialist. Lecturer at various training institutes. Owner of Pentacon AG in Zurich, and, from 2008 to 2020, Managing Director of BWI Management Weiterbildung at the Department of MTEC of ETH Zurich. Main areas of work: Leadership development and training, coaching for leaders and project managers, conception, design and implementation of companywide project management standards and training programmes. www.pentacon.ch Christian Bachmann, Business Economist FH Studied at the University of Applied Sciences in Aargau and Chur, graduating as a business economist. Further training in coaching, organisational development, and theology: Systemic Training Group, Koenigswieser & Network, Vienna; MAS ZFH in Supervision and Coaching in Organisations, IAP Zurich; MAS Spiritual Theology in Interreligious Processes, University of Salzburg. Ten years of operational project management in the financial services industry. Independent consultant and coach since 2006, trainer since 2011, and partner at the BWI AG Consulting and Further Education Institute, Zurich, since 2020. Main areas of work: Trainer in self-management with a focus on resilience and stress management, project management, and facilitation of meetings xv

xvi

About the Authors

(in industry and in educational organisations). Process support in the further development of project organisations. Coaching of managers and project managers. www.bwi.ch Mike Hubmann, Engineer FH, EMBA HSG, Integral Systemic Coach Training in coaching, organisational development, systemic constellation work, agile and traditional project management (Certified Senior Project manager IPMA Level B, Hermes 5 Advanced, Certified scrum master), MBA in Business Engineering, Marketing and Electrical Engineering. More than 30 years of experience in project management of agile and traditional projects. Mastering challenging projects is his core competence. Since 2009, assessor for IPMA Level B certifications at VZPM, and, since 2017, additionally examination expert. Since 2011, trainer, coach and, since 2020, partner at the consulting and Further Education Institute BWI AG, Zurich. Owner of Mike Hubmann GmbH since 2016. Main areas of work: Coach and organisational developer for individuals, teams, and organisations in challenging business situations or in change situations, constellator (systemic constellations, organisational constellations), trainer, consultant, project manager, and project management expert. www.bwi.ch Robert Lippmann, Lic. oec. publ., NDU SNU Commercial training, then studies and degree in economics (Lic.oec.publ., University of Zurich). Further training and diplomas in work and organisational psychology, group dynamics and postgraduate diploma in corporate development (DNU SNU). Since 1996, independent management and organisational consultant, trainer and coach in industry, the service sector, and public administration, primarily in project management, leadership, coaching, communication, and facilitation. Many years of experience as a project manager, specialising in the operational implementation of concepts, organisational projects and as a client representative. Co-author of the reference book Lippmann

About the Authors

xvii

E. (ed.), Coaching (3rd ed. 2013) published by Springer Verlag. Main areas of work: project management and consulting, coaching, trainer in Further Education for executives and project managers, mandates as temporary manager. www.lippmann.ch Patrick Schneider, graduate engineer ETH, EMBA, University of Zurich Studied electrical engineering at ETH Zurich. Diploma thesis at Harvard University. Executive MBA in General Management at the University of Zurich and Stanford University. Certified project manager IPMA Level C. Fifteen years of experience in business development with internationally active service providers, in e-commerce and IT outsourcing. Four years of divisional management at executive level with product management, project management, test department, and customer service in the machine industry. Since 2015, active as a trainer for project management, as a project manager and as a consultant for project, product, and process management. Founder and owner of Schneider Associates GmbH. Main areas of work: In-house training for product and project management; introduction of processes and standards; project management mandates. www.schneiderassociates.net

1

Introduction

1.1

Project Management, What for?

The dynamics of change in business and research are high. Innovative organisations have recognised project management as a critical success factor. The products and services of tomorrow emerge from temporary, targeted, and interdisciplinary cooperation. For this, it is necessary to design the optimal working methods and organisational forms according to the situation, so that efficient management and communication channels are possible. Project management was developed in the 1950s in the aerospace and plant construction industries. Special planning methods such as the network planning method (Critical Path Method) or PERT (Programme Evaluation and Review Technique) were developed for these projects. They were used to solve complex tasks not only for technical undertakings, but also for problem and crisis situations in all management functions: for example, for marketing, and in human resources, finance and organisation in private-sector companies and public administrations. The traditional approaches are still valid today and are widely applied. However, in various areas such as product or software development, they have reached their limits. Agile methods such as scrum help and increasingly rely on the principle of selforganisation of teams. They are deliberately lean and focused on fast, iterative delivery of results and prototypes. Mixed forms have developed from the traditional and agile approaches, which are referred to as hybrid project management. If projects include operational, structural, organisational, or personnel aspects, project management is often also called change management.

1.1.1

The Taylor Tub

In the industrial age of Taylorism, traditional project management helped to create efficient procedures. Today, in the knowledge age of the network economy, complexity and dynamics determine the everyday life of companies. Bernd Oestereich # Springer-Verlag GmbH Germany, part of Springer Nature 2023 J. Kuster et al., Project Management Handbook, Management for Professionals, https://doi.org/10.1007/978-3-662-66211-3_1

1

2

1 Introduction

Share of value added Machine

complicated

Efficiency pressure

Man

complex

Who?

How?

Who?

Craft

Efficiency Method Rules

Knowledge Trying it out Meaning Innovation pressure 1980 2000

1900 Manufactury

tight local markets

Taylorism Industrial age

wide global markets

Zeit

Network economy

tight global markets Market pressure

Fig. 1.1 Taylor tub

and Claudia Schröder illustrate this using the model of the Taylor tub by Wohland et al. (2004) and Pflaeging and Hermann (2015) in Fig. 1.1. Companies have to adapt to the intense competition and the increased demand for personalised offers. In order to master the high dynamics and complexity of everyday life, they tend to use agile approaches in project management. Depending on the situation in which an organisation finds itself, it then chooses the appropriate approach accordingly.

1.1.2

BANI Is the New VUCA

Science is constantly developing new explanatory models for changes seen in the world; e.g. the sensemaking model BANI by Jamais Cascio (Facing the Age of Chaos, April 2020). It describes four trends that are increasingly observed in today’s world: • • • •

Brittle: many systems have become unstable and can collapse at any time Anxious: a diffuse basic fear has taken hold of the world Non-linear: linear logic has long since reached its limits Incomprehensible: previous explanatory models are increasingly losing their value

1.2 What are Projects?

3

The VUCA model (W. Bennis, B. Nanus, 1987) was developed after the end of the cold war and consists of the following four elements: • • • •

Volatility: Fluctuations and rapidity in the digitalised world Uncertainty: Difficulty in predicting events and trends Complexity: Many influencing factors are interdependent Ambiguity: Clear and unambiguous decisions are rarely possible any more

This great speed of change also repeatedly leads to adjustments in the understanding of project management. In summary, the following features characterise this domain: • A flexible and quickly reactive temporary organisation ensures the optimal handling of the respective project. • Project management facilitates and promotes direct, interdisciplinary cooperation. • The competences of leadership are clarified in the project organisation. • Direct communication channels within and outside the project are easily accessible. • The existing performance potential is activated through teamwork and a stimulating atmosphere. • Clear affiliation to the project team makes it easier to identify and deal with conflicts of loyalty. • Involving the people concerned makes it possible to form a learning organisation.

1.2

What are Projects?

A generally valid definition of the term project has not been agreed upon yet. Organisations define projects differently according to their needs. The following common characteristics can be singled out: • Projects are goal-oriented. They bring about changes that can result in very different reactions: from euphoria to resistance, from scepticism and fear to joy and motivation. They require great organisational-psychological demands to manage. • Projects are innovations. Either they push the limits of what has been technically or organisationally feasible so far (e.g. new information and communication technologies), or they are something completely new for the organisation, for which knowledge has to be acquired at first (e.g. by means of self-organisation). • Projects are undertakings having clear boundaries: They are one-off, limited in time and under deadline pressure. • Projects are interdisciplinary: they go beyond the usual organisational structure and touch on different disciplines and areas of responsibility. • Projects are of high content and social complexity.

4

1 Introduction

• Their character changes from a phase to the next (vision, concept, execution), and they require different management skills at every step. • Projects are difficult to plan and control, they require special organisational measures as well as clear and unambiguous decisions. • Projects need extraordinary resources in terms of leadership, knowledge, personnel, and finances. • Depending on their size and complexity, projects also carry various risks, namely risks of a financial, personnel, technical, and scheduling nature. • Projects are social systems: they need their own project organisation for their execution. The team of authors defines a “project” as follows: Definition A project is a unique, cross-departmental, time-limited, goal-oriented, and interdisciplinary undertaking that is so important, critical, and urgent that it cannot be handled within the existing line organisation, but requires special organisational framework conditions. Projects which are not really projects, but in which individual elements of project management are applied, include: • one-off special assignments that can essentially be fulfilled by one person, i.e. without a separate project organisation. • continuous processes such as learning, production, development, or change processes without a defined end. They are more like a stream. However, projects can be embedded in them. For example, the conception and introduction of a quality management system is usually handled as a project in order to install on-going feedback and learning processes. The principles and methods of project management can on the whole be adopted for such projects, too. Each organisation can and should set criteria based on its level of project management maturity as to the scope and complexity of a project. It is often a good idea to classify projects. A higher number of governance documents and processes are prescribed for projects with a higher classification. Table 1.1 shows an example of project classification. Other criteria used in practice for classification can be: • • • • •

Personnel expenses internal/external Content/social complexity (Sect. 1.2.1) Internal vs. customer projects Project duration In addition to the project-specific classification, projects can also be grouped together in programmes according to their interdependence, see Sect. 2.7.3.

1.2 What are Projects?

5

Table 1.1 Example of a project classification Criterion Project costs Complexity

A Projects >€1m Group-wide

B Projects > 250 k€ Business unit

C Projects > 100 k€ Maximum 3 departments Low

D Activities ≤ 100 k€ Maximum 2 departments Low

Strategic importance Risk Default documents according to matrix list Governance structure

High

Medium

Very high All mandatory

High Many mandatory, some optional

Medium Some mandatory, many optional

Low No specifications

Monthly steering committee (group)

Regular steering committee (business unit)

Ad hoc steering committee at the request of the PL

Optional

Classification (A, B, C, D) is based on the highest criterion

Table 1.2 Project characteristics Task

Closed Open

Social complexity

Deep High

1.2.1

Known, clear task with limited solution options, e.g. structural extension for certain uses Many possibilities regarding content and approach without solution ideas, e.g. improving the flexibility and reaction speed of an organisation Unproblematic cooperation, e.g. few stakeholders, little differences in interests, cooperation mainly in one field of expertise Interdisciplinary, politically explosive, different user interests, great potential for conflict

Project Characteristics

The character of a project gives the project manager important information on how to structure the project, define the project organisation, and see what resources are needed. There are different ways of characterising projects. A distinction is made between projects according to the nature of their task: closed or open, and according to their social complexity.: low or high (Table 1.2). Four project characteristics can be derived from this (Fig. 1.2):

6

1 Introduction

Social complexity

High Extends across departements or areas, interdisciplinary, complicated causal relationships

Acceptance project Standard project

Pioneering project Potential project

Low Cooperation mainly within one specialist field, simple causal relationships, low risk Goals Closed Clear goals

Open Goals with a wide range of possibilities in terms of content and approach

Fig. 1.2 Project characteristics

• Standard projects can draw on a wealth of experience and can therefore be handled in a standardised and simple manner. Examples: technical customer project, replacement investment. • Acceptance projects are projects with clearly defined tasks. Based on experience, methods and tools can be formalised and standardised to a certain extent. As they are often associated with acceptance problems, communication with stakeholders plays a crucial role. Examples: a road construction project, or a complex software project. • Potential projects are tasks with open questions, but which are not (yet) closely linked to the project environment and are not too risky in this respect. The project organisation here is usually simple and small. This category includes studies, potential clarifications, feasibility studies, often also research projects. Examples would be: product innovations, and the development of new business models. • Pioneering projects are interventions having far-reaching consequences in the organisation; they span several areas, have a high novelty content, and are threatening and risky for many of those affected. The scope of the task is difficult to estimate. Examples might be, for instance, the merger of two companies, or the development of self-driving vehicles.

1.2 What are Projects?

7

Many projects alter their project character during their development from the initialisation phase to the introduction. They often change from a potential project to a pioneer project and then turn into an acceptance or even a standard project. This typology can not only provide information about the basic project management approach, the choice of the project organisation, the characteristics of the communication, or the methodological focus, but also about the necessary strengths and qualifications of the project manager. For example, a construction project requires different qualifications than a change project, a development project, or an order processing project. The traditional approach is well suited for the handling of standard projects. On the other hand, agile approaches are better suited for the handling of pioneer projects, potential ones, and even acceptance projects. Estimating dates and costs is easier in standard and acceptance projects. Dates and costs can be planned with a low tolerance. In contrast, the estimation of the effort needed and the derivation of a possible schedule in potential and pioneer projects is much more demanding and tends to be associated with a higher degree of uncertainty and fuzziness.

1.2.2

Project Types

Another way of classifying projects is to arrange them according to their purpose. For some purposes, separate project procedures have been developed and standardised by appropriate bodies. Typical project types are: • • • • • • • • • • •

Investment projects Product development projects Organisational development projects Change projects Information and communication technology projects (ICT projects) Software development projects Order processing projects, customer projects Process optimisation projects, efficiency improvement projects Infrastructure projects Building projects Research and development projects

1.2.3

Emergence of Projects

Projects can arise in different ways as shown in Fig. 1.3. Depending on how the project originated (as an internal project or customer project), depending also on what its history is, what type of project it is, or what project characteristics it has, the project manager has to adapt his approach accordingly. These points have a direct influence on the selection of processes and tools, as shown in Table 1.3.

8

1 Introduction

Company

B

Project order

Management external customer A

Employees

Idea, suggestion for C improvement = Project request

Request for proposal Proposal

Signing = Project order

Contract negotiations External contract

Fig. 1.3 Emergence of projects

1.3

What Is Project Management?

Every company wants to achieve strategic and operational objectives. The objectives set cannot always be achieved through the line organisation. Depending on the situation, it makes sense to approach and implement plans and measures as a project. This makes it possible to bundle and focus forces. With regard to the management of projects, the traditional and agile approaches pursue different approaches. In the traditional approach, the following steps have proven to be very successful: • Subdividing the procedure as a whole into phases and work packages • Defining decision-making, leadership, and technical competence per phase In the agile approach, the focus of the elements is slightly different: • Empowered, self-organised teams are to continuously review and adapt • Timebox procedures with early and frequent deliveries " Project management is understood as a generic term for all planning, monitoring,

coordinating, and controlling measures that are necessary for the redesign or reorganisation of systems, processes, or problem solutions.

1.3 What Is Project Management?

9

Table 1.3 Different project types and characteristics require different approaches Order processing project

Internal development project at own risk

Suggestion for improvement, idea from own employees

Small project

Acceptance project

Innovation project, pioneering project

An external customer has a problem. The company has made a binding offer to the customer. Deadline and costs are fixed and legally binding, perhaps a contractual penalty has been agreed upon. The project manager focuses on proven standardised processes, low-risk and on-time execution, and effective cost control Management has initiated a strategic project to realign the company. Objectives and deadlines are not set in stone. In case of new findings, targets, deadlines, or costs can be discussed and adjusted Motivation and knowledge are given. The supervisor must have the employees’ backs in that they have sufficient resources to be able to work on the project efficiently in addition to all routine tasks Individual phases or activities can be passed over. The project manager works according to the standard process, decides at the start of the project to skip individual steps and reviews. He records this in the project documentation If major resistance is to be expected in a project, the project manager will involve all relevant stakeholders at an early stage and draw up a carefully coordinated information and communication concept The company has reached its limits with its product line and needs to rely on a completely new technology in manufacturing. The project manager will use a balanced mix of people with a wide range of abilities and experienced specialists and have both types of work in self-organised teams

The procedure for achieving the solution, the resources required for this, their use and coordination are more important than the solution itself. In contrast to project management, line management is more concerned with day-to-day business and its management of the organisations involved.

1.3.1

Hierarchies in Project Management

The “project management” method permeates the entire organisation. Different tasks are carried out by different hierarchical levels in the company. Programme management is about coordinating different interdependent projects, aligning priorities and allocating all resources, such as labour and finances, accordingly. Examples: Research programme, development programme, etc. A project portfolio consists of the projects and/or programmes of a company or a division. They do not necessarily have to be related to each other, but they have access to the same pool of resources, i.e. mostly to people and finances. It is about making the best use of the organisation’s resources and achieving the organisation’s strategic objectives while minimising risks.

10

1 Introduction

Product management encompasses all strategic and operational activities of a position or person responsible for a product or service in all areas of the company. Whoever is responsible for product management is usually also the contact person for customers. Developments, introductions, or problem solving in connection with a product may very well be regarded and handled as projects.

1.3.2

Dimensions in Project Management

The dimensions in project management can be illustrated well using the IPMA “Eye of Competence” (see Fig. 1.4).

1.3.2.1 Competence Area Perspective This competence area deals with the context of a project. It contains the following topics: • • • • •

Strategy Governance, structures, and processes Compliance, standards, and regulations Power and interests Culture and values

People

Practice

People

Practice

Perspective

Perspective

Fig. 1.4 Eye of Competence from IPMA (International Project Management Association)

1.3 What Is Project Management?

11

These topics set the framework and define the environment in which the project is carried out. In this handbook on project management, these topics are addressed in various places of this reference work and explored in greater depth.

1.3.2.2 Competence Area People This competence area deals with personal and social competences. It contains the following topics: • • • • • • • • • •

Self-reflection and self-management Integrity and reliability Personal communication Relationships and engagement Leadership Teamwork Conflicts and crises Ingenuity Negotiations Results orientation

This area of competence is key to the success of a project. A project is successful if it succeeds in shaping the relationships between people and teams in a constructive and positive way. In this handbook on project management, these topics are dealt with in Chaps. 3 “People” and 5 “Teams”.

1.3.2.3 Competence Area Practices This area of competence deals with methods employed in project management. It contains the following topics: • • • • • • • • • • • • •

Project design Requirements and objectives Scope of services and deliverables Procedure and dates Organisation, information, and documentation Quality Costs and funding Resources Procurement Planning and control Opportunities and risks Stakeholders Change and transformation

To master a project successfully, mastering the craft is an indispensable prerequisite. However, the decisive factor for project success often lies in the question of how to manage the relationships between people and teams. In this handbook on project management, these topics are mainly dealt with in Chap. 2 on “Methodology”.

12

1 Introduction

1.3.3

Principles of Procedure

The following principles and attitudes have proven effective in practice: • • • •

From the general sketch to more detail Investigate alternatives; variant formation Arrangement of phases Problem-solving methodology

The principles “from the rough and general to greater detail” and “investigating alternatives” are explained below. The two other principles (phase structuring Sect. 1.4.2 and problem solving Sect. 2.3.14) are so crucial to project management that they are dealt with separately.

1.3.3.1 From a Rough Sketch to a More Detailed Depiction The principle shown in Fig. 1.5 is an important basic attitude in the handling of a project. It is described as follows: At the beginning of the project, the field of observation should be broadly defined and then gradually narrowed and focussed. This applies to both the investigation of the problem area and the design of solutions.

Level A

Area of investigation

Procedure from rough to detail

Area of design

Level B

Level C

Fig. 1.5 Procedure from the rough to the detailed

1.3 What Is Project Management?

13

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

1.3.3.2 Variant Formation Figure 1.6 shows an indispensable part of good planning. It is a basic methodological approach and, if the principle of “from the rough to the detailed” is observed, works without any significant additional planning effort. If this principle is not observed,

Problem: Car ready for the scrapheap Spontaneous project idea: New car

Solution principles

Variants on the concept

Detail variants

Fig. 1.6 Example of a step-by-step variant formation

white

red

blue

14

1 Introduction

there is a greater risk that fundamentally different solution approaches will only be introduced into the discussion at an advanced stage of planning.

1.4

Process Models in Projects

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

1.4.1

Agile Approach

Traditional approaches have made and continue to make significant contributions to project management. In product and software development, however, it has been shown that many projects that were carried out with a waterfall method did not bring the desired results or even failed. The reasons for this are to be found in task complexity, faster working environments, and there being constant changes. Agile methods such as Scrum, Large Scale Scrum (LeSS), Extreme Programming, Kanban, or the Scaled Agile Framework (SAFe®) are employed to maintain control. Agile methods also help to realise a customer or user-specific and functioning software in the shortest possible time span, without the complete requirements

1.4 Process Models in Projects

15

having to be defined in detail at the beginning. Agile project management refers to an elastic, nimble, process-oriented, reflexive, learning approach. Its principles and values were published in the Manifesto for agile software development (Beck et al., 2001, http://www.agilemanifesto.org): • Individuals and interactions are more important than processes and tools • A software that works well is more important than extensive documentation • The cooperation with project stakeholders is more important than contract negotiations • Responding to change is more important than sticking to a rigid plan The agile manifesto follows these 12 principles: • Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software. • Welcome changes in requirements even late in development. Agile processes use change to the customer’s competitive advantage. • Deliver working software regularly within a few weeks or months, giving preference to the shorter time span. • Subject matter experts and developers have to work together on a daily basis during the project. • Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. • The most efficient and effective way to communicate information to and within a development team is face to face. • (Well-)functioning software is the most important measure of progress. • Agile processes promote sustainable development. The project owners, developers, and users should be able to maintain a steady pace indefinitely. • Constant attention to technical excellence and good design promotes agility. • Simplicity—the art of maximising the amount of unnecessary work not done—is essential. • The best architectures, requirements, and designs are created by self-organised teams. • At regular intervals, the team reflects on how it can become more effective and adjusts its behaviour accordingly. The values and principles of the agile manifesto can also be applied to areas outside of software development. In an agile approach, the dimensions time and budget are rigid, the result (the scope) is flexible. In a traditional approach, the scope is usually set while the time and budget dimensions remain flexible (or they are estimated based on the scope). This is a principle that often leads to time delays and budget overruns in projects. In this project management handbook, scrum is examined in depth as an agile process model.

16

1 Introduction

1.4.1.1 Scrum Scrum was initially very strongly influenced by the lean and innovative ways of product development in Japan (lean management). Scrum consists of a few rules. Figure 1.7 shows schematically the procedure according to scrum. The start phase (initialisation and product conception) is followed by iterations or sprints during pre-planned intervals of time (i.e. within timeboxes). The agreed-upon partial assignments are processed by teams that do and organise things acting largely on their own responsibility. The basic principle underlying these forms lies in the relatively short and predefined iteration cycles (timeboxes), within which highly motivated teams independently develop and test solutions (increments). In the process, learning experiences or new user insights flow into the next cycle. In scrum there are three roles (responsibilities): product owner, developer, and scrum master. The role of the traditional project manager either does not exist or is divided up between the two roles of product owner (technical and content-related control) and the scrum master (method specialist who removes any hurdles). The requirements for this are recorded in a prioritised product backlog. The content and prioritisation of this product backlog changes continuously during the project, which means that changes can be dealt with easily and flexibly. It is the product owner who controls the product backlog and determines the prioritisation. Scrum is an empirical process that follows a credo of “inspect and adapt”. The achieved result (increment) and the ways of working are thus regularly assessed in the sprint review and improved retrospectively. This ensures continuous improvement. A sprint is planned in such a way that at the end an increment is created which represents added value and is functional. This focus on the delivery of added value

Start-up phase Product Target

• • • • •

Product Backlog

• • • • •

Release Plan

• • • • •

Sprint 1

Sprint Backlog 1 • • •

Sprint 2

Product Increment 1 • • •

Sprint Backlog 2 • • •

Sprint 3

Product Increment 2 • • •

Sprint Backlog 3 • • •

Time

Fig. 1.7 Schematic representation of the agile procedure according to SCRUM

…

1.4 Process Models in Projects

17

prevents one from being preoccupied with anything unimportant. In sprint planning, the product owner specifies his priorities, wishes, and the sprint goal. Ultimately, the developers themselves decide on the effective content of the sprint according to the pull principle. This promotes personal responsibility and self-organisation. In addition, the pull system avoids systematically overloading the developers. It is also advisable to identify and address problems and obstacles at an early stage. Especially in the first sprints, the sticking points should be tackled and directed towards a solution. Scrum is hard work. New rules have to be learned, old habits discarded, obstacles overcome, and problems solved. Successfully applying scrum is a constant learning process that also requires time and patience. It is the central task of the scrum master to support the developers and the product owner in overcoming these challenges and to apply scrum successfully. The phase concept can also be applied to scrum in an adapted form. In the initial phase of a scrum project, it is essential that a product goal is first developed. This concretises the idea. The product goal describes the benefit for the future user of the product or service and the essential performance features. Furthermore, the initial product backlog and the release plan must be created in the beginning phase. Agile approaches have proven to be more flexible, faster, and more economical than planning-oriented project management in complex areas.

1.4.1.2 Kanban Kanban has its origins in the mid-twentieth century at Toyota. Kanban was developed as a method to increase flexibility and efficiency in production. The transfer of kanban’s ideas to the management of projects was later undertaken by David J. Anderson. Kanban does not prescribe any processes or structures. Like scrum, kanban promotes self-organisation in that the employees or the team independently pull tasks to themselves (pull principle). Kanban is based on four basic principles and six practices. The four basic principles of kanban are: • • • •

Start with what you are doing right now. Aim for incremental, evolutionary change. Respect current processes, roles, responsibilities, and titles. Promote leadership and responsibility at all levels of the organisation. The six practices of kanban are:

• • • • • •

Make the work visible (Kanban board, see Sect. 2.5.2). Limit the amount of work started. Measure and manage flow. Make process rules explicit: clear and known. Develop feedback mechanisms. Make collective improvements.

18

1 Introduction

The principles of kanban can be combined well with other agile methods such as scrum or the traditional approach to project management.

1.4.1.3 Scaled Agility An agile approach using scrum is suitable for teams with a size of three to ten people. If larger teams or an entire company want to work agilely, an approach like scrum is not sufficient. The two best-known approaches to scaling agility are Scaled Agile Framework (SAFe®) and Large Scale Scrum (LeSS). SAFe® and LeSS provide approaches for agile working and synchronisation across multiple teams. Both approaches are based on teams working according to scrum or a scrum adapted approach. In SAFe® several teams are grouped into an “agile release train”. These release trains are aligned with value streams. Quarterly big room planning takes place in which the next product increment and the work for the next 3 months are planned. The implementation then takes place in sprints during the next 3 months. At a higher level, a programme backlog is kept and each team also keeps its own backlog. There is a product owner for each team and also a product manager at this level, who among themselves divide up the work of the product owner. This also applies to the work of the scrum master. At a higher level there is a release train engineer. For large organisations, several agile release trains can be combined into one solution train. At the company level, management is carried out according to the principles of lean portfolio management (see Sect. 2.7.2). The LeSS framework is closer to the scrum method. It divides events such as planning, review, and retrospective into a general part for all teams and an individual part for each team. In addition, there are further synchronisations between the teams during the sprint. SAFe® and LeSS are efficient approaches to scaling agility across the whole organisation. They are oriented towards scrum and lean management. Part of the autonomy and self-organisation in the teams is given up in favour of a common orientation. In addition to the methodological support of these frameworks, it is also crucial to develop the attitude and mindset of the people involved in the direction of agility. If this is not done, there is a high risk that the methodological approach will be changed, but the old problems will be retained or simply reorganised.

1.4.2

Traditional Approach: Phase Concept

The principles of “from the rough to the detailed” and “variant formation” mean the following for the processing of problems: namely that the Idea, development, implementation planning, and the realisation of a solution are divided into individual work packages, and these in turn into phases that can then be logically and temporally separated from each other. The purpose of this is to split the development of a solution as a whole into manageable stages. This enables a graduated planning, decision-making, and concretisation process with predefined milestones or correction points.

1.4 Process Models in Projects

Assignment

Initialisation

19

Concept

Realisation

Introduction

Milestone: Size of the rhombus as a measure of the probability of a project break-off Project break-off

Fig. 1.8 The ideal phase concept

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

1.4.2.1 The Project Commissioning Phase This phase, which is usually rather unstructured, comprises the period between the recognition of the problem and the decision to do something concrete. The problem can either be formulated in real terms or merely be the result of vague assumptions. It is not important where the impetus for redesigning or reorganising comes from. What is important is that it is received, accepted, and approved in a project agreement by those authorised to allocate the necessary human, financial, and organisational resources.

20

1 Introduction

Systems Engineering Product development Building projects SIA projects projects 1 Preliminary project

1 Preliminary project

2 Main project

2 Development

3 Detailed project

3 Production preparation

IT projects with Scrum

1 Strategic planning 1 Initialization 2 Preliminary studies 2.1 Feasibility 2.2 Selection process

2 Rough concept

3 Project Planning 3.1 Preliminary project 3.2 Building project 3.3 Approval process 4 Tender process 5 Realisation 5.1 Detailed design

4 Implementation

4 Pilot series

5.2 Execution

5 Introduction

5 Serial production

5.3 Commissioning

3 Sprints Iterative programming Introduction and acceptance

6 Facility Management 6.1 Operation 6.2 Maintenance

Fig. 1.9 Phase models and phase designations

The preliminary work and activities of this first “definition phase” ideally result in a project factsheet. The project factsheet contains information on the strategic reference and the expected added value, an initial rough schedule and the expected costs. It names the central project roles and, together with the business case, serves as a basis for deciding whether the project should be approved and included in the project portfolio.

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

1.4 Process Models in Projects

• • • • •

21

Elaborate requirements: What should be realised? Determine project organisation Identify and analyse stakeholders Identify risks and develop measures to reduce them Structure and roughly plan the project

The project owner is responsible for transforming the proposal into a project order. From a tactical point of view, the project owner often delegates the preparation of the project proposal to the project manager, who conducts the “kick-off” at the end of the phase. If one decides to abandon the project at the end of the initialisation phase, this is neither a “mistake” nor some kind of failure, but rather a conscious decision based on newly attained knowledge.

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

Manufacture plants and equipment Create software Create user-friendly documentation or operating instructions Establish organisational arrangements in the event of disruptions, etc. Determine support organisation, maintenance concepts, etc. Perform tests

Often, individual subsystems are also built here which are integrated into the overall solution. Comprehensive project controlling helps to ensure that the targeted objectives are achieved. Any change requests are managed via the change request process and therein taken to the decision-making stage.

1.4.2.5 The Introduction Phase Introduction Only relatively small and simple solutions can be introduced as a whole without taking a great risk by keeping them in one piece. With large and complex systems, an

22

1 Introduction

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

1.4.2.6 The Utilisation Phase When the project is completed, the utilisation phase begins. After a predefined period of time an evaluation or control of the project outcome takes place. Depending on the type of project, work is recorded under warranty or for an improved version of the solution in a new release. Usually, an effectiveness review

1.4 Process Models in Projects

23

or project evaluation is carried out here: How precise have the business forecasts been?

1.4.3

Hybrid Project Management

Fewer and fewer projects are so clearly positioned that only the traditional or agile approach is suitable for their management. In practice, they usually lie somewhere in between, so that a combination of both project management approach models becomes obvious (Fig. 1.10). The best way to combine them is to handle selected project phases or sub-projects differently. For example, in a product development project in which the requirements are only known roughly at the beginning, an agile phase can be switched on in order to afterwards continue in the traditional way. In a complex customer project with sub-projects, software development with scrum can be more advantageous, while the traditional approach is more suitable for the other sub-projects. It is also possible to use individual components of the traditional approach such as daily stand-up meetings, kanban board, planning in cycles and iterations, or using retrospectives gained from the agile approach. This form of hybrid project management has a lot of potential. Often, corporate structures require that a project is set up in a traditional way towards the outside environment. This means that existing reporting structures or stage-gate processes can be utilised. In order to maintain

Traditional and agile settlement of phases Initialisation

Conception

Realisation

Manufacturing planning

Set up of production line

Traditional and agile settlement of subprojects Initialisation

Conception

Realisation Hardware I Realisation Hardware II

agile traditional

Fig. 1.10 Traditional and agile phases

Realisation Software

Introduction

24

1 Introduction

the necessary flexibility in project management, it is advisable to work agilely in the project. The aim is to skilfully combine traditional and agile elements. From the point of view of project management, the “both and” approach places high demands on flexibility. Whereas in traditional project management the focus lies more on rational connections, planning, and direct control, in the agile approach it is on the evolutionary and social aspect as well as on indirect control. Both approaches require a different understanding of organisations, roles, and leadership. Individual methods can be “hybridised”. But the rule here is: only mix them in a targeted and conscious way, otherwise there is a risk of weakening them. For example, the kanban method can be used in a traditional project sequence with parallel work packages, as it is more flexible and transparent than bar charts.

1.4.4

Procedure in Change Projects

Every project brings about change. The term “change project management” covers all projects that aim at radical, comprehensive, and interdisciplinary changes within the organisation. This can be: introduction of new processes, mergers, implementation of new strategies, etc. In the process, new behaviours and cultures are often aimed at, e.g. communication culture, error culture, etc. In contrast to change projects, we exclude “continuous improvement” (CIP, KAIZEN). The procedure in change projects depends very much on the context in which the change or transformation takes place. In order to understand this context, it is advisable to carry out a context analysis as a first step. Kurt Lewin developed the basic cycle of change management consisting of unfreeze (initiating change), move (shaping the transition process), and refreeze (institutionalise the new state). Building on this, John P. Kotter developed the traditional approach of the eight-step model for change projects (Kotter, 2012). Since change projects often do not run in a linear fashion and can therefore only be planned in advance and to a limited extent, an agile approach such as Jason Little’s lean change cycle can also be used in change projects. See also Sect. 5.5.10.

1.4.5

Further Process Models

1.4.5.1 V-Model The V-model is another sequential process model. The procedure is suitable in industries and areas putting high demands on safety, such as medical technology or aviation. On the left branch of Fig. 1.11, the project object is specified step by step from the loose design to the detailed design (top-down specification). On the right branch, the different realisation and verification stages are gone through from the bottom-up (bottom-up integration). 1.4.5.2 Simultaneous Engineering Simultaneous engineering (also called concurrent engineering) is a response to the demand for shorter development times. The partial parallelisation of processes speeds

1.4 Process Models in Projects

25

Validation

Stakeholder Requirement

System requirements System specification

Validation Release

Verification System test

Architecture, technical detailed design

Integration test

Fine architecture, Component design

Component module or unit test

Development Programming

Fig. 1.11 V-model

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

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

26

1 Introduction

Sequential project procedure Correction loop

Correction loop

Procurement

Engineering

Preceding phase

Correction loop Succeeding phase

Simultaneous Engineering Time saving

Preceding phase

Engineering

Project start

Coordination Procurement Coordination Succeeding phase

Originl market introduction

Optimised market introduction

Coordination

t

Fig. 1.12 Simultaneous engineering as an overlapping phase concept

Step 1: Analysis, Feedback

Step 4: Planning next iteration

De

tai

Ro

led

ug

ets

Fig. 1.13 The version concept (spiral model)

de

sig

n

es

Ta rg

Step 3: Realisation

hd

ign

Step 2: Evaluation

1.4 Process Models in Projects

27

attached. To prevent this, it must be clarified at the beginning at which point good is good enough. Hence, termination criteria have to be defined, e.g. three iterations of 2 weeks each or optimising until test users give a certain grade. This concept is very similar to the agile approach according to scrum. Another development method with a high user focus is the design thinking described in Sect. 2.8.2.6.

1.4.6

Choice of a Process Model: Traditional, Agile or Hybrid?

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

28

1 Introduction

complex

complicated

• • • • •

• the system is predictable, • cause and effect are present but not everyone can see it, • expert advice is needed, but more than one correct answer.

everything is in flux and unpredictable, no correect answers, several unknowns, recognisable orientation patterns, many competing ideas, creative and innovative approaches are needed.

senss – analyse – respond probe – sense – respond

er

ord

Dis chaotic

simple

• • • •

• repeatable patterns and unique events • clear causes and effects, • clear relationships, • there are correct answers.

high turbulence, no cause-effect relations, big unknowns, many decisions under high time pressure.

act – sense – respond

sense – categorise – respond

co

al

ex pl

c liti

m

po d

te

ica

pl

m

co

WHAT: Requirements

tic

ao

ch

unclear

Fig. 1.14 Cynefin framework according to David J. Snowden (simplified representation)

ar

clear

ion

vis

e

pl

sim

y

certain

Fig. 1.15 Stacey matrix

HOW: Technology

uncertain

1.5 Projects are Based on Teamwork

29

Table 1.4 Criteria for selecting a suitable process model Characteristics of the project Complexity of the task Stability of the requirements Team member qualifications Team size

Spatial distribution

Traditional Standard project

Agile Potential project or pioneer project

Simple or complicated Stable

Complex or chaotic

Inexperienced in agile approaches Small and large teams Local or distributed over several locations

Volatile Experienced in agile approaches Ideally less than nine people. Multiple networked teams possible Locally in one room or at the same site

Hybrid Pioneer project, acceptance project, or potential project Complicated or complex Volatile Experienced in agile approaches Large teams

Distributed over several locations

The choice of a suitable process model is a demanding task. It should be done at the beginning by the project owner together with the project manager. It is possible to change the process model during the course of the project, but this should be done in a well-considered and conscious manner. Making ad hoc changes in the process model is not advisable. It can still be observed too often that companies use agile methods and processes in projects or parts of them, but do not enable the corresponding teams to act in an agile manner. Table 1.4 provides guidance for the selection of the process model.

1.5

Projects are Based on Teamwork

Project work is always teamwork. An individual cannot manage the complexity of a project doing it alone, but only in association with others. This makes teamwork an essential success factor in project management. The model of the three levels of cooperation in Fig. 1.16 summarises the requirements for teamwork.

1.5.1

Content: Working in the System

The scope is always the deeper meaning and the reason for the existence of a project, whether it is a product, a service, an application, a process, or the further development of the organisational culture. In some way, added value must be created for the organisation or the customer. In order for several people to work towards a common scope, they must know it and know what it is about. Objectives and restrictions guide them to make the right decisions and to create the appropriate documents, e.g. concepts, specifications, project orders or product visions, product backlog, and sprint backlog. The productive work is also located at this level.

30

1 Introduction

Content

To know, what is going on Productive work, requirements and scope, cost, time, decisions, concepts

Interdisciplinary cooperation Relationship Develop relations, trust, personal communication, project culture, conflict management Shape the cooperation Organisation Project organisation, connection to line organisation, approach (structures, processes, methods)

Work in the system

Work on the system

Fig. 1.16 The three levels of cooperation

1.5.2

Organisation and Relationship: Working on the System

In order for several people to be able to achieve a common scope, framework conditions must be fulfilled for their cooperation. Organisation The line organisation provides the project with financial, technical, and human resources. The project is therefore always dependent on the line organisation. Consciously or unconsciously, the following aspects, among others, have an effect on the project coming from the organisational level: • • • •

Linking the project to the leading line organisation (Sect. 2.3.8.8) Position, roles, and role assumption in the project organisation (Sect. 5.3.1) Methodological guidelines, guides, or manuals (Sect. 2.3.12) Competence regulations (Sect. 2.3.8.9) and communication processes (Sect. 3. 9.4)

Relationship Interdisciplinary cooperation is an integral part of project management. It is assigned to the level of relationship. We, as people, as social creatures, depend on being able to live sustainable relationships. This enables us to satisfy essential basic needs such as security, social recognition, and self-development (Sect. 3.3.2). For this, it is of prime importance that every human being can perceive him- or herself as part of the greater whole. As explained in Sect. 1.6.3, human beings are non-trivial systems: their behaviour is neither externally controllable nor predictable. What may be controlled, however, is the shaping of relationships between people in a group. In project management, the first step towards shaping these relationships is the stakeholder analysis with the communication concept. Other aspects also have an influence:

1.5 Projects are Based on Teamwork

31

• How well developed is the basis of trust (Sect. 3.3.5) and cohesion (Sect. 5.2.3)? • How do the formal and informal networks work? (Sect. 4.9.3) • How is communication to be rated (Sect. 3.9) and how is feedback dealt with? (Sect. 3.9.7) • How does a team deal with problems or even failure? (Sect. 3.8.5) • How are negotiations conducted (Sect. 4.10) and how are conflicts managed? (Sect. 5.6) • How is the project culture shaped? (Sect. 3.4.3)

1.5.3

Interactions

Of course there are interactions between the three levels of cooperation. Unclear objectives or a contradictory project organisation sooner or later become visible on the relationship level and can manifest themselves in the form of personal or emotional conflicts (Sect. 5.6.2). In addition, the needs of the individual team members are also different: some want to work on the substantive issues immediately, as this is the level at which they feel safe. Others cannot work on content at all until they have attained welldeveloped relationships and a solid basis of trust for an open exchange. Individuals have needs but these may be expressed differently even if similar. They can be captured by personality typologies such as VIA Character Strengths, Belbin Team Roles or MBTI (Sect. 3.10.2). An important task of the project manager, product owner, and scrum master is to promote and develop cohesion in the project team or scrum team. If this succeeds, the team goes in the same direction (Fig. 1.17).

Develop and promote cohesion in the team …

Fig. 1.17 Team building and traction

… and work towards the goals with combined energy and determination

Project goal

32

1 Introduction

1.6

Projects are Social Systems

1.6.1

Taylorism in our Heads

We as humans like to organise our lives in a predictable way. This gives us a sense of security. This attitude is an important basis for the Taylor tub in Sect. 1.1.1. Frederick Taylor developed his theory around 1910, when transport costs were falling and an increasing amount of different machines were being invented. This was something that opened up the global market to companies for the first time. Innovation was not crucial back then because there was little competition. And where there was a competitor, he could move to another market. White Collar vs Blue Collar workers

The mantra of Taylorism was that humans had to function like machines (Oestereich & Schröder, 2017, p. 7). Discipline became a primary virtue. The existing rules and processes had to be followed. Every step in the process was precisely prescribed. Thinking along and creativity on the part of the workers were not desired. A clear distinction was made between thinking and acting. The superiors (white collar) defined the methods and made the decisions, the workers (blue collar) were responsible for their implementation. Today, there exists high pressure to innovate in global markets. As a result, the complexity in project work has increased manyfold. The separation between thinking and acting is no longer practicable or at least very ineffective: if decisions cannot be made by the people who have the specific expertise, the proximity to the problem or to the corresponding market, this entails communication and decision-making processes of very little added value in hierarchical organisations. Agile project management brings thought and action together again by giving the product owner far-reaching decision-making powers and granting the scrum team the autonomy to make their own decisions during the sprints. However, the change to a network economy cannot be achieved by adapting these methods alone: it requires the appropriate attitude, an adequate view of people and the world.

1.6.2

Mechanistic and Systemic World View

The dose makes the poison (Paracelsus).

Taylor based his teaching on a mechanistic world view. This is characterised by the conviction that people and organisations can be explained by means of logic and linear causal chains. Hard facts and the conviction that there is a common objectivity and thus also some kind of truth dominate here. The aspects of systemic project management described in Sect. 1.6.4 are based on the systemic world view. Table 1.5 compares the main differences between these two world views.

1.6 Projects are Social Systems

33

Table 1.5 Based on Königswieser and Hillebrand (2004, p. 28) Mechanistic world view Objectivity, one truth, immutable laws Right–wrong, guilty–innocent External control Linear causal chains Formal logic, freedom from contradiction Hard facts, rational relationships

Systemic world view Reality construction, many truths, hypotheses Contextuality, usefulness, connectivity Self-direction, self-organisation Multiple interactions Integration of contradictions Integration of hard and soft factors (emotions, intuition)

Every organisation that handles projects is a living and thus a non-trivial system. This makes the systemic approach an integral part of every project organisation, regardless of whether it works according to the agile or the traditional approach. The point here is neither to denigrate the mechanistic world view nor to dump the Taylor tub. For certain projects, the traditional approach is better suited, for others the agile approach. Of course, project work is also about hard facts. The budget has to be discussed and the controlling has to be handled. Complexities have to be abstracted and linear causal chains to be formed. But when people work together it is always about the aspects of the systemic world view. As Paracelsus’ proverb reveals, it is the dose that distinguishes poison from medicine: Anyone who is only at home in mechanistic thinking will one day have the experience of being confronted with phenomena such as resistance and conflict. He might also then not be able to find creative solutions. Those who are only oriented towards systemic thinking are in great danger of not understanding the principles of cause and effect or of then developing creative solutions that no client wants to pay for. It is not about the “either-or”. Dealing with polarities and thus integrating the opposites with an “as-well-as” approach should mediate moderately between the opposing positions: Depending on the question or situation, we should be able to assess which attitude or which mode of thinking is goal-oriented. In any case, experience shows that the systemic approach offers an extremely effective design option for both traditional and agile project management. It is important to know that the systemic approach does not replace the psychological or group dynamic principles. Both complement each other. In traditional project management, the focus is on external control. The project owner and the project manager take in the two central roles having the essential decision-making competencies. Of course, the expectations and responsibilities of the other stakeholders must also be clarified, which can be illustrated, e.g. with a RACI matrix (Sect. 2.3.8.9). The objectives are also specified as well as that is possible at the beginning of the project. The project manager is often challenged by the fact that he is responsible for both the work on the system and the work in the system. In small- and medium-sized projects, the project manager is often also an essential technical resource. The high time pressure then tempts him to focus his restricted resources on the productive

34

1 Introduction

work in the system. The work on the system then takes a back seat. Thus, a project kick-off is carried out in only 1 h. That is barely enough to get an understanding of the task. But it is far from creating a social team structure and an organisational framework in which the members can see themselves as part of a larger whole. This also means that the basis for clarification and discussion is lacking in an early phase of cooperation, which then manifests itself in specific symptoms such as conflicts and resistance during project implementation. In agile project management, the focus is on self-organisation. This is in the foreground. The team members have to divide the management work among themselves and can thus merge thinking and action. Networking with internal and external stakeholders is also not regulated via the hierarchy, which, too, is challenging. The project manager does not exist in this approach. With the scrum master, a role is explicitly created in this approach that should not or cannot do any productive work in terms of content, but concentrates entirely on the work on the system. The scrum master’s sole purpose is to ensure optimal cooperation between the two “productive” roles, namely those of product owner and developer. In addition, it is his task to remove obstacles that the scrum team is confronted with and to ensure that the respective requirements and challenges are dealt with using the optimal methodological approaches.

1.6.3

People and Teams Are Non-Trivial Systems

Anyone who has children experiences again and again: what you tell them (input) and what they finally do (output) as a response to that can be miles apart. In professional cooperation, too, we experience time and again that an apparently clear instruction to a colleague results in a completely unexpected response. Heinz von Foerster explains this phenomenon through the concept of trivial and non-trivial systems. Trivial Systems: External Control A trivial system is based on the logic that a clearly specified input triggers a specific function, which then leads to a clearly defined output. In Taylorism, the human being had to function like a machine; the image of the human being was thus shaped by the logic of the trivial machine. This definition is valid in inanimate nature (minerals, inorganic substances) as well as in mechanical, electronic, and IT systems, or at least it should be. Cars, ships, or planes are built to be controlled by actions from the cockpit. Our computers with all the programmes and applications are designed to generate specific outputs and performances based on specific inputs from the users via the programmes. Non-Trivial Systems: Self-Control Everything that lives is non-trivial, be it organisms such as plants or animals, individual people, project teams, and other organisations. Living systems are self-

1.6 Projects are Social Systems

35

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

1.6.4

Systemic Approach to Project Management

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

36

1 Introduction

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

1.7 Versatility and Creativity

1.7

37

Versatility and Creativity

The reason for the existence of every project is to create something new. Be it a new customer request or an internal problem: the existing products and solution strategies do not (or no longer) meet the new requirements. The requirement for creativity is rather low in a standard project (Sect. 1.2.1) but in a potential or pioneer project it is very high. This will be discussed in the second part of this section. Always essential for project managers is their versatility.

1.7.1

Versatility

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

1.7.2

Creativity as a Surplus of Attention

The crown of versatility is creativity. This is about creating innovation, developing ideas and approaches to solutions that are new in nature. Specific creativity techniques are described in Sect. 2.8. Basic thoughts on this topic are presented here in connection with people and the organisation. The psychologist Mihaly Csikszentmihalyi has studied creativity scientifically. He considers creativity to be the central source of human meaning. This is because all human cultural achievements, be it language, technology, science, art, or the economy, are the results of human creativity (Csikszentmihalyi, 2015, p. 9). If you want to be innovative, if you really want to create something new in a sustainable way, you need a lot of energy. The tried and tested must be let go of and the boundaries of knowledge must be transcended. Creativity always requires learning anew. This is not an exclusively pleasurable process; it often also involves effort, stress, and setbacks. Humans are limited beings. We can only absorb and process a limited amount of information at any given time. If we want to learn something, we have to give it our attention. The problem is that our attention is also limited. First and foremost, humans need their attention to ensure their survival. As long as our basic need for

38

1 Introduction

bodily integrity is not satisfied, we cannot take care of anything else. In addition, there are many other expectations from family, friends, and society that require our attention. In everyday working life, it’s the same song: many things demand attention. The more we are held captive by operational necessities from the lines or project work, the less attention is left for the sustainable creation of something new. For Csikszentmihalyi, creativity is only ever possible when there is a surplus of attention (Csikszentmihalyi, 2015, p. 20). As long as people are completely absorbed with themselves and others, they cannot muster the energy for innovation. A look back at history also proves this: Significant bursts of human creativity took place, for example, in Athens in 500 BC, in Florence in the fifteenth century, or in Paris in the nineteenth century. These were always places and times of relatively high material prosperity. This allowed people to direct their attention beyond the necessities of survival to other aspects of life. This enabled enormous developmental steps in philosophy, art, architecture, and science.

1.7.3

Interplay Between Human, Field and Domain

Creativity is any action, idea, or thing that changes an existing domain or transforms an existing domain into a new one (Csikszentmihalyi, 2015, p. 48).

A further differentiation seems appropriate in the source of creativity. In many cases, the individual with his or her good ideas is described as the most important factor for creativity. Of course, these are important. However, for an idea to become visible, another aspect is essential: it has to be understandable for other people and recognised by experts in the specific field. Otherwise, no sustainable innovation can take place. Thus, creativity is always the result of interactions between people or groups who have a new idea, experts (in the field) who can evaluate this idea, and a field (domain) which is changed by this idea (Csikszentmihalyi, 2015, p. 47 ff.): Human Whatever has value also has a price.

Man’s inventiveness is the source of our cultural goods and technology. Currently, humans are in the process of losing their pioneering role in creativity to artificial intelligence. Enormous resources are flowing into the further development of artificial intelligence. Machines and robots are becoming adaptive and autonomous, beating humans at chess and other things. For Dennis Lück (Lück, NZZaS, 11.3. 2018), it is an extraordinary contradiction that, on the one hand, everything is being done to promote artificial intelligence, while on the other hand, the foundations of human creativity are not being sufficiently promoted.

1.7 Versatility and Creativity

39

In addition to heredity, the environment has a significant influence on human creativity. This brings the school system into focus. Often, the focus in schools is still on acquiring knowledge. What is needed to be creative, however, are competences or skills in that domain: it is about developing new approaches to solutions in complex situations (Sect. 2.3.14), questioning existing rules and methods, learning from mistakes and failure (Sect. 2.3.5), and to change perspectives (Sect. 3.9.8.3). Lück recommends more project work for schools, through which students can work together on topics that really interest them. In this way, they may develop their competences more than just accumulating knowledge with an expiry date. Thanks to the fact that people are capable of learning throughout their lives, these recommendations also apply to all organisations that carry out projects. Creativity does not come for free: Those who value it must be prepared to pay a price for it. Example

With regard to scrum, it was Jeff Sutherland and Ken Schwaber who asked themselves in the mid-1990s how software development could be made more effective. Schwaber and Sutherland developed new ideas for handling projects because they felt that the current project management approaches did not lead to the desired results. ◄ In order to be creative, a person has to be able to think outside of commonly accepted norms and habits. In doing so, he challenges the existing system and confronts it with its weaknesses. Measures to promote creativity are listed in Sect. 2.8. Field The field consists of experts and opinion leaders who can assess the content of a new idea and on whom it also depends whether an idea should or can be developed further. The field includes all persons and organisations who monitor access to a subject area (domain). They decide which idea or which new product should be included in a domain. In project management, the field essentially consists of the standards and certification models (Sect. 1.8). What is included here becomes part of the domain. The field of the domain project management also includes the professional bodies and communities, publishers, established authors, or consulting and educational institutions. If Schwaber’s and Sutherland’s ideas had not been taken up by representatives of the field, it is unlikely that it would ever have become an established procedure as it is now used in many areas. In a company, the field is often formed by the members of the management, the head of the PMO, or the project owners in the projects. They are confronted with the ideas and creative suggestions of their employees. What they approve of can bring about sustainable change. What they reject or prevent, however, is lost in most cases.

40

1 Introduction

Domain In the example of Sutherland and Schwaber, their ideas of agile project management were adopted into the “cultural asset” of project management. This is what Csikszentmihalyi calls a domain. Here, knowledge is collected and managed that is recognised and valid for a specific field. Each company also has one or more domains in the area of its specific business activity which allow them to develop value creation. This domain can be in specific technologies or services and is always linked to a specific process competence in how the services are provided to the customers. Every project organisation has also gained experience of some kind in what is the best way to handle projects in their specific fields of business. Such experiences are often described in a project management manual. This then serves as a binding guideline for all project managers on the procedure and methodology of the project. If those responsible in a company now decide not only to handle their projects according to the traditional approach, but also to apply agile or hybrid project management, depending on the type of project, they would thereby expand the company’s internal domain of project management.

1.7.4

Framework Conditions for Creativity

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

1.8 Standards and Certification Models in Project Management

1.8

41

Standards and Certification Models in Project Management

There are different standards and certification models for project management on the market. The different standards focus on different topics such as competences or project management processes. At the international level, there are three well-known certification models: IPMA, PMI, and PRINCE2. In Switzerland, Hermes is widely used as a process model in public administration. In addition, there are also standards that describe and structure project management. Each different certification model specifies its own standard. The advantage of using a standard is thereby having a common language and a common process framework in a company or whenever there is cross-company collaboration. However, if a model is chosen that does not fit the company, the problems in project management will multiply. The certifications offered by IPMA, PMI, Prince2, and Hermes are summarised in Table 1.6. The scrum alliance offers various certificates in the field of scrum.

1.8.1

IPMA: International Project Management Association

IPMA is spread worldwide and has European origins. For individuals, IPMA offers a certification system with four levels. The basis for certification is the Individual Competence Baseline (ICB).

Table 1.6 Overview of certification models Project staff

Project manager

Project Director, Programme Manager and Portfolio Manager

IPMA Certified Project Management Associate/ Certified Agile Associate (Level D) Certified Project manager/ Certified Agile Leader (Level C) Certified Project Senior Manager/Certified Agile Senior Leader (Level B) Certified Project Director/ Certified Agile Organisational Leader (Level A)

PMI CAPM

Prince2 PRINCE2 Foundation

PMP, PMI-ACP

PRINCE2 Practitioner PRINCE2 Agile Practitioner

PgMP, PfMP

Hermes 5 Hermes 2021 Foundation Level Hermes 2021 Advanced Level

42

1 Introduction

In addition to the certification of individuals, IPMA also offers the possibility of certifying teams in accordance with the Project Excellence Baseline and organisations with the Organisational Competence Baseline. The certification of persons on the basis of the ICB is the most successful certification model of IPMA. The certifications are issued by the respective national organisations (Germany: Deutsche Gesellschaft für Projektmanagement GPM, Switzerland: Association for the Certification of Persons in Management VZPM, and Austria: Projekt Management Austria PMA) are offered and carried out. IPMA certification is about proving existing and applied competences. In this way, IPMA differs significantly from the other certification models, which are very process-oriented and designed for the application of a defined framework. IPMA understands individual competence as the application of knowledge, skills, and abilities to achieve the desired results. Skills build on abilities, which in turn require knowledge: • Knowledge is the totality of information and experience that a person possesses Example: Being able to explain the concept of a Gantt chart • Skills are specific technical abilities that enable a person to perform a task Example: Creating a Gantt chart • Skills describe the effective use of knowledge and skills in a specific context Example: Creating a project schedule with a Gantt chart and using it to successfully manage the project The heart of the ICB is the “Eye of Competence”. The competences are described in Sect. 1.3.2. Table 1.7 shows the IPMA certification system for persons.

Table 1.7 IPMA certification areas and certification levels Level A

B

C D

Domain Project Certified Project Director Certified Agile Organisational Leader Certified Project Senior Manager Certified Agile Senior Leader Certified Project manager Certified Agile Leader Certified Project Management Associate Certified Agile Associate

Programmes Certified Programme Director

Portfolio Certified Portfolio Director

Certified Senior Programme Manager

Certified Senior Portfolio Manager

1.8 Standards and Certification Models in Project Management

43

In Switzerland, certification at level D is purely a knowledge examination with an “open book”. For certification at levels B and C, proof of project experience and a completed project is required in addition to the knowledge examination. The candidate has to prove in a written report and an interview how he has applied the individual competences in his reference project. At level A, the knowledge test is omitted.

1.8.2

PMI: Project Management Institute

PMI is a globally established provider of a certification system. In the USA, PMI is the de facto standard for project management. The certifications are carried out directly by PMI. There are country-specific chapters that serve the networking and dissemination of PMI methods. The certifications are based on the PMBOK® Guide (Project Management Body of Knowledge), which since the seventh edition also supports agile project management in addition to traditional project management (Project Management Institute, 2021). In addition to organisational influences on project management, the PMBOK® Guide describes a project process as having four phases. The PMBOK® Guide structures the project process into eight performance domains and 12 principles. These performance domains are: • • • • • • • •

Team Stakeholders Life cycle Planning Navigating uncertainty and ambiguity Delivery Performance Project work The PMI offers the following eight certification options, these are, among others:

• • • • • • • •

CAPM, Certified Associate in Project Management PMP, Project Management Professional PgMP, Programme Management Professional PfMP, Portfolio Management Professional PMI-PBA, PMI Professional in Business Analysis PMI-ACP, PMI Agile Certified Practitioner PMI-RMP, PMI Risk Management Professional PMI-SP, PMI Scheduling Professional

44

1 Introduction

The certification is done via a multiple-choice exam (closed book) and is based on the PMBOK® Guide.

1.8.3

PRINCE2

PRINCE2 is the de facto standard for project management in the UK. Prince2 stands for “Projects in Controlled Environment”. PRINCE2 was originally developed by the British government. Today, PRINCE2 is offered by the company AXELOS Ltd. PRINCE2 is a very detailed and integrated process model that defines exactly what needs to be done in the project from start to finish. PRINCE2 focuses on the framework provided. It is less about a set of methods or competences. Figure 1.18 shows the Prince2 project management system, consisting of basic principles, themes, and processes.

Project environment Business case Progress

Organisation PRINCE 2 processes

Change

Quality Risk

Plans

PRINCE 2 themes PRINCE 2 principles

Fig. 1.18 Overview of Prince2 Model

1.8 Standards and Certification Models in Project Management

45

The seven basic principles of PRINCE2 are: • • • • • • •

On-going business justification Learn from experience Defined roles and responsibilities Control over management phases Taxes according to the exception principle Product orientation Adapt to the project environment The seven themes of PRINCE2 are:

• • • • • • •

Business case (What for?) Organisation (Who?) Quality (What?) Plans (How? How much? When?) Risks (What if?) Changes (What are the effects?) Progress (Where are we? Where do we go from here? Shall we continue?) The seven processes of PRINCE2 are:

• • • • • • •

Prepare project Steer project Initiate project Control a phase Manage product delivery Manage phase transition Complete project The following certifications are offered for PRINCE2:

• PRINCE2 2017 Foundation • PRINCE2 2017 Practitioner • PRINCE2 2017 Agile Practitioner Certification is by means of a multiple-choice examination (open book) and is based on the current PRINCE2 manual.

1.8.4

Hermes

Hermes is the project management method for public administrations in Switzerland. Hermes 2021 supports the control, management, and execution of projects having different characteristics and degrees of complexity. The so-called scenarios are

46

1 Introduction

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

1.8.5

Scrum Alliance

The goal of the scrum alliance is to further establish scrum. To this end, the scrum alliance offers certifications for scrum: • Certified scrum master • Certified scrum product owner • Certified scrum developer Building on this, the certification as a certified scrum professional can then be completed.

1.8.6

DIN 69901 and ISO 21500

In Germany, there is DIN 69901 a series of standards for the standardisation of project management: • • • • •

DIN 69901-1 Basics DIN 69901-2 Processes, process model DIN 69901-3 Methods DIN 69901-4 Data, data model DIN 69901-5 Terms

At the international level, there is the standard ISO 21500 “Guide to Project Management”, which describes terms, basics, processes, and process models in project management. Both standards represent the traditional view of project management and do not give clear recommendations regarding the process model. Agile

1.9 Project Portfolio, Multi-Project and Programme Management

47

project management had not yet been incorporated into the standards by the time this book went to press.

1.9

Project Portfolio, Multi-Project and Programme Management

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

Table 1.8 Project portfolio, multi-project, and programme management Project portfolio management = multi-project management

Programme management

Project management

• Strategically oriented and interdependent management of all projects of a company or division • A project portfolio consists of individual projects and/or programmes • A project portfolio has no time limit • Configure, prioritise, and control project portfolios to do the right things • Serves to implement selected strategic initiatives and objectives • Composed of the implementation of various projects • Lasts until the strategic initiatives are implemented and the strategic objectives are achieved. A programme is thus limited in time • After the end of the programme, the temporary structure of the programme management will also be dismantled • Project management is used to design, steer, and control individual projects: doing things right

48

1 Introduction

References Beck, K., Schwaber, K., Sutherland, J., et al. (2001). Manifesto for agile software development. http://agilemanifesto.org Csikszentmihalyi, M. (1997). Flow und Kreativität (2. Auflage, 2015). Klett-Cotta. Dierig, S. (2015). Projektkompetenz im Unternehmen entwickeln. Wissenschaftlicher Verlag Berlin. Königswieser, R., & Hillebrand, M. (2004). Einführung in die systemische Organisationsberatung. Carl-Auer-Systeme Verlag. Kotter, J. P. (2012). Leading Change: Wie Sie Ihr Unternehmen in acht Schritten erfolgreich verändern. Vahlen Verlag. Lück, NZZaS, 11.3.2018. Oestereich, B., & Schröder, C. (2017). Das kollegial geführte Unternehmen: Ideen und Praktiken für die agile Organisation von morgen. Verlag Franz Vahlen GmbH. Pflaeging, N., & Hermann, S. (2015). Komplexithoden. Clevere Wege zur (Wieder)Belebung von Unternehmen und Arbeit in Komplexität. Redline. Project Management Institute. (2021). PMBOK® Guide in der 7. Edition. Seliger, R. (2008). Das Dschungelbuch der Führung (5. Auflage, 2014 Ausg.). Carl-Auer Verlag GmbH. Wohland, G., Huther-Fries, J., Wiemeyer, M., & Wilmes, J. (Eds.). (2004). Vom Wissen zum Können. Merkmale dynamikrobuster Höchstleistung. Eine empirische Untersuchung auf systemtheoretischer Basis. Detecon & Diebold Consultants.

Further Readings Doppler, K., & Lauterburg, C. (1994). Change Management, den Unternehmenswandel gestalten (13. Auflage 2014). Campus. Königswieser, R., Sonuc, E., & Gebhardt, J. (2008). Komplementärberatung. Das Zusammenspiel von Fach- und Prozeß-Know-how. Klett-Cotta. Petersen, D., Witschi, U., Kötter, W., & Bahlow, J. (2011). Den Wandel verändern. ChangeManagement anders gesehen. Gabler Verlag | Springer Fachmedien.

2

Methodology

2.1

Introduction

2.1.1

Traditional, Agile and Hybrid

Chapter 1 gives a brief introduction to the traditional, agile, and hybrid approach to project management. In the traditional approach, a project is divided into phases; the result is available at the end of the project. In the agile approach, partial results are produced continuously. On closer inspection, an agile approach such as scrum also goes through a shortened concept phase, a realisation phase, and an introductory phase. In the agile approach, the tasks of initialisation are carried out before or often together with a refinement of the product vision, the product backlog, and the release plan in the concept phase. The most important phase in the agile method is the realisation phase. After a defined number of sprints, a release goes live. This go-live phase is comparable to the introduction phase in the traditional approach. In this handbook on project management, the traditional and agile approaches are not treated separately. In terms of hybrid project management, the elements of the traditional and agile approach are explained and expanded on the basis of the phases of traditional project management (project commissioning, initialisation, concept, realisation, and introduction). Hybrid project management leaves open the issue how the parts of the traditional and agile approach are to be combined with each other. It must be decided on a situational basis which of the combination options should be used in hybrid project management: • Traditional and agile phases • Traditionally and agilely handled sub-project • Situational combination of elements from the traditional and agile approach methods (e.g. daily stand-up meeting and retrospective in the traditional approach) Focus of the Traditional and Agile Approach in the Specific Phases The compass in Figs. 2.1 and 2.2 provides an overview of the focus, activities (risk management, planning, controlling, information, and communication) and of the # Springer-Verlag GmbH Germany, part of Springer Nature 2023 J. Kuster et al., Project Management Handbook, Management for Professionals, https://doi.org/10.1007/978-3-662-66211-3_2

49

50

2 Methodology Project Management Compass Agile

Preparation phase

0 Commissioning

Project phases

0

1 Initialisation

1

Usage phase

Agile project (based on Scrum) Focus

Idea

Constitute project team

Risk management

First risk assessment

List risks

Planning

Business case, profitability Assess financial viability

Feasibility study

Controlling

Information & communication Results

Set up project handbook

Project factsheet (1-Pager) Business case Project request

2 Concept

2

3 Realisation

Project order Stakeholder analysis Risk list

3

4 Introduction

Product target / Product concept

Implementation (sprints)

Acceptance

Assess risks Agree on measures

Ongoing monitoring

Ongoing monitoring

Release planning

Update product backlog and release plan Sprint planning Daily standup meeting

Update product backlog and release plan Sprint planning Daily standup meeting

Sprint review Burndown charts (release, sprint)

Sprint review Burndown charts (release, sprint)

Daily standup meeting

Daily standup meeting Retrospective

Daily standup meeting Retrospective

Product target / product concept Product backlog

Sprint backlog Increment Updated produt backlog Updated release plan Implementation or operating concept

Acceptance protocol Project closure

Release plan Test concept

Fig. 2.1 Project management compass for the agile approach

4

Usage

2.1 Introduction

51

Project Management Compass traditional

Preparation phase

0 Commissioning

Project phases

0

1 Initialisation

1

Usage phase

Traditional project

Focus

Idea

Project targets / specification (WHAT) Check and confirm feasibility Project structuring, rough planning Constitute project team

Risk management

First risk assessment

Identify risks

Planning

Business ase, Profitability Assess financial viability

Feasibility study Project structuring Phase and milestone plan Project structure plan

Controlling

Project status meeting Constitute project steering

Information & Communication

Set up project handbook Conduct kick-off Project factsheet (1-Pager) Business Case Project request

Results

2 Concept

2

3 Realisation

Project order Specification (HOW) Stakeholder analysis Risk list Project plan (milestone and project structureplan) Deliverables

3

4 Introduction

Solution concept (HOW) Detailed planning

Implementation (development, construction, etc.) Test

Serial production (product) Launch (system, plant) Go-live (software)

Assess risks Agree on measures

Ongoing monitoring

Ongoing monitoring

Detailed planning Time and cost planning Resource planning

Ongoing monitoring Change request management

Ongoing monitoring Change request management

Progress control Corrective measures Steering group

Progress control Corrective measures Steering group

Progress control Corrective measures Steering group

Project status meeting Reporting

Project status meeting Reporting

Project status meeting Reporting

Technical specification Time and cost planning Resource planning Risk management tool Introduction concept Quality management plan Test concept, operating concept

Test reports Construction release Content results

Series release (product) Acceptance protocol (system,plant) Project closure Lessons learned

Fig. 2.2 Project management compass for the traditional approach

4

Usage

52

2 Methodology

Discovery

Realisation

Introduction

Daily Scrum Retro

Product Target

• • •

Sprint Planning

Sprint Review

Increment DoD

1. 2. 3.

Product Backlog

Sprint Backlog Sprint Target

Release Plan

Refinement

Release

Fig. 2.3 Agile project planning

results in the individual phases for the agile and traditional approaches. The overview clearly shows that the discussion of WHAT and HOW takes place at a later stage in the agile approach than it does in the traditional approach. Different Approach in the Planning of the Project The agile and the traditional approach follow different concepts in the planning of the project. In the agile approach, only rough planning takes place in the concept phase. Since we work with a fixed team, resource and cost planning is simplified. Detailed planning is only carried out immediately before the implementation of a sprint. Planning in scrum is conducted on three levels as is shown in an overview in Fig. 2.3: • In release planning during the concept phase, the following points are determined: Planning the number of sprints, determining the provisional order of implementation of the requirements from the product backlog, and determining the go-live dates of releases. The release plan is dynamic and is constantly adapted to the latest circumstances. • During sprint planning in the realisation phase, the activities of a sprint are planned. The result is recorded in the sprint backlog. • The planning of the work day takes place in the daily scrum.

2.1 Introduction

53

Fig. 2.4 Traditional project planning, consisting of project structuring and detailed planning

In the traditional approach, planning takes place over several stages. After the objectives and requirements (specifications) have been defined in the initialisation phase, the project is structured (rough planning) according to Fig. 2.4. The project structuring contains the following elements: • Project phases and milestones • Work breakdown structure with sub-projects, deliverables, and work packages with a rough cost estimate In the concept phase, solution variants are developed for the requirements. For the selected solution variant, a detailed elaboration of the solution concept takes place. The detailed planning of the project is based on the solution concept. The detailed planning contains the following elements: • Schedule • Resource plan • Cost plan

2.1.2

Accuracy of Estimates

An estimate is a provisional or preliminary calculation. However, the project owner or the management of the company expects a cost estimate that is as reliable and dependable as possible. In the agile approach, this context is taken into account by defining the duration (timeboxing) and the costs of the project in advance. The uncertainty then lies in the effective scope of services that will be realised.

54

2 Methodology

In the traditional approach, the scope of work is fixed. For simple projects and standard projects, the estimation of the duration and costs is relatively reliable. For large projects, pioneer or potential projects, estimating the duration and the costs is subject to many uncertainty factors and is accordingly inaccurate at the beginning. The inaccuracies decrease as the project progresses, see Sect. 2.4.7.3. Depending on the type of project, the following tolerances must be expected in the phases: • After project order: +100%/–50% or more • After project structuring: +40%/–20% • According to detailed planning: ±10%

2.1.3

Practical Examples

The theory discussed is supported by the following two real-life examples of hybrid project management. BLS AG BLS is one of the largest transport companies in Switzerland. In its core rail business, BLS operates the Bern S-Bahn and thus the second largest S-Bahn network in Switzerland. BLS also operates the western lines of the Central Switzerland S-Bahn and is besides that anchored in tourist transport. Its services include railway lines through the Emmental, lines in the Jura, the Seeland, the Simmental, to Interlaken, and the Lötschberg mountain line. Furthermore, BLS operates InterRegio and RegioExpress lines. BLS is active in the areas of bus, ship, car transport, and freight transport, too: • In Emmental and Oberaargau, BLS operates a bus network of 18 lines with its subsidiary Busland AG. • BLS shipping on Lake Thun and Lake Brienz is a flagship for the Bernese Oberland as a tourist destination. • The BLS car transport on the Lötschberg from Kandersteg to Goppenstein offers a fast connection from Bern to the Valais all year round. With the car transport from Brig to Iselle, BLS also offers a connection to Italy. • The subsidiary BLS Cargo AG occupies a central position in rail freight transport through the Alps. Project Sales Back-End VBE Two developments in public transport formed the basis of this project. Firstly, the public transport platform and the associated standard interface NOVA were developed in the industry project ZPS (future pricing system public transport Switzerland). Each transport company can connect its own distribution systems to this interface. In order to effectively sell tickets from the public transport platform, a dedicated distribution back-end and front-end are needed. Secondly, due to market trends and the on-going digitalisation of society, the importance of digital sales is

2.1 Introduction

55

increasing strongly. In order to meet this trend as well as the underlying needs, and to strengthen its customer orientation, BLS has to be able to serve its customers via the internet as well as via a mobile channel. The VBE project brought these two developments together, aiming to realise a separate, independent, and multi-client capable sales back-end—including a mobile solution and an online sales channel based on the future industry standard public transport platform/NOVA.

Metrohm AG Metrohm AG is one of the world’s largest manufacturers of high-precision instruments for chemical analysis. It was founded in 1943 by engineer Bertold Suhner in Herisau, Switzerland. Metrohm has made it from a start-up to a global player and is now present in more than 80 countries with its own subsidiaries and exclusive sales partners and a good 2200 employees. As the worldwide market leader for analytical instruments in the titration sector, Metrohm develops solutions for all ion analysis tasks. OMNIS Titration System Project The OMNIS project developed a fully integrated titration system that meets the needs of today’s laboratory and delivers faster results with more safety, convenience, and efficiency. The fully integrated system included the titrator, liquid handling modules, new software, and a new sample robot. OMNIS offers performance at a whole new level, having all the answers to the growing demands of everyday laboratory operations: • Quadrupling of sample throughput: With a single system, four analyses can be carried out simultaneously and fully automatically.

56

2 Methodology

• Touch-free chemical handling: Thanks to the patented 3S adapter technology, no bottle needs to be opened when changing reagents. • An analysis platform that everyone can master: thanks to intuitive system management, OMNIS can be operated by almost all users. The OMNIS titration platform project was launched 6 years before the planned market release.

2.2

Project Commissioning Phase

Changed market conditions, customer demands, and the pressure to realise efficiency gains force companies to implement projects on an on-going basis. Usually there are more requests for new projects than a company can afford. The project idea has to first make it into the portfolio of projects in the project commissioning phase (Sect. 2.7). The project owner and other staff (e.g. the portfolio manager, product manager, or project manager) then clarify whether a new project is worthy. For this purpose, a project factsheet and a business case (Sect. 2.2.3) are developed and included in the project portfolio discussion. The project factsheet clarifies the most important key data of the project idea: namely, the objectives, added value to be created, an approximate idea of how much time it will take, what the budget is, and its relation to the strategy. The business case clarifies the strategic relevance, the benefits, and the economic viability. In this phase, the project is not yet planned in concrete terms, but a sufficient amount of key data is gathered so that the management can decide which projects should be implemented and which should not. Ideally, the project manager, the product owner, or scrum master are also appointed in this phase, at the end of which the project proposal is drawn up to plan the initialisation phase. Figure 2.5 shows a possible sequence of project factsheet, project proposal, and

2.2 Project Commissioning Phase

Project factsheet

Project request

Project order

Vision

Global target

Detailed targets

57

Requirements Requirement specification

Commissioning

Initialisation

Technical specification

Conzept

Realisation

Introduction

Fig. 2.5 Step-by-step operationalisation of the project objectives

project order as well as the objectives hierarchy and the assignment of requirements and specifications to the corresponding phases (see also Table 2.37). In this phase, there are no specific distinctions between projects that are handled agilely or traditionally. For small projects and order processing projects, this phase can be shortened or skipped.

2.2.1

What Is Important in the Commissioning Phase?

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

58

2 Methodology

Table 2.1 Steps of the project commissioning phase Work step Check project worthiness

Record the project factsheet and business case in writing Planning: first rough estimate

Preparation of project proposal and planning of the next phase (initialisation)

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

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

2.2 Project Commissioning Phase

59

Table 2.2 Results of the project commissioning phase Questions to be answered

Process-oriented results Content-oriented results

• Is the project feasible with the available resources in addition to the decided project portfolio? • Is it worthwhile to carry out this project, considering the effort and expected benefits? • Project factsheet • Project request for the initialisation phase • Business case: Consideration of whether the project is economic and makes sense from the point of view of the market, corporate strategy, etc. • Depending on the type of project and situation: initial feasibility assessments, rough coordination of resources, basic financial feasibility

factors of the project idea and to formulate the business case and project request. The following actions and competences are important. • Lateral leadership (Sect. 4.4.3): Usually a formal organisation is not formed in this phase, but a coordinator is appointed who leads his team laterally. • Work in the system (Sects. 1.5.1 and 5.2.4): The content-related work is in the foreground. • Versatility and creativity (Sect. 1.7): From the beginning, different variants and scenarios should be illuminated. • Informal network (Sect. 4.9.3): The project manager has no official mandate at this stage. How effectively he can fulfil his mandate in this situation depends strongly on his informal network.

2.2.2

Project Factsheet

In the project factsheet (1-pager), the idea for a project is recorded in a structured manner and made more concrete. The project factsheet should be brief and contain statements on the following contents: • • • • • • • • • • •

Project name Strategic reference Short description Brief history (how did the project come about, what previous work has been done?) Expected added value, benefits, revenue (from the business case) Expected costs (from the business case), rough resource requirements Choice of process model (agile, traditional, hybrid) Estimated start and end date Designation of central project roles (project owner, project manager or product owner, scrum master) Known dependencies First risk assessment

60

2 Methodology

The project factsheet, together with the business case, serves as the basis for deciding whether the formulated idea should be pursued further and a concrete project should be launched. Every company is organised and positioned differently. Typically, such decisions are made during strategic planning, project portfolio planning, multi-year or budget planning. The body in which such decisions are made also varies: executive board, portfolio board. In the case of order processing projects, the project factsheet can also correspond to the customer’s quotation or order, possibly supplemented with internal company requirements.

2.2.3

Business Case

Organisations live through the creation of benefits. That is why the question of the benefit of a project idea arises at a very early stage. An organisation can survive in our economic system if it has enough money at its disposal. Every planned project must be examined to see if it improves the chances of the organisation’s survival. Whether a project should be undertaken must be assessed by the project owner or the relevant body before the contract is awarded. Not only quantifiable monetary values, but also strategic considerations, philosophies, resources, etc. play a role. In the run-up to a project many organisations require, together with the project factsheet, a business case with the following content: • • • • • • • • • •

Problem and justification of the project SWOT analysis Customer needs and market potential Framework conditions Competitive position Strategic relevance, contribution to the achievement of strategic objectives (strategy alignment) Marketing mix Economic efficiency (expected added value, benefits, revenues, investment and operating costs, result, return on investment) Non-monetary benefit for the company Effects of non-implementation

2.2.4

Project Request

If a company decides to carry out the project on the basis of a project factsheet and a business case, the next step is to then prepare the project request for the initialisation phase. The project proposal corresponds in essential parts to the project order. However, the project request only considers just the initialisation phase and not the whole project and regulates the following points:

2.3 Initialisation Phase

• • • • • • • • • • •

61

Objectives for the initialisation phase Basics (on what preliminary work or basics is the project based?) Delimitations (project boundaries, project scope) Dependencies Framework conditions Results and deliverables of the initialisation phase Project costs and personnel resources for the initialisation phase Risks Project plan for the initialisation phase (procedure and schedule) Project organisation for the initialisation phase Signatures of project owner and project manager, product owner

Some companies do not just focus on the initialisation phase and the content of the project proposal alone. As a preliminary stage for the project order, they already roughly plan the whole project. They also estimate the total costs and the follow-up costs such as those of operating.

2.2.5

Checklist Completion Project Commissioning

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

2.3

Initialisation Phase

In the initialisation phase, binding statements on feasibility, risks, and stakeholders are to be drawn up in the traditional approach. Essential bases for this are the analysis of the current situation as well as clearly agreed objectives and the formulation of requirements. It is a declared concern to reduce the uncertainties and risks that exist at the beginning of a project as quickly and as far as possible. If the objectives and

62

2 Methodology

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

2.3.1

What is Important in the Initialisation Phase?

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

2.3 Initialisation Phase

63

Risk large Project costs

Relative importance of the decisions

Knowledge

medium

Risk

typical management attention

small

Initialisation

Concept

Realisation

Introduction

Time

Fig. 2.6 Possibilities of influence in the project

Table 2.3 Steps of the initialisation phase Most important steps

Agile approach Clarify initial situation and problem Survey and analyse the current situation Clarify and define objectives Analyse stakeholders Draw up a rough project order: • Objective • Plan of procedure: Methods, very rough schedule • Human resources and project organisation • Rough estimate of the project costs Identify risks Write project manual Set the rules of the game Carry out project kick-off

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

64

2 Methodology

Table 2.4 Results of the initialisation phase Phases and activities Principle

Questions to be answered

Processoriented results

Contentoriented results

Agile approach In the agile approach, this phase will be very short. Only the rough key data from the commissioning phase are checked and, if necessary, concretised. The planning of the project takes place with the creation of the release plan in the Concept phase and in the respective planning of the individual iterations of the Realisation phase • Who are the relevant stakeholders? • Who is the product owner, scrum master, and who are the developers? • What is the composition of the scrum team? • What are the rough benchmarks for the project? • How are the risks assessed?

Traditional approach In the traditional approach, the project is planned comprehensively. This allows clear statements to be made about deadlines, costs, and resources

• By when can the results or interim results be expected? • What is the planning for the project? • What is the estimated effort in persondays? • How much money is to be invested over the entire duration of the project? • Who are the relevant stakeholders? • Who is the project manager? • Who are the sub-project managers? • What is the composition of the team? • Which bottleneck resources are needed in which time period? • How are the risks assessed? Project order as a document of agreement between two parties: • Procedure plan: Methods, steps, milestones, first deadline, resources, and costplans (in a more detailed form for the traditional than for the agile approach). • Project organisation • Plan of action for the next phase • Information and communication concept (internal and external) and rules of the game Project manual, project management plan Risk list Stakeholder analysis Status reports, protocols Application for the next phase Documents in the traditional procedure, In the agile approach, it is not until the which concern the substantive results: concept phase that the in-depth • Prerequisites and assumptions discussion of content takes place in • Weaknesses and deficiencies of the order to create the product concept current state (product goal). This means that no • In-depth market studies, surveys, content-related topics are developed employee interviews, etc. in the initialisation phase. At most, the • Revised, detailed objective feasibility is checked • Requirements/specifications • Examination and assessment of feasibility, costs, economic viability, risks, and detailed profitability calculation (continued)

2.3 Initialisation Phase

65

Table 2.4 (continued) Phases and activities

Agile approach

Traditional approach Concept: in the initialisation phase, solution concepts are not yet in the foreground. Here, analysis results and objectives are more decisive. Solutions are initially limited to ideas for solutions or rough variants

Critical Success Factors and Key Performance Indicators The concept of Critical Success Factors (CSF) can be applied at the level of a company, but also within a project. CSFs are the factors and key variables that are central to the achievement of the project’s objective. The CSFs of a project are directly related to the CSFs of the company. The product owner or project manager has to be able to align the CSFs of the project with the CSFs of the company. Addressing the CSFs is important in the initialisation phase as this helps to align the project more effectively to achieve its objectives. Critical success factors in a project can be: • • • • • • • • • •

Project approach Project start Project organisation and the filling of roles Experience of the key people in the project Motivation and cooperation of the project team Managing the magic triangle of scope, time, and cost Stakeholder management Risk management Agile or traditional project planning Dealing with stress, resistance, and conflicts in the project team

Based on the defined CSFs, the project strategy (Best in Market, Design to Cost, Time to Market) (Sect. 2.3.4) can be determined. Key Performance Indicators (KPI)) are performance indicators. They help to continuously measure and assess the progress of the project and the degree of goal achievement. KPIs are used to manage CSFs. Each critical success factor (CSF) has one or more KPIs. People and Team The aspects below from the competence areas of people and team may be relevant in this phase of the project. However, they may also occur at a later stage or not at all. During initialisation, the team organisation is formalised based on the choice of the methodological approach (agile, traditional, or hybrid). In addition to this, the project order is then negotiated. This results in the following measures.

66

2 Methodology

• Depending on the chosen methodology (agile, hybrid, traditional), the corresponding key positions in the team have to be filled (agile: Sect. 2.3.8.4—traditional: Sect. 2.3.8.5). • Select key people: Choosing the right project manager, product owner or scrum master is crucial for the success of the project. • Working on the system (Sect. 1.5.2): With the official project order, the cooperation in the team has to be formalised. • Manage stakeholders (Sect. 2.3.5): Recording different views and expectations of stakeholders and managing their networking begins in this phase. Even small changes are noticeable in this network. • Setting up teams (Sect. 5.3.1) and roles in the agile Sect. 2.3.8.4) and traditional (Sect. 2.3.8.5) approach. • Consider dynamics in teams (Sect. 5.2): A project team can already fall from “forming” into “storming” even in this first official project phase. This increases the competences in personal communication (Sect. 3.9) and in conflict management (Sect. 5.6). • Negotiations (Sect. 4.10): Project managers are strongly challenged in this phase to work out a project order with the responsible decision-makers, in which the influencing factors of the magic triangle (Sect. 2.3.4) as well as the distribution of task, competence, and responsibility (Sect. 4.8) are in a realistic relationship to each other. Negotiation as an important competence is required here.

2.3.2

Setting Objectives

Objectives are statements about what is to be achieved with future solutions or what future state is to be aimed for. They are ideas, wishes, hopes, emotions around the question: What is to be achieved? Solutions, on the other hand, are not objectives, rather possible ways how objectives can be achieved. It often makes sense to distinguish between objectives and requirements. While objectives state what is to be achieved by a solution, requirements describe the quality of a solution or of a system that is required in order to achieve the objectives. Requirements are derived from objectives and listed in the “catalogue of requirements” (e.g. for offers). Objectives and requirements are often used synonymously: In this case, a distinction has to be made between objectives and detailed objectives. The importance of setting an objective is different in the traditional and in the agile approach. In traditional project management it is important to arrive at a precise, operationalised and stable objective as soon as possible, which then forms the benchmark for assessing the solutions. In the agile field, the objectives (frequently these are more “visions” than objectives) are often fuzzy and subject to change, i.e. they can be handled flexibly. The “magic triangle” in Fig. 2.7 shows the differences: In the traditional field, the objectives are described in more detail than the costs and deadlines from the beginning and are therefore relatively constant, whereas in the agile field, deadlines and costs are set as quickly as possible and the objectives and possible solutions are aligned accordingly (Sect. 2.3.4).

2.3 Initialisation Phase

67

Traditional: Plan Driven

Agil: Vision Driven

Scope (Vision, Objectives) operationalised, relatively fixed

Scope (Vision, Objectives) approximate, flexible

Time estimated, planned

Costs estimated, planned

Time (Deadlines) fixed

Costs fixed

Fig. 2.7 Magic triangle in traditional and agile project management

Basically, it is the type of project that determines how far target structuring ought to be advanced. For example, a target structure is less important in an organisational project than in a technical and highly complicated investment project. In traditional project management, the objectives can be operationalised using the following structuring features: • Global objective and detailed objectives • System objectives and process objectives • Elimination criteria and optimisation criteria

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

68

2 Methodology

Table 2.5 Objectives along the project phases Agile project management

Traditional project management

Initialisation phase • Vision, approximate global objective

• Objectives derived from analyses • Formulate global goal and requirements (specifications)

Concept phase • Product objective (product concept) • Objectives and requirements • Derive requirements (product backlog) from customer “stories“ • Review objectives on an on-going basis and adjust as necessary • Derive criteria for the evaluation of the solution variants • Develop solution concepts (specifications)

Realisation phase • Requirements according to the iterations • On-going learning shapes the requirements (product backlog)

• Refining or correcting requirements (specifications) and solution concepts (specifications) if necessary

requirements are developed from initially existing global objectives (e.g. introduction of a titration system for the Analytica trade fair by the end of April 2022). In the process, the objectives are refined step by step through an iterative application of the problem-solving process. They are thus operationalised. Even Non-objectives Are Helpful Non-objectives can be very useful as they narrow down the project and better describe what room there is for new solutions. Or vice versa: without formulating non-objectives, new problems or difficulties may arise and might be allowed to arise. Also, non-objectives can be an obstacle to ever new desires that inevitably arise in the course of the project process, e.g.: • The new regulation must not create additional bureaucracy • The adaptation of the website is done without rewording the texts (this non-objective can also be called a framework condition)

2.3.2.2 Global Objective and Detailed Objectives The rough, global or overall objective is often part of the project order and ought to be concise. It characterises the final state to be achieved in the project in a focussed manner and serves as orientation for the project staff. The formulation of the global objective contains a succinct statement regarding: What is to be achieved? When is this to be achieved? With what is this to be achieved?

Quality, functionality, scope Time limit Cost framework

2.3 Initialisation Phase

69

Example: Practical Example BLS Project Sales Back-End

Global objective: Technological foundation for an expandable, future-oriented, independent, and multi-client-capable BLS sales platform, mobile solution (app), online ticket shop, and timetable solution for the bls.ch project by the timetable change in December 2023, while not exceeding the defined budget. ◄ Example: Practical Example Metrohm OMNIS Titration System Project

Global objective defined at the beginning of the project: To further strengthen the market leadership in the field of titration, a “best in class” titration system is to be brought to the market. A fully automated, modular, user-friendly titration system with leading measurement precision is to be developed with the aim of being able to offer a Minimal Viable Product (MVP) for potentiometric titration in 2023, which will be expanded with further titration methods in the following years. The system should consist of a robotic solution for sample handling, a processing module, a measurement module, and a new software platform. Non-objectives of the MVP: No devices from the current portfolio are to be integrated into the software in the system. The planned cost framework is to be adhered to and will be reviewed on a quarterly basis. ◄ Detailed objectives are formulated as requirements. In extensive and complex projects, these can comprise up to several hundred pages and are in many industries also referred to in their entirety as specifications, as the requirements specification or as a requirements catalogue.

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

70

2 Methodology

Table 2.6 Practical example BLS: Process and system objectives System objective • Connection to the public transport platform via NOVA interface • Multi-client capability regarding sales back-end and digital sales channels • Expandable architecture that allows the connection of all distribution channels • Realisation of a mobile solution for ticket sales • Realisation of the online ticket shop for bls.ch • Integration of a timetable into the mobile solution and the online ticket shop

Process objective • The project is being carried out in accordance with the Hermes 2021 process methodology and passes through the BLS-internal quality gates (systematic review of interim results at defined milestones) • On-going coordination with Postbus and Südostbahn regarding the NOVA connection

2.3.2.4 Criteria for Appropriate Project Objectives The following rules should be observed when formulating project objectives: • Describe objectives as if they have already been achieved; this has a suggestive effect. For example, “Half a year after the solution goes into operation, the entire project costs have been amortised”. • Formulate objectives in a solution-neutral way: What can be perceived when the goal is achieved? If solutions are given or described, there is a danger that good solutions will be excluded too early. Example: “When a customer calls, the current information about him is available”. And not: “System XY provides current customer data on the screen”. • In addition to the objectives, the framework conditions should be recorded: What has to be adhered to? What must not happen under any circumstances? E.g., which safety aspects must be respected? • Formulate objectives as operationally as possible: Simple, understandable, clear, unambiguously measurable or in such a way that the achievement of objectives can be assessed. In particular, quantitative objectives should be stated in absolute values and not merely as a percentage improvement (compared to an often unstated reference value). For example, “The reject rate should be reduced from 1.0% today to a maximum of 0.5%” instead of “Halving the reject rate” or “Reducing the reject rate by 50%”. • Objectives should be realistic, even if the solution is not yet apparent at the moment. Realistic means that the achievement of objectives allows being actively influenced by those involved. Objectives can be put forth as demanding and challenging, because this has a strong motivating effect, especially in an innovative environment. • Operational detailed objectives In the traditional approach, detailed operational objectives should be formulated as early as possible after the project order and formulated as precisely as possible, and modified or supplemented later in the course of the project if necessary. • Objectives can also be prioritised or weighted: which objectives are more important than others?

2.3 Initialisation Phase

71

In summary, the SMART formula is helpful: "

SMART objectives are: Specific Measurable Attractive (also: achievable) Realistic Terminated

In many situations, the benefit of objectives is not measurable yet at the end of the project, e.g. in organisational development projects that aim to achieve efficiency gains or cultural improvements. In situations such as these, it is important to identify appropriate measurable indicators for the actual achievement of the objectives. Examples: Reduce error rate from 10 to 5%, reduce lead time from today’s 12 to 10 months, reduce the number of interfaces from 50 to 40, reduce staff turnover by 3 percentage points from 11.5 to 8.5%, halve the number of stock items to 1500 items, increase profit margin by 33% from the current 12 to 16%. These indicators can then be reviewed 6 months or a year after project completion. Finding and Agreeing on Objectives Together Objectives must be discussed, questioned and, above all, accepted and agreed upon. Therefore, the project manager or the product owner will never formulate the project objectives alone, but will work out and agree them with the project owner, the project team, if necessary with the project committee or with a support team. Objectives have to be agreed upon by all project participants, all ought to feel responsible for them.

2.3.2.5 Mandatory and Optimisation Objectives Often it is also useful to distinguish between objectives that have to be achieved and objectives that should be achieved as far as possible: Elimination criteria, or mandatory objectives (also called: must-have or essential objectives) are conditions that need to be achieved or adhered to in order for a solution to be useful or viable, even if it costs more or takes longer. These include above all: laws, safety regulations, standards, etc. Solutions that do not meet the mandatory objectives are gotten rid of and rejected. Mandatory objectives have to be free of contradictions. Optimisation criteria or also wish objectives (sometimes also referred to as nice-to-have or desired objectives) are objectives not having a decision-making character. Since these can be more or less strong desires, and are also often contradictory, such as cost objectives on the one hand and cost-generating performance and quality objectives on the other, optimisation criteria need to always be provided with an additional indication: the weighting. The weighting is easiest to understand if it is expressed in %.

72

2.3.3

2 Methodology

Requirements, Requirements Engineering

Requirements are derived from the objectives. They concretise the objective and answer the question “What is to be achieved?”. The requirements are formulated much more concretely and in more detail than the objective. The requirements are summarised in a specification. The further concretisation of the requirements into a solution concept answers the question “How should the requirement be implemented?”. This step is presented in the technical specification. Figure 2.8 shows the connection between objectives, requirements, and the solution concept. In the traditional approach, the requirements should contain all the criteria according to which a solution or solution variant will later be assessed and evaluated. Checklists help to achieve completeness early in the project. If no requirement is formulated for an aspect of the solution, the criteria for selecting the best solution are missing. Comprehensive requirements specifications and functional specifications are primarily developed in the traditional approach. In the agile approach, the requirements are developed iteratively in the realisation phase. Furthermore, a sharp separation of the requirement specification and technical specification is not always possible. The requirements are compiled in a product backlog (Sect. 2.4.3). Requirements, according to IEEE 610.12-1990, are defined as follows:

Global Objective

Detailed Target Requirement regarding … (Requirement specification: what shall be achieved?) Functionality

Quality

Boundary Conditions

Solution Concept (Functional specification: how shall the requirements be implemented?)

Fig. 2.8 Interplay between objectives, requirements, and solution concept

2.3 Initialisation Phase

73

• A condition or capability required by a user (person or system) to solve a problem or achieve a goal. • A condition or capability that a system or subsystem fulfils or possesses has to meet a contract, standard, specification or other formally specified document in order to achieve an objective.

2.3.3.1 Requirement Engineering Activities Requirements are developed and defined in Requirement Engineering, often abbreviated as RE. The main activities of requirement engineering can be summarised as follows: • • • •

Investigate: Gaining, detailing, and refining requirements Document: Adequately describe requirements Check and consolidate: Check quality criteria Manage: Requirement Management

Another important task of requirement engineering is to clarify the context, system boundaries, and scope of delivery. Requirements are elaborated through the use of different elicitation techniques, such as questioning (interview, questionnaire), use of creativity techniques (brainstorming, change of perspective), or observation (field observation, doing the user’s work under his or her guidance), (brainstorming, change of perspective) or observation.

2.3.3.2 Types of Requirements Table 2.7 shows the different types of requirements. The framework conditions (also called boundary conditions) are not requirements that are implemented, but they limit the solution space. Laws (for example: regulations for safety, health and environmental protection), norms and standards (for example, relevant codes of conduct, professional regulations, principles and objectives of sustainability) have to be identified and it is to be ensured that they are complied with. Table 2.7 Types of requirements Functional requirements • Functions and capability of the system • Behavioural requirements • Structural requirements • Business rules • Data • States • Error handling • Interfaces

Non-functional requirements Quality requirements: • Details on functions (safety, accuracy) • Reliability • Usability • Efficiency • Modifiability • Transferability

Framework conditions (organisational and technical): • Development process • Budget • Dates • Team • Laws • Standards • Operation

74 Table 2.8 Criteria for the quality of requirements and requirements documents

2 Methodology

Requirements • Tuned • Rated • Clearly • Valid and up to date • Correct • Consistent • Testable • Realisable • Trackable • Complete • Understandable

Requirements document • Consistent • Unique, Versioned • Clearly structured • Modifiable • Extendable • Complete • Trackable

2.3.3.3 Criteria for the Quality of Requirements and Requirements Documents Requirements and requirements documents can be checked for their quality using the criteria in Table 2.8. 2.3.3.4 Prioritisation of Requirements In many projects, users, customers, or marketing formulates more requirements and wishes than can be implemented within a reasonable period of time or with the available resources. To ensure that the important and central requirements are implemented, they have to be prioritised. Requirements and wishes can also change in the course of the project. The agile approach takes this circumstance into account. In scrum, the requirements in the product backlog are continuously prioritised. Prioritising the requirements helps the project team to focus on the important and central requirements. Prioritising requirements is demanding, it is done by representatives of users, customers, or marketing. In scrum, this responsibility falls to the product owner. Frequently used criteria for prioritisation are: benefit, cost, and risk. Various methods are available for carrying out prioritisation. It is advisable to combine different methods. Kano Model for Determining Benefit Noriaki Kano, in his model, distinguishes between basic, performance, and enthusiasm requirements, see Fig. 2.9. The fulfilment of basic requirements (e.g. a heated holiday flat in winter, a brake on a bicycle that works well even in rainy weather) is essential, but does not lead to high customer satisfaction. Performance requirements (e.g. the number of rooms, the equipment of the kitchen in the holiday flat, the number of gears on the bicycle) lead to a linear increase in customer satisfaction. The motto “the more, the better” applies to performance requirements. Enthusiasm features (e.g. a beautiful view, a good location, intelligent gears) lead to high customer satisfaction. The indifference zone is the area where expectations are more or less fulfilled. The satisfaction values in this zone are moderate. Outside of the indifference zone, the satisfaction values of the basic and enthusiasm requirements rise or fall disproportionately. In the prioritisation, a clever

2.3 Initialisation Phase

75

Fig. 2.9 Kano model for determining utility

combination of the requirement categories has to be found, whereby the basic requirements are implemented. Over time, enthusiasm requirements shift to performance requirements and performance requirements to basic requirements. MoSCoW Prioritisation The MoSCoW prioritisation (sometimes also known as MuSCoW) divides the requirements into four groups: Must have, should have, could have, and won’t have: • MUST: Implementation is mandatory for acceptance. • SHOULD: Requirements ought to also be implemented, but unlike MUST requirements, they can be changed through change requests or negotiations. • COULD: These requirements are implemented when all must and should requirements are met and sufficient resources and time are still available. • WON’T: These requirements are not yet implemented in the current project and are instead saved in an idea pool or the requirements list for the next project. Business Value As described in Sect. 2.4.6 effort estimation, the business values for the individual requirements are determined using the T-shirt sizing method. The requirements with the highest business values are given the highest priority for implementation.

2 Methodology

high

76

implement first

implement last

implement second

low

Risk

avoid

low

high Value

Fig. 2.10 Value-risk matrix

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

2.3 Initialisation Phase

77

2.3.3.5 Feasibility Check At the end of the initialisation phase, it must be clear whether the project can be carried out successfully. A feasibility study provides the basis for decision-making: • Is the project technically and politically feasible as well as possible in time? • Can the necessary resources (financial, human, knowledge, management support, etc.) be provided? • Do regulatory/legal requirements allow the implementation? • Are the benefits of the project known to and recognised by all relevant stakeholders? • Other sources for clarifying the feasibility can be: stakeholder analysis, SWOT analysis, risk analysis, best practices, industry experience, business case, etc.

2.3.4

The Magic Triangle

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

78

2 Methodology

Scope 1

At the beginning of the project

2

During the project

3

Towards the end of the project

3

1

2

Time

Costs

Fig. 2.11 The magic triangle

dimensions. This determines his room for manoeuvre in dealing with these three restraining factors. This may be the “magic part”: How does the project manager deal with these conflicting demands? Beyond this balancing act, there is nothing magical about the term “triple constraint”. Sometimes a meaning is also assigned to the connecting lines in the magic triangle: Between scope and cost is profitability, between scope and time is effectiveness, and between cost and time is productivity. Different strategies lead to different weighting, see Table 2.9. As shown in Sect. 2.3.2 there are also differences in the magic triangle between the agile and the traditional approach. In the agile approach, time, costs, and team size are fixed. In contrast, the scope is fixed in the traditional approach. Table 2.9 Different project strategies with influence on the project objectives Best-inMarket Time-toMarket Design-toCost

The highest priority is to maximise quality and functionality. This “attraction” is intended to draw in as many new customers as possible on the market. The highest priority is a minimum project duration in order to be able to appear on the market as quickly as possible (e.g. product development). Costs and quality are of secondary importance. The highest priority is given to the cost objective, i.e. how much the developed result may cost. The project manager breaks the cost objective down into smaller units and monitors these partial cost objectives (also called “target costing”).

2.3 Initialisation Phase

79

The meaning of the corners of the magic triangle also changes in the course of a project. At first the focus is on finding and defining the scope, soon the focus changes to costs and towards the end of the project the focus is on time.

2.3.5

Stakeholder Management

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

80

2 Methodology

Expected reaction:

Project Owner

positive, promoting neutral, indifferent negative, hindering

Authorities

Customer

Project Manager

Project

Employees

Suppliers

Competitors

Fig. 2.12 The project as a social system

Each stakeholder’s interest, influence, and power (Sect. 4.9) over the project should be assessed. The influence can be on a formal or an informal level. The question of how the stakeholder will react to the project is also of interest. This task is most easily presented in tabular form, see Table 2.10. The following considerations are helpful in addressing this question: • What do the stakeholders think about the project? The problem should be considered from the different perspectives of the stakeholders. • What are the relationships between the stakeholders? How do they relate to each other? What interests and objectives do the individual stakeholders pursue? Are there any conflicts of objectives and interests (Sect. 5.6.6.1)? • What reactions and behaviours of the stakeholders must the project manager or product owner expect? • A stakeholder map can be derived from the first analysis, see Fig. 2.13. 3. Steering stakeholders Based on the stakeholder analysis and assessment, measures are formulated and implemented. Possible approaches for dealing with stakeholders are: (a) Involve stakeholders in the project, i.e. include them in a suitable project committee and define the tasks and roles of the stakeholders in the project. (b) Clarify interests and objectives, resolve objectives or conflicts of interest with conflict management or mediation

2.3 Initialisation Phase

81

Table 2.10 Practical example “New Town Hall”: Excerpt of a tabular representation of a stakeholder analysis

Stakeholder Voting citizens

Interest, concern Multifunctional town hall

Administration staff

No open-plan offices!

3

Associations

Infrastructure for activities! Impairment due to shadow cast

2

Residents

Monument protection

No impairment of the townscape

3

3

1

Power, influence, legitimacy Public vote

Indirectly via motivation Influence voting Legitimate to raise objections Objection possibility

3

Expected reaction to the project Consent probable

+

2

Different reactions

?

1

neutral

Ø

2

Objection probable

–

3

Public debate, objection

–

large

Degree of relationship with the project: 3, high; 2, medium; 1, small Type of relationship: +, positive; –, negative; ?, unknown; Ø, neutral

Environmental organisations (+)

Voting citizens (+)

Residents (-)

medium

Influence

Monument protection (-)

Employees (?)

Clubs (0)

Providers (+)

small

Customers (+)

small

medium Interests

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

large

Measures Communicate effort/benefit well Inclusion in office planning Arouse interest Early information Integration into the project team

82

2 Methodology

(c) Based on the information and communication concept Inform stakeholders in a way that is appropriate for the target group and maintain dialogue, i.e. consciously align the communication types and channels with the stakeholders. (d) Create additional communication vessels, e.g. workshop, large group intervention, information event. In order for the project manager or product owner to successfully manage the stakeholders, they have to be given authority by the line to play their role. The product owner or project manager needs to address the stakeholders at all three levels of cooperation (relationship, content, and organisation: Sect. 1.5) and involve them in the project. The stakeholder map (Fig. 2.14) shows directly how those responsible for the project should deal with whom. Basically:

Respond to demands, communicate early, involve project owner

Pay greatest attention, involve them, work close together

Maintain minimal contact, observe, show interest

Keep up to date, appreciate

medium small

Influence

large

• The power and influence of stakeholders can hardly be controlled. However, the relationship of the stakeholders to the project can be controlled through relationship management. • Identify changes and developments in relation to stakeholders • Communicate regularly with stakeholders • Periodically check and adjust the measures taken

small

medium Interests

Fig. 2.14 Strategies for dealing with stakeholders

large

2.3 Initialisation Phase

2.3.6

83

Project Marketing

Project marketing includes all supporting activities that can positively influence the acceptance as well as the course and progress of a project. It is about selling the project, where “selling” is understood to mean how to: • Communicate the meaning of the project, create benefits, pass on one’s own conviction. • Create trust and acceptance • Show fairness: also make possible disadvantages or problems transparent, take fears and questions seriously and address them • Create publicity, generate expectations that energise the project • Tap into resources and sales markets Project marketing promotes the relationship between the project and its environment or stakeholders. Project marketing means shaping communication and can be approached very creatively depending on the situation and stakeholders, comprising, e.g.: • Wide-ranging information with opportunities to engage with the topic (e.g. open space event) • The project blog, in which those affected, users, etc. (i.e. not project actors) are allowed to express themselves critically • Info market: information boards and stands with documents; project participants answer questions • A creative workshop for interested parties; the results of which will be recorded and further processed by the project team • Visit and experience the project object • The use of key people, promoters, decision-makers for information • Speaking the language of the stakeholders and getting a notion about what they are interested in Project marketing is often not just about “selling” the project, but also about conveying management messages and values at the same time, e.g. that a new culture of cooperation is being introduced simultaneously with the project. The basic attitude in marketing is important: showing off, deceiving, talking up, pretending to be involved only works in the short term at best. In order to really create trust, honesty—transparency and appreciation are required. Project marketing already begins during the initialisation of the project. However, its importance increases during the implementation phase, namely when the project gets introduced and the number of people to be informed increases.

84

2 Methodology

Risk Process

Identification

• Identify all possible risks (fields) • Collect all risk relevant information

Quantification

• Evaluate and weight identified risks • Probability of occurrence • Evaluate extent of damage

Coverage

Control

• Develop measures and prepare actions: - Avoid (preventive) - Mitigate (preventive, reactive) - Pass on (insurance, contract) - Accept (carry consciously, plan)

• Regularly check and announce status • Ensure that new risks are identified

Fig. 2.15 The risk process

2.3.7

Risk Management

Risk management in the context of a project should cover not only the product risks, which are often well mapped in the company processes, but especially the actual project risks. In many companies, project and product risks are well thought out in a joint risk analysis. In the following concentration on project risks, the considerations also apply mutatis mutandis to product risks. Figure 2.15 shows the sequence of the risk process. In the same way that risks are dealt with, opportunities can also be identified and realised.

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

2.3 Initialisation Phase

85

Table 2.11 Examples of risk categories

large

• Methodological risks (complexity, procedure) • Technological risks (new products, material properties, etc.) • Economic risks (cost ceiling, creditworthiness of business partners, etc.) • Personnel risks (availability, bias, dilemma with different roles, illness, resignation, etc.) • Political risks (change in corporate strategy, legislation) • Competition and market risks (competitor product is better or lower cost) • Legal risks (product liability, contracts, etc.) • Environment risks • Stakeholder-related risks (resistance from opponents)

hi -ri

gh

Ri

sk

medium

Probability of occurrence

sk

small

ee

-fr

lem

ob

pr small

medium

large

Severity of damage

Fig. 2.16 Extent of risks

2. Quantify Risks To quantify the risks, both qualitative and quantitative methods are available. This step is primarily concerned with describing the “level” of the risk. The risk can then be described quantitatively from the two following parameters: Risk = probability of occurrence × severity of damage The probability of occurrence can be divided into probability classes as shown in Fig. 2.16 or estimated as a percentage. The severity (degree of harm) is often quantified in monetary terms or given as a time delay. Instead of a supposedly precise calculation of the risk, in practice it is

86

2 Methodology

Risik Map 70-100 30-70

R4 R1

R6 R3

R2 R14

R5

0-30

Probability of Occurence (P)

Overview all risks

R9

R1

R13

R12

Medium

R6: R9: R10: R12: R13: R14:

R10

low

R1: R2: R3: R4: R5:

Introduction of public transport platform NOVA Pilot Scarce resources at BLS Project is overloaded Dependence on other projects (CEM, bls.ch, ESB, S16) Quality of cost estimates Experience with agile approach Compliance with pace by project team Coordination difficulties between BLS, PAG, SOB and ZVV Decision to connect TUs by ZPS Ongoing changes to NOVA interface

high

Severity (S)

Fig. 2.17 Practical example BLS: Risk matrix

often sufficient to assess the risk in terms of the probability of its occurrence and the severity of the damage, as shown in Fig. 2.16. In Fig. 2.17 the risk matrix is shown and in Fig. 2.18 a description of the main risks of the practical example BLS is presented. It is recommended that the assessment of the probability of occurrence and the expected severity of damage get carried out in the project team. A jointly developed view promotes understanding and increases the sensitivity towards the critical risks by the project team. For this assessment, the cards from the Planning Poker (Sect. 2.4.6.2) can also be used. A sensitivity analysis looks at the influence of one parameter at a time (e.g. observation period, interest rate, annual returns, etc.). This means that it is examined how sensitively the parameters react to small changes. This can help to identify sensitive assumptions or critical parameters in order to be able to monitor them intensively during implementation. A method that follows the basic idea of sensitivity analysis and has become established in many industries and companies is FMEA, the Failure Mode and Effects Analysis, see Sect. 2.3.7.2. In some industries it is compulsory for every system and every component that is newly created, also by all suppliers (automotive engineering, medical technology). In other industries, this method has been adapted to the different conditions, e.g. in the food industry (HACCP: Hazard Analysis and Critical Control Points). Another way to assess the risks is simulation. With it, several parameters can be run through in the form of different scenarios.

2.3 Initialisation Phase

87

Risks Description of the top project risks Risk

Description

Impact

Measures

R4

Project is overloaded, great project complexity, parallel clarifications of principles

Change Requests

Rapidly press ahead with parallel clarifications of principles

The replacement of distribution channels or the development of new channels is done in the project.

Trend

Burden in the project increases with declarations of principle R5

Dependence on other projects (CEM, bls.ch, ESB, S16)

Requirements / requests from linked projects

Voting meetings (Trident+)

R6

Quality of the cost estimates

Cost overruns

Regular evaluation of the assumptions underlying the project Identification and monitoring of cost drivers Strong involvement of controlling

Measures show effect (improvement) No deviation foreseeable Deviations foreseeable (deterioration)

Fig. 2.18 Practical example BLS: Description of the top project risks

3. Cover Risks To ensure that a project can still be carried out or that the risk is acceptable for the company, targeted preventive measures should be developed that are able to reduce the risk to an acceptable level. The basic measures according to Table 2.12 can be helpful. In a risk management tool all identified risks are listed and evaluated. Measures are defined for each risk, and their influence on the risk is presented. In practice, the risk management tool is often mapped out in a spread sheet programme; the market also offers specific software solutions. Table 2.12 Measures to reduce risks Avoid Decrease

Roll off

Carry consciously

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

88

2 Methodology

Table 2.13 Example of a risk list Risk Two weeks milestone delay due to staff bottleneck because of work on several projects Failure of the existing test facility for testing the prototypes

P0 7

S0 6

R0 42

Measure Clear communication of project priorities according to portfolio

P1 1

S1 6

R1 6

Costs 1/4 h at project meeting

Decision Implement

3

4

12

Procure a second test facility as a backup

3

1

3

35k €

Do not implement

Legend: P, probability of occurrence; S, severity on a scale of 1–10; R0, risk before implementation of the measure; R1, risk after implementation of the measure

Table 2.13 shows an exemplary risk list with qualitative risk assessment before and after implementation of the corresponding measures. In addition to the measures for reducing risks shown in Table 2.4, conscious risk strategies as shown in Fig. 2.19 can be selected for coping, too. For risks that can be influenced by the project, measures can be developed or the FMEA (Sect. 2.3.7.2) can be applied. Despite all the measures, risks remain that can hardly be influenced by the project. The project manager can only prepare to these and observe them carefully on an on-going basis. 4. Control Risks The implementation of the defined measures has to be monitored continuously. In addition, the risk process needs to be run through periodically. This ensures that new risks are identified and the quantification of the identified risks is reviewed and adjusted if necessary.

2.3.7.2 Failure Mode and Effects Analysis (FMEA) An FMEA (Failure Mode and Effects Analysis) can be carried out at different stages of a project, a distinction is made in particular between the following types of FMEA: • Design FMEA (also called concept FMEA) • System FMEA (also called product FMEA) • Process FMEA (also called production FMEA) All potential errors that are conceivable in a wide variety of situations are listed. Then, preventive, focused measures are taken. Their effectiveness is checked on an on-going basis. Procedural steps of an FMEA include:

89

low

2.3 Initialisation Phase

Process multiple alternative solutions in parallel

Ri

sk

Own responsiveness to events / changes

Prepare several scenarios and act accordingly if needed

high

Develop preliminary considerations and act decidively if needed

Monitor closely and react immediately

good

poor Predictability of events / changes

Fig. 2.19 Risk strategies

• • • • • •

Listing all conceivable errors, failures or problems. Indicating possible consequences of the failure or problem. Formulating possible causes and corrective actions O = Occurrence: Assessing the probability of occurrence [1 ... 10]. S = Severity: Determining the severity effects of the error [1 ... 10]. D = Detection: Finding out the probability of detection in the company [10 ... 1].

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

Test of system cannot start as planned

R3 ASIC is not functional in time

Fig. 2.20 Practical example Metrohm: FMEA analysis 6 10 10

Market * SW backlog is not met introduction of the on time system cannot take place as desired

3

R5 Software is not available with sufficient functionality

8

8 10

3

8

9 10 8

R4 UL certification will Sales in the North * UL requirements will not American market be achieved not be achieved will be difficult

* ASIC technology has long design loops * Not enough Resources

* Clogging of valves

Dosing accuracy is not achieved

Root Cause

R2 New valve technology does not work

Consequences

User has * Valves do not operate inaccurate and correctly fluctuating results * Drive control inaccurate * Waiting times for changes in movement not sufficient

Error

R1 Dosing precision does not meet required measuring accuracy

ID

Assessment prior to measures Measures M2 Optimise drive control, measure with high-grade linear path measuring system, compare with existing metering system

Measures

600 Make more resources available, obtain external support

72

Prioritise backlog with experienced specialists

640 Provide more resources, Enable test start by obtain external support integrating existing ASIC

720 Find alternative solution (Plan B)

Current Status O S D RPN M1 8 10 6 480 Optimise valves through material selection improvement, test all variants

Failure Mode and Effect Analysis (FMEA)

EWP100 OMNIS Titriersystem

Clear prioritisation of functions, schedule those needed later in a later design loop

2

3

1

10

8

8

2

2

2

40

0

48

16

Improved State M3 O S D RPN Determine waiting 2 10 3 60 times using existing metering system, check metering accuracy with different waiting times

Assessment after measures

red fields have to be mitigated

90 2 Methodology

2.3 Initialisation Phase

91

after implementation of the measures is then determined. It needs to also be below the limit value.

2.3.8

Project Organisation, Roles, Committees

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

2.3.8.1 Line and Project: Two Different Worlds If special problems are dealt with by project teams in a company, this means that, in addition to the line organisation, a further work formation is permitted which differs from the regular line organisation: • • • • •

In the delegation of authority In the nature of the cooperation In the conflict culture In communication In dealing with taboos

Table 2.14 Important prerequisites for a well-functioning project organisation Important prerequisites for a well-functioning project organisation

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

92

2 Methodology

Line organisation

Line culture hierarchical, given reporting channel and decision-making structures

Project organisation

Project culture team-oriented, simultaneous cooperation, networked communication

Fig. 2.21 Two worlds: Line organisation and project

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

2.3.8.2 Roles and Bodies In project organisations, people are often appointed without there being a clear idea beforehand of what their role ought to be. As a result, roles are not clearly defined and delimited, or even missing. Example: The project owner, who also likes to work in the team, makes decisions “from above” (as is expected of him) due to his given position of power and “from below” in the team as a team player. The project manager is faced with having to fulfil conflicting roles because of this dual function. Such cases should be clarified at the beginning of the project. Multiple roles are dangerous. In small projects, a complete assigning of divided roles is of course not possible down to the last detail. But then, if achievable, “neighbouring roles” should be played by the same person, e.g. the project manager ought to also work on the content of the project. Several roles together form a body (e.g. project committee). The committees and roles, often also referred to as project organs, are formed and named according to the project and corporate culture (and industry culture) in such a way that all levels of competence are represented and the project objective can be achieved as effectively

2.3 Initialisation Phase

93

as possible. Often it is not really known who decides. The role of the project manager is seen as a necessary evil and is therefore only marginally perceived. The project has to be clearly anchored in and at the decision-making level. The decision-making process has to be made transparent. Further explanations related to the topic of position and role are given in Sect. 5.3.1.

2.3.8.3 Competences and Management Tasks in the Project Organisation The competences of the various roles and committees differ in part in the agile and traditional approaches. Table 2.15 shows the institutional roles and committees with their respective focal points at the competence level. In order for a project team to work effectively, the project manager, the product owner, or the scrum master must perform a variety of management tasks and Table 2.15 Roles and committees with their respective focal points at the competence level Role, board Project owner: what?

Agile • Decision-making authority regarding project thrust • Social competence • Negotiation skills • Subject matter expertise

Project committee: what? Project manager: what & how?

• Preliminary ruling • Connection project-line

Product owner: what & how?

• Self-competence • Social competence • Negotiation skills • Subject matter expertise Decision-making authority within the framework of the project • Self-competence • Social competence • Team and leadership competence • Methodological competence • Team and leadership competence regarding self-organisation • Subject matter expertise • Decision-making authority on what to include in the next sprint

Scrum master: how?

Project team: how?

Traditional • Decision-making authority regarding the direction of the project • Social competence • Negotiation skills • Subject matter expertise • Preliminary ruling • Connection project-line • Self-competence • Social competence • Negotiation skills • Team and leadership competence • Methodological competence • Decision-making authority within the framework of the project

• Subject matter expertise

94

2 Methodology

Table 2.16 Different tasks Team development

Conflict management and crises Chair and moderate meetings

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

services. These are described in detail in Chap. 5. In Table 2.16 individual aspects are listed by way of example.

2.3.8.4 Project Organisation in the Agile Approach A scrum team (see Fig. 2.22) in the agile approach according to scrum consists of the following members: • Product owner • Developer (the team) • Scrum master Agile teams are self-organised and interdisciplinary (Sect. 4.5). The members have all the skills required to generate value in each sprint. Each role in the agile project organisation has specific result responsibilities, which are described in Table 2.17. Weighted Competence Profiles Product Owner and Scrum Master The competence profiles shown in Fig. 2.23 for a product owner and a scrum master are based on the competency model in Sect. 3.1 Non-hierarchical, Network-Like Project Organisation Similar to scrum, non-hierarchical, self-organised project organisations are very effective especially for highly complex and dynamic projects. Practice has shown that these “work” very well in projects with a lot of creative freedom and carefully worked out framework conditions and rules. For extensive projects, it is possible to

2.3 Initialisation Phase

95

Product Owner

Scrum Master

Scrum Team

Developers

Fig. 2.22 Scrum team

Table 2.17 Responsibilities for results of the individual roles and committees in the agile project organisation Role, board Project owner

Project committee, Steering committee Scrum team

Product owner

Task The project owner has less influence on the project in the agile approach than in the traditional approach. Nevertheless, the project owner has to fulfil the following tasks: • Setting the strategic framework • Support the product owner, give him back-up • Affirm resources • Open doors, for example for important informants • Show your motivation (for example at the kick-off) The use of a project committee in the agile approach is optional. It is best to invite the important stakeholders to the sprint reviews. This allows them to provide valuable input to the project The scrum team as a whole is responsible for the implementation. Activities such as stakeholder involvement, verification, maintenance, operation, experimentation, research, development, and everything else that is needed are detected and carried out together. The scrum team produces a valuable and useful increment in each sprint The product owner controls the scrum team at the content level by determining what is to be implemented. He manages the product backlog and is responsible for maximising value. In summary, the responsibilities of the product owner are: (continued)

96

2 Methodology

Table 2.17 (continued) Role, board

Scrum master

Developer

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

2.3 Initialisation Phase

97

Table 2.17 (continued) Role, board

Task capacity and work together in close proximity where possible The ideal team size is between three and nine members. If more than nine members are needed to realise a project, parallel teams are ideally formed. The Large Scale Scrum (LeSS) approach can be followed. The realisation of projects with several teams working in parallel is very demanding and requires a lot of experience from all participants. In a setting with several teams, there is only one product owner

Product Owner

Methodological skills

Scrum Master

Expertise

Expertise

4

4

3 2

Selfcompetence

1

3 2

Methodological skills

1

0

Team and leadership skills

Selfcompetence

0

Social skills

Team and leadership skills

Negotiation skills

Social skills

Negotiation skills Key: 0 not relevant 1 not necessary 2 helpful 3 important 4 requirement

Fig. 2.23 Weighted competence profiles in agile project management

have several parallel teams that are networked with each other. Direct networking ensures better coordination than a central coordinator. These teams are selforganised, and relations with the project owner and any project committee are non-hierarchical. Management must explicitly commit to self-organisation (Sect. 4.5), because it delegates part of its decision-making power and must support the project accordingly. As the project owner, it defines the project order, i.e. the content framework and the rules of the game. The project owner is thus more of a customer and agrees on the assignment with the team. The “project lead” can have two forms: • In hybrid projects, the “agile project manager” is responsible for the overall planning (Kolb, 2014).

98

2 Methodology

Project Team 1 Project Owner Support Team Product Owner

Organiser/ Team Coach Scrum Master

Project Team 2

Project Team 3

Fig. 2.24 Possibility of a project organisation as a network

• In agile project parts, the “team coach” or scrum master is responsible for supporting the team. Depending on the project, both roles can be combined in one person. Basically, however, it should be noted that project managers do not have a leading but an organising and supporting function in the context of self-organised teams: They organise the nomination of team members, plan and moderate meetings such as the kick-off or the coordination and presentation meetings, present a shield from outside influences or offer coaching. If there is a project committee, it also has a supporting function vis-à-vis the team(s), in addition to the preliminary work (developing the vision and guidelines, carrying out higher-level strategic work, etc.). In such situations, the project committee is therefore also called a support team, as shown in Fig. 2.24. Alternatively, frameworks such as SAFe (Scaled Agile Framework) or LeSS (Large Scaled Scrum) can be used as orientation and alignment for parallel agile teams.

2.3.8.5 Project Organisation in the Traditional Approach Each role in the traditional project organisation has specific tasks to perform, which are described in Table 2.18.

2.3 Initialisation Phase

99

Table 2.18 Tasks of the individual roles and committees in the traditional project organisation Role, board Project owner

Project committee Steering committee

Sounding board

Project manager (PM)

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

100

2 Methodology

Table 2.18 (continued) Role, board

Sub-project manager (SPM), sub-project teams

Project team

Temporary groups

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

The ideal-typical project organisation is shown in Fig. 2.25. The project manager should have self-competence, social competence, negotiation competence, team and leadership competences, and methodological competence. Of course, he cannot be a specialist in all of these areas. But depending on the project and the task at hand, he or she should have the competences that are favourable for project management in each field. Weighted Competence Profiles Project Manager and Project Owner Based on the competence model in Sect. 3.1 a possible competence requirement profile for project managers and project owners is shown in Fig. 2.26. Self-competence: The project manager’s view of himself and the world influences the way he interacts with his team. His general awareness (Sect. 3.3.4), his

2.3 Initialisation Phase

101

Project Owner Project Committee Steering Committee

Project Team

Project Manager

Core Team Subproject-Team

Subproject-Team

Subproject-Team

Fig. 2.25 Ideal typical project organisation

Auftraggeber

Methodological skills

Projektleiter

Expertise

Expertise

4

4

3 2

Selfcompetence

1

Methodological skills

Selfcompetence

1 0

0

Team and leadership skills

3 2

Social skills

Team and leadership skills

Negotiation skills

Social skills

Negotiation skills Key: 0 not relevant 1 not necessary 2 helpful 3 important 4 requirement

Fig. 2.26 Weighted competence profiles in traditional project management

102

2 Methodology

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

2.3.8.6 Project Organisation in the Hybrid Approach In the introduction (Sects. 1.4.3 and 2.1) we describe possible organisational forms for hybrid project management. The best combination of agile and traditional elements must be determined individually for each project. Figure 2.27 shows the hybrid project organisation using BLS as a practical example. 2.3.8.7 Project Organisation in Customer Projects The project organisation in customer projects has to be assessed and determined according to the situation. Various constellations are conceivable: • The customer project is a sub-project in a larger project. • The project is implemented jointly. Key roles such as project management are filled twice. This is the case in many construction projects, for example, with an owner’s representative and a construction manager. • The project is implemented independently. The customer is involved in defined sub-steps for acceptance and reviews. It is important to clarify the roles together. Who does what? How are the tasks differentiated from each other? Who is responsible for which topic? It is also advisable to establish a common set of rules.

2.3 Initialisation Phase

103

Principal /

Project Board Quality Gates Overall project manager

Technical Committee

Enterprise architecture

Finance/ Controlling

Technical lead, Processes, Requirements, Product Owner

Supplier mgmt., Testing, IT operation, IT Project Manager, Scrum Master

Architecture, Development

Procurement

Product Owner & Change Log

IT-operations / Infrastructure

Solution Architecture

Processes, Requirements, Req. Engneering

IT Security

Developer & Realisation partner

Communication & Marketing

Testmanagement

Operational preparation / set-up Customer support

Operational preparation IT

Tenders

Purchasing, Legal

1 agile

traditional

agile and traditional mixed

Fig. 2.27 Practical example BLS: Hybrid project organisation

2.3.8.8 Linking the Project Organisation to the Line Organisation The question with every temporary organisation is how it is linked to the organisation as a whole. Project organisations are set up in three different forms: • Project coordination • Pure project organisation • Matrix organisation The various organisational forms differ in the way the entirety of leadership and decision-making authority is shared between the line and the project, or in how great the degree of freedom for the project manager and his team is. An agile project can only be implemented in the pure project organisation or in a matrix organisation. For details, see Fig. 2.28. The Project Coordination The Project Coordination (or Influence Organisation) is the minimal form of a project organisation in which the primary organisation is merely supplemented by the staff position of the project coordinator. For organisational chart, see Fig. 2.29. The functional hierarchy remains unchanged. The coordinator (project manager on staff) has no authority to issue directives. However, he or she is responsible for the

104

2 Methodology

Authority of line management

small

Project coordination The decision-making authorities are with the line instances

small

Authority of project management

large

Pure project organization The decision-making authorities are with the project instances

Matrix project organization Decision-making is negotiated between line and project organization

Fig. 2.28 Forms of project organisation and allocation of competences

Management

Department A

Department B

Department C

Employee A1

Employee B1

Employee C1

Employee A2

Employee B2

Employee C2

Employee A3

Employee B3

Employee C3

Authority

Organization

Fig. 2.29 Project coordination

Project

Project Manager

2.3 Initialisation Phase

105

Table 2.19 Advantages and disadvantages of project coordination Project coordination

Advantages • High degree of flexibility with regard to staff deployment • Simple exchange of experience • Large collection of experience across the different projects • No organisational change • Responsibility of the project remains largely with the line

Disadvantages • No one feels responsible for the project • Low reaction speed • Cross-organisational perspective is more difficult • No real project team

factual and temporal course of the project, for the timely information of the relevant line instances and for the correct procedure. In his coordination function, he proposes measures and next work steps to the line. This type of project management requires that the line management cooperates constructively and makes the necessary information available to the project manager. In this form of organisation, the project manager is not to be held solely responsible for the achievement of objectives, since he lacks leadership responsibility in the project and is particularly dependent on the willingness of the line management. The advantages and disadvantages of project coordination are shown in Table 2.19. This form of project coordination is particularly suitable for projects that do not significantly exceed the scope of conventional tasks. Examples: Customer orders, simple product developments The Pure Project Organisation At this organisational form, an independent new organisational unit is formed for the project. For organisational chart, see Fig. 2.30. The project manager and the team members are full-time members of the project. Thus, the project manager also bears full management responsibility with all decision-making powers (except with regard to milestone decisions). An independent, efficient team/task force is created. This project organisation can be quite expensive, because the previous positions have to be filled. And if the employees are not fully utilised in the project, there will be idle time. The advantages and disadvantages of pure project organisation are shown in Table 2.20. The pure project organisation is clearly demarcated from the line and has a high degree of autonomy. As a task force, it handles very important and urgent projects in a short time. It is suitable: • For projects that have relatively little contact with traditional tasks (e.g. developing a completely new product line, constructing a new building) • For projects carrying a very high risk (spin-off of the project from the company) • For time-critical projects • Where a specifically resounding impact of the results is needed

106

2 Methodology

Management

Department A

Department B

Employee B1

Department C

Project Manager

Employee C1 Project Team Member 1

Employee A2

Employee B2 Project Team Member 2

Employee A3

Employee C3 Project Team Member 3 Authority

Organisation

Project

Fig. 2.30 Pure project organisation Table 2.20 Advantages and disadvantages of pure project organisation Pure project organisation

Advantages • Efficient organisation for large projects • Clear responsibility and decision-making authority with the project manager • Fast reaction time in the event of mistakes • High degree of identification of the project team with the project • Independent of the influence and any arbitrariness of the line

Disadvantages • Little staff flexibility, especially for specialists who are only needed temporarily • Recruitment and reintegration of project staff after the end of the project can be difficult • Danger of authoritarian or non-teamoriented leadership by the project manager more probable, as he/she leads in a special temporary situation

The Matrix Project Organisation This organisational form represents a mixture of pure project organisation and project coordination. For organisational chart, see Fig. 2.31. The responsibilities and competences are divided between the project manager and the line instances. This division depends on the project and can vary within wide limits. The matrix project organisation places very high demands on the clear division and adherence to the agreements between the line and the project as well as on the role awareness of all

2.3 Initialisation Phase

107

Management

Department A

Department B

Department C

Employee A1 40%

Employee B1

Employee C1

Employee A2

Employee B2

Employee C2 80%

Employee A3

Employee B3 60%

Employee C3

Project Manager

Project Team Employee A1 60% Project Team Employee C2 20% Project Team Employee B3 40%

Authority

Organisation

Project

Fig. 2.31 Matrix project organisation

participants. Therefore, it is very conflict-prone and requires a high degree of communication, especially for regulations and agreements. The advantages and disadvantages of the matrix project organisation are shown in Table 2.21. The matrix project organisation is by far the most common organisational form in the practice of traditional project management. Many companies, with regard to limited resources, have almost no other choice. Because of the dependencies and Table 2.21 Advantages and disadvantages of the matrix project organisation Matrix project organisation

Advantages • Project manager and team feel responsible for the project • Clear responsibility and decisionmaking authority with the project manager • Flexible staff deployment, no workload problems • Continuity of professional development, no loss of contact with the line • Targeted coordination of different interests • Promoting a holistic, interdisciplinary approach

Disadvantages • Danger of conflicts of competence between lines and project authority • Insecurity of managers due to waiver of exclusivity • Insecurity of employees as “servants of two masters” • High demands on information and communication readiness

108

2 Methodology

contradictions that arise from the hierarchically oriented line organisation, on the one hand, and from the team culture of the project organisation, on the other, this is probably the most delicate and demanding form in terms of organisational psychology. It only works sensibly when: • The tasks and competences are clearly regulated, analogous to a right-of-way regulation at intersections, • The line uses capacity planning to optimally coordinate the employee’s use of resources in line work and in project work, • Problems and conflicts are addressed and discussed at the right hierarchical level, i.e. if the conflict culture is sufficiently developed; if this is not the case, the conflicts are delegated to the system, • The business units want to work together and do not compete over the project.

2.3.8.9 The Competence Regulation RACI Matrix Many conflicts and misunderstandings arise from unclear or differently understood responsibilities. The RACI Matrix is a method for recording responsibilities completely and without overlaps and visualising them in the form of a table. All work packages or tasks are listed in the rows; the different project roles are listed in the columns. The RACI matrix answers the following three questions for a project: • Which work packages need to be completed? • Which project roles are involved? • Who is responsible for what? In the fields, the four responsibilities R, A, C, I are entered according to Table 2.22. Table 2.23 shows an example of a RACI matrix. Several variants of RACI exist, such as RASCI, which describes the additional responsibility of “support”, or RACIQ, which includes the responsibility of “quality Table 2.22 RACI responsibilities RACI code R Responsible A

Accountable

C

Consulted

I

Informed

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

2.3 Initialisation Phase

109

Table 2.23 Example of a RACI matrix

Work package Draw up the project order Create proof of concept Develop prototype Produce prototype Create a marketing concept Build a support organisation

Project owner A

Project committee I

Project manager R

Subproject R+D C

Sub-project production C

Sub-project marketing C

A

I

R

C

I

A

R

C

A

R

I

A

I

C

A

I

C

I R

R

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

110

2 Methodology

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

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

2.3 Initialisation Phase

111

• In projects with strongly diverging interests, the degree of participation of the stakeholders will be greater and thus the project organisation will be more extensive. Nevertheless, it is advisable to keep the project organisation as lean as possible. Broad participation can also be achieved with support groups, special workshops for stakeholders and users, possibly with a large group event. • Pay attention to defined roles, avoid multiple roles! Strive for separation of powers between the bodies. • Do not leave the appointment of project members to chance. In addition to assigning participants for the committees, also determine how to nominate managers, project owners or project managers in order to achieve broad stakeholder support. • Project members should have the necessary resources at their disposal. Overloaded project members are not motivated or feel forced to set their own priorities according to their interests. • In the course of the project, the project organisation may change from phase to phase. Within a phase, the organisation should be kept as constant as possible in order not to interrupt the team processes. • It is better to have fewer projects with professionally excellent and motivated people. Management must also be able to commit to the project.

2.3.9

Information Gathering and Situation Analysis

One of the focal points in the initialisation phase is the critical examination of the real project objective. This can differ in several respects from the superficial objectives: • The project order, the framework conditions, or the objectives are unclear and/or incomplete. • The project owner may have set an incomplete objective based on his perception. • Conflicts of interest and power relations between different stakeholders may have led to an unclear objective. • The project order first requires the identification and analysis of a symptom. Only with the results of the analysis can the actual objective formulation take place. Example: “For 3 months we have been receiving increased amounts of returns from the market. Find the problem and fix the root cause!” In project work, not everything is clear from the start. That is why it is worthwhile to first switch to fact finding mode, carry out a situation analysis, and gather information. The situation analysis serves to clarify the problem situation, the relevant problem environment in the sense of clarifying the task and assessing the situation, and to narrow down the problem. The state of affairs is reviewed at each milestone and can be repeated or supplemented for partial aspects as needed. Depending on the problem and the available knowledge, a situation analysis can be carried out “ad hoc” in a few hours, or it may in other cases require detailed clarifications by several

112

2 Methodology

Table 2.24 Elements of the situation analysis Task Order clarification

Analysis of the present

Inclusion of the future

Instruments and issues to be addressed • What is the reason for doing something? • What is it really about? • Is the project order complete? • Do the project owner and the project team have the same understanding of the assignment? (Sect. 2.3.11) • Context analysis • Stakeholder analysis (Sect. 2.3.5) • SWOT analysis • Cause–effect analysis • Analysis of the legal basis and compliance specifications • Information security and protection need analysis • Planning horizon • Scenario technique

people, possibly over a period of months. This is typical in product development and investment projects and carries with it the danger of driving the analysis to paralysis. A complete situation analysis includes at least the aspects according to Table 2.24.

2.3.9.1 Context Analysis In practice, context analysis is used in two different cases: • Environment or environmental analysis • Method for recording the tasks of users The environment and environmental analysis have a certain correspondence with the stakeholder analysis. The following three perspectives are relevant: • Temporal: What happened before the project? What did the world look like before the project? What should happen after the project is finished? What does the world look like after the project? • Factual: Which factual influencing factors, framework conditions, and trends are relevant for the project? • Social: Which persons or groups of persons have an interest in the project? Who influences the project or is affected by the project? (Sect. 2.3.5) The recording of users’ tasks also includes the processes involved and can be done through various forms of work such as user interviews, questionnaires, online recording, etc. The following questions need to be examined in more detail: • • • •

Where do users perform their tasks? What do they do under which circumstances? How do they fulfil their tasks? Why do they do it this way?

2.3 Initialisation Phase

113

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

Table 2.25 Questions for the SWOT analysis

Viewing level Strengths

Weaknesses

Opportunities

Threats

Possible questions • What is going well? • What can we rely on? • What satisfies us? • Where do we get energy from? • What are we proud of? • What do we want to keep? • What is unsatisfactory? • Which disturbances hinder us? • What are we missing? • What is difficult for us? • Where are our traps? • What opportunities are opening up for us? • Which market segments will boom? • What can we use in the environment? • What is undeveloped? • What is expandable? • Where do the dangers lurk? • What difficulties are we facing? • What should we expect? • What are our fears?

114

2 Methodology

Table 2.26 Dealing with the dimensions of the SWOT analysis SWOT • Internal aspects • Today’s situation • Impressionable • External influences and trends • Future situation • Hardly influenceable

Positive Strengths → Maintain or expand

Negative Weaknesses → Eliminate or reduce

Opportunities → Use or expand

Threats → Evaluate and develop alternatives

Strengths

Weaknesses

S-T Strategy S-O Strategy

Opportunities

W-O Strategy W-T Strategy

Threats

Fig. 2.32 SWOT strategies

identify opportunities and threats, and so the upper and lower halves in Table 2.26 are mixed: Strengths are often interpreted as opportunities and weaknesses as threats. In Fig. 2.32 possible SWOT strategies are presented in the four analysis dimensions. In order to concretise the strategies, the following questions can be asked, as shown in Table 2.27.

2.3 Initialisation Phase

115

Table 2.27 Questions for the concretisation of the SWOT strategies Strategy S-O strategy S-T Strategy W-O Strategy W-T Strategy

Question What opportunities could be exploited, e.g. by expanding the current strengths? Which threats can be eliminated or reduced with the current strengths? What opportunities would arise if the current weaknesses were eliminated? What threats could be reduced or eliminated if the current weaknesses were eliminated?

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

Men (1st order cause)

Methods (1st order cause)

Machines (1st order cause)

«Too much waste» (Clearly formulated effect)

Process axis Cools down too quickly (2nd order cause) Causes of lower order

Material (1st order cause)

Fig. 2.33 Cause–effect analysis

Milieu (1st order cause)

Management (1st order cause)

116

2 Methodology

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

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

Legislation (laws, regulations) Compliance and governance Regulations for safety, health, and environmental protection (SHE) Rules of conduct and professional regulations Principles and objectives of sustainability Standards and norms

After the analysis, the impacts and consequences for the project are to be assessed and derived. During the implementation of the project, ensure that the identified and relevant framework conditions are adhered to.

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

2.3 Initialisation Phase

117

measures to protect confidentiality and integrity can be, for example, encryption of data during storage or an authorisation system for access to applications or data.

2.3.9.6 Planning Horizon A changed environment can significantly influence the project objectives and the subsequent benefits of a product. The more pronounced the influencing factors change, the greater the effect on the project, and the greater the time periods, the more pronounced the change can be. The goal-setting process has to therefore be directed at the planning horizon, as Fig. 2.34 shows. 2.3.9.7 Scenario Technique Scenarios are alternative representations of the future and help to identify possible project courses at an early stage and to assess their effects. The scenario technique is particularly helpful in situations that have major consequences when they occur and that allow only short reaction times. Scenario techniques are used to develop and prepare “if-then” options. Both the impact strength of individual actions on one’s own organisation and the forecasting reliability in predicting these actions are examined. The higher an expected action tends to be with regard to both dimensions, the more attention is needed, as reaction time and costs or investments play an enormous role. If the uncertainty is reduced to two

Environment today

Environment at the end of the project

Environment at planning horizon

Project tasks at project start

Product at the end of the project

Product at planning horizon

Determining for successful product introduction

Determining for successful usage of the product

Determining for solution finding

Fig. 2.34 Consideration of factors influencing the future

118

2 Methodology

alternatives with very different costs, both scenarios are recorded as alternatives in planning. Imagine a customer wants a high-precision machine that you have never produced before with such a low tolerance. Your engineers have determined in a feasibility analysis that you could achieve the required precision with your current production methods and some additional work “with a bit of luck”. How much additional work will be necessary cannot be estimated from the outset. If it turns out that the goal is not achievable with the methods you know, a new process will have to be devised with an effort of eight person-months. In addition, a clean room for the new process must then be obtained, which requires investments of 600k €. Both scenarios are planned for in advance. A milestone is set by which the decision has to be made to discontinue the first of these alternatives (deadline). The project management may also decide to implement both alternatives in parallel. If the existing procedure proves unsuitable after, say, 3 months, the new procedure is ready for implementation only 5 months later. The price for this speed lies in the costs and tied-up resources for the second team and in any investments in initial cleanroom components.

2.3.10 Project Structuring The planning and therefore also the structuring of projects is carried out very differently depending on the situation. In distinct standard projects with a great deal of experience in the company, the structure is already provided in specification documents and is also enforced for the purpose of a uniform procedure. In smaller projects or potential projects with a high degree of openness to objectives, e.g. in basic research or if the detailed specifications have not yet been bindingly defined, only basic structures are set, e.g. different teams are put together. Project structuring, also called rough planning, is about clearly structuring projects according to their size and complexity and thus making them manageable in the first place. The project is structured in two dimensions, as shown in Fig. 2.35:

Goals Requirement Specification

Fig. 2.35 Project structuring

Project structuring

Concepts Technical Specification

2.3 Initialisation Phase

119

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

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

System / Project Level

2.3.10.2 Setting Milestones in the Project: The Phase Plan The phase plan (also called milestone plan), as shown in Fig. 2.36 roughly depicts the chronological sequence of the project and is intended to clarify the following questions:

Review Project Idea

Ideas

Review User Review Design Requirements Specifications Goals

System Design Freeze

Design Phase

Study Phase

Utilisation Phase

Sub-Project Level

System Integrations Review Design Input Development Phase

Review Design Output (Design Freeze)

System Release

Review Design Transfer

Pre Production

Fig. 2.36 Practical example Metrohm: Milestone plan

Series Production

Market Release

120

2 Methodology

• Into which phases should the project be divided in terms of time? • Which milestones, documents, and results must be achieved and checked at the milestones between the phases? • Which deliverables and work packages are processed in which phase? • At which milestone is a review necessary? According to Which Criteria Is a Project Divided into Phases? It would be risky to carry out a large project in one go and to only make a check-up at the end whether the intended goal has been achieved. That is why large projects are divided into individual phases with verifiable interim results, the milestones. The project manager thinks about what work has to be done in which phase or for what eventuality a concept has to be created in which phase, which then gets decided on at the milestone. It is also necessary to further subdivide a project or a project phase if the later discovery of a mistake, a wrong direction taken or an inadequate attitude would lead to disproportionately sizeable consequences. It does make sense to set a prearranged point in time with a further milestone at which what has been achieved is reviewed and the further course of action is determined. For a small, unproblematic project with a high routine factor, two phases may be sufficient: an initialisation and concept phase and an implementation phase. For larger projects or greater uncertainty in the project, more phases and milestones at the critical points in time make sense. Figure 2.37 shows milestone plans for simple and complex projects.

0

0

0

Definition and design phase

Commissioning

Feasibility study

1

1

1

Initialisation

Specification WHAT

2

2

Concept

Rough concept HOW

3

3

Realisation

Detailed concepts

4

4

Introduction

Realisation

5

5

Realisation phase 2

Integration / Test 6

Pilot series 7

Series adjustments Milestone

Fig. 2.37 Milestone plans for simple and more complex projects

8

2.3 Initialisation Phase

121

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

Are there new risks to be identified or existing ones to be re-qualified? Are the earlier assumptions still correct? Do the general conditions still apply? Does the chosen approach still make sense? Often the project owner requires such a critical review before signing off on the next phase and thus releasing the necessary funds. The project manager and the project owner agree on where a review is necessary.

In certain companies with standard project processes, the review and the timing of this review may be predetermined. Terms such as quality gates or milestone review are used to describe this activity.

2.3.10.3 Projects, Sub-projects, Work Packages, Deliverables, and Activities There is a hierarchy within and between the overall project, the sub-projects, the work packages, and the deliverables, as shown in Fig. 2.38. Sub-projects For small to medium-sized projects, project management is the responsibility of a single person. If, in the case of very large or very complex projects, the management span becomes too large for just one project manager, it makes sense to then manage sub-projects and divide up the project management activities (planning, control and steering of the process) between two or more people. The price for this is the necessity of additional agreements and of a coordination between the sub-project managers and the overall project manager. It only makes sense to form sub-projects if the advantages (manageability, independence) outweigh the disadvantages. Merely dividing the content into work packages or activities is not sufficient reason for introducing sub-projects. The overall project manager and the sub-project manager have to agree on the interfaces between the sub-projects and define continuous milestones at which decisions are made for the entire project. On the occasion of a milestone, all sub-projects have to have the corresponding basis for decision-making so that a go/no-go decision can be made for the entire project.

122

2 Methodology

Project Subproject 1

Subproject Manager Project Manager

Work package 1 Deliverable Activity

Work package 2 Deliverable Activity

Subproject 2

Subproject Manager Work package 3 Deliverable Activity

Fig. 2.38 Hierarchies in the project

Work Packages The project as a whole is divided into clearly structured activities or tasks, with simple interfaces and a technical allocation of the task holders, so that a clear assignment of responsibilities is possible. Throughout the different phases of the project, it has to be warranted that there is a clear demarcation and continuous responsibility of the task bearers. The project should be presented in its entirety. A work package is the totality of several deliverables and activities that are to be selfcontained in order to get a verifiable result or outcome. A work package manager is designated for each work package. Work packages can be put together in two ways: Top-down: the whole project is broken down step by step into smaller units with a sensible delineation of work packages. This requires experience with similar projects and a good overview of the project. Bottom-up: If little experience is available, this procedure is chosen. All activities that come to mind are collected in the team. Then group related activities into deliverables and work packages. Finally, check whether the listed activities are complete. In large or complex projects, a work package description is created for each work package. This provides information about prerequisites (input), activities that are carried out with this work package, results (deliverables, output), the effort required for this work package, the people responsible, and the general conditions.

2.3 Initialisation Phase

123

“Prerequisites” section lists in keywords the information or documents that need to be available before the work can be started. Figure 2.39 shows an example of a work package description from the BLS practical example.

T-TA

Designation Context / initial situation

Goal / Description

Work package description

Test concept project sales back-end In the Sales-Bach-End project, standard components (e.g. timetable) are purchased from the market and substantial parts are developed in-house. The realised system must be systematically checked and tested before going live. Creation of a test concept for the Sales-Bach-End project as a basis for setting up the necessary test organisation and test infrastructure.

Client

Mike

Contractor

Bruno, Thomas

Total effort [h]

80 h

External costs

No external costs

Start date

1 December 2022

Deadline

31 January 2023

Dependencies

None The general requirements for BLS projects regarding testing must be taken into account. The test concept describes the test objectives, test objects, test types, test infrastructure and the test organisation of the project. It also includes the test planning and a definition of the test scope, as test case descriptions or as a reference to the test cases in an external test tool. A detailed test case specification is created for each test case. The test planning defines the logical and temporal sequence of the tests. The test concept forms the basis on which the test organisation and the test infrastructure are provided and the tests are carried out. Mike, Irina

Input, prerequisites Result

Acceptance of the results Degree of target achievement

Content Approval Job

Good (at least 80%): ƒ Test concept contains all elements as described in the result ƒ The BLS specific specifications are complied with. ƒ The test concept has been approved and the findings have been incorporated. Very good (100%): ƒ How good, in addition, the test concept is considered best practice in the BLS project community. Date

Signature

Assessment after completion Job Date

Signature

Client Mike

Client Mike Comment

Fig. 2.39 Practical example BLS: Example of a work package description

124

2 Methodology

Deliverables The Deliverables are the results that are to be delivered by the project, such as a product, a service, or a concept. The success of the project is measured by the deliverables. • Deliverables are part of a work package. • Depending on the size of the project, deliverables and work packages are merged and not differentiated. • Project objectives, or more precisely, system objectives and deliverables are linked to show the connections and interrelationships. Activities and Tasks The activity (also called task) is the indivisible unit in project planning. While a team or a department can be responsible for a work package, an activity should be assigned to exactly one person. The granularity of the activities, i.e. the intellectual and temporal scope, also depends in particular on the experience of the person carrying out the task.

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

2.3 Initialisation Phase

125

Vacuum cleaner structured according to modules

Mechanical system

Electrical system

Housing and assembly

Small impeller

Motor

Support plate

Big impeller

Power switch

Housing base

Filter holder

Power cable

Filter cover

Filter element

Overload protection

Operating flap

Fine filter

Control

Air hose

Flap valve

Operating elements

Nozzles

Cable drum

Filter holder

Sealing

Dividing wall

Sound isolation

Fig. 2.40 Example of an object-oriented WBS structure

Vacuum cleaner structured according to activities

Technology

Production

Marketing

Alternative solutions

New production processes

Market analysis

Wooden model

Subcontracting agreement

Customer survey

Fluid dynamics

Expansion of inspection

Specifications

Rough draft

Prototype production

Pricing

Detailed development

pilot series

Distribution network

Energy optimization

Series adjustements

Exhibition

Prototype testing

Serial production

Marketing campaign

Qualification EMC testing

Fig. 2.41 Example of a process-oriented WBS structure

Introduction program

126

2 Methodology

Project Organisation

Lab Logic Service

Samples

Equipment

Processes

Bottle top

Liquid Adapter

Power Supply

Magnetic stirrer

Measuring system

Mainboard

Dosing system

OMNIS Software

Bottle Cap

Titrator

Mainboard

Power Supply

Gripper Module

Rack

Main module

Pick & Place Modul

Pump modul

Sample Robot Pick & Place

Fig. 2.42 Practical example Metrohm: Work breakdown structure

Phase

Subproject Subproject 1 Technology TPL 1 : Developer nn

Subproject 2 Production TPL 2 : Production assistant

Subproject 3 Marketing TPL 3 : Head of marketing

MS 0

Decision on specification and product development

Development

Development tests Construction prototype Make a prototype Test the prototype Adjust documents

MS 1

Decision on pilot series

Transfer to production

Pilot series documents Test pilot series Small adjustments

MS 2

Decision on serial production and market introduction

Launch

Documentation adjustments

MS 3

Decision on further projects

Preliminary clarification for production Consulting construction Production planning Preliminary costing

Advertising concept Service concept Sales concept Contract negotiations Economics

Procurement of production means Produce pilot series Optimise production

Optimise production Service and sales organisation Field test pilot series

Optimise serial production

Marketing campaign

Fig. 2.43 Example of a mixture of phases and work breakdown structure

2.3 Initialisation Phase

127

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

Objectives Scope of the project (Scope) and results

Delimitations

Dependencies and influences

Framework conditions Basics

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

128

2 Methodology

Table 2.28 (continued) Project costs, benefits

Risks

Procedure, schedule

Project organisation

Information, communication

Signatures

Appendix

• How big will the effort for the project be? • Are the required financial and human resources budgeted? • Which cost centre will the planned project costs be charged to? • What quantifiable/non-quantifiable benefits or advantages result from the implementation of the project? • What risks are present or discernible from today’s perspective? • What measures can be taken to reduce them? • What are the consequences of non-realisation? • Project structure and project plan with milestones • When is the project finished? • Notes on special procedures • Project owner • Contractor (Project manager) • Project team(s), possibly staffs • Supervisory bodies (e.g. project committee) • Escalation path This describes the flow of information or communication with the project owner, the supervisory bodies, the user, and other interested parties. Reporting can take place in writing or orally. The creator and recipient of documents as well as the periodicity should be clearly recognisable: • Progress report (status report) • Project plan • To-Do and Decision Lists • Project Newsflash • Project owner • Project manager • Controlling (for major projects) • Decision-making bodies according to financial competence • Project plan • Project organisation • Detailing “economic efficiency” • Resource plan • Planned expenditure

project. In other cases, only the next phase is planned in detail, the remaining phases only roughly.

2.3.12 Project Manual, Project Management Plan The project management manual (Sect. 2.7.5) regulates how project management is applied throughout the company and how it applies to all projects. The project manual is the specific adaptation for a project. It has to be adapted to the specific situation of each project. The project manual or project management plan depicts the most important process regulations such as agreements, plans, structures, organisational charts, and rules of the game of the project. Possible contents of the project manual are shown in Table 2.29. The project manual is intended to create

2.3 Initialisation Phase Table 2.29 Possible content or structure of a project manual

129

Project order and performance planning

Project environment

Project organisation

Project planning

Controlling

Information, communication

• Project order, project agreement • Structure: Project phases, work breakdown structure • Interfaces in the project • Decision-making process • Environment analysis, stakeholder groups • Embedding in the corporate strategy • Organigram • Description of roles, tasks, and competences • Contact persons and addresses • Rules of cooperation, escalation procedures • Scheduling • Resource planning • Cost planning • Quality assurance, test plan • Risk management • Control and steering • Measures in case of deviations, change management • Information and communication concept • Meeting planning • Meeting and workshop minutes • Progress reports (possibly under controlling) • Filing structures, document management

transparency and commitment for all participants. It is kept up to date from the beginning. The updated version is made available to the entire project organisation.

2.3.13 Kick-Off The Way a Project Began is How it Usually Ends With regard to the management of a project, the beginning of a project needs to be given the utmost attention. The formation and establishment of the project organisation is an essential part of this. In order to lay a good foundation in the project organisation, the design and implementation of a kick-off is of central importance. Depending on the type of project and the timing of team members, several kick-offs take place at different times. The kick-off meeting is the official start of the project. It is not only about contentrelated or organisational issues, but also in particular about building up or expanding the relationships of the project team that has just been put together (see also Sect. 1.5). The checklist according to Table 2.30 should help to plan the kick-off comprehensively. It is quite possible that several kick-offs are held in the course of a project.

130

2 Methodology

Table 2.30 Checklist: Objectives of the kick-off Content level

Relationship level

Organisational level

• The product vision, the benefits to be realised, and the background of the project are presented. • The current project status or assignment is discussed • The intentions and objectives are explained • The team members have a common understanding of the tasks • The interrelationships of the individual task areas are explained • All team members get to know each other • Rules of the game are defined and adopted by the team • Identification (sense of togetherness) with the project and project team (through insight into the meaning of the project, highlighting the special characteristics of this team) • Informal platforms are available which enable an interpersonal exchange of opinions • The methodological procedure is outlined • Project planning already in existence or release planning is presented • Possible problem areas of the project have been addressed and the team members responsible for solving them have been identified. • The project organisation is shown, the resources of the individual members are known • The communication and decision-making channels are defined • The tasks, responsibilities, and competences are assigned to individual team members or groups • The meeting rhythm and the taking of minutes are fixed

These kick-offs may take place with different participants or at different points on the timeline. Procedure of a Kick-Off Table 2.31 shows a possible sequence of a very comprehensive kick-off. A kick-off can also be shorter. The authors of the book recommend not to simply hold information events, because it makes sense to start working on the topics together.

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

2.3 Initialisation Phase

131

Table 2.31 Example “Kick-off” Time 08:00

Topic Arrival of the people, coffee

08:30

Start, welcome by project manager, introduce kick-off procedure (with times), project manager briefly introduces himself/herself Introduce project, explain brief overall history and global goal Introductions of project staff, discuss personal connections to the project: What do I personally expect from my involvement in the project? Inform about the project status or create it together Prepare stakeholder analysis, identify system boundaries

08:45 08:55

09:25 09:40

10:00 10:20

Break Showing the field of forces of the project

10:40

Derive already identified problem areas

11:00

Show the organisation of the project with regard to cooperation and project sequence (deliverables and work packages) Regulating cooperation, meeting interval, document management and minutes Discuss and determine next steps Each person briefly comments on the further process, their role and function and the planning Closing words from the project manager or project owner End of the kick-off

11:10 11:20 11:30

11:55 12:00

Objective Informal reunion or getting to know each other Punctual start, orientation to the meeting, transparency, building trust

Create information level, introduce project objective Get to know each other, establish a relationship with the project, discuss wishes, expectations, fears and related project experiences, initiate networking. Information Recognise environment and dependencies, identify people’s attitudes towards it Informal exchange Knowing which forces promote the project, which hinder it Situation analysis, data on risk considerations Set up the project organisationally, identify bottlenecks, regulate fixed deadlines, show scope for action Determine communication, rules of the game Create a clear work plan Recognise commitment and resistance, create commitment Appreciate and show importance

solutions. However, most of the time important details get overlooked and hence solutions are adopted that were suitable in the past, without taking into account the currently changed situation. This situation, which is often encountered in practice, is called the “solution trap” or “jumping to solution”, as Fig. 2.45 shown. A structured approach is worthwhile for projects that enter new territory. The problem-solving process is run through in each project phase. The emphasis on the individual steps of the problem-solving process shifts in the course of the project: while in the initial phase the focus is on the situation analysis and the formulation of objectives, in later phases it will be on the search for or evaluation of solutions and the decision. The level of detail also increases from phase to phase.

132

2 Methodology

Monitoring

Situation analysis

Did I forget or overlook something in the planning?

What exactly is it about? Strengths / Weaknesses Opportunities / Threats Causes / Effects

6

1

5 Implementation

Problem-solving process

Plan, who can do the work or whether I can delegate it

Formulation of goals 2

4

Goal criteria > SMART Must / desired goals Procedural goals System goals

Find a suitable solution 3

Solution with best benefit, best achievement of goals

Search for alternative solutions Thinking in alternatives

Fig. 2.44 The problem-solving process

Experience Automatism Pattern behavior

Monitoring

6

1

Situation analysis

jumping to solution Implementation

5

Find a suitable solution

Fig. 2.45 The solution trap

2

4

3

Formulation of goals

Search for alternative solutions

2.3 Initialisation Phase

133

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

Lean, Six Sigma (DMAIC, DMAEC) • Improvement • Optimisation of a business process

Deming circle (PDCA circle), Shewhart cycle, continuous improvement process The sprint cycle in the agile approach scrum corresponds completely to the PDCA cycle

Appreciative inquiry See also Sect. 2.8.2.9 Appreciative questioning in team and organisational development

• Understanding: Design Challenge • Observe: User-Centred Design • Define point of view: Synthesis via Persona • Finding ideas: Customer-oriented solutions, thinking in variants • Develop prototype: Iterative approach • Testing: early feedback loops • Define: what customer needs should the process meet? • Measure: expression of the performance characteristics of the process • Analysis: Identify causes of deviation from defined performance objectives • Improve, engineer: seek possible solutions to identified problems, set evaluation criteria • Control: Introduce and monitor improvements and new procedures • Plan: analyse current status, identify potential for improvement, plan measures, sprint planning • Do (implement): implement, try out, test on a small scale, sprint implementation • Check: Check results with regard to effectiveness, sprint review • Act (improve): introduce as a standard across the board or identify improvement actions, sprint retrospective. • Discovery: discovery phase, recognising and understanding • Dream: Vision design, dream of the best solution • Design: Future design, develop a vision, take a decision • Destiny, Delivery: implementation phase, determining what will happen, implementing new ideas

134

2 Methodology

2.3.15 Checklist Completion Initialisation Phase

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

2.4 Concept Phase

• • • • • • • • • • • • • •

135

Were the future users involved in the formulation of the requirements? What does the project organisation look like? Have the competences and responsibilities been agreed upon? Are clear and sufficient decision-making competences and corresponding leadership responsibilities assigned to the project management? Is adequate interdisciplinary representation and expertise ensured in the project team? Are active users and stakeholders involved in such a way that the highest possible acceptance can be achieved? Are the resources available? Has a work breakdown structure been drawn up? Has the division into sub-projects been correctly made or planned? Have critical decisions been scheduled? By when can the results or interim results be expected? What is the planning for the project? What is the estimated effort in person-days, how much money is to be invested over the entire duration of the project? Are the effort, deadlines, necessary knowledge, and availability of key personnel checked and realistically aligned to the new findings? Which bottleneck resources are needed in which time period? Are any estimates (quantities, frequencies, milestones, costs, times) realistic? Is the accuracy of the estimate indicated? Are the specialists, necessary means, and resources available at the right time? Specific points of the agile approach:

• Who is the product owner, scrum master, and who are the developers? • Is the product owner well anchored in the line organisation and does he or she have direct access to relevant decision-makers? • Are the resources available?

2.4

Concept Phase

In the agile approach, the concept phase focuses on the development of the product concept (product goal) and the requirement catalogue (product backlog). Planning takes place in a less concrete form than in the traditional approach. As a part of this planning process, a release plan is drawn up. The concept phase should be much shorter in the agile approach than in the traditional approach. The work in the agile project begins with this phase. In the traditional approach, during the concept phase, solution variants are developed and evaluated. Plans are drawn up for the selected variant, ready for implementation, and solution concepts as well as the technical specifications are

136

2 Methodology

drawn up. The needs of all interest groups must be reconciled as far as possible. In doing so, it is important to be aware of one’s own habits. In large projects, the “concept” phase can be divided into the main project and the detailed project. The division creates another milestone. This avoids the project team getting bogged down in rough terrain. At each milestone, the project owner decides which variant to pursue. He also releases the funds for the next phase.

2.4.1

What Is Important in the Concept Phase?

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

What should be paid particular attention to in the concept phase?

Agile approach • Develop the idea by means of a product concept (product goal) and, if necessary, visualise it by means of a simple model • Start building the requirements catalogue (product backlog) • Prioritise and estimate the entries in the product backlog and derive a release plan from them • Establish and ensure information and communication • Establish documentation/ ticketing system

Based on the rough project planning by means of the release plan, the planning in the realisation phase is concretised on the occasion of the sprint planning and the daily stand-up meetings

Traditional approach • Further specify and revise the requirements as needed • Develop solution variants (culmination of creativity in this phase) and check them for conformity with the goal • Evaluate solution variants, have one variant selected by the project owner • Develop the solution concept (specifications) for the selected variant. • Review and adjust means and resource needs • Detailed planning: scheduling and resource planning • Establish and ensure information and communication • Establish documentation system • Based on the requirements, a solution variant has to be found in the concept phase and this needs to be worked out in detail by means of a solution concept • The detailed plan for the rest of the project developed in this phase serves as the basis for progress monitoring in the further course of the project

2.4 Concept Phase

137

Table 2.34 Results of the concept phase Principle Questions to be answered Processoriented results

Contentoriented results

Agile approach In the agile approach, asking “what” is central • What should be implemented, what is the vision? • What added value is to be realised? • Updated project order (if necessary) • Release schedule • Project documentation and ticketing system • Phase report • Product concept (product objective) • First version of the product backlog (requirements catalogue)

Traditional approach In the traditional approach, the focus lies on asking “how” • Which solution variant should be selected? • What is the chosen solution? • How should the chosen solution be implemented? • Updated project order (if necessary) • Information and communication concept • Detailed plans for the realisation according to the traditional approach • Project documentation system • Phase report • Solution variants are developed • A variant with plans ready for implementation is selected • The specific solution is elaborated in detail with the necessary concepts (functional specification) (The way of solution conception differs greatly within sectors and project types)

Results of the Concept Phase Communication with stakeholders needs special attention in order to achieve trust, identification, and support. Important instruments for this are: the information and communication concept and project marketing. In the concept phase, the results according to Table 2.34 are of importance. Phase Report In some organisations it is common to produce a phase report at the end of a phase. The phase report gives a brief overview of the results and outcomes achieved. This document contains the evaluation or summary of the concept phase and forms the basis for the next phase: • Initial situation: prerequisites, assumptions, problems encountered, consequences • Achieved results and outcomes • A critical review of the process during this phase is of great value: what does the team learn from it for the next phase? • Objectives, newly identified framework conditions • Solution, solution variants • Impacts on stakeholders, e.g. customers, owners, personnel • Benefits and updated economic efficiency calculation, in particular changes compared to initialisation • Updated project organisation

138

2 Methodology

• Overall planning of the project, planning of the next phase, financial management incl. funding requirements for human resources and material resources • Risks • Motion: Solution and further procedure Upon reaching the milestone “Conclusion of the concept phase”, the solution variant to be implemented gets defined formally and the further procedure is made known. People and Team Various aspects from the competence areas of people and team (see Chaps. 3 and 5) may be relevant in this phase of the project. However, they may also occur at a later stage or not at all. With the signed project order the concept phase begins. In the agile approach, the effective project work at this stage begins with the development of the product vision (product concept, product goal). In the traditional approach, substantial and demanding conceptual work must now be done. The team is often changed during this phase: New people join because more capacities are needed. This changes the social structure of the project team. Therefore, initialisation measures often have to be repeated. The following topics are important now: • Work on the system (Sect. 1.5.2): With the official project order, the cooperation in the team must be formalised. • Versatility and creativity (Sect. 1.7): As in the commissioning process, high attention should be paid to variant thinking and creative approaches to solutions in the initialisation process. • Dynamics in teams (Sect. 5.2): In response to a possible “storming” it is important to further clarify and possibly adjust the roles in the project through “norming”. • Self-management (Sect. 3.8): The intensity of the work now also places greater demands on individual project participants in terms of their self-management and behaviour in relation to stress and change (Sect. 3.5). • Motivation and meaning (Sect. 3.7): How well do you succeed in communicating the meaning and benefits of the project to the team? This has a strong influence on intrinsic motivation. • Connection of the project to the line (Sect. 2.3.8.8): The way in which a project is integrated into the line has a significant influence on the decision-making competences and the management style of those responsible for the project. • Concretisation of the leadership approach (Sect. 4.4) and the necessary power and authority (Sect. 4.9). • Project culture, multicultural cooperation (Sect.5.4), and possibly also aspects of virtual cooperation.

2.4 Concept Phase

2.4.2

139

Product Goal (Product Concept)

It all starts with the idea. With the creation of the product goal (also product concept or product vision) in the agile approach, this idea is concretised. The product goal describes the benefits for the future user of the product or service and the essential performance features. The product objective should be deliberately formulated in concise way. This puts the focus on the essentials. It is advisable to visualise the product goal with the help of a physical model, as shown in Fig. 2.46 on the practical example of BLS. The product objective and the model define the vision for the project. This is a simple way of efficiently picking up stakeholders at different management levels in order to win them over for the project. The product objective describes the following topics: • • • •

Needs of users, customers Benefit or added value for users, customers Key features and functions Target figures

Fig. 2.46 Practical example BLS: A simple model for visualising the product idea

140

2 Methodology

The product goal is defined by the product owner together with the scrum team and stakeholders such as users, customers, marketing, market research, product management, sales, manufacturing. The product goal forms the basis for the efficient creation of the product backlog and stands for commitment to the artefact product backlog.

2.4.3

Product Backlog

Ken Schwaber and Jeff Sutherland define the product backlog in the scrum Guide in the following way: The product backlog is an emergent, ordered list of things needed to improve the product. It is the only source of work done by the scrum team. Product backlog entries that can be completed (Done) by the scrum team within a sprint are considered ready for selection in a sprint planning event. They usually achieve this level of transparency through refinement activities. Refinement of the product backlog is the process by which product backlog entries are broken down into smaller, more precise elements and further defined. This is an on-going activity, adding more details as, for instance, description, order, and size. The attributes often vary depending on the working environment. The developers who will do the work are responsible for sizing implementation. The product owner can influence the developers by helping them to understand the product backlog entries and make trade-offs. (Schwaber & Sutherland, 2020, p. 11/ 12). The statements can be summarised as follows: • • • • • •

The product backlog is the source of the requirements The product backlog is dynamic and never complete or free of contradictions The product owner is responsible for the product backlog The entries are prioritised (ordered) The entries have different levels of detail The entries are estimated in terms of their effort

The product backlog is a list and can be set up as a table in all commercially available tools. In the initial phase, it is also advisable to visualise it with slips of paper on a wall, as Fig. 2.47 shows. A product backlog can also be structured by focus topics. A focal topic is often referred to as an epic. Each focus topic (epic) is divided into several features and enablers in a subsequent step, if required. Features are business functionalities for users. Enablers are technical prerequisites or foundations for the implementation of features. Features and enablers are divided into several user stories. It should be possible to implement several user stories in one sprint. It is advisable to define acceptance criteria for the epics, features, enablers, and user stories. (Definition of Done) for the epics, features, enablers, and user stories.

2.4 Concept Phase

141

Fig. 2.47 Practical example BLS: Initial Product backlog BLS

Key

Summary BLS Mobile App

Description For customers who buy public transport tickets from BLS, the BLS Mobile APP is their personal travel companion, allowing them to buy tickets, store subscription moments and call up timetables.

VBE-463 Timetable preferred I, as an end customer, would like to be able to find my preferred travel route at a time defined by me with as little interaction effort as possible. travel route Acceptance criteria: - Suggestion list for stations - Route finding without location - Target timetable data - Presentation of results in tabular form - Consistency of customer information with station displays and existing sector specifications. - cf. V580 The timetable server must support national queries in Switzerland (all means of transport and lines in Switzerland) and in the border area of Switzerland VBE-36 National timetable queries (according to GA validity area). All stops and connections provided by INFO+ shall be offered. VBE-329 Route finding without location

"I, as an end customer, would like to be able to find my way from a certain station to another certain station and, if necessary, define via stations.

Status Issue Type Open Epic Open

Feature

Closed Enabler Open

Story

Acceptance criteria * When entering station names (updated at each keystroke), possible values from the list of all UIC-code stations (Switzerland and near-border area according to INFO+ station list) are suggested * The sorting of station names is based on a statically defined weighting (basis of entry and exit numbers). * The autocompletion mechanism does not cause any additional server roundtrips, but takes place exclusively locally on the device. * It must be ensured that the application has an up-to-date list of stations. * The autocompletion mechanism allows stations to be found even with slight typing errors (no exact matching). * The searched part can be anywhere in the station name (e.g. ""mundigen"" in ""Ostermundigen"") * Via limitation to 5 stations * Via stations are collapsed by default and must be explicitly activated by the user * Reuse of autocompletion logic between mobile and online ticket shop

Fig. 2.48 Practical example BLS: Excerpt from product backlog

This makes it promptly recognisable for the scrum team when a user story, feature, enabler, or epic has been fulfilled for the product owner. The acceptance criteria also help with testing. Figure 2.48 shows an excerpt from the product backlog with one epic, feature, enabler, and user story each using BLS as a practical example. A product backlog does not need to be filled with as many requirements as possible at the beginning. This would actually even be counterproductive. It is advisable to keep the product backlog small at the beginning. It should contain the important requirements. The product backlog ought to contain enough requirements for at least two to three sprints. Good requirements (user stories) show the INVEST characteristics according to Table 2.35.

142

2 Methodology

Table 2.35 INVEST features for good requirements I

Independent

N

Negotiable

V

Valuable (useful) Estimatable

E S T

Small (small) Testable

2.4.4

Requirements should be as independent of each other as possible and have as few interdependencies as possible Negotiations can take place between the product owner and the project team regarding the order, modification, or reduction of requirements Requirements produce a demonstrable benefit The implementation of the requirements can be estimated by the team. This requires that the requirements are understood by the team The description of the requirement should be brief All entries in the product backlog are verifiable/can be tested. This requires the formulation of acceptance criteria for each entry

Release Plan

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

Table 2.36 Practical example BLS: Release plan BackEnd App Webshop

Sprint 4 Timetable Itinerary Ticket sales

Sprint 5 Administration VBE Payment

Sprint 6 After Sales Service Ticket control

Timetable Itinerary

Ticket sales

Payment

Sprint 7 Clearing After Sales Service Ticket control

2.4 Concept Phase

143

over the course of the project among the developers. The velocity is lower at the beginning of the project because: • • • • •

Knowledge must first be built up or deepened Teams must first grow together and find the optimal interaction Ideally, the requirements with a high risk are addressed first Infrastructure needed at the beginning must be built up first Obstacles are more likely to occur at the beginning

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

2.4.5

Requirements Specification: Solution Concept

The specifications result from the sum of all solution concepts and describe how the needed objectives and requirements are to be achieved.

144

2 Methodology

Table 2.37 Project objectives, requirements specification, and functional specification Term Project objectives Specifications Specifications

Explanation

Catalogue of requirements Sum of the solution concepts

Question What is the scope/the aim of the project? What can the product do? How is this achieved?

Responsible Project owner Requirements engineering Contractor, project team

If the objectives and requirements are formulated in a solution-neutral way, they allow for various implementation options and give the project team a high degree of freedom in selecting the most suitable solution variant. Table 2.37 shows the different issues in the objectives, requirements, and specifications. In traditional project management, a complete set of requirements is assumed in order to develop the specifications. Subsequent changes to the requirements, i.e. to the specifications, can lead to completely different solutions with considerable costs and scheduling consequences. For example, the subsequent change of the tolerance from 0.1 to 0.08 mm can mean that a completely new production technology has to first be developed and introduced in order to be able to manufacture this product line. This additional requirement can double the project duration and costs or cause the entire project to fail. In practice, terms used synonymously for the functional specification include overall system specification, target concept, technical specification, and system specification.

2.4.6

Effort Estimation

In the traditional approach, the project manager is responsible for the planning (planning procedure, method, tools, plausibility test). For the effort estimation he will involve the project group for the following reasons: • The whole project group together has more necessary interdisciplinary expertise than the project manager as a generalist. This results in there then being better estimates. • With joint planning, the sub-project managers are better informed. This also increases their motivation and willingness to take responsibility for their activities. • In practice, it has proven useful for the sub-project managers or the project staff to approximate the effort of their work packages and activities and then consolidate it with the project manager. In the agile approach, the scrum team is responsible for carrying out the effort estimation. The product backlog entries are estimated entries and, during sprint

2.4 Concept Phase

145

planning, the identified activities. Ideally, the project group is guided by the following credo whilst making their calculations: "

Counting before calculating before expert opinions

The reason for this recommendation is the decreasing accuracy of the estimation methodology.

2.4.6.1 Importance of Effort Estimation in the Traditional Approach In the traditional approach, the effort estimate is the basis for calculating the project duration (scheduling) and the project costs. The company asks itself whether the project should be realised, whether the funds are available in the time span set aside for this, whether the project is economical, or which investment, when there are several possibilities at hand is the best to secure the future. The quality of the decisions thus depends on the accuracy of the effort estimate. For companies that have to make binding price offers to their clients, e.g. in engineering or architecture, a very accurate effort estimate is necessary and vital to avoid losses. From this point of view, effort estimation and the associated uncertainty are of great importance. Making a useful effort estimate requires experience, care, and preparation. Basic options for effort estimation are: • Experience and analogy through comparison of deliverables or work packages with similar tasks already realised (empirical values from similar projects) • An analytical procedure of breaking down the task into individual, clear activities or functions, estimating the effort • Combining these possibilities Many estimation procedures are based on empirical values. These have to be systematically built up by evaluating many projects at the end of the project over a longer period of time. The deliverables or work packages need to be clearly structured and delimited. From the analysis of the actual values of completed projects, adjusted effort values as well as influencing factors for the future are to be worked out. Possible influencing factors are: Scope and complexity of the task, experience of those carrying out the work, acceptance by those affected, available infrastructure, applicable regulations, etc. Only the most important influencing factors then get selected. These characteristic values are only valid for the company and the project type for which they were evaluated. A company must select an estimation procedure and adapt it to its circumstances. In order for them to be applicable across an entire organisational unit in the company, the definitions and delimitations of the deliverables and work packages and their contents have to be uniformly defined, interpreted, and handled. Empirical values cannot be adopted that are invisible to others.

146

2 Methodology

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

2.4.6.2 Planning Poker, Story Points The estimation method with story points is a frequently used method in the agile approach. It is a modernised and optimised further development of the Delphi method according to gamification aspects. The project team estimates a size for each user story (or requirement, or building block). Cards with the values 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 or with 100, based on the Fibonacci numbers, are used. After the user story has been presented, each member of the project team approximates the effort and places the card face down on the table. Once all members have given their estimates, the cards are turned face up and compared. If the estimates do not match, the members with the highest and lowest estimate briefly justify their estimate. Then there are further rounds of estimation and discussion until a consensus is reached. The number of story points for the implementation of a user story says nothing about the effective effort. As soon as the project team is working, an empirical value can be formed of how many story points can be realised by the team in a sprint. The speed of implementation (velocity) in the team increases with each sprint. 2.4.6.3 T-Shirt Sizing Often it is difficult to estimate the exact effort needed at an early stage of the project, a stage during which marketing or sales staff often have to make decisions on the project scope. However, an engineer is not able to provide a perfect calculation without there being defined specifications. To resolve this dilemma, it is advisable to make people aware that estimated figures accurate to the millimetre are not necessary in an early phase. In the T-shirt sizing method, the developers classify the size of each requirement in relation to other requirements into the T-shirt sizes Small, Medium, Large, or Extra Large. Likewise, the marketing and sales representatives classify the business value of the requirements using the same scale. By comparing business value and effort, this simple method can be used to have qualified discussions about project scope. Example: I would like to have requirement A implemented, as this represents a business value of Extra Large and can be implemented with an effort of Medium. In return, I will forego requirement B because the effort is Large and the business value was only estimated as Small. 2.4.6.4 Multiplier Method The task to be realised is broken down into small, manageable units for which the effort is known. Or it is tried out on an example: Number of modules, number of

2.4 Concept Phase

147

pages, number of graphics. The effort per unit multiplied by the number of units adds up to the total effort for all types of units.

2.4.6.5 Percentage Method The percentage method gives empirical values for the percentages of the total effort for each phase. The percentages per phase are highly dependent on the project type and the company. A phase is estimated and realised in detail. When this phase is completed, it is used to draw conclusions for the whole project. Caution is advisable if the entire project is to be inferred from a first small project phase with little effort. However, the procedure is well suited as a plausibility test for checking estimated values that were developed in another way. The empirical values or key figures must come from projects that were developed under comparable framework conditions (e.g. same infrastructure, same corporate culture). 2.4.6.6 Analogy Method When estimating effort using the analogy method, the work packages, tasks, or features of the project to be estimated are listed and compared with actual values from similar or identical work units from previous projects. Correction factors can be used to make situational adjustments. The better the match between the reference base and the object of estimation and the higher the expertise of the estimators, the more precise the estimate will be. Figure 2.49 shows the use of the analogy method.

Previous projects (actual values) Project A Feature list: Feature 1 Feature 2 Feature 3 ...

Project C 10 h 15 h 23 h

Project B Feature list: Feature 11 Feature 12 Feature 13 ...

Project to be estimated

10 h 15 h 23 h

Fig. 2.49 Effort estimation by analogy method

Feature list: Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 ...

10 h 15 h ?h 15 h 23 h

148

2 Methodology

It is particularly well-suited for standard projects, e.g. for the preparation of quotations for modular overall systems (see also Sect. 2.8.2).

2.4.6.7 Expert Estimation (Delphi Method) At the risk of great uncertainty about the effort estimate, expert surveys are nonetheless common. The Delphi method interviews several experts independently of each other. The different estimates are presented to all of them anonymously. In further rounds, the experts use the opportunity to make their arguments known and to then still adjust their values before a group opinion is formulated. Another expedient procedure is the estimation meeting. Here, all the implementing specialists come together well-prepared and state their values and arguments. This creates a welcome group dynamic process, which is moderated by the project manager. The aim of an estimation meeting is to have a consolidated estimate at the end, in which the specialists reach a consensus. 2.4.6.8 PERT (Programme Evaluation and Review Technique) For projects with a high degree of uncertainty (e.g. pioneer projects, acceptance projects, research projects), the dispersion can also be taken into account. In this case, a probable time expenditure pT (most frequent case) is estimated for each work package and additionally a minimum time expenditure MinT (optimistic, most favourable case) as well as a maximum time expenditure MaxT (pessimistic estimate, most unfavourable case). The planning is continued with a single planned value: Planning value = ðMinT þ 4 × pT þ MaxTÞ=6

2.4.6.9 Reserves Already even with medium-sized projects, in terms of the number of deliverables and work packages, statistical equalisation has a favourable effect on the deviation in the total effort, provided there is no systematic error in the individual estimates. Even when there is careful planning, unforeseen events can occur, effort items are forgotten, small changes are made, or the effort that needs to be made is underestimated, which is why a project needs project reserves in the form of money or time reserves, for instance. The project manager has these project reserves at his disposal. If a project team member has an overrun in his deliverables or work packages that he can no longer absorb within his own deliverable or work package, he informs the project manager. In this way, the project manager controls the use of the project reserve and can adjust his goodwill towards desirable changes to the situation. If no project reserves may be created in a company, the project manager should consider creating hidden or undisclosed reserves. 2.4.6.10 Typical Errors in Effort Estimation Efforts estimating expenses are always associated with uncertainties. There are always traditional errors in the estimation of expenses that occur due to:

2.4 Concept Phase

• • • • • • • • •

149

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

2.4.7

Schedule and Timetable

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

Tasks and deadlines No Tasks Measures Processes

Responsible

PreDura- Scheduling / Gantt chart condi- tion tion (weeks) 1

2

3

4

5

6

1 Project 2 Phase 1 3 Task A

MM

-

6

4 Task B

MM

3

1

5 Task D

PP

-

2

6 Task E

PP

5

3

7 Task C

MM

3;6

2

8 Task F

TT

7

3

9 Task G

MM

8

1

10 Preparation MS

PL

4;9

1

11 MS-Decision

AG

10

0

12 Phase 2 13 Workpackage H

MM

Fig. 2.50 Exemplary activity list with bar chart (Gantt chart)

7

8

9

10

11

12

13

14

150

2 Methodology

Thus, for each activity, the executing agency or the responsible department is entered, as far as known. The executing agency must have the necessary expertise for the activity and have sufficient free capacity at the scheduled time. In the case of bottleneck resources, availability should be taken into account as soon as it is roughly known. The subject matter expert estimates the time and lead time required to solve the problem. Time required is the amount of time in person months, -weeks, -days, or -hours required by the task owner to fully complete all tasks associated with the work package, taking into account the resources expected to be used. The lead time (duration) is the shortest time necessary to achieve the previously defined effort, taking into account the availability of bottleneck resources, unavoidable waiting times, and other general conditions. Example: A painter needs four hours to prepare and spray a bathtub. Then the tub needs 72 h of drying time until the next work step is possible. The painter needs another four hours for sanding the bathtub. The time required for the painter’s work is therefore eight hours, but the turnaround time is 4 days. Then the sequence of activities is determined that makes the most sense or that is necessary from a work point of view. For each activity, the questions must be answered: What results must be available? Which general conditions must be fulfilled so that the activity can be started? These time dependencies are entered in the activity list as preconditions. With this information, scheduling can then take place.

2.4.7.2 Termination, Critical Path, and Slack Scheduling can be carried out using the bar chart technique (Gantt chart). Scheduling provides the final date and also the intermediate dates of the project, taking into account the dependencies. The scheduling process results in an earliest and a latest start and end date for each activity. The earliest finish date indicates when an activity can be completed at the earliest, if all conditions are fulfilled as best as possible. The latest end date indicates when the activity must be completed at the latest so that the project is not delayed. If the latest and earliest dates of two consecutive activities are different, the preceding activity has time leeway (slack, buffer). The slack is the time by which an activity may be delayed without this having an effect on the final deadline. The critical path is the connection of all activities that have no slack. It also determines the end date. If an activity is delayed along this path, the end date of the project is then postponed by the extent of this delay. In order for the project manager to be able to take early action if necessary, he must check the activities on the critical path regularly and at sensible intervals. The Gantt chart shows the earliest possible start, the earliest possible end date, and the latest possible end date for each activity in a compact and clear presentation. Duration, slack, temporal relation of the individual activities and the dependencies on each other are clearly visible, as Fig. 2.51 shows.

151

Activities

2.4 Concept Phase

Critical path Slack

3 4 5 6 7 8 9 10 11 1

2

3

4

5

6

7

8

9

10

11

12

13

Time

Fig. 2.51 Bar chart with critical path and slack

Figure 2.52 shows an excerpt from the process and schedule in two levels of detail based on the practical example from Metrohm. The picture also shows the on-going exchange between the project and the system architecture.

2.4.7.3 Accuracy in the Process and Scheduling How precisely should one plan deadlines, resources, and costs? Does the project management have a better grip on the project the more precisely it makes plans? Any planning constitutes a hypothesis made about the future. In some projects, especially those that are highly dynamic, the future reality will often be different from prior ideas about it. It is therefore worthwhile to assess the project dynamics: can a relatively smooth course of events for the project be expected, is there a high degree of certainty about the individual events and activities, or must uncertainties, many changes and surprises be expected? Examples: In the case of a “normal” single-family house on a problem-free plot of land, the individual planning and realisation steps have been tried and tested and can be planned with relative certainty until commissioning. This is a standard project (see Sect. 1.2.1). Detailed planning is very helpful here in order to be able to meet deadlines and costs. In the development of a new product or software, where new findings change the situation after each step or where new impulses flow in from the environment, precise planning would be an obstacle, acting like a rail of fixed expectations that one wants to fulfil to as high a degree as possible. Iterations or learning loops are thus made more difficult, new

152

2 Methodology

Fig. 2.52 Practical example Metrohm: Procedure and schedule

ideas are blocked out. In this case, it is more appropriate to plan for milestones or fixed deadlines in order to be able to use flexible planning and controlling instruments like kanban in between. It would be even better to handle a project of this type using the agile approach. Figure 2.53 shows that the estimation accuracy improves in the course of the project.

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

2.4 Concept Phase

Commissioning

153

Initialisation

Concept

Realisation

Introduction

Project request

Project order

Technical specification

1. Rough estimate

2. Rough planning

3. Detailed planning

+50%

+10% -10%

-50% Accuracy of estimation e.g. similar projects (already carried out) Accuracy of estimation e.g. pioneer projects (new territory)

Fig. 2.53 Estimation accuracy

Adjust deviations

Management

Project Management

Work Level Detailed planning – Time planning – Cost planning – Resource planning – Resource leveling

Fig. 2.54 Planning top-down and compaction bottom-up

Bottom-Up: Consolidate detailed plans

Top-down: break down requirements

Requirements

154

2 Methodology

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

2.4.7.5 Adherence to Deadlines and Capacity Planning Depending on the objective, planning in the project is carried out on schedule or on capacity, as Fig. 2.55 shows. If the final deadline has a high priority, we plan on schedule. How do we have to proceed? What resources do we have to use? What measures need to be taken to

2.4 Concept Phase

155

Capacity (FTE) …results in required capacity 1.0 fixed deadline

Time-oriented planning The work package A (200 working hours) must be completed in 5 weeks

Capacity-oriented planning The work package A (200 working hours) obtains a capacity of 0.5 FTE

5 weeks

…results in required time

fixed capacity 0.5

10 weeks

Time (weeks)

Fig. 2.55 Resource histogram

make sure this deadline is met? How substantial is the overload at that point and how long will it last? Do the costs or other projects have higher priority, is planning in line with capacity? What is the deadline depending on the available resources? Forward Scheduling Scheduling from project starts to project completion. If the deadline is exceeded, measures of adapting to this event have to be examined (more resources, parallelisation, infrastructure improvement, externalisation of subtasks, reviewing the objective, etc.). Forward scheduling with possibilities of correction is the most common approach. Backward Scheduling Starting from the required end date, scheduling is done backwards in order to be able to answer the question: When do we have to start so that the deadline is reached? If the start date is in the past, the time until the planned date can be split into parts in proportion to the ideally required lead times—and used as orientation. Adjustments to the Planning In the initialisation phase, initial planning was prepared and released. At the milestones, critical questions are asked and the situation is reassessed: Are the assumptions made in the initial planning phase still applicable in full? Have new

156

2 Methodology

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

2.4.7.6 How Detailed Should a Plan Be? The level of detail is oriented towards the purpose. The planning should be detailed to such a degree that we are able to derive the necessary measures from it and reliably monitor and control the project. The planning must be at least as detailed as we would like to have it when controlling it later. If control is to take place at shorter intervals so that problems can be addressed early on, the tasks must need to be broken down more finely. The quality (accuracy, completeness) of the data is more important than the level of detail. The level of detail should not be chosen to be higher than necessary because then the corresponding effort for planning and control quickly becomes very large. 2.4.7.7 Further Planning Variants: Target Costing, Design-to-Cost In a price-sensitive environment, the costs of the result from the project (e.g. the manufacturing costs of the product) are more important than the “one-off” costs of the project. The product costs are mainly determined in the definition and development phase and can only be influenced to a very limited extent in later project phases. This results in a special responsibility of the project manager and the developer for compliance with the cost objectives agreed in the requirements catalogue. When defining target costs, a maximum value is set for how high the manufacturing costs of the product is allowed to be (target costing) and may be included as a binding value in the objectives. The project manager monitors compliance with this manufacturing cost budget. From the customer’s point of view, the operating, training, maintenance, and disposal costs incurred during use are relevant in addition to the acquisition costs. He is interested in low total costs (life-cycle-costs). The project manager should prefer solutions that aim at low total costs, as long as this does not excessively increase the manufacturing costs and project costs, unless, of course, the customer accepts these. At the price of higher project costs, manufacturing costs can be further reduced. The break-even analysis helps to illustrate the relationship between project costs and manufacturing costs for a forecast sales quantity. It also shows the effects if the planned number of units cannot be sold on the market, see Fig. 2.56.

157

Costs

2.4 Concept Phase

Variable costs 1

Variable costs 2 Break-even Fixed costs 2

Fixed costs 1

Quantity N

Fig. 2.56 Break-even analysis

2.4.8

Resource Deployment Plan and Resource Coordination

In the traditional approach, resource planning can be derived from the process and schedule. A prerequisite for this is the coordination of the required resources in the project with the available resources in the line. In practice, failure to coordinate resources is often the cause of problems in demanding multi-project environments.

2.4.8.1 Resource Planning in the Project: Line and Project Manager as Partners The project manager is responsible for project planning. With process planning and scheduling, he plans what is to be done and when it is to be done (Fig. 2.57). At the time of planning, the availability of resources is not yet guaranteed. Once the schedule is available, the resource input has to be planned. The resource utilisation plan of a project contains the planning data of at least all bottleneck resources involved in the project. The project manager is responsible for resource planning together with the line managers or an assigned resource coordinator. 2.4.8.2 Resource Coordination in Multi-project Management For resource planning, the project manager and the line managers depend on each other. The project manager reports his resource needs and wishes to the line managers. If the required resources are available, they are promised and reserved

158

2 Methodology

Number of persons (FTE) 3

C 2

D

E

G

1 F

B

V

A WE

1

2

3

4

5

6

7

8

9

10

11

12

13

Time

Fig. 2.57 Resource allocation plan of a project

in a binding manner. A prerequisite for a binding commitment by the line managers is that they carry out an updated resource utilisation planning for all projects (see Sect. 2.7.1.6). If resource conflicts arise because several projects want to access the same resource at the same time, the project manager and resource managers must find solutions together and reach agreements. It is good if the resource manager (often the line manager) is aware that he has a service responsibility in his field for the benefit of the projects. However, it is also helpful if the project manager is aware of not always being able to have exactly the specialist he wants at any given time, and that he must therefore show a certain degree of flexibility. It is then that the conditions need negotiations to be conducted in a spirit of partnership between project managers and resource managers. Figure 2.58 shows the resource alignment of various projects with the line. Figure 2.59 shows the workload of an employee by basic load and several projects over time. If the resulting deadline does not meet the specifications, it is the project manager’s task to check measures and make corrections. If the timeframe or effort proves to be unrealistic, the project manager will discuss it with the project owner. Possible optimisation measures in the event of the planned result happening too late are:

2.4 Concept Phase

159

Project A 21

Project T 05 Line Management, Resource Manager Deployment plan: Marcus Miller

Workload %

150 Resource requirement Resource requirement

Resource requirement

F 34 100

D 17 A 21

50

0

2

4

Base load 8 10

6

Resource requirement

T 05

12

14

Period

Resource adjustment Project D 17

Project F 34

Fig. 2.58 Multi-project planning

Capacity 150%

100%

50%

0%

1

2

3

4

5

6

Project F 34 Project T 05 Project A 21 Project D 17 Base load

Fig. 2.59 Workload of a project staff member

7

8

9

10

11

12

13

14 Time

160

2 Methodology

• Shifts within the buffer time • Increased parallelisation (first, look for the activity with the greatest potential for further integration on the critical path. This is usually an activity with a long duration. Now check the dependencies on subsequent activities with the aim of bringing forward the dependent activities so that subsequent activities can start earlier. In this way, the activity under examination is to be divided into two or more parts and the list of activities extended); • Use of additional available resources • Setting of project priorities by the management, whereby individual projects are given preference to the detriment of others • Outsourcing of suitable activities or work packages • Distinction between basic functions and options to be implemented later in updates.

2.4.9

Cost Plan

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

2.4 Concept Phase

161

No. Task 3 4 5 6 7 8 9 10 11

Duraon days 30 5 10 15

Acvity A Acvity B Acvity D Acvity E Invest Acvity C Acvity F Acvity G Prepare MS MS-Decision

FTE 0.50 1.40 1.00 1.40

Effort days 15 7 10 21

Rate € p.d. 1’200 1’500 1’200 1’500

1.50 0.80 1.60 1.00

15 12 8 5

1’200 1’833 1’500 1’800

external cost €

internal cost € 18’000 10’500 12’000 31’500

95’000 10 15 5 5 0

18’000 22’000 12’000 9’000

Subtotal 117’000 Project Cost Total

FTE = Full Time Equivalent

111’000 228’000

Fig. 2.60 Information for cost planning

If the budgeted data from resource and cost planning is overlaid with the schedule planning, the cost curve is created, showing the course of the cumulative total costs of the project over the project duration. The cost curve shown in Fig. 2.61 is a useful tool for making approximations about:

250

100 90

1'000 € (per week)

70 150

60 50

100

40 30

50

20 10 0

1

2

3

4

5

Internal costs External costs Total costs (cumulative)

Fig. 2.61 Cost curve

6

7 Time

8

9

10

11

12

13

0

1'000 € (cumulative)

200

80

162

2 Methodology

• Period costs when releasing the individual project phases • Budget amounts for the individual financial years for the provision of funds • Liquidity for the required investments It also provides a basis for a comparison of planned and actual costs.

2.4.10 Information, Communication, and Documentation Information and communication processes always take place in some form or another in projects. The question here is: do these “happen” by chance, or are they configured deliberately? Leaving things to chance involves high risk: project participants are either not provided with the necessary information or not in a timely manner. Documents are neither filed nor found. Stakeholders do not feel involved and resist. Rumours spread. Information flow and the communication taking place in projects are often seen as a necessary evil or simply forgotten, because the project management or the project team is too busy with content-related issues. However, the project management should be aware that good information and communication are essential factors for the success of the project and represent a further success factor in stakeholder management (Sect. 2.3.5). In agile projects, a structured exchange of information takes place daily via the daily stand-up meeting (Sect. 2.5.3). Information and communication are addressed internally and externally: • Internally to the group of project participants: goal-oriented action requires a high degree of transparency and comprehensive information for the project participants and comprehensive information. The facts and documents such as specifications, schedules, and contracts must be accessible to all team members. • Externally to customers, users, interest groups, and the public: during the project, the most important thing is to gain acceptance and support. Rumours are replaced by facts, thus reducing negative influences on the project. After project completion in the utilisation phase, project documentation must be available to ensure operation. Information and communication are handled differently in the project and in the line. In the line hierarchy, communication takes place via predefined reporting channels. In projects with rather small teams, direct information channels that are as short as possible are more suitable. They allow for flexible and rapid decision-making and better coordination.

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

2.4 Concept Phase

163

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

2.4.10.2 Scope of an Information and Communication System The whole system of project information and project communication can be structured as follows: • Oral communication in conversations, meetings, problem-solving, and contentrelated cooperation at workshops • Reporting: minutes, progress reports, amendments, etc. • Project documentation: project manual, project-related files, content-related documents such as concepts or instructions • Project marketing to create trust and acceptance through information events, in-house posters, presentations, lobbying, etc. • Cooperation tools to collaborate and share plans, documents, backlogs, etc. Not all components have to be equally important in a project. For example, in a research project the keeping of a diary can be important for continuous data collection, while hardly any marketing needs to be done. In a change project, on the other hand, oral communication and marketing are important. Since the communication concept practically always has to be reinvented for each project, it is worthwhile for standard projects to standardise the corresponding reporting channels, checklists, documentation principles in project management guidelines and to provide corresponding templates. The totality of information and communication can be represented in a communication matrix as shown in Table 2.38. The so-called W-questions can be helpful in creating the communication matrix: • Who is the sender? Who informs? It can often make a considerable difference whether the project management or the CEO informs! • Who does the project need? Who are the beneficiaries? • What is the subject of the information? What is the objective? What is the message?

164

2 Methodology

Table 2.38 Communication matrix Characteristics, information type Oral information Project status (presentation) Project committee meeting, Sprint review Project meeting, Daily stand-up meeting Written information Project status report

Phase completion report, project completion report

Responsible person, reporter Product owner, project manager Team, project manager

Distributors, participants

Date, frequency

Stakeholder

According to need

Project committee, internal stakeholders

As needed, at end of sprint Weekly, daily

Scrum master, project manager

Project team

Project manager, product owner Project manager, product owner

Project committee, portfolio management, internal stakeholders Project committee

Monthly, quarterly According to need

• When and in which periodicity is information provided and announced? • How is information provided, in what form, with what media e.g. paper, mail, notice board, scrum board, in-house newspaper, etc.? What method is used to inform? How should feedback be obtained? • Where and in what framework should the information be conveyed, the debate conducted? • How far, to which degree should the information be made accessible to serve as a working platform for the spatially separated project staff, e.g. homepage, intranet?

2.4.11 Quality Management Quality management ensures that the results produced meet the requirements in that regard during the course of the project. For this purpose, a corresponding process must be established in the project. In addition, an understanding of what quality entails has to be created among all members of the project staff. Quality is relative and depends on the requirements of the project owner. The demands on the quality level to be achieved can vary greatly. The project is not about achieving the highest possible quality level, but rather simply about just the required level. The quality objectives for the project can be derived and defined from the requirements. In quality assurance, a distinction is often made between checking and testing:

2.4 Concept Phase

165

• Check: Check documents and compliance with agreed-upon processes and tasks in terms of content and form. • Testing: Checking the fulfilment of the requirements and the applicability of the processes on the developed product, system, or plant. Review Procedures such as consultations, audits or reviews are suitable or reviews. This means that the review is to be carried out by affected stakeholders or experts. The aim is to find out whether the required quality has been achieved or whether a concept or an architectural sketch serves to achieve the set project objectives. Any defects or deficiencies found are recorded in a list of findings or in an inspection report and returned to the project team for further processing. In many cases, the auditor also makes a recommendation on how best to remedy adverse findings. Testing Before testing, it is advisable to develop a test concept. A test concept describes the test objects, test methods, and the test infrastructure. It is also advisable to record test objectives and the test organisation. In addition to the test concept, test cases and a test plan are developed in practice: Who tests what and when? The test cases can be built using Office applications or in a comprehensive test suite (software). The use of a test suite has the advantage that the errors found can be recorded and tracked until they are completely eliminated and tested again. With a test suite, evaluations of test progress and test success can also be made. By carrying out the tests, the fulfilment of the set requirements is checked. Any errors found are recorded. At the end of a test sequence, a test protocol is created. Quality Management Plan Quality planning involves defining all those inspection and test measures that are made necessary by regulations, good practice, and the company’s quality requirements in order to ensure the quality objectives of the project or product. In the quality plan, all defined and economically justifiable measures are listed, namely by when they will be carried out and who is responsible for them. In large projects, these measures are recorded in a separate quality plan. In small projects, this information can be integrated into another planning document, e.g. the process and schedule plan. Examples of Measures in the Quality Plan • Document verification • Test of the finished product, intermediate tests • Testing in the customer’s operating environment, qualification test, conformity test, homologation, clinical tests, approval tests • Design reviews, design verification, design validation • Value engineering, value analysis, reliability analysis • Special tests: Integration test, safety tests • Pre-treatments (endurance test, burn-in, etc.)

166

• • • •

2 Methodology

Environmental tests, climate test, shake test, drop test Corrosion test, test for chemical residues, test of flammability Electromagnetic compatibility, interference radiation Prototype, pilot series

For economic reasons, only measures which are necessary in terms of the subject matter and economically justifiable may be defined and implemented.

2.4.12 Checklist Completion Concept Phase

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

2.5 Realisation Phase

167

• Has a variant with plans ready for implementation been selected? • Has the chosen solution been worked out in detail with the necessary solution concepts? • Were effort, resources, and deadlines planned completely and realistically in detail? Has a plausibility test been carried out? • Are the financial resources and liquidity secured for the entire duration of the project? • Is the availability of the required financial and human resources assured? • Is the necessary knowledge available? Are the appropriate resources assured? • Specific points of the agile approach • Has the product goal (product concept) been clarified and the vision defined? • Has a first version of the product backlog been developed? • Are the entries in the product backlog prioritised and estimated? • Has the release plan been defined? • Are the entries prioritised?

2.5

Realisation Phase

In the traditional approach, the plans from the concept phase are accomplished in the realisation phase. Comprehensive on-going review and control help to keep the project on track and achieve the desired goal. In the agile approach, external monitoring of the plans is no longer necessary. Due to the self-organisation of the teams, control takes place within the team. The detailed conception is made for each sprint and implemented directly. This makes it possible to respond flexibly to changed wishes or framework conditions.

2.5.1

What Is Important in the Realisation Phase?

Steps of This Phase Table 2.39 shows the most important steps in the agile and in the traditional approach for the realisation phase. Results of the Realisation Phase In the realisation phase, the results according to Table 2.40 are of importance. People and Team In the realisation phase, the composition of the team can change again, which means that all the aspects listed in the concept phase can be relevant again (Sect. 2.4.1). In addition, the introduction is already to be planned.

168

2 Methodology

Table 2.39 Steps of the realisation phase Most important steps

What should be paid particular attention to in the implementation phase?

Agile approach • Concretise the solution and realise it iteratively • On-going realisation of improvements to the product and in the cooperation of the team • Plan training for future users • Conduct project marketing, i.e. inform stakeholders and external bodies (e.g. clients).

Traditional approach • Provide material, human, and financial resources • Produce and test solution • Plan training for future users • Steering the project process • Carry out plan-actual comparisons (financial management, controlling) • Communicate deviations • Conduct project marketing, i.e. inform stakeholders and external bodies (e.g. clients) • Focus on the solution to be implemented. Avoid delays • In the agile approach, continuous learning and improvement are institutionalised. Successful project managers consistently apply the principles of continuous improvement in the traditional approach as well

Table 2.40 Results of the realisation phase Principle

Processoriented results

Contentoriented results

Agile approach Traditional approach The solution or system is built and tested. In order for the project to be completed, the following objectives have to be achieved at the end of the realisation phase: • The system, the product, the service have been procured or created • The solution has been tested and approved • The results are used as soon as the users are empowered to do so The project management puts The iterative development is based on controlling in the foreground: it current priorities. The solution to be communicates the project status realised is continuously adapted to the compared to the planning as well as latest needs the planned changes. Since there are • Current product backlog often many project participants in this • Sprint planning phase, systematic information and • Offers, contracts, settlements communication is essential • Phases, review report • Project progress reports • Realisation plans, change documents • Offers, contracts, settlements • Quality assessment • Phases, review report • Realised results • Implemented partial solutions • Test reports (increments) • Documents for the introduction and • Results from the sprint review instruction summarised in the introduction concept

2.5 Realisation Phase

169

The following measures and competences are important: • Dynamics in teams (Sect. 5.2): Conflicts and resistance often arise in the team during this phase. The team can fall back from “performing” into “storming”. The work on the system (Sect. 1.5.2) and conflict management (Sect. 5.6) remain important aspects for those responsible for the project. • Project teams are dependent on constantly adapting their procedures and learning quickly. To do this, it is essential to be able to give constructive feedback and to master the questioning techniques (Sect. 3.9). • Constructive feedback, in turn, is based on a communication culture that is based on a human image of the “non-trivial system” (Sect. 1.6.3), selective perception (Sect. 3.3.3) and thus also on making the distinction between evaluation and effect. • Success factors of cooperation: project teams that are balanced in their team roles are more efficient than those with the highest intellect. There needs to be a balance between team roles. In order for this balance to be transformed into higher performance, high competences are required in terms of personal communication (Sect. 3.9), conflict management, or negotiation (Sect. 4.10) • Every project brings about minor or major changes. Project managers are always also “change agents”. Changes in turn cause resistance. Attention must now be paid to planning the introduction and thus to dealing with change and resistance (Sect. 5.5)

2.5.2

Sprint Planning, Sprint Backlog

The implementation in the agile process according to scrum takes place in iterations. These iterations are called sprints. Depending on the type of project, the duration of a sprint is between 2 weeks and 1 month (possibly up to 2 months for hardware). In practice, sprints most often last 3 or 4 weeks. A sprint should be planned in such a way that the results can be achieved in a relaxed and focused manner. The scrum team should still be fresh enough after a sprint to be able to tackle the next sprint in such a mindset. Before sprint planning, the product owner makes sure that the product backlog items are understood by everyone in the scrum team and that they contribute to the product goal. Sprint planning is done in three steps. • Step 1: Why is this sprint valuable? (Why) – The product owner proposes how the value for the product can be increased and which benefits should be realised in the sprint. – The scrum team members work out the sprint goal together • Step 2: What can be accomplished (Done) in the sprint? (What) – The developers select the product backlog entries to achieve the sprint goal. – If necessary, a refinement of the product backlog entries takes place in the scrum team to increase the understanding and confidence for the implementation in the scrum team.

170

2 Methodology

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

Task (To Do) In Progress Developed Examination (review) Done

2.5 Realisation Phase

171

Fig. 2.62 Practical example BLS: Sprint Backlogs

The kanban board can be supplemented by other areas: ideas, backlog, specification, integration, delivery, etc. This creates transparency and the flow of work gets visualised as a process. This increases the scrum team’s sense of responsibility. Figure 2.63 shows a kanban board that is managed in a tool.

Fig. 2.63 Practical example BLS: Scrum board (Kanban board)

172

2.5.3

2 Methodology

Sprint Implementation, Daily Scrum

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

2.5 Realisation Phase

173

Story Points

Remaining Story Points Burndown ideal

1. June

3. June

5. June

7. June

Time

Fig. 2.64 Example: Sprint Burndown Chart

The product backlog is a dynamic list that continuously gets adapted to the latest findings and needs. If details are added to entries, estimates are made, or the order of the entries in the product backlog is determined, this is called refinement of the product backlog, often also called refinement or grooming. Refinement is a continuous process in which the product owner and developers work together to detail the product backlog entries. During the refinement of the product backlog, the entries are reviewed and revised. The scrum team determines when and how this work of refinement is done. However, the product owner can update the entries in the product backlog or have them updated at any time.

2.5.4

Sprint Review

The sprint review takes place at the end of a sprint; during these occasions, the developers show what they have accomplished in the previous sprint. The developers make a presentation and demonstration of the realised increment. During the sprint review, together with the product owner, it is clarified to what extent the sprint goal and the requirements defined in the sprint backlog have been achieved. It is up to the product owner to decide whether a requirement has been fulfilled or not. Only requirements that have been implemented 100% are considered to have been fulfilled. If only 80–90% of a requirement has been implemented, it is

174

2 Methodology

not seen as fulfilled and gets carried over to the next sprint planning as a left-over. With regard to the implementation of a requirement, the principle of “all or nothing” applies. In addition to the developers, the product owner and the scrum master other stakeholders such as clients, representatives from marketing, or customers can also participate in the sprint review. A sprint review lasts a maximum of 4 hours.

2.5.5

Retrospective

Between the sprint review and the planning of the next sprint, a retrospective takes place. The aim of the retrospective is for the product owner, the developers, and the scrum master to review (reflect) on the last sprint and evaluate suggestions for improvement. This is done intending to increase quality and effectiveness. In doing so, the scrum team checksteam reviews how the last sprint went in terms of individuals, interactions, processes, tools, and Definition of Done. The following procedure has proven successful: • The participants think about the following topics and write a card or post-it for each contribution: – What went well? – What went wrong? – What could be improved? • Participants post their contributions onto a pin board, grouped around the three questions. • All participants look at the contributions and let them sink in. • Each participant can comment on and add to their contributions. • The group discusses the question “What could be improved?” Improvement measures are defined and decided together in the group. The retrospective is moderated and led by the scrum master. He pays attention to constructive and objective contributions. Contributions that personally attack other group members are to be avoided. The sprint review and the retrospective firmly establish continuous learning and improvement in the process. The two meetings generate knowledge and stimulate the constant improvement process. In many cases, this also leads to a steady increase in the speed (velocity) of development. As a result, more and more requirements and topics can be implemented from sprint to sprint during the fixed sprint duration. This improvement process is also called kaizen in lean product development. In practice, retrospectives are often conducted very mechanically and with little commitment. Questions such as “liked, learned, lacked” or “start, stop, continue” are reeled off emotionlessly, a few impressions are collected, the team members pat themselves on the back and move on to everyday project work. Retrospectives only make sense if they are done with commitment and all topics are addressed openly.

2.5 Realisation Phase

2.5.6

175

Project Controlling

Overview Project controlling is to be regarded as an independent term in the traditional approach and describes the processes and rules within project management that contribute to seeing to it that the project objectives are achieved. Project controlling in the overarching sense is a cycle in three stages, as Table 2.41 described. The elementary basis for successful project controlling is the correct definition of binding objectives and reliable planning. In project controlling in the narrower sense, corrective measures are derived from a comparison between the target and the actual status, which can lead to adjusted plans or to altered objectives, a new target state. Project management runs in cycles: If executed well, it is aligned with the goal, otherwise the project goes round in circles, as shown in Fig. 2.65. Project controlling is therefore a direct management task of the project manager in cooperation with the project owner, project committee, decision-maker or management. Depending on the level of flight, a distinction is made between the following terms: • Strategic controlling (by the management) • Multi-project controlling (through the project portfolio board or the project committee) • Project controlling (also individual project controlling) by the project management and the project committee Table 2.42 summarises the main tasks of effective project controlling. Table 2.41 Project controlling in the context of overall project management Definition stage Planning stage

Control stage

Correct and complete agreement on objectives between project owner and project team Project planning can be derived and elaborated from the objectives of a: • Phased plan • Project structure plan • Date and schedule • Resource plan • Cost plan Within the framework of project controlling in the narrower sense, the target state is compared with the actual state. In case of deviations, corrective measures are defined Disturbances in the form of conflicts or change requests flow into this stage and lead to a new cycle run: • Approved change requests modify the original objectives in the definition stage • The handling of conflicts as well as changes in objectives leads to an adjustment of the planning in the planning stage

176

2 Methodology

Definition • Set goals

Control • Content, quality • Deadlines • Costs, resources • Conflicts • Changes

Plan • Phase plan • Project structure plan • Schedule • Resource plan • Cost plan

Fig. 2.65 Project controlling as a cycle in three phases

Table 2.42 Aspects of project controlling Project control Reporting Project management Project changes Project assessment

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

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

2.5 Realisation Phase

177

• The progress of the project is determined objectively • The data obtained is interpreted correctly • Comparison with the target state presupposes clear, measurable objectives Depending on the size and complexity of the project, different methods can be used to record and visualise the progress of the project and to compare target and actual values. The bar chart or work package schedule control, the earned value analysis, and the milestone trend analysis can be mentioned. Earned Value Analysis The Earned Value Analysis (also called Performance Value Analysis or Completion Value Method) is used to assess the progress of projects. It allows the three elements of the “magic triangle”, scope, costs, and time, to flow simultaneously into the project assessment. This is done by calculating the following quantities: • Planned expenditure (planned value) • Completion value (earned value) • Actual expenditure (budget burned) Earned value is the key performance indicator in this model for controlling the progress of the project and the associated costs (Fig. 2.66). Only work aspects that are fully completed and audited contribute to the earned value (0 or 100%)

Costs

PV

AC – Actual Cost

Extra effort

AC

PV – Planned Value

EV – Earned Value

Delay

EV

Time Project start

Fig. 2.66 Earned value analysis

Reporting date

End of project

178

2 Methodology

Commissioning Initialisation

Concept

Realisation

Introduction

Mar Feb Jan Dec

Milestone dates

Nov Oct

Introduction

Sep

Realisation

Aug

Concept

Jul

Initialisation

Jun

Commissioning

Apr Mar Feb Jan

Reporting date

May

Fig. 2.67 Milestone trend analysis

Milestone Trend Analysis The Milestone Trend Analysis (MTA) shows which temporal development is emerging in the project. The prerequisite for this is the definition of a sufficient number of milestone dates for the project to be assessed. These dates are checked at regular intervals to see whether they can be achieved and transferred to a coordinate system (Fig. 2.67). This results in a forecast curve for each milestone, which ideally runs horizontally (without any deviation). The experienced project manager can create a forecast for the future course based on the course of the curves. The milestone trend analysis gains its special value from the combination of a review of achieved results and an outlook on achievements still to be made as well as being able to provide a comparison between different projects.

2.5.6.2 Reporting The reporting to all stakeholders of the project is probably one of the most important and at the same time less popular tasks of the project manager. A regular exchange of interim results with the responsible bodies and decision-makers ensures that the project is kept in touch with those at management level and that the project manager can quickly count on the appropriate support in case of problems arising.

2.5 Realisation Phase

179

In a status report, also called a progress report, for the attention of the decisionmakers (customer, project owner, or project committee), the following statements should be made at regular intervals (often monthly or even weekly): • • • • • • •

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

• Highlights: What’s going well? • Issues: What is not going according to plan? It is advisable to develop a solution proposal for each issue, which should ideally be able to be supported and implemented or commissioned by the decision-maker. This gives the project manager a great deal of power and can strongly influence his project outside of the scope of his formal competences. The reporting system serves as the basis for all steering and control measures necessary in the course of the project. In many cases, reporting is regulated in the project management guidelines. Appropriate forms and templates are provided for this purpose. Traffic light systems have proven useful in practice. A common understanding of the meaning of the individual traffic light levels has been seen to, for example: • Green: stands for being on course • Yellow: means that an escalation to project management is required. The project manager can then decide and implement measures • Red: escalation to management is necessary. Management is to decide on measures and implement or delegate them If different stakeholders define the traffic light levels differently, misunderstandings and empty runs become inevitable. At Metrohm, the monthly status report is structured with, among other things, the following elements, see Fig. 2.68: • • • •

Project status with traffic lights and management summary Milestones Risk management Project costs

180

2 Methodology

PROJECT STATUS REPORT IC Project Type Sp Titr

EWP 100 EWP Number

OMNIS Project

23.04.2022 Reporting Date

1

KPIs: Next MS

Go Live

07. Okt 22

03. Jul 24

Release Prototype

Market Release

PC

Project Budget

Resources

Scope Deviations

Risk

Management Summary - Project on Track for Market Release, but delay of Prototype Release of 10 days due to late arrival of critical component - First titration-tests showed very good results, the ambitious requirements could be achieved - Major Decision: New Sample handling Concept will be implemented, as agreed with Product Management - Request: Investment 100k for automated production prozess is required, see separate evaluation and busienss case Milestone 1 2 3 4 next MS 6 7 8 Go Live

Start of project Review Design Goals Review URS Review Design Input Release Prototype Review Design Transfer System Freeze System Release Market Release

Actual Plan

Last Approved Dates

Initial Plan (LH-based)

01. Jan 20 19. Jul 20 04. Feb 21 23. Aug 21 07. Okt 22 19. Feb 24 20. Mär 24 19. Mai 24 03. Jul 24

01. Jan 20 19. Jul 20 04. Feb 21 23. Aug 21 27. Sep 22 09. Feb 24 20. Mär 24 19. Mai 24 03. Jul 24

01. Jan 20 19. Jul 20 04. Feb 21 04. Jul 21 08. Aug 22 21. Dez 23 30. Jan 24 30. Mär 24 14. Mai 24

Top 5 Risks Description

Status

Risk (after mitigation)

Level before

Level after

Status

R1: Präzision des Dosierers erfüllt geforderte Messgenauigkeit nicht

80

20

in Arbeit

R2:Neue Ventiltechnologie funktioniert nicht

90

8

in Arbeit

R3: ASIC steht nicht funktionsfähig zeitgerecht zur Verfügung

64

24

in Arbeit

R4: UL-Zertifizierung wird nicht erreicht

24

R5: Software steht nicht ausreichend funktionsfähig zur Verfügung

60

x

keine Aktivitäten notwendig 20

in Arbeit

Project Costs (TCHF)

Fig. 2.68 Practical example Metrohm: Project status report

R1 R5

2.5 Realisation Phase

181

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

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

• • • • •

To approve or reject additional funding To approve of and then enforce additional resources (from the line) To give the go-ahead for the next project phase To decide on the cancellation of projects To change project priorities Some preventive measures for efficient project control are:

• • • • • • • •

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

2.5.6.4 Project Assessment Normally, the most important steps (milestones) of a project are already agreed upon in the project order. These agreed-upon milestones are particularly suitable for project assessment because clearly defined deliverables and work packages have to have been entirely fulfilled at this point. Milestone meetings enable a critical review of that which has already been achieved, of what is still to come, and of the degree of

182

2 Methodology

maturity of the interim results. Together with the project owner or the project committee, the project management has to clarify the following questions in a binding manner: • • • • • • •

Is the achievement of the project objectives still guaranteed? Is the economic viability of the project still ensured? What risks could jeopardise the project? Do prior assumptions still apply or have new framework conditions emerged? Are there any open problems that prevent the project from proceeding? Will the next project phase be released? Dependent on what conditions? Should the project be terminated prematurely?

At the end of the meeting, minutes with any conditions, responsibilities, and deadlines should be drawn up and signed by each of the involved parties. Reviews and Audit for Project Assessment Reviews are critical during and after the completion of the project so as to determine whether the required objectives have been achieved in full and having the required quality. Organisations often distinguish between different levels of reviews, as shown in Fig. 2.69: • • • •

Milestone review at each milestone Gate review according to selected milestones with a particularly large impact Final review incl. debriefing and lessons learned at the end of the project Post-control incl. post-calculation to check whether objectives have effectively unfolded their desired effect.

Final Review

Level 3

Gate Review

Level 2

Level 1

Follow-up inspection

Milestone Review

Phase 1

Milestone Review

Phase 2

Project

Fig. 2.69 Various project reviews

Phase 3

Phase 4

Usage, Operation

2.5 Realisation Phase

183

Table 2.43 Aim and participants of a project review Milestone review Gate review Stage-gate review Quality gate review

End review

Follow-up

Main objective Control of the project process Assessment of the: • Phase objectives, deadlines, finances • Resources • Procedural methodology • Project organisation • Information • Communication and cooperation • Derive consequences for the further procedure of the following phase • Assessment of the achievement of the project objective • Critical review of the project process • Derive lessons learned, i.e. measures for operational project management • Assess long-term goal achievement and project impact

Possible participants • Project manager • Project team • Project committee customers • Possibly other stakeholder groups

• Project manager • Project team • Project committee internal client • External moderation • Team external to the project

In contrast to a review, an audit does not check the results achieved, but rather the compliance with applicable (external or self-imposed) procedure: • Audit: checks process conformity • Review: checks the achievement of objectives Of course, the situational suitability of a chosen approach, of the methodology or the tools can also be looked at in the context of a review. It is then assessed whether the corresponding methodology is suitable for achieving the objectives under the given circumstances. Table 2.43 shows the objectives of different reviews. Often the possibility of reviews is used far too little for (self-)critical retrospection, be it for the on-going phase controlling or for the evaluation of the whole project. Honest reviews are an opportunity to identify emerging problems while they are still small and solvable. In the agile approach, a sprint review takes place after each sprint (approx. every 4 weeks). Improvement measures are identified in the team retrospective. This creates a learning organisation that can react quickly to problems or changed situations. In the traditional approach, it should be examined to what extent such elements can be adopted from the agile approach.

2.5.6.5 The 90% Syndrome Relatively soon after the project has really got going, some project participants believe that a large part (90%) of the project work has already been done, as Fig. 2.70 shows. This phenomenon occurs because some feasible solution ideas are already emerging, for example a working prototype might already exist. However, the obstacles and as yet unknown problems that then arise in the realisation

184

2 Methodology

Stage of completion 100%

Es ti

ma ted

90%

ed

nn

a Pl

al

tu

Ac

Time End of project

Fig. 2.70 90% syndrome

phase are then underestimated. This assessment of one’s effort is typically very optimistic in the first half of the project and usually requires correction in the second half. Objective control methods are needed to avoid the 90% syndrome.

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

2.5.7

Deadline, Cost and Resource Control

2.5.7.1 Deadline and Cost Control For schedule and cost control, it is usually sufficient to compare the following key figures, as shown in Fig. 2.71. However, the current data required for these needs to often be compiled in time-consuming detail work (e.g. evaluations from reporting systems, statements from project staff, etc.). For this, the planned and actual data has to be available in a compatible form:

2.5 Realisation Phase

Schedule

185

completed in %

1

Duration/Costs according to initial planning

2

Forecast Reporting date

3 4 5 6

Time

Cumulative cost curve Costs

Planned

Actual Time

Fig. 2.71 Project status assessment and cost control

• Planned and effective duration • Planned and effective costs • Degree of fulfilment in % A project status assessment with cost control should take place in pre-determined intervals, which ought to be adhered to for the duration of the entire project (weekly, monthly, or quarterly). It is not always easy to say whether the costs incurred are sufficient for the services actually provided. In general, the following conditions are required for effective cost control: • Transparent cost planning • Rapid availability of the cost status • Periodic review of the projected final costs If significant changes are made to the task during the project or if there are large deviations between the planned and actual values, the original planning needs to be revised. For the remaining or not yet completed activities, the remaining duration (time-to-complete) and the expected remaining costs (cost-to-complete) are determined, as Fig. 2.72 shows.

186

2 Methodology

Time-to-complete

Cost-to-complete

Costs

d2

ne

n Pla

d1

ne

n Pla

l

tua

Ac

Reporting date

Time

Fig. 2.72 Time-to-complete and cost-to-complete

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

2.5 Realisation Phase

187

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

Profitability calculation Return on Investment (ROI) Net present value method Break-even analysis Dynamic Payback Method

188

2.5.8

2 Methodology

Project Changes, Change Request Management, Claim Management

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

Claim management (claim) The change has already been implemented Allocation of additional costs incurred: Who pays? More likely to lead to enforcement claims Cannot always be avoided with very extensive and complex projects

2.5 Realisation Phase

• • • • • • •

189

Customer wishes, customer complaints Development errors New insights gained in the course of the project Components or materials that are no longer available Amended rules General product improvements Possibilities for improving economic efficiency

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

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

1. Change Request and impact analysis (a) The applicant sends the change request to the project manager (b) The project manager has the application reviewed by all potentially affected project staff or departments on: • Cost impact • Timeline impact • Risk impact

190

2 Methodology

Change Request Project Distribution Back-End 1 Change request identification Creator:

Overall project manager

Identification no.:

Subproject / Work package

Overall project

(to be filled in by the project management)

Contact

Overall project manager

Creation date:

Title/short description:

Sale of Libero subscriptions

005

15.05.2022

2 Classification of the application / error message Category:

Postponement

(Please mark with a cross where applicable)

Change of responsibilities / organisation

Change / Extension

3 Effort estimation Sub-sector Additional costs for realisation Verbund - subscriptions

Expenditure external

Internal expenditure

CHF 350,000

160'000 CHF

Total

Total

CHF 510,000 CHF 510,000

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

5 Desired change - possible solutions Planned webshop to be implemented in first priority for the sale of season tickets. The sale of single tickets for public transport will be downgraded to 2nd priority.

6 Consequences of non-realisation Automatic renewal of BLS customers' subscriptions will be handled through other sales channels outside BLS from December 2022.

7 Supplements Further details are described in the documents of the steering committee.

8 Approval internal, department and area 15.05.2022

Submission amendment

Fig. 2.73 Template “Change Request”

Page 2 from 3

2.5 Realisation Phase

191

Change Request Project Distribution Back-End

Instances (electronic only, no signature required) Applicant

Date

Overall project manager

31.05.2022

9 Decision Reason Change will be realised

Appointment

Securing the sale of Libero subscriptions as of 31.05.2022 December 2022

Change will not be realised Documentation of any restrictions or conditions.

10 Signatures Commissioning instanceCommissioning Chairman Steering Committee

instance Overall Project Manager

_______________________________________ _______________________________________

15.05.2022

Fig. 2.73 (continued)

Submission amendment

______________________________________

Page 3 from 3

192

2 Methodology

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

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

2.5 Realisation Phase

Commissioning Prevention Delivery and service scope Contractual agreement on claim process

193

Initialisation Preparation Implement negotiation results for delivery and service in a contract Implement procedure rule in the project

Concept

Realisation

Implementation • Recognise possible claim events • Documentation • Factual and commercial examination • Clarify the facts • Compensate claim-related requests

Introduction Experience building • Checklists • Strategy • Procedural rule

Fig. 2.74 Steps in claim management

2.5.9

Checklist Completion Realisation Phase

Agile and traditional approach: • How well were all the objectives agreed upon in the project objective achieved? • How well do the results accomplished match the objectives? • Is the introduction of the solution to the user planned in such a way that it can realistically take place? • How are the accompanying measures such as training, adaptation of the organisation for the introduction seen to? • How broad is the acceptance for a successful introduction? Is it sufficient? Specific points of the traditional approach: • Have changes been systematically documented? • What successes do the planned checks and tests on the new object display: product, system, organisation? • Is a pilot test necessary before widespread introduction is initiated? • Which results were not achieved? What are the consequences? • For which deficiencies are there no corrective actions? • What specifically needs to be considered in the closure review? What open points remain? (continued)

194

2 Methodology

Specific points of the agile approach: • • • •

How did self-organisation and cooperation work in the team? Were the individual sprint objectives achieved? How was the team’s learning curve? Has the speed of development (velocity) increased over the course of the project?

2.6

Introduction Phase

After realisation is completed, the system is put into operation and introduced. In the case of it having had to do with product manufacture, serial production begins. Services are then actively offered or the new organisation is put into effect. Now the phase of utilisation begins. Here, experience is gained that can be used to improve the present solution and to design similar systems. When the new service or product has been introduced to the user, the project organisation has to be ended again, a process which includes appreciating what has been achieved and the drawing of lessons from what has taken place. Ideally, this happens when, after an agreed period of productive use of the developed solution, a retrospective assessment is undertaken together with the project owner and the user.

2.6.1

What Is Important in the Introduction Phase?

Steps of This Phase Table 2.45 shows the most important steps in the agile and traditional approach for the introduction phase. Results of the Introductory Phase A good introduction of the new solution and a complete conclusion with an evaluation of the project ensure that the project can be completed, leaving a positive overall impression. The project team it not to be allowed to fall prey to the “almost done syndrome”, and must not be permitted to inwardly say goodbye to the project before all pending work has been completed. Conclusions can be drawn from any mistakes. Other projects can benefit from the acquired and documented knowledge. When the project is finished, the following can be ticked off and stated: • • • • • • • •

System, product, service has been carefully handed over to the line Users can deal with it productively The acceptance protocol has been signed The recalculation has been carried out A documentation on expertise and experience is available The final assessment has been carried out The project team members are relieved and say goodbye to one another An appointment for a follow-up has been arranged

2.6 Introduction Phase

195

Table 2.45 Steps in the introduction phase Most important steps

What should be paid particular attention to in the introductory phase?

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

Table 2.46 Results of the introduction phase Principle

Processoriented results Contentoriented results

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

In the introductory phase, results according to Table 2.46 are relevant. People and Team With the introduction, all tasks, competences, and responsibilities are transferred from the project team to the internal or external customers. It is now a matter of

196

2 Methodology

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

2.6.2

Types of Introduction

The Introduction needs to be planned and prepared in good time. Ideally, an introduction concept is developed in the concept or realisation phase for the preparation of the introduction. A new solution can be introduced in three ways: • Abruptly on a defined date (big bang approach) • Gradually, sub-area by sub-area • Parallel: Old and new solution are operated simultaneously until the new one works and can be operated. It is often difficult to assess in advance how a system, a plant, or a process adaptation will perform in productive use. Despite good preparations and

2.6 Introduction Phase

197

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

Type of introduction, introduction procedure Introductory measures Introductory organisation Implementation planning Planning of the pre-acceptances and acceptances

Depending on the type of project, the introduction has to be planned meticulously. In certain cases, it makes sense to draw up a detailed schedule of the introduction with checklists. This should also show who does what and when. Such a schedule should be tested once or twice before productive implementation. When planning the introduction, it is also very advantageous to prepare a fall-back plan or a plan B. In the preparation, it is important to consider how the introduction will be carried out. In the preparation phase, consideration is given to how the transition from the old to the new can be shaped. The principles of organisational change management (Sect. 1.4.4) should be taken into account.

2.6.3

Acceptance and Commissioning

2.6.3.1 Acceptance In the previous phase, the product or service was realised and tested. Based on the tests in the realisation phase or on special acceptance tests, the deliverables are accepted by the project owner. The project owner can also delegate this competence, e.g. to the product owner in the agile approach. It helps if clear acceptance criteria have been defined for the acceptance itself. The acceptance criteria in the traditional approach should be based on the requirements and the solution concept. 2.6.3.2 Commissioning Depending on the type of project, commissioning and effective use of the plant, product, or software take place before or during acceptance. In the case of services or organisational adaptations, there is less talk of commissioning. In these cases, productive use takes place after acceptance. Depending on the size of the project, it makes sense to already carry out preliminary and partial acceptance in the realisation phase.

198

2 Methodology

2.6.3.3 Going Live in the Agile Approach In scrum, a release is formed from several sprints. A release is a deliverable product version that is put into production and made available to the users for use. The release plan is developed in the concept phase. 2.6.3.4 Pilot Test, Pilot Series When introducing new work processes or infrastructure in a company, it makes sense to test their practicality in a limited organisational unit by means of a pilot test or a pilot series and to only then extend it to the other organisational units, to companies of the group, or to other countries. If a prototype was able to be produced successfully, this does not mean that the manufacturing process has been mastered. By producing a pilot series with the intended manufacturing process, the processes can be optimised and any errors eliminated in time. 2.6.3.5 From Pilot Series to Serial Production During the transition from pilot series to serial production, the method may well get critically reviewed again. The following steps should be taken into account: • • • • •

Putting the new system into operation Preparing and monitoring introduction Consolidation, rectifying deficiencies Making and introducing organisational arrangements Handing over new system to users, starting serial production

2.6.4

User Training and Education

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

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

2.6 Introduction Phase

199

2.6.4.2 Types of User Training With any kind of imparting of new knowledge or skills, questions concerning the aim of the training have to be formulated: What do you want the participants to know or to be able to do after the course? Depending on the situation and requirements, the following possibilities are suitable: • • • • • •

E-Learning Training video (Youtube.com, Vimeo.com etc.) User manual Direct on-screen, online help Seminar, workshop Training-the-trainer or power user

2.6.5

Transfer to the Operational Organisation

In addition to the introduction, acceptance and commissioning and user training, the operational organisation needs to also be prepared and the realised results handed over to the operational organisation.

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

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

200

2 Methodology

2.6.5.3 Business Handover The realised results and the documentation are then handed over to the company. In addition to the application and operation manual, the system concepts, requirements, and solution concepts are also part of the documentation that gets given to the company. The operational organisation has to clarify whether and in which ways these documents will be further used. It makes sense to keep the product backlog as a basis for continuous development. Documentation should not be designed, set up, and continuously maintained only at the end, but during the course of the project.

2.6.6

Project Completion

At the end of the project, a final assessment of it is conducted. This serves to pass on experience gained and to provide the basis for project closure. Ideally, the project review includes different levels as shown in Fig. 2.75. The final project appraisal at the content level provides information on the following topics: • Assessment of the achievement of objectives – What was achieved and what was not? – What results were delivered? • Plan-actual comparison of costs and deadlines • Assessment of economic efficiency • Any follow-up inspections in the company, also after the expiry of the warranty period, for economic efficiency, etc.

Review from a meta level

Project start

Content level Relationship level Organisational level

Fig. 2.75 Project review

End of project

2.6 Introduction Phase

201

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

Introduction and training of future users Setting up and reviewing the successor organisation: Who runs the solution? Critical review: How appropriate was the project organisation? What can the company learn from this for later? Appreciation of team achievements, relief of project members Feedback of team members’ performance to managers Conscious dissolution of the project organisation Possibly offer support for the reintegration of team members into the line organisation • Organisation of the follow-up work and the subsequent review of success (follow-up control)

202

2.6.7

2 Methodology

Checklist Conclusion Introductory Phase

Agile and traditional approach: • Is it necessary and is there an intention to review the benefits formulated in the project order? • Were the results achieved in light of the project owner’s requirements? • Is the functionality of the product or service well realised? • Does the impact of the product/service meet the objectives? • Does the organisation that ensures the correct handling of the product/ service work well? • Has the final report been approved of? • Did the project team members have the opportunity to analyse the cooperation and give each other feedback? • In a joint review, were positive and negative experiences regarding effort, methodical procedure and cooperation evaluated and measures introduced to ensure the transfer of knowledge to other projects and the systematic process improvement? • Has a list of all open points been drawn up and their implementation planned? Is it clear to all those involved who it is that will complete which final work and by when? • Where will the project team members once again have adequate employment after the end of the project? • Do all beneficiaries of the project results know who to contact should future problems of some predefined form or other arise? • Who checks the sustainability and effectiveness of the project and when? • Who calculates—and when—whether the results planned in the profitability calculation have been achieved, what financial benefit the project unfolds, and how well this holds up to predictions made? Specific points of the traditional approach: • Have all project documents been created and completed? Has all the necessary information been handed over to the future users? • Has the documentation been checked for completeness and archived? • Has an acceptance protocol been drawn up and signed by the project owner/ customer? • Has the project manager carried out an assessment of the performance of the project staff? • Has excellence been identified and appropriately acknowledged? (continued)

2.7 Project Portfolio and Programme Management

203

Specific points of the agile approach: • Has the product backlog with not yet realised wishes, requirements, and features been handed over to the line or product management?

2.7

Project Portfolio and Programme Management

2.7.1

Project Portfolio and Multi-project Management

Organisations have many more project ideas than resources available to implement these. Therefore, a project idea has to fit the formulated strategy and fulfil the desired framework conditions until it finds a place in the strategic project portfolio. Management has to see to it that available resources are used in a targeted manner. The portfolio should prevent too many projects from being undertaken at the same time, and it should also prevent these projects from obstructing each other too much in the allocation of resources. Apart from the question of resources, however, there are also others needing to be answered in project portfolio management, as listed in Table 2.47. In order to establish the link between corporate strategy and project management (prioritisation), an overview of the “intended” and “on-going” projects has to be developed that is as complete as possible. A project portfolio is an overview of all existing projects and programmes, which are presented in the form of a structured list or graphically arranged according to different criteria. The multi-project management process includes the management of all project management processes of task configuration and project portfolio prioritisation and control. In practice, the terms project portfolio and multi-project management are often used to describe the same thing.

Table 2.47 Questions to be answered in project portfolio management What does the portfolio mix look like?

Too many projects?

Effects of project delays? Qualifications needed in the future?

Which are the right projects? When is the right time to start a project? Which projects are running at all? Which ones will still be running next year? Are all projects useful and necessary? Does the quantity of projects entail risks? Which are the really important projects? Will another project be affected? What does this mean for resources (finances, people)? Who is assigned to which projects? How much longer will it take? What do projects that are planned require? Are needed skills available?

204

2 Methodology

The project manager has to consider different intersections with the project portfolio management. First and foremost, he has to provide information about his project to the project portfolio management, including information on evaluation, dependencies, resources, or the progress of the project. The project portfolio management also gives the project manager instructions on the form of reporting or on the available resources.

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

Problem areas

Task areas

Bottleneck-oriented allocation of resources to strategic projects

Selection of not value-adding projects, duplications

Ensuring adequate use of evaluation tools

Lack of strategy orientation of projects

Alignment of project prioritisation to strategic requirements

Disregard of interactions between projects

Evaluation and visualisation of all project dependencies

Loss of control over the totality of projects

Establishing of consistent and method-based monitoring and review processes

Loss of project-related knowledge and experience

Establishing knowledge management tailored to specific requirements

Missing organisational regulations

Establishing a leadership organisation for multi-project-management

No timely project- and portfoliorelated information

Establishing an information system for multi-project-management

Fig. 2.76 Problem areas, task areas, and elements of multi-project management

Elements

Inappropriate resource allocation to projects

Multi-projectstructure

Coordination of projects and strategic budgets at corporate level

Multi-projectmonitoring

Overruns of strategic budgets

Multi-projectprioritisation

Use of consistent and objectively designed assessment and decision-making processes

Multi-projectconfiguration

Power-political frictions within the project selection

2.7 Project Portfolio and Programme Management

205

--

Multi-project configuration

Multi-project prioritisation

Realisation = Project Management

Control

Multi-project control

Structuring the multi-project management

Planning and decision

Fig. 2.77 Elements of multi-project management

central task in the start-up phase. Figure 2.77 shows the interaction of the elements of multi-project management (Kunz, 2007, p. 35).

2.7.1.2 Multi-project Management Process Figure 2.78 shows the ideal-typical multi-project management process. The first step is to configure the portfolio. The remaining steps are then run through repeatedly. Depending on the company, the multi-project management process is run through quarterly to annually. Individual steps such as reporting can take place in shorter cycles (e.g. monthly). The periodicity to a large extent depends on the project types. Companies with innovative and agile projects tend to have shorter cycles. On the other hand, a company with many construction projects may be satisfied with quarterly reporting. 2.7.1.3 Configuration of the Portfolio When configuring the portfolio, the following points need to be considered and determined: • Dimensioning the portfolio: Which parts of the company should be represented in the portfolio? • Evaluation criteria for project selection

206

2 Methodology

Planning and decision

Control

Configuration portfolio

Ideas Project requests Current projects

Reporting Planned – Actual comparison

Project portfolio Project assessment Resource availability Prioritized project list: Mandatory projects Projects under implementation Ranking of remaining projects

Content dependency

Fig. 2.78 Ideal-typical multi-project management process

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

2.7.1.4 Prioritised Project List Since organisations usually have more ideas and wishes than they can realise with the available means and resources, they have to select and choose the best and most

2.7 Project Portfolio and Programme Management

Strategic significance

207

Monetary value

Project priority

Political motives

Project risk + flexibility

Relative comparison

Project dependencies

Fig. 2.79 Influencing factors for project priority

suitable projects from the line-up of these ideas and wishes. Evaluative questions to be answered in order to find out, which projects are the right ones: Is it: • • • •

Those that make the greatest contribution to the strategy? The ones that are most urgent? Those that generate the greatest benefit? Those that to the project have the highest priority?

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

208

2 Methodology

Table 2.48 Priority classes and recommendations for action Priority class Mandatory

A

Importance for the company Legal requirements, existential for the organisation, mandatory software, or hardware updates Strategically aligned and/or high profitability

B

Positive economic efficiency

C

Low or negative profitability

Recommendation for action Full implementation

Full implementation, unless prioritised otherwise due to interdependencies Implementation based on ranking list taking into account interdependencies Do not perform

Priority Cost-benefit analysis

Project

Prio-Class

Priority

Urgency

20%

P1

Mandatory

1

Contribution to strategy

40%

P8

Mandatory

2

Economic benefit

30%

P6

A

6

Non-monetary benefit

10%

P2

A

7

100%

P5

B

12

Total

Fig. 2.80 Typical categories in project evaluation

Tables 2.49, 2.50, and 2.51 show possible evaluation criteria for the categories mentioned in Fig. 2.80. The assessment criteria are to be individually aligned to the company. Due to the changing environment of the companies, these assessment criteria need to also be continuously adapted to the latest circumstances. As the end result of the evaluation of the projects, a prioritised project list becomes available.

2.7 Project Portfolio and Programme Management

209

Table 2.49 Evaluation criteria for the urgency category Criterion Mandatory—Legal, regulatory, compliance constraints Mandatory—Technological constraints (HW, SW, security updates) Introduction date postponable Stage at which the project is

None (0 points) No

Small (1 point) –

Medium (2 points) –

Large (3 points) Yes

No

–

–

Yes

By 3 years

By 2 years Concept phase

By 1 year

Not movable

Early realisation phase

Late realisation phase, introduction

Idea, preliminary study

Table 2.50 Evaluation criteria for the category contribution to the strategy None (0 points) No contribution No reduction No increase

Criterion Contribution to the achievement of strategic goal XY Reduction of ICT costs Increase customer loyalty/customer satisfaction Opening up new markets Creation of competitive advantages Creation of innovation

No No No

Small (1 point) 25%

Medium (2 points) 50%

Large (3 points) 100%

25%

50%

100%

By 10% Yes Yes Yes

– – –

Table 2.51 Evaluation criteria for the categories economic and non-monetary benefits Criterion Net Present Value, NPV Return on Investment, ROI Expected benefit, added value Image gain Increasing attractiveness as an employer Improvement of quality, reduction of error rate Building up internal knowledge Minimising risks/lowering the risk index

None (0 points) Negative > 3 years None

Small (1 point) =0 2 years Low

Medium (2 points) – 1 year High

No No

– –

Partial Partial

Large (3 points) Positive 10%

– By 4 years

214

2 Methodology

To reach a level of excellence, critical success factors include the following: • • • • • • •

Criteria and methods have to be adapted to the company: What is important? Prioritisation system provides clear and unambiguous solutions Consistent and stable project evaluation methodology and criteria over time Prioritisation system is transparent and comprehensible to all stakeholders Data quality is a prerequisite for a good result Defined and lived process for multi-project management Support from top management

2.7.2

Lean Portfolio Management

The shift to agile approaches is in full swing in companies. The pace of change and market upheaval is forcing companies to evolve from traditional portfolio management to lean portfolio management. The prerequisite for the application of the lean portfolio management approach is the introduction and implementation of agile approaches (e.g. scrum) and scaled approaches such as SAFe or LeSS (Sect. 1.4.1.3) in the company. Table 2.53 shows the difference between a traditional and an agile approach to portfolio management: The comparison shown in Table 2.53 can be interpreted as constituting polar opposites. Companies that use rolling planning in traditional project and portfolio management already come very close to agile approaches. The authors advocate an ideal middle path, i.e. the use of elements from the traditional and the agile approach. The following prerequisites should be created for a lean portfolio management approach: Table 2.53 Comparison between traditional portfolio management and lean portfolio management (based on SAFe) Traditional approach Employees move from project to project and work on many different projects at the same time Project-related budgeting is carried out and the financing is monitored by the controlling department Planning is top-down and projects often follow inflexible annual plans Control is centralised. As a result, projects are often overloaded Detailed project plans full of requirements and business cases are prepared before work starts There is an alignment with work activities driven by waterfall, corner deadline, or stage-gate projects

Lean-agile approach Work is passed on to teams and value is created step by step in the value streams Funding is based on value streams and lean budgets Plans are value-added and customisable to achieve maximum customer benefit Strategic demand is managed decentrally in the value streams via portfolio kanbans Lean business cases are used to prioritise and fund the work that matters most There is an orientation and focus on resultsoriented value creation

2.7 Project Portfolio and Programme Management

215

• Lean approach to budgeting, financing, and governance • Value stream planning and alignment in the teams • Agile project management The lean portfolio management approach maximises value output, which means that planned investments are managed in a backlog in a portfolio kanban system. In doing so, the business opportunities with the highest value for the customers are continuously identified and aligned with the work in the teams in the value streams. This creates a balance between existing implementation capacity and demand for high value business opportunities and thus prevents bottlenecks.

2.7.3

Programme Management

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

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

216

2 Methodology

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

2.7.3.3 Distinction Between Project and Programme Management Table 2.54 shows the differences between project and programme management.

2.7.4

Project Management Office: PMO

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

2.7 Project Portfolio and Programme Management

217

Table 2.54 Project management versus programme management Characteristics Changes

Project A project tends to try to minimise changes (deadline, costs, quality)

Leadership style

The main focus is on the execution of the project and the creation of the defined, contractually assured deliverables

Management style

“Team player”, using skills and knowledge mainly for team motivation Orientation inwards into the project

Monitoring

Planning

Detailed work package planning, resource allocation, etc.

Scope

Usually, a well-defined, limited scope is pursued, focussing on the content, organisation, and relationship of the assigned project Customer satisfaction Deadline, costs, quality

Success

Programme A programme expects changes and responds to them if they appear promising in terms of achieving the strategic objectives The main focus is on relationship management and the resolution of any conflict situations such as project dependencies, programme and line, conflicts of interest, resource allocation, capital requirements Maintaining an overview, emphasis is on mission and vision of the programme Perspective shifting between projects and interfaces with projects outside of the programme. A view that systematically looks for potential synergies or risks that could endanger the programme Roadmaps as well as rules of action for project managers regarding planning (similar to QA specifications, risk management, etc.) Scope at programme level is broader and can undergo changes in order to achieve a strategic objective Return on Investment (ROI), KPI, achievement of the strategic goal or at least evidence of impact

• Support function: Support for the individual projects in operational project work, e.g. writing project documentations and reports and other traditional back-office tasks. • Advisory function: advise, coach, and train project managers and project staff, define and maintain process standards, provide methods and tools • Coordination function: interfaces and communication management (deadlines, content and scope, synergies). This includes resource coordination between the line and the projects. • Governance, regulatory function: strategic project portfolio management and project portfolio steering manages project prioritisation and approval of the project portfolio and project controlling in a multi-project company.

218

2.7.5

2 Methodology

Project Management Handbook

It is highly advisable for a project-oriented company to draw up a project management guideline in the form of a handbook that defines the rules applying to all project processes, making them binding. The project staff will adopt and live this project culture most quickly if they are able to understand the rules while also finding the document as a whole helpful, which is the case provided the document is lean and easy to understand, and if furthermore the employees were involved in the creation of the document and also if, lastly, useful tools are provided, e.g. templates, instruments, and checklists. In the case of complex projects, these guidelines are to be adhered to fully and strictly. For small routine projects, the steps are adapted to the entrepreneurial needs and applied in a scaled manner. For important projects, a form adapted to the project needs can be created. The project management manual is utilised company-wide. The project manual, on the other hand, applies only to an individual project. Possible topics in a project management handbook are: • • • • • • • • • • • • • • • • • • • •

Scope Definition “project” Project types (organisation, ICT, product development, infrastructure) Project categories (strategic, international, small projects) Overview of the process landscapes, value chain, phase plan, milestones, reviews, releases, traditional and agile approach Description of the activities, related documents Project organisation, team composition, steering committees Responsibilities, competences Stakeholder analysis, function diagram, escalation paths Scheduling and cost planning, multi-project management Information, communication Change request management Managing the risks Project controlling, cost and schedule monitoring, reporting Project closure Applicable documents, tools, templates, checklists Knowledge transfer, continuous improvement process Cooperation between line organisation and project organisation Competences, responsibilities, project manager career planning Glossary

2.8 Creativity and Innovation

2.8

Creativity and Innovation

2.8.1

What is the Difference?

219

The two terms, creativity and innovation, are often and erroneously used synonymously. Yet there is a clear distinction between the two interrelated approaches they refer to: Creativity is a thought process that ideally leads to an unexpected or unique idea for a solution or invention. Whether or not this idea actually turns into something that works is initially of secondary importance. That is why creativity is difficult to measure from a business perspective. The focus of creativity lies on originality. It is therefore about the question of how new ideas come about. Innovation is the process of transforming this solution idea into a new product or service, i.e. into something tangible: you can touch it, try it out, change it, make it. And if it works, then money can be earned with it; a result that can usually be measured. The focus of innovation is on effectiveness and feasibility. It is about exploiting an idea. Idea management is that part of the organisation which actively manages new ideas and suggestions for improvement within it. Ideas can come from employees but also from customer reactions thereby forming an important pool of ideas. Extraordinary ideas, giving the company a real competitive advantage, come from its employees. An environment promoting the development of creative ideas is a necessary thing. An environment that also allows enough time and space for experimentation, in which employees may fail with their ideas once in a while. In a rapidly changing business field, projects are often the biggest drivers of innovation for a company, e.g. when it comes to developing new products to market maturity or seeing to it that new technologies get accepted and thus become suitable for the masses. The ability to innovate is therefore one of the critical factors for companies wanting to remain successful in the long term. What a company can do to achieve this is described in detail in Sect. 2.8.4. The following section will show which instruments and methods are helpful for promoting and supporting creativity in the project team.

2.8.2

Finding Creative Solutions

The solution finding follows the goal formulation and is the creative part of a problem-solving process. In this step of the problem-solving process, the aim is to identify as many variants as possible after which the suitability of the solution ideas is examined. The best variants are finally evaluated by means of a systematic comparison. The methods of solution finding are mostly used in the concept phase in the traditional approach and in the realisation phase in the agile approach. In the creative phase of finding a solution, the project team should consciously step back from the real project environment and its framework conditions in order not to fall into “old familiar” patterns of solution finding. The more complex the problem is, the more versatile do different techniques and ways of thinking have to be applied and combined to find a good solution. The best way to have a good idea is to have a lot of ideas. (Linus Pauling)

220

2 Methodology

2.8.2.1 The Creativity Process Creativity is the ability of human beings to produce thought results of any kind that are essentially new and were previously unknown to the person who produced them. Creativity requires above all intuition, intelligence is secondary. Many creative solutions are prepared unconsciously. The facilitator should create a climate in this phase that promotes the independence of the team members and the fun of finding new ideas. The project objectives should appeal to the emotions and thus stimulate the curiosity of the entire project team. However, creativity is also often hindered by blockages. Such blockages are usually created or reinforced unconsciously by ourselves or by external influences and unfavourable circumstances. Creativity can be positively influenced by: • • • • • • • • •

A team that is able to work with little tension An informal working atmosphere Clear tasks and objectives The ability to defer judgement Different perspectives, optics, viewpoints Permission to turn things upside down Working with analogies from nature Allowing fantasies and images Visualisation of all contributions and ideas

Due to the way they work in the creative process, a distinction is made between intuitive-creative methods and analytical-systematic methods. In a solution process, several instruments can be applied one after the other, depending on the level of detail. A creative process takes place in four phases, see Fig. 2.84. These can flow smoothly into each other.

2.8.2.2 Brainstorming Brainstorming was developed in the 1940s by the American A. F. Osborn with the aim of allowing the stream of ideas to flow unhindered productively and effectively in a problem-solving conference. He separated the creativity process from the immediate discussion of the suitability of the ideas found. Prepare • Assemble a heterogeneous group representing the system (five to twelve people) • Designate moderator and “secretary” to visualise the ideas • Determine topic • Create a productive working atmosphere (space, time, environment) • Set time frame (20–30 min) • Announce rules: No criticism, not even non-verbal criticism (evaluation comes later), quantity before quality, let the imagination run free

2.8 Creativity and Innovation

Task 1. Preparation Preparation

221

Define, understand and clarify the task or problem. Collect information and activate knowledge. Known solution approaches in today‘s frame of reference. Unbiased consideration of the task or problem.

2. Incubation

Phase of unconscious further development. Departure for new approaches, distance from the known problem, distance from known tasks.

3. Illumination

Phase of meaningful insight. Solution ideas suddenly become conscious in their entirety. Synthesis of the unsconscious processes.

4. Evaluation

Phase of reflection and evaluation. The idea is checked for its usefulness and feasibility. Adjustments are still possible.

Fig. 2.84 The creativity process

Perform • Formulate the problem clearly • Write down ideas on an on-going basis for all to see • Let ideas be expressed spontaneously; do not discuss; do not criticise; intervene in case there is criticism • Welcome unusual ideas, but also steal ideas! • Give new impetus when fatigue sets in Evaluate • Group ideas • Evaluate ideas and eliminate unusable ones • Further concretise useful ideas • In the case of challenging topics, hand over the ideas to the specialists for processing • Give feedback to the group on what has become of the ideas It has proven helpful in practice to give impulses after the phase of initial fatigue by the facilitator in order to find the ideas that are “crazy” in the sense of the word in a second wave (Fig. 2.85).

222

2 Methodology

Ideas

well-known

crazy

withstand silence, distance, give new impulses Time

Fig. 2.85 Course of a brainstorming session

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

Addresses both the right and left hemispheres of the brain Sharpens the memory and increases the ability to concentrate Provides a good overview Helps save time Brings hidden ideas to a more conscious level

2.8.2.4 Brainwriting This creativity technique is suited for generating ideas based on concrete questions intending to tackle challenges of simple to medium complexity. It is equally well

2.8 Creativity and Innovation

223

Pack up Closing

Cleaning place Thank you mail

Music / Dance

Entertainment Event

Bithday Party

Shuttle for guests

Games

Decoration Invitations Drinks Preparation

Catering

Fingerfood Staff

Fig. 2.86 Example of a mind map

suited for idea enrichment. A brainwriting session (Fig. 2.87) proceeds in the following steps: Step 1: Each participant receives a prepared worksheet. At the top of the sheet is the question that is to be worked on. Below this, there are, for example, three empty fields on one line, in which each participant is supposed to write out three ideas for a solution. Step 2: Depending on the difficulty of the question, the facilitator now sets a time limit for working on this task. Each participant then develops solution ideas, and then passes the worksheet to the neighbour on the right. Step 3: Next, each participant tries to take up, add to, or further develop the ideas already described by his predecessor. He writes his modified ideas onto the next free line. Step 4: The worksheets are passed around until all participants have written a contribution onto all of the sheets.

2.8.2.5 Scamper This procedure is based on the model of the “Osborn checklist” (Alex Osborn) and consists of the following steps (Table 2.55):

224

2 Methodology

Birthday present for mother

A describes his ideas:

B complements ideas of A:

Idea 1

Idea 2

Other ideas

Flowers

Weekend excursion

...

Favourite color is purple

With father she went several times to ...

...

... to an island with many

...

C complements ideas of A or B:

Each person starts a worksheet on the top position and has his ideas complemented by the persons following up.

Fig. 2.87 Example: Brainwriting Table 2.55 Model Scamper Substitute Combine Adapt Modify Put Eliminate Reverse

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

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

2.8 Creativity and Innovation

225

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

226

2 Methodology

Understand

Observe

Defining point of view

Problem analysis

Find ideas

Develop prototype

Testing

Solution finding

Fig. 2.88 The six phases in Design Thinking

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

2.8 Creativity and Innovation

227

In design thinking, the motto is: every failure, if recognised at an early stage, is an advantage for the progress of the innovation process.

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

Solutions (Characteristics of the partial problems)

Shape of the table plate

Material

Wood

Shape of the edge

Support concept

Fig. 2.89 Example: Morphological box

Metal

Stone

Glass

228

2 Methodology

Table 2.56 Procedural steps of the analogy method Step 1 Step 2 Step 3 Step 4

Set the desired property or function Look for role models that have similar characteristics or functions Investigate the system that possesses or produces this property or function. Check whether and how the mode of action is transferable

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

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

2.8.3

Evaluate and Decide on Solution Ideas

The solution ideas for the individual sub-problems are partial solutions. Only the combination of solution ideas for all sub-problems results in a multitude of, often

2.8 Creativity and Innovation

229

new, overall solution variants. Creativity methods produce a large number of possible solution variants, sometimes even unusual or seemingly impossible ones. Not all combinations of ideas are useful as solution variants.

2.8.3.1 Analyse and Optimise Solutions In a first pre-selection, these solution variants are initially measured against the elimination criteria. If comprehensible partial solutions are available, for example as the result of a “morphological box” (Sect. 2.8.2.1), it becomes possible to optimise overall solutions by analysing the weaknesses of individual non-useful or suboptimal partial solutions and by replacing them if possible. For a sensible choice of solution, at least two variants are needed, whereby one of these can also be the existing current solution, the “zero variant”. Projects are characterised by their not pursuing a single solution in a linear way, rather by always providing several variants to choose from. The many ideas that have arisen need to be condensed into different variants. By combining known partial solutions, it is possible to shape suitable solution variants. The project team with its expertise first optimises and then limits the number of variants through selecting. The aim of creating variants is to expand the solution space. In this way, unsatisfactory partial solutions are systematically improved, solutions are optimised according to certain criteria (e.g. costs, weight), and “all” conceivable possible solutions to a problem are found. The goal is to first narrow down the solution space. In the concept phase of the traditional approach, the overarching solution concepts are elaborated in several solution variants. In large projects, it is advisable to have rough solutions confirmed by the project owner before the necessary detailed solutions are prepared for the realisation phase. The design of products and processes is becoming increasingly customer-specific due to the increasing transparency and globalisation of markets. Many products are offered in variants. In improvement management, an additional consideration of the product life cycle, i.e. of product usage circumstances (e.g. knowledge from complaints processing) and the production context (products, processes, and facilities) must be included in the creation of variants. 2.8.3.2 Decide Making decisions is often a very demanding activity and is therefore sometimes consciously or unconsciously delayed, delegated, or carried out carelessly for precisely this reason. In many cases, good alternative solutions are available, which are then not selected due to a messily made choice of a particular solution, be it for personal, political, or even largely inexplicable reasons. “Deciding” means to give up, to part with, different alternatives in favour of a possible chosen variant. Every assessment and decision is to a certain extent subjective. In the book “Fühlen, Denken, Handeln” (Feeling, Thinking, Acting), Gerhard Roth comes to the following conclusions: “All our conscious decisions, even those made after long periods of thought and consideration, are prepared and created by means of unconscious processes. Emotions have the first and the last word in decision-making processes. There are no purely rational decisions. Rationality and intellect are only advisors for

230

2 Methodology

decisions. The brain always decides on the basis of an expected reward situation. Avoiding or reducing unpleasant conditions is also a kind of reward. Reward expectations are mediated by feelings. it is first and foremost the emotional experience system that gives rise to desires, intentions, and plans, deciding whether what is planned should really be carried out now and in this particular way and not otherwise. This guarantees that we always perform all of our actions in the light of past experience. However, this does not exempt us from making wrong decisions. Understanding and reasoning are necessary for evaluating complex, detailed situations, retrieving and applying expert knowledge, assessing medium and longterm consequences—especially in the social sphere—and comparing alternative courses of action. Reason and intellect do not decide anything. This is done by the emotional system”. (Roth, 2001, p. 445).

2.8.3.3 Utility Analysis and Sensitivity Analysis For project management, this means that decisions, whether they concern new products, processes, or other behaviours, need to be prepared in such a way that they can be understood. By far the most common systematic method for this in practice is the utility analysis. The method looks objective, but accumulates subjective judgements. The utility analysis is carried out in four, at the most five steps: 1. 2. 3. 4. 5.

Determine and weight assessment criteria Assign values for the variants Multiply weights by the assigned values Determine the weighted total results in the utility values Analyse the sensitivity of the results

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

2.8 Creativity and Innovation

231

Table 2.57 Example: Value tables for “Car purchase” Criteria Weighting Vehicle A Vehicle B Vehicle C

Consumption (l/100 km) 20% 5.5 4.5 5.8 Table of values 6 l = 1 pt 5 l = 4 pts 4 l = 7 pts 3 l = 10 pts

Purchase price (€) 50% 21,800 29,800 25,500 Table of values 30,000 € = 1 pt 26,000 € = 4 pts 22,000 € = 7 pts 18,000 € = 10 pts

Operating costs (€) 10% 4800 3200 3900 Table of values 6000 € = 1 pt 5000 € = 4 pts 4000 € = 7 pts 3000 € = 10 pts

Range (km) 10% 620 850 500 Table of values 400 km = 1 pt 600 km = 4 pts 800 km = 7 pts 1000 km = 10 pts

Table 2.58 Example: Utility analysis “Car purchase” Elimination criteria Consumption < 6 l/100 km Purchase price < 30,000 € At least 5 seats Optimisation criteria Consumption Purchase price Reach Operating costs Total utility value Degree of target achievement

W

Vehicle A Fulfilled?

Vehicle B Fulfilled?

Vehicle C Fulfilled?

–

Yes

Yes

Yes

–

Yes

Yes

Yes

– W

Yes V

20% 50% 10% 20% 100%

2.5 7 4.0 4.6

W×V 0.5 3.5 0.4 0.92 5.32

Yes V 5.5 1.0 7.8 9.4

53%

W×V 1.1 0.5 0.78 1.88 4.26 43%

Yes V 1.6 4.0 2.5 7.3

W×V 0.32 2.0 0.25 1.46 4.03 40%

Legend: W, weight; V, valuation; W × V, partial utility value

sensitivity analysis helps. That is, weights or values are slightly changed and their influence on the ranking is observed. This sensitivity analysis determines how stable or sensitive an evaluation result turns out to be in the face of changed assumptions. If there is any doubt about the result or the ranking, the completeness of the optimisation criteria and their weights should be carefully checked. A risk analysis could also be consulted. If a solution involves high risks, it should be possible to assess this in the target criteria. Exclusion criteria, required or must-have objectives or framework conditions are mandatory, even if it all costs more or even if it takes longer. These include, above all, laws, safety regulations, and possibly also standards. The precise definition of an elimination criterion requires that its achievement can be clearly assessed

232

2 Methodology

at the latest at the end of the project. When comparing different solution variants, elimination criteria are only answerable by either a “yes” or a “no”. If clear criteria for a “yes” are absent, discussions are taken up about the achievement of objectives and the feasibility of the project. If the requirement of clear assessment cannot be met, an objective cannot formally be an elimination criterion. Optimisation criteria are objectives without elimination character. They are often referred to as “target objectives” or “desired objectives”. Since these preferences can be very sizeable and often contradictory, such as cost objectives, on the one hand, and cost-generating performance and quality objectives, on the other, optimisation criteria must always be provided with an additional indication: the weighting. The weighting is easiest to understand if it is expressed in the form of per cent values. Such a weighting is usually negotiated in the team, but it always remains the subjective result of the assessments made.

2.8.4

Innovation Management

Innovation defines who wins and who loses.

True innovation cannot be planned and controlled deterministically. Luck and chance are the constant companions of innovations. But at the same time, the probability of success of innovations is greatly increased by the use of a selection of instruments and processes, combined with innovation-oriented leadership and a strong culture of innovation. Innovation is controlled chance. The three levels of innovation management are: • Normative: discussion of vision, mission values, and mission statement • Strategic: central source for market differentiation and cost reduction • Operational: focus on the design and management of the innovation process Concepts for the following dimensions are to be created: • • • • •

Innovation strategy Innovation process Innovation controlling Innovation structure Customer orientation

2.8.4.1 Innovation Strategy An innovation strategy primarily defines the desired goal, which can be derived from the company’s vision and mission statement. The optimal innovation strategy depends on the selected markets and has to integrate aspects of technology, competition, and customer needs. The following dimensions are developed from this consideration:

2.8 Creativity and Innovation

• • • • •

233

Competitive innovation strategy (competitors) Market-oriented innovation strategy (customers, requirements) Technology-oriented innovation strategy Time- and resource-oriented innovation strategy Cooperation-oriented innovation strategy

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

Does the product really interest the customer? Can the product also be realised technically? Does the product support the company’s core competencies and its strategy? Is the company really better than the competition? Can the company also make a profit in the end? Is innovation controlling established?

2.8.4.3 Innovation Traps The Customer Trap The customer’s wishes are neither recorded in time nor precisely enough and the product is therefore developed “past the market”. It is the technically feasible and not the product actually desired by the customer that is realised. The Technology Trap Unforeseeable technical difficulties in the development or production are underestimated and the product fails while still in development or it cannot be brought to market in a reasonable amount of time. The Competition Trap Products do not offer sufficient advantages over existing competitor products. Competitors bring an equivalent product to the market first. The in-house development either becomes a “slow seller” or it has to be sold below value.

234

2 Methodology

The Profitability Trap The product is sold, but is not profitable because the costs for development, production, and marketing were underestimated, or the achievable prices, quantities, and thus revenues were overestimated.

2.9

Procurement

In many projects, goods or services have to be purchased in order to be able to provide the required service. Depending on the agile or traditional approach in the project, the procurement procedure needs to first be chosen well and then adapted. Depending on the organisation, guidelines or laws are to be taken into account for the implementation of a procurement. Such guidelines define the procurement process and are binding for projects to comply with. Public project owners have to comply with legal regulations and are also forced to follow the traditional procurement procedure in the agile approach, unless the legal possibilities allow for a dialogue procedure. In such cases, resources are often purchased traditionally by a company. The cooperation with the company’s employees in the project then takes place in an agile manner.

2.9.1

Procurement Procedure in the Agile Approach

Ideally, a product objective (product concept) (Sect. 2.4.2) and an initial product backlog (Sect. 2.4.3) will already have been worked out before the start. The role of the product owner (Sect. 2.3.8.4) should not be bought externally to ensure knowhow. Procurement in the agile approach is about the purchase of the most suitable resources. For this, it is advisable to realise a small test project together with several suppliers. The process involves that you: • • • •

Clarify procurement needs Select suitable providers Implement the pilot project Negotiate the contract and finalise procurement

This procedure is also called the dialogue procedure. For the purchase of goods and other services, the same procedure can be followed in the agile approach, or purchasing can instead be handled as in the traditional approach.

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

2.9 Procurement

235

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

Presentation of the company Staff structure: are resources with the necessary skills available? What would a possible project team on the part of the provider look like? Experience and references with similar projects Assessment of the complexity of the project to be realised Proposal for a project procedure: project organisation, roles and responsibilities, risk management, quality assurance

The identified providers are now sent the questionnaire, the product concept (product objective), and the initial product backlog. In the next step, the providers present their proposed solutions and answer to the questions to the evaluation team. Finally, two or three providers are selected for the implementation of a pilot project.

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

2.9.2

Procurement Procedure in the Traditional Approach

The process for comprehensive procurement is divided into the following steps where you need to: • Clarify procurement needs • Create procurement plan • Create tender documents

236

2 Methodology

• Carry out tender and evaluation • Negotiate contract and finalise procurement For smaller procurements, individual steps can be omitted. The duration of an acquisition process strongly depends on the complexity of the procurement item and the applicable specifications. Simple goods and services can be purchased within days or weeks. For complex procurements, the whole process can take several months. The duration for the implementation of procurements has to be taken into account in the project planning.

2.9.2.1 Clarify Procurement Needs The first step is to clarify and define what exactly needs to be obtained. The procurement has to be clarified in terms of the type of resource to be provided (personnel, tools, materials, services, partial deliveries, etc.) and its quantity. Procurement need is most easily formulated in the form of a specification (Sect. 2.3.3). Depending on the complexity, it can take several weeks or months to draw up such a specification. If there are precise ideas of the object of procurement, the description itself can also take the form of such a document (Sect. 2.4.5). Strategic considerations also play a role in the procurement of goods or services. In a project for internal process optimisation or in a product development project, it must be considered very carefully what one’s own core competence and the critical success factor or USP (Unique Selling Proposition) is. Competences in the area of critical success factors or the USP must be built up oneself and not procured externally. 2.9.2.2 Create Procurement Plan In the procurement plan, procedure and important key points for the process are recorded. The procurement plan is often also referred to as a procurement or tender concept. The procedure is coordinated with the requirements of the line organisation (procurement guidelines) and the legal basis. The procurement plan has to be taken into account in the project planning and can strongly influence the project planning depending on the duration of the procurement. The procurement plan provides answers to the following questions: • What is the object of procurement, what is to be procured and in what quantity and quality? • What are the expected costs for the procurement item? • What is the estimated financial procurement volume? • Do strategic partnerships or contracts with suppliers already exist that need to or that can be taken into account? • What does the market look like? Which and how many potential suppliers are there? • Which tendering procedure or procurement method should be used? • What are the parts making up the tender documents?

2.9 Procurement

237

• What is the detailed planning in terms of deadlines and lead times for the implementation of the tender? • What resources are needed to carry out the tender? Who is responsible for which activities? Table 2.59 shows the procurement methods and their differences. When choosing the tendering procedure, a distinction has to be made between private companies and public contracting authorities. In the case of contracting authorities, there are defined threshold values (financial procurement volume) that determine the tendering procedure. For contracting authorities, a distinction is made between the procedures according to Table 2.60. Private companies are free to procure in any way they want and are not bound by any threshold values, which means that you can write directly to potential suppliers in procurement or publish a procurement on a suitable platform and put it out to tender.

Table 2.59 Procurement methods RFI: Request for information RFQ: Request for quotation RFP: Request for proposal

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

Table 2.60 Tender procedure Invitation procedure, restricted invitation to tender Open procedure Selective procedure, non-open procedure

Contract by private treaty, negotiated procedure

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

238

2 Methodology

2.9.2.3 Create Tender Documents Once the object of procurement and the procedure have both been clarified, the tender documents can be drawn up. The preparation of the tender documents is a time-consuming process and usually takes longer than the execution of the actual tender. The tender documents consist of the following documents: • Main document (often referred to as specifications, tender documents or, in practice, often incorrectly as requirements specifications) • Suitability criteria • Award criteria • Description of the object of procurement • Draft contract Specifications, Tender Documents The main document is the overarching cover document of the tender documents. It serves as an orientation for potential bidders and regulates the course of the procurement procedure. Typical contents are: • • • • • • • •

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

Suitability Criteria The Suitability criteria describe the minimum criteria that a bidder has to fulfil. These are often requirements for the bidder in terms of performance, experience, or references. Minimum requirements for the object of procurement can also be formulated. Suitability criteria are to be fulfilled by the bidding company. Companies that do not meet the suitability criteria are excluded from the procurement procedure.

2.9 Procurement

239

Award Criteria Award criteria are used to determine the best offer. The award criteria serve to assess the quality and price of the service offered. It makes sense to declare these, their weighting, and how their fulfilment are already evaluated with the publication of the tender documents. This information is important for potential suppliers to be able to assess whether they want to make a bid at all or not. Description of the Object of Procurement In order to obtain good and meaningful tenders, it is advisable to describe the object of procurement qualitatively well, i.e. precisely and completely. The criteria to be applied should be analogous to those in the SMART rule (Sect. 2.3.2.4). Draft Contract To avoid difficult negotiations before awarding the contract, it makes sense to enclose a draft contract along with the tender documents.

2.9.2.4 Carry Out Tendering and Evaluation After the tender documents have been completed and released, they are sent to the potential suppliers or published on a tender platform. The potential suppliers are given a deadline for submitting their offers. During this period, the suppliers often have questions needing to be answered. After receipt of the bids, they are assessed and evaluated. In a first step, the fulfilment of the suitability criteria is checked, excluding companies that do not meet the suitability criteria from the procurement procedure. The best offer is determined using the award criteria. Depending on the situation, the bidders may be invited to a bid presentation. Each bid is assessed on the basis of the award criteria. The results of the assessment are summarised in a utility value analysis on the procurement object (Sect. 2.8.3.3). The best offer can then be easily derived from this. 2.9.2.5 Negotiate Contract and Finalise Procurement Often there are still open questions regarding the best offer having to be clarified and settled with the provider. These questions are clarified together with the negotiation of the contract. During the negotiation, the principles of conducting negotiations (Sect. 4.10) must be taken into account. With the conclusion of the contract, the procurement is completed. All bidding companies are informed about the award. If necessary, the award will be announced on the tender platform.

240

2 Methodology

References Kolb, C. (2014, November 26). Der agile Projektleiter—Bindeglied zwischen Scrum und klassischem Umfeld. ProjektMagazin, 17. Kunz, C. (2007). Strategisches Multiprojektmanagement (Konzeption, Methoden und Strukturen). Gabler Edition Wissenschaft. Roth, G. (2001). Fühlen, Denken, Handeln: Wie das Gehirn unser Verhalten steuert. Suhrkamp. Schwaber, K., & Sutherland, J. (2020). Der Scrum guide. http://scrumguide.org.

Further Readings Andresen, J. (2017). Retrospektiven in agilen Projekten—Ablauf, Regeln und Methodenbausteine. Carl Hanser. Cohn, M. (2005). Agile estimating and planning. Pearson Education Inc. Gloger, B. (2016). Scrum—Produkte zuverlässig und schnell entwickeln. Carl Hanser. Schweizerische Gesellschaft für Projektmanagement (spm). (2016). Swiss Individual Competence Baseline Version 4 Domäne Projektmanagement. spm und VZPM.

3

Human

In project management, humans are players. By definition, several such players work together in projects and communicate with each other. Therefore, it is important to understand people better in order to provide them with the appropriate framework conditions so that they may develop their full potential in project work and collaboration in order to deliver what is expected of them. In Taylorism, the human being was supposed to function like a machine. But we now know that man is not a rational being and cannot be explained purely on the basis of cause-and-effect relationships. Instead, humans are highly complex beings with identities strongly shaped by their environment, having a brain that changes shape throughout their lives (neuroplasticity). Project work is always a personal experience that is marginal, as innovation has to be created within limited resources. This chapter explains the basic features of the modern view of man, the topics of stress and change, flow, as well as motivation and meaning. These form the basis for self-management, which aims at achieving a selfdirected and self-responsible development of personal life. This chapter concludes with aspects of self-responsible further development and a description of the basics of interpersonal communication. People are always the same whether they are working in traditional or agile project management. The explanations in this chapter refer to both approaches.

3.1

Competence Model

The requirements and tasks for employees can be broken down into different competences (Fig. 3.1). The methodological competences are elaborated in Chap. 2. In this chapter, self-competence and personal communication are dealt with in greater depth. Chapter 4 describes the requirements for social, team leadership and negotiation skills. Depending on the role in the project, there are differently weighted competence profiles for the individual job holders. For project owners and project managers, these are presented in Sect. 2.3.8.5 for product owners and scrum # Springer-Verlag GmbH Germany, part of Springer Nature 2023 J. Kuster et al., Project Management Handbook, Management for Professionals, https://doi.org/10.1007/978-3-662-66211-3_3

241

242

3

Methodological skills – Project execution – Planning – Organisation – Controlling – Information & communication – Stakeholder Management – Risk Management

Team and leadership skills – Position & roles – Delegation & MbO – Dynamics in teams – Leadership styles & self-control – Lead & moderate meetings – Change in organisations

Expertise – As part of the project role

Negotiation skills – Leading negotiations – Negotiation cycle & strategy

Human

Self-competence – Conception of man, world view – Perception & awareness – Motivation & purpose – Self-management – Dealing with stress – Personal change & development – Culture and values

Social skills – Power & authority – Personal communication – Interdisciplinary & multicultural cooperation – Conflict Management & crisis – Handling resistance

Fig. 3.1 Competence model

masters in Sect. 2.3.8.4. Technical competence results from the respective task of the project content.

3.2

Conditions for Good Performance

Unfortunately, competences alone are no guarantee for successful project work. According to Sprenger (2014, p. 183 ff), good team performance depends on three influencing factors (Fig. 3.2): • Commitment (Willingness): Every person needs to want to perform a task. In order to achieve this, they give themselves inner permission. • Capacity (Ability): Being motivated is not enough for good performance. Personal skills have to be up to the requirements of the task. • Performance Capabilities (Allowing): On the one hand, the organisation needs to allow a person to perform a specific service (social allowing). On the other hand, the means of production and the capacities needed have to be available. With optimally developed capacity, performance is strengthened. The commitment to perform and the performance capabilities are not yet influenced by this. Often, attempts are also made to encourage project teams to reach a higher level of performance through additional motivational factors. Motivation is what primarily

3.2 Conditions for Good Performance

243

Commitment Personal Dare and Desire • Inner permission • Values, morals, self-esteem • Over- or underestimation

Social Dare • Rules and (unspoken) norms • Organisational culture Performance Capabilities

Behaviour Performance

Situational Enabling • Tasks, responsibility and competences • Situational conditions: resources, time budget, tools

Capacity Individual Ability • Individual skills and capabilities • Over- or underchallenge

Fig. 3.2 Conditions of good performance

influences the willingness to perform. Personal capabilities, such as methodological or technical competences, are not enhanced by it. Performance capability also remains the same for the time being due to motivation. Example

A young project manager who is motivated (commitment to perform) and well trained (capacity to perform) will only succeed if the organisational culture supports his work (performance capabilities). If he is empowered and respected by the “old hands” in the company for his function (social permission) and accepted into the informal network, his ability to act unfolds. In addition to this, he needs the time resources to successfully complete the task. ◄ The design of the performance capability is probably most often underestimated: There are always operationally very well-managed projects that fail only because they do not have a performance capability. The performance capability must at the

244

3

Human

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

3.3

Human Phenomenon

3.3.1

The Brain Is a Miracle

Neuroplasticity: The Brain Changes Its Shape Our brain consists of up to 100 billion nerve cells (neurons). Each individual neuron is itself connected to 1000–5000 other neurons by synapses. The constituent parts of the brain only work as a team: a neuron by itself cannot do much. Only when it connects with thousands or millions of other neurons does it unfold its capabilities (Esch, 2014, p. 68). A breakthrough in brain research was the realisation that the brain changes its shape. Neuroplasticity suggests that the brain develops its structure not only because of genetic markers, but also because of the experiences a person goes through during their life. When a person learns something, whether in terms of how to feel, think or act, neuronal networks develop in their brain. The more a specific neuronal network is used successfully, the more does it develop in the light of that success. Figuratively speaking, it develops from a trail to a highway. Neurons wire together if they fire together. Use it or lose it.

According to this image, the human brain prefers to take the highway. The human being is said to be a “creature of habit”. He loves the networks of thinking, feeling and behavioural patterns that he may have developed in childhood. These habits convey routine, security, and efficiency. Example

A project manager who has already handled many projects according to the traditional approach is very efficient in project planning and project management.

3.3 Human Phenomenon

245

If the employer decides to handle the projects according to the agile approach in the future, the routines and strategies of the project manager are suddenly no longer helpful. A demand is made of him to deal intensively with the agile methodology and to, for instance, find his new role as a product owner or scrum master in it. ◄ Life means change (Sect. 3.5.5). People are repeatedly confronted with the experience that the existing highways of feeling, thinking and acting are no longer purposeful. The only way to leave the highway is to train oneself bit by bit to follow a new behavioural pattern. This is very demanding. In the process, new neuronal networks develop in the brain, which requires much more energy than calling up the already existing habitual patterns, in other words: using the autopilot. The good news, however, is that thanks to neuroplasticity, the human brain can create new highways, in short, it is capable of learning. The reverse of this also happens to us humans again and again: neuronal networks that are not needed for a longer period of time degrade again. The brain has a very efficient energy-saving mode and functions according to the motto: “Use it or lose it”. Example

For the project manager as described above, it is therefore not enough to simply attend a seminar on agile project management and to then believe that one can take on the role of product owner again with the same assuredness and efficiency. What he has acquired in years of practice as a traditional project manager, he must now be able to let go of in part. He deals intensively with the agile approach and its critical success factors, such as self-organisation, developing the product vision or building the product backlog. In the process, his brain maps these new competences as new neural networks. This also means that his agile training will only bear fruit if he keeps practising the new approaches. If he is called back into a traditional project at some later point, he might have a hard time using the traditional planning tools again or developing a requirements specification. ◄ Where Is the Centre in the Brain? As part of the human central nervous system, the brain is its supreme organ of control. For a long time, the question remained unanswerable as to where the “control of control” was located within the brain itself. Today this function is assigned to the frontal lobe of the cerebral cortex, the prefrontal cortex. It forms the government or the executive committee in the brain and characterises the human species in a general way and each person in particular (Esch, 2014, p. 86). All experiences a person has in the course of his or her life are stored in the prefrontal cortex. It is there that, recurring experiences are condensed, the result, ultimately is a

246

3

Human

person’s inner attitude. Since all experiences become part of the brain structure of each person due to neuroplasticity, new attitudes can only be changed again through great effort. What is so special about the prefrontal cortex is that it is a coupled network with a cognitive and an emotional part. Every experience is therefore stored with the corresponding emotion. Although attitudes can be rationally justified by humans, they are always also emotionally anchored and can therefore be felt. For this reason, personal as well as organisational change that is only rationally justified cannot be successful. Sustainable change always needs to take place in a secure space in which people and organisations can make new experiences (Ballreich & Hüther, 2009). More on this in Conflict Management (Sect. 5.6.9). From Knowledge to Ability Reflecting, reasoning and the general functions of intelligence and intellect, also action control, are assigned to the prefrontal cortex. The knowledge that human beings over the course of history have acquired, be it in mathematics, language or the expert knowledge of their professional activity, serves them as a toolbox and is stored in the cerebral cortex. Figure 3.3 represents the relationship between data, information, knowledge and ability: Data is available in abundance in the digital age. Interrelated data becomes information. Information that makes sense for a person, then becomes specific

Data

Information

Fig. 3.3 Knowledge and skills (Pfläging, 2015, p. 36)

Knowledge

Ability

3.3 Human Phenomenon

247

knowledge. With knowledge we can solve problems. Knowledge becomes ability when we succeed in solving new, previously unknown problems. This in turn generates new knowledge. In order to implement knowledge, the boundary between knowledge and ability hast to be crossed repeatedly. This leads us back to the “trail and highway” metaphor. An ability that is able to generate new solutions thereby creates a new trail, which then gets expanded into a new highway through repetition. Practice makes perfect. Further elaboration on the strategies of personal change can be found in Sect. 3.5.6.

3.3.2

Basic Needs Determine Our Lives

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

248

3

Human

Vital security

Physical integrity

Performance

Self-development

Security

Recognition Social status

Fig. 3.4 Basic human needs (Largo, 2017, p. 183 ff)

Recognition and Social Status Humans, like many animal species, can only survive within a community. It is in a community that our ancestors developed a need for social recognition and a secure social position. This basic need can be satisfied in very different ways within communities. For some, the family is most important; for others, professional or voluntary work, etc. It is not necessary to be a project manager, CEO, club president or head of the family: “Most people are satisfied when they can occupy the social position that suits them and when they receive the social recognition they are entitled to expect on the basis of their performance” (Largo, 2017, p. 193). What is true for all people, however, is that all people want to be respected in their social position, however humble it may be. Any form of exclusion impairs well-being. Self-Development People want to be able to develop their innate abilities to the extent that is possible. Even children have a strong desire to develop skills and to acquire knowledge. However, children as well as adults tend to overextend themselves or to emulate ideals that they cannot fulfil. “Every child is born with an individual development potential in terms of the expression and maturation speed of its characteristics and

3.3 Human Phenomenon

249

abilities. Depending on the living conditions in which it grows up, it can realise its potential to varying degrees. However, even under optimal living conditions, the child cannot develop beyond its developmental potential. There is no promotion beyond a person’s individual gifted potential” (Largo, 2017, p. 114). Accordingly, it is not success itself that is decisive for a person’s well-being and self-esteem, but whether they succeed in developing their individual talents. Performance In their performance, people want to achieve specific results with abilities and skills they have acquired. People do not only want to perform in order to earn a living or to achieve social recognition. People also want to perform because that way they can experience self-efficacy and stimulate their self-esteem. How important the achievements are for children and also adults can be seen in our emotions: If we succeed, we feel joy and euphoria. If we fail in an important undertaking, we feel sad and distressed. If we are permanently underchallenged, we feel bored and frustrated. Those who are permanently overstrained and can never experience that they have achieved anything feel disillusioned or even exhausted. Achievement is also not about every person climbing Mount Everest, running a marathon or cycling around the world. It is about a person being able to perform at a level that is commensurate with their abilities or skills. Vital Security If people experience a lack of existential security or even lose it completely, this triggers overwhelming fears in them. People who are affected by poverty, war or displacement become deeply insecure emotionally as well as psychologically traumatised. Humans share an urge to take precautions and to create security with other species: the squirrel builds up stocks, the mole retreats into its cave system. Humans first lived in caves, then in stone huts and farms. Today, cities, provision systems or insurances of the modern world form the basis for an increasing sense of security, though people view what constitutes security very differently: some want to be able to pay their living expenses, others strive for wealth and power. For some, providing for life after retirement is enormously important, while for others that is completely secondary. "

Every human being is unique. The more choice and freedom to make decisions a person has in his or her life, the more they will try to shape their life in such a way that they can live out these freedoms as best as possible. One person strives more for status and recognition, for others security is much more important; there is no good or bad in this. But these expressions needs have an influence on the personality traits, which can be recorded, e.g. via personality typologies such as Belbin or MBTI (Sect. 3.10.2). The better a person knows himself, the more he can

250

3

Human

seek out an environment that best suits him, just as the cactus needs dryness and the reed needs wetness. Those who have a strong urge for recognition and social status will hardly feel comfortable as members of an agile team with collegial leadership. If feelings of security and connectedness are important to you, you will not be happy performing the role of product owner. In this case, it would be better if the two people swapped roles, provided, of course, that they also have the appropriate professional skills.

3.3.3

Human Perception

Selective Perception What we perceive (“take as true”) can never be objective. First of all, our senses have a “mechanical” limitation. We humans can only see light of certain wavelengths and only hear sounds of certain frequencies. Nor can we smell, taste and touch everything. Rather, our perception is a highly complex processing procedure, which has to always be evaluated purely subjectively and selectively: “The image composed of all these sensory impressions is admittedly not a true reflection of the actual nature of the external world, but merely the image we can form of this world with all our limitations”. Man has the unique ability to evaluate his perceptions. He can focus on specific perceptions from the external as well as the internal world and make them the centre of attention or leave them in the background as completely insignificant (Hüther, 2001, p. 103 ff). This perception is different for all people, since it is based on how intensively specific neuronal perception networks have been developed. Depending on how strongly we “sharpen” our senses to certain phenomena, we are then very sensitised to specific perceptions. In interdisciplinary project work, we become aware of these opposingly “sharpened” perceptions again and again: A technical expert, be it a computer scientist, a mechanical engineer or an electrical engineer, has a highly differentiated perception in the area of expertise with regard to the technical problem. These people may be much less sensitive to disruptions at the relationship level, omissions in the area of stakeholder management or even the importance of well-prepared and moderated meetings. This is no wonder, since they have invested decades of education and training in their domain and have built their professional careers precisely because of these skills. A product owner, on the other hand, may not get lost in technical problems at all. On the one hand, he has another function in the team and on the other hand, he would not have the technical competences to do something outside of his field of expertise. "

If it is assumed that people have different perceptions and thus different realities, it becomes obvious that it is advantageous to bring them “to the

3.3 Human Phenomenon

251

table” in order to let a common reality emerge. This is why joint collaboration or agreements are so important. A change of perspective is often useful: to put yourself in the other person’s place, e.g. the place of the customer, the user, etc. What is important from their point of view, what do they expect from the project? This is where stakeholder analysis comes in (Sect. 2.3.5), the questioning technique (Sect. 3.9.8) or the integration of other people into the project organisation (Sect. 2.3.8).

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

This phenomenon is important for human behaviour under stress (Sect. 3.5) and in conflicts (Sect. 5.6): The stressor or the conflict can completely take over the perception of individual project participants from one moment to the next. Perception then focuses on this subjectively perceived security-threatening aspect. Everything else that is going well may be faded out. In this situation, it is important for those responsible for the project to be able to narrow things down with those affected. Very helpful here, as a technique, (Sect. 3.9.8) is answering questions such as: • The relationship with the colleague is very strained. Was there a time when it was better? If so, what was different then? • On a scale of 1–10: How are the chances of success for the project assessed at the moment? What would it take to increase these chances by one point?

252

3.3.4

3

Human

Awareness and Self-Reflection

Between stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom (Viktor E. Frankl).

Frankl describes a very special characteristic of the human being: He is selfaware and therefore has the possibility to reflect on how he deals with the (selective) perception of stimuli from his environment and how he reacts to them. This space between stimulus and reaction is created by our consciousness: According to the Latin term “con-sciencia”, consciousness is an accompanying knowledge that is aware of one’s own state of mind and activities, but also allows one to distinguish oneself from fellow human beings and the environment (Rager & von Brück, 2012, p. 36 ff.). Hüther understands consciousness as the ability to become aware of one’s own sensations and perceptions, of one’s own “being-inthe-world”. Thanks to consciousness, primary processing procedures that underlie the brain’s performance are in turn made the object of cognitive processes (Hüther, 2001, p. 115). Example

So, we can lead a meeting and be aware of our own state of mind while speaking: “Do I feel stressed because of a colleague’s critical remark? Or am I talking too fast because I’m afraid I won’t be able to finish the session on time?” ◄ By being able to reflect on superficial feelings, thoughts and actions at a higher meta-level, the superficial level can be influenced, for example, by speaking more slowly or asking the meeting participants if the session can be extended. According to Frankl, our freedom lies in how the space between stimulus and reaction is used. Man, unlike animals, is not unconditionally at the mercy of his feelings and instincts. Rather, he is capable of controlling them through reason and subordinating them to long-term goals (Rager & von Brück, 2012, p. 93). So if a person is afraid, he will run away. If someone is made to feel uncomfortable in a meeting, he does not have to retaliate immediately in the heat of the moment. Of course, those sorts of feelings do come up in many meeting situations. We may feel hurt or humiliated. But despite all this, thanks to our consciousness and reason, we can keep our composure and categorise our being openly criticised by someone, be it through verbal and non-verbal communication (Sect. 3.9) and then still remain calm. This process, which summarises the reflections on the phenomenon of man, is simplified in Fig. 3.5. Not only perception is context-dependent, but also behaviour. This aspect is dealt with in Sect. 5.3.2.

3.3 Human Phenomenon

253

Fig. 3.5 Perception and self-reflection

3.3.5

Trust

Trust is a mechanism that allows us to deal with our uncertainty (Christoph Bosshardt).

Life is full of uncertainties. For example, if we were not able to trust that all road users will likely follow the rules, we would no longer get into a car. Without trust in the train driver and the train control system, we would no longer get onto a train. Trust is the basis and prerequisite of every qualified form of human community. Trust as Experience Like every human ability, trust is a mixture of genetic predisposition and learned behaviour. In order for the child to learn to trust, it above all needs a sense of security. This sense of security comes from how sensitively and predictably the caregivers respond to the child’s needs (Schneider, 2003). If the reaction of a parent is sometimes loving and then again there is an outburst of anger, the reaction of the caregiver or parent is no longer one the child can predict. This does not create security. The child also cannot build up trust, neither in itself nor in its environment. Trust can also be “learned” in adult life. For this, stable relationships that provide security are needed.

254

3

Human

Synonym for Trust: Closeness or Connectedness We trust people or organisations we feel close to or connected to. Trust is, like power (Sect. 4.9), always a relational matter. What is the basis of relationships? According to the philosopher Wilhelm Schmid, it is shared experiences. Relationships without regular shared experiences disintegrate. Family relationships also thrive on repeatedly meeting each other and thereby having shared experiences (Schmid, 2010). Confidence in the Professional World Everyone wants trust: Politicians want to be trusted by voters, companies by their consumers, managers by their employees and project managers from their project owners. However, this cannot be achieved with a wonderful speech or a nice commercial. What is needed is predictability and a feeling of security in this relationship with the other person. This is best achieved through interpersonal contact, which is why formal project communication is a basic prerequisite for cooperation. But it is only one among many. It, for instance, also needs the unstructured communication of something like lunch and the aperitif at the end of the day, so people can interact outside of their professional role and thus develop closeness and security with each other, making sustainable professional relationships possible. Those who lack trust show an excessive need for being in control of things, with a prevailing inner feeling of being lost. In working life, this is reflected in the inability to delegate (Sect. 4.7) and in a high degree of perfectionism: superiors who, as “micro-managers”, want to have every detail under control. Trust and Psychological Safety Trust and psychological safety (Sect. 5.4.1) have much in common. The main difference being that trust is something that is directed towards the future: “I trust you that I will get the concept by the end of the month”. Psychological safety, however, refers to the “here and now”: “Because I do not feel psychologically secure, I do not ask for help”.

3.3.6

Humour

Eckart von Hirschhausen, MD, is convinced that laughter is the best medicine. That is why he has turned away from his work as a doctor to devote himself to cabaret. He is a book author and hosts television programmes. Hirschhausen describes the battle of David against Goliath as a primeval joke of humanity: “The mighty giant Goliath is struck down by the physically inferior David with his slingshot. Wit wins against violence. And that is why the creative spirit is such a good weapon, especially when we ourselves are the enemy: murky thoughts, nasty pain or when the whole world is against us” (Hirschhausen, 2016, p. 447). It is a precious human competence to always be able to laugh at oneself. Instead of being angry and grouchy and judging ourselves harshly when we encounter a mishap or make a mistake, we can also try to laugh at ourselves. Humour allows people to not take themselves too seriously, to create an inner distance. Humour

3.4 Culture and Values

255

relaxes and also allows for a sense of detachment, of being less tenacious and better able to let go. In this way, humour also has an influence on our resilience (Sect. 3.8.4) and on our creativity (Sect. 1.7). In humour, man experiences that he is a social being. He can only laugh heartily in a community. Laughing together generates closeness and connection, which in turn creates more trust.

3.4

Culture and Values

3.4.1

What Is Culture?

Culture refers to norms of behaviour and values shared by a group of people (John Kotter). Culture is the totality of commonly shared basic assumptions, values, norms and patterns of orientation that have been developed by the people in an organisation to cope with the problems of external adaptation and internal integration, and which, according to common conviction, have proved so successful that they are to be passed on to new members so that they perceive, think, feel and act in the right way (Edgar Schein). Culture is part of your organisation’s memory. You could also say: corporate culture is like a shadow. You can observe it, find it beautiful or less beautiful. It exists and you cannot change it, although it itself is constantly changing (Niels Pfläging).

The Latin word root of culture refers to the management and cultivation of the soil. Culture is everything that man has created around himself. Culture has a visible and an invisible part: visible are, for example, verbal and non-verbal communication: language, greeting rituals, physical distance, food or architecture. With soil, you can dig deeper. Thus, culture also has a deeper and thus much more personal level: the way we think, feel and behave towards other people (Dumetz, 2012, p. 21). With this approach, other influencing factors are also relevant for culture, as Fig. 3.6 illustrated.

3.4.2

Organisational Culture

Every community has a specific culture. This is something that applies to every family as well as to every organisation and project team. According to the definition by John Kotter, culture is composed of: • Specific norms of behaviour: Shared or predominant ways of acting that have become established in a group. These persist because group members tend to behave in ways that transmit these behaviours to new members: – Those who conform will be rewarded. – Those who do not conform will be punished. • Common values: Values symbolise what we consider important and right and what we feel bound to. Our values determine our identity, which is why we also react very sensitively when we feel that our values are under attack (Sect. 5.6.6.8).

256

3

Human

Physical Distance Habits

Food

Culture Language

Religion

Tradition

…

Fig. 3.6 Influencing factors for culture (Dumetz, 2012, p. 22)

These values often still remain even after the composition of the group has long since changed. All this feeds into Edgar Schein’s pragmatic definition, “culture is the way we solve problems”. Many aspects of the organisation are invisible, especially to longstanding members. What is the flow of information? How do we talk to each other? How do we make decisions? How do we behave under pressure and stress? What happens when mistakes are made? What reputation do project managers have in the organisation: career springboard or siding? These questions and many more are part of the organisational culture. It is precisely because so many aspects of culture are so deeply entrenched that it is difficult not only to make them tangible but also to change them (Sect. 5.5).

3.4.3

Project Culture

In Sect. 3.4.1 the topic of cultural imprinting was described. Now we will focus on the specific project culture. This differs in varying degrees from the culture of the

3.4 Culture and Values

257

line organisation. For example, different rules, principles and values or ways of solving problems apply here compared to what is otherwise the day-to-day business outside of the project. While these culture-shaping elements are established in the line organisation and are difficult to change, they can be reprioritised, agreed upon and lived in the project sub-organisation. This is called subculture. Example

Culture-shaping elements can be: • Linking the project organisation to the line organisation (Sect. 2.3.8.8). • Project management approach: agile, traditional or hybrid. • Leadership style: from directive to delegative (Sect. 2.3.8.5) or collegial leadership with self-organisation (Sect. 4.5.3). • Personal communication (Sect. 3.9) with aspects such as “I or You message” or dealing with feedback. • Information- and communication concept (Sect. 2.4.10) and stakeholder management with formal and informal communication (Sect. 2.3.5). • Definition of the scope for the design and determination of the decisionmaking competences (Sect. 4.8). • Error culture and dealing with failure (Sect. 3.8.5). • Creation of the project name and project logo. ◄ Depending on the type of project, these elements may more or less differ from the line organisation. The more complex, the more novel a project is, and hence the more distinct the project culture will be from the line culture. For example, the culture of a standard project is usually more similar to that of the line organisation than that of a potential or pioneer project (Sect. 1.2.1); vice versa: in a specific project, the behaviour of the actors may well be animated by a special culture. In a project framework that challenges, outstanding results can also emerge. Culture-shaping thus influences behaviour and is indirect leadership. Only: the cultural difference has to be desired and communicated by the management in the company, otherwise the project might be rejected, i.e. might not get taken seriously. However, culture-shaping elements need to not only be wanted and formulated, but also lived, which is a great challenge for those responsible for the project, especially at the beginning. This is where the start workshop or kick-off comes in, where the new principles and rules are agreed upon and practised. Novel project cultures can also be a valuable experience for future permanent organisations. For example, scrum projects are precursors for self-directed organisations. This allows culture-changing measures to be linked to a “hard” project object or goal of this scrum project. The culture change is thereby concomitant. The complex topic of change projects is discussed in more depth in Sect. 5.5.10.

258

3.4.4

3

Human

Generations Y, Z, and Alpha in the World of Work

Each generation is described by the attributes of its time and has its own set of basic needs. Generations Y and Z (born 1980–2010) already represent the majority of the workforce. There is already a term “Alpha” for the upcoming generation born in 2011 and later, but they will not enter the workforce for a few more years. Line and project managers are challenged to bring about the inclusion of all generations and to optimally combine their different skills in the team. To achieve this, mutual understanding between younger and older employees needs to be promoted. This also means repeatedly finding a respectful way of dealing with the noticeable differences. The various basic needs are shaped, among other things, by the social framework conditions or the level of development of society, by the prevailing culture and value system and also by world-changing events. For project management, knowledge of the needs and expectations of the younger generations is particularly important. The following characteristics, needs and expectations of younger people in the world of work can be identified: • They are usually well educated and invest in their further education. • They are looking for meaning in their work: it must be interesting and above all meaningful. • They strive for autonomy and also take responsibility. • They have a technology-affinity and live in various systems. • Professional development is important to them, but it goes more in the direction of project or expert careers than in that of wanting to manage staff. • They do not let themselves get tied to their employer over longer periods of time. • They are committed, while also perfecting themselves. Work-life balance is very important to them: time sovereignty while working, doing away with the separation of work and private life, having enough time for the family, etc. • They tend to be critical of hierarchies and enjoy working in teams. • Shaped by the VUCA world (Sect. 1.1.2), they have a more open attitude towards change and are more successful in repeatedly engaging with and adapting to the changing environment. Of course, this is a trend, and these characteristics do not apply to everyone. The opposite can also be observed in certain people, be it an exaggerated desire for security, adaptation or for retreating into the private sphere. Modern project management should be able to offer the right framework conditions to meet these needs: Teamwork, creative freedom, decision-making authority, selforganisation, etc. instead of maximising money and status, enable an organisation to attract good employees on whom it depends today. For many (still) largely hierarchically managed companies, this is a great challenge. But experience shows that with the right framework conditions, the significant potential inherent in this can be used.

3.5 Stress and Change

3.4.5

259

Becoming Aware of One’s Own Cultural Imprint

How can you become aware of your personal cultural make-up? You cannot do it yourself. You need other people who greet you differently compared to what you are used to, who eat different food, tell different jokes or use different problem-solving strategies. The differences will help you see this more clearly. We can recognise certain things ourselves. However, a great deal remains hidden from our own perception. That is why feedback (Sect. 3.9.7) is so important. This is how we learn from other people what they notice about us. Of course, every human has the right to be the way he is or the way he wants to be. This has an impact on personal communication (Sect. 3.9), behaviour in conflict (Sect. 5.6.9), or in the conduct of negotiations (Sect. 4.10).

3.5

Stress and Change

The aim of our stress-response is not to get sick, but to be able to change (Gerald Hüther). Stress ensures that we are capable of high performance in a wide variety of environments (Clemens Kirschbaum).

3.5.1

Fight or Flight

Stress in humans sets off an ancient survival mechanism in preparation for fight or flight. When a person perceives a stressor (a stimulus or situation that poses a threat to personal goals or well-being), the release of cortisol and adrenaline leads to physical stimulation and the mobilisation of energy. This increases the blood flow to the brain and the perception of the sensory organs is directed outwards. The biological stress programme of humans makes a lot of sense from an evolutionarybiological point of view: it allowed humans to instantly prepare their organisms to various forms of danger. That is why the human stress reaction is not a health risk. Figure 3.7 shows the schematic sequence of a stress reaction. If an external stimulus (stressor) is perceived, the person’s tension increases and with it his or her capability. If the stressor is overcome within a reasonable span of time, relaxation sets in and with it recovery. If the tension remains, however, it first leads to permanent stress and exhaustion. We all need a certain level of stress to cope with our demanding tasks or to initiate important change processes, as expressed in the quotes by Kirschbaum and Hüther. In a state of overload, performance drops again. The main reason for this is that the focus of attention narrows with increasing activation. “Tunnel vision”, in a profound phase of wakefulness, helps one to concentrate on what is essential. However, if activation goes beyond “the good level”, task-relevant stimuli and information are blocked out when having to cope with complex demands, which causes capability to drop once again. In addition, strong activation can lead to

3

high

260

capability

Tension

Human

Relaxation Excessive demand

Exhaustion Vague attention

small

Recovery

External stimulus Period

Fig. 3.7 Schematic sequence of the stress reaction (Based on: Drath, 2014, p. 229)

emotional and cognitive symptoms of stimulation that can distract from dealing with the essential task (feelings such as fear, anger or rage, or disturbing thoughts, e.g. about a possible failure).

3.5.2

Psychological Stress

The biological stress response developed to physically ward off danger (being able to run away from a sabre-toothed tiger, for instance). However, project work is about psychological stress: whether it is caused by the delay of a milestone, whether the quality of a work package is insufficient or whether we see ourselves as confronted with an enormous pressure to perform. These stressors are not manifest, physical threats. That is why the assessment of our perception is so important. "

People have to ask themselves in stressful situations: “What is the focus of my perception? How do I evaluate this situation?” Is every deviation from the ideal necessarily an immediate threat to my self-esteem? Is it still possible, especially in difficult situations, to distinguish between personal performance (commitment and capacity) and the performance capabilities? (Sect. 3.2) What about your resilience? (Sect. 3.8.4).

3.5 Stress and Change

Ich get into stress:

261

Stressors

+

• • • •

Time and performance pressure Multi-tasking Social conflicts Disruptions & interruptions

Ich put myself under stress:

Personal stress amplifiers

• • • •

Indispensability syndrom Perfectionism Being a lone wolf Self-exhaustion

When I am stressed:

Stress reaction, activation

• • • •

Physical Emotional Mental Behaviour

long-term Exhaustion Illness

Fig. 3.8 Stress traffic light (Kaluza, 2018)

3.5.3

Stress Traffic Light

The art of personal stress management lies in being able to regulate the current level of activation in relation to the requirements of the task at hand. In practice, this often means reducing personal activation wherever and whenever possible. Coming up with the metaphor of a stress traffic light, Gert Kaluza subdivides individual stress competence into three parts: stressors, personal stress amplifiers and stress reaction (Fig. 3.8). Possible stressors in project work are deadline and performance pressure, multitasking, social conflicts or disturbances, and interruptions that hinder one’s efforts to concentrate. However, people themselves add to these stress events through their own personal stress amplifiers, such as wanting to be indispensable, being perfectionistic, not allowing others to help you or overtaxing oneself in one’s own demands. All this contributes to the fact that the effect of the original stressors on us is intensified. Every stressor ultimately leads to a stress reaction. This includes the physical and psychological responses of the organism reacting to the stress. People who are exposed to stress-induced strains over the long term may experience exhaustion or illness.

262

3

Instrumental

Stressors

Actively address requirements

• • • •

Self-mgmt, work technique Conflict management Maintain networks Further education

+ Mental

Personal stress amplifiers

Develop supportive attitudes

• • • •

Self-reflection skills Perceive reality Accept one‘s own limits Discover opportunites and meaning

Regenerative

Stress reaction

Recover and relax

• • • •

Relaxation training Sports and activities Enjoy everyday life Hobbies and breaks

Human

Fig. 3.9 Stress competence (Kaluza, 2018)

3.5.4

Stress Competence

People can develop stress competence on three levels (Fig. 3.9). Instrumental stress competence aims at enabling people to develop specific strategies to help them reduce their personal stress activation. At the level of stressors, the demands themselves are actively addressed. All aspects of selfmanagement and personal work techniques are helpful here, so are the skills of personal communication and conflict management and maintaining personal networks and space for personal development. Mental stress competence is based on the ability to self-reflect: to be able to observe oneself from an outside perspective in one’s thoughts and actions and from this to constantly develop new beneficial attitudes pertaining to the current situation. Regenerative stress competence works on the level of the stress reaction and includes sport, relaxation, enjoyment, and breaks to reduce the stress hormones in the body once again. What is important at that point in the development of our stress competence is that we do not just always keep doing one and the same thing, i.e. not just do sport every time to regenerate after stress, because that way the external stressors remain in place and the personal attitude towards them does not get reflected either. But simply reflecting on one’s personal attitude again and again and practising “affected calmness” is not enough in the long run either. Every now and then we need to be able to directly address a stressor, e.g. in the form of a social conflict, in order to arrive at a situation that is then once again tolerable to us (e.g. clarifying roles in a project or negotiating expectations with my superiors). The more stress reduction competencies we can develop on these three levels, the better we can time and again regulate our personal stress activation.

3.5 Stress and Change

3.5.5

263

Life Means Change

Most live in the ruins of their habits (Jean Cocteau).

It is a law of life that everything that lives can never remain as it is. Life around us is constantly changing. We ourselves also change through our daily positive and sometimes negative experiences. On the other hand, we constantly try to create as much security and stability as possible for ourselves and our environment. Security has a lot to do with predictability. Habits give us a lot of security. We create patterns of feeling, thinking and behaving that we can hold on to and that give us orientation. The problem is that these habits originate in the past: they involve our work techniques, our modes of interaction with other people or our reactions when facing stressful situations. In all the situations we encounter in daily life, we first try to react to these with a familiar pattern of behaviour because it gives us security: We know this has already worked in other situations. And so, often it is an adequate strategy. However, there are always situations in life, in which we have to break out of our established habits. The more we hold on to old habits, the more difficult it becomes. Breaking out of habits and developing new strategies is always a path into the unknown. It takes courage and self-confidence.

3.5.6

Personal Coping Strategies and Dilemmas

When current coping strategies and habitual patterns are not helpful in solving a new situation or meeting a challenge, the following three strategies are practical: 1. Change 2. Reassessment 3. Displacement

The external situation or one’s own behaviour is changed. The person adjusts his or her personal evaluation. The situation remains, but it is no longer evaluated as threatening or particularly challenging. The person tries to suppress the stressor.

The best strategy always depends on the challenge at hand, the personality traits of the person and his or her physical and mental condition. There are situations or events that are best suppressed. Other situations need change or personal reassessment. Project managers are often confronted with dilemmas: A dilemma occurs when a person or an organisation has to achieve two conflicting goals. Examples

• A company wants to respond to individual customer needs, but needs efficient production methods and thus standardisation. • Project managers or product owners want to maintain good relationships with their teams, while having to make unpopular decisions. • The magic triangle even represents a trilemma: An ambitious goal has to be achieved at a certain time with a limited budget. ◄

264

3

Human

Many dilemmas can only be resolved by changing the external situation or one’s own behaviour. If the dilemma remains unresolved, the causes of the contradiction need to be identified and tackled through negotiation (Sect. 4.10) or using various methods of conflict management (Sect. 5.6) or risk management (Sect. 2.3.7).

3.5.7

Burnout

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

There are no limits to the demands and expectations placed on a person by their professional and private environment: line managers, project owners, customers, suppliers, project and line staff, work colleagues; all other stakeholders in the project and then the personal private environment. All these people can make demands on a single person far in

Table 3.1 Forms of burnout Physical exhaustion Emotional exhaustion Mental exhaustion

Chronic fatigue, a feeling of weakness, physical pain such as head-, back-, muscle aches, weight fluctuations, sleep disturbances, increased susceptibility to illness. Dejection, helplessness, crying, uncontrolled outbursts of emotion, irritability, feelings of emptiness, despondency, loneliness. Negative attitude towards oneself, work and life. Increased feelings of inferiority, loss of self-esteem, increasing loss of contact and refusal to communicate; cynicism, suicidal thoughts, and aggressiveness.

3.6 Flow

265

excess of his or her capabilities. The human being is limited in his or her capacity and needs recreational space. In project management, the methodology provides important impulses to make complexity visible and to find a realistic way of dealing with it. Possibilities include clarifying the scope, stakeholder management or planning.

Without external help a sustainable personal change that a burnout requires is almost impossible to achieve. It is strongly recommended that those affected be supported by learning guidance from a coach. According to Paul Watzlawick, a return to the ancestral task would be a solution to the first order. There is a danger of falling back into the old patterns of thinking, feeling and acting. The next burnout would be just around the corner. Sustainable solutions need new approaches. During re-entry into one’s former, original job after a burnout, the person concerned, the line manager, and a coach should re-describe the job with its tasks, decision-making powers and responsibilities.

3.6

Flow

Another concept to describe healthy and unhealthy stress is the flow concept (Csikszentmihalyi, 2004). Mihaly Csikszentmihalyi’s research focused on the question of what makes a person’s life worth living, what he can “burn” for and what it is that gives him the energy to commit himself to things that promise neither wealth nor fame. He calls this state of existence “flow”, when a person completely forgets himself in the performing of a task and when his work emerges as if by itself. Musicians, for example, experience flow when the piece seemingly composes itself. Writers report that at some point, the characters in their novels take on a life of their own. Identical to all flow experiences is the fact that in these moments, any consciousness of self disappears. One becomes absorbed in the activity at hand and seems to forget oneself while experiencing an altered perception. The everyday worries that otherwise circulate in the mind are gone. In Fig. 3.10 shows the different states in which a person can find himself or herself. The concept relates the demands placed on a person to his or her personal abilities. The reference point is the centre. From this centre, each person positions himself in each task in relation to his abilities as well as he can, given the necessary requirements. The ideal state to which we should always direct our actions is “flow”. Here we experience the specific requirements as a high-level request, but our skills in this regard are also high. This is the basic prerequisite for us to enter this selfforgetfulness in which we forget everything around us and within us and are completely one with our activity.

3

high

266

Excitement

Requirements

Fear

Concern

Human

Flow Control

Apathy

Relaxation

low

Boredom low

Skills

high

Fig. 3.10 Flow concept (M. Csikszentmihalyi, 2004)

Example

An experienced scrum master enters this flow state the moment his scrum team is in a difficult situation. He feels that the way he intervenes is crucial for the scrum team to overcome the current technical or social challenge. If the scrum master is confident that he has all the competences to help the scrum team in this situation, he will be able to experience a feeling of flow. However, should he realise that he is confronted with phenomena he does not understand, he will experience a state of fear or concern in this demanding situation. These are all aspects of being overburdened. ◄ The lower half of the diagram shows what happens when a person has more skills than those that are currently needed: At best, one sees this as being in a state of control or even as being in a “comfort zone”. This is pleasant for a moment, but in the long run it is not a satisfying situation. Every person needs, for his own development, the feeling of being able to cope with a new challenge in a specific aspect of life. So, if we assign the same, experienced scrum master to a very simple project with a small, homogeneous scrum team, which also already has a lot of experience in agile project management, a kind of relaxation sets in for this person,

3.7 Motivation and Meaning

267

that eventually turns into boredom. The hardest to bear state to be in for a person in this model is apathy. In such a case, we see ourselves as being confronted with activities for which we do not feel qualified and which do not represent a challenge for us in any way, one does not feel at all that one is doing something that corresponds to one’s skills. This is how a technical expert may feel who, after years of research work, suddenly has to take on repetitive tasks such as those in production. Or a project manager who, after several large projects, is assigned a sub-project manager task. Underchallenge is even more dangerous than overchallenge! "

This model provides guidance on how people position themselves in a specific task in relation to the demands and personal abilities. The closer we get to a state of flow in this context, the healthier do we experience stress related to it. Yes, we notice that we even need additional challenges in order to experience this state. The starting points for then experiencing a state of flow are zones of control and excitement. The strategies for getting there, though, are quite different: a project manager who sees his employee enthusiastically has to focus on developing his skills even further, for instance through more training or coaching. For an employee feeling control or even relaxation, however, the focus is on how to meet higher demands, for example, through challenging milestones or more exacting tasks.

3.7

Motivation and Meaning

As we no longer saw meaning of our work, we began to talk about motivation (Reinhard Sprenger).

3.7.1

Goal Orientation of the Human Being

The concept of basic human needs implies that our behaviour is goal-oriented and that these goals derive from basic personal needs. In Sect. 3.3.2 it is explained how important the basic need of striving for achievement is in us and what direct influence this has on positive emotions. Through achievement, we experience ourselves as effective and are able to develop our creative potential.

3.7.2

What Is Motivation?

The Latin word root in movitum ire can be translated by: “to enter into that which moves man”

268

3

Human

Basically, motivation can be described as movement. Either: • “Towards” something called appetite, or • “Away from” something called aversion However, motivation is in no way standstill (Esch, 2014, p. 118). The motivational system plays an important role in humans. At the beginning of evolution, early forms of life had no such motivational system. Today, it is assumed that their motor activities were more or less based on chance. Later, the activities of living beings became connected to a system for perception and experience. This system was in turn linked to neuronal circuits. This created the basis for reinforcing precisely those activities that increased the probability of survival by means of a reward system (Esch, 2014, p. 126).

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

Opportunity to do what you are really good at Leadership quality Challenging and varied activity that is perceived as meaningful Colleagues Corporate goals, corporate philosophy

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

3.7.2.2 Intrinsic and Extrinsic Motivation Some models explaining motivation distinguish between intrinsic and extrinsic motivation. Intrinsic motivation is a self-control that enables the free flow of innate human energy. It motivates the respective person with the question of “why”:

3.7 Motivation and Meaning

269

• Why does an employee choose a specific company? • Why does a project manager commit all his energy to the project? Extrinsic motivation provides a person with motives that they did not have before. It therefore constitutes external control. Extrinsic motivation focuses on the question of “how”: • How can I encourage my project staff to perform better? • How can I ensure that my team achieves the annual targets?

3.7.2.3 Motivation Through Working on the Demotivating Factors The direct superior exerts the greatest demotivating influence on employees (Reinhard Sprenger).

Based on the “downside” strategy, see Sect. 3.10.5 it is much more effective to work on the causes of demotivation instead of asking how employees can be motivated even more (Sprenger, 2014, p. 200 ff). Sprenger identified the following sources of demotivation that need to be taken into account: • • • • • •

The boss knows it better and can always do more than you Decisions that are made alone and without support Excessive and unobjective criticism Dynamic, loud dominance-oriented behaviour Treating employees as if they were invisible Insufficient information that is one-sided, gets given too late, or is restricted in scope

To check their own attitude and approach, supervisors can ask themselves the following questions: • • • • •

Do I trust the employee? Do I know his strengths? Am I giving him enough space? Do I agree on the goals with the employee or do I impose them? Do I give him credit for his achievements?

3.7.3

Meaning as an Intrinsic Motivator

Meaning is what has significance (Tatjana Schnell).

A key intrinsic motivator is meaning. The Gallup study identifies meaningful work as an essential factor. This also plays an essential role for personal resilience (Sect. 3.8.4).

270

3

Human

3.7.3.1 What Is Meaning? Humans are the only living beings who have to explain the world to themselves in order to cope with life (Remo Largo).

Satisfying only one’s basic needs is not fulfilling. In trying to explain the world to himself, man inevitably encounters the question of meaning. According to the psychotherapist Alfried Längle, meaning is man’s lived answer to the question of “what for”. Man needs a reason for his actions. He wants to feel what he is there for and why he does things.

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

3.7.3.3 Our Way of Life Systematically Destroys Meaning According to philosopher Wilhelm Schmid (Schmid, 2010), we live in a time in which meaning is systematically being destroyed: In the past, for example, community and thus a sense of belonging was obligatory. In village communities, one had to participate in public life, whether by attending church or by following other traditions. Today, we live much more as citizens of the world. As a result, many of our meaningful relationships are disintegrating while at the same time the degree of specialisation of our work is increasing. It is much more difficult to still be able to see the effect one’s actions have. A person ought to be suited for his or her occupational task. The person’s competences (Sect. 3.1) should match the requirements of the job as closely as possible. The comparison of the weighted competence profiles in Sects. 2.3.8.4 and

3.8 Self-Management

271

2.3.8.5 make it clear, however, that the requirements for each project role can be quite different. Example

In one study, participants were asked to rate how they fit their work (coherence) • Only 14% of respondents said that the demands of their job and their skills were a good fit. • Sixty-two percent defined the fit as “more or less good”. • The remaining quarter rated the fit as “not good”. ◄ So, it is not at all self-evident that you will perform a role in project work that fully matches your competences, character traits, and your interests. It would probably also be too much of a demand to expect this. Therefore, the question arises how much fulfilment of meaning can be expected from the profession at all?

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

3.8

Self-Management

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

272

3

Human

• Jäger understands self-management as the targeted, self-directed and selfresponsible development of one’s personal life in the direction that someone feels is best for oneself in order to be successful (In: Steiger & Lippmann, 2008, p. 151). • According to ICB 4.0, self-management is the ability to set personal goals, review and adjust progress, and systematically complete daily work. Self-management includes dealing with changing conditions and successfully managing stress (ICB 4.0 PM, p. 53).

3.8.1

Human Self-Efficacy

According to the definitions, self-management is always about self-efficacy in some form or another. Even in the most difficult situations, people with a high level of selfmanagement competence manage to exert a controlling influence over their own feelings, thoughts and actions. This is why self-efficacy is also an important pillar of personal resilience (Sect. 3.8.4). People who only do what is expected or demanded of them live a life that has not connection to their personal ideas, goals and needs. Thus, their personal boundaries break up more and more. Feelings of powerlessness take over, which at some point even lead them to perceive of themselves as victims. If you feel like a victim, your environment and all the expectations placed on you are seen as threatening. This in turn leads to increased stress or even the danger of burnout (Sect. 3.5.7). Of course, we do not have free choice in everything we do. There are superiors, project owners or customers who make demands and requirements on us that we have to fulfil. For the protection of our own self-efficacy, the model of the sphere of control, influence and concern offers valuable orientation (Fig. 3.11). In the Sect. 3.3.4 it is stated that humans have developed the unique ability of separating their behaviour from their feelings and their intuition. From this it can be concluded that everyone has a sphere of control in which he can be self-determined. This basically concerns one’s own feeling, thinking and acting. In relation to project work, this includes areas such as personal work technique, communication or the shaping of relationships. Depending on the function and role of the respective person, the area of control expands: A product owner has clearly assigned decision-making competences, a scrum master has control over the course of the daily standups. For every human being, the domain of his control is limited. Next, in line of order, is his sphere of influence. A project manager can and has to exert influence where it regards his project order. The sphere of influence is upheld by constructive discussions, suggestions as well as by providing reasons and explanations. In the case of the project order, the project manager thereby exerts his influence on the project owner. The outermost layer is the area of concern: Seeing how the world market might develop or whether the new company strategy will be successful—this cannot be influenced even with our greatest efforts. That is why we need to also be able to

3.8 Self-Management

273

Concern „Affected calmness“

Influence Inquire, give reasons, suggest, discuss

Control Own feeling, thinking and acting

+ Experience of competence Self-esteem

Feeling of helplessness Victims‘ perspective

Fig. 3.11 Area of control, influence and concern

distance ourselves from such issues. If you want to protect your self-efficacy, you must not lose yourself in the area of concern. Here, any energy invested is wasted and in no proportion to the achievable benefit. People who want to manage and preserve their self-efficacy focus on their specific areas of control and influence. This is the means by which they experience competence. I can influence my environment with my competencies and personality traits. This in turn allows experiences of competence to take place—and it increases self-esteem.

3.8.2

Personal Competence Circle: Strengths and Weaknesses

I’m no genius, but I’m smart in spots, and I stay around those spots. (Tom Watson, founder of IBM).

Warren Buffet coined the term “circle of competence” For Buffet, the circle of competence is the personal reference line for deciding what someone should or should not do. As an extremely successful investor, Buffet only invests in companies the business models of which he understands. If he feels unable to do so, he cannot

274

3

Human

calculate a realistic company value and therefore cannot make successful investments (Dobelli, 2017a, p. 93 ff). Buffet may well be called a genius of his discipline. Despite his success, he stands out because he is aware of his limits. Or, to put it the other way round: it is because Buffet is aware of his limitations that he is so successful. For Buffet, by the way, it is not crucial how large the circle of competence is. The world today is so complex that each individual person can only understand a fraction of all that is happening around them. But it is precisely in this small area that the personal circle of competence lies, which can be the launch pad for a personal flight of fancy. "

What constitutes this circle of competence? The school education, the university lectures? For Dobelli it is obsession: it is what drove Bill Gates to programme or Warren Buffet when he invested his first pocket money in shares as a 12-year-old. In the field in which a person’s obsession lies that he will invest thousands of hours over the years. That, in turn, will make him really good at his discipline.

The circle of competence also has its pitfalls: Those who become more and more successful by doing something specific suddenly think they are good at doing anything. But a technology expert is far from being a good project manager. Or a good project manager is far from being a good managing director. Of course, it is possible to expand one’s own circle of competence. But this should be done consciously, in an honest consideration of one’s own strengths and weaknesses and also in the awareness that this will take a lot of energy and effort.

3.8.3

Time Management and Work Technique

How do you start your working day? Do you get your coffee, start your PC, read your email? That’s probably true for many who call themselves knowledge workers and spend their day in the office processing, transforming and passing on some form of information. People are fundamentally curious. You can see what’s going on in the emails and chat tools. But do you find your personal priorities realised through the use of these tools? Does your most important task for the day show up in these? Unfortunately not. Most of the time, colleagues, superiors or customers report in, who have expectations of you. If you at that moment start reading and writing (using messenger apps, for instance), your valuable working time is wasted. Of course, we need to communicate, and digital platforms have many advantages. Self-effective people adopt a working technique that allows them to effectively achieve their personal priorities. The priorities are, of course, very different for a project owner, a project manager or a technical expert in a project. How can you identify your personal priorities? This can only be done through your goals. You need to know for yourself what roles you have been assigned to and

3.8 Self-Management

275

urgent

not urgent 2

not important

important

1 Necessity • Critical path • Troubleshooting • Resources not available • Crises • Work under time pressure

Quality • Planning • Controlling, magic triangle • Innovation • Stakeholder Management • Negotiations • Risk Management

Illusion • Many meetings • Many E-Mails • Disorders • Colleagues want to get rid of work • Things we like to do

Waste of time • Irrelevant information • cc: E-Mails • Escape activities • Social Media, Web, Smartphone

3

4

Fig. 3.12 Time management matrix (S. Covey, 2020, p. 36)

what goals you need to achieve with them. Most of the time you do not only have just one work project, but are active in several projects at the same time or you have responsibilities in line tasks as well. In his traditional book “Der Weg zum Wesentlichen” (2014), Stephen Covey recommends that each person ought to define a maximum of seven roles for themselves (Sect. 5.3.1). For each role, you define specific goals on the basis of which you can reason out priorities. In a further step, you also divide the goals into specific tasks, which you in turn quantify by means of an effort estimation, and you schedule them within your personal capacities. Covey’s time management matrix has become well known. (Fig. 3.12), which distinguishes between urgent and important activities. What is the difference between urgent and important? We have to respond to urgent tasks. They need immediate attention. Colleagues call, customers send emails. Its about crisis meetings, production stoppages or short-term staff absences. "

Important tasks are as if they were invisible: this is where we have to act. Important tasks contribute to our personal goals and tasks.

The tasks that are urgent and important are in the quadrant of necessity. These have to be attended to immediately. Failure to do so would have immediate

276

3

Human

consequences. Non-urgent but important tasks are listed in the quadrant of quality. These are conceptual tasks such as planning, risk management, stakeholder management or communication; mostly, these are not activities that are actively demanded of one. We have to actively act on these tasks much more. If the quadrant of quality is neglected in project work, the consequence is foreseeable: more and more operational problems then get flushed into the quadrant of necessity. Negligent planning leads to unmet milestones, inadequate risk management generates massive additional costs, or insufficient stakeholder management leads to resistance or conflicts with stakeholders. "

We create our personal self-efficacy via the quadrant of quality. Whoever neglects this becomes increasingly controlled from the outside and thereby falls into the quadrant of necessity.

We can gain time in the quadrants of illusion and waste of time: In illusion, we think we are engaged in important tasks. But in relation to our goals, they are not. And example for this might be attending meetings simply out of habit that have nothing to do with our current priorities. Or we might be simply distracted by the news on our smartphones and on the internet or by news in social media. Active self-management challenges us again and again to reflect on our actions and to classify them via this matrix. Those who perceive themselves as being in a state of strong actionism for a large part of their working time need to ask themselves which measures in the quadrant of quality they can use to reduce the number of necessities. In the vast majority of cases, it will then be a matter of intensifying the work on the system, as explained in Sect. 1.5.2. The time for this can be found in the quadrant of illusion or waste of time. This requires that one is able to disconnect oneself from habits that no longer serve any purpose.

3.8.4

Resilience

3.8.4.1 What Is Resilience? Resilience is the maintenance or rapid restoration of mental health during and after adversity (Raphael Kalisch). Resilience is the ability to master crises through one’s own resources and to grow from them (Martin Seligman)

The high pressure to perform in project work is a great challenge to all participants in terms of personal resilience. The mode of action taken when facing resilience reveals itself in different phases, as Fig. 3.13 illustrates. After an event that has been subjectively assessed as a crisis, be it a failed project, the breakup of a (work) relationship or the loss of a job, everyone normally experiences a drop in capability (performance). One feels depressed, can no longer concentrate or has no more energy. In the worst case, personal capability is

277

high

3.8 Self-Management

Growth

dro

Recovery

p in

g pin Co

nce ma

Damage

small

Normal state

for

per

Capability

Crisis

Time

Fig. 3.13 Schematic functioning of resilience (Drath, 2014, p. 102)

permanently damaged after the crisis. Those who can use resilience as a resource regain their performance or even emerge stronger from the crisis.

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

278

3

Human

Future orientation Develop visions and goals

Solution orientation Problems can be solved in principle

Network orientation Being able to accept help, persons to rely on

Self-responsibility Learning from mistakes

Self-efficacy Feeling up to the demands

Acceptance Being able to accept crises

Optimism Trust that things will get better

Resilience

Virtues and character strengths (be capable) Needs and motives (be willing) Fig. 3.14 The seven keys to more inner strength (Jutta Heller)

Self-Efficacy Self-effective people are convinced that they can influence their environment and are not categorically at the mercy of their environments. They are able to realistically tie their own capacity to their performance capabilities in their project organisation (Sect. 3.2). Self-effective people have well-developed stress management techniques at all levels (Sect. 3.5.6) and also always manage to leave the victim role after having had difficult experiences. Personal Responsibility Taking responsibility for one’s own feelings, thoughts and actions characterises this personality trait. This also includes being able to accept and protect personal (capacity) limits. Self-responsible people to a high degree also have the ability of self-reflection. They are able to always question their own convictions and evaluations. Network Orientation Man is man’s best friend. Beneficial relationships and social networks provide solidarity and support. Relationships are therefore to be nurtured and protected. People with a high level of network orientation also tend to succeed in finding, as an alternative, other people to rely on after separations or relationship breakdowns and

3.8 Self-Management

279

in building new supportive relationships. Being able to accept help from other people without feeling bad about it or having a guilty conscience is part of this topic. Solution Orientation “He who wants to, looks for ways, he who does not want to, looks for reasons” (Harald Kostial). Think about solutions, activate resources. Get out of the “problem trance” and develop option, be open to new ideas and unfamiliar perspectives. Developing the flexibility to change methods and behaviours when they no longer work is as important as thinking creatively and trying out new things—or as creating and organising structures in chaos. Future Orientation Have a desirable, meaningful mental representation of the future: Meaning, values, visions, dreams, inner images and longing provide orientation in times of crisis. Seeing the future as a potential and taking active control of one’s life is part of future orientation, as is feeling largely responsible for one’s own well-being and knowing what one wants to achieve in the long term or recognising limiting assumptions and beliefs as well as focusing on the possibilities of the future: “He who is down on his knees cannot reach for the stars” (Raffael Kalisch).

3.8.5

Dealing with Failure

3.8.5.1 Failure at Roche and Dyson Severin Schwan, Roche’s CEO, outlined the success factors of the world’s largest biotech company in his speech at the Swiss Economic Forum 2015 (Müller, 2015). One of these success factors was: celebrate failures! Because the degree of complexity in the pharmaceutical business is very high, nine out of ten projects fail. By celebrating failures, a signal was given internally that it was worth taking a risk with projects. And often the insights gained from failed projects form the starting point and basis for the next projects. Unfortunately, this attitude has not yet become part of all organisations. The fear of making a mistake is still significant in many places. People are afraid of losing their reputation or even of being sanctioned. But what does it mean for project participants if they are afraid of failure? Where the fear of making a mistake resonates consciously or unconsciously, people cannot develop their creative potential. Especially in project work, which has the goal of creating innovation, which is always exposed to risk due to its nature, the attitude and corporate culture described by Severin Schwan is needed. Only those who do not dare to try anything new can lull themselves into the security of not making any mistakes. But those who want to create innovation accept from the outset that the path will be a difficult one and that the fruits of success will not be given to them easily.

280

3

Human

Example

James Dyson says of himself that he had to build 5127 prototypes before he was able to come up with the bag-free hoover. For Dyson, everything starts with failure: “Failure is the starting point: when something fails, you understand why it fails, and then you start thinking about what you can do to prevent failure” (Brand, 2017). ◄ Dealing with failure therefore always has two influencing factors: personal and organisational parts.

3.8.5.2 Personal Assets: Attitude Ute Lauterbach developed a simple formula for failure: failure = intended goal þ fall short Failure happens when we cannot achieve a goal. Fundamentally, of course, this is unpleasant, as failure interferes with our basic need to strive for achievement. This in turn affects our emotions: We feel sad and distressed. Of course, we do not want to and should not simply gloss over failure. But to get close to the attitude of a James Dyson, our project work will not succeed if we regard every failure as a personal defeat and feel personally degraded because of it. Based on Lauterbach, we can ask ourselves: Do I serve failure, or does failure serve me?

When I serve failure, I let it win over me. I devalue myself and tell myself that I did not make it. However, if failure serves me, I can ask myself, as Dyson did 5127 times, what I can learn from not achieving my intended goal?

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

3.9 Personal Communication

281

3.8.5.4 Fail Fast The failure of an idea does not mean that the person who had the idea has failed (Biswas, 2015).

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

3.9

Personal Communication

3.9.1

What Is Communication?

The term “communication” is a general collective term for all processes in which a certain information is sent (signalled) and received, even if it is not reciprocal (Iris Boneberg).

Mutual influence is called interaction. Communication serves interaction. Essential characteristics of interpersonal communication are: • Communication is always subject to interpretation. What we perceive as relevant information, what everyone personally considers to be “true”, is the result of a complicated selective perception (Sect. 3.3.3). Others produce “truths” that deviate from my “truth”. • Communication is more than simply an exchange of information. Since every person constructs his or her reality subjectively, communication always serves to reconcile the different individual constructions. • In communication, several messages are always sent and received simultaneously. Some are overt, others indirect, covert. Often, however, the covert is more important than the overt.

282

3

Human

• Communication does not take place only with those present being involved. Many absent people are also participants in the “communication game” in the background, by influencing the thinking and reactions of those present: What would the customer say?

3.9.2

Axiom Theory

A gesture or a facial expression tells us more about how someone else thinks about us than a hundred words (Paul Watzlawick).

The quality of communication is the spice of all relationships. However, communication is often also the cause of injuries and conflicts (Sect. 5.6.6.4). Under the guidance of the communication scientist Paul Watzlawick, five axioms were developed which represent the challenges of interpersonal communication: 1. One cannot not communicate. The boss comes into the office in the morning and says nothing. That also says something about how he is doing or what his relationship is with his staff. 2. Every communication has a relationship and a content aspect. Whoever it is that says something and how something is said always carries more weight than what is said. The relationship aspect determines the content aspect. In conflictual relationships, the content aspect loses almost all importance. 3. Communication is always cause and effect. The woman is annoyed because the man is nagging. The man nags because the woman is annoyed. 4. Digital and analogue communication. Verbal communication is referred to as digital. The non-verbal as analogue. In interpersonal relationships, analogue communication has a great influence, as the above quote describes. 5. Communication is symmetrical or complementary. Symmetrical: We talk at eye level: scrum team Complementary: There is a kind of hierarchy: project owner—project manager

3.9.3

Communication Square

The axioms 2 and 4 are taken up by Friedemann Schulz von Thun in the communication square. In this model, every message has four sides: Next to the factual content, which is always supposed to be the point, self-revelation, relationship and appeal resonate as part of each message (Fig. 3.15). The aspects of self-revelation, relationship and appeal are often not expressed verbally (digitally) but non-verbally instead (analogue) and thus get encoded via

3.9 Personal Communication

Factual content What I want to inform about «It is …» «You are …» Relationship What I think of you and how we relate

283

Self-revelation What I declare about myself «I am …» «You should …» Appeal What I want you to do

Fig. 3.15 The 4 sides of a message (according to Schulz von Thun)

tone of voice, facial expressions or gestures. In Schulz von Thun’s model, the receiver should have four “ears” according to the four-sided message, see Fig. 3.16. Depending on which side of a message and thus which ear is in the foreground for a recipient, his or her reaction can be quite different. Example

During a meeting, one person is busy with his smartphone. The project manager, who is chairing the meeting, sees this. Although the person concerned is not communicating verbally at the content level at the moment, he or she is sending a piece of information. What does the project manager do with this “communication”? If he listens by means of the relationship ear, he will feel annoyed or frustrated. He interprets the person’s behaviour as: “You bore me”, “Your chitchat is unprofessional”, etc. If he has a big ear for appeals, the project manager will look for the fault in himself and his meeting leader and try to change something: speak faster or work through the meeting points more efficiently. Inevitably, the project manager will feel stressed. Consciously or subconsciously, however, people also revealsomething about themselves with their smartphone. If the project manager can receive the non-verbal communication on the self-revelation ear, he has another explanation for it: maybe e.g. that the person is involved in very urgent business proceedings.

284

3

Factual Ear

Self-Revelation Ear

Focus on the matter, on objectivity „What is it about?“

What does he want to tell me about him? „What does he think about himself?“

Relationship Ear

Appeal Ear

Reaction to appreciation, proximity, distance, warmth, cold „What does he think of me?“

Human

What does he want from me? „What should I do?“

Fig. 3.16 The four ears principle according to Schulz von Thun

The person who can receive at the level of self-revelation leaves the problem and the cause of the corresponding communication with the sender. He runs less risk of being influenced by emotions that are unfavourable in the current situation. It makes sense if the project manager confronts the person, possibly only after the meeting, that it is important for him/her to concentrate fully on the meeting. ◄ In such a conversation, the project manager can use the “complete message” method by Schulz von Thun as a guide. This is to ensure that as much as possible of what was sent is also heard, i.e. received in its informational content: 1. if you . . . (factual content: concrete cause, concrete behaviour that set off something in me) 2. I feel . . . (self-revelation: describe what this does to me) 3. because I . . . (relationship: explanation of what is important to me about the relationship with you) 4. I ask you . . . (appeal: wish, expectation for the future)

3.9 Personal Communication

3.9.4

285

Communication Cycle

The axiom theory and the communication square are summarised in the communication cycle. When a person wants to send a message, he or she must put it into certain words or clothe it in an appropriate form of expression. Expectations, feelings or needs are encoded into digital and analogue communication. This requires the receiving side being able to decode accordingly. This decoding is a highly complex process that is influenced by, among other things: • Selective perception with the dominance of the human sense of sight (Sect. 3.3.3) • The quality of the relationship (2nd axiom by Paul Watzlawick) Different people, groups, committees, organisations hear and understand things differently, assign different meanings to the same words, thereby giving rise to different feelings. Misunderstandings are therefore predictable and normal. The result of the decoding process is then what makes it to the receiver; it is the important, relevant information that he or she takes in. This process revolves around the following questions again and again: • • • •

Perception: what do I hear and see? Interpretation and understanding: what does that mean? Sensation: what feelings does this cause me to have? Action: what does what I have heard make me do? Example

The project manager is chairing the weekly project team meeting at 9 am. One of the sub-project managers arrives a quarter of an hour late and scurries to his seat, mumbling an apology. At this moment, communication takes place. On the content level, the non-verbal communication has to do with the timing, the verbal level is the mumbled apology. In this situation, completely different reactions are possible from the perspective of the project manager: The project manager has a good relationship with his colleague. Just last week he had lunch with him and found out that his wife is in training this week, so that his colleague has to organise childcare alone. He knows this, understands and nods sympathetically to his colleague as he takes his seat. On the basis of the good relationship, he interprets the colleague’s lateness as a self-revelation regarding his private constellation. He continues the meeting calmly and then briefly informs the colleague about the points he missed. He asks how the colleague is doing and gives him an encouraging pat on the back. The project manager only maintains formal relationships with his colleagues. He does not care about an informal exchange with them and is focused on a professional and productive work attitude. He reacts hurt on the relational

286

3

Human

level because he feels that his authority as project manager is not being respected by his being late. He interprets his self-revelation as “I had something more important to do”, and possibly as an appeal the request “this meeting is unnecessary, having one only every fortnight would be more than enough”. After the meeting, the project manager immediately disappears into his office, no further exchange takes place. ◄ An identical situation can produce completely different consequences. In the first case, the solidarity of the project manager can deepen the relationship. In the second case, the incident can be the starting point for a conflict.

3.9.5

Meta-Communication

" Make the way we communicate with each other an issue.

The process of communication normally consists of a back and forth of sending and receiving (third axiom of Paul Watzlawick). It is a joint game between two sides, between action and reaction. In a systems theory approach, this means that it is not the behaviour of only one side that should be considered, but the rules of the interplay, the behaviour of both sides and their interdependence. Example

If, in the above example, the project manager “snaps”, feels disrespected, he can try to bring his authority even more to the fore. If the sub-project manager falls behind in a work package, this is commented on with appropriate sharpness. The project manager does not let the sub-project manager get to him: “At the moment we seem to be suffering from delays everywhere”. The sub-project manager then retreats and does not tell his project manager that he has been assigned to a higher priority project by his boss. This leads to further delays. These are criticised even more harshly by the project manager. ◄ The behaviour of both is dependent on that of the other. The cycle of an endless back and forth can only be broken if both talk about how they are communicating, relating to one another and in which ways both contribute to keeping the back and forth going. coming to an agreement about how we talk to each other is called metacommunication, see Fig. 3.17. "

The cause-effect feedback loop can only be broken through personal conversation. In the above example, the aim is for the two to address the problem as soon as possible in a bilateral conversation. For this, it is necessary that both get involved in the relationship to such an extent that personal aspects such as the family situation but also the emotional injury can be addressed. In the conversation, it will be important for both

3.9 Personal Communication

287

Discussion, how we talk to each other

Fig. 3.17 Meta-communication

persons to be able to explain the reasons for their own behaviour or feelings, especially from the perspective of a self-revelation. This means that a high level of communicative skills are required from both of them, such as the “I” message or active listening.

3.9.6

I and You Message

In verbal communication, it makes a big difference whether we are using an “I” message or a “You” message. With a statement that begins with an “I”, I refer to myself: • I am not satisfied with the result of your work. • I'll be annoyed if you’re late for our appointment. • I am worried that we will lose this customer if we continue to communicate with him in this way. In my statement, I emphasise the subjectivity of my perception and its evaluation. I describe on the level of self-revelation how something or someone affects me. If, on the other hand, I send “you” messages, I place my evaluation at the centre. I am no longer communicating at eye level and sound as if I am reprimanding another person:

288

3

Human

• You did that wrong. • You should pay attention to your punctuality. • You are not allowed to talk to the customer like that.

3.9.7

Feedback

In project work, communication often takes place in connection with the control of processes. This means that the behaviour of people gets addressed. This can take place with reference to positive cases (confirmation of a performance, a result) but also in response to negative ones (non-performance, criticism, misconduct). This response to behaviour is called feedback. Feedback is a communication to a person informing them how their behaviours are perceived, understood and experienced by others (Klaus Antons).

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

3.9.7.1 Structure of the Feedback The following model, based on the Management Forum Wiesbaden, describes the building blocks of good feedback: Perception • What did I see? • What did I hear? • What have I observed? Effect • What set this off for me? • What impression do I have? • What emotions did it evoke in me? Wish (expectation) • What behaviour do I hope for in the future? • What do I expect from you by when? • How can or will I support you?

3.9 Personal Communication

289

Statement

Appeal

Encode

Self-revelation

Factual content Decode Selective perception

Relationship

Sender

Recipient

Selective perception Feedback

Fig. 3.18 Communication circuit

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

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

I am aware

I am not aware

others are aware

3

1. Public Person Arena of free action: Area which everybody knows

3. Blind Spot How others perceive me, behaviours not known to me

others are not aware

290

2. Social Facade Hidden characteristics: my privacy, my secrets and needs I do not want to share

4. Personal Unconscious Neither accessible to me nor others

Human

Fig. 3.19 Johari window

our own behaviour from others. At the same time, we also check what actions of others set off in us. Now there are things we know about ourselves and things we do not know. Likewise, there are things that we make freely available to others and those that we keep to ourselves. For this purpose, the two social psychologists Joseph Luft and Harry Ingham have designed a team development model, the Johari Window (Fig. 3.19). It helps us to better perceive interpersonal relationships. Thanks to our consciousness and the ability to self-reflect (Sect. 3.3.4), it is possible for us to understand ourselves. This is represented in the left square by the fields “I am aware” lying vertically below each other. I am prepared to share part of this with others in a public person way. In professional work, however, we are often unwilling to share our entire private sphere with colleagues. Luft and Ingham refer to this part of our person, which we are conscious of and that is known to us, as the “social facade” or private sphere. Of course, every person also has a subconscious part. This remains hidden from the person himself as well as from his environment.

3.9 Personal Communication

291

Examples

A product owner in the finance industry, always smartly dressed, loves to go for a ride on his Harley-Davidson at the weekend in his black leather jacket. He shares having this “social facade” only with his assistant. This morning I have a severe headache, but I don’t tell my work colleagues. They wonder why I attend the meeting with little energy and enthusiasm. ◄ Relevant for feedback is above all the “blind spot”. These are aspects of our behaviour that we ourselves are not aware of, but which others notice. Example

Normally, the product owner has a winning personality. He takes time for the team members and is good at listening. In the current, important project, a new scrum master has been assigned to him, whom he does not yet know. This stresses him out. He often does not let him finish talking by interrupting him. Due to the difficult day-to-day routines of the project, the product owner is under more stress than ususal. In addition to this, he does not understand that a new scrum master has just been assigned to him for the current, strategic project. Under these circumstances, feedback from the product owner’s established colleagues is very valuable. They can make him aware of what is happening in his behaviour and also in the communication with the scrum master and how this has changed compared to previous projects. In this way, this can be made conscious and finally also worked on to the benefit of team development. ◄ Through feedback (Fig. 3.20) one’s own “blind spot” can get reduced and one becomes aware of one’s own behaviour. This also makes areas visible in which it makes sense to receive support from the team. If I explain my own behaviour to others on the basis of feedback and thus reveal my “social facade”, I can be freer and more open and become more predictable for others. If all of us who are involved carry out this process to further team development, then trust, and relationships develop. This can also be used positively in different ways, for example, by assigning certain tasks in cooperation according to the concept of Belbin team roles (Sect. 5.4).

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

292

3

others are not aware

others are aware

I am aware

Cooperation is facilitated by the expansion of the field of free action

Human

I am not aware

Change through giving and taking active feedback

Change through openness for own and others ideas

Fig. 3.20 Johari window: Further development through feedback

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

3.9 Personal Communication

293

Receive Feedback • • • • • •

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

Feedback allows me to learn how I am seen by other people. Feedback reinforces positive behaviour. Feedback serves to clarify relationships between people. Feedback straightens out behaviour that is not helping the group. Feedback helps to better understand the perceptions and behaviours of others.

3.9.8

Questioning Techniques

An open heart and an open mind depend on us not stopping to ask. An exclamation mark always puts an end to everything (Bertrand Piccard).

According to the systemic worldview (Sect. 1.6.2) we can never “know” what someone is thinking, how they are doing or what is bothering them. The only way to find out is to ask questions.

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

• • • • •

Do you get along with your boss? Do you speak French? Is this a photo of your children? Do you have any questions? Are there still risks? ◄

Closed questions are contrasted with open ones. The latter are intended to . . .

294

• • • • • •

3

Human

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

• • • • •

How is the cooperation with your boss? Which languages do you speak? Who are the children in the photo? What other questions do you have? What are the main risks from your perspective? ◄

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

3.9.8.2 Active Listening Technique and Method In the communication cycle (Sect. 3.9.4), it is impossible for something to be decoded exactly as it was encoded. The “translation errors” can be recognised and corrected by active listening. Active listening always means “wanting to understand”. On the one hand, the receiver of a message can reflect back to the sender what he or she has understood. But I can also use active listening in meetings if I have the feeling that the meeting participants are talking past each other, if I want to get to the heart of something or if I want to reduce the pace of the conversation. Active listening allows the listener of the message either to confirm a piece of information or to formulate it more precisely or to have the other person clarify statements that were not intended. Example

Active listening checks whether the other person’s statement has been correctly understood:

3.9 Personal Communication

Stage 3

Stage 2

Stage 1

295

Verbalise emotions - Capture mood - Assumptions about perceptible emotions - Mirror feelings

«Your emotions»

Formulate core statement - Summarise - Mirror - Feedback

«Getting to the point»

Establish relationship - Eye contact - Create framework - Listening nod

«I am all ears»

Fig. 3.21 Active listening as a basic attitude and developmental support

• Did I understand you correctly that you will complete the new draft feasibility study by the end of September?

• In my words, that would mean we can’t deliver the specification to the client yet until the head of development confirms the test results for the prototype? ◄ Active Listening as a Basic Attitude and Development Support The model was originally described as a technique by the American psychologist and psychotherapist Carl Rogers in 1942. In 2005 Friedemann Schulz von Thun derived a basic attitude from that and in 2013 Eric Lippmann formulated a coaching intervention. An effective coaching method can be seen in the three-stage model of Active Listening (Fig. 3.21). This coaching is about “wanting to understand empathetically” (Schulz von Thun), and about reporting back the content and emotional state of one’s counterpart (Lippmann), whereby that emotional state is included in particular in the 3rd stage. In this way, the coachee can recognise where his emotional “entrapment” with the situation comes from. Stage 1: Establish Relationship At the relationship level, signal to the interlocutor that I am “all ears”. In this phase, the framework for the further conversation is created and trust is built up, which is necessary later so that personal feedback is also made possible.

296

3

Human

Stage 2: Formulate Core Statement By asking questions and summarising, an attempt is made to work out the essentials, the core message. Here it is important that the interests become visible. Feedback about the situation is also part of this process. The interviewee should be able to “get to the point”. Stage 3: Verbalise Emotions With questions, hypotheses, assumptions, the coachee is supported to express his/her feelings, be they verbal or non-verbal. Active listening consists of the coach trying to put these feelings into words: “ . . .and you are quite angry about that. . .”. Even if this assumption is not exactly true, it often helps the coachee to clarify his/her feelings. This kind of listening is also called “mirroring”.

3.9.8.3 Other Question Types Below are listed other types of questions that can help you to maintain an open spirit regarding this process: • Circular questions allow the perspectives of other people to be included in the conversation, thereby incorporating further perspectives: “If I were to ask your supervisor, what would he say?” • Goal-oriented questions allow you to clearly define an objective: “How can you tell if the objective has been reached?” • Resource-oriented questions are used in difficult situations to help the counterpart become aware of his or her resources: “Was there a time when the working atmosphere was better?” • Scale questions ask the counterpart to move from the emotional level to the rational level and give an evaluation of a situation: “On a scale of 1-10, how would you rate your performance?” • Hypothetical questions prompt the other person to think through a scenario again on the basis of an assumption: “If person A were to leave the project team, what would be the consequences for team performance?” • The heart question is used to question positions in order to find out what is close to a person’s heart: “What exactly is important to you in this?”

3.10

Personal Development

We cannot live just any life, but only our own (Remo Largo).

In Sect. 3.5.6 the three strategies available to people for dealing with challenges, and thus also for personal development, are explained: Change, reassessment or displacement. Here, further aspects are presented that can support the reader in his or her personal development.

3.10

Personal Development

297

World of work Work Profession

World of relationship Partnership Family

World of one‘s own Space for yourself and others

Fig. 3.22 Life worlds of humans (Based on: Walser & Wild, 2002)

3.10.1 The Three Living Worlds The career choice that brought you to project management is hopefully not just coincidence, but also has something to do with your basic needs (Sect. 3.3.2) and competences (Sect. 3.1). Gainful employment lies at the centre of life for many people in our culture. The explanations on the topic of meaning reveal that it would be an excessive demand on gainful employment to therein expect a very high degree of accommodation for this topic (Sect. 3.7.3.3). It is therefore important to take a holistic approach to self-responsible further development. Here the model of the three living worlds helps (Fig. 3.22). In this model, the world of work stands on the foundation of the world of relationships and the world of one’s own. The world of work is of course not only understood to mean gainful employment, but also family or voluntary work. However, human beings as social beings need more in order to have a flourishing existence than simply “just” work. Above all, the quality of our relationships has a significant influence on our psychological well-being. Of course, we also want to maintain good relationships within the world of work. But in this field, relationships are always also shaped by positions, roles, power or organisational cultures. In truly authentic relationships, we can be as we feel. We don’t have to play roles and are not restricted by power relationships. While the relationships of the world of work are based on respect and recognition. the world of relationships should be characterised

298

3

Human

by love and empathy. The world of one’s own forms the space for our personal interests, hobbies and also for our extended circle of friends. "

Conflicts and crises can happen to us at any time in gainful employment, even through no fault of our own. It is then that a dream job suddenly turns into a heavy burden. The better we take care of our relationships and our “world of one’s own” when times are good, the more we are able to rely on them when a crisis in the world of work hits us unprepared. In such (stress) situations, closeness to our fellow human beings is very precious (Sect. 3.5.6).

3.10.2 Self-Knowledge Every person has his or her own, specific personality, character traits, strengths and weaknesses. The personality of an adult can only be changed to a small extent; it is to a large extent the result of genetic disposition as well as socialisation and formative life experiences. Much more important than change in personality development is to increasingly get to know oneself better and better and to be affirmative with oneself. With this knowledge, one seeks or develops a working environment fitting one’s personality traits as well as possible. Two fundamentally different methods are available for this process of becoming aware.

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

3.10

Personal Development

299

used in assessments, among others in personnel, traffic, school, and legal psychology. Examples of this procedure are Workplace big five (WPB5), the VIA Character Strengths or the Reiss motivation profile. Three personality typologies are presented below.

3.10.2.3 Belbin How do you behave in teams? Or even more specifically: How do you behave under stress or in conflicts? If you are honest, you cannot answer this question in any exact way, which is because in these exceptional situations, people lose their ability to selfreflect (Sect. 3.3.4). But there are experts who can tell you exactly how best to behave under exceptional circumstances: Your colleagues and employees. Because they have often experienced and observed you in such situations. Their feedback (Sect. 3.9.7) helps you to gain knowledge about yourself. The concept of Belbin team roles can be used on two levels: • Personal self-knowledge: Belbin provides a structured way of becoming aware of your personal blind spot through a comparison of your self-image and how others see you. • Success factors of cooperation: The Belbin concept makes it possible to put together teams that are as well-balanced as possible and thus also efficient (Sect. 5.3).

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

A key finding with regard to the individual participants was that they behaved very differently in the same situation. These different behaviours or behavioural clusters were assigned by Belbin to nine team roles (Fig. 3.23). Belbin distinguishes three competence groups and assigns team roles to each of them:

300

3

Plant theorising

Human

Completer Finisher perfecting

Monitor Evaluator assessing impartially Specialist specifing details

Shaper driving

Teamworker supporting

Co-ordinator generalising

Resource Investigator finding new possibilities

Implementer applying

Fig. 3.23 Belbin team roles (Belbin Germany e.K.)

• Accomplish: Shaper, Completer Finisher, Implementer • Thinking: Specialist, Plant, Monitor Evaluator • Communicate: Teamworker, Co-ordinator and Resource Investigator

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

3.10

Personal Development

301

3.10.2.7 Belbin Team Roles to Increase Self-Knowledge The basis for the personal team role report is formed by means of self-assessment. This is done using a structured questionnaire. This is then contrasted with four to eight external assessments from one’s own field of work. The development potential of each individual lies, above all, in the differences between self-perception and external perception: it is often the case that one’s own strengths are underestimated or not seen at all. Example

If you have always had new ideas since your youth, a certain level of creativity comes naturally to you (plant). This is also the case if you have become accustomed to taking things into your own hands instead of just talking, or if it is normal to you to create a benchmark with other market participants in case of a problem (shaper) or to activate your own network instead of wanting to reinvent the wheel yourself (resource investigator). ◄ So other people can first of all help you to become aware of your own strengths. Of course, they are then also a good mirror for sensitisation to the behaviour patterns because of which someone feels irritated or is even rejected. For Belbin to be a benefit on a personal level, well-developed personal communication skills are needed in all participants (Sect. 3.9). External assessments, according to Belbin, are feedbacks. These can only be constructive if the person receiving the feedback can distinguish between perception and evaluation. Those who see feedback as an evaluation of their own person may find it threatening. They will try to protect themselves from it. However, when feedback is used to assess how one person affects another, one’s own subjective perception is made available for this purpose. How the person receiving the feedback uses and interprets, it is up to him or her.

3.10.2.8 MBTI Based on the developmental psychology described by Carl Gustav Jung, Isabel Myers and Katharine Briggs in the USA formulated the personality typology MBTI (Myers-Briggs Type Indicator). Since 1999, the Golden Profiler of Personality (GPOP) test procedure, which is based on the same theory and has been further developed, has also been used. Today, they are both among the most widely used analytical instruments, as they are available in several languages and are supported by a very large test base of several million evaluations. Its success is also based on the fact that it builds on dimensions that describe essential characteristics of the occupational environment (Fig. 3.24): Attitude to the environment (introversion or extraversion), attitude to acting (judging or perceiving), Perception (sensing or intuition), and Decision (thinking or feeling). These four basic dimensions are each described with their characteristics. The possible 16 variations result in personality profiles with very different strengths and weaknesses. These type combinations result in 16 personality functions, consisting of the combinations of the respective four preferred attitudes. This makes it possible to

302

3

Human

Attitude to the environment E

I Contact

Extraversion

Introversion

Perception Features

Settings

S

N Recording of information

Sensing

Intuition

Decision F

T Assessment of information

Thinking

Feeling

Attitude to acting P

J Judging

Approach

Perceiving

Fig. 3.24 Dimensions of MBTI

identify personality profiles that are better suited to certain roles, functions and tasks than others. Many companies use these findings when filling positions and putting together teams.

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

3.10

Personal Development

303

Table 3.2 VIA Virtues and character strengths Virtue and description Wisdom Cognitive strengths involving the acquisition and application of knowledge

Courage Emotional strengths that overcome inner or outer resistance through willpower Humanity Interpersonal strengths that enable loving, human interactions Justice Strengths that promote community

Temperance Strengths that protect against excesses

Transcendence Strengths that connect us to the larger universe and provide meaning

Associated strengths and description Creativity: Finding original ways of doing things Curiosity: Fascination for subject areas and topics Judgement: Thinking things through, openmindedness Love of learning: Systematically adding to knowledge Perspective: Being able to give wise counsel to others Honesty: Authenticity and integrity Bravery: Not shrinking from fear Perseverance: Finishing what one starts Zest: Enthusiasm and energy for life Kindness: Care & compassion, generosity Love: Valuing close relationships with others Social intelligence: Knowing what makes other people tick Fairness: Not letting feelings bias decisions about others Leadership: Organising group activities Teamwork: Social Responsibility, loyalty Forgiveness: Giving people a second chance Humility: Letting your achievements speak for themselves Prudence: being careful, not taking undue risks Self-regulation: Managing impulses and emotions Appreciation of beauty & excellence: Awe, wonder, elevation Gratitude: Thankful for the good Hope: Optimism, future orientation Humour: Bringing smiles to others Spirituality: Religiousness, faith, purpose, meaning

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

304

3

Human

++

-Underload

Overload

Conformity

Creativity

Eccentricity

Disinterest

Curiosity

Indiscretion

Unreflectiveness

Judgement

Narrow-mindedness

Self-indulgence

Love of learning

Know-it-all attitude

Superficiality

Wisdom

Insolence

Fig. 3.25 Zone of strength (golden mean)

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

3.10.3 Coaching Similar to sport, coaching is also spoken of in a professional context when individuals or teams receive individual professional advice and guidance. Such support can make a lot of sense for all project participants in specific situations. Coaching offers fields of learning and reflection that are specifically geared to the respective functions and roles of the coachee. The content can focus on considerations in the planning or implementation of the next work steps, on behaviour in critical situations and in dealing with conflicts. However, reflections are also useful in order to better understand, analyse and learn from reactions, and from behaviour and results of past situations. On the one hand, this helps to deal with

3.10

Personal Development

305

one’s own disappointments and fears, and on the other hand, and above all, in order to better configure future situations. "

According to the model of the three levels of cooperation (Sect. 1.5), it makes sense for the project manager to check whether his design and leadership intervention . . . • Enables knowledge- and result-oriented work at the content level • Promotes a climate of acceptance and trust at the relationship level • Sees to it that order and favourable structures are ensured at the organisational level

In coaching, care must be taken to support the project manager in correctly grasping and recognising the status of the project or to discover where risks currently remain. From this, he develops scenarios for the further process design. Coaching a project manager is often quite difficult, as it is challenging to remain restrained while in the role of a coach in the strict sense. Rather, the coachee needs an interlocutor for strategy considerations and for his reflection on what has happened so far, for planning the next steps, for conflict management, as well as a supplier of methods, a kind of “frustration listener” and role guardian. This complexity also places some demands on the coach. He should have a command of the following topics: • Theoretical approaches to work such as systemic thinking, simultaneous engineering, organisational development, change management • Working techniques such as time management, moderation, crisis intervention • Peculiarities of the dynamics of projects in organisations • Dealing with pressure situations created by the different stakeholders The more experience the coach can bring to the table, the higher his acceptance by the coachee will be. On the other hand, it is all the more important to clarify in an agreement which advisory services the coachee wants: coaching in the sense of process advice or also expert advice on technical- and methodological questions. "

Coaching should be voluntary. The coachee should want the coaching and not see it as a rebuke. It is not a matter of glossing over mistakes in the descriptions of situations or embellishing something in order to look good.

Coaching is not an assessment in the sense of an examination, but an opportunity to examine, critically question and strengthen the quality of one’s own work employing outside help. It helps to recognise and to then qualify risks, to understand one’s own and other people’s motivations, to broaden one’s perception through the use of an outside perspective and, above all, to develop possible alternatives to a wide variety of problems associated with project management.

306

3

Human

3.10.4 Intervision Another platform for personal development is intervision. The psychoanalyst Michael Balint developed a method for case work among psychoanalysts. The method is based on the basic idea that in problem situations, the contributions of others are often well recognised, but that one’s own contributions to the problem are partially concealed (Sect. 3.9.7.2). Neutral observers of a situation notice such contributions quickly. Through valuable, critical feedback, they can reveal new views related to the problem and identify new approaches to solving it. The intervision method structures the treatment of a problem that a group member wants to solve together with people not involved in it. Michael Balint has found that it is helpful to discuss the outsiders’ impressions without the caseworker immediately commenting on them. In this way, a Balint session has a clear structure: 1. The Case Giver Describes His Problem The group listens to this and does not interrupt him. The listeners note down what comes to their minds while he speaks, what they feel and how they experience the case giver (for instance, as insecure, nervous, arrogant, dissolute, etc.). 2. The Group Asks Comprehension Questions The group only asks comprehension questions, it asks no questions that contain an assumption, a hypothesis, or an interpretation, etc. The facilitator makes sure that only a sense of understanding is thereby improved and lets the asking of questions continue until he/she feels that the group has enough information for the next phase. This can take different lengths of time. 3. The Audience Describes Their Hypotheses Thoughts, impressions, assumptions, causes etc. are allowed to be put forward, but not yet any solutions. The audience is permitted to then use its imagination freely and without restrictions. Someone writes down the group’s feedback in key words onto a flip chart. The case giver remains turned away from the group, listening without commenting—not even doing so non-verbally. He is not allowed to intervene, but he may note down his thoughts, ideas, etc. 4. The Case Giver Names the Hits He goes through the list and says what applies to him and why or what is incorrect or to what degree something is true for him. He crosses out the “false reports”. His subjective view is correct! While the facilitator strictly observes the rules of speech in the first three steps, he can allow more discussion to take place in this phase. 5. The Group Develops Proposals for Solutions The case giver or a participant notes down and visualises the suggestions. If necessary, the solution is simulated in a role play. 6. The Final Round This gives the case giver the opportunity to share with the group what they have learned from the session. The other group members reflect on what they have learned for themselves. The more personally exposed the case giver is, the more

References

307

important it is for the rest of the group to say something about themselves at that stage.

3.10.5 Upside or Downside Strategy? Change, reassessment or displacement: According to which criteria can we align our personal development? The upside or downside strategy offers an effective approach here (Dobelli, 2017b). Upside refers to all positive characteristics that are to be achieved via an action or change. The downside strategy is exactly the opposite. Example

• Upside: What is it that motivates me? How can I experience more meaningfulness? Or in general: What promotes a better life? • Downside: What demotivates me? When do I feel stressed? And why? What pointless tasks do I want to protect myself from? Or in general: What prevents me from leading a better life? ◄ In many cases, the downside strategy is much more effective: the things that cause us trouble, that seem pointless or that demotivate us—are tangible. We experience this every day. On the other hand, it is much more difficult to ask oneself what a suitable job might look like, what it is that would make me more satisfied. The effort needed to keep switching from the downside to the upside perspective is definitely worth it.

References Ballreich, R., & Hüther, G. (2009). Du gehst mir auf die Nerven! Neurobiologische Aspekte der Konfliktberatung. Concadora Verlag. Bamberger, G. (2005). Lösungsorientierte Beratung. Beltz Verlag. Biswas, C. (2015). Hier entsteht die Zukunft. NZZaS. 20.12.2015. Brand, C. (2017). Tausendmal gescheitert. NZZ. 4.06.2017. Covey, S. (2020). The 7 Habits of Highly Effective People. Simon & Schuster. Csikszentmihalyi, M. (2004). Flow, the secret to happiness. Retrieved on 23rd of January 2018 on TED: ted.com. Dobelli, R. (2017a). Die Kunst des guten Lebens. Piper Verlag. Dobelli, R. (2017b). Ergründen Sie Ihre Downside. NZZ. 9.09.2017. Drath, K. (2014). Resilienz in der Unternehmensführung. Haufe Verlag. Dumetz, J. (2012). Cross-cultural management textbook. CreateSpace Independent Publishing Platform. Esch, T. (2014). Die Neurobiologie des Glücks. Georg Thieme Verlag. Heller, J. (2013). Resilienz – 7 Schlüssel für mehr innere Stärke. Gräfe und Unzer Verlag. Hirschhausen, E. (2010). Glück kommt selten allein. Rowohlt Verlag. Hüther, G. (2016, 2001, 12. Auflage). Bedienungsanleitung für ein menschliches Gehirn. Vandenhoeck & Ruprecht Verlag. Kalisch, R. (2020). Der resiliente MENSCH. Piper Verlag.

308

3

Human

Kaluza, G. (2018, 2004, 4. Auflage). Stressbewältigung. Springer Verlag. Largo, R. (2017). Das passende Leben. Fischer Verlag. Lippmann, E. (2013). Coaching. Springer Verlag. Müller, G. (2015). Innovation wird von unten erzeugt. NZZ. 5.06.2015. Niemiec, R., & McGrath, R. (2019). The Power of Character Strengths. Official Guide from the VIA Institute on Character. Pfläging, N. (2015). Organisation für Komplexität. Redline Verlag. Rager, G., & von Brück, M. (2012). Grundzüge einer modernen Anthropologie. Vandenhoek & Ruprecht. Schmid, W. (2010). Auf der Suche nach Glück. NZZ Format. Schneider, S. (2003). Trau, Schau, Wem. Input DRS 3. Sprenger, R. (2014). Mythos motivation. Campus Verlag. Stadelmann, U. (2017). Warum unserem Hirn teurer Wein besser schmeckt. NZZ. 15.11.2017, S. 25. Steiger, T. und Lippmann, E. (Hrsg.), (2008. 3. Aufl., Bd. I). Handbuch angewandte Psychologie für Führungskräfte. Heidelberg: Springer Medizin Verlag. Walser, C., & Wild, P. (2002). Men’s Spirit. Spiritualität für Männer. Herder Verlag.

Further Readings Amrein, M. (2015). In unserem Ohr steckt eine Wasserwaage. NZZaS. 13.09.2015. Donzé, R., & Pfister, F. (2015). Leben heißt spüren. NZZaS. 11.10.2015, S. 53 ff. Hirschhausen, E. (2016). Wunder wirken Wunder. Rowohlt Verlag. Hüther, G. (2016, 1997, 13. Auflage). Biologie der Angst. Wie aus Stress Gefühle werden. Vandenhoeck & Ruprecht Verlag. Schulz von Thun, F., et al. (2005). Miteinander reden: Kommunikation für Führungskräfte. Rowohlt Verlag.

4

Leadership

In most cases, the complexity of today’s projects requires interdisciplinary cooperation. In order for this to succeed, those responsible for projects need a healthy amount of leadership competence to give their teams the right impulses, both in the agile and in the traditional approach. This chapter looks at different leadership styles and covers the relevant aspects of leadership in a project, such as agreeing on tasks, competence and responsibility, motivation as well as effective delegation, dealing with power and authority. Other aspects such as self-organisation or the central competence of negotiation are also covered in depth. The topics are structured according to their relevance for the agile and the traditional approach.

4.1

Leadership and Cooperation

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

# Springer-Verlag GmbH Germany, part of Springer Nature 2023 J. Kuster et al., Project Management Handbook, Management for Professionals, https://doi.org/10.1007/978-3-662-66211-3_4

309

310

4

Leadership

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

4.2

Leadership: What Is It?

Every team needs leadership, regardless of whether it works according to the agile or the traditional approach. The word leadership is often experienced in a very ambivalent way by the people involved. Some think of responsibility and challenge. Others tend to think of domination and command and thus of oppression and a means of

4.2 Leadership: What Is It?

311

Table 4.1 Definition of leadership in projects Leadership has to. . . Leadership requires. . .

• Provide orientation • Live and enable human relationships • Ensure that the required objectives can be achieved • Power consciousness • Self-awareness (self-reflection) • Courage

asserting one’s own claims. In fact, the word “leadership” indicates power and influence over others. Those who have leadership exercise power over people or groups of people. However, the way in which this power is exercised is ultimately decisive for the quality of the leadership work and for whether it results in leadership success. " There are a wide variety of definitions of leadership, as the following examples

demonstrate: • Leadership means “setting something in motion”: Those who lead ensure that something moves. Leadership is about movement, change, development. Leadership is the medium of that movement. Leadership initiates change and ensures development. • Leadership means “giving direction”: If we think of a “routing”, for example, the word leadership means showing the way. Leadership gives orientation as to where the movement should go. • Leadership means convincing people of an idea and enabling them to transform this conviction into action. • Leadership always takes place in relationships. Leaders and those led behave according to their own subjective concepts, which are also group-specific and situation-dependent. • Leadership is the goal-oriented, social exertion of influence to accomplish common tasks in or with a structured work situation. • Leadership means constant problem solving in social systems. • Leadership is the recognition, design, and control of interpersonal processes and can be divided into two parts, namely referring to leadership activities and leadership behaviour. Instead of “setting something in motion” and “giving direction”, we can also define leadership in traditional and hybrid projects as follows (Table 4.1). Self-organised teams, as we know them in agile project management, also need leadership. In this context, we speak of collegial leadership: Collegial leadership is the leadership work taken on dynamically and decentrally by many colleagues according to the pull principle instead of centralised leadership by a few exclusive leaders according to the push principle (Oestereich & Schröder, 2020, p. 32).

312

4

Leadership

In the traditional understanding of leadership and thus also in traditional project management, specific people and bodies are endowed with leadership competences and management responsibility. In the self-organisation of agile project management, the manager is removed. The team as a whole takes over the leadership work. However, this is in turn embedded in a system with specific further leadership competences, as explained in Sect. 5.5.

4.3

Different Forms of Leadership

A project is always ostensibly based on the achievement of objectives and thus on the work being done in the system (Sects. 1.5.1 and 5.2.4). For this to happen, however, essential framework conditions need to be created at the relationship and organisational level—and work hast to be done on the system. For the work on the system there are different forms of leadership. Leadership = Management In a comprehensive business sense, it is understood to mean leading and managing a company, an organisation or a project, etc. Corporate management is concerned with securing the existence of the company under changing conditions. It assesses the influences of the environment and uses the knowledge gained to adapt the company to the circumstances. Internally, it takes into account the existing strengths, abilities, and resources. The strategies, corporate goals, and corporate policy are derived from a combination of external and internal influencing factors. Similarly, managing a project can be understood as securing the existence of the project in the organisation and the permanent adaptation to the changing framework conditions and influencing factors. Here it can be observed that more and more companies are changing from a hierarchical to a sociocratic or holacratic organisation. Leadership = Employee Management In a narrower sense, one speaks of leadership when a conscious and goal-oriented influence is exerted on employees. Employee leadership is shaped by changes in the environment. An intelligent management can quickly adapt to new situations. It needs many competent people who are in the know and who are willing to think, act, and take responsibility. This requires a high degree of transparency in the area of information and communication, coordinated interaction between all those involved, and a high level of trust between staff and managers. Leadership here means exerting influence on the behaviour of employees so that goals can be achieved together with them. When it comes to issuing, demanding, and correcting goal-oriented orders, the project manager takes on the role of employee leadership like a manager would. Leadership = Coaching The project manager also has the task of supporting and promoting his employees in a resource-oriented way and developing their personality. This is what the term coaching stands for. The element of leadership in partnership is a useful addition to

4.4 Leadership Styles and Models

313

the other instruments of personnel development. In the role of the coach, he is a companion and trainer. He pursues the goal of supporting his project staff in such a way that they can act independently and on their own responsibility. Coaching quality is characterised by realistic implementation, concrete results, and sustainability. Leadership = Dynamic and Distributed Leadership Work In collegial leadership, the actual leadership responsibility falls away. The leadership work, and thus all the work on the system, is distributed among the team members. This does not mean that everyone has to anticipate having to do leadership work, but that different roles are performed situationally by different team members. Leadership Characteristics in Project Management Finally, we relate the forms of leadership described above to the tasks of the project bodies described in Sect. 2.3.8. With the signing of the project order the project manager takes over temporary leadership, as well as the coaching and the management tasks for his project and the team. The management task is carried out through controlling. It is the project manager’s responsibility to identify and deal with all deviations from the initial plan during project implementation. Every detected deviation has to result in an action. The problem-solving process is suitable for developing and evaluating the measures (Sect. 2.3.14). The project manager needs to report to the project owner all deviations remaining after the implemented measures that have an influence on the magic triangle (Sect. 2. 3.4), the project manager needs to report to the project owner. Through the reporting the project owner, for his part, comes into the management function. The solution alternatives evaluated via the problem-solving process also serve as a basis for decision-making. The project owner focuses on the project manager with regard to employee management and coaching. The project manager exercises his management function vis-à-vis his sub-project managers and, to a lesser extent, also vis-à-vis individual experts. In agile project management, these characteristics are more clearly assigned to their respective roles: The product owner, responsible for the content management of the project, focuses on the management task. The scrum master takes over the coaching. There is no actual employee management in the agile approach. This happens through the self-organisation explained in Sect. 4.5.3.

4.4

Leadership Styles and Models

A leadership style is understood to be a relatively stable, situation-variant behavioural pattern of the leader over the long term (Charles Lattmann).

Actual employee leadership is only applied in traditional project management. In an agile project, the leadership task is performed collegially. In everyday leadership, the leadership style is the way in which the leadership activities of planning, steering,

314

4

integrative

Leadership

participative

directive

delegative

Formal leadership power decreases

Leadership styles

Situative leadership model

Positive leadership

Self-organisation

Leadership without formal authority (lateral leadership)

Fig. 4.1 Different leadership styles

and controlling are carried out and the individual leadership processes are influenced. A certain leadership style has the consequence that every leadership situation is characterised by a uniform basic behaviour. On the other hand, leadership always takes place in relationships. This means that the people involved in leadership influence the respective characteristics of the leadership style with their specific situation. Basically, the success of a project is mainly measured by the benefits achieved for the organisation. Is there a correct and more promising leadership style? Chapter 3 explains that every human being is characterised by a unique constellation of basic needs and abilities. Organisations in which projects are carried out are also unique and each has its own organisational culture. Therefore, there can be no right or wrong when it comes to leadership styles. Rather, the optimal leadership style for oneself and for the team needs to be found in order to achieve the project objectives. The leadership style is also shaped by the personal style of the project manager. The project order can influence the choice of leadership style. In the tension between directive and delegative leadership, the project manager has to find the right mix to bring the ability to act and make decisions into the project. Depending on the situation, different leadership styles are suitable for this purpose, as shown in Fig. 4.1.

4.4 Leadership Styles and Models

4.4.1

315

Directive Versus Delegative Leadership Style

The leadership continuum developed by Tannenbaum and Schmidt as early as 1958 has found its widespread expression in leadership theory (Fig. 4.2). Between the two poles of directive and delegative leadership, further characteristics are possible, which result in different leadership styles. The leadership styles differ with regard to the delegation of decision-making competences: In the participative or delegative leadership style, these are partially or completely handed over to the employees. This contrasts with the directive leadership style, in which the supervisor has all decisionmaking authority. This linear model is still useful today. In a crisis, for example, a directive style of leadership can be deliberately applied. The emergency situation justifies quick decisions and clear allocations of authority. Or at the other end of the scale, the entire decision-making authority can be delegated to a project team to solve a difficult problem.

4.4.2

Situational Leadership Model

In the situational leadership model, the leadership style is not only oriented towards the current situation and the goals to be achieved. The main point of reference is the

integrative

participative

directive

delegative Leadership styles

high

Directive leadership Sole decision of the manager

low

Delegative leadership Delegated decisions to employees low

high Manager allows the team to • indentifiy the problem • develop options • to determine the course of action within a given limit

Fig. 4.2 Directive and delegative leadership

4

high

316

S3

train

Participative leadership style SU: Coach EM: Professional Share ideas and encourage to take decisions

Seconding behavior – relationship orientation

delegate

S2

Integrative leadership style SU: Trainer EM: Learner Explain decisions and give the opportunity to ask

S4 Delegative leadership style SU: Partner EM: Expert Hand over responsibility for decisions and implementation

low SU: Superior EM: Employee

support

Leadership

S1

direct

Directive leadership style SU: Instructor EM: «Junior» Exact instructions and monitor performance

low

Conducting behavior – task orientation

high

high

Maturity level of the employee

low

Fig. 4.3 Situational leadership model (Based on Blanchard, 2015)

maturity of the person being led, made up of the product of performance (ability) and the willingness to perform (desire), compare also Sect. 3.2. For this level of maturity of the employee (EM) (see Fig. 4.3) a specify superior’s (SU) leadership style is necessary to optimally match the employee’s needs: directive, integrating, participative and delegative. A great advantage of this leadership model is that the manager can do justice to the heterogeneity of the team. It is often the case that the personal maturity level in a project team covers the entire range between very experienced experts to “juniors”. In this situation, it is not helpful for the project manager to apply only one leadership style. Rather, it is about finding the appropriate leadership style in the relationship with the respective individuals. • Directive leadership style S1: Instructing, directing, steering – The supervisor gives precise instructions and conscientiously oversees the performance of the task. • Integrative leadership style S2: Training, convincing – The supervisor continues to conscientiously direct and monitor the performance of the task, but discusses the decisions with the employee, and asks for suggestions, he also trains, instructs, and convinces the employee of the necessity of the task. • Participative leadership style S3: Advising, supporting

4.4 Leadership Styles and Models

317

– The supervisor advises and supports the employee in finding solutions and making decisions. Principle: Helping people to help themselves. • Delegative leadership style S4: Delegating – The supervisor delegates to the employee to a large extent the competence and responsibility for the decisions to be made and the tasks to be solved.

4.4.3

Leadership Without Authority to Issue Directives

The term lateral leadership (Lat. Latus stands for “side”) has also become established for leadership without authority to issue directives. This style of leadership is predestined for project coordination because the “project manager” in this project organisation has no authority to issue directives. Project managers need to therefore be able to work effectively without institutional power. The essential starting point for this, in leadership without authority to issue directives, is borrowed power (par. 4.9.4): It is a matter of achieving the best possible coordination with the decisionmakers in the line organisation. An essential success factor of leadership without authority is the definition of framework conditions for the environment (organisational framework), the project manager (personal framework), and the team (team framework) (Radatz, 2009). The following questions need to be worked out:

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

4.4.3.2 Personal Framework Whoever assumes responsibility hast to, in order to protect the ability to act, also determine which rules of cooperation are to be followed. In addition to this, every lateral manager needs to also become aware of what goals and motives the team can achieve in the fulfilment of this task:

318

4

Leadership

• What makes the task attractive in a personal way? Which extrinsic or intrinsic motivational factors can be met and satisfied by this task? But also: What should or is not to happen? • What demands are made on the team? What does the manager need from the team so that the task can be fulfilled well? How should the rules of cooperation be defined? Example

• • • •

What form does communication take? How are binding agreements made? What are the consequences of not meeting deadlines? How are absences and delays dealt with? ◄

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

4.4 Leadership Styles and Models

319

4.4.3.4 Friction Points in Leadership Without Authority to Issue Directives If there is a lack of controlling or a poor selection of resources, there is often the danger of individuals being overburdened or of role conflicts arising. The following points should help to avoid this kind of friction: • Work on the expectations of individual project roles early on and together in the project team. This involves clarification and transparency of and regarding the different expectations of the role sender on the role holder (Sect. 5.3.2), but also the communication process within the team. • Distinguish between roles performed by individuals and those performed by the project team or parts of it (sub-project teams). • Define roles on a project-specific basis, even if individuals repeatedly take on the same project roles. • Address role specifications (function description, job specifications) to the respective role holders and their deputies. Example

Things that a role holder (e.g. project manager). . . • • • •

must do: he must manage the project and lead the team should do: treat the team members equally can do: organise something together outside the project work should refrain from doing, e.g. because it is incompatible with his or her role ◄

4.4.4

Positive Leadership in Projects

Based on positive psychology and the PERMA model by Martin Seligman (Sect. 5. 4.1), Ruth Seliger developed the leadership model of positive leadership. For leadership to succeed, I must be able to lead myself. Only those who can lead themselves are also able to lead other people. This is achieved by reflecting on one’s own leadership behaviour, one’s own role, but also one’s values and goals. In the management of people and projects, communication represents the central management tool and the question arises: “How can I make communication come across as positive and inspiring?” Systemic theory (Sect. 1.6) teaches us that living systems are autonomous, relatively inaccessible from the outside and that decisions are made internally, with the power of self-organisation. In humans, it is the inner maps that control action.

320

4

Leadership

Involvement: Inclusion into decisions Empowerment: Hand over responsibility

Focus on and appreciation for strengths, resources and potentials Confidence

Influence

Principles Meaning

Past: Motifs Present: Big picture Future: Vision

Fig. 4.4 Principles of “positive leadership” (Seliger, 2014)

If the project manager’s task is to induce a certain behaviour in the project employees, how can he do this if they are internally controlled? The solution lies in a systemic understanding of communication and interaction: • We construct our individual world views, our “inner maps”. • At the same time, our maps are also the “engine” that controls our actions. • Whatever people do, they do it on the basis of their inner images and assessments, not on the basis of external reality. By shaping communication in a positive way, the project manager can exert influence: • By creating a positive communication climate, exerting influence by asking questions and using feedback as a source of energy, the project manager can positively influence direct communication. • The project manager can conduct meetings productively and thereby positively influence organised communication. • In addition to this, it is also important to make clever use of informal networks. At the heart of positive leadership are the three principles: confidence, influence, and meaning. These act as elements for shaping a positive organisational energy (Fig. 4.4).

4.4 Leadership Styles and Models

321

Energy is generated among project team members when their own activity is considered meaningful (Sect. 3.7). The better the project manager succeeds in making the project activity meaningful for the project team, the more will the employees commit themselves to the project and get involved. As soon as the project team can fully utilise and experience its strengths, resources, and potential, this then creates positive energy in the project. The positive energy in the project can be further increased by involving the project staff in the decision-making process and handing over responsibility, both in terms of content and in terms of emotion. This also builds a trusting environment. The principles serve to generate high positive organisational energy. High energy is central to the success of a project; i.e. the project manager has the task of ensuring that: • The project builds up enough energy and can mobilise it again and again. • The project energy flows in a good way and there is enough of it, so that all parts and all environments of the project are energetically well supplied, that there are no congestions or energy holes. • The available energy is also used effectively and does not go to waste. The professional mastery of leadership tools and the creation of role clarity form further important foundations in the positive leadership model.

4.4.5

Tips for Remote Leadership

The project team working together in one room has many advantages. After all, questions or problems can be solved promptly and without complications over a coffee in a direct conversation. Due to the pandemic, working together at a distance via home office was inevitable. Regardless of the preferred leadership style, the following rules should be observed when collaborating in this way: • Frequent contacts: Daily conversation with each project member, without necessarily having a specific agenda. • Clarify questions in a consultation hour: Set up question time for project employees. • Create stability through rituals: Morning check-in; opening sessions with feelgood rounds. • Increase security through clear boundaries: Set rules for availability and absence. • Problems, not just solutions: Encourage your team to come up with problems even if they don’t have solutions yet. • Build capacity through feedback: Proactive feedback every day, for good (not just great) work. • In difficult situations: Praise efforts, not results.

322

4.5

4

Leadership

Self-organisation, Specific Characteristics in the Agile Project

How does self-organisation work? Which specific characteristics or methods should or can be taken into account when taking on the roles of product owner, scrum master , and developer?

4.5.1

Principles and Requirements for Self-organisation

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

4.5.2

What Does Self-organised and Agile Working Mean?

Agile working means experimenting, iterating, continuously improving and learning, actively involving stakeholders and taking responsibility. It is important to develop an agile mindset. A purely mechanical application of an agile framework like scrum does not work in practice and is doomed to fail. According to the agile manifesto (https://agilemanifesto.org/) and derived from practical experience, the following points are central to the development of an agile mindset: • Interaction between individuals is more important than strict adherence to processes and tools. This is achieved by team members talking to each other and continuously exchanging ideas. Collective intelligence beats individual performance. • Reacting to changes is more important than rigid adherence to a plan. A culture of openness to change must be developed within the team. • Shared learning with customers is part of the approach. A culture of continuous improvement and learning should be developed in the team. Openness to criticism

4.5 Self-organisation, Specific Characteristics in the Agile Project

323

and feedback helps, and it is easier if mistakes are understood as learning opportunities. Intelligent failure is to be encouraged here (Sect. 5.4.1). • The customer benefit (Sect. 2.8.2.6) is the focus. • Experimentation helps the team to find out what works and what does not. This succeeds when a pragmatic approach is taken and perfection is not a precondition from the start. • Through a kanban board (Sect. 2.5.2) and regular stand-up meetings (Sect. 2.5.3), a team creates transparency for itself and the stakeholders about what is being worked on and what the progress of the work looks like. These principles are based on values such as openness, commitment, focus, courage, willingness to take responsibility (for commitment, productivity, efficiency, and health), and mutual respect. It is also interesting to ask oneself what interests and qualities lie behind these values for oneself and for the team. Only if the scrum team succeeds in developing these principles and values into an agile mindset will the agile approach have a chance of success. In the process of self-organisation, constructive and sustainable communication between the team members is needed. The shaping of relationships among these and their communication is more important than the organisational structure in the team. The performance of a team is not the sum of the individual performances. The performance of the team essentially depends on how well it succeeds in shaping the interaction between the team members. Self-organisation does not mean fewer structures than in a traditional project organisation. New structures are created by the team itself and no longer imposed from the outside.

4.5.3

How Does Self-direction and Leadership Work in Self-organisation?

Teamwork needs leadership. In self-organised teams, leadership is collegial (Sect. 4.2). Collegial leadership is distributed, situational, and temporary. Depending on skills and temperament, some team members are experts in brainstorming, others at “doing things”, while yet others have a sensorium for social processes, and so on. The team has to deal with these different preferences. As a result, the work to be done is pulled by the individual team members and no longer pushed by the project manager. Example

It makes sense for one person with the appropriate skills and interests to take over the facilitation process, another to organise the infrastructure, someone else to pay attention to quality, and yet another team member to keep an eye on team cohesion and address latent conflicts, and so on. It is important to talk about these leadership or team roles, to organise and reflect on them. In this way, it can be avoided that the roles get monopolised by one influential person or, conversely, that a leadership vacuum is created. ◄

324

4

Leadership

The advantages of collegial leadership are: Rapid adaptation to change, strong commitment, and sustained high levels of identification and motivation. This leads to a correspondingly high level of performance. Leadership here simply means that roles previously embodied by a manager are now seen as distributed. This means that someone takes the lead in an area in which they have special skills or knowledge. "

A possible aid to suitable staffing is offered by the Belbin team roles (Sect. 5.3). This model describes which team roles are filled and how. The Belbin team report shows any deficits in the team and enables them to be compensated. In the process, the different experiences of a professional and methodological nature must also be addressed. In short: A team’s management potential lies in dealing with diversity.

Of course, over time, one-sided hierarchical patterns can emerge which diminish the diversity of a team. This happens especially in teams that work on projects remaining the same in composition over and over again. If team members withhold important information, diversity also suffers. Such rigidities can only be done away through self-reflection. The primary platform for this is the sprint retrospective moderated by the scrum master. Here, the cooperation in the team gets critically reflected. Self-organised teams are not feel-good oases. They expect their members to perform as agreed. External control is replaced by self-control. In agile project management, the project team itself becomes the entrepreneur. This “grassroots entrepreneurship” means that there is more commitment and responsibility for all people involved. And because the pressure of time and expectations is high due to the short sprint intervals, individual team members may well get into stressful situations, be criticised by the team, or even excluded.

4.5.4

Decide on Procedures and Solutions in Their Own Competence

In traditional project management, project teams develop proposed solutions and submit them to the project owner or the project committee for a decision. However, self-direction is only successful if the teams can decide on the solution themselves within a defined framework. This can be, for example, the development of an internal process that the team members then later have to “live” themselves. Or it may be a product development that the team offers to the internal or external customer without obtaining the approval of the internal management. This happens before a background of the team members having at least as much knowledge in their specific field as their management. If the knowledge in the team is deemed insufficient, the team can also seek the support of the scrum master or that of other experts at any time. By being customer-oriented instead of boss-oriented, the team experiences a corresponding appreciation, is motivated, and takes on full responsibility. And yet

4.5 Self-organisation, Specific Characteristics in the Agile Project

325

the team should not only be able to decide on solutions, but also on the procedure and the choice of methods. It is important to clarify the framework conditions within which self-organised work is to take place. This provides orientation and defines creative freedom: • Content: What is the vision, the goal, the object of the project and what is it not? Is this vision meaningful? What is the purpose to be pursued? • Processual: What are the rules of the game, what is to be observed, and what is prohibited? (Prohibitions can very well define the free space, because everything else is permitted) What is still to be preceded by superordinate instances or guidelines? How is the project team’s scope for decision-making and action defined?

4.5.5

Important Factors for Self-organisation to Succeed and Be Effective

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

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

326

4

Leadership

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

4.6 Leading with Goals

327

With all these points, the overall process needs to always be kept in mind. Are the competences of the team members used optimally? Who goes into the lead with which topics and when? Are concrete results being delivered for the client or is the team preoccupied with itself? What about the performance of the team? In order to keep an eye on the overall process, it is important to create a space for learning in order to reflect on the issues that have been identified and to look for ways to improve.

4.6

Leading with Goals

Depending on the corporate and management culture, the operational implementation of projects is structured differently. A widespread technique is management by objectives. Leading projects also means achieving goals. Within project implementation, milestones form intermediate goals that have to be achieved. This technique is just as suitable in project work. It is also used within the participative and delegative leadership styles explained above.

4.6.1

Management by Objectives MbO

With the basic attitude of delegating tasks, competence, and responsibility to employees, the MbO technique provides the substantive framework for setting the goals to be achieved. Traditionally, this process takes place annually or semiannually or when joining the project team. The following aspects are at the forefront of leadership by objectives: • Leading through goals (WHAT) and not through solution strategies (HOW) • Company or project objectives must be broken down along the vertical organisational structure • Task performance process (TCR) based on: – Division of tasks – Delegation of decision-making and directive authorisation with the associated responsibility Leading by objectives offers significant advantages: • MbO promotes performance motivation, initiative, and a sense of responsibility • MbO allows delegating tasks and content-related decisions to the technical experts, who are better qualified in the area of their expertise than the project manager, who is more of a generalist • MbO creates freedom in project work for situationally optimal solutions • MbO involves the people concerned, it promotes and also makes demands • MbO allows the participants to grow with the tasks and expand their qualifications • MbO leads to operational relief for leaders • With MbO, higher-level goals become personal goals

328

4

Leadership

Table 4.2 Differences between target setting and target agreement Target setting Directive Sales culture Based on acceptance Boss-driven Short-lasting and fast Normal demands on supervisors Often win–lose situation Often demotivating

Target agreement Participative Negotiation culture Based on commitment and identification Boss- and employee-driven Longer time process High demands on superiors More of a win–win situation Motivating

A key factor in whether MbO can be successful or not is the basic understanding of MbO. Are mutual expectations negotiated in the sense of a target agreement and agreed upon if there is mutual agreement? Or are the objectives ordered “top-down” by the hierarchical levels as targets without taking into account the opinions and needs of the recipient? Table 4.2 makes the differences clear. Management by agreement on objectives is of course more time-consuming and requires good negotiating skills of both sides. But only through a process of agreement will it be possible to achieve a really high level of commitment and thus also a high level of motivation and commitment on the part of the people who are to take on the tasks.

4.6.2

Leading by Objectives and Key Results (Management by OKR)

With the shortening of planning and action times, the previous MbO management concept now often gets replaced by the OKR approach. This management model, which is based on objectives and key results, in its basic ideas comes from the MbO approach and combines today’s working conditions much better (Table 4.3). It takes into account the digital transformation and the different demands made by today’s generations (Sect. 3.4.3). A cycle in the OKR process takes 3 months. The goals are developed together with the employee in a top-down and bottom-up process. During the implementation phase, a weekly OKR, OKR review, and OKR retrospective is conducted, similar to agile project management. Essential prerequisites for a functioning OKR are listed in Table 4.3: The OKR leadership approach fits much better today, this is true in many places in the normal leadership environment as well as in the traditional and agile project environment, as it meets today’s circumstances and demands. In rapidly changing markets and environments, it fits to leading in an agile way. The short leadership cycles create a maximum of flexibility. Only tasks that are result-oriented are tackled, which bundles strengths and resources. However, it is important to ensure that the key results are formulated in a comprehensible and measurable way and that they comply with the SMART rule (Sect. 2.3.2.4). Similar to the agile project approach, the result ultimately also depends on how well the cyclical, qualitative method work steps are carried out. In order for these to become routine, someone from within the company may also help here as an OKR master.

4.6 Leading with Goals

329

Table 4.3 Prerequisites for a functioning OKR Aspects Openness

Transparency

Not an employee appraisal tool

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

Example

Within the framework of a project, market clarifications are planned at various levels. This task and the corresponding responsibility are implemented differently in the two different management approaches MbO and OKR. ◄

MbO: leading with goals The project manager’s annual or biannual performance mandate lists this task as part of the overall project. The project management ensures that the necessary market clarifications and forecasts are available by the end of the concept phase.

OKR: leading with goals and key results In the particular cycle of the OKR process, the key results are defined. The market research sub-project team helps to develop a market analysis over the next 3 months, conducting: 1. An analysis of the competitors 2. A market analysis of the possible sales channels 3. Forecasts of possible market developments 4. Proposals for further action.

330

4

4.7

Leadership

Delegation

Delegation is a big challenge for many project managers. Most of the time, they qualify for a project role through good work as subject matter experts in the line organisation. With project management, sub-project management, as scrum master, product owner, or in the project team, they take on new roles. This involves taking on many new tasks and responsibilities. In order for these project roles to be fulfilled at all, those concerned need to free up capacities. The principle of delegation is helpful for this, whether in terms of line or project tasks. In operational, agile project management, delegation plays no role, as the team is self-organised and decides very dynamically who does what and when.

4.7.1

Decision-Making Process in the Delegation

How can delegation be made concrete and as sustainable as possible? Figure 4.5 shows the decision-making process as to whether and how a task is suited for being delegated. First check whether the task is really necessary for the organisation or the project. For this clarification, the time management matrix in Sect. 3.8.3 is helpful. Unnecessary tasks should be eliminated. For the remaining tasks, one tries to find a

I choose a task and ask myself…

… is it necessary? yes … Am I only able to fulfill her? yes

no eliminate no

delegate according to checklist

… warum?

not transferable why? He knows or can not now

He wants or he may not

• form • to advise • accompany • explain • instruct • clarify hierarchy

too little available • Check utilisation • Check deployment planning • Looking for employment for temporary job • Loan person • New person to adjust

Fig. 4.5 Decision-making process in delegation

is a management task • Can the work be simplified? • Can it be done later?

4.7 Delegation

331

person with the necessary skills. If there is a person who is ready, willing, and able to do the work, the task can be delegated according to the checklist in Table 4.4. If at the moment only I can do the job myself, I have to ask: Is the task non-transferable because. . . • there is no one who has the relevant knowledge or skills? If there is not, such a person has to be built up. • the competences are available, but the person in question cannot take on the assignment? Then the reasons have to be determined, and the appropriate resource need to be released via the hierarchy. If there are too few resources available, check the workload and the assignment planning. The delegating person hast to look for additional resources. In such situations, simplify the tasks or fix them for a later date. Specific leadership tasks cannot be delegated.

4.7.2

Delegation as a Recurring Process in Project Management

In the traditional approach, the project manager must constantly ask himself which tasks he is going to carry out himself and which of these he intends to delegate to other people. By definition, he should work on the system and not in the system. Table 4.4 Checklist for delegation Focus WHAT System objectives WHO People and hierarchy levels WHY Purpose, motivation WITH WHAT Means, resources WHEN Deadlines RESPONSIBILITY of the delegating person

Possibly: HOW Process objectives

Description • What is the desired outcome? • Which subtasks are to be completed in detail? • What difficulties are to be expected? • Who is suited to carry out this task or activity? • Is the person available? • Who should be involved in the execution? • What purpose does the task or activity serve? • What happens if the task is not carried out? • What must the employee be equipped or authorised with? • Which documents are required? • When must the work be completed? • Which intermediate deadlines have to be met? • To what extent do I remain part of the solution? • What responsibility remains with me towards whom? • When do I have to check what in order to intervene if necessary? • How to proceed with the execution? • Which regulations and guidelines must be observed? • Which positions, departments are to be informed?

332

4

Leadership

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

There are many arguments in favour of delegation, especially in project management: • Relieving the burden on those responsible for the project, i.e. more time for the essential tasks and responsibilities of the respective roles. • Based on the understanding of their role, the team members have to be more competent in their field than a project manager. • Decisions can be prepared and made by professionals where the consequences are going to have an immediate impact. • Delegation often opens up the freedom necessary for creativity in the search for solutions in project work. • Delegation also means involving the employees. They are challenged and thus encouraged. By taking on responsibility, the qualification-levels of the contractors increase. ◄ Qualified employees usually want to be able to use and show their potential. With the delegation principle, the delegating person emphasises trust in the employees and at the same time reinforces their independence and ability to act. In addition to these arguments in favour of the delegation principle, the dangers should be mentioned. It seems important in this context that the delegating person is concerned that: • The “right” employees are deployed, i.e. the risk of over- and under-employment is clarified before employees are scheduled into the project. • The employees are fully informed, i.e. that they have understood not only the goal and purpose but also the context. • Execution and results are monitored systematically and according to plan (status reports, milestones).

4.8 Task, Competence, Responsibility (TCR)

333

• With the delegation of work tasks, the corresponding competences are granted and responsibility is transferred (Sect. 4.8).

4.8

Task, Competence, Responsibility (TCR)

The considerations on the subject of power are summarised in the congruence principle of tasks, authorities, and responsibilities (TCR): Each project body has to also be able to assume the corresponding responsibility for the tasks that are assigned to it. This is usually not the problem; the project managers are very aware of their responsibility. The tricky point lies in the lack of competence, which empowers the project managers to make decisions themselves and to issue instructions to others (Fig. 4.6). The design of the area of competence connected to the respective project roles is an essential factor for the success of the project. No matter how well projects are managed operationally, if the project organisation does not have the competence for its tasks and goals, it will not be able to work successfully. In traditional project management, the power system between the project owner, project management, and line managers needs to be balanced: The project owner has to be sufficiently “powerful” in the line organisation to be able to provide the project manager with the budget and the resources effectively required. The project manager needs a clear project order from the project owner, in which he also clarifies his

Formulate a task Responsibility and competence are always task related

Grant competence Authorisation and freedom of action enable the task to be accomplished

Transfer responsibility By taking over a task I take over the commitment, on deliver a result

Tasks Competence Responsibility

Fig. 4.6 The congruence principle TCR

If there is no congruence between the 3 dimensions, conflicts are likely

334

4

Leadership

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

4.9

Power and Authority

4.9.1

Empowerment and Seizure: Power Is Based on Relationship

Man is fundamentally a self-controlled, “non-trivial system”. His feeling, thinking, and acting are always the result of inner, very complex processes. Whenever a person’s actions or attitudes do not correspond to his natural, inner development and he perhaps acts against his own inclination or despite of his intentions, the phenomenon of power is behind this (Zirkler, 2008, p. 383). Power is neither good nor bad. Power is a basic prerequisite for achieving common goals. Several definitions are also used in relation to power: Power is the ability to cause or influence organisational outcomes (Spisak & Della Picca, 2017). Power is the ability of individuals or groups to influence the behaviour of other individuals and groups in their favour. Abuse of power disempowers other people. Good use of power empowers other people (Beat Hänni & Felix Marti).

Power always and only takes place in relationships. In order for a person to do something that others demand of him, he has to give up his natural predisposition for self-direction. If an unknown person suddenly appears at the workplace and demands a report on the current status of the project, this is hardly likely to happen. It would first be asked who this person is and what legitimises him to access this information. However, if the same request comes from the supervisor, it is promptly complied with. A person who fulfils an expectation from someone else has to always first authorise that other person to influence personal behaviour. In leadership tasks, however, seizure of power is

4.9 Power and Authority

335

needed in addition to empowerment. The project manager or product owner has to also demand and exercise the power that their roles require of them. In the above definition, leadership is an interplay between assuming responsibility and exercising creative power. The leader has to take responsibility for the common goals and also take ownership of the leadership task (e.g. as project manager). However, a project manager only becomes effective when he is given the power to make decisions having to do with the project order, organisation, structure, and methods. In order to be able to do this, all persons and bodies involved in the project need to empower the project manager in his role. The project owner has to give the project manager decision-making authority in the substantive issues, but also in relation to the relationship and organisational level. The individual team members are to align themselves with the common goal and thus consciously subordinate their own will and personal convictions to the group goals. Power is always based on the interplay between empowerment and seizure of power. The self-determined person is in a relationship with other persons through communication, he is someone who can formulate expectations, instructions, or demands. Ultimately, however, it is still the person to whom these demands are communicated, who is to actively assign this power to configure his own actions towards another person. In one sense or another, leadership always requires the empowerment of a person who assumes the leading function and the empowerment of the person on whom this power is exerted. Agile project management also needs an intact power system. If the product owner is not authorised by the customer to make decisions on the content of the sprint reviews, he cannot fulfil his task. The product owner is to then empower himself by actually making the decisions instead of delegating the decision to someone else in cases of uncertainty. And the scrum master also needs empowerment for his role: the team has to empower him to deal with disturbances or to take over the moderation of the sprint retrospective. The line organisation needs to empower the scrum master to quickly deal with all resistance and difficulties that hinder the team in its work. Exciting and also challenging is the game between empowerment and seizure of power in the team itself. There are no clear-cut assignments here. Rather, it is a matter of constantly re-establishing the balance between the two poles.

4.9.2

Traditional Sources of Power

When the word power is mentioned, many people think of authoritarian power. This has a correspondingly negative connotation. In Table 4.5, the traditional sources of power listed here were originally developed by French and Raven (1959) and are still valid (Spisak & Della Picca, 2017, p. 156 f.) Positional power, power through reward and punishment as well as informational power are largely assigned to a person by the organisation (hierarchy) within the framework of the position he holds. The term “institutional power” is used for this. A head of department can decide on appointments, and he can at least have a say in

336

4

Leadership

Table 4.5 Traditional sources of power Power Legitimate power, positional power Power through reward

Power through punishment

Information power Power through identification, role model Knowledge and expertise

Based on. . . • Position or function in the organisation • Employment contract, project order Ability to give other people something. . . • To give them what they desire, or • To take away what they do not desire Ability to help other people. . . • Withholding rewards • Imposing sanctions • Information advantage over others • Membership in governing bodies • Attractive personality traits or resources of a person • Sense of connection and loyalty • Qualification and expertise in a specific area • Diplomas, (project management) certifications

wages and bonuses or, through his professional authority, issue directives. He also decides who gets to take on the more attractive projects and who is likely to do the hard work. Project officers often do not have access to this power in their informal leadership role. This is why the role of the project owner is so important in traditional project management. As the representative of the line hierarchy, he has access to these sources of power. If the project owner makes these or parts of them available to the project manager, power is conferred that is based on borrowed power. This is not the case with power through identification and example. Rather, it belongs to the individual himself as personal power. A role model is someone who does what he says (“walk the talk”). Expertise includes interest and continuous training in the relevant field.

4.9.3

Other Sources of Power in Project Management

In organisations there are other sources of power which are essential for project organisations (Table 4.6). The better project managers or product owners are able to tap into these, the more effective they will be in their roles. Several of these sources of power originate in institutional power: Disposition of resources, decision-making competences, interface management, and disposition of technology are to a significant extent linked to the position a person occupies in the hierarchy. The informal networks and the handling of complexity and uncertainty are achievements of the individual himself.

4.9 Power and Authority

337

Table 4.6 Sources of power in project management (derived from Spisak & Della Picca, 2017, p. 158 f) Power Disposition of resources Decision-making power

Interface management Disposition of technology Alliances and informal networks Dealing with complexity and uncertainties Borrowed power

4.9.4

Based on. . . • Professional authority and direct subordinations • Budget capabilities • Position and project role (also in connection with task, authority, responsibility or RACI) • Linking the project to the line organisation (in project coordination these competences remain with the line managers) • Authority to issue directives beyond a business unit • E.g. a sales manager representing a customer’s claim • Mastering key technologies such as information—and communication technology (ICT) in the age of digitalisation • Informal relationship building, participation in social events • Networking in social media such as Xing or LinkedIn • Personal resilience • Self-management, self-reflection skills • Power delegated by customers and line managers to those responsible for the project

Projects Always Need Borrowed Power

In the area of personal power, project managers themselves are responsible for accessing and maintaining these sources of power. In order to achieve results in organisations, project officers always need access to institutional sources of power. Therefore, in project work, borrowed power has a special role. Those who have access to power, whether institutional or personal, can also lend it to others. And this is the crux of many project managers: in their position in the line organisation (Sect. 5.3.1), they often have little access to institutional power. Whether traditional or agile, project organisations as a whole and the individual project managers in particular can only be successful if they are lent power and that includes the associated authorities from the line organisation. The difference in the two approaches lies in who receives what kind of power. The traditional project organisation provides power to be shared between the project manager and the project owner. The project owner is ideally the representative of the line hierarchy. With his positional power and the associated decisionmaking power, he is the power bearer in the project organisation. The latter empowers the project manager for the tasks in relation to his process competence. Practice shows that especially in project coordination (Sect. 2.3.8.8), line managers hold the principal position of power in the project, which not only reduces project management to a coordination task. It is also often the case that the project owner has no authority to issue instructions to the line managers who then make decisions concerning the release of resources in the project. These specific framework conditions in project coordination are best met by the principles of leadership

338

4

Leadership

without authority to issue directives (Sect. 4.4.3) are best suited to these specific conditions in project coordination. In the matrix project organisation, decision-making powers are assigned to the project manager within the framework of his professional management responsibility. A project manager experiences the strongest empowerment in the pure project organisation. Without the delegation of decision-making power to the project organisation, agile project management in principlecannot function. Only with far-reaching decision-making power the product owner can perform his control task at the content level. The self-organisation of the team can also only work if the decisions regarding the requirements that are implemented in a sprint can be made autonomously. Borrowed Power Is Based on Trust Borrowed power, however, still has an all too human Achilles’ heel. What about you? Do you always generously confer the personal or institutional power at your disposal onto others? Do you openly and unreservedly share your expertise and knowledge in your field? Do you delegate decision-making authority and budgetary responsibility just like that? Probably not, because you know that by doing so you may lose your influence or have to answer for someone else’s mistakes. You will only lend power to another person if you have sufficient trust in that person (Sect. 3.3.5).

4.9.5

Sources of Power: Between Person and Institution

Figure 4.7 summarises the relevant sources of power of project managers and relates them to their background. Role model function, alliances and networks or expertise are possessed by and part of the individual himself. To a large extent, each person can cultivate and develop the power derived from this acting on his own responsibility. Reward or punishment or the power of disposal over resources, however, is to a large extent dependent on the empowerment of the institution and thus on the position of a person in the organisational hierarchy. Located in the middle of the two polarities of “person” and “institution” one finds decision-making powers such as those over technology or interface management. Borrowed power also lies between the person and the institution.

4.9.6

Authority

Where there is natural authority there is no need for a show of power (Hannah Arendt).

According to the publicist and philosopher Hannah Arendt, the difference between power and authority is that authority is granted to a person because of his or her personal characteristics or role in the organisation. However, authority is only granted as long as it is respected without question.

4.9 Power and Authority

339

Personal • Role model • Alliance and informal networks • Dealing with Complexity and uncertainty • Knowledge and expertise

Institutional • Technology • Decision competence • InterfaceManagement • Lent power

• Position • Reward and punishment • Information • Have resources

Empowerment

Authorisation

Fig. 4.7 Sources of power in the project

Authority is described as the basis for a leader’s steadfastness and power to influence (Spisak & Della Picca, 2017, p. 9). According to this description, authority lies in three possible influencing factors, namely: • Personal authority • Professional authority (expert authority) • Formal authority (authority based on hierarchy) Authority, taking into account what has been said about power, is therefore a consequence of power. Those who have access to the personal and institutional sources of power as described above also rely on at least one of these three influencing factors of authority. Example

It is also possible that managers have access to the sources of power listed above but are not respected in their roles due to their personal behaviour. Thus, they are not acknowledged as having authority. ◄

340

4.10

4

Leadership

Negotiation

4.10.1 Negotiations in Project Management Working in a project with its innovation mandate, goal orientation, and interdisciplinary cooperation for a limited period of time leads to certain natural consequences: a.o. different interests, requirements, convictions or intentions have to be permanently coordinated. And all this has to happen within the framework of the magic triangle, which is made up of the influencing factors “scope”, “time”, and “costs” (Sect. 2.3.4). At the beginning of a project, one of the essential tasks of the project manager or product owner is to negotiate a project order that sets up “scope”, “time”, and “costs” in a realistic relationship to each other. Negotiations are also repeatedly necessary during project implementation, whether in change request management (Sect. 2.5.8), in the problem-solving process (Sect. 2.3.14), or in role clarification (Sect. 5.3.1). Thus, negotiation skills are an important competence in the context of project work: If you start a project with an illusory project scope, schedule, or budget, you increase the project risk and thereby also present the team with unrealistic challenges. Those who are unable to negotiate project roles and responsibilities by this only confirm the expectations of others and do not live up to standards of personal self-management (Sect. 3.8). Negotiations, like project management, thrive on versatility (Sect. 1.7.1). Like in a chess game, different scenarios are prepared in order to be able to react quickly and flexibly in the situation itself. This means that preparation is an essential success factor for negotiations.

4.10.2 What is a Negotiation? " A situation is called a negotiation when two or more parties, in conversation, try

to come to an agreement on an issue or a set of issues (André Baer). These parties can. . . • • • •

Hold different views or pursue individual goals Be equipped with the competence to act and make decisions Have an interest in a solution Be under pressure to reach an agreement or an outcome

The reason for negotiation lies in differences assessing views or goals. In addition, there needs to be a common interest in finding a solution or in reaching an agreement. The most important prerequisite for a negotiation is the freedom of action and decision-making of the parties involved. In project work, these depend on the connection of the project to the line organisation. (Sect. 2.3.8.8) and on the clarification of roles with the TCR (Sect. 4.8): If the project is integrated into the line, e.g. through coordination, the project manager is merely a project coordinator. In this role he has little or no decision-making authority. He is not legitimised to lead

4.10

Negotiation

341

negotiations. Negotiations have parallels to conflicts. For this reason, the topic of conflict management (Sect. 5.6.9.4) will deal with elements of negotiation.

4.10.3 Negotiation Cycle A negotiation is a complex process. Therefore, it is important that the approach to negotiations reflects this complexity. The negotiation cycle described below (Fig. 4.8) provides a guideline that has proven its practical usefulness many times. The process consists of the three main phases “preparation”, “negotiation”, and “evaluation”.

4.10.3.1 Preparation Preparation is central to conducting negotiations. In complex negotiations, this can take weeks or even months. The preparation phase consists of the following steps: Situation: Problems and Needs Before choosing a negotiation technique and strategy, the situation at hand has to be analysed. The focus is on immediate problems and needs, or, to say it in the language of project management methodology, the objectives (Sect. 2.3.2). The following points or questions need to be clarified:

Preparation Situation Goals Informations Strategy Tactics

Eva ti o lua

n

Fig. 4.8 Negotiation cycle (after André Baer)

2

Contact phase Core phase Agreement phase

ot

Analysis Measures

iat ion

1

3

g Ne

342

4

Leadership

• What is it about? Where is there a difference, what is the subject of negotiation? • Is there any room for negotiation at all? Or does bad news simply have to be delivered? • Which people are involved? What freedom of action do they each have? • For customer projects: Which aspects or framework conditions are specified by the contract? • In conflict-laden situations, additional clarification is needed: • What are the parties really about? • To what extent can a distinction be made between symptom and cause? Goals The goals are developed from the present perspective. They open up the future perspective. It is often easy to name problems. However, formulating solutions in a positive way is considerably more difficult. When formulating goals, the negotiating party has to also be clear about what priority each goal has for them. Moreover, this step is not only about one’s own priorities and goals. The goals and priorities of the negotiating partner are to also be included here. The target pyramid Fig. 4.9 allows one to concretise one’s own goals and their priorities and to make assumptions about what these look like from the perspective of the negotiating partner.

Our goals

Objectives of the negotiating partner

1. Relationship with the customer

1. Reliable suppliers

2. Secure order situation

2. No production loss because of late delivery

3. Protect reputation

3. Cost optimisation

4. Do not lose customer

4. No extra effort through new supplier evaluation

5. Ensure contribution margin

5.

6.

6.

Date:

Fig. 4.9 Example target pyramid for a client project

Responsible:

4.10

Negotiation

343

The personal goals are to be described as concretely as possible. The following points or questions should be clarified: • What do I have to achieve (must have), where are my limits? If these minimum goals are not achieved in the negotiation, this would mean breaking off the negotiation (walk-away position). • What goals am I aiming for in a realistic scenario, what can I count on (want-tohave position)? • What alternatives are possible? What would be a plan B? The better my alternatives, the stronger my negotiating position. We can never know for sure what the negotiating partner’s goals are. But we can make assumptions or form hypotheses (Sect. 5.6.7.1). To do this, we ought to see things through the other person’s eyes, change the perspective. The following points or questions need to be clarified: • What are the goals of my counterpart? • For customer projects: What restrictions or conditions is my negotiating partner confronted with through his organisation? Information Based on the concretised objectives, all information that may be relevant in some way for the negotiation is collected and evaluated: • • • • •

What scope is there for negotiation? Where are the possible areas of agreement for each point of negotiation? Where is the limit? When would a negotiation have to be broken off? What legal restrictions need to be taken into account? What about the distribution of roles?

Strategies The choice of negotiation strategy (Fig. 4.10) is based on similar criteria as the stakeholder analysis (Sect. 2.3.5): Relationships, interests, power, and demands. The more pronounced the relationships and interests are, the more cooperative the negotiating parties will behave. The greater the demands and the more the negotiating parties use the sources of power available to them, the more demanding they will be. Cooperative Strategy (Integration) If the negotiating parties succeed in integrating their common interests into an overall package or focus on a common, sustainable solution to the problem, the cooperative strategy makes it possible to find optimal solutions for all parties. The negotiation result is achieved with the greatest possible efficiency for both sides. The goal is to achieve the Pareto optimum and not the maximum. The groundwork

4

non-cooperative

Relationship, interests

cooperative

344

Adaptation strategy • Sacrifice your own interests • Submit to the relationship to relax

Leadership

Cooperative strategy • The agreement is the goal • Focus on creation on both sides advantageous options

Compromise strategy Do mutual concessions, find a reasonable agreement Evasion strategy • I would like to wait until I strengthened my position • Avoid that relationship is damaged

deep

Enforcement strategy • Focus on the difference, not commonality • Focus on worsening foreign and improving their own alternatives

Power, demand

high

Fig. 4.10 Negotiation strategies (according to André Baer)

for this is done in the goal pyramid (Fig. 4.9), in which the type of negotiation goals and their prioritisation have a high degree of congruence. In the cooperative strategy, common ground is emphasised. An attempt is made to create a negotiation constellation advantageous to both parties. This strategy thrives on open and honest communication. There is no use of pressure tactics, but instead flexibility in the negotiation process and creativity in the search for solutions. This strategy is the basis of the Harvard concept, which will be dealt with specifically in the following (Sect. 4.10.4). Assertion Strategy (Confrontation) In assertiveness strategy, the main goal is to assert one’s own needs, which can have the effect of diminishing the position of the other party. The differences are emphasised. The relationship with the negotiating partner is not considered important. Therefore, it is accepted that the relationship will suffer, break down, or stiffen if the other party is confrontational, too. Adaptation Strategy In the adaptation strategy, one’s own interests are sacrificed. This strategy is chosen when the relationship with the negotiating partner is to be relaxed. Well dosed, this strategy makes sense in any given situation. However, it must not happen that one

4.10

Negotiation

345

party is permanently exploited due to personal weaknesses in negotiating procedures. Compromise Strategy In the compromise strategy, both parties meet halfway. Both make concessions in order to reach a mutually acceptable agreement. This strategy also makes sense in any given situation. In the long run, however, no one is made happy by it. Therefore, in medium- and long-term working relationships, precaution should be taken that compromise does not become the standard. Evasion Strategy The evasion strategy is chosen when a confrontation would be completely pointless in the current situation. If the counterpart holds all the trump cards, be it in terms of content or power factors, negotiating makes no sense. One remains inactive in order to gain time for further clarification. In this situation, it is better not to risk the existing relationship and wait for a more favourable moment. Example

If the customer insists on the contractually fixed delivery date, this would leave no leeway and thus no possibility of going through a negotiation in the strict sense. Then, if the project manager cannot meet the deadline, he becomes unable to negotiate with the customer
putting a strain on the customer–supplier relationship. It turns into a negotiable situation when the parties involved take a different stance, when the project manager is able to negotiate with the customer or his project owner about variants of service delivery. The subject of negotiation might be that a partial delivery gets made or that a different quality is delivered and that therefore a price reduction is then granted for this. It can be negotiated with the project owner to pay the customer a contractually defined claim for damages (Claim) or to allocate more resources to the project in order to fulfil the contract on time. The strategy chosen depends on the prioritisation of one’s own goals and the assessment of the negotiating partner’s goals (goal pyramid). If the customer relationship and one’s reputation are paramount, an adaptation or cooperation strategy is more likely to be chosen. If, on the other hand, one’s own financial interests (contribution margin, order situation) are in the foreground, a compromise or an enforcement strategy would become acceptable. It is often not within the project manager’s decision-making authority which strategy primarily gets chosen. However, through his clever negotiation skills, he can bring about that the parties decide upon more cooperative strategies in order to solve the problem. ◄ Tactics Once the most effective strategy and at least one plan B have been worked out, the tactics for the negotiation can be defined. These tactics also depend on the character traits of the people involved in the negotiation. Tactics include:

346

4

Leadership

• Having the place, room, and time for the negotiation. • Determining people to be involved: project managers or product owners are to ensure that all people who have the freedom of action or of decision for the negotiation items—are involved in the process, e.g. sales, project owner, or line managers. • Demand more than you want: In order to room for manoeuvre in the negotiation, more usually gets demanded at the beginning than is actually needed. • How should arguments be made? What justifications ought to be used to support one’s own negotiating position?

4.10.3.2 Optimal Negotiation Strategy and Tactics: Situational Negotiations always take place between people. These people are in relationships with each other. The conduct of negotiations will strongly depend on how the relationship with the direct negotiating partners (project owner and project manager) as well as the indirectly affected parties is assessed. If the customer is a non-strategic one, a possible claim may be the lesser evil than allowing resources to be diverted from yet another, perhaps strategically important customer project. However, if the customer is a strategically important reference customer, carrying a high risk of losing potential follow-up orders, this will significantly influence the negotiation between the project owner and the project manager. The relationship between the project owner and the project manager is also relevant: If the two have been working together for years in a delegative or participative leadership style, then this is a completely different starting position than if the project owner leads his project manager in a directive way, unafraid to play out his institutional sources of power. In the first case, within the participative management relationship between project owner and project manager, negotiation according to the Harvard concept (cooperative strategy) becomes appropriate. However, this concept does not work if one party uses its power inflexibly in the negotiation. In such a case, it is advisable to choose a negotiation strategy adapted to the situation. The choice of negotiating strategy should always be guided by the following rule: The strategy to be chosen should always be one that aims at long-term cooperation while preserving one’s own reputation.

In principle, the best results can be achieved in the long term with a cooperative negotiation strategy. However, this requires that the parties manage to integrate their different interests. Therefore, cooperation in this regard should always be considered as the best and first choice. Even so, this usually means that it is possible to include new, additional negotiating items in the negotiation process in addition to what it was all about in the first place (Fig. 4.11). Figuratively speaking, it is not primarily about dividing up a cake (confrontational negotiation), but about enlarging it in order to generate additional benefits for both parties (cooperative, integrative negotiation). As soon as one party starts to elbow its way through to its own advantage, integration is no longer possible.

4.10

Negotiation

347

Confrontational negotiation

B A

Fight, often unfair distribution

Cooperative, inclusive negotiation

B A

Subject of negotiations

New, additional items for negotiation

Fair, just distribution

Extended, bigger bargaining chips

Fig. 4.11 Cooperative strategy through new negotiation items (after André Baer)

4.10.3.3 Negotiation After preparation, the effective conduct of negotiations can begin. This is based on the following phases: 1. Contact First of all, an optimal environment for the negotiation needs to be established. Above all, the compromise and cooperation strategy depend on whether the negotiating parties succeed in establishing trust for each other (Sect. 3.3.5). Then the goal for the negotiation hast to be clarified. Possible non-goals should also be delineated. The negotiating parties should be able to put forward their demands and wishes in this step. Finally, the agenda is set: Time frame, agenda, and procedure. It should also be clear which communication rules apply and who plays specific roles such as moderator or chair of the meeting. 2. Core phase The core phase of the negotiation is divided into three sections: a. Exchange of information • Presenting the topic, the problem • Pointing out effects, significance, consequences of the situation for both sides • Commenting on each other

348

4

Leadership

b. Negotiating leeway • Identify negotiating leeway for each component • Investigate whether a common platform for concessions is appropriate • Expand the negotiating mass by integrating other interests c. Solution search • • • • •

Clarify priorities Show scenarios and solution variants Exchange possible concessions Evaluate the usefulness of the results Make a decision

3. Agreement phase The negotiation phase is concluded by the agreement phase. First, the results and decisions of the negotiation are summarised. Finally, the binding nature of the implementation is established through a contract or a protocol. a. Summary and outlook • Summarise results • Check that there are no misunderstandings • Agree on objectives and a timetable for implementation • Discuss and initiate measures b. Agreement, contract • Record results in writing • Agree on further steps • Record what is to happen in the event of non-compliance with the agreement • Arrange a follow-up appointment • Thank the negotiating partners

4.10.3.4 Evaluation and Controlling Like a project, a negotiation also gets evaluated. One’s own conduct of the negotiation, and thus the entire preparation with the definition of strategy and tactics, hast to be analysed, with possible measures for the future inferred from this. In addition, it needs to be guaranteed, in the sense of a controlling procedure, that the agreed-upon measures are implemented accordingly by all negotiating parties.

4.10.4 Conducting a Negotiation According to the Harvard Concept The negotiation according to the Harvard concept (Fisher et al., 2018) is a cooperative negotiation strategy. With this approach, optimal negotiation results can be achieved under the following basic conditions:

4.10

Negotiation

349

• The parties have common areas of interest • The parties refrain from using their power • The parties have high communicative competence and disclose their information Under these premises, the Harvard concept is also well suited for dealing with conflict situations. In Sect. 5.6.9.4, conflict management according to this concept is presented.

4.10.4.1 Separation Between Person and Topic The Harvard concept has become known for its slogan “Hard on the subject, soft on people”. The essence of the model is outlined in Fig. 4.12. As long as all parties to the conflict meet as equals, the focus is on the integration of interests and no institutional power factors such as positional power, decision-making power, or power through punishment (Sect. 4.9) are used, the best possible results can be achieved (Fisher et al., 2018). The content of the negotiation has to be clearly separated from the person. Whether we like the other person or not should have no influence on our negotiation. As in sport taken seriously, the point is to argue with commitment during the negotiation. Afterwards, you respectfully shake hands. In negotiations you:

Person

Thing

Humans People and problems treated separated from one another

Interests Not positions, but interests to put in the center

Possibilities Develop various options before the decision

Criteria Build the result on objective decision-making principles

«Hard on the subject, soft on people»

Fig. 4.12 Key factors in the Harvard concept

350

4

Leadership

• Create trust: A “negotiating space” is needed in which all parties feel safe • Clarify roles and responsibilities of persons (parties) involved in the process • Clarify the rules of communication: I-message, active listening, letting people finish and without making assumptions about the other person’s intentions, but rather asking questions.

4.10.4.2 Interests Instead of Positions The next step is to detach the negotiation from positions describing what we pretend to want. This might be a struggle by project manager with his project owner for more resources. In a position there is always a weaker party (in this case, the project manager) and a stronger party (the project owner). In this example-constellation it is difficult to reach an agreement. If, on the other hand, the project manager succeeds in getting the project owner to commit to a common interest, the negotiation can be conducted at eye level. The perspective shifts from the present to the future: • Focus on common interests and needs: Why do we want something? This may entail risks needing to be eliminated, qualitative aspects or common interests in terms of project duration. • Change of perspective: In order to find common interests, I have to be able to ask myself what the negotiating partner needs from me and what difficulties or limitations they are facing. "

In order to bring about a change of perspective from a position (what?) to interests (why?) and also towards needs, the metamirror suggested by Robert Dilts or the model of the conflict onion is helpful (Sect. 5.6.9.4).

4.10.4.3 Possibilities The more variants there are available in a negotiation, the greater the scope for decision-making. In this phase, the aim is to work out different options that fulfil the aspects of the interests and needs that have been worked out. One has to: • Develop realistic options: The best solution is usually obvious to everyone, but it is not realistic because all organisations delivering projects are always performing a balancing act between the elements of the magic triangle of “scope”, “time”, and “cost”. The second-best solution is to develop realistic options. • Work out other alternatives besides the optimal variant. There needs to be at least one plan B, better still even more possibilities and variants. • Actively involve negotiating parties in the development of possible solutions. This will increase commitment in a later implementation. • Consider that developing different possibilities needs creativity. • The better it is possible to find ways of finding the right balance between the interests of the parties, the more significant the win–win situation for all parties involved.

4.11

Moderation

351

4.10.4.4 Fair Criteria Prior to the effective assessment of the variants, the decision criteria are recorded in a solution-neutral manner following the SMART rule (Sect. 2.3.2.4) as far as possible. The joint discussion of objective criteria that can be applied to the selection of the negotiating alternative makes it easier to leave positions. It also removes the basis for unfair pressure from either side. Common criteria are: • A cost ceiling which may not be exceeded • Specific risks that need to be reduced • Milestones that have to be met

4.10.4.5 Selection According to the BATNA Principle When these four aspects have been considered, the best alternative solution can be chosen. This should be done using the BATNA principle: Best Alternative To a Negotiated Agreement. In decision-making situations, people are always influenced by their feelings, personal goals, and intuition. To see to it that reason and intellect are also adequately taken into account, it is advisable to apply decision-making techniques here (Sect. 2.8.3).

4.11

Moderation

Moderation (from “moderari”, Latin for moderating, guiding, finding the middle) is one of the central competences for successful projects and is needed when processes in the team need to be guided and directed, e.g. for creative problem solving, a decision-making process, opinion forming in the team, conflict resolution, etc. In such situations, reflection or feedback culture in a group is also often promoted. The following requirements are important for successful moderation: • Process competence: The facilitator has to know how to make the group work and how to achieve the meeting objectives. • Social competence: The facilitator must understand and be able to respond to the dynamics of the group; and, if necessary, address these (relationship before matter). • Communication competence: The facilitator needs to master the methods of questioning and directing the conversation. He is to intervene immediately in the case of assessments (you-messages) and boundary violations (Sect. 3.9). • Competence for complexity reduction: In order to be able to work on complexity, it has to be reduced through visualisation techniques, developing scenarios, mind mapping, and other instruments of structured problem solving.

352

4

Leadership

It Subject level - Visible - Conscious Relationship level - Invisible - Unconscious

Me

11% 89%

Facts Language Actions Thoughts Emotions Intentions

We

Fig. 4.13 Iceberg model

4.11.1 Iceberg Model "

“On the factual level, only what the relationship level allows is possible”.

Moderation also means analysing and supporting the level of relationships among the participants. The clarification of roles at the beginning of a meeting should lead to the result that resistance in the course of a meeting does not get relegated to the factual level “It” (Fig. 4.13, iceberg model), but that it can be openly addressed on the relationship level “Me” or “We” and resolved in the group (Ruth Cohn, ThemeCentred Interaction, 2001).

4.11.2 Phases of Moderation “Who asks leads”. This is especially true for the facilitator. He uses questions to steer the process through the various work phases (Table 4.7).

4.11

Moderation

353

Table 4.7 Phases of moderation Phase Prepare

Opening and orienting Collect and select

Edit Plan and finalise Review

Topics to be clarified, questions What is to be achieved? (Goals and expectations) What arrangements and clarifications need to take place before the meeting? Which goals are to be achieved? What is the planned procedure? Creating a constructive working atmosphere, building trust Conducting a review of the meeting topics Collecting further concerns Setting up a prioritisation of the topics Actual processing of the selected topics Commitment and clarity of order: who does what by when? Retrospective Protocol and post-processing Checking agreements and results

Table 4.8 Responsibilities and competences of the moderator Topic Responsibility

Skills

Description • Responsible for the process and not for the result • Selecting an appropriate course of action • Clarification of dual roles (e.g. project manager and supervisor) • To make and keep the group fit for work • Equal involvement of the participants • To lead via questions (. . .instead of by guidelines) • To keep the activities of the group focused on the goal • Being able to think your way into the meeting content • Process and methodological skills • Questioning techniques and social skills • Meaningful visualisation of the course of the conversation • Ability to reduce complexity • Recognising and resolving misunderstandings

4.11.3 Responsibility and Competences of the Moderator In order to develop one’s own understanding of facilitation, it is essential to be clear about the responsibilities and competences in the role of the moderator. Table 4.8 shows possible dimensions.

4.11.4 Checklist for the Preparation of a Moderated Session The following points are helpful for preparing and conducting a moderated meeting, the moderator:

354

4

Leadership

Start-up phase: • • • • • • • •

Pays attention to seating arrangements or even specifies them Formulates the meeting objective at the beginning Briefly picks up all participants at the beginning Defines binding time frame Clarifies his and the participants’ roles Finds the best possible approach with the group Agrees on further rules of the game and ensures that they are observed Make sure that there is appropriate protocolling Basic attitudes the moderator ought to show are:

• • • • • • •

An appreciative attitude towards the persons A neutral attitude regarding topics and participants Being present with head, stomach, and heart Giving social interferences priority The ability to work with the group instead of fighting against it To not be defensive have a self-justifying stance Being able to distinguish between perceiving, assuming, and evaluating Communication, the moderator should:

• • • • • • • •

Ask instead of tell Pay attention to the level of detail Visualise the process flow Activate “silent” participants Intervene with frequent speakers Uncover potential for conflict Analyse the language habits Pay attention to verbal and paraverbal communication Closing phase, the moderator:

• • • •

Recapitulates and summarises results Demands concrete decisions and responsibilities Formulates the further procedure Thanks the participants and closes the meeting

The specific requirements for virtual meetings are described in the following Sect. 4.12.

4.12

4.12

Communicate Effectively with Virtual Teams

355

Communicate Effectively with Virtual Teams

Leading virtual teams represents an additional challenge for those responsible for the project. A virtual team is made up of people who work in geographically, temporally, and organisationally different dimensions. Cooperation is made more difficult because the team members speak different languages or come from different cultures. Communication, in this case, between project members often takes place asynchronously and frequently using a meta-language because they do not share a native language and skills in the language used alternatively are not sufficient. Example: French speakers communicate with German speakers in English. It is advisable to carefully agree on the rules of communication across these boundaries and to clearly define the communication channels and collaboration platforms to be used. Digital platforms facilitate collaboration considerably. The following examples illustrate this: A SWOT analysis can be carried out synchronously with a whiteboard application on an online platform, but it can also be processed asynchronously with a corresponding word template in a time frame agreed upon beforehand. Or project planning can be partially outsourced to the project members with the help of a kanban board and then always remains up to date compared to a manually tracked project plan. In the physical world of work, much information is conveyed verbally. In the virtual world, on the other hand, the proportion of written communication is much higher. Written communication in the project takes place less and less by email, but increasingly via collaboration platforms. This means that rules for the digital exchange of information are becoming more and more important (Sect. 4.4.5). To optimise its communication, a project team should agree on a communication codex. Key points are: • Meaningful subject line: this determines how quickly the message is read • No novels: no scrolling, no resentment • Rapid response: this does not necessarily have to be a substantial response to an email • Correct spelling: a minimum of appreciation for the recipient • Always be polite: “Hello” does not go down well with everyone • No jungle of abbreviations: brgds, fyi, cu,. . . • No emojis: not always a good thing in business communication • Add a signature: Your business card as sender Virtual meetings have different needs in terms of preparation and implementation and require that a minimum level of trust already exists in the team. In order to achieve this, the PERMA model by Martin Seligman (Seligman Martin, 2012) defines important prerequisites for this (Sect. 5.4.2). Figure 4.14 shows some aspects that are helpful for preparing and conducting a virtual meeting.

356

4

Check-in

Prepare • • • •

Measure pulse

Visualise

what do I need to know what do I want to say what do I want to achieve what does the team need

Ensure, that ... • all see the same • all can contribute something • all have access to important documents

Integrate Ensure, that ... • all see, hear and have understood the same thing • all agree

Leadership

Check-out

Agree Everyone knows ... • what the goal is • what they have to do • who needs what by when • how they work together • how to escalate

Build trust and stay connected

Fig. 4.14 Sequence of a virtual meeting

Because verbal feedback or a non-verbal reaction as in a face-to-face meeting is often lacking, the following aspects have to be considered in the individual phases of a virtual meeting: Check-in: At the beginning of the meeting • Build additional trust through a short round of talking about sensitivities; introduce informal topics and see to the mood of people and allow for the appropriate space (disruptions have priority). • Share recent experiences in the team: “What did you do well?” “What are you working on at the moment?” “What are you particularly busy with at the moment?” etc. • The question: “Who wants to start?” usually does not work virtually. Clear announcements are needed, e.g. who speaks in which order. Time management in topic processing • Announce and stick to regular breaks • Keep technical contributions as short as possible, rather distribute this type of information in advance • For improved interaction, delegate the participants to supervised breakout sessions

References

357

Measure the pulse: After completion of the integration phase • Check whether the results or decisions taken are to everyone’s satisfaction: “Are you happy with the result?” “Will this decision be well received in your department?” etc. Check-out: At the end of the meeting • Obtain mutual feedback on the procedure or outcome of the completed meeting: “How did you feel about our work process?” “What did we solve well?” “What was not satisfying?” “What would you do differently next time?” etc.

References Blanchard, J. H. (2015). Management of organizational behavior. Pearson India. Fisher, R., Ury, W., & Patton, B. (2018). Das Harvard-Konzept. Deutsche Verlags-Anstalt. French, J., Jr., & Raven, B. (1959). The bases of social power. In D. Cartwright (Ed.), Studies in social power (pp. S. 150–S. 167). University of Michigan. Gellert, M., & Nowak, C. (2007). Teamarbeit – Teamentwicklung – Teamberatung (3. Auflage Ausg.). Limmer Verlag. Martin, S. (2012). Flourish: A visionary new understanding of happiness and well-being. Atria Books. Oestereich, B., & Schröder, C. (2020). Agile Organisationsentwicklung. Franz Vahlen GmbH. Radatz, S. (2009, Januar 28). Führen ohne. In Führungsmacht. ProjektMagazin. Seliger, R. (2014). Positive leadership – Die revolution in der Führung. Schäffer-Poeschel Verlag. Spisak, M., & Della Picca, M. (2017). Führungsfaktor Psychologie. Springer. Zirkler, M. (2008). Konzepte der Macht. In T. Steiger & E. Lippmann (Eds.), Handbuch angewandte Psychologie für Führungskräfte (Vol. II). Springer.

Further Readings Baer André. (2018). Unveröffentlichte Seminarmanuskripte. Breidenbach, J., & Rollow, B. (2019). New work needs inner work (2. Auflage). Franz Vahlen Verlag. Frederic, L. (2015). Reinventing organizations. Franz Vahlen Verlag. Kühl, S. (2015). Wenn die Affen den Zoo Regieren – die Tücken der flachen Hierarchien. Campus Verlag. Zirkler, M., & Werkmann-Karcher, B. (2020). Psychologie der Agilität – Lernwege für Individuen und Teams. Springer.

5

Teams

This chapter deals with the fundamental aspects of teams and groups and the dynamics that can unfold in them during project work. The focus lies on procedures facilitating successful role clarifying, on how the principles of positive psychology can have an effect on a team, and what the characteristics of a high-performance team are. The chapter concludes by describing change and resistance as well as by taking a comprehensive in-depth look at conflict management and crises. The topics are structured according to their relevance for the agile and the traditional approach.

5.1

Aspects of Teams and Groups

5.1.1

What Distinguishes Teams from Working Groups?

Teams differ from work groups in terms of efficiency, values, working culture, and in how they see themselves as a unit. A team is a group of active individuals whose overall performance exceeds the sum of the individual performances due to the nature of their cooperation. This cooperation has to be continuously developed in order to optimally utilise the performance potential of each individual. This realisation is often described in the formula 1 + 1 = 3. The team pursues a goal that can only be achieved by working together. A key feature is the participation of members in decision-making and the ability to deal productively with conflict. Teams, unlike working groups, have learned to deal productively with the diversity of their members and the resulting conflicts. The goal is delivering good results and not adhering to conformity. The team has the necessary creative leeway to achieve this. These differences can be summarised in Table 5.1.

# Springer-Verlag GmbH Germany, part of Springer Nature 2023 J. Kuster et al., Project Management Handbook, Management for Professionals, https://doi.org/10.1007/978-3-662-66211-3_5

359

360

5

Teams

Table 5.1 Differences between teams and working groups Team • Understanding as a unit of work • Self-organisation • Results orientation • Error tolerance rather high • Professional conflict management • Identification with the group • Coordination • Group responsibility • Complex work processes • Good relations with each other

5.1.2

Working group • Understanding as a collaborator • Organisation by superiors • Focus on individual task completion • Error tolerance rather small • Less risk for conflicts to emerge • No common identification • No personal connections • Individual responsibility • Standardised processes • Relationship with each other not important

Composition of the Project Team

The following guiding principles contribute to the ideal composition of a project team: Who Puts Together the Project Team? The project team is officially appointed and released from responsibility by the project owner after the project is completed. However, those responsible for the project need to be able to exert a decisive influence on the selection of the members. In all organisations, they are therein dependent on the help of the managers. In order for them to be able to send the right people to the project teams, the project owners and the project managers have to formulate a requirements profile for the future project team members. The Objective of the Project Phase Determines the Team Size Depending on the project phase, the project team composition can change. For feasibility studies and process planning, a smaller “mastermind group” is advantageous. If, on the other hand, the broadest possible acceptance is to be achieved, it is more likely that a large, preferably representative team will be chosen. For those responsible for the project, this can lead to a dilemma: If all stakeholders are to be represented or the project owner puts together a large team, this results in groups becoming far too large and cumbersome. In such a case, the formation of a project management team (core team) that does the essential preliminary work ensures mutual coordination and then submits this to the “extended project team” for further processing. Changing Skills Are in Demand Different skills are required in the different phases. For example, a lot of creative thinking and “tinkering” is needed during the concept phase, whereas organisational skills and marketing knowledge are required in the implementation phase. These skills may not all be found to be present and available in the same people, so it may make sense to change the project team members in the course of the project.

5.1 Aspects of Teams and Groups

361

When changing project team members, the following critical points should be considered: • Careful and detailed handovers are to take place between team members. • This is done to regulate for which problems the predecessors were “susceptible” and to what extent they have to be available to the successors in solving them. Depending on the project (Sect. 1.2.1), different skills are required, and these skills are in varying degrees of strength. For example, a project needing a strong potential and a character of its own will want innovative and creative free thinkers, whereas a high acceptance project will need excellent communicators who can approach people, listen to them, and work out arguments for the project with them. If You Don’t Have the Time, Then It Is Better You Leave It Team members who cannot or do not want to devote enough time to the project often block cooperation and thereby project progress. Specific technical experts with selective tasks are exempt from this. Therefore, it is important to clarify at the very beginning: • How much effort the members will have to expect. • Whether they will be released from their normal duties to the appropriate extent. Against Too Much Harmony in the Team Every project manager wants the “chemistry” in his project team to be “right” and to see everybody work together harmoniously. This wish is understandable, but not always reasonable. Tensions that arise from the problem or from some of the conflicting interests of different organisational units are in themselves not a bad thing. On the contrary, they can be used as an opportunity to clarify things in the project team. Problems that are bypassed or put on hold during project work will later re-emerge in a much more dramatic way. Dramatic because as the project progresses, the financial and temporal adjustment effort required to correct such “mistakes” increases disproportionately. "

Save your need for harmony for after work and bring critics and lateral thinkers into your teams. Demand a breath of fresh air and realism in project work. In doing so, make sure that you do not overtax yourself and the other project team members. If the right balance is lacking, this will obstruct work to a high degree, resulting in losses instead of gains.

362

5.2

5

Teams

Dynamics in Teams

Independently of whether an agile or a traditional approach is chosen, according to Bruce Tuckman each team goes through certain phases of a team development process in a specific way. For the five phases shown in Fig. 5.1 the following terms have become accepted: Forming, Storming, Norming, Performing, and Adjourning. Each of these phases contains specific challenges, opportunities, and also dangers, all of which are described below (Gellert & Nowak, 2007, p. 192 ff).

5.2.1

Forming: Orientation

high

In teams that are newly formed, e.g. at the project kick-off, there is more or less uncertainty at the beginning. The members of the group ask themselves what exactly is in store for them, what their personal role shall be, which rules have to be observed, or who the other team members are and how they are going to tackle the tasks. According to their personal characteristics, the team members behave very differently in this phase: some are curious and expectant, others are more reserved or even sceptical.

Danger of a conflict

Top team

Performance

Work group

Team development

Conflict

Developed group

Change

small

Danger of change

Forming Orientation Opening Access Security

Storming Confrontation Regulate Stability Attention Communication

Norming Familiarity Give room To keep the border Sticking to goals

Performing Work in the system To advise Controlling To recognise overconfidence

Fig. 5.1 Five development phases of teams according to Bruce Tuckman

Adjourning Farewell and separation Project review Successes Asynchrony

5.2 Dynamics in Teams

363

The forming phase is characterised by polite, reserved, and a rather distancekeeping behaviour of the members. They are not yet a team in the real sense of the word. "

The most important tasks for team development in this phase are: • Opening: The project managers should create framework conditions and implement interventions that allow the individual group members to get to know each other and develop trust in each other. • Access: Finding access to the content of the project objective. Depending on the assignment, the aim is to achieve the willingness to get involved in something new. • Security: In order to reduce uncertainty, the ability to work needs to be established as well as possible. This includes clarifying the project organisation with the respective roles (agile or traditional), defining reporting channels and information flow or even explaining the entire document management. This helps the individuals to find their way in this first phase.

Careful preparation and implementation of the kick-off represents a valuable contribution to dealing well with the challenges in this first phase of team development.

5.2.2

Storming: Discussion

After a team has been formed through the forming process, work begins on the substantive goals and tasks. The work in the system is in the foreground, the system itself with its relationship and organisational level is usually still weak. The team members now cast off their former reserve and show more openness of character. After the team structure has been regulated on the formal level through the organisational chart or role assignments in the forming phase, the team must now also find itself on the informal level. This phase can be quite unproblematic if the team members already know each other and have already gone through team development in other projects. But if frictions and animosities from a previous collaboration are still unresolved, (new) team members pose a challenge to the formal or informal team organisation. Or a higher-level body delegates a conflict to the project (Sect. 5.6.2). It is then that disputes and conflicts arise. In the storming phase, the group is characterised by tense expectations and the hope for good

364

5

Teams

cooperation. At the same time, this young team is still very susceptible to disruptions. "

The most important management are:

tasks

in

agile

and

traditional

project

Rules: The rules established at the kick-off are now tested by the team for their stability. Those responsible for the project have to keep a watchful eye on which rules of cooperation are effective and where improvements can still be made. Steadfastness: In this phase, the team members test the different roles and committees (agile or traditional) for their assertiveness and (factual) competence. They see themselves as being increasingly confronted with questions and sometimes also with criticism. Behind this behaviour also lies the basic need for social recognition in the group. Good composure and steadfastness will help the managers in this phase to consolidate their personal roles in the group. Attention: In this phase, the group dynamics are played out on several levels. Not everything has to be addressed and dealt with. But wherever the team’s ability to work is impaired, scrum masters or project managers have got to intervene. In these situations, conflict management or dealing with resistance can help. Communication: In order to control this phase well, a well-developed communication and feedback culture is needed. Only if communication and feedback are designed to have a clarifying effect and are not judgemental can the group members exchange ideas without fear. Agile project management has a valuable platform for this: the daily stand-up meeting. The fact that the meeting takes place every day creates a high degree of transparency, thus helping to deal with tensions between people or teams before they get out of hand.

In the storming phase, the work on content is often tedious and slow. However, this work in the system should not be in the foreground here. Much more important is the work on the system. Every behaviour of the people involved can be examined in a differentiated way in terms of symptoms and causes. In dealing with the essential causes lies the great opportunity to develop the work on the system in such a way that the foundation for a high-performance team is created. By focusing on the work on the system in this phase, scrum masters and project managers create the starting point for the next group phase.

5.2 Dynamics in Teams

5.2.3

365

Norming: Familiarity

Through dealing with the different friction points, conflicts, or resistances, the fears of those concerned can be reduced and their roles further clarified. This creates feelings of security. Addressing difficulties and personal needs openly increases the inner cohesion of the group so that a group identity can emerge after the individuals have found their position within the group. It is specifically thanks to the challenge passed through together in the storming phase that mutual trust grows (Sect. 3.3.5). This can lead to cohesion in the group. Cohesion as a sense of community and solidarity that from then on exists in a team. Cohesion has a significant influence on the stability of a group, making the team become attractive to its members. New group norms also encourage more an open and personal behaviour. Table 5.2 shows cohesion-promoting and inhibiting measures and framework conditions. But there is also a downside: the higher the cohesion in a group, the harder it is for new team members to get accepted into the existing group structure. As a consequence of the newly gained familiarity, the work content itself also moves more into the background. The relationship level is in the foreground in this phase. "

The most important tasks for team development in this phase are to: Give space: It does not make sense to put too much pressure on the content in this phase. The group should be able to relieve the stress of the confrontation and strengthen the social fabric on its own. The recommendation is even to offer further confidence-building measures in this phase. Maintain a boundary: At this stage it is tempting for project managers to ingratiate themselves into the familiarity of the group. This temptation must be resisted: The boundary between the team and the other role players in the project has to be maintained. Stick to the goals: The work is no longer tedious as in the storming phase, but productivity is not very high either. The group has to be oriented towards goal setting and the performing phase.

Table 5.2 Factors that promote and inhibit cohesion Promote cohesion Favourable group size (5–8 persons) Common interactions Collective performance assessment Open and honest communication

Inhibit cohesion Group too small or too large Lone warrior work Individual performance assessment Intransparent communication culture

366

5

Teams

To support team development the models for self-recognition (Sect. 3.10.2) and organisational constellations apply (Sect. 5.4.6). The people now have the confidence to talk to each other about their own strengths and weaknesses.

5.2.4

Performing: Working in the System

A successful completion of each of the previous phases increases the ability and willingness of the team members to cooperate. Now the focus is on constructive cooperation, working in the system. The group members are motivated and show initiative. The performance is not only revealed in good, content-related work, but it above all becomes apparent in the group members’ own initiative for cooperation, organisation, and mutual coordination. Only a minimum of formal leadership is now needed. In agile project teams, the scrum master is at this stage required very little. In this phase: • Group rules and norms are openly communicated and supported by all. • Individual needs and group interest are in balance. • Essential work processes are carried out effectively, free from coalition-forming and competition. The group has now reached a high level of maturity. Relationship work is no longer in the foreground, energy is no longer absorbed by rivalries and conflicts. The common goal is in the foreground. "

The most important tasks for team development in this phase are: Advising: One needs to ensure that processes are being followed. Provide advice when needed. Controlling In traditional project management, it has to be checked whether the work packages and intermediate objectives have really been completed in the necessary quality (e.g. 90% syndrome Sect. 2.5. 6.5). In addition, it has to be ensured that the less popular work such as documentation or configuration management also gets tracked in accordance with the course of the project. In agile project management, the product owner checks the qualitative goals in the sprint review. For this purpose, the sprint burndown chart is a valuable source for keeping an eye on the performance of the team remaining effective. Recognising overestimation of one’s self: It can get to the point where a team completely overestimates itself. Those responsible for the project are to rein in statements such as “we are the best”, especially when that happens at the expense of other groups.

5.2 Dynamics in Teams

367

Figuratively speaking, scrum masters and project managers can each take on the role of referee in a football match during this phase. They observe the action from a certain distance and only intervene if rules are broken. Otherwise, they let the game continue and prepare for the next phase.

5.2.5

Adjourning: Farewell and Separation

Every project finally has to come to an end. This also means that the project team is disbanded. In traditional project management, this phase, the final project assessment, unfortunately often gets neglected because the next urgent projects and tasks are already waiting. Yet, it is precisely this last phase that holds great potential for personal and collective development: Here the group process as well as the personal role can be reflected upon. This is the basis of learning within the organisation: that experiences are to be reflected upon again and again. A distinction has to be made between symptom and cause. Finally, new patterns of action and measures derived from these past projects further the effectiveness of project work. The process of separation should also avoid that individuals leave the cooperation either burdened in some way or with feelings of ambivalence, both of which would place a weight on future projects. "

The most important tasks for team development in this phase are: Project closure or retrospective: These platforms need clear structures ensuring that the focus lies on content and on improvement of future project developments, and that no one gets personally attacked or put down. Competent moderation of this occasion is important. In agile project management, the scrum master is assigned this task. In the traditional approach, the responsibility basically lies with the project manager. However, neutral, external moderation is often recommended for the project review: this allows the project manager to fully assume the role of a member of the project organisation during the project review, which avoids him having to play a double role with the responsibility for the design of the process. Successes: Social recognition is an essential basic human need. Successes should be celebrated, the team ought to receive the appreciation it has earned. A team event always has a very good effect also on the future commitment of the employees. In addition to this, an article can be published about this in the internal news channel for the purpose of project marketing. Non-simultaneity: Especially in traditional project management, the last phase is characterised by people being repeatedly withdrawn from it. It is up to those responsible for the project to keep the threads together in this phase and also to ensure that everybody involved is able to be present at the essential events.

368

5

5.2.6

Teams

Dynamics and Interaction

The phases of team development are not always passed through in an orderly, chronological sequence. The intensity with which a specific phase manifests itself can also be quite varied. There is also no guarantee that a team that has arrived at the performing phase will remain in it until it is dissolved. Scrum masters as well as project managers should be sensitive to all kinds of disturbances that challenge the team structure anew every time something like this happens: This mainly concerns changes in the composition of the project organisation, though. When new people join the group or others leave it, completely new dynamics can develop. A team in the performing phase can thus fall back into the storming phase and may need to also briefly go through the norming phase again. The same can happen if the internal or external project owner makes significant changes to one of the parameters of the magic triangle, or if the project team cannot be protected well enough from access from the line organisation. This is often the case when individual team members are assigned to tasks of an operationally higher-priority, thereby reducing their efficiency for the project. "

The challenge of the team development process is that performing can only be achieved through storming and norming. The conflict in storming forms the foundation for the later performing. Teams that lack conflict management skills will get stuck in this conflict wave, making work tedious, exhausting and unsatisfying from beginning to end.

5.3

Roles in the Project Organisation

5.3.1

“Line-up” in Teams: Position and Role

Whoever wants to produce a feature film has to fill very different positions: It needs a writer for the script, a director, actors, extras, cameramen, studio staff, someone to arrange the financing, and many others. One of the basic requirements for the work to turn out successful is to define the necessary positions and to fill these positions with suitable people. An Organisation Empowers Positions Positions describe the formal or informal place in an organisation (Ruth Seliger).

On closer examination, organisations do not empower individuals (line managers), rather, power is assigned to the positions of the line organisation, which are hierarchically divided according to areas of responsibility. CEO, CFO, head of project management or team leader logistics might be position descriptions in this

5.3 Roles in the Project Organisation

369

context. Through these positions, an organisation clarifies its areas of responsibility, defines its “line-up”, so to speak. An organisation delegates status and decisionmaking power to these positions. These authorities are not bound to certain individuals and continue on even if there is a change of position. They can also be delegated to other people (Sect. 4.9). One Position Contains Several Roles Anyone working in the project management environment always has to play multiple roles within his position, except in pure project organisation. The position of head of project management includes very different tasks, which are also only temporary in relation to project management. We refer to these as roles. Example

For example, the head of project management may be responsible for managing the project portfolio of the entire organisation and for developing and enforcing project management guidelines and standards. He nominates the project managers and leads them in terms of discipline as well as professionally. He is also responsible for the budget of his team. In addition, he takes on various temporary roles in specific projects. The position of the customer project manager involves completely different roles: In addition to being a project manager, he is, for example, a customer advisor or provides third level support within the scope of the technical competences. ◄ Of course, this also applies to the roles in agile project management. The specific competencies and management tasks in the respective roles are described in detail in Sect. 2.3.8.3. In Fig. 5.2 an organisation with the positions and roles is depicted. Roles Reduce Complexity and Create Trust Through roles we can reduce complexity in a social system: the better we meet the “behavioural expectations” (Ruth Seliger) of our fellow human beings, the easier it is for them to classify us. This automatically creates more of a sense of security for everyone involved. This feeling of security is in turn a basic prerequisite in order for trust to develop between individuals and, as a consequence, in a team or in an organisation (Sect. 3.3.5). Clarifying one’s own roles is part of every employee’s personal responsibility. In many cases, these roles have to be negotiated because the expectations and demands of the organisation exceed the possibilities of the individual. The more clearly these roles are defined and the better they are coordinated according to the congruence principle TCR (Sect. 4.8), the more effective the work of the individuals and the organisation is as a whole.

370

5

Teams

Fig. 5.2 Position and roles in organisations

5.3.2

Role Carrier and Role Sender

The Role Senders Determine the Behaviour of the Role Carriers Our feature film with only an exciting script and clearly defined positions and roles will not be a box-office hit. Success depends, among other things, on whether the director finds actors who manage to play the roles so authentically that they are thereby able to captivate the audience. Verbal communication, knowing the text by heart, is by far not enough. The star differs from the normal actor in how credibly and effectively he can embody the role, especially through non-verbal communication. And this in turn depends on how well the actor can live up to the expectations of the audience. Be it the hero, the villain or the clown: The audience has expectations of how, for example, a clown should behave in specific situations. They send these expectations (role senders) to the role carrier. We call the behaviour of a role carrier in a specific situation a lived role. In this example, the audience with their expectations of the role of the clown are the role senders. The clown is the role carrier. The phenomenon of the lived role is that the role carrier has to adapt to the expectations of the role senders in order to be effective and credible. So, while position and role describe WHAT a job holder has to do, the lived role of the role carrier describes HOW this is done, i.e. performed.

5.3 Roles in the Project Organisation

371

The Authenticity Hype Much has been said and written about (leadership) success depending on being authentic. We would thus be legitimised or even called upon to simply behave in every situation in a way that would suit us personally. This clearly contradicts the above statements, which aim to create a sense reliability through the predictable behaviour of role carriers. Rolf Dobelli also advises us to not go along with the authenticity hype at work: “Authenticity has its rightful place within a life partnership or a very close friendship, but not vis-à-vis casual acquaintances and certainly not vis-à-vis the public”. Work is about respect, not love. We respect the people who keep their promises, whose behaviour towards us we can predict.

5.3.3

The Role as a Link Between Organisation and Person

The Role Lived Depends on the Context The clown behaves differently at a children’s birthday party than in a cinema film. In the role of a friend, we behave differently in an intimate setting when there are just two people present than when there are more than two people around. The role lived by the role carrier is strongly dependent on the context. Role carriers usually adapt to the context subconsciously. Without effectively noticing it, we behave differently depending on the situation and thereby try to meet the expectations of people involved, the role senders. Example

In one organisation, a project manager needs to be able to be firm with his project owner, be entrepreneurial and, in the event of delays, also be able to put pressure on the line managers who are supposed to release the resources. In another organisation, exactly this kind of behaviour would be an affront: Here, the “project manager” is expected to act as a kind of jack-of-all-trades, the one to ask whatever the issue, but he is in no way to influence the decisionmaking powers of superiors. The scrum master facilitating a sprint retrospective with a scrum team that has never worked in an agile way before has to intervene more strongly and also be more patient than when working with a scrum team that has already completed several projects in the same constellation. ◄ Of course, we are limited in the way we live a role. We cannot take on every role because we cannot simply disconnect our thinking, feeling, and acting from our person with our values, abilities, imprints, or character traits. The Lived Role Is Visible in the Contact Between Role Carrier and Role Sender Successful project work is based on clearly defined and agreed roles. The role carriers have to meet the expectations of the other role senders. These role senders

372

5

Teams

Fig. 5.3 Lived role as interface between person and organisation

are part of a surrounding organisational structure and culture, which in turn influences their expectations. All this creates the context in which the contact between role carrier and role sender takes place, as shown in the upper part of Fig. 5.3. It is in this interface that the lived role of the role carrier emerges. This interface has a high potential for conflict: the greater the discrepancies, the more likely it becomes for role conflicts to occur (Sect. 5.6.6.4). Role Adoption The better the roles are defined, the better the interaction within the team and the less likely it is that role conflicts will happen. This process of consciously shaping a lived role is called role adoption (Steiger & Lippmann, 2008, p. 49 ff). In every organisation, the role senders and also the role carriers have specific expectations concerning how a project manager or a scrum master should behave in specific situations. In contrast to the positions and roles, however, this role adoption is often not explicitly defined, but is shaped by the role understanding anchored consciously or subconsciously in the organisational culture or by role expectations. A successful and thus consciously designed role adoption is based on the following three measures:

5.3 Roles in the Project Organisation

373

Define role: Based on position and role, the first step is to define how a role should be performed and thus what the expectations of the role sender and the role carrier are. Example

The scrum master with a project team of agile novices must be able to clarify for himself, but also for his stakeholders such as the direct supervisor or the project owner, to what extent he can and should support the team in its process. ◄ Design the role: Now that the role has been filled, the contact between the scrum master as the role carrier and the team as the role sender gets shaped by how strongly the framework conditions are being influenced by the organisation or the managers of the line organisation. The organisation has a supportive effect, but it can also create obstacles, such as providing suboptimal tools or team members insufficiently released from other duties for the project. Example

The scrum master identifies more or less with the project and its goals, which also depends on how many other projects he is supervising simultaneously and to what degree he considers the framework conditions to be optimal. He contributes his experience and skills, but also his obstacles and limitations. ◄ Asserting a role: Sooner or later we all fall out of a role, no matter how well defined and designed. This may, for instance, be due to the team development process (Sect. 5.2), because of a role conflict or because of stress, by which those concerned as well as the organisational representatives involved are challenged in this situation to enforce the acting out of respective roles again and again. Example

The scrum master ought not to start to influence the self-organisation of the developers. The product owner has to be able to live with the decisions that the developers make during a sprint. The scrum team, on the other hand, needs to be able to live with the fact that the product owner does not accept the results of a sprint as long as the goals have not been 100% achieved. ◄ Defining, shaping and asserting roles is an on-going process that needs constant attention according to team dynamics. According to the principle of “disturbances have priority” (Sect. 5.6.11.2), it is important to recognise boundary violations between the roles and thus possible points of friction at an early stage and to deal with them on the basis of well-developed competences in personal communication. If, for example, the scrum master influences the self-organisation of the developers, it needs to be possible to communicate this to him in a constructive way. All those

374

5

Teams

involved have to therefore be able to give and receive feedback (Sect. 3.9.7) in order to further develop the assumed roles according to the three steps outlined above. The Belbin team roles approach (Sect. 5.4.3) or the RACI matrix (Sect. 2.3.8.9) is also very helpful for this process.

5.4

Influencing Factors for Successful Cooperation

Projects cannot be mastered by individual efforts. Every project owner has to be able to put together a team for his project that successfully masters the challenges together. Therefore, it is important for those responsible for the project not to leave team success to chance, but to know and use different influencing factors that have a positive impact on teamwork.

5.4.1

Psychological Safety

Organisations today rely on talent, but there are many reasons why talent alone is not enough. The only way human capacities can truly flourish is in an atmosphere free of fear (Amy. C. Edmondson)

One of the essential characteristics of successful teams is psychological safety. In psychologically safe teams: • Employees feel a sense of safety when taking interpersonal risks and showing vulnerability in front of each other. • Thoughts, ideas, mistakes, and criticism can be shared without fear of negative consequences. • Sincerity and authenticity are central elements. • Conflicts are dealt with constructively. • We are not concerned with protecting our “image” (impression management), but with delivering the best possible performance. In psychologically insecure teams: • We tend to remain silent rather than address difficult things. • We make personal development and important innovation steps impossible for ourselves and our colleagues through our silence. • We are, at least subconsciously, so busy with our “impression management” that we cannot contribute to the further development of the organisation. For Amy C. Edmondson, enabling psychological safety is the central element for successful companies. Edmondson (2018) impressively shows how building a culture of fear harms large companies (e.g. the diesel scandal at VW, the collapse of Wells Fargo, the downfall of Nokia).

5.4 Influencing Factors for Successful Cooperation

375

Psychology safety can be promoted in a targeted way in a project or in a company. For a fear-free and inspiring project organisation, the following factors play a central role in the management of the organisation: • Create conditions in which the work is given a frame of reference and an orientation towards meaningfulness is emphasised. • Invite employees to speak up and participate. To do this, leaders should demonstrate humility, practice proactive inquiry, and put in place facilitative structures and processes. • Establish continuous learning as an orientation. This is achieved through expressing appreciation and freeing failure from stigma. Giving the Work a Frame of Reference By enabling project managers to see the bigger picture again and again, project members can develop a more general understanding of what they are dealing with and what goals they are striving for together. Regularly referring to the project vision, the roadmap or even the overall benefit of the project is very helpful in this regard. Another important aspect in this area is dealing with failure (Sect. 3.8.5). A new frame of reference for failure and a basis for “safe” failure has to be created. It makes sense to discuss and formulate common expectations in the project team that have to do with failure, uncertainty, and interdependence. Failure is a feature of learning and not a mistake. A distinction can be made between the following types of failure (Table 5.3): Intelligent failure should be valued. Project employees ought to be encouraged to learn from it and make more such mistakes. Intelligent failure is a thoughtful foray into new territory and can move the project forward on key issues. On the other hand, avoidable failure and, if possible, complex failure should not be sought out. Table 5.3 Archetypes of failure (Edmondson, 2018) Avoidable failure Deviation from existing specifications. The knowledge is potentially in place Deficits in behaviour, skill, and attention Process deviation Educate, train Expand guides Sanction

Complex failure Unique and new combination of several influencing factors lead to an undesired result

Intelligent failure Novel approaches in unfamiliar territory that lead to undesirable results

Complexity, variability, new factors imposed on familiar situations System malfunction Analysis of the influencing factors Identify risk factors Further development of the system

Uncertainty, experimentation, risktaking Unsuccessful attempt Celebrate & reward failure Formulate new hypotheses Learning from failure

376

5

Teams

As project managers, it is important to explain why it is necessary for members of the team to speak out. In the project team we need to talk about and share uncertainty, interdependencies and what is at stake. All these points have implications for failure. The project manager can support this by: • • • •

Setting the direction through the vision (why?) Launching a discussion to clarify and, if necessary, adjust the direction. Creating the conditions for continuous learning. Inviting team members to participate, share important knowledge and valuable insights.

Active Participation and Invitation to Participate • No one is going to take an interpersonal risk if the project manager thinks he knows everything and cannot make any mistakes. For the project manager, it is essential that he succeeds in inviting participation in an inspiring and honest way. With situational humility, the project manager admits his own weaknesses and points out his limitations. This is achieved through an open and curious attitude. As a project manager, I can always learn something new and develop myself further. • By listening intensively and asking good questions, the project manager practices proactive inquiry. This is achieved by asking open and systemic questions and formulating I-messages instead of you-messages (Sect. 3.9.6). • Relationships can only develop through shared experiences. For this, structures and processes have to be introduced. Regular exchange within the team, bilateral meetings and structures for processing input help. This also includes common rules on how to discuss and deal with each other in the team. Respond Productively and Enable Learning To create an atmosphere of psychological safety, the project manager should be present and react quickly and productively. He does this by expressing appreciation and showing appreciation. Any personal opinion expressed should be appreciated and in difficult circumstances efforts (not results) should be shown recognition. Constructive feedback helps in the further development of people. Gratitude towards project employees also helps to increase appreciation. Continuous learning as an orientation. For this to work, failure needs to be freed from stigma. Through mistakes and through failure we can come to a deeper understanding of complexity and interdependencies. Failure is a natural by-product of experimentation. The project manager offers help, looks ahead together with the team and together the next steps are then defined. Effective performers produce intelligent failure, learn from it, and share its lessons with others. Avoidable failure as a result of deliberate process deviations have to be sanctioned as a violation. Clear rules delineate what the limits are.

5.4 Influencing Factors for Successful Cooperation

5.4.2

377

Positive Psychology and What Distinguishes High Performance Teams from Others

Google Project Aristotle In the Aristotle project, Google investigated what makes teams successful. The following success factors were identified: • Psychological safety: Team members feel safe with each other, dare to take risks, and show feeling vulnerable in front of each other. • Reliability: Tasks are completed on time and meet high quality standards. • Structure and clarity: Team members have clear roles, plans, and goals. • Meaning: The work is personally meaningful to the team members and they experience themselves as being competent in engaging in it. • Impact: Team members think their work is important and makes a difference. Positive Psychology As with Amy Edmondson, psychological safety is also an important factor in Google’s findings and the basis for successful teamwork. Martin Seligman, the founder of positive psychology, has also identified similar factors. In his PERMA model he describes the five pillars of positive psychology and personal well-being (2012): • • • • •

Positive Emotions: gratitude, being self-driven. Engagement (commitment): Flow, using one’s own strengths. Positive relationships: being active and constructive. Meaning: transcending the «I». Accomplishment (success and achievement of goals): experiencing one’s own competence.

If we configure these five pillars optimally in ourselves and in the team, then we become able to flourish and to create the preconditions for top performance. Positive Leadership The central elements of positive leadership according to Ruth Seliger (2014) are: • Confidence: Focus on and appreciation of strengths, resources, and potentials. • Influence: Involvement (involving project employees in decisions) and empowerment (handing over responsibilities to project employees). • Making Sense: Motifs from the past, the big picture in the current moment and a specific vision for the future. These principles serve to generate high positive organisational energy. High energy is central to the success of a project. Then the project management has the task of ensuring that:

378

5

Teams

• The project can build up enough energy and mobilise it again and again. • The project energy flows well and that there is always enough of it, in other words: that all parts and all environments of the project are well supplied with energy, that there are no congestions or energy holes. • The available energy is used effectively, too, and does not, for instance, go to waste. These three principles of “positive leadership” permeate the practice and process of leadership, laying the foundation for a positive and creative mood as well as for professional teamwork. High-Performance Teams The different approaches have a high degree of overlap and complement each other in an ideal way. If these success factors can be shaped positively, then nothing stands in the way of a maximum performance by the project team and the project manager.

5.4.3

Belbin Team Roles

In Sect. 5.3.2 it is explained how important clearly defined and agreed-upon roles are for project work. This definition process can be advantageously supported by the Belbin team roles. In Sect. 5.4.3 the concept is introduced in principle. The following section is about using it as a success factor for cooperation. Unsuccessful Teams: Imbalance in Team Roles In Belbin’s management games, it might have been expected that the teams composed of people with the highest intellect would also perform best. But this was not confirmed in the experiment. The teams with the highest individual intellect were not able to realise their potential and were plagued by role conflict. Successful Teams: Optimal Balance of Team Roles According to Belbin, the most successful teams are those that are optimally balanced in team roles: It would be a great loss for the team if a strong shaper no longer contributed his qualities for fear of hurting other people. It is much better if this strong shaper gets the support of a strong team worker who is committed to a good team atmosphere and to whom the well-being of the team is an important concern. This team worker has very high communicative competencies and is thus able to listen and mediate well. No project team can do without the talents of the resource investigator either. His contributions to networking and communication are all-important. But he also needs an implementer who can really concretise the ideas and possibilities, as well as a completer finisher, someone who can reliably and conscientiously take on tasks of high complexity. It is therefore the combination of the different behavioural clusters (team roles) that allows individuals to contribute with their strengths, while at the same time ensuring that their respective weaknesses are compensated for by the strengths of another team role.

5.4 Influencing Factors for Successful Cooperation

379

Belbin Team Report In order to descriptively capture these characteristics in the entire project team per team role, the individual team roles are summarised in a team report. In Fig. 5.4 the different employees are assigned to their most noticeable team roles. In relation to the competence groups, this means: • Accomplish (shaper, completer finisher, implementer): Well represented. • Think (specialist, plant, monitor evaluator): Well represented. • Communicate (team worker, co-ordinator, resource investigator): Not represented. The project manager who looks through this team report can in that moment immediately recognise the current weaknesses of the team in the areas of internal and external communication, stakeholder management, conflict management, or even coordination among team members who are most likely to be neglected. Blind Spot in the Team As with every human being, every team has a blind spot (Sect. 3.9.7.2). This is often due to the fact that like attracts like: When it comes to putting together a team, relationship and sympathy with others play an important role. If you are a strong shaper or a pronounced completer finisher, you usually have more sympathy for your

Empl. 4

New Empl.

Empl. 3

Empl. 2 Empl. 1

Empl. = Employee

Fig. 5.4 Belbin competence groups (Belbin Deutschland e.K.)

380

5

Teams

peers than for the contrary personality type. If the project manager is a shaper, it is highly likely that he will intuitively bring people into his team who match his values and competences. These will most likely belong to the “get things done” competence group. For a shaper, meetings or customer visits are often a waste of time. Action is of primary importance to him, while reflection for balanced approaches to solutions (thinking) or well-coordinated communication is relegated more to the background. This creates a team that is unbalanced in its team roles. What the team is usually not aware of becomes clear to someone from the outside relatively quickly, namely when he looks at how the cooperation is going, what work is being tackled with what priority, and what behaviour is being rewarded or sanctioned in the team. Thus, every team also has a blind spot that it needs to be alerted to. Instinctive Complementation of Team Roles If by chance a strong team worker were to join the team, what would happen to this person (New Empl. in Fig. 5.4)? This person would probably have a hard time because he does not match the self-image of those competence groups who are “getting things done” whilst “thinking”. There is a danger that this person will become the group’s scapegoat because his being-different threatens the current structure of the group. So, if this person wants to have a discussion about a conflict situation or would like to clarify the rules of cooperation, as is also done in the “norming” phase (Sect. 5.2.3), then there is a possibility that their needs will not be taken seriously citing reasons such as: “we don’t have time for that”, “we have to move forward, not chat”. Conscious Complementation of Team Roles The situation would be completely different if the project manager or the team were aware that of a strong imbalance in the team roles and were to actively look for a person to cover the unused competence group. It would be clear to the participants as well as to the new person from the beginning that he is an outsider and that, precisely because of this difference, he has a very important contribution to make for the team. It is clear to everyone that this individual will initially cause irritation or even meet with resistance. But they will deal with it in a completely different way than if the team role had been added to the team without being much noticed. Communication, Conflict Management, and Negotiations In these explanations it ought to become clear that the high ideal of balanced team roles in a project can only be achieved if their side effects are consciously integrated: If you fill all team roles, you will have to deal with people having very different character traits, values, and expectations. This will inevitably lead to differing convictions, which in turn means: intense debates, disputes, and also conflicts. A successful, efficient team cannot be a “feel-good oasis”. Rather, it is precisely the aforementioned debates, disputes, and conflicts that constantly create a new balance between the positive and negative characteristics of the different team roles. In order for this to be possible, the relationship level in the cooperation should

5.4 Influencing Factors for Successful Cooperation

381

be well developed. This means: there have to be high competences of the people involved in the area of personal communication (Sect. 3.9), role clarification (Sect. 5.3.2), negotiation (Sect. 4.10), and conflict management (Sect. 5.6).

5.4.4

Radical Collaboration

In project work, effective teamwork is increasingly becoming the all-important utility, and that is because technical problems and the corresponding exchange of information can be solved. Especially in time-critical projects, hierarchy and competition-free forms of cooperation are necessary. The basis for this are collaboration cultures with trust-based working relationships, as well as high prevalence of role flexibility among individuals working in the project, departments, or organisations. New team constellations thus become quickly to enable, according to the requirements. What counts above all is the efficiency, productivity, innovative strength, and the agility of the team. The radical collaboration method is the best way to achieve a balance in these ever-changing situations. The principle of this approach is illustrated in Fig. 5.5. The question is what the team members orient themselves towards: Do they have their own needs in mind or are they interested in optimising the needs of the whole group? Those who orient themselves only as befitting their own needs stay in the “red zone”. “This shows that, from a team perspective, this behaviour is not goal-oriented. The opposite would be to subordinate one’s own needs to those of colleagues. While this has a calming effect on the group, it may lead to the subordinate person not positively supporting the group with their ideas and skills. Therefore, it is not effective and is referred to as the “pink zone”.” (for many speakers of English this denotes a no parking zone). The optimum is achieved when the team members succeed in orienting themselves to their own needs and those of others, and in supporting common success by challenging and encouraging themselves and others (“Green zone”). However, this realisation often means redefining essential previous objectives of one’s own success, i.e. also reinterpreting strengths and attributes previously considered as strong and independent. It requires a different way of thinking and a corresponding attitude. Radical collaboration thus requires a different mindset. Table 5.4 contrasts the behaviour of the “red zone” and the “green zone”. The radical collaboration approach originated in California in the 1980s and was initiated by the judge Jim Tamm. Today, Bosch, Toyota, Nasa, and many other international companies are realigning parts of their organisations along these lines. Especially areas where innovation, technical developments and customer requirements are to be realised collectively and across departments. Team structures are primarily based on the tasks and competencies of the team members and not, as in the past, on organisational structures and hierarchies. The approach is based on five central core competencies (Tamm & Luyet, 2005):

382

5

Teams

Orientation to the needs of the other

Subordination Green Zone

Pink Zone

Red Zone

Orientation to my needs

Fig. 5.5 Typology of individual behaviour in teams (Derived from an idea from www.euforia.org, 2018) Table 5.4 Transformation of the mindset Red zone behaviour Away from . . . • Winning • Hedging • Not losing • Fighting for posture • Being right • Not making a fool of oneself • Avoiding risk • Extrinsic motivation • Seeing work as tedious, unpleasant

Green zone behaviour Towards . . . • Success • Growth • Connections • Being sincere and frank • Collaborating • Practicing mindfulness • Taking risks • Having intrinsic motivation • Seeing work is pleasant, enjoyable

1. Collaborative intention: Personal success is not the maxim. The focus is on shared benefits and cooperative success. 2. Sincerity: Building an honest and open relationship in which the individual feels safe enough to address difficult issues. 3. Self-responsibility: for one’s own actions. 4. Self-awareness: Knowing oneself and others well enough to classify difficult, interpersonal problems and to solve problems, also in new constellations.

5.4 Influencing Factors for Successful Cooperation

383

5. Problem solving and negotiation: Negotiating upcoming conflicts and working out individual interests. Being able to act strong and reinforced through having clarified relationships. Radical collaboration therefore describes only the basic team and leadership requirements that are necessary for the concept of collegial leadership and selforganisation in the agile approach to work. Of course, radical collaboration can also make a valuable contribution to traditional project management.

5.4.5

Multicultural Cooperation

Globalisation Demands Multicultural Project Teams Today multicultural project teams are the rule and no longer the exception. In this working situation, different cultural influences are likely to collide (Sect. 3.4), which places additional demands on the design of the relationship in a cooperation (Sect. 1.5). In every contact we experience similarities and differences, be it in terms of verbal or non-verbal communication, in our behaviour in conflict situations or under stress, or in problem-solving strategies. Due to our own cultural imprint, our value system and our view of human nature and of the world, we generate conscious and unconscious expectations having to do with our environment and our fellow human beings. Confronted with a difference in behaviour to what we would expect, we react with irritation, which is exactly what happens in multicultural cooperation. Here we are confronted again and again with behaviour patterns in other people that are unusual and unexpected for us. Of course, not only the project teams are multicultural, but also the markets and the customers. Very few companies can still thrive off a monocultural customer base. The aim has to be able to be successful in interregional or international markets and therefore also in different cultures. Project organisations that are not capable of constructive multicultural cooperation will not be able to participate in the increasingly networked markets in the medium and long term. Thus, multicultural cooperation ought not to be seen as an obstacle or a source of problems, but as an absolute prerequisite for future success. Monochronic and Polychronic Organisational Cultures Organisational cultures can be differentiated using various categories. One approach is to distinguish between planning and organisational styles. At the extreme ends, these may tend to be shaped according to monochronic or polychronic criteria. Table 5.5 contrasts the two approaches (Zaninelli, 2005). Of course, these are extremes of the monochronic and polychronic expressions. But the differences, depending on their characteristics, have a significant influence on cooperation. Central and Northern Europe and the Anglo-Saxon cultures tend to favour the monochronic planning and organisational style. The Romanic, Hispanic and, as a tendency, the Russian and Arabic cultural areas, on the other hand, are more influenced by the polychronic style of working.

384

5

Teams

Table 5.5 Monochronic and polychronic planning styles Monochron Prefers to do one thing at a time Is focused on accurate planning, avoids interruptions Believes in facts and figures Punctuality and deadlines are taken seriously Rules are observed Matter before relationship

Polychron Feels good to work on several projects at the same time Is good at improvising, lives with constant interruptions Juggles with facts and figures Punctuality and deadlines are handled flexibly Rules are circumvented Relationship before matter

Example

What do these differences mean for project work? The more polychronic the members of a project organisation are, the more important it is to invest in the development of the relationship level or to leave room for future development. Polychronic does not mean that the work content is not relevant. Rather, it means that a relationship and a level of trust need to first be developed before the matter can be addressed. Whereas the monochronic culture sees a benefit in rules and observes them, the polychronic approach tends to leave them aside. Punctuality at meetings and keeping appointments can cause controversy: Monochronically, these are taken seriously; polychronically, they are more likely to be observed as a point of reference. ◄ In Fig. 5.6 the differences between the two planning styles are shown graphically. The monochronic culture is characterised by a structured, sequential approach. In contrast to this, the polychronic organisational form is much more “agile” and always adapts its approach to the current situation. This representation can be easily related to the mechanistic and systemic world view (Sect. 1.6.2): Monochronic is more mechanistic and oriented towards “truth”, while polychronic is more systemic and oriented towards constructed “reality”. Chances and Dangers of Monochronic and Polychronic Organisational Cultures Most of us feel more comfortable with one or the other of these expressions. And this is probably also connected with a corresponding conviction as to which form is better. As explained above both different cultures are associated with certain large geographical areas and economic regions. All internationally oriented companies ought to at least be able to deal with their customers coming from various different cultures. Often, in order to be truly successful, they will have to even internalise the cultural characteristics of a target market, or at least in part. This means that it is not possible to remain in an “either-or” situation, but rather to develop a “one as well as the other” approach; both contain opportunities and dangers, as Table 5.6 shows (Zaninelli, 2005).

5.4 Influencing Factors for Successful Cooperation

Monochronic Goal

385

Polychronic Goal

3.

2.

1.

Start

Start

Truth

Reality

Fig. 5.6 Monochronic and polychronic culture

Table 5.6 Opportunities and threats of monochronic and polychronic organisational cultures Opportunities

Dangers

Monochronic Reliable in terms of facts Smooth processes Good at creating and implementing plans Little contact with a reality that may be changing Rigid and inflexible in the extreme Can lead to neglect of the relationship level

Polychronic Reliable in terms of relationships Flexible adjustment to changing conditions and disruptive factors Good at performing under unexpected circumstances Can be chaotic due to constant inclusion of changing circumstances Projects can get bogged down Time and deadlines difficult to calculate

Attitude and Mindset For groups or people dealing with extremes, these different expressions also contain significant potential for conflict. In order that cooperation might be successful, all the people involved have to develop a basically open attitude towards other cultures, allowing for appreciation to be shown even in the face of unusual behaviour. This is

386 Table 5.7 Dealing with polarities

5

Consistency Discipline Control Work in the system Knowledge creation Independent conclusions Acting quickly Mechanistic world view

, , , , , , , ,

Teams

Innovation Creativity Trust Work on the system Value creation Empirical evaluation Thorough analysis Systemic world view

made possible whenever a distinction is made in communication between effect and value. Those who see verbal or non-verbal signals as an assessment directed at them or of a situation having to do with them quickly feel attacked or hurt, which can then escalate into conflict. This is why multicultural project teams also need high competences in conflict management. Finally, the people involved need to also be able to develop their thinking, shifting it from an attitude of “either-or” to one of “as well as”. The complexity and dynamics in which project teams move no longer allow the work to be managed with rigid thought patterns, norms, and guidelines. Instead, project teams should learn to manoeuvre between polarities and opposites, as shown in Table 5.7 is illustrated. There are project situations in which creativity and trust have to be the absolute focus. Later, discipline and control can stay in the foreground in the same project. At one time the focus is on value creation, at another time on knowledge creation. Sometimes decisions are based on empirical evaluations and in another situation independent conclusions are to be drawn. The value square (Sect. 5.6.10.8) also provides good approaches on how to deal with polarities. Reflected Personal Perception In multicultural cooperation, differences in individual expectations always become apparent. This requires a high degree of self-reflection on the part of those involved. Those concerned with the project have to always be aware of the fact that personal perception is selective and based on an individual evaluation of circumstances. However, it is also important to be conscious of the external impact of personal actions (Sect. 3.10.2). Those who have been sensitised to their external impact are able to learn step by step to adapt their behaviour as flexibly as possible to the given situation. Cultural Knowledge The project manager needs a basic understanding of the culture he is or will be confronted with. It is all about being aware of the expected gestures as well as the meanings of customs and observances, of preventing taboos and also being informed about religious framework conditions. This requires curiosity and openness when confronting something unknown.

5.4 Influencing Factors for Successful Cooperation

387

Language and Communication Skills English has established itself as the working language used in most multicultural project teams. However, this is often the mother tongue for only a few of the participants, sometimes even for none of them. If one or more team members cannot express themselves in their mother tongue, what is needed above all is a high degree of reciprocal tolerance in verbal communication. Those who put every word onto a scale will have a difficult time. It is much more a matter of all people being aware of the error-prone nature of the communication process, from coding to decoding. The best tool when aiming to avoid irritations and misunderstandings is active listening in direct conversation and, of course, giving regular feedback. Leadership Competence In traditional project management, an awareness of which specific leadership styles are applicable in a particular culture is needed. In the agile approach, on the other hand, it is essential to be sensitised to how different people can be introduced to selforganisation. These competences help across many problem situations in a multicultural project team. Example

• • •

How can I convince? How do I plan meetings in terms of expectations, preparation, agenda, leadership, consensus building, punctuality, or language? Who is involved and what about aspects such as work ethics, qualifications, and networking in the other culture? ◄

Negotiation Especially in many different regions of Asia, very different laws apply in how one conducts negotiation talks. The methods of decision-making are sometimes fairly unfamiliar to Western Europeans. An overly direct approach can quickly lead to a loss of face. Those responsible for a project need to know exactly which negotiation methods can be used and when, which entry or conclusion is promising and who it is that ought to generally chair meetings. Read more at Sect. 4.10. Example

The Western style of communication is characterised more by directness, “getting to the point”, taking a clear stand, being predominantly verbal. The Asian communication style is more subtle, circular, illuminating the context, mainly non-verbal. Western cultures usually still have their prejudices here and interpret: We are direct, open, honest, the others talk around the bush. Through this positive interpretation, however, Asians are in line with the trend: their communication style is now recommended to modern management. This difference has to be made transparent in a project team. If this succeeds, a therein well-prepared team is able to work on more complex problems than a team that represents only one cultural group. ◄

388

5

Teams

In multicultural project teams, it is therefore more important to not only work together online. The full benefit of these resources can only be realised through occasional “face-to-face” sequences. Especially at the start of a project, a “physical” encounter is almost indispensable.

5.4.6

Organisational Constellations

With organisational constellations, hidden mechanisms of action, hidden relationships, systemic background dynamics, or unrecognised patterns can be made visible in a simple and efficient way. Valuable impulses and insights for organisational, team and personnel development in projects can be gained from organisational constellations. It is recommended that the project manager is supported by a coach for organisational constellations. What Is an Organisational Constellation? Organisational constellations offer a new and different approach, characterised by a mindset that focuses on solutions. In addition to this, systemic connections are taken into account and business and working relationships are included, too. This way of arriving at results also breaks new ground. With spatial and visual impressions as well as linguistic and physical forms of expression, a more complex picture emerges. Through organisational constellations, complex relationships are made visible, understandable, and explained. This helps to improve people’s relationships in organisations and makes it easier to change the attitudes of individuals. Organisational constellations are also a valuable support when it comes to improving cooperation between people from different cultures. For example, through this form of constellation, conflicts between organisational units or project teams in different countries can be re-enacted, and thus the behavioural dynamics at work can be understood at a deeper level of consciousness. The so-called gut feeling, the intuitive perception or the “inner knowledge”, can be supported by translating it into visible images on the outside. On this basis, managers and project managers can attain a higher level of certainty for their decisions and effectively check their underlying attitudes (Klein & Limberg-Strohmaier, 2012, p. 40). What Happens in an Organisational Constellation? “In system constellations, aspects of a complex situation are presented in space with the help of representatives, in a kind of role play. This leads to clarification in two ways: on the one hand, the situation is visualised, staged, and on the other hand, creative solution options can be successively worked out” (Rosselet & Senoner, 2010, p. 20). The representatives serve as a sounding board for tacit knowledge. Underlying knowledge, though it exists, is not readily accessible to conscious reflection. The selected representatives are, to their advantage, in no close relationship to the person constellating and the topic of the system constellation. This ensures that these persons approach the constellation in an unbiased way. A constellation is usually supported by a group of 5–15 people. If the hidden mechanisms of action in a team

5.4 Influencing Factors for Successful Cooperation

389

are to be visualised for the whole team, it is also possible to work directly with those affected within the team. Procedure of an Organisational Constellation Say, for instance, a product owner, scrum master, project manager, or other decisionmaker has a question, a goal or a topic that they would like to look at in depth and gain new insights into for possible areas of action. For example, it might be that a project manager wants to analyse the dynamics of his project team and find out the reasons for an underlying conflict. Then, in a first step, the constellation facilitator will discuss the goal of the constellation and the questions derived from it with the project manager. Together with the project manager, he will then determine the representatives for the constellation. The project manager thereupon intuitively chooses the representatives from a group of people and places them in the room according to his gut feeling. This visualises the relationship structures of the project team. The initial image usually reflects the current situation of the project team. First conclusions can already be drawn from this. The constellation facilitator will at that stage bring about targeted interventions, e.g. he might rearrange representatives or bring further elements (representatives) into the constellation. During each intervention, the constellation facilitator, representatives, and project manager observe how the intervention affects the constellated system and what changes become visible. From these findings, development potentials and solution paths can be identified. In this way, it becomes possible to visualise hidden or concealed issues that would otherwise remain hidden. An organisational constellation takes one to one and a half hours. The system constellation process is effective, fast, and unconventional. For a product owner, a scrum master, or a project manager, it is advisable to call in an external constellation facilitator for an organisational constellation who is not part of the system under consideration. Possible Applications of Organisational Constellations in the Project Environment There are many possible applications for organisational constellations in the project environment (based on Weber: Basics of Constellations of Organisations and Working Relationships, Fundamentals and Procedures in Weber and Rosselet (2016), Organisational Constellations—Fundamentals, Settings, Fields of Application): • Make structural “clamps” visible and analyse them. – Structural contradictions in the project or line organisation. – Unclear organisational structures, e.g. inappropriate allocation of competence and areas of responsibility. – Unclear role assignments and role descriptions. – Making hidden stakeholder interests and claims visible. – In case of poor communication and coordination. • Prepare and accompany measures (analysis and trial action).

390

•

• •

•

• • •

5

Teams

– Goal-setting processes, orientation of the project. – Anticipating the impact of possible actions in the development of organisations, teams, project groups, etc. – Preparation of negotiations. Prepare personnel decisions and personnel development. – Personnel selection. – Filling key positions in the project. – Within the framework of personnel development measures. – How does someone in the project organisation come into a position of power. Review leadership quality and behaviour. – Adequate staffing and adequate filling of management functions in the project. Generating meaningful hypotheses and promoting solutions for conflictual relationships. – Causes and ways of resolving conflicts. – Lack of respect and appreciation. – Coalition building and triangulation. – Context mixing between private and business sphere. – Assumed behaviour and denial. – Places not taken, project roles not taken up, internal resignation, tendency to withdraw. – Exclusion, bullying dynamics. Project culture and working atmosphere. – The energy level of the project. – (De)motivation, boycotts – Community spirit, cohesion. – Backgrounds and correlations for persistent staff turnover or high sickness rates. Gaining information about lack of backing and support. Align project organisations (employees) with tasks, goals, and customers. Support in decision-making.

These and other possible applications naturally also apply outside of project work in all questions of organisational and personnel development.

5.5

Change and Resistance

Almost every project inevitably leads to minor or major changes within the line organisation. Change project management includes all projects that aim at radical, comprehensive, and interdepartmental changes in the organisation. This could have to do with the introduction of new processes or products, mergers, implementation of new strategies, etc. Such changes always require adjustments for the people involved, adjustments in their activities, behaviours, and cultures (e.g. communication culture, error culture) and even in their attitudes.

5.5 Change and Resistance

5.5.1

391

Change and Transformation

A change can have different causes. Illustrated by a general business model in Fig. 5.7 for example, the impetus can come from changes in strategy, corrections and adjustments in structures and processes, or the need to develop the organisational culture. Wherever the initial impulse is set, there is always going to be an impact on the other two dimensions of the business model.

5.5.1.1 Change: Solving Problems We speak of “change” when the current situation needs to be altered: Processes and methods have to be improved or replaced to meet current or future requirements. Example

• The production costs are too high. New production processes are to be found in order to reduce costs by which means a higher contribution margin then becomes possible. • The effort estimates for the projects were repeatedly too low by 20%. The reference values of the analogue estimation method ought to be reviewed. In addition to this, for projects with a high degree of complexity, the planning poker (Sect. 2.4.6.2) is to be introduced. ◄

Strategy

Management

Structure

Fig. 5.7 Change in strategy, structure, and culture

Culture

392

5

Teams

5.5.1.2 Transformation: Finding Solutions We speak of “transformation” when new strategies are to be developed on the basis of a vision or future requirements. Example

• Our products should be able to be produced largely by means of robots. Which processes, structures, and procedures need to be used in order to be able to switch for the most part to automation? • An organisation wants to work more following the agile approach. A project for organisational development is started, based on “Radical Collaboration” (Sect. 5.4.4). This is done in order to lay the foundation for self-organisation in the agile teams. ◄

5.5.2

Mind Change

Changes to Strategy and Structure Influence Culture The business model in Fig. 5.7 suggests that any change in strategy or structure has an impact on the culture and therefore on the individuals in particular and the organisation as a whole. In many projects, benefits and profitability only become apparent the moment the people involved adjust their behaviour, be it for instance innovative technological solutions, to more effective processes or new products. Targeted project activities and appropriate project management are necessary so that those affected can change their behaviour. The need for this to happen becomes increasingly pressing as change times become shorter and shorter. The on-going, coordinated measures to bring this about are called change management. It is not only change projects that involve change. It is more encompassing and affects all projects on a larger or smaller scale. Two Levels of Change Figure 5.8 shows the two levels of change. At the level of the “hard factors”, new structures, processes, or systems are developed in change or transformation. The management and control of this physical process are referred to as management and controlling. Equally important are the psychological and spiritual changes. Here the focus is on the “soft factors”, which are used to develop the culture, skills, and behaviour of the individuals and the organisation. Leadership and communication skills are required for this part of project management.

5.5.3

The Human Being and Change

Do you change? How do you personally feel about aspects of change in your private life? Most of us are probably not happy with life around us permanently

5.5 Change and Resistance

hard factors

redeployed vision strategy organisation change

soft factors

393

structures systems processes

Physical change is controlled by: – Management – Controlling

Change / Transformation inherent logic success Mind Change psycho logic

culture skills behaviour

Psychic change is controlled by: – Leadership – Communication

Fig. 5.8 Two levels of change

changing. Why is that? First of all, we have acquired all of the knowledge, learnt all the procedures and skills we need to go through our lives. Acquiring something new is a demanding process that requires a lot of effort and energy. What we had to learn cognitively once with a lot of effort over time becomes the sum of our routines, our implicit and intuitive behaviour patterns over the years. Calling up these patterns costs us only little energy, as these are anchored in fixed neuronal networks in our brain (Sect. 3.3.1). Since humans have had to learn to survive in a world of scarcity for most of their evolution (for many, unfortunately, this is still the case today), our brain has also developed an efficient “stand-by” mode: thus, our brain always tries to keep its energy consumption as low as possible. The familiar and stable has other advantages for us: we feel safe. As project managers, we have acquired a lot of knowledge and experience over the years. We have built up a reputation in the organisation or even in a specific sector, thereby having created a valuable formal and informal network. Through all this, we can consciously or instinctively meet our individually important basic personal needs (Sect. 3.3.2). Changes in our processes, tasks, or responsibilities for us imply having to let go of security and even parts of our identity. Depending on the character traits of persons with their basic needs, and their specific competences or personal resilience (Sect. 3. 8.4), everybody applies a different, personal coping strategy (Sect. 3.5.6). For many,

394

5

Teams

change also means uncertainty, sometimes even fear. Those who cannot overcome this uncertainty or fear will cling to the status quo.

5.5.4

“Formula” of Change

Those who think that the change of people or organisations can be derived from a simple formula would make it seem trivial (Sect. 1.6.3). Organisations and people are much more complex. Nevertheless, a formula can be used as a supplement to the change formula (Sect. 5.5.10): In a change process the fear of learning and the fear of existence are opposites. Learning anxiety means that people or organisations lack confidence in their ability to build up the same competence anew. This “basement wandering” can result in becoming temporarily inefficient or even to losing part of one’s identity, status, or group membership. Existential anxiety includes the loss of livelihood: the loss of market position or even the organisation’s ability to survive, the disintegration of a team or, on a personal level, the loss of expertise, employment, or one’s health. Which fear is the stronger in us? Even if many don’t want to hear it: It is the fear of learning. Lifelong development and further learning of organisations and people is very demanding, exhausting and also associated with an array of uncertainties and risks. Existing habitual patterns, on the other hand, provide security. In most organisations it takes a lot of energy to go through a sustainable change process. Change has a high price and requires a significant commitment from all people involved, requiring risk-taking abilities. Example

Humans are very good at suppression. Many people try to live on for as long as possible along the paths of familiar ways, be it organisations or individuals. These familiar paths are only abandoned when things really don’t work out any more: People fear to lose their jobs if they don’t familiarise themselves with a new technology. Or they suffer so much stress that the psychosomatic symptoms can no longer be ignored. Or maybe even an organisation is afraid of suffering a drop in turnover due to the market entry of a competitor if it cannot achieve a surge in innovation. ◄ In these situations, existential anxiety increases, often accompanied by a higher stress level. The increased existential anxiety then causes the learning anxiety to fade into the background. Suppression is no longer an option. On a personal level, one’s own behaviour can be changed or the situation gets re-evaluated (Sect. 3.5.6). Organisations initiate change through a new strategy or structure.

5.5 Change and Resistance

5.5.5

395

Readiness for Change in Organisations

People who connote change positively and turn to it with curiosity and pleasure are the exception to the “formula” of change described above. Rogers distinguishes the following user groups in change processes (Rogers, 2003): Innovators Visionary thinkers, these people are enthusiastic, sometimes also uncritical and have a one-sided attitude towards innovations. Early transferees Having a positive attitude towards change, taking into account the pros and cons, which is why they enjoy high acceptance in the organisations. Early majority Initially indifferent to change, these people participate, but without great enthusiasm. They get excited about quick successes, which mainly benefit these people themselves (quick wins). Late majority and latecomers Getting them on board is difficult, as they tend to react with resignation or show active resistance. If the group is too large, this can mean the failure of the change process. Figure 5.9 shows, on the one hand, the percentage distribution of people among the groups and also indicates when these groups enter the change process. What does this mean for the design of change processes? According to Rogers, there can also be too much enthusiasm for change (innovators). Change needs to never be an end in itself. It should always be a means to an end and directed towards specific goals. It should also be carefully weighed in terms of risks and the human and financial resources it absorbs. It is a true statement that it is never all of the people who are involved that will enthusiastically embrace change. Change will always generate resistance. The majority wants to see results first before they show support for the change process. To win them over, the successes achieved by the change have to be quantified. The latecomers remain sceptical. Not too much attention should be paid to this group.

5.5.6

Psychology and Factual Logic in Projects

For a differentiation of change on the two levels of factual logic (change or transformation) and psychology (mind change), Table 5.8 compares a few focal points and areas of competence.

396

5

Number of transferees

early majority 34%

Teams

late majority 34%

innovators early transferees 2.5% 13.5%

latecomer 16%

Period

Fig. 5.9 Distribution of user groups (Rogers, 2003) Table 5.8 Psychology and factual logic in projects Factual logic Scope, objective, and requirements Strategies Milestones and sprint goals Costs and resources Project priority (project portfolio) Project planning and execution Project organisation Problem-solving methodology

5.5.7

Psychology Dealing with power and leadership Coping with conflict and resistance Development of the organisational culture Motivation and meaning Personal communication Team development Perception and awareness Developing skills and attitude

Willingness to Shape and Cooperate

Essential prerequisites for a supported and effective change are having the full identification and commitment of the management. Many change projects fail because commitment from the top is missing and the necessity of the changes is not repeatedly communicated and confirmed. When management is actively involved in the change process, it exemplifies the shared learning process. The changes sought by the organisation are thus (more likely) to be adopted.

397

strong

5.5 Change and Resistance

high change dynamics

Leadership‘s will to shape

failure preprogrammed

weak

Without credible, broad-based change work, only little moves

high conflict dynamics

limited change range

weak

strong Willingness of the employee to cooperate

Fig. 5.10 Will to shape and cooperate

Figure 5.10 shows that the dynamics of change are highest when a high degree of determination to shape things in the management organisation can be combined with a strong willingness to cooperate on the part of the employees. If the will to shape is strong, but the willingness to cooperate is weak, a high level of conflict dynamics can be expected in project implementation. Employees without the support of the company leadership can achieve little. If both sides show little commitment, failure is pre-programmed.

5.5.8

Change Process Model

5.5.8.1 Phases of Change Virginia Satir originally developed the “phases of change” model for family therapy. Her model therefore also describes the development of people, groups, and organisations in dealing with change through implementing five phases (Fig. 5.11). These are worked through with varying degrees of readiness and with different time restraints.

398

5

Existing balance “Social systems” tend to maintain the status quo for as long as possible

1

2 Introduce something new

Teams

New balance 5 Confusion uncertainty Chaos and chance Only the positive experience of this phase leads to a real change 4 3

Integrate the new As soon as the first success of the change begins to emerge, the new becomes more attractive

Fig. 5.11 States in change processes (Satir et al., 1991)

Phase 1: Status Quo or Existing Balance This phase (usually the starting position) of stable equilibrium and continuity conveys security. A well-rehearsed routine gives people the feeling of being efficient. In order not to endanger this equilibrium, a need for change is often avoided in real life for as long as possible by wilfully looking away. The longer this phase lasts, the more difficult it becomes for those affected to accept change. Phase 2: Departure, Introduce Something New In this phase, awareness grows that changes are necessary. Usually, it is only a small circle, e.g. the management, that plans and initiates something new based on a perceived need for change. A readiness for change has to be established in this “thawing phase”. Phase 3: Confusion, Uncertainty, Chaos, and Chance When something new gets introduced, confusion at first arises. Often the employees only see the change process in this phase. They have to jump onto a train that is already moving and then try to cope with the change and try out the new with more or less willingness. Most of the time, this is done using previously described methods and behaviours but that are hardly suitable to meet new demands. Situations arise in everyday life in which nothing works anymore because the tried and tested no longer applies and the new is still unfamiliar or unknown. As a result, chaos ensues, both for the people and for the whole organisation. Only positive living through this phase leads to real change. However, this phase is not allowed to last too long, because it is connected to feelings of fear, uncertainty, and costly resistance. It is often not clear whether the old still applies or whether the new already applies.

5.5 Change and Resistance

399

Phase 4: Integrate the New People’s ability to approach phases of confusion and crisis positively despite all the difficulties is a key factor in reaching phase 4. As soon as the first successes of the change become apparent, the new becomes more attractive. An integration phase occurs in which the new reality is practised and the new ways of behaving are tried out until a sense of security gradually emerges again. The new state is then “frozen” once again. Mistakes are also part of the learning process. These should be recorded and reflected upon, but need not immediately lead to corrections of the taken path. If the leaders do not succeed in dealing with mistakes in this tolerant way, they will slide back into phase 3 instead of making progress. Phase 5: Stability and New Balance The integration phase is followed by the new equilibrium phase. This phase of consolidation is important for deepening the experience and anchoring the newly acquired knowledge and skills. In the VUCA world (Sect. 1.1.2), these phases become increasingly shorter because they are caught up to or are overtaken by further changes. The five phases are not passed through linearly. With every major difficulty there are relapses into the chaos phase. Fear and resignation then once more gain the upper hand. Over time, however, both the number and the duration of these relapses decrease. The process of change begins to take hold.

5.5.8.2 Non-simultaneity of Change The phases of change occur in the organisation for certain groups in a kind of stagger (Fig. 5.12), which means that not all people or hierarchical levels involved are in the same phase at the same time. This can introduce additional dynamics to the project. This non-simultaneity arises from the knowledge advantage of those responsible. They have already been dealing with the change for a long time and have progressed accordingly. Now they impatiently expect quick results and increase the tension among the staff with their demands. This disparity places high demands on the project management in particular.

5.5.9

Dealing with Resistance

5.5.9.1 Positive and Negative Connotation There is no change without resistance. It is not the occurrence of resistance but its absence that ought to be a cause for concern. Resistance must neither have only negative connotations nor be reduced to deniers, conservatives, or die-hards resisting all change. Resistance is an important asset in people who want to protect something that is valuable to them. If a project changes something that you personally consider to be valuable and worth protecting, you would also offer resistance. If change processes meet with no resistance, there is obviously nothing (any longer) worth protecting. Or the affected stakeholders are already in despair or inner resignation. Figure 5.13 summarises positive and negative aspects of resistance and change.

400

5

Teams

Executives

Top management is involved in the change before everyone else. That‘s why they move through the change curve first

Management

After that management will be informed and they start to move through the change curve

Employees

When the employees are informed, executives and management are already in the integration phase and they can be impatient with the employees Time

Fig. 5.12 Non-simultaneity of change phases

Resistance contains a coded message • Insert a pause for thought • Reassess opinions

No change without resistance • No resistance is a reason for concern

Without change the human development comes to a stand still Permanent change without resistance leads to arbitrariness, chaos and dissolution Every human being has only a limited capacity for change

The art of dealing with resistance • Go with the resistance, not against it • Explain reasons, lead dialogues • Align a procedure plan together

Fig. 5.13 Aspects of resistance and change

The disregard of resistance leads to blockages • It is a fair offer if you try to find a solution by other approaches

5.5 Change and Resistance

401

Change means departure and the chance to develop further. However, it also means letting go, saying goodbye to what has become dear. Ignoring resistance leads to blockages. Social pressure leads to counter-pressure. Every carefully handled resistance (Sect. 3.5.6) can bring forth new resources and abilities. How does this work? • • • • •

Involve stakeholders and those affected, build in feedback loops. Transparency and openness can be seen as an essential basic attitude. Communicate disadvantages. Making advantages and long-term benefits understandable. Carefully prepare and empower staff for new situations.

5.5.9.2 Is Resistance a Synonym for Conflict? If a person resists, does that inevitably mean conflict? Resistance is often used as a synonym for conflict (Kreyenberg, 2005, p. 97). In our understanding, resistance, when it first occurs and is not yet fully expressed, is not yet a conflict. However, a conflict may well arise if one party insists on its position and if this leads to another party feeling diminished in its freedom to act because of this. 5.5.9.3 Forms of Resistance Resistance always contains a coded message. The causes often lie in the emotional sphere. The resistance of a person affected by change can show itself in very different forms. An existing order, structure, relationship gets questioned. This threatens the inner balance, which can then lead to taking on a defensive attitude. In Fig. 5.14 different forms of resistance are listed. No matter what form the resistance takes, ultimately the causes are hidden in individual or social needs. Resistance usually contains an energy potential that can be used constructively. How can the project management deal with resistance? The project employees or other affected persons are more willing to change if: • Change is perceived and lived as an opportunity and not as a threat. • A good relationship of trust and open communication are maintained. • They feel safe, i.e., if they do not have to expect sanctions and abuse of power should they uncover or address possible grievances. • The changes are meaningful to them and something positive results for them. • Their previous achievements are recognised. • They are involved in the change process at an early stage. • They are well informed and receive the necessary support. • Their resistance is addressed (if the “subliminal emotional energy” is taken seriously, it can be channelled in a meaningful way).

402

5

Teams

Pretended incompetence «I do not understand what we are up to!» Quality «I am the best! Why should I change?» Pretended engagement «I‘m working full time in the project anyway!» Proxy wars «Others have no idea about our problems!» Active resistance «With us the clocks run differently!»

Resignation «It does not make sense anyway!» Resistance against changes

Praying healthy «We have no problems!»

Lack of time «I have to generate sales, I have no time for that!» Passive resistance «I just do what I‘m told to do, they will see what comes of it!»

Fig. 5.14 Forms of resistance

They are less likely to be actively involved in shaping change if: • • • • • •

Fear and uncertainty overshadow the working atmosphere. Patterns of action have become automated. Ignorance or disregard prevails. Lack of awareness, understanding, and isolation are present. Things are not openly communicated within the team. Changes are seen as senseless and meaningless.

5.5.9.4 Dealing with Resistance In the dialogue aimed at clarifying resistance, it is important to ensure that positions are not negotiated. The true interests behind the resistance have to be uncovered. These underlying causes are usually not obvious and need to be worked out step by step. For this purpose, a three-stage procedure is recommended according to Fig. 5.15. Step 1 Assume factual doubts as the cause of resistance. Ask what your vis-à -vis has understood. Then provide information to explain the facts. If the concerns are indeed real, clarify them in terms of content, weigh the arguments. However, if the arguments are pre-textual because there are other underlying causes for the

5.5 Change and Resistance

403

Ursache Cause ofvon resistance Widerstand

Umgangwith Dealing mit Widerstand resistance

Step 1:1: Stufe Sachliche Factual doubts Bedenken

- informieren inform - argue argumentieren - clarify aufklären

Step 2:2: Stufe Ängsteand Fears undconcerns Befürchtungen

- understand verstehen statt instead erklären of explain - listen zuhören instead statt argumentieren of argue - ask nachfragen and mirror und spiegeln

Step 3:3: Stufe Eigeninteressen Self interests

- clear klare Ansprache address andund compromise Kompromiss - Konfrontation confrontation and und giving Einlenken in - Klärung clarification überabout die Hierarchie the hierarchy

Fig. 5.15 Causes and dealing with resistance

resistance, the discussion will be circular in a bogus way. Go to step 2 to leave the intellectual exchange of blows behind. Step 2 It is assumed that far more than half of all resistance is due to fears and concerns. If you have to assume fears, change the conversation strategy: listen instead of arguing back and forth, understand instead of trying to explain. It is at this stage that questioning techniques help. A space is created for your conversation partner in which he feels safe. On the basis of trust, you can address fears (Sect. 5.6.9.3). Ask questions. Make sure you have understood your dialogue partner correctly by reproducing his statements in your own words. Paraphrase and listen actively (Sect. 3.9.8.2). Only when your counterpart has the impression that you have really understood his fears or anxieties and that you take them seriously, is it possible to look for solutions together. Ask the person what might help them and what might still be needed, instead of offering quick solutions too soon. The surest way of not finding out about the other’s fears and anxieties in the process of giving yourself a chance to resolve the issues is to reassure, comfort, placate, or explain matter-of-factly that there is “no reason to worry at all”. If the resistance is really based on fears, the person will respond to the empathetic approach and look for viable ways together with you. If even several such conversations do not lead anywhere, the resistance is probably not based on fears. Go to the third stage.

404

5

Teams

Step 3 At the lowest level, it is self-interest that is causing resistance. Before the interview, form hypotheses about this person’s interests and drivers: what favours could he lose, what hard-won rights or advantages, what incentives, what status or prestige, what benefits and freedoms regarding working time? Enter into this conversation by clearly addressing these interests: What benefits or privileges could the person maybe lose or have to give up as a result of the changes? You cannot assume that every person will be open about this kind of thing and thereby willing to negotiate a solution. If there is no willingness to talk, sometimes a clear confrontation is necessary. In the bilateral conversation, the person has to be made aware of his egoistic behaviour and made aware also that by doing so, he is hindering important changes. Then often only a decision by someone higher up in the hierarchy leads to a solution of such a situation. Even here, a careful approach is called for. Give the person the chance to relent and return to cooperation before going this route. Especially if you want or need to work with this person after the change. Concluding Reflections on the Three Stages Proceeding in this order is recommended, as you will not do any “harm”. If you insinuate that someone who has factual concerns has fears, they may not feel properly taken care of or taken seriously. Insinuating that a person with fears has self-interests often leads to offending him making it impossible to talk about the fears.

5.5.9.5 Interventions in Case of Resistance Table 5.9 summarises possible interventions in case of resistance. Table 5.9 Interventions for resistance • Collect information • Find out the best alternatives for yourself • Identify the best alternatives for the counterparty • Develop options for mutual benefit • Formulate objective criteria • Evaluate possible negotiation solutions Inform about: Listening to and looking for: • Actual situation: value-free • Statements of the employees • Planned changes and goals: be timely • Exceptional behaviour and transparent in manner • Rumours etc. • Consequences for employees: • Different forms of resistance comprehensive and continuous Participate in: Address: • Discussion meetings • Needs of those affected • Wishes and opinions • Assessment of the actual situation • Good ideas • Decision-making processes • Cases of hardship • Hearings and presentations Training and education: Negotiating over: • Points of contention • As early as possible • Disagreements: in a cooperative and • As needed, both for content on the subject level consensual manner and on the relationship level

5.5 Change and Resistance

405

When team members signal resistance, they expect it to be noticed and dealt with. If the project management does not pay attention to the resistance, the team members feel inferior, hurt, or not taken seriously. Their discomfort and dissatisfaction increase. They withdraw and behave passively. The negative emotions are projected onto others. The resistance becomes personalised. This can grow into a social conflict of great magnitude such as “the project management is to blame that . . .!”.

5.5.10 Procedure in Change Projects The procedure in change projects depends very much on the context in which the change or transformation takes place. In order to understand this context, it is advisable to carry out a context analysis as a first step. In doing so, the elements according to Fig. 5.16 should be examined: Since in change projects, one’s own efforts have to be made by way of the acting system itself, they are particularly delicate due to the affectedness of the organisational members, on the one hand, and due to the following, often overestimated approach, on the other hand: namely that hardened structures have to be broken down, fears and resistance, too, but also unrealistic expectations, have to be reckoned with. For these projects, one therefore orients oneself towards transformation management, which uses social processes to achieve the objective goals.

Organisation - Culture - Purpose - Diversity - Resources

Ecosystem - Industry trends - Stakeholders Employees - Energy of change - Arrogance of success - Labour markets Leadership - Type - Team - Readiness - Load - Preferences

Initial situation

Fig. 5.16 Elements of a context analysis according to Claßen (2019)

Objective, topic of change

406

5

Teams

A prerequisite for a change project is a certain active awareness of change, otherwise the preserving forces are going to be too strong. An orientation is given by the formula: D×V ×M >R The individual parameters are defined as follows: D = Dissatisfaction with the actual state. V = Vision, attractiveness of the target state. M = Measures, concrete implementation steps, achievable, first successes. R = Resistance against change, energy to preserve what exists. According to Doppler and Lauterburg (2014), the following key factors should be considered in change projects: • • • • • •

Awaken energy and create trust. Thinking in processes instead of structures. Aligning the company with its environment. Networking through communication. Organise from the outside in. Ensure learning.

It is therefore important for change projects to have a vision, clear goals, transparent information and communication, and a process approach that allows for shared learning to take place and new experiences to be made. Depending on the context and the change awareness, a procedure in the change project needs to be chosen. Different approaches from traditional to agile are available for this. A well-known approach is the eight-step model by John P. Kotter (2012) according to Fig. 5.17. John P. Kotter’s model is based on Lewin’s basic cycle of change management: unfreeze (initiate change), move (shape the transition process), and refreeze (institutionalise the new state). Change projects often do not run in a linear fashion and can therefore only be planned in advance to a limited extent. In order to counter this, a more agile approach with an iterative and incremental approach is recommended, such as the lean change cycle according to Jason Little (2014) (Fig. 5.18). In this approach, the reaction of the stakeholders to the change is recorded via rapid feedback and integrated into the further course of the change project. The focus is on dealing with people’s reactions to the change and less on leading the change. As in the iterative procedure according to scrum, experiments are conducted and feedback is gathered. The starting point for the experiments are hypotheses that need to be tested. In this way, the organisation can be transformed in small steps. Technocratic models focus very much on direct control of change. Even when applied consistently and put into practice, however, this approach often falls short: the organisation proves resistant; entrenched organisational knowledge is difficult to unlearn; existing walls are defended.

5.5 Change and Resistance

407

Anchor change in corporate culture

8

7 Introduce new behavioural patterns

6

5

Unfreeze the hardened status quo

2 1

4

3

Anchor new approaches in the culture

Consolidate success and initiate changes

Achieve fast results

Empower employees on a broad basis

Communicate the vision of change

Develop vision and strategy

Build a leadership coalition

Create a sense of urgency

Fig. 5.17 Eight-stage model according to Kotter

2. Options

1. Prepare

1. Insights

2. Introduce

3. Experiments

3. Review

Fig. 5.18 Lean change cycle according to Jason Little (2014)

408

5

Teams

Holistic approaches are also based on systemic insights. They focus on the reflexive dynamics of the organisation, which, when used in a targeted way, can achieve far greater leverage for fundamental change than focusing exclusively on people. This puts the focus on the macro level, i.e. on working on the system instead of working in the system, as well as on indirect control, on shaping the project context and its relationship to the world of the line organisation. These prerequisites and conditions stimulate the organisation to change itself in a certain direction. In any case, companies and organisations contemplating change would do well to consciously decide on an approach and to use a neutral outsider (or an external system) as a consultant or change agent. It is very difficult for an organisation to “pull itself out of the swamp”. According to the model of complementary counselling, this can also be a counselling team consisting of a process counsellor and a specialist counsellor who understand each other and work together.

5.6

Conflict Management and Crises

The existence of differences is not the problem. Differences do not in themselves constitute a conflict. The only thing that matters is how people experience the differences and how they deal with them (Friedrich Glasl).

Conflicts are fundamentally part of human interaction. Human beings are expansive by nature. That means man wants to shape his environment and follow his convictions. With this attitude, he inevitably gets in the way of his fellow human beings. Thus, in project work with interdisciplinary teams, ambitious goals have to be achieved under time pressure and with limited resources. Especially in teams where people work with great dedication and passion, different convictions clash again and again. This results in divergence. Seen in this light, the origin of conflicts in projects is often something positive: in stakeholders for instance, or project managers who are committed to their convictions or to their project owner. These framework conditions virtually always cause differences to arise and create tension between the elements of the magic triangle: “Scope”, “time”, and “resources” (Sect. 2.3.4) making conflict management one of the core competences in project work. According to Glasl, it is not the difference but the way it is dealt with that is the problem. In order to be able to deal with conflicts constructively, these ought not to be evaluated as threatening or as a consequence of mistakes, but as a natural result of the framework conditions of the project work. The conflict is diagnosed from the perspective of this attitude. The conflict has to be recognised and understood in its complexity. In this way it can be dealt with constructively (Lippmann, 2008, p. 316). Conflict management aims at making people capable of once again acting in their objectives, which is only possible if the parties involved manage to leave their possible affect behind and move into cognition. Most of this chapter applies to both traditional and agile project management. Only the topic of conflict types is considered in a differentiated way.

5.6 Conflict Management and Crises

5.6.1

409

What Is Conflict?

In the German-speaking world, the definition by Friedrich Glasl (2008, p. 24) is widely cited: Social conflicts are tensions where two or more mutually dependent parties vigorously try to realise apparently or effectively incompatible plans of action, while conscious of their opposition.

In this definition, Glasl refers to social conflict. He thus implies that conflicts always occur between at least two people or groups. In it, at least one party experiences differences in its thinking, feeling, or desire vis-à-vis another party, so that the latter feels impaired. For comparison, here is the definition by Karl Berkel (2014, p. 11): A conflict exists when two elements are simultaneously opposed or incompatible.

The neutral term “elements” expresses that different contents can cause a conflict situation: • Thoughts: Why don’t I get any recognition from my project manager? • Desires: I would like to take on the role of a product owner and still have a friendly relationship with the scrum team. • Behaviour: I expect regular support from my project owner, but I am not very supportive of my team. • Assessments: The project committee finds that the project manager of an acceptance project needs a high level of social competence. The project owner finds that project experience and subject matter expertise are more important. • People: Two members of the project team feel a strong antipathy towards each other and refuse to work together. • Groups: The account managers are at odds with the project manager because they cannot meet the deadlines. The project manager accuses the account managers of including unrealistic deadlines in the contracts. The conflict definitions of Berkel and Glasl agree on the following points: Conflicts Are Disturbances Conflicts tear us out of our usual patterns of thinking, feeling, and acting. We at first perceive conflicts as a disruption. Something is not as we expected it to be. We feel impaired in our actions. Conflicts Are Emotional Feeling affected by a disturbance leads to an emotional reaction in us. We find the situation unpleasant, feel disappointed, or perhaps hurt. Tension mounts, accompanied by fear or anger.

410

5

Teams

Conflicts Require Intervention Differences of opinion are the most natural thing in the world. Disagreements can be argued and debated. Conflicts are situations in which there is an inherent compulsion to reach an agreement. Intervention has to then take place so that the harm done to at least one party can be resolved to such an extent that their ability to resume normal behaviour is once again given.

5.6.2

Origin and Symptom: The Systemic Phenomenon

Most conflicts initially manifest themselves as personal (psychological) or interpersonal conflicts. In the case of personal conflict, the responsibility lies within the person involved in it. His thoughts or desires are in conflict with each other. In interpersonal conflict, the disorder manifests itself in the behaviour or peculiarity of another person or group: one feels an aversion to another person, possibly rooted in different values, beliefs, or attitudes. Sometimes the reason is not even apparent. It is then simply the interpersonal chemistry that is not well attuned. Or the perceived fault is not in the other person himself, but in his behaviour. We feel affected by it. In project work, disruptions can occur at many points, if only because the influencing factors of scope, time, and costs in the project are in conflict with each other. There are also different convictions regarding that which constitutes optimal project methodology (traditional, hybrid, agile). Or perhaps personal project and line work cannot be reconciled. All these incompatible elements do not remain simply just theory, something written down on paper: they lead to each person aligning their feelings, thoughts, or actions according to their personal beliefs and judgements. This shifts the conflict away from its origin, the incompatibility between lines and project work, to the symptom: the relationship one has with oneself or with other people. "

A project manager has discussed the tasks in detail with the expert responsible for the work package and has reached an agreement on the effort to be made and the deadlines. Repeatedly, the expert is unable to meet his obligations. Again and again, his line manager assigns him to other projects having a higher priority. At the beginning it is an organisational conflict: the line manager does not stick to the agreement with the project manager and there is no resource planning between line and project. After the second or third postponement, the project manager is likely to take his being left out as an expert “personally”. He feels disrespected in his role, maybe even betrayed. This does something to his feelings towards his project collaborator. The project manager might incite a fierce emotion against his co-worker, thus damaging the relationship. In a different work situation, the two people might have been able to cooperate very well. But now the expert becomes the symptom bearer of an organisational conflict.

5.6 Conflict Management and Crises

411

This example is based on the levels of cooperation. Most causes of conflict in projects result from the content or occur at an organisational level. An essential purpose of the entire project management methodology related in Chap. 2 is that possible conflict potentials are actively recognised and clarified: Tasks and authorities are defined via the project organisation. A RACI matrix (Sect. 2.3.8.9) defines who has to do what in which work package. An information concept shows who is informed about what by whom and in what form, etc. All this serves to prevent possible disruptions in the project organisation. Phase 1 of the Systemic Phenomenon The less well the methodological approach is applied, the higher the potential for conflict. The unclarified tasks and authorities represent a failure at the organisational level. However, they will manifest themselves in disruptions at the relationship level because there are different expectations between the project participants or among their line managers. In a first phase, the conflict shifts from content and organisation to relationship. See Fig. 5.19. The conflict is thus “delegated” from the line manager to the relationship between the project manager and the expert. If those involved and responsible in projects are not aware that they can be symptom bearers of delegated conflicts, they will increasingly think of these disturbances as having to do something with themselves. This is called a “systemic phenomenon”. " System " The word “system” comes from the Greek. In German it means “to stand” and “together”. A basic systemic attitude tries to grasp a whole always in the interaction of the individual parts (Königswieser & Hillebrand, 2004, p. 22).

Those who are familiar with the systemic phenomenon do not hastily focus on the relationship level as the cause of conflict in cases of conflict, but understand the point

Content Relation Organisation

Fig. 5.19 First phase of the systemic phenomenon in conflict

412

5

Teams

of friction as a symptom. It uncovers the dynamics, fields of forces, contradictions, and deficits that causally drive the conflict. Phase 2 of the Systemic Phenomenon On the relationship level, two options are possible: The tension either manifests itself externally in the relationship with the employees, namely as a social conflict, or internally as a personal conflict. Example

If there is no established change request management process in an organisation (Sect. 2.5.8.2), the project manager will always be faced with the intrapsychic conflict of how to deal with a gradual change of scope (Scope creeping)). Without having done anything wrong, the project manager finds himself in an avoidance– avoidance conflict (Sect. 5.6.6.6). If he rejects the request, he snubs the stakeholder who is making the request. This is very difficult or even unrealistic with a project owner or customer. If the request is accepted without the consequences of the request being adequately reflected in the project planning and budget, the project manager and his team are confronted with additional costs, higher risks, and new dilemmas because other tasks have to be postponed in terms of priority. ◄ In this situation, two different options are available: 1. Conflict management takes place. The conscious confrontation between symptom and cause takes place. The relationship level is protected, the conflict is rejected. This means that the delegation is not taken over and is rejected back to its origin, where the causes are dealt with as best as possible. Example

The project manager does not adopt the attitude of “anticipatory obedience” and strives to change the situation. He specifies the change request according to the rules of change request management (Sect. 2.5.8.2). In doing so, he challenges his project owner to take a clear position and of course also runs the risk that his intervention will be sanctioned in some way. ◄ 2. Conflict management does not take place. In this case, the conflict cannot usually be addressed at the relationship level because the parties are already facing each other in a state of emotion. There is great danger that the conflict will be suppressed at the relationship level. However, since the feelings between the parties concerned remain, they will always engage in debates on issues of content or organisation.

5.6 Conflict Management and Crises

413

Example

The project manager does not dare to intervene with the project owner. He tries to realise the additional requirements within the existing time and resource budgets. In this way, he avoids the risk of getting into a dispute with the supervisor. However, the project risks as a whole increase because more complexity has to be managed. In addition, the risks increase that there will be tensions within the project team (social conflicts), as well as that personal self-management will suffer under this situation. ◄

5.6.3

Conflict Syndrome

Conflicts usually do not suddenly arise in their full intensity. The longer they manifest themselves on the relationship level and are not dealt with, the more they intensify. In Fig. 5.20 the following influencing factors are shown, which are also known as conflict syndrome.

Communication diminishes or is insincere

1

4

Perception is distorted or polarised

Common goal is lost out of sight

2 3

Attitude is dominated by mistrust

Fig. 5.20 Conflict syndrome (Berkel, 2014, p. 65)

414

5

Teams

1. Communication diminishes or is insincere. (a) Information is hardly ever exchanged or, if it is, exchanged incorrectly. (b) There is more talk about each other than about the subject matter. (c) Covert threats and open pressure take the place of arguments and persuasion. 2. Perception is distorted and polarised. (a) Different interests, opinions, and convictions are seen as being more distinct. (b) The differences among themselves are thought to be more significant than the (still) existing commonalities. (c) Conciliatory gestures are interpreted as being hypocritical, humorous remarks as cynical and factual intentions as hostile. 3. Attitude is dominated by mistrust. (a) The willingness to support others decreases. (b) The ability and willingness to understand and empathise with others diminish. (c) The tendency to hurt each other on a personal level increases. 4. The common goal is lost from sight. (a) Everyone tries to achieve their goals at the expense of others. (b) Reciprocal obstructions increase. (c) There is no coordination and division of labour, so there is no synergy.

5.6.4

Conflict Symptoms

According to the systemic phenomenon, contradictions and dysfunctionalities shift from the content and organisational project level to relationships. This causes a change in people’s feelings, thoughts, and actions as symptom bearers of the conflicts. For others, it is primarily the actions that are perceptible. The symptoms listed in Table 5.10 can indicate that there are conflicts. Table 5.10 Conflict symptoms Symptom Rejection, resistance Aggressiveness, hostility Stubbornness, intransigence Making escapes Over-conformity Disinterest Formality

Examples Constant contradicting, “yes, but” behaviour, bad-tempered reactions Hurtful speeches, giving “evil” looks, derogatory remarks, deliberate mistakes, “stonewalling”, sabotage Opinionated behaviour, “sticking” to rules, “it doesn’t work like that for us, . . .” Avoiding contact, staying out of the way, taciturnity, inner withdrawal, averting of other topics Not contributing one’s own ideas, avoiding criticism, going along with other opinions Formal politeness, withdrawing, passive working attitude, ignorance Doing things by the book, following instructions painstakingly, committing everything to paper and expecting others to do the same

5.6 Conflict Management and Crises

5.6.5

415

Potential of Conflicts

Often conflicts only have a negative connotation and are perceived as a disruption that prevents or delays the achievement of project objectives. If this is the case, they become a threat or violation and can cause anxiety. It is then that conflicts become more intense. Their potential is not used and the people involved cannot (further) develop. The primary benefit of conflicts is that they indicate that two elements are opposed or incompatible and thus need the attention of all involved. Anything else would be detrimental: if there is a “peaceful” atmosphere in a project team or in its line organisation, where people are nice to one another, different points of view will not be addressed. In the high complexity and under the demanding framework conditions that characterise project work today, it is impossible for a “master mind” to oversee everything and have a kind of “magic code” to solve all problems. Project work depends on differences and conflicts being dealt with constructively, dealt with furthering the project objectives in order to grow together through tackling the challenge. Of course, everyone has at some time in his life had negative experiences with conflicts. Of course, negative consequences can always be attributed to conflicts. But they also contain a lot of positive potential, as can be seen in Table 5.11.

5.6.6

Types of Conflict in Project Management

There is always the danger in conflicts that they get taken personally to soon, which means that the parties to the conflict are also perceived as being the cause of the conflict. This does not do justice to the complexity of conflicts. Most of the time, the conflict parties are symptom carriers and the causes are kept to the background. Types of conflict that often occur in project management are described below. Table 5.11 Positive and negative characteristics of conflicts (Derived from Lippmann, 2008, p. 318) Positive Allows to develop one’s own personality Helps to protect one’s own boundaries Refers to problems Prevents stagnation, is the root cause for change Stimulates ideas Stimulates interest and curiosity Helps find solutions Enables a comparison of self-image and external image Leads to self-knowledge

Negative Violates basic personal needs Leads to isolation Promotes resistance Takes focus away from the main task, blocks energy Ties up valuable resources Arouses fear, anger, frustration, pain, stress, and dissatisfaction Confuses employees Favours blame Leaves behind winners and losers

416

5

Teams

5.6.6.1 Goal Conflict and Conflict of Interest A goal conflict occurs when two or more parties pursue different goals and interests (Kreyenberg, 2005, p. 27). Possible goal conflicts in project work are manifold: • Goal conflicts occur in projects when the objectives with the corresponding weightings have not been comprehensively worked out, negotiated, and approved of by the project owner. • In the magic triangle, the interdependent influencing factors “scope”, “costs”, and “time” are mutually dependent, which can also generate conflicts. Every customer or project owner expects as much quality or functionality as possible as a project result. However, this needs to be achieved within a limited time frame and at small cost. • Different interests and expectations of stakeholders. Agile project management is less prone to conflicting goals, because these projects are defined much more by a shared vision than by having specific goals. The prerequisite, however, is that the product owner is granted all decision-making authorities. If this is not the case, there will be goal conflicts and interests between the product owner and the decision-making bodies of the line organisation.

5.6.6.2 Distribution Conflicts and Resource Conflicts Every project requires personal, financial, or technical resources. The parties agree on the importance of a project. However, because the personal, financial, and technical resources are limited, a conflict may arise regarding the allocation of resources (Kreyenberg, 2005, p. 29), a distribution conflict. Whether agile or traditional project organisation, in both approaches there are distribution conflicts when: • The estimates for the effort necessary are not realistic or too small a budget has been released. • The effort estimates are not updated over the course of the project. • The projects are integrated into the line organisation through coordination and the line managers repeatedly make changes to the priorities. • The projects are not consolidated in a multi-project plan. • There is no project portfolio at the strategic level through which the management can transparently set and control priorities. Often, only strategically important projects are well protected from these conflicts. For all other projects, the struggle for resources is a recurring challenge for project managers and scrum masters.

5.6.6.3 Structural and Organisational Conflict Another major source of conflict is the integration of the project organisation into the line organisation. Projects are always temporary forms of organisation which are incorporated in a specific way into the permanent line organisation. It is especially

5.6 Conflict Management and Crises

417

the integration forms of project coordination and matrix organisation that are prone to conflict. In project coordination, the project manager is a mediator and decisionmaker and is heavily dependent on the decisions of line managers. In the matrix organisation, the project manager has technical authority over his employees, but the consequence is that all employees have two superiors who often do not coordinate their priorities well. If it is also a client project and a client representative is integrated into the project organisation or even acts as its formal project owner, a structural conflict is almost guaranteed. Structural and organisational conflicts occur when: • It is not explicitly clarified and discussed how a project is to be integrated into the line organisation and if, based on this, the decision-making authorities and the management style (e.g. lateral management) are not coordinated. • Project roles and committees are defined, but they do not so what they are supposed to do (e.g. if the project owner is not visible in the project). • In client projects, the responsibilities and information flows between the internal and the client organisation are not coordinated. Agile project teams are well protected against interventions from the line organisation with the concept of self-organisation. Of course, conflicts can always arise within the team because each team member has to take on tasks related to productive work (work in the system) as well as work on the system, depending on the situation. If no personal willingness or flexibility, both serving as the basis of self-organisation, is present, or if solutions are given to the scrum team by the product owner or the line organisation, structural or organisational conflicts are pre-programmed.

5.6.6.4 Evaluation Conflict and Procedure Conflict Evaluation conflicts often go back to the different previous experiences, levels of knowledge and also levels of information of the parties involved. In this case, the parties agree on what goals are being pursued, but there are different convictions about the ways and methods required in order to achieve these goals. The effectiveness and impact of the approaches are assessed differently (Kreyenberg, 2005, p. 27 f). Agile or traditional or hybrid, and in what form? What does the milestone plan look like? What can be binding milestones during project implementation? The potential for evaluation conflicts is also high in traditional projects. Project work is not repetitive work as line work often is. Every project is unique in some sense. As a result, there will always be different opinions and convictions concerning the methods and ways of achieving these goals. Evaluation conflicts occur when: • • • •

The project order has been neither clearly formulated nor negotiated. The objectives of the project are not SMART or not well defined. No transparent criteria for decision-making have been established. Decision-making authorities and models are not regulated between the project committee and the project owner.

418

5

Teams

In the agile approach, the product owner has the sole decision-making authority to accept sprint results. What he rejects has to be worked on again. The teams themselves are challenged in this type of conflict when: • Different convictions exist about the requirements that are implemented within a sprint. • There is a different perception of who contributes how much to the team’s performance. • the work in the system has a higher value than the work on the system, • the scrum master does not intervene quickly enough in the event of discrepancies.

5.6.6.5 Role Conflict The different roles in the agile and traditional project organisation are explained in Sect. 2.3.8, the distinction between position and role in Sect. 5.3.1. Project work is highly exposed to role conflict because most project participants, except in the pure project organisation, fulfil several roles at the same time. The less clearly these roles are defined and the less clearly the roles are assumed, the greater the potential for conflict. The traditional approach often suffers from role conflicts. In contrast to agile project management, the responsibilities between team, sub-project manager, project manager, project owner, and project committee are often less clearly defined. The human factor is similar in both approaches, which means that role conflicts are always possible. Role conflicts occur in traditional project management when: • The responsibilities of the roles and committees are not clearly defined. • The specific responsibilities and decision-making authorities are not made transparent via a RACI matrix or a function diagram. • The leadership style of the project manager is not aligned with the integration of the project into the line organisation (e.g. lateral leadership). • The congruence principle TCR is not reasonably balanced at all project levels. • The team development process (Sect. 5.2) is not led from the storming phase into a constructive norming phase. In the agile approach, role conflicts are likely when: • The product owner is not given decision-making powers regarding prioritisation or acceptance of the sprint results. • The scrum master actively participates in the scrum team. • The developers are not granted decision-making authority when it comes to requirements or self-organisation. • The developers are not sufficiently on par in their abilities and hence a few top performers have to manage the overall performance of the team.

5.6 Conflict Management and Crises

419

Approach-Approach-Conflict The person is caught between two goals that are considered to be equally valuable, but cannot be achieved simultaneously

Avoidance-Avoidance-Conflict The person has to decide between two conditions, both of which are considered to be evils

Approach-Avoidance-Conflict The person is faced with the decision that brings her both valuable and evil

Fig. 5.21 Mental conflicts (After Berkel, 2014, p. 15 f)

5.6.6.6 Personal Conflict When personal conflicts (also called psychological conflicts) take place, people feel a variety of different decision-making or behavioural tendencies within themselves (Kreyenberg, 2005, p. 30). The more contradictory or unclear the requirements for the project are, the stronger the personal conflicts of those involved in the project. These inner decision-making conflicts can be categorised according to the options that are realistically available to a person. Figure 5.21 summarises the three conflicts. Approach–Approach Conflict Someone has two options open to him, both of which are attractive. This sets up the dilemma of finding both similarly interesting. However, as it is impossible to realise both goals at the same time, a decision has to be made for one of the two options and against the other and therein lies the conflict. "

• The scrum master notices tensions in the scrum team. He has to decide whether he should intervene directly or whether he should risk that the scrum team manages the problems itself thereby continuing to grow together.

420

5

Teams

• The project manager has to decide whether to take on a team leadership role in the line organisation or whether to continue on to lead projects.

Avoidance–Avoidance Conflict In the case of the avoidance–avoidance conflict, a choice has to be made between two options, both of which will have negative consequences. The decision then has to be made in favour of the lesser evil. "

A well-tried project manager is a month behind schedule with his client project. The project owner now has the choice of either coming down hard on him (which he is reluctant to do), allocating additional resources to this project (which he in turn has to compensate for elsewhere) or informing the client that there will be a delay in project completion. Whatever the project owner does leads to trouble.

Approach–Avoidance Conflict Approach–avoidance conflicts are characterised by ambivalence: Each choice has both positive and negative consequences. "

Someone is nominated for the role of product owner in a strategic development project. This would put him in a higher income level and he would also finally have more management and decision-making powers. However, he would be obliged to pass the product owner certification within just 1 year. He doubts whether the demanding task of being the product owner, combined with having to study for the certification, is compatible with his role as a young family father.

5.6.6.7 Relationship Conflict (Social Conflict) Relationship conflicts are present when there are subliminal or open disturbances in the relationship between people. Because two or more people are involved in relationship conflicts, they have a completely different dynamic than personal conflicts (Berkel, 2014, p. 18 ff). Two-Person Conflicts or Couple Conflicts We experience couple conflicts not only in our private relationships. Very often we also experience conflict-laden situations between two people in the work sphere: Supervisors, co-workers, negotiating partners, etc. Possible causes for two-person conflicts are: • Closeness vs. distance: The need for closeness and distance always changes in people. Too much distance or too much closeness increases tension in the other person. The other person feels either abandoned or constricted.

5.6 Conflict Management and Crises

421

Example: If a work colleague is appointed project manager, the proximity-distance relationship changes. The person promoted will tend to keep his distance in order to fulfil his new leadership role. The former colleague, however, still expects the same closeness as before the promotion. • Preserve vs. change: Every person has his or her own developmental dynamics: one person is very open to change, curious and constantly on the lookout for new possibilities. The other seeks more stability in his life, wants to preserve what he has achieved and finds stability and satisfaction in recurring rituals and processes. Example: If a colleague comes back to the company full of enthusiasm from a training course, he wants to apply what he has learned immediately and change existing procedures. This is sure to lead to conflicts with the people who want things to stay as they are. • Communication: Interpersonal verbal as well as non-verbal communication has a lot of conflict potential (Sect. 3.9). Triple Conflicts or Triangular Conflicts With a third party, new phenomena occur in conflicts that are not possible in a two-person relationship: • Coalition: Two people ally against a third. • Rivalry: A supervisor plays two of his employees off against each other. They now compete to win the boss’s favour. • Relationship: In a couple, the personalities determine the relationship. The personality is then the main factor influencing the conflict. In a three-way conflict it is the other way round: the personalities of the people involved are not the main factor, but the relationship that the conflict parties have with each other. For example, the supervisor has a separate relationship with each of his two employees. Group Conflicts In the group, further potential for conflict may come to light, this can involve: • Territory: Each group considers a certain territory as its home ground and defends it against intruders. The individual in the group is not only sensitive when spatial boundaries are disregarded, but is also irritable when dealing with perceived transgressions of responsibilities and authorities. • Ranking order: Every group consciously or subconsciously establishes a ranking order. Well-known is the ranking according to: – – – –

Leader (Alpha) Expert (Beta) Group Member (Gamma) Outsider (Omega)

422

5

Teams

In case a group does not establish the hierarchy, it remains unable to work. New organisational units or even projects inevitably cause ranking struggles. According to Karl Berkel, a group is not successful because of the formal organisational chart, but because the internal hierarchy best meets the functional requirements. If the organisation is not seen as purposeful or is not accepted, this leads to a state of permanent friction. Recurring conflicts are often an indication of an organisational hierarchy that is not accepted by its members. • Leadership: Every group, be it a project team or a line organisation, has to fulfil two basic requirements: It needs to be able to achieve its goals and guarantee at least a minimal degree of cohesion. Except in a pure project organisation, every person in project work has two or more superiors: the line manager and the project manager. The methods employed by the leadership as well as the possible discrepancies and clashes among these leaders contain further potential for conflict.

5.6.6.8 Conflict of Values Values form the core of the identity of social systems, be they the values of individuals, groups, or entire organisations. Values symbolise what we consider important and right and what we feel bound to. Values do not come into conflict with each other; it is always the people who identify with specific values. Those who fear that their own values are being questioned feel that their personal identity is under attack. This is why people often react so violently to conflicts at this level (Berkel, 2014, p. 93). These can be personal values as well as values in an organisational culture. Values are dynamically related to each other. In paid work, the tension is mainly between the values of performance (organisation) and satisfaction (individual). The more the company management focuses on performance, the more do values of individual satisfaction, as for instance well-being or health, recede into the background (Berkel, 2014, p. 23). Interdisciplinary and often also intercultural project work is exposed to such value conflicts. These occur in both the agile and the traditional approach. At the individual level, differences can occur in the expectations of how priorities are set, of how the culture of communication is shaped, or even how decisions are made. At the organisational level, differences mostly occur between subsystems such as sales, production, and development. These pursue different and also contradictory values in their tasks: Sales focuses on customer proximity, flexibility, and competitive prices, production wants efficiency in the processes and low inventory levels, and in development the focus is on innovation and high quality.

5.6 Conflict Management and Crises

5.6.7

423

Conflict Diagnosis

Conflicts are like a visit to the doctor: If the diagnosis is wrong, the treatment will not be effective either. Conflict diagnosis is meant to avoid an unreflective personification of conflicts or even a rash apportioning of blame. Only when we have understood the causes behind the conflict symptoms we can deal with conflicts in a goal-oriented way.

5.6.7.1 Forming Hypotheses Instead of Wanting to Know Each human being is a non-trivial system (Sect. 1.6.3). Therefore, we can never know what a person feels, how he thinks, or how he acts. The only thing we can do in relation to other people or groups is to form assumptions and by these come to form hypotheses. However, whether a hypothesis is right or wrong is always determined by the party for which it was made. The hypothesis only becomes a fact when it has been confirmed by all the parties involved. 5.6.7.2 Forms of Expressions of Conflicts The object of conflict is expressed in the types of conflict described above. Stepping back from this, the way in which conflict is expressed can differ a lot (Lippmann, 2008, p. 327 et seq.). Latent and Open Conflict With latent conflicts, there are differences between parties that have not yet led to hostile activity. This would be the case in an open conflict. It can be valuable for a project manager or scrum master to recognise latent conflicts in order to be able to deal with them at an early stage and thus prevent them from escalating. "

For example, the project manager may feel substantial differences to exist with one of his sub-project managers. However, because the project manager knows that the sub-project manager has a close relationship with the project owner, he will not let the conflict escalate. Should the project owner hand over the project to a colleague, the latent conflict would erupt into open conflict.

Hot and Cold Conflict In hot conflicts interaction is strikingly active, the parties tend to overreact. Attack and defence are recognisable to all and are conducted impulsively and emotionally. The forcefulness of the parties is fed by their exaggerated positive self-images. In cold conflicts (Fig. 5.22), interaction is inactive. Disappointment, frustration, and feelings of hatred are suppressed and continue to have a destructive effect for those caught up in these emotions. A confrontation does not take place except indirectly, as the parties avoid each other and deflect direct contact. Interactions are also possible in a scenario containing both a hot and a cold conflict. A cold conflict, as an example, can suddenly escalate into a hot conflict months or years

424

5

formally

• • • • • • •

static inward-oriented according to rules reactive indirect communication avoid risk backward-looking

Teams

informal

versus

cold

Lost faith in constructive goals Frustration, sarcasm Not taking responsibility for actions Wihdrawal, avoidance

• • • • • • •

dynamic outward-oriented spontaneous provocative direct communication risk taking forward-looking

hot

Heating up for own goals Over- motivation Beyond all doubt Rejecting criticism Attack, confrontation

Fig. 5.22 Hot and cold conflicts (Based on Schwarz, 2014)

later. But the opposite is also possible: If a hot conflict is not managed, the conflict parties can withdraw into a cold conflict (Glasl, 2004). "

In meetings it is easy to observe whether there is a hot or cold conflict culture. Is there open debate and argumentation? Do people defend their convictions even if these are not shared by the majority? This could initiate a hot conflict. However, if the participants in the meeting avoid each other and try to badmouth and defame the other party “behind the scenes”, this would be a cold conflict.

Displaced Conflict (Substitute Satisfaction) A further differentiation in the form of expression is to examine whether the actual issue in dispute is being fought out between the parties at all. It is also possible that the issue seemingly at the centre of the discussion is only meant to distract from an underlying, real issue. When the brain finds that it does not get what it needs, it tries to find a substitute (Ballreich & Hüther, 2009).

5.6 Conflict Management and Crises

"

425

A project manager repeatedly demands from his employees to do things as quickly as possible, as if these tasks had a profound urgency compared to other unresolved issues. There is a high probability that the project manager is not at all concerned with the effective activities: he wants to experience his status and influence again and again.

On the surface, this is a good strategy because it at least gives the brain a rest. However, the actual longing or basic need behind it is not satisfied. Conflicts may also arise over a topic or concern that is considered very important from a subjective perspective. A displaced or hidden conflict can be recognised by the fact that: • • • • •

The dispute has no compelling reason and appears to be “wanted”. The subject matter of the dispute is disproportionate to the strength of the conflict. No real interest is discernible. Obvious solutions are avoided. The conflict is fought out tenaciously and pettily.

Displaced conflicts can actually only be resolved sustainably if the underlying real conflict is addressed.

5.6.7.3 Conflict Styles Figure 5.23 represents the different styles that people use in conflicts. These are distinguished in relation to the self-assertion or the consideration of the respective conflict parties (Berkel, 2014, p. 60 ff). Evolution has given humans three conflict styles, which they share with all animal species: Absolute Self-assertion: Attack I want to get my way and the other party should lose (win-lose). Open confrontation (hot conflict) or indirect resistance (cold conflict). Absolute Consideration: Escape The other party gets its way, I submit and obey (lose-win). Give right of way to a strong desire for harmony and cohesion. Neither-nor: Playing Dead Both parties try to avoid the confrontation. Both lose (lose-lose). The conflict is denied or played down as irrelevant. It is also possible that contact is broken off or that the parties are content with the current state. As long as the intensity of the conflict is not too strong for those affected, they can use their trained behaviour patterns from childhood. In a best case scenario, they develop conflict styles via their cognitive abilities that are only possible for people having their specific mode of reasoning.

high - altruistic

5

Escape (Lose/Win) • Demand of the other side • Subordinate, obey • Strong desire for harmony

Teams

Integrate (Win/Win) • Expand resources • Clarify needs • Explore new options

Negotiate (Compromise) Making mutual concessions Differentiate points of contention

Play dead (Lose/Lose) • Avoid conversation • Deny conflict • Talk around the topic

Attack (Win/Lose) • Open (direct) confront, attack • Covered (indirect) process control, resistance

low

Orientation to the goals and concerns of the other party (Consideration)

426

low

high – egoistic Orientation towards my goals and concerns (Self-assertion)

Fig. 5.23 Typology of conflict styles (Berkel, 2014, p. 60)

Negotiate (Compromise) The points of contention can be differentiated. Both parties deviate from the maximum demand. Concessions are granted to each other. Integrate The real causes of the conflict can be identified. It is possible to manage the conflict in a way that is a win-win for all parties involved. The specific conflict style of integration is dealt with in detail in the Harvard Concept in Sect. 5.6.9.4. Effectiveness of Conflict Styles The bad news is that there is no such thing as the most effective conflict style. Depending on the type of conflict, duration, intensity, and the people involved, a different style is required in each case. Nevertheless, the effectiveness and appropriateness of conflict styles can be assessed (Fig. 5.24). Effectiveness: Can the goals be achieved, one’s own and the others’? Appropriateness: Can violating relationships or valid rules be avoided? The illustration makes it clear that the goal of any conflict management is always integration or cooperation (negotiation). These two conflict styles are cognitive. Yielding, avoiding, and fighting, on the other hand, are characterised by affect. Conflict situations are always stressful situations for people, especially with

427

large

5.6 Conflict Management and Crises

Integrate (Win/Win) Fight (Win/Lose)

Effectiveness

Negotiate (Compromise)

Avoid (Lose/Lose)

small

Submit (Lose/Win)

unreasonable

conduct

appropriate

Fig. 5.24 Effectiveness of conflict styles (Berkel, 2014, p. 62)

increasing intensity and duration. Conflict styles can also change over time: A dispute once begun with an open attitude of integration or compromise can lead to the affective styles of fighting, avoidance, or giving in as stress increases or when the basic emotions of fear and anger become more prominent. The conflict styles of fighting, avoiding, and giving in often conceal fears: • Fighting: I don’t want to be perceived as insecure or as a weakling. • Playing dead: I am afraid of taking a concrete position and thus also being held responsible. • Escape: I am afraid that acting as befits my needs might be perceived as aggressive, uncaring, or cold.

5.6.8

Models for Conflict Diagnosis

5.6.8.1 Conflict Escalation Levels The model of conflict escalation stages by Friedrich Glasl (Fig. 5.25) helps to identify the degree of intensity of a conflict. The phenomenon behind this is that unresolved conflicts increasingly activate people’s destructive forces over time. The behaviour of the conflict parties becomes increasingly emotional and unpredictable. Hence, the ability to control is lost over time. It becomes increasingly difficult for the conflict parties to differentiate between objective actuality and perception and to be able to resolve a conflict independently and neutrally.

428

5

Teams

Major phases 1

Hardening

2

Debate

3

Actions

4

Coalition

5

Loss of face

6

Strategy of threat

7

Limited destruction strikes

8

Fragmentation

9

Together into the abyss

Cooperation and competition

Self fulfilling prophecy

Degradation and reification

Fig. 5.25 Escalation stages and their main phases (Glasl, 2004, p. 218 f)

Table 5.12 Phase I: cooperation and competition (win-win) Level 1 Hardening

2

Debate

3

Actions

How can the escalation level be recognised? • Points of view crystallise, harden and clash • Noticing tensions itself leads to cramping symptoms. Nevertheless, there is the conviction that the tensions can be solved through conversations • No rigid parties or groups • Polarisation in thinking, feeling, and desire • View of superiority and inferiority • Arguments are used to hurt the other party in the emotionally • A conviction that “talking no longer helps” gains ground • A fait accompli strategy • Empathy for the “other” is lost. Misinterpretations increase because non-verbal behaviour is no longer corresponds in line with verbal behaviour

Phase I: Cooperation and Competition (Win-Win) As shown in Table 5.12 phase I, the parties involved still focus on the well-being of all. The parties concerned are convinced that everyone can emerge from the conflict as a winner. Everyone has a constructive attitude regarding the conflict. The conflict style of integration (win-win) is in the foreground.

5.6 Conflict Management and Crises

429

Phase II: The Self-fulfilling Prophecy (Win-Lose) The belief in constructive conflict resolution gets lost among the parties involved. The focus is now on differences and on gaining advantages. Self-assertion is in the foreground (win-lose). Table 5.13 describes the three stages of phase II. Phase III: Degradation, Reification (Lose-Lose) The conflict has escalated to such an extent in phase III that the parties realise that no one will be able to win any more (lose-lose). Both parties are now still trying to incur less damage than the other. Relations between the conflict parties have at this stage become completely functionalised. Participants treat each other as objects, doing so without sympathy. Table 5.14 shows the three final stages of mutual destruction. For conflict management in the project, the following conclusions can be drawn from the model of escalation levels: • The longer you wait to deal with the conflict, the more difficult it becomes. • Up to level 3, a conflict resolution is possible from which all parties involved profit. • In conflicts that escalate to level 6, there is still a winner–loser solution at best. • After that, in principle, both parties lose. Table 5.13 Phase II: self-fulfilling prophecy (win/lose) Level 4 Coalitions (“rope teams”)

5

Loss of face

6

Threat strategy

How can the escalation level be recognised? • The parties manoeuvre each other into negative roles and fight each other • People try to confirm their own prejudices • Supporters are recruited by each party for itself • There are public and direct (prohibited) attacks intended at making the opponent lose face • The counterparty is seen as the intrinsically bad • Threats and counter-threats increase • The pressure is increased, therefore stress increases, too • Those involved no longer get to think about what they are doing

Table 5.14 Phase III: degradation, reification (lose-lose) Level 7 Limited destruction strikes 8

Fragmentation

9

Together into the abyss

How can the escalation level be recognised? • The opponent is no longer seen as a person • Limited destructive attacks become the “appropriate” response • Lying becomes almost a virtue, as long as it harms the opponent • Relationships are systematically cut off • Important functions become immobilised • Regeneration seems no longer possible • Overall confrontation • Overcoming the opponent becomes acceptable even if the price is harming oneself

430

5

Teams

Limits of Self-help As soon as a social conflict gets to level 3, the people involved begin, at level 4, (coalitions) to win over as many supporters as possible for their own party. Conflict resolution is thereby intended to be established by means of the larger coalition. If, from this stage onwards, a project manager, scrum master or line manager intervenes with the well-meant intention of mediating the conflict, the parties will try to draw even the intervening person into their respective coalition. By giving in to this he loses his neutrality and becomes a party to the conflict himself. Therefore, from escalation level 4 onwards, it is imperative to involve a moderator or mediator. If this is an internal person, he or she should not come from the same hierarchical level, but, e.g., from a staff unit or from HR. It is even better if this is done by an independent person from outside the company. Figure 5.26 represents the limit of self-help and also summarises recommendations for intervention in conflicts.

5.6.8.2 Layer Model How do we proceed when a conflict is identified? What can give us orientation so that we do not fall into a foolhardy stance of seeing the conflict as something personal instead of retaining an ability to separate the symptoms from the causes? The layer model in Fig. 5.27 provides valuable support for this (Schmidt & Berg,

►from here on support is necessary

Main phases Winner – Winner

Winner – Loser

Loser – Loser

►from here on support is necessary

Possible roles

Level 3 - 6 External process support Level 6 - 7 Mediation

Level 1 - 3 Moderation

Level 6 - 8 Arbitration Level 7 - 9 Power intervention Meaningful interventions

►from here on support is necessary

Ask what it is about

Encourage listening

Conduct individual interviews

Reappraise selfimage / external image

Revisit history of polarisation

Separate parties

Support conversations

Make aware of behaviour

Recognise and point out patterns

Role assignment

Analyse critical incidents

Offer alternatives to exit

Become aware of inner drivers

Address non-verbal behaviour

Support conversations

Record unvalue, show coalition

Fig. 5.26 Meaningful roles and interventions in conflict situations

5.6 Conflict Management and Crises

431

Intervention from top to bottom

1. Work organisation (factual conflict) Infrastructure, structuring of working time, external working conditions, recognition, processes, information flow, resources (people, finance) 2. Role Distribution of tasks, responsibility and competences, organisational chart matching roles and skills 3. Behaviour Communication and behavioural patterns leadership style, cooperation, conflict skills 4. Norms and values Personal attitude to life view to human nature organisational culture 5. Personality profile Characteristics of a person, identity of organisation

Fig. 5.27 Layer model

2008, p. 158 ff). Conflict management according to the layer model needs adherence to two principles: • Making changes begins at the top. • Conflict management should only be extended to the lower levels as far as necessary. It is not about deepening every conflict to the lowest level. The model assigns the norms and values of the organisation and the person as well as character traits and personality profiles to the two lowest layers. This is to prevent a premature personification of the conflict. According to this model, the influencing factors from the work organisation are to be examined first, followed by role clarification and role assumption (behaviour). Assignment of the Conflict Types to the Layer Model In a next step, Fig. 5.28 the conflict types are assigned to the layer model. This is of course a simplification, because often the conflicts concern several influencing factors (and layers). Nevertheless, this assignment makes us aware that the causes of most conflicts can be relegated to the top level of a work organisation: Goal and interest conflicts, distributional conflicts, structural and organisational conflicts, and evaluation conflicts. These conflict types can be subsumed as factual conflicts. Role conflicts are then arranged at the next lower level.

432

5

Teams

Intervention from top to bottom

1. Work organisation (factual conflict) Conflicts of interests and goals, distribution and resource conflict, structural and organisational conflict, assessment conflict

2. Role role conflict

3. Behaviour relationship conflict personal conflict

4. Norms and values conflict of values

5. Personality profile

Fig. 5.28 Assigning the conflict types to the layer model

The most frequent types of conflict are arranged on levels 1 and 2. If the methodological approaches of agile and traditional are applied appropriately in the project organisation, many conflicts can be avoided or managed after they occur without people playing a role. They are only symptom carriers. From level 3 (behaviour) downwards the person has an influence over the conflict. If neither the work organisation nor the roles explain the disruption, the analysis is taken to the deeper behavioural level (relationship conflict or personal conflict), descending to the next level lies the conflict of values. Especially in intercultural cooperation, discrepancies can occur here. No type of conflict gets assigned deliberately to the personality profile. In a professional context, a person’s identity should be respected and protected as much as possible. Of course, it may be that a conflict in a project becomes a projection surface for a disruption on the personality level. Even if that is the case, the disturbance would nonetheless have to be dealt with at the behavioural level.

5.6.8.3 Questions for Conflict Diagnosis Now all the basics for a comprehensive conflict diagnosis have been discussed. Whether as a directly affected party, as an involved supervisor, as a conflict moderator, or as a mediator, it is always a matter of stepping away from emotions whilst activating rational, cognitive abilities. To this end, formulating questions

5.6 Conflict Management and Crises

433

helps at considering the conflict soberly. Following Karl Berkel (2014, p. 45 ff), the following questions should be worked on: 1. The points of contention: What is at stake? (a) What do the parties bring against each other? (b) What are they asking of each other? What is the intention behind it? (c) Do they see the points of contention the same way? How do they know? (d) How do the parties experience the conflict personally? How important is it for them? (e) To what extent are the points of contention objectively based or subjectively conditioned? 2. The course: How did the conflict develop? (a) What caused the conflict? (b) Which critical outcomes have exacerbated or mitigated it? (c) What is the state of affairs at the moment? (d) Which conflict escalation level according to Glasl can the conflict be assigned to? (e) What is the form of expression of the conflict: “hot” or “cold”, latent or open, displaced or real? 3. The behaviour: How do the parties act? (a) How is each party trying to influence the other? (b) Are they manipulating each other? Or are they arguing honestly? (c) What patterns (stimulus-response) occur repeatedly between them? (d) What is the preferred style—rigid or flexible—of each party? (e) Are the opposing parties debating with each other, reacting to each other, or are they already fighting with each other? (f) Can a specific conflict style be assigned to the conflict parties? (g) What does a continuation of the conflict mean for the parties involved in terms of outcome? What would the benefits of a settlement be? (h) What price (what concession) are the parties willing to pay? 4. The parties: Who is in conflict with each other? (a) Who are the parties: individuals? Groups? Organisations? Collectives? (b) In the case of individuals: Are there (interest) groups backing them? (c) For groups: Who is in charge? Where and how does is the person in charge intervening in the conflict? (d) For organisations: What is the internal communication, power, and decisionmaking structure? (e) How are the parties hierarchically organised? Is one superior or subordinate to the other? Are they equals in this regard? (f) How does each party feel about the other: as superior or inferior? As stronger or weaker? (g) What principle should apply in the relationship: Equality? Fairness? Necessity? (h) What can each side demand based on its position?

434

5

Teams

5. The expectations: What do the parties hope to achieve or fear from this conflict? (a) Is the conflict unavoidable or avoidable for the parties? Is it possible or impossible for them to reach an agreement? (b) Who benefits from the conflict: Just one party? A third party? The organisation? (c) Who is disadvantaged by the conflict: One of the parties? A third party? The organisation? (d) Who benefits from the on-going, unresolved conflict? (e) How do the regulatory mechanisms in the system work? (f) How do the parties assess the attempts to end the conflict so far? What has each done to reach resolution? With what effect? (g) Do the parties hope to be able to settle the conflict? Or have they given up all hope?

5.6.9

Conflict Resolution

5.6.9.1 The Aim of Conflict Management What is the purpose of conflict management? Can we claim to “solve” all of the types of conflict listed above? After all, that would mean that all the different beliefs, perspectives, needs, and feelings that have led to the deadlock can be dissolved? Since conflicts always have a personal and emotional component, resolving them becomes a challenging goal. Conflicts are always a challenge that has to be actively dealt with. Karl Berkel describes the goal of conflict management as follows: Conflict management aims at getting a grip on and mastering a conflict in such a way that the person (party) is (no longer) restricted in his or her experience and is (again) fully capable of acting (Berkel, 2014, p. 72).

Conflicts are always disturbances that first manifest themselves in our relationships with other people. At first glance, a conflict is always unpleasant: On the one hand, conflicts impede the personal, goal-oriented striving of the person. On the other hand, conflicts also always activate the basic feelings of fear or anger. Human feelings come faster and therefore long before a rational response. People who immediately act out their basic emotions in conflicts quickly become destructive. This prevents the unfolding of the positive potential of conflicts described in Sect. 5.6.5.

5.6.9.2 Restoring Self-control In a conflict, our brain is stimulated because the situation it is confronted with does not correspond to what it expects. In the excitement, people lose their ability for reflective self-control. When the brain is literally “running hot”, it has to be cooled down again to enable reflected self-control once more. This can only be achieved in the same way in which the excitation came about.

5.6 Conflict Management and Crises

435

The challenge here is that our attitudes and evaluations in the prefrontal cortex (Sect. 3.3.1) are based on a coupled network having cognitive and emotional components. Every position or demand in a conflict can therefore be rationally justified while being emotionally biased. Often an attempt is made to reach a new agreement in a discussion between the parties to the conflict and thereby come to lay down rules for an altered behaviour. Even if this agreement may make a lot of sense in terms of content, it often happens that the parties fall back into their former behavioural patterns soon or immediately afterwards. The reason why many conflicts are not successfully managed lies in a person’s behaviour being based on his or her attitude, an attitude shaped by the cognitive and emotional elements described above; conflict management that does not include these cannot therefore be successful. Conflict parties can only regain control over the situation and themselves if they at the same time emerge from their emotional foment. In order for this to happen, a space of trust must be created in which the parties involved feel safe. The feeling of security then allows emotions to cool down. In this newly created space of trust, people should next be encouraged or even inspired to have new experiences with strategies and patterns of behaviour the effectiveness they had before considered impossible in comparable situations given their attitude (Ballreich & Hüther, 2009).

5.6.9.3 Conflict Resolution Process Example

A man wants to hang up a picture. He has the nail, but not the hammer. The neighbour has one. So, our man decides to go over and borrow it. But then he has a doubt: what if the neighbour doesn’t want to lend me the hammer? Yesterday he only greeted me in passing. Maybe he was in a hurry. Maybe he was only pretending to be in a hurry, and he has something against me. What’s that? I didn’t do anything to him; he’s imagining things. If someone wanted to borrow a tool from me, I’d give it to him right away. And why not him? How can you refuse a fellow human being such a simple favour? People like this guy poison your life. And then he imagines I’m dependent on him. Just because he’s got a hammer. I’ve had enough of this. So he storms over, rings the bell, the neighbour opens the door, but before he can say hello, our man shouts at him: “Keep your hammer, you bully!” (Paul Watzlawick, 2004, p. 37 f) ◄ The hammer story by Paul Watzlawick shows: Man, preoccupied with his own thoughts and ideas, soon gets himself into a vicious circle. The longer we carry difficult situations around with us, the greater the danger that we become unnecessarily involved in something. Figure 5.29 summarises the prerequisites for successful conflict management. Each of the following steps illustrates the process as described by Karl Berkel (2014) in his cooperative conflict resolution (Fig. 5.29). It starts with the person,

436

5

Stage 3 Topic

Work on the problem Make an agreement

Stage 2 Relationship

Build up trust Communicate openly

Stage 1 Person

Teams

Recognise disturbance control excitement Willingness to deal with conflict

Fig. 5.29 Process of conflict resolution (Derived from Berkel, 2014, p. 111 ff)

then moves to the relationship, so that effective problem-solving can finally take place at the topic level. Recognise Disturbance Since people take conflicts personally, conflict resolution starts with people. First, the conflict or the subjectively observed disturbance needs to be seen for what it is. "

Either the conflict parties themselves report to the project manager. Or the project manager intervenes on the basis of his own personal perception or assumptions. The focus here is on the form of expression of the conflict, which can be quite different depending on the person and the situation. Knowledge of the conflict syndrome and conflict symptoms provides valuable help in this phase. It is important to note that the project manager can never know whether a disturbance exists and what the reasons may be. He can only form hypotheses about it and address the people involved. It is important that this discussion takes place bilaterally. No pressure should be built up. If the person addressed denies a conflict (because it is true or because the person is not yet in a position to talk about it), he has to accept this as long as the team’s performance is not affected. Otherwise, the project manager needs to intervene.

Control Excitement A constructive conflict resolution is not possible in a state of agitation. The parties concerned have to succeed in activating the “lift to the top” again, i.e. to get out of

5.6 Conflict Management and Crises

437

archaic emergency programmes and early childhood survival strategies and back into a state of self-control. Suppressing these feelings only escalates them. Starting off from affect, it is conversation which best leads best to reason. In conversation, feelings are put into (rational) words. By talking about one’s feelings and needs and also by paraphrasing statements made by other (conflict) parties, the brain is forced to think rationally. If talking is not possible, writing helps. Writing, like talking, activates people’s rational behaviour patterns and thus allows them to develop a certain distance from their own feelings. The project manager, or in more difficult cases a neutral coach or mediator, can create a space in which people concerned can describe how they are feeling and what it is they are feeling, and what is is, from their point of view, that has led to this specific provocation. The person responsible for the project has to be able to listen well and should be familiar with different question-asking techniques (Sect. 3.9.8). This step is neither about diagnosis nor about developing solutions. It is much more important to be able to describe one’s own and others’ emotions, since conflicts are multi-layered. At this stage the basis for a conflict diagnosis is created. "

The earlier the conflict is dealt with, the easier it is for the parties involved to understand their own feelings and to classify them. The more a conflict escalates, the more difficult it becomes for the people caught up in it. It is important that the people concerned can be convinced that their feelings are not to be fought. This makes them even more intense, as Watzlawick’s hammer story shows. The person in charge ought to create a space wherein he feels safe. Depending on the situation and the level of escalation, it may be useful to involve a neutral third person in the conversation at this stage. The following questions should be answered together: • What caused the malfunction? • Which basic emotions (fear or anger) are activated?

Willingness to Deal with Conflict The essential prerequisite for conflict transformation is that all parties involved show the willingness and readiness to manage the conflict. Even if only one party is unwilling or unable to do so, conflict resolution will not be able to deliver the desired results. The challenge in conflict is that, according to Glasl’s definition of conflict, it is always about subjectively perceived differences in feeling, thinking, or acting.

438

"

5

Teams

Conflicts disrupt the progress of the project. Therefore, project managers should want to resolve these problems as quickly as possible. However, the people involved have very different needs. They may also have different abilities and ways of dealing with these situations. Therefore, scrum masters or project managers need enough patience in a conflict to meet the needs of those affected. They have to succeed in creating enough urgency for the issue as well. The longer the conflict therefore lasts, the more it intensifies and the more people are affected.

Build up Trust Now the space of trust described above (Sect. 5.6.9.1) has to be established. If you want to maintain trust, you have to be and reveal yourself, you have to be able to open up and share your ideas and feelings. However, this opening up is always comes at a risk: Openness and honesty can get exploited. That is why it is so important to be able to create framework conditions in which all parties feel safe. "

A neutral third party has a great influence on the perceived security in conflict resolution. Whether it is the person responsible for the project, a coach, or mediator: if the parties have confidence in this person, they become able to engage in the process. It is important that the third party is accepted in his or her role by all parties to the conflict. Furthermore, rules should be laid down that are binding for all involved in the process. It is helpful to accommodate the other side with realistic proposals and to ensure that their personal motives and intentions are understood.

Communicate Openly Directly linked to trust is openness of communication. This, too, takes place at the relationship level. Good personal communication skills (Sect. 3.9) are essential for this, which includes: • Communication without judgement. • I-messages instead of you-statements. • Communication square: Revealing oneself and stating one’s concerns in a complete message. • Avoiding interpretations: Clarify discussion points through active listening and other questioning techniques. Work on the Problem The preconditions for effective problem solving at the substantive level have now been created. The concrete approaches to this are listed in Sect. 5.6.10. Make an Agreement Starting points for sustainable conflict resolution are concrete measures and activities, personal behaviour, or also a change in personal evaluation (Sect. 3.5.6).

5.6 Conflict Management and Crises

439

The more clearly (or “SMART”) the agreements can be defined, the greater the likelihood that conflict resolution will be successful. In this phase, small steps are to be appreciated as successes. However, the parties should not be hastily satisfied with specific results, but ought to continually ensure that perceptible and sustainable improvements can be achieved.

5.6.9.4 Harvard Concept in Conflict Management Behind every conflict there is a negotiation. Either it failed or it never took place (Michael Bullinger).

If we see a conflict as two elements that are incompatible or opposed, the question arises as to how these two elements can be connected or reconnected. Negotiation, according to the Harvard concept, can make a valuable contribution to this (Sect. 4. 10.4). The clear separation between people and problems makes it possible to argue intensely about content while maintaining respect for the person. The focus lies on the interests and allows for a balance to be established between the parties to the conflict. In Fig. 5.30 the process of conflict resolution is presented, oriented towards the Harvard concept.

Choose the best possible alternative Implementation and control

Separate people and things Protect relationship building up trust

6

5

1

4

2

Criteria Evaluate ideas, build up results on objective decisionmaking principles

What is it about?

Possibilities Creative choices for the common interests, New solutions

Basic conflict diagnosis: what is clear? unclear? agreement/ difference

3 Interests and needs Do not remain in positions, give space to feelings, self-image and a external image

Fig. 5.30 Conflict management according to the Harvard concept

440

5

Teams

Separate the Person from the Issue Depending on the escalation level of a conflict (Sect. 5.6.8.1), the conflict parties are still exposed to their basic emotions of anger or fear. It is therefore important to first (re-)create a space in which the parties feel safe and in which they can develop trust in the other side and possibly in the neutral mediator. Every person needs different amounts of time for this process. "

• The conditions described above for constructive conflict resolution have to be created before the process itself can begin. • All parties to the conflict are able to state their needs and impose conditions on the process. • Roles need to be clarified: Which conflict parties are actively involved in the process? Who is responsible for the process? What tasks, authorities, and responsibilities does this person have? • Rules for the process of conflict resolution have to be agreed upon: What rules apply to communication? How do we deal with breaches of the rules? Who is the referee? Who makes which decisions? • Depending on the level of escalation of the conflict, the conflict parties need to choose a neutral third party to moderate through the process, or even an authority that separates the opposing parties.

What Is It About? The vast majority of conflicts are not characterised by dissent about simply everything. The first step in this phase is therefore to first identify and subsequently protect areas of agreement. In a second step, the effective differences and thus sources of conflict are either worked out or confirmed. Ideally, in this situation a conflict diagnosis (Sect. 5.6.7) has already been carried out. Otherwise, the diagnosis has to now be carried out at the same time. "

• Discuss the results of the conflict diagnosis. Identify the effective differences. • Do not be satisfied too quickly with a realisation: Complaining about the situation, the framework conditions or other (absent) persons such as the superior, the project owner, or the supplier is usually easy. In every conflict, those involved have their own part to play as well. It is usually much more difficult to shed light on this. • Moving from symptoms to causes: The systemic phenomenon (Sect. 5.6.2) and the displaced are in conflict with substitute satisfactions (Sect. 5.6.7.2).

5.6 Conflict Management and Crises

441

Interests and Needs In many cases, parties to a conflict are so preoccupied with their anger at the other party or with a fear that they no longer feel themselves. They can hardly say what’s missing and what they need. In this phase, the parties ought to be able to take the big step of freeing themselves from their ego-centredness and of complementing their own self-image with that of others. If the parties involved can see points of contact in common interests and needs, the prerequisite for a viable conflict resolution is thereby created. They can step back from their present position and open up to future interests and needs. Example

Robert Dilts has developed the meta-mirror for this purpose. You can use it alone or with a coach. In a nutshell, it works like this: You put two chairs face to face: Chair 1 for you, chair 2 for your conflict partner. You imagine that your counterpart is sitting on chair 2. You sit down on chair 1 and tell your counterpart what you appreciate about him or her and what you expect and want to be different in the future. Then you get up and stand behind chair 1 and describe your own behaviour in relation to your conflict partner. Then you sit down on chair 2 and ask yourself: How do your words feel when heard by your opponent? What do you feel? What good intentions do you discover behind the behaviour of the conflict partner? Now stand sideways to the two chairs. From this metaposition, describe the interaction between the two people. What do you think of your own behaviour? How do you judge the behaviour of your conflict partner? How are they both dealing with each other? Which metaphor might describe this interaction? What ideas do you have from being in this position: What would you like to do differently in the future? What skills can you use to achieve this? Now go back to the second position. Evaluate the solution idea from this perspective. Back to the first position, determine how you see the communication. What has changed and how? Change your position between chairs 1 and 2 until you are satisfied with your new perception. Using a concrete situation, imagine how you are going to communicate with this person in the future. ◄ The conflict onion shown in Fig. 5.31 illustrates this differentiation. It works directly with the people involved in the conflict on far-reaching conflict situations. "

• Through solution-oriented questions, a positive picture can be drawn on the basis of which an improvement of the situation might be achieved: “How are we able to recognise that the conflict has been managed? What would be different then compared to the current situation?” • Circular questions can ask one party to see things from the other’s perspective: “If I were to ask colleague M, what do you think he really

442

5

Teams

cares about?” Or: “What interests is he pursuing with this project, what is really important to him?” • The “miracle” question can also open up new perspectives: “Imagine that the conflict has been overcome. You are, in this imagined situation, motivated and committed to your project again: What would indicate to you that that is the case?” • Paraphrasing or active listening can always be used to mirror and clarify the answers.

Possibilities The more choices that are available, the better the decision that is made. This phase thrives on the participants being able to break free from their existing patterns of thinking and behaviour in order to develop approaches to solutions that may not yet correspond to the common organisational culture. All approaches that make it possible to come a little closer to the common interests should be quickly grasped. Only diligence and pressure will make it difficult to develop these possibilities. What it takes is a surplus of attention enabling there being space for creativity (Sect. 1.7.2).

Positions Things that a party pretends to WANT TO HAVE ► Short-term focus

Interests Things a party really WANTS ► Medium-term desires

Needs Things that a party NEEDS TO HAVE. ► Long-term central

Fig. 5.31 Conflict bulb

5.6 Conflict Management and Crises

"

443

• Creative solutions are scarcely possible under time pressure. It often takes several attempts to develop viable or even high-quality options. The parties and the facilitator then have to admit that they need more time. • Ideas for solutions from external people can be valuable in this phase.

Criteria The joint discussion of objective criteria that can be applied to the selection of the negotiating alternative facilitates the abandonment of positions and reduces there being a basis for exerting unfair pressure. "

• In case of real conflicts, those responsible for the project have to ensure that the decision-making criteria are in line with the requirements of the project order or product vision. • For solutions outside the existing requirements, consult the product owner or the project owner.

Choose the Best Possible Alternative The BATNA principle is suitable for selecting the best possible alternative (Sect. 4. 10.4.5). Once a decision has been made, the most important thing for project managers is to then demand commitment to the chosen solution from all parties concerned. "

A kind of action plan determines who has to do what by when in order to realise the chosen solution. Controlling this is also a responsibility of those in charge of the project: if those affected fall behind with their contributions or even relapse into old behaviour patterns, this needs to be noticed early on. Corrective measures need to then be initiated.

5.6.10 Conflict Resolution Depending on the Type of Conflict The basic approach to conflict resolution outlined above is elaborated here with recommendations for managing specific types of conflict as specified in Sect. 5.6.6.

5.6.10.1 Goal Conflicts and Conflicts of Interest Conflicting Goals At an early stage in the project, conflicting goals can be clarified by means of written goals formulated as SMART as possible. These objectives should also, in the spirit of MbO, be agreed upon and not simply specified (Sect. 4.6.1). If a goal conflict arises in a later phase of the project, it has to be dealt with using the change request procedure. The different levels of authority of the project committees are to always

444

5

Teams

be taken into account (Sect. 2.3.8). Often, in the case of goal conflicts or conflicts of interest, the systemic phenomenon has an effect because the orders are unclear or contradictory. The shortcomings of an unclear order manifest themselves sooner or later in the project team as conflicts. It is part of the project manager’s task to point out differences or contradictions in the project objectives as formulated and to suggest solutions to those responsible for the project. If the contradictions are not addressed by the project owner, project manager, and project committee (decision-makers), but are rather delegated to the project organisation, they then tend to become evident among the employees. Conflicts of Interest It is very difficult to bring all the different stakeholder interests in a project down to a common denominator. With a sound stakeholder analysis, the diverging interests of the stakeholders become visible. This way they can be dealt with. Especially for acceptance and pioneer projects (Sect. 1.2.1), the on-going management of stakeholder interests is an important task that needs to be attended to in order to identify potential conflicts at an early stage.

5.6.10.2 Distribution Conflicts and Resource Conflicts Every project therefore faces the challenge to achieve its goals with human, financial, and technical resources. The tension this causes cannot, in principle, be resolved. Within the project, the project manager has to anticipate, point out divergences, and propose solutions to the decision-makers. Often, however, project managers need to also learn to put pressure on their project owners in order to receive the allocated resources they are entitled to according to the project order. In resource conflicts, the systemic phenomenon (Sect. 5.6.2) has its effect: If insufficient resource planning is made for employees in the line organisation, this also finds its reflection in the project teams. Those who do not know their available resources may start many more projects than they can handle. If resource planning and allocation are not decided at the level of decision-making authority in the project, the conflict is delegated to the project team. The consequences arising from this are: • Relationship conflict: The conflict manifests itself between people in the project team, e.g. between project manager and sub-project manager. • Personal conflict: The project manager tries to compensate for the deficit. This increases the workload and leads to a loyalty dilemma or motivation problems. In larger organisations, multi-project management (Sect. 2.7) and a project portfolio can defuse major points of friction. Over-allocations of individuals become apparent in multi-project management and can only be solved, or at least mitigated, by prioritising them in the project portfolio. The prerequisite for this, however, is that the responsible bodies also take responsibility for multi-project management and, in case there are over-allocations, make the necessary decisions. This means that on-going projects are then stopped, slowed down, or cancelled.

5.6 Conflict Management and Crises

445

5.6.10.3 Structural Conflicts and Organisational Conflicts Structural conflicts mainly concern project organisations that are linked to the line organisation via a matrix or coordination form (Sect. 2.3.8.8). The project manager can make this problem transparent. It is very difficult to bring about a change, though, as this would influence the management system of the line organisation. The most the project manager can do is to obtain optimal framework conditions for his project work through his project owner. In addition, he needs to adapt his leadership style accordingly: In a project coordination he leads laterally (Sect. 2.3. 8.5). If structural or organisational conflicts are not negotiated and decided, but solved with “lazy compromises” or with “work-arounds”, conflicts only get shifted or delegated to other bodies. 5.6.10.4 Evaluation Conflicts and Procedure Conflicts Man as a non-trivial system is unpredictable. Each individual has different points of view, different convictions, and is able to change his mind. Evaluation conflicts can be avoided if the decision-making mode is determined in advance before any decision is made. A consensus decision is indeed a worthy goal. Since everyone involved rarely has the same opinion as everyone else, a consensus or even a majority decision has to be a possible scenario. In certain situations, project managers or project owners need to also reserve for themselves a right of veto. The most important measure to avoid evaluation conflicts is the project order. The project manager is responsible for negotiating it until it is completely clear and he knows against which objectives he will be judged. The project organisation with the RACI matrix or the function diagram helps to determine at an early stage who is responsible for which deliverable or work package. These tables also make it clear which decision-making competences the project owner claims for himself and what it is he delegates to the project team. For the project manager, the process competence is in the foreground. He has to be able to delegate requests for technical decisions to his experts in the team because he does not himself have the expertise to do so. If different convictions and points of view become more acute in a scrum team, it is the task of the scrum master to intervene and mediate. A retrospective serves as the means by which possible discrepancies are made visible and dealt with. 5.6.10.5 Role Conflict Role conflicts exist on two levels: • Formal level to define the roles: WHAT are the tasks and responsibilities of the project manager or product owner (Sect. 5.3.1)? • Informal level of the lived role: HOW is this role fulfilled? HOW is the interface between organisation and person designed (Sect. 5.3.3)? Formal Level The formal structure of the project roles in the traditional approach is well known (Sect. 2.3.8.2), but this structure varies greatly depending on the connection of the project to the line organisation: If the project is integrated into the line organisation

446

5

Teams

via coordination, the project manager has almost no decision-making authority. As coordinator, he is responsible for ensuring that the relevant line managers receive the relevant information and so have a basis for decision-making. In matrix integration, coordination with line managers is challenging, too, especially when the project plan is in flux and resources have to be re-planned. In principle, formal role conflicts can be prevented through a well-founded project order or clarified afterwards. The RACI matrix or the Belbin team role concept also provides valuable services here. The formal roles in agile project teams are clearly defined. Agile project management is ideally handled in a pure project organisation. Self-organisation works best when forces are fully concentrated on the project. It is difficult for the product owner to accept the sprint results of the developers if he is not equipped with the decisionmaking authority to do so. If he is dependent on some committee of the line organisation for his decisions, this slows down the progress of the project, too. The product owner also loses his status vis-à-vis the scrum team. He has to see to it that he has enough resources for his task. Both aspects have to be clarified with the decision-makers in the line organisation. Informal Level The lived role takes place at the point of contact between the organisation and the person (Sect. 5.3.3). The organisation is composed of several role senders. As a role carrier, each person brings his unique persona, character and imprint to the project role, in whichever way it is defined in terms of content. Sometimes we send out messages to people that we are not aware of. Moreover, we can never know how we come across to other people. If we want to clarify conflicts in relation to the lived role, we depend on being able to constantly compare our self-image with the images of others. Therefore, our communication skills are of fundamental importance. We depend on receiving feedback from our colleagues again and again (Sect. 3.9.7) and must deal with it constructively. In order to get a better picture of how we are seen by other people, the Belbin team roles are helpful here as well. The approach emphasises that very different competences are needed in a team. In addition, it allows us to recognise differences by comparing self-assessment and assessments made by others and to work on them.

5.6.10.6 Personal Conflict In Sect. 5.6.2 it is explained that conflicts as a consequence of the systemic phenomenon manifest themselves superficially as personal and social conflicts. Lack of resource planning, unclarified project priorities (project portfolio), and the coordination between those responsible for the project and the line managers (project coordination and matrix organisation) are often causes for conflicts being delegated from the organisation to the project, thus challenging the individuals. This conflict can be managed if the person responsible for the project recognises that he or she is a symptom bearer and is able to refer the conflict back to the body that caused it. The best outcome would be that the project owner or the line manager recognises that there is a requirement for action in the area of change request management. The quality of the project work has to be guaranteed, and those involved in the

5.6 Conflict Management and Crises

447

project need to be protected from conflict. In order to achieve this optimal result, the project manager needs high competences in the area of negotiation Sect. 4.10. The challenge in this situation is that in a delegated conflict, the responsibility for action is with the symptom bearer and not with the party responsible for the cause of the conflict. This means that the symptom bearer still has to take time for this delegated conflict under the operational pressure of project implementation. This starts an avoidance–avoidance conflict. The more time a person takes for fighting the cause, the less time they have for other obligations. "

In the avoidance–avoidance conflict, the people involved face a dilemma. This can often neither be resolved, nor can those concerned have any expectation that there might be a good solution to it all. If the external situation cannot be changed (e.g. if no structured change request management is set up), the following options remain (Sect. 3.5.6): • One might change one’s own behaviour and no longer accept change requests after a certain project phase. In doing this, the project manager naturally takes a risk because it does not correspond to the usual project management culture and could therefore be sanctioned by line managers or employees. • One might change the assessment and thus accept that permanent changes in the scope are part of everyday life in this organisation, with all the consequences for the project itself as well as for oneself. • Of course, one can also try to suppress the whole thing. Most of the time, this only works in the short term in project work, because all kinds of omissions and deficits have an influence on the magic triangle and thus become visible through time delays, budget overruns, or changes in scope.

"

In the worst case, if personal stress increases more and more despite the attempt to reassess, the affected person has to even protect himself from an uncontrollable stress reaction (Sect. 3.5) and give up project responsibility or even change jobs.

5.6.10.7 Relationship Conflict (Social Conflict) Communication Within a social conflict, verbal and non-verbal communication always have friction potential. The well-known phrase “I only know what I have said when I know the message that has reached the receiver”, challenges us again and again to open ourselves to the subjective truth of the other person.

448

5

Teams

The best way to manage a communication conflict is through direct discussion. A distinction needs to be made between effect and evaluation. As shown in the conflict syndrome (Sect. 5.6.3), communication always suffers in conflicts, which also makes it an effective intervention. Developing communication skills should be a matter of course for all project participants. Those responsible for the project are also called upon to ensure that regular communication opportunities are installed in the teams. Proximity Versus Distance Project managers assume a leadership function. As a result, they are dependent on having authority to issue directives and take decisions vis-à-vis their team. The better the role is clarified and the better the project order is formulated, the lower the potential for friction should be. However, all those involved ought to always be aware of who is in which role and when. Especially if project managers used to be work colleagues, they need to develop a good instinct for when they can still be colleagues and in which cases they need to distance themselves more in order to do justice to their responsibility and role. Territory In its interdisciplinary cooperation, a project team always has the task of connecting different areas of competence and thus territories. Often the project objective has consequences for existing territories, be it production in the case of development projects or the processes of the line organisation in the case of change projects. This always questions existing power structures. Project managers often do not have the power to deal with these tensions themselves. Rather, they have to secure the support of the decision-makers within the framework of the mandate. Ranking Often project managers do not have the same status as managers in the line organisation. There may also be people in the team who are higher up in the line organisation than the project managers. If project managers are not acknowledged in their roles, they become ineffective. Again, it is important that they are supported by their decision-makers and that all people involved in the project are aware of which line managers are behind the project. Clarifying the hierarchy is best achieved at the kick-off: If the project owner is present and officially assigns the project manager or product owner to his role in front of the assembled project team, these roles are far more effective than if this does not happen. Leadership Product owners and project managers fill exacting management positions. They have often shown themselves as being qualified for these tasks through their expert roles. Their competences in this situation are largely of a technical-content nature. However, this is not enough in view of the challenges that product owners and project managers have to overcome. Here, process and decision-making competencies are required. Project owners who cannot let go of technical details demotivate their teams and create confusion. This then often manifests itself in relationship conflicts.

5.6 Conflict Management and Crises

"

How do we deal with the chemistry not being right? What if the project manager dislikes one of his sub-project managers and has negative feelings every time he meets him? In such situations, the ability to selfreflect helps (Sect. 3.3.4): Our own feelings have much more to do with ourselves than with other people. The reasons why a sub-project manager appears unlikeable to the project manager can be manifold, here is a list of some the possible reasons: • The sub-project manager has very different character traits compared to the project manager. If the project manager is a strong shaper in the sense of the Belbin team roles and the sub-project manager is a completer finisher, there is potential for conflict (Sect. 3.10.2). • Project managers and sub-project managers show different expressions of their basic needs. For example, a high need for status and recognition can clash with a strong need for security (Sect. 3.3.2). • It is also possible that it is a projection: The project manager projects something he does not like about himself onto the sub-project manager. If the project manager is not able to do solid project planning and accepts this as being his own weakness, he could accuse the sub-project manager of being unreliable and of not fulfilling his obligations. But perhaps the sub-project manager has the wrong face, the wrong name or it may just be some other quirk that on a subconscious level reminds the project manager of a person with whom he has once had a bad experience.

"

In all situations, feelings need to first be allowed and not fought. Then, after self-reflection, they can later be classified and evaluated. Since the project manager “only” has to work with his sub-project manager on a professional level, sympathy is not absolutely necessary. It is sufficient if there is respect and as long as the goals that have been agreed upon are achieved. This requires role clarification and an adequate leadership style. The essential needs for affection, sympathy, and love are met by the world of relationships and the world of self (Sect. 3.10.1). It would be an undue demand to try to satisfy these needs in the professional environment. One has to stop questioning oneself and be able to accept that the chemistry is not right with a specific person. If, in the sense of personal change strategies (Sect. 3.5.6), repression of antipathy and reassessment of the situation are not possible, there is always the possibility of changing the situation by reducing or breaking off contact with this person.

449

5.6.10.8 Conflict of Values Values are an essential part of our personality. This explains why it is so difficult to manage conflicts of values. Every virtue is opposed by a sister virtue. Such value pairs are, for example, trust and caution, assertiveness and consideration, or structure and flexibility. To be in balance with both virtues, to be able to live both qualities, is what constitutes professionalism.

450

5

Teams

Values Become Unvalues Every value also has a negative exaggeration, as shown in the square of values according to Friedemann Schulz von Thun Fig. 5.32. As an example, the value of structured work, which stands in the foreground in monochronic organisational cultures is discussed (Sect. 5.4.5). Being able to work in a structured way is important in project management. All project management, whether agile or traditional, is based on this. But there is also “too much of a good thing”, which is called (devaluing) exaggeration. However, it is just as important to be able to deviate from plans or to be able to take “detours” in the event of changes or problems, i.e. to be flexible. Here, the exaggeration would lie in leaving out all planning in order to then proceed chaotically. Example

Anyone who plans activities in detail in a traditional project that are to take place in 10 months is pedantic. The planning effort is enormous. The risk that something will change is very high. ◄ The opposite of structured work is flexible work. For this, chaotic work is the direct opposite form of exaggeration to pedantic work. Thus, there are two new pairs: structured work being in a state of positive tension with flexible work. The respective

Network of relations between the four poles of the value square

pedantic

positive tension ratio

flexible

devaluing exaggeration

devaluing exaggeration

structured

Development

overcompensation

chaotic

Fig. 5.32 Example of value square for structured working method

5.6 Conflict Management and Crises

451

exaggeration results in the negative value pair described by the terms pedantic and chaotic. The development is that one can use both values as virtues, though there is the danger of getting lost in the exaggeration of the sister virtue. This is done in an effort to fulfil the other virtue, which one is not so familiar with, as well as possible (overcompensation). The constructive handling of such value conflicts means the simultaneous development of both sister virtues. This brings the human qualities into balance.

5.6.10.9 Summary of Conflict Resolution The overview in Fig. 5.33 summarises a small selection of strategies and approaches that can be helpful in dealing with specific types of conflict.

5.6.11 Conflict Prevention

Goals and interests Distribution and resources Structure and organisation Evaluation Rolle Relationship Person Values

Fig. 5.33 Conflict management strategies per conflict type

Agree on common rules of conduct

Clarify roles RACI Matrix

Connection of the project to the line organisation

Multiproject management project portfolio

Manage dilemma

Negotiate

Clarify expectations with decision makers

Since project work is usually also prone to conflict, possibilities for the best possible prevention are shown here.

452

5

Teams

5.6.11.1 Project Management Methodology Either you look for the conflict at the beginning of the project, or it finds you during the process.

By far the most effective prevention at the root cause level is careful application of project methodology. If goals or visions are clear, stakeholder interests analysed, the project structure plan and detailed planning supported by the effort estimates, the project organisation defined, the availability of resources clarified, and communication platforms established, then conflicts have less of a chance of coming up. If contradictory or irreconcilable elements are found in the documents, they have to be dealt with in a methodically transparent manner. If not, the potential for conflict will not simply dissipate, but will instead unfold with greater intensity in a later project phase.

5.6.11.2 Disruptions Have Priority The conflict syndrome (Sect. 5.6.3) enables us to initiate preventive measures where conflicts might escalate: communicate openly, confront and correct distorted perceptions, take confidence-building measures, and reinforce common goals. Changes in the behaviour of people in the project team and thus symptoms of conflict (Sect. 5.6.4) are early indicators of disruption. Project managers and scrum masters must sensitise themselves to these early indicators of conflict. A postulate of Theme-Centred Interaction (TCI) according to Ruth Cohn is: “Disruptions have priority”: The earlier these are dealt with, the easier it will be to develop coping strategies that are satisfactory for all parties involved. The longer one waits, the higher the intensity of the conflicts are going to be, as explained in the escalation levels in Sect. 5.6.8.1. The primary means of preventing these escalations as they emerge is the information and communication concept (Sect. 2.4.10.2). Once all internal and external stakeholders have been identified and assessed, target-oriented platforms for communication have to be installed. These are supplemented with the competences of personal communication (Sect. 3.9) and thus form the foundation of cooperation. Meetings also bolster communication, relationship building, and relationship maintenance. Trust is built through relationship. Trust enables open dialogue and a culture in which the best solution can be argued for in the spirit of “hard on the issue, soft on the person”. 5.6.11.3 Conflict Skills and Frustration Tolerance Two areas of competence at the personal level conclude this chapter. Conflict Skills A person’s ability to deal with conflict is reflected in the extent to which he or she can endure conflicts and manage them fairly. Conflict capacity is based on the personal attitude that any situation, no matter how difficult, can somehow be worked through and that benefits can come from any conflict. This attitude is closely related

5.6 Conflict Management and Crises

453

to resilience (Sect. 3.8.4). Conflict-capable people are convinced that the energy developed in the conflict can be used positively. Differences and disagreements are seen as integral parts of life. Conflicts are managed profitably with the conviction that working on differences moves people and organisations forward. This is not possible in an “either-or” way of thinking. In dealing with polarities, people must be able to engage with the “as well as” (Sect. 5.4.5). Table 5.15 presents the ability to deal with conflict as a link between conflict aversion and belligerence. The exaggerated good becomes evil (F. Glasl).

Frustration Tolerance Frustration tolerance as a competence is assigned to people who do not always have to assert their own goals (Kreyenberg, 2005, p. 219). The sister virtue of conflict ability is frustration tolerance. Even young children have to learn that they can’t have everything, that things don’t always go the way they want them to. It is the same in professional life. There are customers, superiors, and organisational cultures that do not correspond to our ideal. We must always be able to realise that we are limited in our possibilities and abilities, on the one hand, and that the project organisation will not work perfectly, on the other.

5.6.12 Dealing with Crises Crises are sudden and unexpected events that cannot be handled with the usual and more or less standardised management methods (Wastian et al., 2015, p. 292).

Crises can arise in any project. A project crisis is a situation in which the progress of the project is blocked or severely restricted and the achievement of the project objective is at risk. A crisis therefore requires immediate intervention. This is a non-delegable management task of the project manager. A crisis can have its origin in the (project) organisation itself. However, they are often caused by conditions from outside the organisation.

Table 5.15 Basic assumptions on conflict capacity (Glasl, 2008, p. 13) Conflict aversion Conflicts only cost energy, so keep your hands off them! Open conflicts destroy many things unnecessarily!

Conflict skills Aggression is energy: I redirect it positively! Conflicts help to break away from old habits!

Conflicts only deepen the differences. Differences are basically not solvable!

Differences are vital, working on differences enriches everyone!

Belligerence In conflicts I experience myself, they increase vitality! Only from chaos does something new really emerge! Consensus is often illusion, because: “War is the father of all things!”

454

5

Teams

5.6.12.1 Internal Causes of Crisis There are a number of warning signals or indicators of impending crises. Examples are: cumulative cost overruns, unfinished partial results, lack of decisions, dwindling motivation and lack of commitment of those involved in the project, cries for help from the project. Crises are exceptional situations and therefore require a special procedure and adequate organisation. Crises are dealt with in different phases. The following measures can help to identify and deal with internal causes of crises as early as possible: • Careful and periodic risk management and controlling of “scope”, “time”, and “costs”. • Identifying indications for the conflict syndrome (Sect. 5.6.3) and for conflict symptoms (Sect. 5.6.4) and aspects of group dynamics (Sect. 5.2). • Cultivating an open culture of discussion, regular, personal agreements as well as measures relating to conflict prevention.

5.6.12.2 External Causes of Crisis In spite of all caution and professionalism, project crises can hit project teams unexpectedly from the outside. Reasons for this may, for instance, be that project participants are at that moment suffering a crisis in their personal environment. This can paralyse their ability to work as required of them and also affect the team as a whole. However, an important supplier can also fail, a customer might go bankrupt or a hacker attack occurs that may paralyse the entire infrastructure. Large organisations operate crisis teams in preparation for worst-case scenarios. However, project organisations are too small for this. The following measures can help to identify and deal with external causes of crises as early as possible: • Regular and active stakeholder management. • Risk management measures such as credit checks or second source suppliers. • Rapid intervention and assistance when project participants experience a personal crisis. " The moment a crisis gets noticed, the current state at that moment should be documented as well as possible. Just as the police immediately take photographs of evidence in the event of a car accident. If, for example, a product owner is no longer available and is replaced by another person, just at the moment of taking over a comprehensive as-is recording of the product concept, the product backlog, a release plan and also of the costs incurred need to be established.

5.6.12.3 Leadership and Communication Crises are a matter for the boss. Project managers, scrum master, and product owners are to deal with crises immediately. They need to also inform their superiors in the line organisation instantly. A task force has to be set up that takes on responsibility for managing the crisis. Depending on the assessment of the situation,

References

455

Table 5.16 Guiding principles in crisis communication (Alter, 2008, p. 120) As a manager, inform . . . Active and not reactive Rapid and continuous Always first the directly affected Truthfully and empathetic Never say: “no comment”!

Provide concrete information about . . . Victims Damage Consequences Immediate measures Investigations

the accountable hierarchical levels have to be represented in it. Crises are unsettling. They generate fears. That is why communication is central in crisis situations. Base your communication in crises on the guiding principles in Table 5.16.

5.7

Finally. . .

There is nothing good unless you do it (Erich Kästner).

The complexity and dynamics to which projects are exposed today place very high demands on those responsible for projects. With this handbook on project management, we have endeavoured to elaborate all critical success factors for project work in a differentiated manner. Many different competences are required for the success of complex, interdisciplinary projects. That is why we have here connected the methodological foundations to the people who work in project teams, teams that have to be led. These levels interact with each other. We hope that you will always be able to derive new, creative impulses from it in order to cope constructively and successfully with the challenges in your project work. Projects are social systems in a permanently changing environment. This repeatedly challenges everyone involved. So, you yourself are also challenged and invited again and again—and in the spirit of Erich Kästner—to do good for your projects.

References Alter, U. (2008). Informieren als Führungsaufgabe. In T. Steiger & E. Lippmann (Eds.), Handbuch angewandte Psychologie für Führungskräfte (Vol. II). Springer. Ballreich, R., & Hüther, G. (2009). Du gehst mir auf die Nerven! Neurobiologische Aspekte der Konfliktberatung. Concadora Verlag. Berkel, K. (2014). Konflikttraining. Windmühle Verlag GmbH. Claßen, M. (2019). Spannungsfelder im Change Management. Handelsblatt Fachmedien GmbH. Doppler, K., & Lauterburg, C. (2014, Auflage 13). Change Management, den Unternehmenswandel gestalten. Campus. Edmondson, A. C. (2018). The fearless organisation (1st ed.). Wiley. Gellert, M., & Nowak, C. (2007). Teamarbeit – Teamentwicklung – Teamberatung (3rd ed.). Limmer Verlag. Glasl, F. (2004). Konfliktmanagement. Ein Handbuch für Führungskräfte (8th ed.). Haupt Verlag.

456

5

Teams

Glasl, F. (2008). Selbsthilfe in Konflikten. Haupt Verlag. Klein, P., & Limberg-Strohmaier, S. (2012). Das Aufstellungsbuch – Familienaufstellung, Organisationsaufstellung und neuste Entwicklungen. Braumüller Verlag. Königswieser, R., & Hillebrand, M. (2004). Einführung in die systemische Organisationsberatung. Carl-Auer-Systeme Verlag. Kreyenberg, J. (2005). Konflikt-Management. Cornelsen Verlag. Lippmann, E. (2008). Konfliktmanagement. In T. Steiger & E. Lippmann (Eds.), Handbuch angewandte Psychologie für Führungskräfte (Vol. II). Springer. Little, J. (2014). Lean change management. Happy Melly Express. Rogers, E. M. (2003). Diffusion of innovations. Free Press. Rosselet, C., & Senoner, G. (2010). Management macht Sinn – Organisationsaufstellungen in Managementkontexten. Carl-Auer-Systeme Verlag. Satir, V., et al. (1991). The Satir model. Science and Behavior Books. Schmidt, E. R., & Berg, H. G. (2008). Beraten mit Kontakt. Gabal Verlag. Schwarz, G. (2014). Konfliktmanagement. Springer. Seliger, R. (2014). Positive Leadership – Die Revolution in der Führung. Schäffer-Poeschel Verlag. Seligman, M. (2012). Flourish: A visionary new understanding of happiness and well-being. Atria Books. Steiger, T., & Lippmann, E. (Eds.). (2008). Handbuch angewandte Psychologie für Führungskräfte (Vol. I&II, 3rd ed.). Springer. Tamm, J., & Luyet, R. (2005). Radical collaboration. Harper Collins. Wastian, M., et al. (2015). Applied psychology for project managers. Springer. Watzlawick, P. (2004). Anleitung zum Unglücklich sein. Piper Verlag. Weber, G., & Rosselet, C. (2016). Basics des Aufstellens von Organisationen und Arbeitsbeziehungen, Grundlagen und Vorgehensweisen. In G. Weber & C. Rosselet (Eds.), Organisationsaufstellungen – Grundlagen, Settings, Anwendungsfelder. Carl-Auer-Systeme Verlag. Zaninelli, S. (2005). Chancen und Herausforderungen weltweiter Zusammenarbeit über die Entfernung. In Wissensmanagement in der IHK-Organisation. Geschäftsfeld International.

Further Readings Doppler, K. (2017). Change – wie Wandel gelingt. Campus Verlag GmbH. Euforia. (n.d.). From inspiration to impact. https://www.euforia.org Hüther, G. (2016a, 2001). Bedienungsanleitung für ein menschliches Gehirn (12th ed.). Vandenhoeck & Ruprecht Verlag. Hüther, G. (2016b, 1997). Biologie der Angst. Wie aus Stress Gefühle werden (13th ed.). Vandenhoeck & Ruprecht Verlag.

6

Reference List for the Individual Competence Baseline (ICB) from IPMA (International Project Management Association)

Section 1.8 describes the standards and certification models in project management. Like IPMA, this Project Management Handbook covers the various competences for project management and is not designed for a defined process-oriented framework. The basis for IPMA certification is the Individual Competence Baseline (ICB). IPMA structures the necessary competences on the basis of the “Eye of Competence” (Fig. 6.1). Table 6.1 lists references between the Swiss Individual Competence Baseline (Version 4.0) for Project Management and this Project Management Handbook and in that way supports people preparing for IPMA certification. The referencing can also be used analogously for the two Swiss ICB for programme management, and portfolio management can also be applied mutatis mutandis. However, the adaptation to programme management and portfolio management needs to be made by the reader.

# Springer-Verlag GmbH Germany, part of Springer Nature 2023 J. Kuster et al., Project Management Handbook, Management for Professionals, https://doi.org/10.1007/978-3-662-66211-3_6

457

458

6

Reference List for the Individual Competence Baseline (ICB) from. . .

People

Practice

People

Practice

Perspective

Perspective

Fig. 6.1 Eye of competence from IPMA (International Project Management Association)

6

Reference List for the Individual Competence Baseline (ICB) from. . .

459

Table 6.1 Swiss individual competence baseline (ICB) version 4.0 Competence Competence indicators Competence area context (perspective) 1.01 Strategy 1.01.01 Align the project with the mission and vision of the organisation 1.01.02 Identify and exploit opportunities that influence the organisation’s strategy 1.01.03 Develop justification for the project and ensure that the business and/or organisational reasons that led to the project still exist. 1.01.04 Determine, assess, and review critical success factors 1.01.05 Determine, assess, and review key performance indicators (KPI) 1.02.01 Know the basics of project 1.02 Governance, management and its implementation structures, and processes 1.02.02 Know the basics of programme management and their implementation 1.02.03 Know the basics of portfolio management and its implementation 1.02.04 Align the project with the support functions 1.02.05 Align the project with the decision-making and reporting structures and quality requirements of the organisation. 1.02.06 Align the project with HR processes and functions 1.02.07 Align the project with finance and controlling processes 1.03.01 Identify and comply with the 1.03 Compliance, legislation applicable to the project. standards, and regulations 1.03.02 Identify and comply with all safety, health, and environmental (SHE) regulations relevant to the project. 1.03.03 Identify and comply with all codes of conduct and professional rules relevant to the project 1.03.04 Identify and adhere to sustainability principles and objectives relevant to the project. 1.03.05 Evaluate, use, and further develop professional standards and tools relevant to the project. 1.03.06 Evaluate, compare, and improve the organisation’s project management competence.

Section in the book 1.2.3, 2.3.2, 2.3.4, 2.7.3, 2. 8.3, 2.8.4 1.2.3, 1.4.2, 2.2.2, 2.2.3, 2. 3.9 1.9, 2.2.2, 2.2.3, 2.3.2, 2. 3.10, 2.5.6, 2.5.7, 2.7.1, 2. 7.4 2.2.1, 2.3.1, 2.7.1, 2.9.2 2.3.1 1.1–1.4, 2.1, 2.3.8 1.3.1, 1.9, 2.7.3 1.3.1, 1.9, 2.7.1, 2.7.2 2.7.4, 2.7.5 2.3.5, 2.3.6, 2.4.11, 2.5.6

2.3.5, 2.3.8, 2.5.7, 2.6.4, 2. 7.1.6, 2.3.8.8 2.3.5, 2.5.6, 2.5.7 2.3.3.2, 2.3.7, 2.3.9.4, 2.3. 9.5, 2.9 2.3.3.2, 2.3.7, 2.3.9.4, 2.3. 9.5 2.3.3.2, 2.3.9.4, 3.2

2.3.2, 2.3.3.2

1.4, 1.8, 2.3.9.4, 2.7.1, 2. 7.4, 2.7.5 1.8, 2.7.4, 3.10

(continued)

460

6

Reference List for the Individual Competence Baseline (ICB) from. . .

Table 6.1 (continued) Competence 1.04 Power and interests

Competence indicators 1.04.01 Assess personal ambitions and interests of third parties and their potential impact on the project and use this knowledge for the benefit of the project. 1.04.02 Assess the informal influence of individuals and groups of people and their potential impact on the project, and use this knowledge for the benefit of the project. 1.04.03 Assess personalities and working styles of third parties and use them for the benefit of the project 1.05 Culture and 1.05.01 Assess culture and values of values society and their impact on the project 1.05.02 Align the project with the formal culture and values of the organisation 1.05.03 Assess the informal culture and values of the organisation and their impact on the project. Competence area people 2.01 Self-reflection 2.01.01 Identify and reflect on the and self-management influence of own values and personal experiences on the work 2.01.02 Build self-confidence based on personal strengths and weaknesses 2.01.03 Identify and reflect on personal motivations in order to set and focus on personal goals 2.01.04 Organise own work depending on the situation and own resources 2.01.05 Take responsibility for personal learning and development 2.02.01 Recognise and apply ethical 2.02 Personal values in all decisions and actions integrity and reliability 2.02.02 Promote sustainability of outputs and outcomes 2.02.03 Taking responsibility for one’s own decisions and actions 2.02.04 Act, make decisions and communicate without contradictions 2.02.05 Perform tasks carefully to build trust with others 2.03 Personal 2.03.01 Communicate clear and communication structured information to others and ensure their equal understanding

Section in the book 2.3.5, 2.3.9.1, 4.9, 5.5

2.3.5, 2.3.8, 4.9, 5.2.2, 5.5

3.1, 3.2, 3.4.3, 3.10.2

1.6, 2.3.5, 2.3.9.1, 3.4, 4.1, 5.2 2.3.5, 2.3.9.1, 2.3.9.4, 3.4, 4.1, 5.2 2.3.5, 2.3.9.1, 3.4, 4.1, 5.2

3.3, 3.4, 3.8.1, 3.9, 3.10

3.5, 3.8.2, 3.10.2.2 3.3.3, 3.5, 3.7, 3.8, 3.10.2

3.2, 3.5, 3.8, 3.9, 3.10.2 3.8, 3.10 3.4, 3.9, 5.6.10.8 2.3.4, 2.6.5, 3.8.4, 4.10.3, 5.5 2.8.3, 3.8.4, 3.10, 4.8 2.3.14, 2.8.3, 3.5.6, 3.9 3.2, 3.3.5, 5.2.3, 5.3.1, 5. 4.1 2.6.4, 3.9, 3.10.3, 4.11

(continued)

6

Reference List for the Individual Competence Baseline (ICB) from. . .

461

Table 6.1 (continued) Competence

2.06 Teamwork

Competence indicators 2.03.02 Enable and promote open communication 2.03.03 Select communication types and channels to meet the needs of the target group, situation, and management level 2.03.04 Communicate effectively with virtual teams 2.03.05 Use humour and change of perspective appropriately 2.04.01 Establish and maintain personal and professional relationships 2.04.02 Build, moderate, and participate in social networks 2.04.03 Show empathy through listening, understanding, and support 2.04.04 Show confidence and respect by encouraging others to express their opinions and concerns 2.04.05 Communicate own visions and goals to achieve third-party engagement and commitment 2.05.01 Taking initiative and proactively providing advice and support 2.05.02 Take ownership and show commitment 2.05.03 Lead and improve the work of individuals and teams through setting direction, coaching, and mentoring 2.05.04 Exercise power and influence appropriately over third parties to achieve the objectives 2.05.05 Making, enforcing, and reviewing decisions 2.06.01 Assemble and develop the team

2.07 Conflicts and crises

2.06.02 Promote cooperation and networking between team members 2.06.03 Enable, support, and review the development of the team and team members 2.06.04 Strengthen teams by delegating tasks and responsibilities 2.06.05 Recognise mistakes to enable learning from mistakes 2.07.01 Anticipate conflicts and crises and prevent them if possible

2.04 Relationships and engagement

2.05 Leadership

Section in the book 3.3.5, 3.9, 5.2, 5.4.1 2.3.5, 2.3.6, 2.4.10, 3.9

3.9.8.2, 4.12 2.3.5, 3.3.3, 3.3.6, 3.5, 3. 9.5, 3.9.8, 3.10.5 1.5.2, 2.3.6, 2.4.10, 3.3.6, 3.4, 3.10, 4.12 1.5.2, 1.6.3, 4.11 3.4, 3.9.8 1.6.2, 3.3.5, 3.4, 4.4.4, 4.6, 4.7, 5.4 3.7, 3.9, 4.4.3, 5.2.3, 5.4

2.3.7, 3.8.1, 3.8.4, 3.9.3, 3. 10.3, 3.10.4, 4.2 4.2, 4.5 2.3.2, 2.3.6, 3.7, 3.10.3, 3. 10.4, 4.4.4, 4.6 2.3.5, 2.3.8, 4.9

2.3.5, 2.3.14, 2.8.3, 3.9, 4. 4.2, 5.3 1.5, 2.3.8, 3.1, 3.4, 3.7, 4.6, 4.10, 5.3 1.5, 2.3.9.1, 3.9.8, 4.2, 5.3.1, 5.3.2, 5.3.3, 5.4.1 2.5.4, 2.5.5, 2.6.6, 3.7, 3.8, 3.10 3.9.7, 4.4–4.7 2.5.5, 2.5.6, 2.6.6, 3.8.5, 5.4 2.5.5, 3.5, 4.7, 5.6.11 (continued)

462

6

Reference List for the Individual Competence Baseline (ICB) from. . .

Table 6.1 (continued) Competence

2.08 Versatility

2.09 Negotiations

2.10 Resultorientation

Competence indicators 2.07.02 Analyse causes and effects of conflicts and crises and select appropriate responses 2.07.03 Resolve or mediate in conflicts and crises and/or their effects 2.07.04 Identify and share learning from conflicts and crises to improve future work 2.08.01 Create and support an open and creative environment 2.08.02 Apply conceptual thinking to analyse situations and define solution strategies 2.08.03 Apply analytical techniques to analyse situations, information, and trends. 2.08.04 Promote and use creative techniques to find alternatives and solutions 2.08.05 Promote holistic view of the project and its context to improve the decision-making process 2.09.01 Identify and analyse interests of all parties involved in negotiations 2.09.02 Develop and evaluate options and alternatives that have the potential to meet the needs of all stakeholders 2.09.03 Define negotiation strategy that is in line with own objectives and acceptable to all parties involved 2.09.04 Reach agreements with other parties that are in line with own goals 2.09.05 Discover and exploit additional sales and acquisition opportunities 2.10.01 Evaluate all decisions and actions for their impact on the success of the project and the organisation’s objectives. 2.10.02 Align needs and resources to optimise results and successes 2.10.03 Create and maintain a healthy, safe, and productive working environment 2.10.04 Promote and “sell” the project, its processes and results 2.10.05 Delivering results and gaining acceptance

Section in the book 5.6.2, 5.6.3, 5.6.6–5.6.9

3.3.5, 3.9, 5.2, 5.6.9 2.5.5, 5.2, 5.6

1.5–1.7, 2.8, 3.3.5, 5.1.2, 5.4 1.3.3, 1.6.3, 1.6.4, 1.7.1–1. 7.3, 2.3.14 2.3.9, 2.3.14, 2.8.2

2.3.14, 2.8

1.3.3, 2.3.5, 2.3.10

2.3.5, 4.10.1, 4.10.2, 4.10. 3.1, 5.6.9.4 4.10.1, 4.10.2, 4.10.3.1–4. 10.3.3, 4.10.4 4.10.3.2, 4.10.3.3, 4.10.4

4.10.3.2, 4.10.3.3, 4.10.4 1.2.3, 2.3.6, 2.4.11, 2.9 2.3.2–2.3.4, 2.3.10, 2.4.3

2.3.3.4, 2.3.5, 2.3.10, 2.4.3 2.3.8, 2.3.10, 2.4.3, 2.5.2, 4.2, 5.4 2.3.5, 2.3.6 2.5.4, 2.5.6, 5.5 (continued)

6

Reference List for the Individual Competence Baseline (ICB) from. . .

463

Table 6.1 (continued) Competence Competence indicators Competence area practice 3.01 Project design 3.01.01 Recognise, prioritise, and review success criteria 3.01.02 Review, apply, and share lessons learned from and with other projects. 3.01.03 Determine project complexity and its consequences for the project management approach 3.01.04 Select and adapt general project management approach 3.01.05 Design, monitor, and adapt concept for project implementation 3.02 Requirements 3.02.01 Define and develop hierarchy of and goals project objectives 3.02.02 Identify and analyse needs and requirements of project stakeholders 3.02.03 Prioritise and decide on requirements and acceptance criteria 3.03.01 Define deliverables 3.03 Scope of services and delivery 3.03.02 Structure scope of services items 3.03.03 Define work packages 3.03.04 Create and maintain scope of service configuration 3.04 Procedure and 3.04.01 Define activities that are deadlines necessary to deliver the project 3.04.02 Determine workload and duration of activities 3.04.03 Determine procedure for deadlines and phases or sprints 3.04.04 Determine the sequence of project activities and prepare a process and schedule. 3.04.05 Monitor progress against schedule and make necessary adjustments 3.05 Organisation, 3.05.01 Assess and determine information, and stakeholder needs for information and documentation documentation 3.05.02 Define structure, roles, and responsibilities in the project 3.05.03 Build infrastructure, processes, and information systems 3.05.04 Implement, monitor, and, if necessary, adjust the organisation of the project.

Section in the book 2.3.1–2.3.3, 2.3.5, 2.3.10 2.5.5, 2.5.6, 2.6.6 1.2.1, 1.2.2, 1.4, 2.1

1.4, 2.1 1.4, 2.1, 2.3.12, 2.5.4, 2. 5.6 2.3.2, 2.3.3 2.3.3, 2.3.5, 2.3.10, 2.4.2, 2.4.3 2.3.3, 2.3.5, 2.3.10, 2.4.2, 2.4.3 2.3.10, 2.4.3, 2.5.2 2.3.10, 2.4.3, 2.5.2 2.3.10, 2.4.3, 2.5.2 2.3.3, 2.3.8, 2.3.10, 2.4.3, 2.5.2, 2.5.6, 2.5.7 2.3.10, 2.4.7, 2.5.2 2.4.6, 2.4.7, 2.5.2 2.4.4, 2.4.7, 2.5.2 2.4.4, 2.4.7, 2.5.2

2.5.3, 2.5.4, 2.5.6, 2.5.7

2.3.5, 2.3.6, 2.4.10

2.3.8, 2.3.8.8, 5.3.1–5.3.3 2.3.5, 2.4.10 2.3.8, 5.3.1–5.3.3

(continued)

464

6

Reference List for the Individual Competence Baseline (ICB) from. . .

Table 6.1 (continued) Competence 3.06 Quality

3.07 Costs and financing

3.08 Resources

3.09 Procurement

3.10 Planning and control

Competence indicators 3.06.01 Develop quality management plan for the project, monitor implementation, and revise as necessary. 3.06.02 Review the project with its deliverables to ensure that they continue to meet the requirements of the quality management plan. 3.06.03 Verify achievement of the project’s quality objectives and recommend necessary corrective and/or preventive actions. 3.06.04 Plan and organise validation of project results 3.06.05 Ensure quality in the course of the project 3.07.01 Estimate project costs 3.07.02 Create project budget 3.07.03 Secure project funding 3.07.04 Develop, establish, and maintain financial management and reporting system for the project 3.07.05 Monitor finances to identify and correct deviations from project plan 3.08.01 Develop strategic resource planning to be able to deliver the project results 3.08.02 Define quality and quantity of resources needed 3.08.03 Identify potential resource sources and negotiate their procurement 3.08.04 Allocate and distribute resources according to defined needs 3.08.05 Evaluate resource consumption and take necessary corrective action 3.09.01 Agree procurement needs, options, and processes 3.09.02 Contribute to evaluation and selection of suppliers and partners 3.09.03 Contribute to negotiations and agreements of contractual provisions to bring them in line with project objectives 3.09.04 Monitor contract performance, address problems, and claim compensation if necessary 3.10.01 Start project, develop project management plan, and obtain approval

Section in the book 2.4.11

2.4.3, 2.4.11, 2.5.4, 2.5.6, 2.6.3

2.4.3, 2.5.6, 2.5.8, 2.6.3

2.4.11, 2.6.3 2.4.11 2.4.4, 2.4.6, 2.4.9 2.4.9 2.2, 2.7.2 2.5.6, 2.5.7, 2.7.1.8

2.5.6, 2.5.7, 2.7.1.8 2.4.8

2.4.4, 2.4.7 2.4.8, 2.9 2.4.7, 2.4.8, 2.5.2, 5.6 2.5.6, 2.5.7, 3.10 2.9 2.9 2.9, 2.3.9.4

2.5.6–2.5.8

2.3.5, 2.3.8, 2.3.11–2.3.13 (continued)

6

Reference List for the Individual Competence Baseline (ICB) from. . .

465

Table 6.1 (continued) Competence

3.11 Opportunities and risks

3.12 Stakeholders

3.13 Change and transformation

Competence indicators 3.10.02 Initiate and manage transition to a new project phase 3.10.03 Compare project performance with the project plan and take corrective action if necessary. 3.10.04 Report on the progress of the project 3.10.05 Assess, obtain approval for and implement project changes. 3.10.06 Complete and evaluate a phase or the project 3.11.01 Develop and implement opportunities and risk management structure 3.11.02 Identify opportunities and risks 3.11.03 Analyse probability and impact of opportunities and risks 3.11.04 Select strategies and implement measures to address opportunities and risks 3.11.05 Evaluate and monitor opportunities, risks, and implemented measures 3.12.01 Identify stakeholders and analyse their interests and influence 3.12.02 Develop and maintain stakeholder strategy and communication plan 3.12.03 Engage executive, project owner, and senior management to achieve commitment and to manage interests and expectations 3.12.04 Engage users, partners, and suppliers to achieve cooperation and commitment 3.12.05 Establish, maintain, and terminate networks and alliances 3.13.01 Assess the adaptive capacity of the organisation(s) to change 3.13.02 Identify change requirements and transformation opportunities 3.13.03 Develop a change or transformation strategy 3.13.04 Implement change or transformation management

Section in the book 2.2.1, 2.2.5, 2.3.1, 2.3.15, 2.4.1, 2.4.12, 2.5.1, 2.5.9, 2.6.1, 2.6.7 2.4.7, 2.5.2, 2.5.4, 2.5.6, 2. 5.7 2.2.5, 2.3.15, 2.4.12, 2.5.4, 2.5.6, 2.5.7, 2.5.9, 2.6.7 2.5.8 2.2.5, 2.3.15, 2.4.12, 2.5.5, 2.5.9, 2.6.6 2.3.7, 2.3.9.2

2.3.7, 2.3.9.2 2.3.7, 2.3.9.2 2.3.7

2.3.7

2.3.5, 2.5.7, 3.3.3, 4.9 2.3.5, 2.3.6, 2.4

2.3.5, 2.3.8.8

2.3.5, 2.9

2.3.5, 4.9.3 1.4.4, 3.5, 5.5 2.3.5, 5.5 1.4.4, 2.5.5, 2.6.6, 5.5 2.3.6, 2.6.2, 2.6.4

Index

A Ability, 250, 251 Acceptance, 82, 166, 201, 228, 281, 314, 332, 364 criteria, 144 project, 6, 9 Accuracy of estimate, 53 Acknowledgment, 199 Active listening, 298 Activity, 125 Adherence to deadlines, 157 Adjourning, 371 Agile approach, 14 manifesto, 15 model, 27 project management, 14, 27, 49, 94, 141, 142, 145, 148, 172, 175–177, 238, 326, 339, 342 Analogy method, 231 Anticipatory obedience, 416 Appreciation, 84, 292, 328, 329, 379–381, 389 Appreciative inquiry, 136, 231 Archetypes of failure, 379 Assertion, 348 Assessment of one’s effort, 187 Attitude, 389 Audit, 168, 185 Authenticity, 375 Authority, 338, 342 Award criteria, 242 Axiom theory, 286

B Backlog product, 142 sprint, 172

Backward scheduling, 158 BANI model, 2 Basic needs, 251 BATNA principle, 355, 447 Belbin, 31, 303, 382 blind spot, 383, 384 team report, 383 team role, 303, 328, 382, 450, 453 team role report, 305 Belonging, 274 Best‐in‐market, 79 Bionics, 231 Blind spot, 295, 383, 384 Body, 92, 112, 339 Brain, 233, 248 Brainstorming, 224 Brainwriting, 226, 227 Break‐even analysis, 159, 191 Buffer, 153 Burndown chart, 175, 370 Burnout, 268 Business case, 56, 59, 60, 137 Business handover, 203 Business organisation, 203

C Capacity planning, 157 Catalogue of requirements, 146 Cause-effect analysis, 115–117 Certification, 461 Certification model, 41 Change, 24, 191, 326, 394, 395 formula, 398 level, 396 management, 192 process model, 401 project, 24, 394 readiness, 399

# Springer-Verlag GmbH Germany, part of Springer Nature 2023 J. Kuster et al., Project Management Handbook, Management for Professionals, https://doi.org/10.1007/978-3-662-66211-3

467

468 Change request, 195 Change request management, 192 Character strength, 306, 307 Check, 168 Circle of competence, 277 Claim management, 191, 195, 349 Coaching, 299, 308, 316 Coherence, 274 Cohesion, 369 Cold conflict, 427 Collegial leadership, 327, 387 Commissioning phase, 201 Committee, 95, 97, 101, 204, 289, 422 Communication, 165, 451 codex, 359 concept, 9, 30, 81, 139, 166 cycle, 289 matrix, 166 square, 286 Communication square appeal, 286 content, 286 relationship, 286 self-revelation, 286 Compass, 50 Competence, 94 leadership, 245 methodological, 245 moderation, 357 negotiation, 245 self-competence, 245 technical, 246 Competence area, 10 context, 10 people, 11 practice, 11 Competence model, 100, 245 Competence profile agile project, 94 traditional project, 100 Competence regulation, 109 Complexity, 5, 373 Compliance, 10, 114, 118 Composition of team, 364 Concept phase, 21, 138 Concurrent engineering, 24 Conduct negotiations, 344, 351 Confidence, 281, 324, 381 Configuration portfolio, 209, 210 Conflict, 199, 412 approach-approach, 423 approach-avoidance, 424 avoidance-avoidance, 424

Index cold conflict, 427 conflict of interest, 420, 448 conflict of values, 426, 453, 454 diagnosis, 427, 431 displaced, 428 distribution, 420, 448 escalation stage, 431 evaluation, 421, 449 goal, 420, 447 Harvard concept, 443 hot, 427 latent, 427 layer model, 434 management, 412, 438, 443 organisational, 420, 449 personal, 423, 450, 451 prevention, 455 procedure, 449 relationship, 424, 451–453 resolution, 447, 455 resource, 420, 448 role, 422, 449 skills, 456 social, 451–453 structural, 420, 449 symptom, 418 syndrome, 417, 418 Conflict style, 429 Confrontation, 429 Constellation, 372, 392 Context, 10 Context analysis, 113 Contract by private treaty, 241 Controlling, 102, 178, 215, 353, 370 Control of results, 216 Cooperation, 3, 22, 29, 33, 34, 313, 378 level of cooperation, 29, 31, 81, 309, 415 tool, 166 Cooperative conflict resolution, 439 Coping strategy, 267, 268 Cost control, 187, 189 Cost plan, 53, 163 Cost transparency, 190 Courage, 267, 307, 327 CR, 192 Creativity, 37, 223 domain, 38 field, 38 human, 38 technique, 37, 73, 223 Credit, 273 Crisis, 457 Critical path, 153

Index Critical success factor (CSF), 64 Critical thinking appraisal, 303 Culture, 259 Cynefin framework, 27

D Daily stand-up/daily scrum, 52, 145, 175, 368 Data protection, 118 Deadline control, 187, 189 Decision, 305 Decision making, 60 Definition of done, 144 Delegation, 334 Delegative leadership style, 320 Deliverable, 53, 121, 125, 130, 152, 201, 449 Delphi-method, 150 Deming circle, 136 Design thinking, 136, 228 Design‐to‐cost, 79, 159 Detailed objective, 69, 71 Detailed planning cost plan, 53 resource plan, 53 schedule, 53 Deutsche Gesellschaft für Projektmanagement (GPM), 42 Developer, 326 Development project, 9 Dialogue procedure, 237 Dilemma, 267, 268, 275, 364, 423, 451 DIN 69901, 46 Directive leadership style, 320 Displaced conflict, 428 Disruption, 456 Distribution conflict, 420, 448 Documentation, 165 Downside strategy, 311 Draft contract, 242 Dynamic payback method, 191 Dynamics in teams, 366 adjourning, 371 forming, 366 norming, 369 performing, 370 storming, 367

E Earned‐value‐analysis, 180 Economic efficiency, 60, 190, 204 Economic viability, 137, 169, 185 Efficiency, 102 Effort estimation, 147, 150, 151, 279

469 Elimination criteria, 71 Empowerment, 338, 372 End review, 186 Environment analysis, 113, 184 Epic, 143 Escalation stages, 431 Estimate, 53 Estimation accuracy, 155 Evaluation conflict, 421, 449 Exclusion criteria, 235 Existential anxiety, 398 Expert estimation, 150 External assessment, 305 External control, 33, 34, 36, 273 Extreme programming, 14 Extrinsic motivation, 272 Eye of competence, 10, 42, 461

F Facilitation, 355 Fail fast, 285 Failure, 283 Failure mode and effects analysis (FMEA), 86, 88 concept, 90 design, 90 process, 90 product, 90 production, 90 system, 90 Feedback, 293 Feedback rules, 295 Final project appraisal, 203 Find consensus, 314 Fishbone method, 115 Focus, 8, 12, 16, 50, 74, 141, 171, 175, 218, 322, 327, 419, 443 customer’s view, 230 topic, 143 user focus, 27 Follow-up, 186 Forming, 366 Framework condition, 70, 74, 235 Frustration tolerance, 457 Future orientation, 283

G Gantt chart, 153 Generations Y, Z, and alpha, 262 Global objective, 68, 69 Goal conflict, 420, 447 Goal orientation, 3 Going live, 201

470

Index

Golden profiler of personality (GPOP), 302, 305 Governance, 5, 10, 118, 217, 221 Grooming, 176

Kano model, 75 Key performance indicators (KPIs), 64 Kick-off, 34, 131–133 Knowledge, 250, 251

H Harmony, 365 Harvard concept, 350, 353, 443 Hazard analysis and critical control points (HACCP), 86 Hermes, 41, 45, 70 Hierarchies in project management product management, 10 programme management, 9 project portfolio, 9 High performance team, 381 Hot conflict, 427 Hybrid model, 27 Hybrid project management, 23, 27, 49, 102

L Large Scale Scrum (LeSS), 14, 18 Latent conflict, 427 Lateral leadership, 321 Layer model, 434 Leadership, 314, 317, 327, 400, 452 competence, 95, 100, 245, 315, 316 continuum, 111 different forms of leadership, 316, 317 lateral leadership, 321 skills, 391 work, 317 Leadership model collegial leadership, 327 delegative leadership, 319 directive leadership, 319 lateral leadership, 321 leading with goals, 331 positive leadership, 323 remote leadership, 325 self-organisation, 326 situational leadership model, 319, 321 Leadership style, 317 delegative leadership style, 320 directive leadership style, 320 integrative leadership style, 320 participative leadership style, 320 Lean change cycle, 410 management, 16 portfolio management, 217, 218 six sigma, 136 Learning, 25, 37, 68, 171, 177, 326, 331, 379, 380, 410 Learning anxiety, 398 Legislation, 118 Level of change, 396 Level of cooperation, 29, 31, 81, 309, 415 Life‐cycle‐cost, 159, 190 Line organisation, 47, 92, 104, 248, 313, 339, 344, 372, 420, 449, 452 Lived role, 374, 450 Living world, 301 Logic factual, 399 psycho, 399 Lose-lose, 433

I Iceberg model, 356 Impact analysis, 195 Improvement project, 9 Inclusion, 262 Increment, 16, 173, 176 Individual competence baseline (ICB), 41, 461 Influence organisation, 105 Information, 165 Information security, 118 Initialisation phase, 20, 61 Innovation project, 9 Integrative leadership style, 320 Integrity, 11, 38, 118 Interaction, 31, 459 International Project Management Association (IPMA), 10, 41 certification, 461 competence area, 10 Intrinsic motivation, 272 Introduction phase, 21, 197 INVEST characteristics, 144 Invitation procedure, 241 Ishikawa diagram, 116 ISO 21500, 46

K Kanban, 14, 17, 155 Kanban board, 23, 173

Index M Magic triangle, 78 cost, 78 scope, 78 time, 78 Management by objectives (MbO), 331 Management task, 94 Mandatory objective, 71 Matrix project organisation, 107 Maturity level employee, 320 project management, 4 Meaning, 141, 262, 271, 273, 283, 307, 324 in life, 274 of life, 274 Mechanistic world view, 33 Meta communication, 290 Meta mirror, 354, 445 0/100 method, 187 Methodological competence, 95, 100, 245 Milestone, 53 plan, 120, 121 Milestone trend analysis (MTA), 181 Mind change, 396 Mind mapping, 226 Mindset, 385, 389 Mission, 219, 220, 236 Moderation, 355, 356 Moderation competence, 357 Moderation phases, 357 Moderation preparation, 358 Moderation responsibility, 357 Monochronic organisation culture, 387 Morphological box, 230 MoSCoW prioritisation, 76 Motivation, 246, 271, 335, 400 extrinsic, 272 intrinsic, 272 Multicultural cooperation, 387 Multiple interaction, 33 Multiple roles, 112 Multiplier method, 149 Multi-project management, 47, 161, 206, 448 element, 207 problem field, 207 task field, 207 Must-have objective, 71 Myers-Briggs Type Indicator (MBTI), 31, 305

N Needs, 228 Negotiated procedure, 241

471 Negotiation, 11, 66, 78, 161, 344, 391, 408, 443 competence, 245 Harvard concept, 353 skills, 95, 100 strategy, 347, 350, 353 tactics, 350 Net present value method, 190 Network orientation, 282 Neuroplasticity, 245, 248 Nice-to-have objective, 72 Non-objective, 67 Non-recurring costs, 190 Non‐trivial system, 34 Norming, 369

O Obedience anticipatory, 416 Objective, 66, 113, 118, 125, 146, 184, 219, 457 contradictive, 71 detailed, 69 essential, 71 global, 69 mandatory, 71, 235 must-have, 71 nice-to-have, 72 non-objective, 67 optimisation, 72, 235 process, 70 rough, 69 SMART, 71, 447 system, 69, 125 OKR, 332 Openness, 283, 326, 333, 390, 405 Open procedure, 241 Operating processes, 203 Opportunity, 84 Optimisation criteria, 72, 235 Optimisation objective, 72 Optimism, 281 Oral communication, 166 Order clarification, 114 Order processing project, 9 Organisational conflict, 420, 449 Organisational constellation, 392 Organisational culture, 259, 260 Organisational form matrix project organisation, 107 project coordination, 105 pure project organisation, 106 Organisational framework, 321

472 Organisation culture monochronic, 387 polychronic, 387 Orientation, 274 Overall project, 123

P 1-pager, 59 Participative leadership style, 320 PDCA circle, 136 People, 11 Percentage method, 149 Performing, 370 PERMA model, 323, 359, 381 Personal communication, 400 Personal conflict, 423, 450, 451 Personal framework, 321 Personality typology, 302 Personal responsibility, 282 Personal self-knowledge, 303 Perspective, 10 Phase concept, 18, 21, 138 initialisation, 20, 61 introduction, 21 plan, 121, 178 project commissioning, 19, 56 realisation, 21 report, 140 Pilot series, 201 Pilot test, 201 Pink zone, 385 Pioneering project, 6, 9 Planned and actual costs, 163 Planning, 120, 145, 155 horizon, 118 poker, 148 style, 387 Plus and minus list, 196 PMBOK® Guide, 43 Polarity, 390 Polychronic organisation culture, 387 Portfolio, 214 board, 60, 178, 209 configuration, 209, 210 management, 167, 206, 216, 217, 221, 461 manager, 41 mix, 207 planning, 60 Position, 372 Positive leadership, 323, 325, 381 Positive psychology, 306, 381

Index Potential of conflicts, 419 Potential project, 6 Power, 338, 400 borrowed, 341 institutional, 340 personal, 340 user, 202 Practical examples, 53 Practice, 11 Prefrontal cortex, 249 Preparing operation, 203 Prevention, 455 PRINCE2, 44 Priority classification, 210 Probability of occurrence, 85 Problem solving process, 133 Procedural principle, 12 agile, 27 hybrid, 27 from rough to detailed, 12 traditional, 27 variant formation, 13 Procedure conflict, 449 Procedure principle phase structure, 120 problem solving process, 133 Process objective, 70, 335 Procurement, 237 Product backlog, 16, 49, 68, 72, 74, 97, 138, 142, 145, 147, 171, 175, 191, 200, 203, 238, 458 Product concept, 65, 68, 138, 141, 458 Product goal, 17 Product management, 10 Product owner, 16, 94, 95, 97, 142, 146, 276, 326, 344, 447, 458 Product vision, 29, 49, 132, 141 Profitability, 190, 211, 396 Programme evaluation and review technique (PERT), 151 Programme management, 9, 47, 218, 461 Programme manager, 41 Progress monitoring, 216 Project assessment, 184, 186 Project change, 191 Project body, 313 Project characteristics, 5 acceptance project, 6 pioneering project, 6 potential project, 6 standard project, 6 Project classification, 5 Project commissioning phase, 19, 56

Index Project committee, 71, 95, 98, 101, 178, 182, 184, 186, 328, 330, 421, 422 agile project, 97 traditional project, 101 Project communication, 166, 167 Project completion, 203 Project control, 21, 178, 179 Project coordination, 105 Project culture, 260, 261 Project definition, 3 Project director, 41 Project documentation, 166 Project factsheet, 20, 56, 59, 60 Project information, 166, 167 Projection, 453 Project list, 210 Project management, 8 agile project management, 14, 27, 49, 94, 141, 142, 145, 148, 172, 175–177, 238, 326, 339, 342 dimensions in project management, 10 hybrid project management, 23, 27, 49, 102 traditional project management, 18, 27, 49, 341 Project management compass, 50 Project management guideline, 221 Project management handbook, 221 Project Management Institute (PMI), 43 Project management methodology, 456 Project management office (PMO), 220, 221 Project management plan, 129 Project management standard, 41 Project manager, 41, 94, 95, 101, 337, 344, 458 Project manual, 129 Project marketing, 82, 166 Project objective, 66, 70, 71 Project order, 20, 29, 35, 60, 62, 69, 71, 94, 101, 113, 128, 141, 184, 276, 317, 340, 344, 421, 447, 448 Project organ, 93, 317 Project organisation, 90, 100 Project owner, 15, 97, 101, 196, 337, 447 Project phase, 53 Project planning, 120, 145, 155 Project portfolio, 9, 35, 42, 47, 56, 61, 89, 206, 209, 210, 215, 216, 220, 373, 400, 420, 448, 450 Project proposal, 56, 60 Project request, 21, 59, 190 Project staff, 41 Project steering, 184 Project strategy, 79 Project structure plan (PSP), 125

473 Project structuring, 120 Project team, 95, 102 Project types, 7, 365 Project typology, 5 Projekt Management Austria (PMA), 42 Protection needs analysis, 118 Psychological safety, 258, 378, 381 Psychological stress, 264 Pure project organisation, 106 Purpose, 250, 329, 335, 379, 381, 400

Q Quality gate review, 186 Quality management, 167, 168 Quality of the relationship, 289 Quality planning, 168 Question active listening, 298 circular, 300 closed, 297 goal-oriented, 300 heart, 300 hypothetical, 300 open, 297 resource-oriented, 300 scale, 300 Questioning technique, 297

R RACI matrix, 109, 415, 449 Radical collaboration, 385–387 Ranking, 452 Realisation phase, 21, 170 Realistic assessment of economic efficiency, 190 Recognition, 30, 301, 368, 371, 413, 453 Red zone, 385 Refinement, 176 Refreeze, 24 Reiss motivation profile, 303 Relationship, 338 Relationship conflict, 424, 451–453 Release plan, 49, 138, 145, 458 Remote leadership, 325 Reporting, 166, 179, 181, 317 Reporting in multi-project management, 215 Request for information (RFI), 241 Request for proposal (RFP), 241 Request for quotation (RFQ), 241 Requirement, 66, 69, 72, 400 catalogue, 69, 138

474 Requirement (cont.) engineering, 72 framework condition, 74 functional requirement, 73 non‐functional requirement, 73 prioritisation of requirements, 74 specification, 69, 146 Reserves, 151 Resilience, 280 Resilience factor, 281 acceptance, 281 future orientation, 283 network orientation, 282 optimism, 281 personal responsibility, 282 self-efficacy, 282 solution orientation, 283 Resistance, 3, 172, 199, 394, 399, 403, 410, 418, 429 dealing with resistance, 406 forms, 405 Resource availability, 213 Resource conflict, 420, 448 Resource control, 189 Resource coordination, 159 Resource dependency, 213 Resource deployment plan, 159 Responsibility, 97, 109 moderation, 357 project committee, 97 project manager, 101 project owner, 97, 101 scrum master, 97 Retrospective, 177, 199 Return on Investment (ROI), 190 Review, 112, 123, 168, 185, 199, 216 Review board, 101 Risk, 85 impact, 195 list, 88 management, 84, 285 management tool, 88 probability of occurrence, 85 process, 84 severity, 85 Role, 92, 95, 97, 101, 372, 375, 422 adoption, 376, 422 carrier, 374 conflict, 422, 449 lived role, 374, 450 sender, 374 Rough objective, 69 Rough planning, 120, 145, 157

Index S Scaled Agile Framework (SAFe®), 14 Scamper, 227 Scenario‐technique, 118 Schedule, 152 Scheduling, 157 Schulz von Thun, F., 286, 299 Scope, 15, 29, 73, 78, 130, 146, 195, 198, 220, 344, 400, 412 Scope creeping, 416 Scrum, 16, 49, 141, 142, 145, 172, 175–177, 326 Scrum alliance, 41, 46 Scrum master, 16, 36, 94, 95, 97, 173, 175, 177, 276, 317, 326, 339, 371, 376, 422, 449, 458 Scrum team, 31, 36, 94, 142, 147, 172, 177, 270, 286, 326, 338, 423, 449 Selective perception, 254, 289 Selective procedure, 241 Self assessment, 305 competence, 95, 100, 245 control, 34, 338, 438 development, 252 direction, 33, 34 efficacy, 276, 282 esteem, 253 leadership, 327 management, 275, 276 organisation, 17, 33, 34, 94, 95, 170, 326 Serial production, 197, 201 Severity, 85 Significance, 274 Simultaneous engineering, 24 Situational leadership model, 319, 321 Situation analysis, 113 Slack, 153 Small project, 9 SMART, 71 Social competence, 95, 100 Social conflict, 451–453 Solution concept, 138, 146 finding, 223 orientation, 283 selection, 223 variant, 138 Sounding board, 101 Sources of power, 339 Specification, 69, 146 Sprint backlog, 173 Sprint implementation, 175

Index Sprint planning, 145, 172, 173 Sprint review, 16, 97, 176, 339, 370 Stacey matrix, 27 Stakeholder, 228 analysis, 79 management, 79 Standard project, 6 Steering committee, 101 agile project, 97 traditional project, 101 Steering group, 101 Storming, 367 Story points, 148 Strategy implementation, 218 Stress amplifier, 265 Stress competence, 265, 266 instrumental, 266 mental, 266 regenerative, 266 Stressor, 255, 263, 265 Stress response, 263, 264, 268, 451 Stress traffic light, 265 Structural conflict, 420, 449 Sub-project, 120, 123 Sub-project manager, 102 Substitute satisfaction, 428 Success factor, 64, 216, 303 Suggestions for improvement, 177 Suitability criteria, 242 Swiss ICB, 461 SWOT analysis, 114 Synectics, 231 Systemic approach, 35 Systemic phenomenon, 414 Systemic world view, 33 System objective, 69, 125, 335

T Target agreement, 332 Target costing, 159 Target pyramid, 346 Target setting, 332 Task, 101, 123, 125, 317 Task force, 106 Task performance process (TCR), 331 Tasks, authorities and responsibilities (TCR), 337 Tasks of the project committee, 184 Tasks of the project manager, 184 Tasks of the project owner, 184 Taylorism, 1, 32, 245 Taylor tub, 1

475 Team, 98, 363, 364 agile project, 326 competence, 95, 100 development, 96, 293, 366, 370, 372, 400 frame, 322 report, 383 role, 172, 303, 382, 450, 453 role report, 305 work, 29 Technical competence, 246 Technical specification, 138 Tender, 239 Testing, 168 Timebox, 16 Time management, 278–280 Time management matrix, 279 Time‐to‐market, 79 T-profile, 229 Traditional project management, 18, 27, 94, 100, 138, 146, 152, 159, 167, 178, 191, 239, 339, 341 Transformation, 395 Transparency, 84, 129, 165, 174, 175, 217, 316, 323, 327, 330, 333, 368, 405 Triple constraint, 78 Trivial system, 34 Trust, 329, 336, 342, 351, 369, 373, 390, 410, 439, 442, 456 T-shirt sizing, 149 Tuckman, B., 366 Type of conflict, 419 Type of introduction, 200

U Unfreeze, 24 Upside strategy, 311 User manual, 202 User training, 202 Utilisation phase, 22

V Value-risk matrix, 76 Verein zur Zertifizierung von Personen im Management (VZPM), 42 Versatility, 37 Version concept, 25 VIA character strength, 303, 306, 307 Virtual team, 359 Vision, 29, 49, 68, 78, 132, 136, 141, 219, 220, 236, 329, 410, 420

476 V‐model, 24 VUCA, 3, 262, 403

W Willingness to cooperate, 400 Willingness to shape, 400 Win-lose, 433 Win-win, 432 Wish objective, 72 Work breakdown structure, 53, 120, 121, 125 Work group, 363, 364 Work in the system, 29, 33, 316, 367, 370, 390 content, 29 Workload, 162

Index Work on the system, 30, 34, 36, 280, 316, 368, 390 organisation, 30 relationship, 30 Work package, 121, 123, 130, 152, 449 Workplace big five, 303 Work technique, 278–280 World view mechanistic, 32 systemic, 32 WPB5, 303 W-questions, 298

Z Zone of strength, 308