Project Management (IPMA®) E-Book

Karen Dittmann

• Herausgeber: Haufe Lexware
• Kategorie: Fachliteratur
• Serie: Haufe Fachbuch
• Sprache: Englisch

Seitenzahl: 479

Veröffentlichungsjahr: 2024

Beschreibung

The book contains the complete learning content for the IPMA® Level D Certification as well as the GPM Basic Certificate. It offers numerous examples, templates for project management methods and practical tips. It also aims to convey the joy of project management, which – when carried out professionally – is probably one of the most versatile and exciting professions imaginable. The IPMA® (International Project Management Association) defines global standards for professional project management. The three competence areas of the current standard ICB4.0 (Individual Competence Baseline) Perspective (context), People (personal and social) and Practice (methods and technical) provide the certification framework for project managers. The competence-based approach of IPMA® enables the transfer into practice and goes beyond the pure knowledge acquisition of other certifications solely based on tools and methods. In this way, the transfer to everyday project management can be managed successfully. Contents: - Project context: how projects are embedded in companies, what legal regulations need to be considered, the role of organizational culture in project implementation  - People in the project: personal and social skills for project managers, how to design projects with people for people - Methods and techniques: from requirements analysis to performance, resource, time and cost planning through to project controlling and project closure All topics are explained for both classical (plan-based) and agile project management and how to combine these two approaches (hybrid). New in the 2nd edition: - Modernized German standard of the current ICB 4 (valid from 01.01.2024) - Coverage of agile and hybrid project management - Continuous project examples as an aid for writing the Level D report

Leseprobe

Inhaltsverzeichnis

InhaltsverzeichnisHinweis zum UrheberrechtmyBook+ImpressumWelcome to the book!1 Competence Area »Perspective« (Context)1.1 CE Strategy (4.3.1)1.1.1 Mission, Vision and Strategy1.1.2 Standard Success Factors of a Project1.1.3 Business Case1.1.4 Benefit-Cost Analysis1.2 CE Governance Structures and Processes (4.3.2)1.2.1 Temporary Projects1.2.1.1 The Term «Project « 1.2.1.2 The Term «Project Management «1.2.1.3 Project Types 1.2.1.4 Project Classes1.2.2 Permanent Systems and Structures1.2.2.1 Functional Organization1.2.2.2 Steering Committee1.2.2.3 Project Management Office (PMO)1.2.3 Projects, Programs and Portfolios1.2.4 Process and Structural Organization of Projects1.2.5 Project Management Manual 1.2.6 Project Management Standards1.2.7 Project Management Regulations1.3 CE Compliance, Standards and Regulations (4.3.3)1.3.1 Data Protection and Data Security1.3.2 Regulations for Safety, Health and Environmental Protection1.3.3 Hazard Analysis1.3.4 Compliance Requirements of Individual Economic Sectors1.3.5 Corporate Social Responsibility (CSR)/Sustainable Corporate Management 1.3.6 Agenda 20301.4 CE Power and Interests (4.3.4)1.4.1 Definition of Power1.4.2 Promoter Model according to Witte1.4.3 Force Field Analysis1.5 CE Culture and Values (4.3.5)1.5.1 The GPM Code of Ethics1.5.2 Aligning the Project with the Culture and Values of an Organization (according to Edgar Schein)1.5.3 Traditional versus Agile Values1.5.3.1 Traditional Values1.5.3.2 Agile Mindset2 Competence Area »People« (Personal + Social)2.1 CE Self-Reflection and Self-Management (4.4.1.)2.1.1 Methods for Self-Reflection2.1.1.1 5-Finger Method2.1.1.2 Personal SWOT Analysis or Strengths and Weaknesses Analysis2.1.1.3 Self-Reflection Based on the Role in the Project2.1.2 Self-Management Methods2.1.2.1 Eisenhower Matrix2.1.2.2 Getting Things Done2.1.3 Project Management and Stress2.1.4 Personal Competence Development in Project Management2.1.4.1 Career Planning in Three Approaches2.1.4.2 The IPMA® 4-Level Model 2.2 CE Personal Integrity and Reliability (4.4.2)2.2.1 Reliability and Trust2.2.2 Error Culture2.2.3 Sustainability2.3 CE Personal Communication (4.4.3)2.3.1 Communication Models2.3.1.1 Iceberg Model2.3.1.2 Sender-receiver Model (Shannon/Weaver)2.3.1.3 Five Axioms of Communication (Watzlawick)2.3.1.4 Communication Square (Schulz von Thun)2.3.2 Receiving Information: Active Listening2.3.3 Questioning Techniques 2.3.4 Communication and Disturbance of Perception2.3.5 Meetings 2.3.5.1 Meeting Types2.3.5.2 Recommendations for Conducting Meetings2.3.5.3 Protocols2.3.6 Communicating Effectively with Virtual Teams2.3.6.1 What is different in Virtual Teams?2.3.6.2 Netiquette2.3.6.3 Online Conferences2.3.6.4 Emails2.3.6.5 Best Practices2.4 CE Relationships and Commitment (4.4.4)2.4.1 Building and Maintaining Personal Relationships2.4.1.1 Exploring the Interests of Others2.4.1.2 Self-Determination Theory According to Deci and Ryan2.4.1.3 Motivation Continuum2.4.2 Professional Network (Business Network)2.5 CE Leadership (4.4.5)2.5.1 Leadership Styles, Leadership Techniques, Leadership Tools2.5.2 Leadership Styles2.5.2.1 Theory of Situational Maturity2.5.2.2 Lateral Leadership2.5.3 Leadership Techniques2.5.4 Decision Making2.6 CE Teamwork (4.4.6)2.6.1 Success Factors for Teamwork2.6.2 Team Rules2.6.3 Special Team Effects2.6.3.1 Groupthink2.6.3.2 Risk Shifting2.6.3.3 Social Loafing2.6.4 Teamwork Models2.6.4.1 Tuckman’s Team Clock2.6.4.2 Belbin’s Team Roles2.6.5 Feedback Guidelines2.7 CE Conflicts and Crises (4.4.7)2.7.1 Symptoms of Conflict2.7.2 Causes of Conflict2.7.3 Cooperative Conflict Resolution2.8 CE Resourcefulness (4.4.8)2.8.1 An Open and Creative Meeting Environment2.8.2 Problem Solving2.8.2.1 Analyzing Problems2.8.2.2 Creativity and Creativity Techniques2.8.2.3 Problem Solving Process2.8.2.4 Problem Solving Strategies2.8.2.5 Four Phases of Creativity as a Process2.9 CE Negotiation (4.4.9)2.9.1 Overt and Covert Negotiations2.9.2 Conducting a Negotiation2.9.3 Determining Needs as a Basis for Conducting Negotiations2.10 CE Result Orientation (4.4.10)2.10.1 Connection to Project Management Subfields2.10.2 Efficiency and Effectiveness2.10.3 Project Marketing2.10.4 Results Orientation in Practice3 Competence Area »Practice« (Methods + Technical)3.1 Plan-based, Hybrid, Agile3.2 Initialization3.2.1 Documents in the Initialization and Definition Phase 3.2.1.1 The Business Case (4.3.1)3.2.1.2 Vision (4.5.1)3.2.1.3 Big Picture (4.5.1)3.2.1.4 The Project Profile (4.5.2, 4.5.10)3.2.1.5 The Project Order (4.5.2, 4.5.10)3.2.1.6 Project Manual (4.5.1, 4.5.5)3.3 Definition3.3.1 Requirements and Objectives (4.5.2)3.3.1.1 Functions of Objectives3.3.1.2 Defining Project Objectives3.3.1.3 Representation of Objective Classes3.3.1.4 Carefully Formulate and Operationalize Objectives3.3.1.5 Objectives and Acceptance Criteria3.3.1.6 Identifying Objectives ‒ Objective Process 3.3.1.7 Recognizing Objectives Compatibility3.3.1.8 Symptoms of Inadequate Objective Definition3.3.1.9 Agile Requirements and Objectives (4.5.2)3.3.2 Project Design (4.5.1)3.3.2.1 Step 1: Define Success Criteria3.3.2.2 Step 2: Determine Success Factors3.3.2.3 Step 3: Lessons Learned3.3.2.4 Step 4: Determine Project Type and Project Class3.3.2.5 Step 5: Select and Adapt Implementation3.3.2.5.1 Waterfall Process Model3.3.2.5.2 Agile Software Development (Incremental)3.3.2.5.3 Kanban3.3.2.6 Step 6: Design and Project Manual3.3.2.7 Step 7: Verification3.3.2.8 Project Success 3.3.3 Phase Planning (4.5.4)3.3.3.1 Elements of Phase Planning3.3.3.2 Levels of Phase Planning3.3.4 Starting the Project and Obtaining Approval (4.5.10)3.3.4.1 Creating a Project Plan3.3.4.2 Project Startup Workshop3.3.4.3 Project Kick-off3.3.4.4 Project Start in Agile Projects3.3.5 Project Organization (4.5.5)3.3.5.1 Funcional Prroject Organization3.3.5.2 Pure or Autonomous Project Organization3.3.5.3 Matrix Project Organization3.3.5.4 Agile Project Organization Form3.3.5.5 Comparison of Project Organization Forms 3.3.5.6 Project Roles in the Team (TCR)3.3.5.7 Project Roles and Definition of Responsibilities (RACI matrix)3.3.5.8 Principle of congruity in the Definition of Roles3.3.6 Project Documentation (4.5.5)3.3.6.1 Document Standards 3.3.6.2 Documentation obligation3.3.6.3 Types of Information Visualization3.3.6.4 Organizing Project Documents3.3.7 Stakeholders (4.5.12)3.3.7.1 Project Environment Analysis3.3.7.2 Stakeholder Analysis3.3.7.3 Stages of Stakeholder Management3.3.7.4 Methods and Influence3.3.7.5 Stakeholder Measures in Agile Projects3.3.8 Opportunities and Risks (4.5.11)3.3.8.1 Definition3.3.8.2 Risk Management Objectives3.3.8.3 One- and Two-Dimensional Risk Assessment3.3.8.4 Sector-specific Risk Assessment3.3.8.5 Risk Analysis Process3.3.8.6 Identification of Risks3.3.8.7 Qualitative Risk Analysis3.3.8.8 Risk Description3.3.8.9 Classification of Risks3.3.8.10 Quantitative Risk Analysis3.3.8.11 Strategies for Dealing with Risks and Opportunities3.3.8.12 Failure Mode and Effects Analysis (FMEA)3.4 Detailed Planning3.4.1 Scope and Deliverables (4.5.3)3.4.1.1 Requirements for Delivery and Performance3.4.1.2 Documents describing scope 3.4.1.3 Work Breakdown Structure (WBS)3.4.1.4 Project Structuring 3.4.1.5 Delimitation of Objectives and Scope3.4.1.6 Defining Work Packages3.4.1.7 Structuring Requirements in an Agile Way3.4.1.8 Agile Performance Definition3.4.2 Process and Time Planning (4.5.4)3.4.2.1 Activity List 3.4.2.2 Network Diagram3.4.2.3 Logical Relationships3.4.2.4 Floats3.4.2.5 Gantt Chart/Bar Chart3.4.2.6 Traditional Scheduling3.4.2.7 Agile Scheduling3.4.2.8 Hybrid Scheduling3.4.3 Resources (4.5.8)3.4.3.1 Resource Types3.4.3.2 Estimating Expenses3.4.3.3 Effort, Duration and Workload3.4.3.4 Load Resources3.4.3.5 Optimizing Resources3.4.3.6 Agile Resource Planning3.4.4 Costs and Project Financing (4.5.7)3.4.4.1 Cost Planning 3.4.4.2 Cost Accounting3.4.4.3 Presenting and Reporting Project Costs 3.4.4.4 Agile Cost Planning3.5 Steering3.5.1 Managing Transitions to a New Phase/Section (4.5.10)3.5.2 Managing Transitions to a New Iteration/Section – Agile (4.5.10)3.5.3 Determining Project Progress (4.5.10)3.5.4 Determining Project Progress in an Agile Environment (4.5.10)3.5.5 Compare Project Plan with Actual Data (4.5.10)3.5.5.1 Earned-Value Analysis3.5.5.2 Cost Forecasts and Cost Trend Analysis (KTA)3.5.5.3 Milestone Trend Analysis (MTA)3.5.6 Reports (4.5.10)3.5.6.1 Status Report 3.5.6.2 Closure Report 3.5.6.3 Experience Reports3.5.7 Change Management (4.5.10)3.5.8 Quality (4.5.6)3.5.8.1 Quality Management Objectives3.5.8.2 Quality Plan: Develop a Quality Plan for the Project3.5.8.3 The Continuous Improvement Process3.5.8.4 Quality Assurance in Agile Projects3.5.9 Procurement (4.5.9)3.5.9.1 Relevant Contract Types for Projects (Civil Law)3.5.9.2 Contract Management3.5.9.3 Make-or-Buy Decisions3.5.10 Change and Transformation (4.5.13)3.6 Closure (4.5.10)3.6.1 Product Acceptance 3.6.2 Closure Analysis and Evaluation3.6.3 Project Evaluation (Lessons Learned)3.6.4 Project Dissolution3.6.5 Project Closure in Agile ProjectsList of Technical Terms German-English/English-GermanAbout the authorsReferencesIhre Online-Inhalte zum Buch: Exklusiv für Buchkäuferinnen und Buchkäufer!Stichwortverzeichnis

Buchnavigation

InhaltsubersichtCoverTextanfangImpressum

[1]

Hinweis zum Urheberrecht

Alle Inhalte dieses eBooks sind urheberrechtlich geschützt.

Bitte respektieren Sie die Rechte der Autorinnen und Autoren, indem sie keine ungenehmigten Kopien in Umlauf bringen.

Dafür vielen Dank!

myBook+

Ihr Portal für alle Online-Materialien zum Buch!

Arbeitshilfen, die über ein normales Buch hinaus eine digitale Dimension eröffnen. Je nach Thema Vorlagen, Informationsgrafiken, Tutorials, Videos oder speziell entwickelte Rechner – all das bietet Ihnen die Plattform myBook+.

Ein neues Leseerlebnis

Lesen Sie Ihr Buch online im Browser – geräteunabhängig und ohne Download!

Und so einfach geht’s:

Gehen Sie auf https://mybookplus.de, registrieren Sie sich und geben Sie Ihren Buchcode ein, um auf die Online-Materialien Ihres Buches zu gelangen

Ihren individuellen Buchcode finden Sie am Buchende

Wir wünschen Ihnen viel Spaß mit myBook+ !

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.dnb.de abrufbar.

Print:

ISBN 978-3-648-16627-7

Bestell-Nr. 10621-0002

ePub:

ISBN 978-3-648-16628-4

Bestell-Nr. 10621-0101

ePDF:

ISBN 978-3-648-16629-1

Bestell-Nr. 10621-0151

Karen Dittmann/Konstantin Dirbanis

Project Management (IPMA®)

2. Auflage, April 2024

© 2024 Haufe-Lexware GmbH & Co. KG, Freiburg

www.haufe.de

[email protected]

Produktmanagement: Bettina Noé

Dieses Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte, insbesondere die der Vervielfältigung, des auszugsweisen Nachdrucks, der Übersetzung und der Einspeicherung und Verarbeitung in elektronischen Systemen, vorbehalten. Alle Angaben/Daten nach bestem Wissen, jedoch ohne Gewähr für Vollständigkeit und Richtigkeit.

Sofern diese Publikation ein ergänzendes Online-Angebot beinhaltet, stehen die Inhalte für 12 Monate nach Einstellen bzw. Abverkauf des Buches, mindestens aber für zwei Jahre nach Erscheinen des Buches, online zur Verfügung. Ein Anspruch auf Nutzung darüber hinaus besteht nicht.

Sollte dieses Buch bzw. das Online-Angebot Links auf Webseiten Dritter enthalten, so übernehmen wir für deren Inhalte und die Verfügbarkeit keine Haftung. Wir machen uns diese Inhalte nicht zu eigen und verweisen lediglich auf deren Stand zum Zeitpunkt der Erstveröffentlichung.

Welcome to the book!

This book is written for those interested in an introduction to project management. You can start with either an «IPMA Level D« course or the «Basic certificate (GPM)« course. The present textbook provides a basis for both courses. If you want to get a first impression or an overview of project management, you can simply read through it.

The basis for this book is the international project management standard of IPMA® in the current version of ICB4.0 (Individual Competence Baseline) as well as the further development of GPM from 2023. The international standard of ICB4.0 is divided into three competence areas. Accordingly, this book is also divided into these three competence areas and color coded accordingly:

Competence area Perspective (Context)

Competence area People (Personal and Social)

Competence area Practice (Methods and Technical)

The three competence areas mentioned above are further subdivided into different competence elements in the ICB. These competence elements (CE) have a standard numbering system in ICB4.0. We have adopted the standard numbering of the CE in this book and use it to identify the respective book chapters by announcing the CE abbreviations in brackets. This ensures that the contents of the book refer to the current version of ICB4.0. Read more about ICB4.0 and other project management standards in Chapter 1.2.6 Project Management Standards.

The IPMA® standard is hybrid. This means that it contains both traditional (plan-based) and agile (value-based) methods and capabilities. The terms «traditional« and «plan-based« are used interchangeably in this book. Traditional project management is a well-established, long-standing term that is not easily erased from the minds of project managers. Plan-based project management, on the other hand, is now the more accurate term, especially in contrast to agile project management, where detailed long-term plans tend to take a back seat.

Content related to agile or hybrid project management is marked with this symbol.

Text passages in italics without references are extracted from Motzel’s Project Management Lexicon or represent definitions by the authors. All other quotations are presented in italics with the source duly cited. Definitions are additionally marked in gray boxes.

We have integrated our extensive training experience into this book in terms of content, methodology and didactics. In this way, we aim to assist you in navigating the intricacies of project management.

The book’s download area offers numerous templates for practical use, serving as a foundation for your individual project work.

1 Competence Area »Perspective« (Context)

This chapter aims to define the external influences that impact a project. These influences can be organizational, social and/or political and must be considered in the context of the project work. Only those who are aware of these influences and interactions can use them in a structured way and react to them appropriately within their project work.

1.1 CE Strategy (4.3.1)

Projects and a company’s strategy are intricately linked. This is why the first competence element of ICB4 (GPM 2016) and the first chapter of this book deal with the subject of Strategy.

A company’s strategy is defined as its long-term market approach, which is aligned with its corporate objectives. The corporate strategy facilitates differentiation from competitors and emphasizes the company’s unique focus. It is divided into individual strategic objectives, which are implemented in the form of projects.

1.1.1 Mission, Vision and Strategy

Ideally, the mission describes the present, while the vision outlines a desired, ideal future state derived from the mission. The strategy is the long-term pathway (3–5 years) toward realizing the mission, while also taking the vision into consideration.

Mission Mission

«Assignment or purpose of a company or organization to a certain action or to achieve a goal. Deals with the question: What are we here for? What is our mission?« (Motzel)

The mission of a company constitutes its foundation. It describes its raison d’être and its purpose as a mandate to achieve its vision. The mission answers fundamental questions such as: Why does this company exist, what drives it in the long term and why does it make sense to maintain our company? What is its value proposition for the environment and clients? Without a conscious mission, vision and strategy become arbitrary.

Vision Vision

«A vividly described vision/desire for the future, serves as an orientation for all actions and decisions. It should create a positively motivated state and provide a direction with which the people of the organization can identify.« (Motzel)

The vision focuses on the future and answers the question of where the company/organization aspires to go. It specifies the ideal state to be achieved in the future. The core messages of a well-formulated vision address the following questions:

Who do we want to be?

What do we want to have done?

What clients/stakeholders problems do we want to have solved?

Where do we want our company/organization to be in the future (5–10 years)?

The first step in strategic management is to define the mission. It describes the current state until altered by the company. Based on this, the company formulates its vision, depicting a specific state that the company aspires to achieve in the future.

Both should provide orientation and direction. When mission and vision are aligned, they motivate employees and channel the company’s direction and activities toward a unified purpose.

Fig. 1:

Connection between a company’s mission, vision and strategy

Strategy [Ger. Strategie] Strategy

«Fundamental, long-term and documented behavior (combination of measures) that is planned to achieve the vision on the basis of the mission.« (Motzel)

A company’s projects should follow and align with its strategy. If projects diverge from the strategic management elements of an organization, this can lead to what is termed «value-destroying complexity«. A company’s strategic management is responsible for aligning strategic objectives with the projects to be implemented.

Examples:

If an automotive company that has only produced cars now also wants to produce motorcycles, according to the company’s strategy, either this project must be canceled or the strategy must be modified to accommodate this new direction.

If a pacifist consulting firm receives a contract from an arms manufacturer, the organization should make a conscious decision to either accept or reject the contract.

Before submitting a project to the portfolio board for approval (see Ch. 1.2.3 Projects, Programs and Portfolios), the client should assess the alignment between the project objectives and the corporate strategy by asking the following questions:

Are the success factors (see Ch. 1.1.2 Standard Success Factors of a Project) of this project supported by the company’s strategy?

Can the business case (see Ch. 1.1.3 Business Case) be aligned with the company’s strategy?

Which factors of the project context (see Ch. 3.3.7.1 Project Context Analysis) have their origin in the company’s strategy? Are there any contradictions between the environmental factors and the strategy?

It is the responsibility of both the client and the portfolio management to ensure that each new project supports the company’s vision. This is crucial to prevent execution of projects that do not contribute to the company’s overall success.

1.1.2 Standard Success Factors of a Project

Based on studies conducted by GPM (2007), the factors outlined in Fig. 2 are responsible for the success of projects. These factors are not universally present in companies. For example, it is not always possible to find qualified project staff who can contribute to the company’s success. In the author’s experience, these factors have remained consistent to date.

Fig. 2:

Standard success factors

The client and project manager should possess a thorough understanding of these standard success factors and assess their presence in their own company. If not, the project context must be adapted accordingly (e.g. enhancing the qualifications of the project staff) and the project plan must be adapted accordingly (e.g. setting up a comprehensive communication system in the case of a conflict-ridden organizational project).

In addition, it is the project manager’s responsibility to define further critical success factors (CSF) in collaboration with the client and to integrate them into the project design (see Ch. 3.3.2 Project Design (4.5.1)).

1.1.3 Business Case

The business case is created by the client during the initialization phase. It formulates the rationale for undertaking the project, or alternatively, why it would be impractical (in which case the project is not started). The business case must therefore always be intricately linked to the corporate strategy.

Business Case Business Case

«Business transaction with proof of the eligibility, objectives, benefits, and economic efficiency or profitability of a project. This proof is usually developed during project definition, continuously reviewed during project selection, and evaluated at the end of the project. The business case is based on the company or business unit strategy and project selection and includes the success and long-term consequences of a project.« (Motzel)

Fig. 3: Business case form

The business case always refers to the economic motivation for carrying out a project. This can be either the implementation of a strategic objective (as a basis for possible future sales) or the need for a specified change (external or internal) in the company, justified by legal or organizational requirements (so-called mandatory projects).

Examples:

Development of a new material or technology that can be used to open up new business areas or attract new clients in the future (additional sales);

Merging two purchasing areas in order to exploit cost effects (internal change);

Process or system adjustments to comply with new/changed laws, e.g. GDPR (external change).

1.1.4 Benefit-Cost Analysis

A benefit-cost analysis assists the client in identifying and qualitatively evaluating alternatives:

Should we implement software A or B?

Should we develop a component ourselves or buy it in?

Should we relocate our production from Germany to country A or to country B?

In contrast to a list of pros and cons, the decision criteria are not only listed, but also evaluated and weighted. The list of criteria in the benefit-cost analysis can include both economic and non-economic factors. It serves as the basis for a non-monetary decision based on several differently weighted factors.

Fig. 4:

Example of a benefit-cost analysis for the selection of new CRM software (Customer Relationship Management)

The effectiveness of a benefit-cost analysis depends on whether it contains the relevant criteria and reflects the perspective of key stakeholders. The relevant criteria must be evaluated either within the project team or by the person commissioning the analysis. The stakeholder analysis (see Ch. 3.3.7 Stakeholders (4.5.12)) is commonly employed for communication planning, which is usually only applied in the detailed planning phase. In connection with the benefit-cost analysis, it may be useful to prepare an initial version of the stakeholder analysis during the initialization phase. This approach allows stakeholders to contribute their perspectives to the benefit-cost analysis at an early stage of the project and at the same enabling the project team and manager to better assess their expectations and concerns.

In connection with the business case, the benefit-cost analysis servers as a vital tool for defining the scope and objectives of the project. The corporate strategy should in turn be considered in the criteria and weighting of the analysis.

Examples:

A company wants to increase its digitalization over the next three years. The user-friendliness criterion (see Fig. 4) is therefore weighted higher than the acquisition costs of the CRM system.

Another company needs to undertake a cost-cutting initiative for economic reasons. In this case, the criteria in the benefit-cost analysis will certainly be weighted higher in terms of costs than shown in Fig. 4.

1.2 CE Governance Structures and Processes (4.3.2)

This competence element (CE) describes structures, systems and processes of companies that impact their projects. It encompasses both temporary projects and permanent systems and structures (line organization). Acquiring knowledge of structures and processes helps project managers to comprehend their own projects, embed them into the company’ organizational context and effectively manage them.

1.2.1 Temporary Projects

1.2.1.1 The Term «Project « 

«Projects« are ubiquitous in everyday language. People discuss projects like «tidying up the apartment«, dedicate themselves to the project of «learning an instrument« or are involved in the project called «family«. But are these all real projects in a professional context?

We aim to refine the definition of projects and differentiate them from tasks. For processing tasks in the line organization, the discipline of project management would be an unnecessary overhead and uneconomical in a cost-benefit comparison. In contrast, for genuine projects, project management plays a pivotal role in ensuring success and achieving the desired results.

Popular Definition (from a company brochure)

A project is an initiative that:

is unique,

is complex,

has a limited duration,

requires the use of different resources (people, material resources, etc.)

Definition according to DIN 69901 Part 5

A Project [Ger. Projekt] is referred to as an «undertaking«, which is characterized by its uniqueness. The following characteristics are attributed to it:

Defined objectives

A time, financial, personnel or other limit

A project-specific organization. (PM4, GMP 2019)

Definition according to IPMA®/ICB4

«A Project is defined as a one-time, temporary, interdisciplinary, and organized endeavor to achieve fixed work results within the framework of predefined requirements and boundary conditions.« (GPM)

Characteristics of Projects

Summarizing the definitions provided, the following characteristics can be attributed to projects:

Novelty (Uniqueness)

Projects are unique undertakings. Reliance on existing knowledge is only partial. This uniqueness introduces increased risks and risk management is required.

Complexity

Projects are comprehensive and multi-layered undertakings with many dependencies. They are characterized by many objectives, influencing factors and interdependencies (complexity characteristics are product dependent – e.g. an aircraft is a complex engine in itself – or complexity can be recognized by the size and number of participants).

Time limitation

Projects are constrained by time, featuring well-defined start and end dates. They therefore require specific organizational and personnel regulations in contrast to line tasks.

Projects can be divided into phases (time periods) and subdivided into milestones (points in time). They entail a temporary project organization and emphasize teamwork.

Interdisciplinary projects require interdisciplinary cooperation in teams (across departments, hierarchies, locations and countries).

Limited resources

Projects are always limited in terms of resources (personnel, material resources, budget considerations).

Objectives

Projects have clear and limited objectives. Requirements are described in terms of deliverables. The criteria of performance (quality), costs, time and, if applicable, project implementation are taken into consideration.

Project activities fundamentally differ from routine activities (tasks) within a line organization. While line activities involve recurring tasks that must be completed as efficiently as possible in a defined process (e.g. production on an assembly line or processing customer orders), projects pose the challenge of solving complex tasks in the form of a project.

Activities like tidying up a home may not align with the characteristics of a project. However, endeavors such as learning to play an instrument or raising children exhibit the features of a project.

Ultimately, the portfolio board must decide whether a project fulfills sufficient project characteristics and should therefore be carried out as a project with corresponding project management tasks or whether line management methods should be used for the project. Not all listed project characteristics (indicators) must be fully met for an initiative to qualify as a project. Ultimately, however, it is the portfolio board that decides whether a project is to be executed as a project or a task. If there is a Project Management Manual that defines the characteristics of a real project, it should be serving as the basis for such decision.

1.2.1.2 The Term «Project Management «

Project management constitutes a distinct management discipline focused on overseeing the implementation of projects and includes all activities throughout the entire lifespan of the project. Due to the temporary nature of projects, this management task is also limited to the duration of the specific project.

Definition from a company guideline [Ger. Definition aus einer Firmendokumentation]

«Project management is a comprehensive leadership task related to a project that includes all leadership activities required for meeting the desired quality and functionality within the stipulated time frame and budget. This endeavor contributes to the overall success of the project.«

Definition according to DIN 69901 Part 5 [Ger. Definition nach DIN 69901 Teil 5]

«Project management is defined as the entirety of managerial tasks, organization, techniques, and means of initiating, defining, planning, controlling, and completing projects.«

In this definition, management is related to «implementation«. Therefore, project management includes all activities related to the implementation of the project.

Definition according to IPMA®/ICB4

«Project management is concerned with the application of methods, tools, techniques and authorities to a project in order to achieve objectives. It is implemented using processes and involves the integration of different phases of the project life cycle. …« (GPM), although IPMA® does not specify any processes.

Definition according to DIN ISO DIN ISO 21500:2016

«Project management is the application of methods, tools, techniques and authorities in a project. It encompasses the […] interaction of the various phases of the project life cycle.«

1.2.1.3 Project Types 

The term «project« covers the construction of a nuclear power plant as well as the relocation of a department or the organization of an open-air concert. Key criteria for differentiating projects include content, number of participants, «degree« of change for the participants, strategic importance of the project, budget and time frame.

The application of project management methods is always an administrative overhead that must be weighed up against the costs and benefits. It must be in proportion to the scope of the project and demonstrate a return on investment itself in the overall efficiency of the project implementation. Accordingly, it should be a matter of course to keep this overhead as low as possible using customized methods and instruments, but also as comprehensive as necessary. Depending on the type of project, it is important to find the right selection and scope for the adequate use of instruments and methods (appropriate «flight level«).

Differentiation based on content:

Project Type

Characteristics/description

Investment projects

• Tangible assets are built or procured (e.g. buildings, plants, large machinery)

Often high investment costs, commissioning usually by tender, public interest present

Planning focus: project financing, cost planning and controlling

Examples: Construction of a dam, renewal of the server landscape in a company, infrastructure of a telecommunications network provider

Organizational projects

• Organizational or process structures are to be created or changed

Affects employees in the company (in total or in part)

Stakeholder interests play a major role in the project (e.g. participants in a music festival)

Planning focus: stakeholder management, communication planning

Examples: Company mergers, reorganization of departments, introduction of new processes, establishment of a new department, organization of events of all kinds

R&DR&D projects

(Research and development)

• For new or improved products, materials or services

Unknown ratio of input and output and therefore low planning reliability

High degree of novelty

Planning focus: Dealing with novelty, interactive approach with regular feedback cycles for continuous learning and further planning

Example: product development based on new technologies, scientific research projects, drug development, user behavior analysis

Tab. 1: Classification of projects based on content

The term IT projects is also used, but this is too unspecific as it only indicates a reference to IT. «IT projects« can take many different forms and be multi-layered. The construction of a server farm or the nationwide rollout of laptops for home-schooling teachers may be categorized as investment projects. The introduction of a large accounting system should be considered as an organizational project because it affects people in their organizational and operational structures. The Greenfield1 development of a new software system has the characteristics of an R&D project.

Given this diversity, it is advisable to categorize IT projects according to the above-mentioned project types with their specific characteristics and not be defined as a generic project type «IT project«.

1.2.1.4 Project Classes

In addition to project types, project classes are also distinguished. This proves advantageous if a company seeks differentiation within a specific project type, e.g. in the case of predominantly organizational projects, for better classification and comparability of projects. By differentiating between project classes, the PM standards available in the company can be adapted and reused individually and tailored to the respective project class.

Classification according to Project Size

This book explores a variety of different tools and methods, recognizing that it does not make sense to use the full range of methods in every project. Small projects can be organized very well with a few selected methods on a small scale: e.g. a simple objective definition, phase planning, and a tabular work breakdown structure (WBS).

For larger projects, the CEs described in this book along with the associated tools and methods become imperative in a strong form and may need to be supplemented by other specific methods. Otherwise, successful project implementation is not possible.

Therefore, it may be helpful to define not only project types but also categorize them into classes according to the different «sizes« of individual projects. For reasons of results orientation and desired efficiency, we do not want to «use a sledgehammer to crack a nut«.

But how do you classify the size of a project? According to effort, duration, importance, complexity, budget, number of parties involved?

Since every company is unique, internal classification characteristics can be defined based on the organization’s specific needs and goals.

Classification by Size

Simplified company example:

Project classes

C

B

A

Expenditure in PD*

50 to 100

101–1000

From 1000

PM-Methods

• Project profile

Phase planning

• Like C-projects

In addition:

WBS, resource planning

Stakeholder analysis

• Like B-projects

In addition:

Cost planning

Risk analysis

Monthly reporting to the Management Board

Training level of the project manager

IPMA® Level D

IPMA® Level C

IPMA® Level B

Tab. 2: Classification of projects based on size

*All endeavors involving less than 50 Person days (PD) are considered tasks and not projects.

Depending on the project class, the procedure for using the methods is mandatory for the projects. These specifications may relate to:

the use and scope of specific project management methods,

the qualifications (level of training) of the appointed project manager ,

the need for a steering committee,

Description of the TCRs of the project roles,

specified opportunity/risk analysis with risk management,

…

Classification According to Priority

In addition to the classification by size, projects can also be classified by need (reason for implementation) or contribution to the company’s success.

Examples:

Classification by project prioritization: 1 – 2 – 3 (e.g. 1 = legally required, 2 = strategic, 3 = cost optimization)

Classification by product life cycle, e.g. the «BCG matrix« of the Boston Consulting Group (Question Marks, Stars, Cash Cows and Poor Dogs)

With project classification, companies can standardize project management while creating a way to scale across project classes. The type of scaling does not need to be redefined each time.

It is also possible to use the company-specific project classes to build up the company’s own project portfolio and thus manage it more transparently.

Classification by Customer Project or Internal Project

Customer projects are carried out by an external service provider on the base of a formal legal contract. This might refer to the entire project or to parts of the project. In-house projects take place entirely within the company’s own organization and are largely carried out using its own resources.

Project Type

Characteristics/description

Extern

(customer projects, contract projects)

• Client is located outside the own organization

The objective is to provide services, usually on the basis of a contract for work and services, which must be accepted by the client at the end of the project

A legal contract between the person placing the order and the person receiving the order as the basis for the project assignment is customary

Planning focus: Scope definition and controlling to fulfill the contract of work, maintenance of the customer relationship

Examples: A mechanical engineering company (client) hires an agency (contractor 1) to create an Internet portal or an external construction company (contractor 2) to build a new office building.

Internal

• Client belongs to the company itself (management, project steering committees) and assigns, for example, the IT department of its company to introduce a new CRM system

Initiation and funding usually from internal sources (for the implementation of a strategic project, however, these may also benefit from external sources, e.g. a legal decision that must be taken into account in the IT processes, so-called mandatory projects)

In most cases, there is no formal, legally binding mandate (contract)

Planning focus: Integration of the project into the internal corporate structure and communication, alignment with the corporate strategy (business case)

Examples: Development of new products, organization of a company party, changeover to GDPR (General Data Protection Regulation), adaptation of products to new emission standards.

Tab. 3: Classification of projects based on the client

External projects follow slightly different rules than so-called internal projects. Only a few important points will be discussed here:

Double project organization: In most cases, there exists a complete project organization with a client, project manager and team on both the commissioning side (client) and the executing side (service provider, contractor).

Detailed project planning is typically carried out exclusively on the service provider’s side. On the customer side, there is usually only a preliminary plan focused on controlling the quotation and planning potential change requests.

The project begins much earlier on the client’s side (initialization phase) than on the service provider’s side. The service provider is integrated into the project after numerous decisions regarding scope, time frame, budget and project implementation have already been made.

A project manager on the service provider side should be aware of the distinctive features of a customer project and take them into account accordingly in the risk and stakeholder analysis, as well as in other aspects of their own «service provider project planning«.

1.2.2 Permanent Systems and Structures

1.2.2.1 Functional Organization

Permanent or Parent Organization [Ger. Stammorganisation]Permanent or Parent Organization

«Synonyms: Basic, business organization

Permanent, project-independent organization, e.g. that of a company, administrative authority, or organization, in contrast to the temporary organizational structure of a project. The term refers to both the structural (personnel, roles, responsibilities) and the process-related organization. However, in practice, the term is often used to refer only to the organization as an institution.« (Motzel)

Fig. 5: Example functional organization with its project

In contrast to project organizations, functional organizations have a longer existence and assert themselves in their environment. Project members may originate from the functional organization or external entities and may return to it after the project is completed.

The project members provided by the functional organization include project managers, members of the project core team, and required technical experts. As a result, the project inevitably adopts the culture of the functional organization.

This is also the reason why the project members (project managers, team members, etc.) should be familiar with the basic rules of the functional organization. Communication and integration into the company will be much smoother due to shared cultural context.

1.2.2.2 Steering Committee

Steering Committee [Ger. Lenkungsausschuss] Steering Committee

«Synonyms: steering committee, steering group.

Superior decision-making board related to a specific project or program or group of projects and/or programs (project portfolio). For a single project, the steering committee can be an internal board within the sponsoring organization consisting of authorized representatives of the client/project owner. External project members can also be included where appropriate. The steering committee should be kept small. It serves the project manager as a go-to board for reporting, decisions to be made, and escalation.« (Motzel)

Fig. 6: Functional organization and project organization

The steering committee is chaired by the project owner and is complemented by members of the functional organization’s management. Stakeholders with substantial power and high conflict potential can be appointed to the Steering Committee as a participatory stakeholder measure (see Ch. 3.3.7 Stakeholders (4.5.12)). By participating in the Steering Committee, they gain increased opportunities to help shape and influence the project and therefore have less reason to be critical of it.

For smaller internal projects, a steering committee may consist only of the team leader, the project manager and possibly another manager, such as a product manager or department head.

1.2.2.3 Project Management Office (PMO)

Project Management Office (PMO) [Ger. Projektmanagementbüro]

«Tell me how a project starts and I’ll tell you how it ends.«

Project management wisdom

«Note: The terms ‹project office (PO)’ and ‹project management office (PMO)’ are often used as synonyms in practice, although they have different meanings. These differences are related to both the institutional setup and the tasks involved. The following spectrum of interpretations of a PMO is common:

(1) Central administration for a specific project, often also physically representing an office (project administrator, project assistant).

(2) Project-controlling function for a single or several projects within an organization.

(3) Service function for the project managers of an organization or organizational unit with the aim of providing project management education, unification and standardization of PM processes, or skilled project personnel such as project managers, project controllers, or assistants.« (Motzel)

The term «Project Management Office (PMO)« refers to a line team that is responsible for the project organization and project processes across all projects of an organizational unit of a company. It supports the projects assigned to it and creates transparency across the project portfolio. For this reason, the PMO is also referred to as a support function:

Administrative function: Service and Central Services

Control functions: Control of the portfolio using standardized indicators and uniform status reports

Coordination function: interfaces with the line structure and portfolio management

Optimization function: continuous improvement of methods, software used and the qualifications of project staff

Fig. 7:

Functions of the Project Management Office

In some organizations, the term «Project Office (PO)« is used interchangeably with the term «Project Management Office (PMO)«. However, this is not correct, as the PO supports a single project, while the PMO is responsible for all projects in an organization. The TCRs (see Ch. 3.3.5.6) also differ fundamentally.

1.2.3 Projects, Programs and Portfolios

Companies that conduct projects professionally (project-oriented companies) supplement their project landscape with programs and project portfolios in addition to individual projects.

Project

Program

Portfolio

Number per company (example)

50–100

1–5

1

Management

Project management

Program management

Portfolio management

Duration

Life cycle of project

Live cycle of program

Life cycle organizational unit of company (no start/end)

Objective

Implementation of a strategic objective or mandatory project

Overarching program management of several jointly structured projects that are conducted together to achieve one or more strategic objectives. Use of synergies between these projects (e.g. uniform governance, joint resource planning, uniform stakeholders/risk management, etc.)

Management of all projects/programs of an organizational unit or the entire company to fulfill the corporate strategy, based on the annual portfolio budget and resource availability

Tab. 4: Comparison of project, program and portfolio

In a project-oriented company, there is usually not just one project, but multiple projects that overlap and run in parallel. The project landscape is used to implement the company’s strategic objectives.

Programs

Companies with prior experience in managing individual projects can form cohesive programs if useful. Programs are used to structure and combine several projects that are intended to contribute to the achievement of one or more strategic objectives.

Example: Digitization

A medium-sized company has set itself the objective of enhancing its digitalization efforts. A program is established for this purpose and several projects are assigned to it, all of which contribute to digitalization:

Migration of telephony to mobile devices,

Implementation of a standardized CRM system (Customer Relationship Management),

Secure Wi-Fi in all company buildings and rooms,

Home office access through VPN (Virtual Private Network),

Migrating internal servers to external cloud solutions,

…

The program is led by an «IPMA® Level B« certified project manager. The project managers are all «IPMA® Level C« certified. In addition, the program management is supported by a program office, which is responsible for the overall coordination and management of the individual projects, ensures compliance with quality standards, carries out large parts of stakeholder communication centrally and thus relieves the individual projects.

By creating a program, synergies between the projects are made transparent and can thus be leveraged. The quality of the program can be monitored more efficiently and maintained centrally than in several independently managed projects. A program has a stronger impact on the company than several individual projects. This means that important issues that might meet with resistance can be implemented more easily and more effectively.

However, programs should not be used in an inflationary manner, as the program organization ties up important and extensive resources. When too many projects are declared programs, they lose their importance and effectiveness.

Project Portfolio

All projects and programs within a division or the company are organized into a project portfolio. Each individual project or program must «apply« to be included in the company’s portfolio. This is typically submitted with an approved project profile or the internally issued project order. Portfolio management decides on inclusion based on various criteria, such as:

Contribution to the implementation of the corporate strategy (→ Is it worth carrying out the project, is it cost effective or important?)

Current resource availability of project staff (→ Do we currently have enough resources, or do we have to wait for other projects to be completed?)

Existing portfolio budget of the company for the implementation of projects (→ How is the portfolio budget distributed among the individual projects and programs? Which of them are newly financed, further financed or stopped?)

Can several projects be combined into one program in order to make the implementation more efficient and effective through synergies?

…

The portfolio manager controls the strategic implementation of the company’s objectives with his or her project portfolio. Project portfolio management is often also seen as a sub-task of the PMO (Project Management Office), which means that the PMO leadership also takes on the role of a portfolio manager.

The terms program and portfolio manager are sometimes confused. However, their roles significantly differ in terms of their tasks and responsibilities:

Program Manager

Portfolio Manager

Position

Captain of the program

Navigator across the project landscape

Focus

Program

Overall view of the projects

Tasks

• Leadership tasks

Must intervene directly in his projects if the situation requires it

• Coordination task

Analyzes and presents the project managers’ problems to the project owners and the higher management

Budget responsibility

Is responsible for the budget

Has no budget responsibility, monitors the portfolio budget

Personnel responsibility

Has personnel responsibility

Analyzes personnel responsibility in the project landscape

Duration of task

Task ends with completion of the program

Permanent task as long as the project landscape in the company needs to be coordinated

Challenges

Is exposed to the client’s rough winds on external projects

Must deal with company policy, power and his own powerlessness in the individual projects

Tab. 5: Tasks and responsibilities of program and portfolio managers

1.2.4 Process and Structural Organization of Projects

The temporary project organization follows a defined structure and process organization. Both the process organization and the structural project organization depend on the individual regulations of a company.

Project Organizational Structure [Ger. Aufbauorganisation]

The entirety of defined responsible persons and the binding regulations regarding responsibilities, authorities, directive authority, and reporting obligations in an organization, usually presented in an organizational chart.

The organizational structure is the result of organizational design in the project referring to the static aspects of the project organization – in contrast to the project process organization, which refers to the dynamic aspects. Nevertheless, the organizational structure can change as required during project execution (e.g., in individual project phases). General design principles of organizational plans are «centralization« and «decentralization«.

A project organizational structure describes the organizational units and project roles. These can be as follows:

Types of project organization,

Project management office (PMO),

Steering committee

Individual project roles (described through TCR or RACI matrix)

Organizational structures are depicted and described hierarchically in organizational charts, with top-down and bottom-up directives. The graphical representation corresponds to the reporting and escalation obligations as well as the desired management levels.

Process Organization [Ger. Ablauforganisation]

Synonym: Project Process Organization

Definition, arrangement, design and description of the procedures (processes) and rules for the implementation of an undertaking, e.g. a project, and at the same time the result of these activities including the corresponding agreements (work and process instructions). The project process organization is the result of organizational design in the project in terms of the dynamic aspects of project organization.

Organizational procedures (processes) are depicted in flowcharts (e.g. flowchart).Flow-Chart Examples of defined processes in project management are:

DIN project management phases

Project approval

Objective setting process

Budget approval

Change management

Resource procurement

Controlling

Product acceptance process

Stakeholder management

Opportunity/risk management

Both the organizational structure and the process organization are strongly influenced by the respective project design and vary depending on the project type, project class and the chosen project organization. The definition options for a company’s individual projects are described in its project management manual.

1.2.5 Project Management Manual 

Companies that regularly conduct projects develop their own company-specific project management standards that are relevant for all projects. These are based on international project management standards (e.g. IPMA®, PMI, PRINCE2, etc.) and industry-specific standards that are formulated individually. These standards are summarized in a project management manual.

Fig. 8:

Structure of a project management manual

(example)

The project management manual may also go by other names, such as project management guide, project management handbook, company guideline PM, design paper PM, etc.

The employees of the PMO create the project management manual and revise it regularly as part of a continuous improvement process. This means that additions and new requirements are constantly being incorporated. The PMO also trains its project staff based on the project management manual.

One difference between the project management manual and the project manual is that the project manual only refers to a specific project. The project management manual, on the other hand, is a set of rules for all projects in the company. In this respect, however, the project manual is based on the project management manual and uses it as a «blueprint« to comply with all internal company requirements for project implementation.

1.2.6 Project Management Standards

There are several international project management standards that address the diversity and characteristics of a wide variety of project types. In simple terms, they differ as follows:

competence-based,

process-based,

agile.

Another difference is the distinction between the certification of persons and the certification of processes.

Fig. 9:

Overview of project management standards and certifications

IPMA® IPMA®

The International Project Management Association (IPMA®) is an overall organization that fosters the professionalization of project management across 70 national associations. Germany is represented within IPMA® by the GPM (Gesellschaft für Projektmanagement). Based on their cooperation, they formulate a new PM standard (ICB, Individual Competence Baseline) at regular intervals, which forms the basis for internationally coordinated certification procedures.

IPMA® develops standards that are competence-based. They relate to the competence of individuals and organizations.

Fig. 10:

ICB as a competence-based standard

The ICB does not contain any specific processes or methods; instead, it defines the skills that project managers need to successfully manage projects. The ICB is formulated for all sectors, including nonprofit organizations. The qualifications teach project managers how to apply methods and procedures based on the sector they work in and the specific project. The qualification and certification process emphasize the demonstration of skills, including the transfer of PM knowledge to a project (report), case studies, assessments (role-based interview), and not just the testing of knowledge.

The current IPMA® standard is ICB4.0, which is divided into three competence areas and 28 competence elements:

The 28 competence elements apply to all certifications, from Level D to Level A. Depending on the level, however, the qualification and certification will take place at a different competence level.

Fig. 11:

The 28 competence elements of ICB4.0 with the Relevance Basic Certificate label. The «Eye of Competence« is the property of IPMA® and is protected by copyright. Reprinted with the kind permission of the copyright holder.

Fig. 12:

Competence levels

For the basic certificate, only selected competence elements, mainly from the Practice area, are included in the certification.

The three areas of competence are marked with three different colors, making them easy to distinguish visually. We have adopted the color codes of the three domains for this book in order to support better recognition and orientation of the three areas of competence.

The IPMA® standard is «hybrid«. This means that the competence elements include both traditional (plan-based) and agile methods.

PMI

The Project Management Institute (PMI) is the largest of the standardizing organizations in terms of membership. Its standard is described in the PMBOK Guide and, unlike the ICB, is process-based. The PMI is centrally located in the USA.

PRINCE2

The PRINCE2 standard (Projects in Controlled Environment) was developed in England. Originally a mandatory standard for government IT projects, it is now also used in other industries. The standard is also process-oriented.

PM²

Since 2014, there has been a project management standard defined by the European Union. The standard refers to methods from IPMA®, PMI and PRINCE2. The standard is specifically intended to improve the quality of EU projects.

Scrum

There are several agile standards (e.g. Kanban, Design Thinking [Gürtler/Mayer 2013], LeSS, SAFe, Nexus). Scrum is described here as a representative example. The Scrum standard is documented as a guideline in the Scrum Guide (Sutherland/Schwaber 2020). Scrum follows an incremental, iterative approach. This means that after initial planning, a completed increment is delivered after each sprint in continuous work and feedback cycles (sprints).

The Scrum Guide contains the definition of Scrum and serves as a framework for using the agile framework. It describes all the elements of Scrum and enables the practical application of the required processes, techniques and methods.

1.2.7 Project Management Regulations

DIN 69901

The DIN 69901:2009-01 series of standards «Project Management – Project Management Systems« describes various aspects of project management. Parts 1–5 define fundamentals, processes, methods, data models and terms. The standard is formulated in a sector-independent manner. The DIN standard is a document that defines the requirements of the process. It thus creates clarity about its characteristics and ensures quality.

DIN ISODIN ISO 21500:2016-02

The DIN ISO 21500:2016 is a German standard. It is based on the ISO 21500 standard, which was last updated in 2012 as an international guideline for project management. It describes terms that generally apply to all projects as best practice in project management. ISO 21500 is considered the lowest common denominator of well-known global standards such as PMI, IPMA® or PRINCE2. It describes the essential, generally accepted components of project management in an extremely condensed and comprehensible form. Individuals can be certified according to this standard by the IHK2. Companies can align their project management system with ISO 21500, have it audited and certified. The current DIN definitions can be viewed on the Internet.

1 Greenfield development refers to the process of developing a system for an entirely new environment and requires development from a clean slate – there is no pre-existing legacy code. It is an approach used when you’re starting fresh, with no restrictions or dependencies.

2 IHK – (Industrie und Handelskammer): German organization that represents the interests of companies in a particular region. It offers a variety of services, including advice, training and events.

1.3 CE Compliance, Standards and Regulations (4.3.3)

Compliance, i. e. the adherence of companies to business and legal rules, policies and regulations (including those within the organization), has become increasingly important in recent years. Through compliant behavior, project management reduces risk and increases the efficiency and effectiveness of the project.

At the same time, it supports compliance with the rule of law and protects the company from potential fines in the event of non-compliance.

Compliance

«The compliance, standards, and regulation competence element describes how the individual interprets and balances the external and internal constraints in a given area such as country, company, or industry.« (ICB4)

Compliance [Ger. Ablauforganisation]

«Proper compliance with specified laws and regulations. Since ICB4.0, ‹Compliance, standards and regulations’ has been a competence element (Perspectives 3), translated in NCB 4.0 as ‹Compliance, standards and regulations’. This competence element defines the interpretation and application of internal and external frameworks, in particular restrictions. Compliance is seen as the process by which requirements are implemented appropriately. These requirements may be formal or informal, mandatory or voluntary.« (Motzel)

«Standards and regulations influence and define the way projects, programs and portfolios should be organized and managed in order to be feasible and successful.

Standards and regulations address compliance with requirements that include legal and regulatory requirements, contracts and agreements, intellectual property and patents, safety, health and environmental protection (SHE), and professional standards.« (ICB4)

Fig. 13: The project and its legal (sanctionable) regulatory framework (PM4, GPM 2019)

1.3.1 Data Protection and Data Security

During the progress of a project, the project management is responsible for complying with all data protection and data security regulations. This applies to the personal data of project staff, users and colleagues as well as the confidential treatment of data provided by clients, suppliers or partners.

Data protection in Germany is governed by the Federal Data Protection Act (Bundesdatenschutzgesetz – BDSG) and specified in the GDPR (General Data Protection Regulation, German: Datenschutzgrundverordnung – DSGVO).

The object and purpose of the GDPR is data protection, which includes the following legal regulations relating to personal data:

Protection against unauthorized data collection,

Protection against unauthorized data storage,

Protection against unauthorized or inappropriate data processing,

Protection against unauthorized disclosure,

Protection of the right to informal self-determination,

Protection of privacy,

Protection of personal rights in data processing.

Data security is an important prerequisite for ensuring data protection. The objective of data security is to adequately protect digital information, technical data and IT systems of all kinds against unauthorized access, loss, damage, manipulation, theft and other threats.

1.3.2 Regulations for Safety, Health and Environmental Protection

The German Occupational Safety and Health Act (Ger. Arbeitsschutzgesetz – ArbSchG) implements the EU directives on safety and health at work. The full name of the Occupational Health and Safety Act is:

«Act on the Implementation of Occupational Health and Safety Measures to Improve the Safety and Health Protection of Employees at Work.«

The objective of the Occupational Safety and Health Act is to improve the health of all employees. The OSH Act requires, among other things, risk assessments, monitoring the effectiveness of preventive measures and instructions.

Examples of important occupational health and safety legislationOccupational health and safety legislation and regulations in Germany:

Occupational Health and Safety Act (Arbeitsschutzgesetz – ArbSchG)

Workplace Ordinance (Arbeitsstättenverordnung – ArbStättV)

Construction Site Ordinance (Baustellenverordnung – BaustellV)

Ordinance on Industrial Safety and Health (Betriebssicherheitsverordnung – BetrSichV)

Ordinance on Hazardous Substances (Gefahrstoffverordnung – GefStoffV)

In addition, there are other legal and regulatory requirements that are the responsibility of the project management in coordination with HR:

Examples of German labor lawLabor law:

Working Hours Act (Arbeitszeitgesetz – ArbZG) – compliance with maximum daily working hours

Maternity Protection Act (Mutterschutzgesetz – MuSchG) – employment restrictions during pregnancy (SGB IX)

Youth Employment Protection Act (Jugendarbeitsschutzgesetz – JarbSchG) – protection of young people’s/trainees interests

Act regarding Holidays (Urlaub – BurlG)

Act regarding temporary employment (Arbeitnehmerüberlassung – AÜG)

Act regarding the posting of employees (Arbeitnehmerentsendung – AentG)

Examples of German health protection lawsHealth protection:

Infection Protection Act (InfSG)

Food Hygiene Regulation

Accident prevention regulations (§ 15 SGB VII)

Ordinance on Occupational Medical Care (ArbMedVV)

Environmental protectionEnvironmental protection: