Projektmanagement (IPMA®) E-Book

Karen Dittmann

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

Seitenzahl: 414

Veröffentlichungsjahr: 2023

Beschreibung

Das Buch enthält den kompletten Lernumfang für die Zertifizierung zum IPMA® Level D sowie des Basiszertifikats (GPM). Es bietet zahlreiche Beispiele, Vorlagen für Projektmanagement-Methoden und Praxistipps. Zudem möchte es die Freude an einer Projektleitung vermitteln, die – professionell durchgeführt – wohl einer der vielseitigsten und spannendsten Berufe ist, die man sich vorstellen kann Die IPMA® (International Project Management Association) definiert weltweit Standards für professionelles Projektmanagement. Die drei Kompetenzbereiche des aktuellen Standards ICB4.0 (Individual Competence Baseline) Perspective (Kontext), People (Persönliches und Soziales) und Practice (Methoden und Technisches) stellen den Zertifizierungsrahmen für Projektleitende. Der kompetenzbasierte Ansatz der IPMA® ermöglicht den Transfer in die Praxis und geht über den reinen Wissen Erwerb anderer Zertifizierungen hinaus. So gelingt der Transfer in den Alltag der Projektleitung. Inhalte: - Projektkontext: wie Projekte in Unternehmen eingebettet sind, welche rechtlichen Regelungen beachtet werden müssen, welche Rolle die Kultur eines Unternehmens bei der Projektdurchführung spielt - Menschen im Projekt: persönliche und soziale Kompetenzen für Projektleitende, wie Projekte mit Menschen für Menschen gestaltet werden  - Methoden und Techniken: von der Anforderungsanalyse über die Leistungs-, Ressourcen-, Zeit- und Kostenplanung bis hin zum Projektcontrolling und Projektabschlus Alle Themen werden sowohl für klassisches (planbasiertes) als auch für agiles Projektmanagement erklärt Neu in der 2. Auflage: - Modernisierter Standard der aktuell gültigen ICB 4 (gültig ab 01.01.2024) - Thema agiles und hybrides Projektmanagement - Durchgängiges Projektbeispiel als Hilfestellung zum Schreiben des Level D Reports

Leseprobe

Inhaltsverzeichnis

InhaltsverzeichnisHinweis zum UrheberrechtmyBook+ImpressumWillkommen im Buch!1 Kompetenzbereich Perspective (Kontext)1.1 CE Strategie (4.3.1)1.1.1 Mission, Vision und Strategie1.1.2 Standard-Erfolgsfaktoren eines Projektes1.1.3 Business Case1.1.4 Nutzwertanalyse1.2 CE Governance-Strukturen und -Prozesse (4.3.2)1.2.1 Temporäre Vorhaben1.2.1.1 Begriff »Projekt«1.2.1.2 Begriff »Projektmanagement«1.2.1.3 Projektarten1.2.1.4 Projektklassen1.2.2 Permanente Systeme und Strukturen1.2.2.1 Stammorganisation1.2.2.2 Lenkungsausschuss1.2.2.3 Projektmanagementbüro1.2.3 Projekte, Programme und Portfolios1.2.4 Projektablauf- und -aufbauorganisaiton1.2.5 Projektmanagement-Handbuch (Projektmanagement-Manual)1.2.6 Projektmanagementstandards1.2.7 Normen zum Projektmanagement1.3 CE Compliance, Standards und Regularien (4.3.3)1.3.1 Datenschutz und Datensicherheit1.3.2 Vorschriften für Sicherheit, Gesundheit und Umweltschutz1.3.3 Gefährdungsanalyse1.3.4 Compliance-Anforderungen einzelner Wirtschaftssektoren1.3.5 Corporate Social Responsibility (CSR) / Nachhaltige Unternehmensführung 1.3.6 Agenda 20301.4 CE Macht und Interessen (4.3.4)1.4.1 Definition von Macht1.4.2 Promotorenmodell nach Witte1.4.3 Kraftfeldanalyse1.5 CE Kultur und Werte (4.3.5)1.5.1 Der Ethik-Kodex der GPM1.5.2 Das Projekt mit der Kultur und den Werten einer Organisation in Einklang bringen (nach Edgar Schein)1.5.3 Klassische versus agile Werte1.5.3.1 Klassische Werte1.5.3.2 Agiles Mindset2 Kompetenzbereich People (Persönliches + Soziales)2.1 CE Selbstreflexion und Selbstmanagement (4.4.1.)2.1.1 Methoden zur Selbstreflexion2.1.1.1 5-Finger-Methode2.1.1.2 Persönliche SWOT-Analyse oder Stärken-Schwächen-Analyse2.1.1.3 Selbstreflexion anhand der Rolle im Projekt2.1.2 Methoden zum Selbstmanagement2.1.2.1 Eisenhower-Matrix2.1.2.2 Getting Things Done2.1.3 Projektmanagement und Stress2.1.4 Persönliche Kompetenzentwicklung im Projektmanagement2.1.4.1 Karriereplanung in drei Ansätzen2.1.4.2 Das 4-Level-Modell der IPMA® 2.2 CE Persönliche Integrität und Verlässlichkeit (4.4.2)2.2.1 Verlässlichkeit und Vertrauen2.2.2 Fehlerkultur2.2.3 Nachhaltigkeit2.3 CE Persönliche Kommunikation (4.4.3)2.3.1 Kommunikationsmodelle2.3.1.1 Eisbergmodell (Freud)2.3.1.2 Sender-Empfänger-Modell (Shannon/Weaver)2.3.1.3 Fünf Axiome der Kommunikation (Watzlawick)2.3.1.4 Nachrichtenquadrat (Schulz von Thun)2.3.2 Information erhalten: Aktives Zuhören2.3.3 Fragetechniken2.3.4 Kommunikation und Störung der Wahrnehmung2.3.5 Besprechungen2.3.5.1 Besprechungsarten2.3.5.2 Empfehlungen zur Durchführung von Besprechungen2.3.5.3 Protokolle2.3.6 Mit virtuellen Teams effektiv kommunizieren2.3.6.1 Was ist in virtuellen Teams anders?2.3.6.2 Netiquette2.3.6.3 Online-Konferenzen2.3.6.4 E-Mails2.3.6.5 Best Practice2.4 CE Beziehungen und Engagement (4.4.4)2.4.1 Persönliche Beziehungen aufbauen und pflegen2.4.1.1 Interessen anderer erkunden2.4.1.2 Selbstbestimmungstheorie nach Deci und Ryan2.4.1.3 Motivationskontinuum2.4.2 Berufliches Netzwerk (Business Network)2.5 CE Führung (4.4.5)2.5.1 Führungsstile, Führungstechniken, Führungsinstrumente2.5.2 Führungsstile2.5.2.1 Theorie des situativen Reifegrads2.5.2.2 Laterale Führung2.5.3 Führungstechniken2.5.4 Entscheidungsfindung2.6 CE Teamwork (4.4.6)2.6.1 Erfolgsfaktoren der Teamarbeit2.6.2 Teamregeln2.6.3 Besondere Teameffekte2.6.3.1 Groupthink2.6.3.2 Risk Shifting2.6.3.3 Social Loafing2.6.4 Modelle zur Teamarbeit2.6.4.1 Teamuhr nach Tuckman2.6.4.2 Rollenmodell nach Belbin2.6.5 Feedback2.7 CE Konflikte und Krisen (4.4.7)2.7.1 Symptome von Konflikten2.7.2 Konfliktursachen2.7.3 Kooperative Konfliktlösung2.8 CE Vielseitigkeit (4.4.8)2.8.1 Offenes und kreatives Umfeld in Besprechungen2.8.2 Problemlösung2.8.2.1 Probleme analysieren2.8.2.2 Kreativität und Kreativitätstechniken2.8.2.3 Prozess der Problemlösung2.8.2.4 Problemlösungsstrategien2.8.2.5 Vier Phasen der Kreativität als Prozess2.9 CE Verhandlung (4.4.9)2.9.1 Offene und verdeckte Verhandlungen2.9.2 Gesprächsführung einer Verhandlung2.9.3 Bedürfnisermittlung als Grundlage zur Verhandlungsführung2.10 CE Ergebnisorientierung (4.4.10)2.10.1 Verbindung zu Teilgebieten des Projektmanagements2.10.2 Effizienz und Effektivität2.10.3 Projektmarketing2.10.4 Ergebnisorientierung in der Praxis3 Kompetenzbereich Practice (Methoden + Technisches)3.1 Planbasiert, hybrid, agil3.2 Initialisierung3.2.1 Dokumente in der Initialisierungs- und Definitionsphase 3.2.1.1 Der 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 Der Projektsteckbrief (4.5.2, 4.5.10)3.2.1.5 Der Projektauftrag (4.5.2, 4.5.10)3.2.1.6 Projekthandbuch (4.5.1, 4.5.5)3.3 Definition3.3.1 Anforderungen und Ziele (4.5.2)3.3.1.1 Zielfunktionen3.3.1.2 Projektziele definieren3.3.1.3 Darstellung von Zielklassen3.3.1.4 Ziele sorgfältig formulieren und operationalisieren3.3.1.5 Ziele und Abnahmekriterien3.3.1.6 Zielfindung – Zielprozess 3.3.1.7 Zielbeziehungen erkennen3.3.1.8 Symptome einer ungenügenden Zieldefinition3.3.1.9 Agile Anforderungen und Ziele (4.5.2)3.3.2 Projektdesign (4.5.1)3.3.2.1 Schritt 1: Erfolgskriterien definieren3.3.2.2 Schritt 2: Erfolgsfaktoren festlegen3.3.2.3 Schritt 3: Lessons Learned3.3.2.4 Schritt 4: Projektart und Projektklasse bestimmen3.3.2.5 Schritt 5: Handlungsansatz auswählen und anpassen3.3.2.6 Vorgehensmodell Wasserfall3.3.2.7 Agile Softwareentwicklung (inkrementell)3.3.2.8 Kanban3.3.2.9 Schritt 6: Design und Projekthandbuch3.3.2.10 Schritt 7: Überprüfung3.3.2.11 Projekterfolg3.3.3 Phasenplanung (4.5.4)3.3.3.1 Elemente der Phasenplanung3.3.3.2 Ebenen der Phasenplanung3.3.4 Projekt starten und Zustimmung einholen (4.5.10)3.3.4.1 Projektplan erstellen3.3.4.2 Projektstart-Workshop3.3.4.3 Projekt-Kick-off3.3.4.4 Projektstart in agilen Projekten3.3.5 Projektorganisation (4.5.5)3.3.5.1 Einfluss-Projektorganisation3.3.5.2 Reine oder autonome Projektorganisation3.3.5.3 Matrix-Projektorganisation3.3.5.4 Agile Projektorganisationsform3.3.5.5 Projektorganisationsformen im Vergleich 3.3.5.6 Projektrollen im Team (AKV)3.3.5.7 Projektrollen und Verantwortungsdefinition (RACI-Matrix)3.3.5.8 Kongruenzprinzip in der Rollendefinition3.3.6 Projektdokumentation (4.5.5)3.3.6.1 Dokumentenstandards3.3.6.2 Dokumentationspflicht3.3.6.3 Visualisierungsarten von Information3.3.6.4 Projektdokumente organisieren3.3.7 Stakeholder (4.5.12)3.3.7.1 Projektumfeldanalyse3.3.7.2 Stakeholderanalyse3.3.7.3 Stufen des Stakeholdermanagements3.3.7.4 Methoden und Einflussnahme3.3.7.5 Stakeholdermaßnahmen in agilen Projekten3.3.8 Chancen und Risiken (4.5.11)3.3.8.1 Definition3.3.8.2 Ziele des Risikomanagements3.3.8.3 Ein- und zweidimensionale Risikobetrachtung3.3.8.4 Branchenspezifische Risikobetrachtung3.3.8.5 Risikoanalyseprozess3.3.8.6 Identifizieren von Risiken3.3.8.7 Qualitative Risikoanalyse3.3.8.8 Risikobeschreibung3.3.8.9 Klassifizierung von Risiken3.3.8.10 Quantitative Risikoanalyse3.3.8.11 Strategien zum Umgang mit Risiken und Chancen3.3.8.12 Fehlermöglichkeits- und Einflussanalyse (FMEA)3.4 Detailplanung3.4.1 Leistungsumfang und Lieferobjekte (4.5.3)3.4.1.1 Anforderung an Lieferung und Leistung3.4.1.2 Dokumente zur Leistungsbeschreibung3.4.1.3 Projektstrukturplan (PSP)3.4.1.4 Projektstrukturierung3.4.1.5 Abgrenzung Ziele und Leistungsumfang3.4.1.6 Arbeitspakete definieren3.4.1.7 Strukturierung von Anforderungen agil3.4.1.8 Leistungsdefinition agil3.4.2 Ablauf und Termine (4.5.4)3.4.2.1 Vorgangsliste3.4.2.2 Netzplan3.4.2.3 Anordnungsbeziehungen3.4.2.4 Puffer3.4.2.5 Gantt-/Balkendiagramm3.4.2.6 Terminplanung klassisch3.4.2.7 Terminplanung agil3.4.2.8 Terminplanung hybrid3.4.3 Ressourcen (4.5.8)3.4.3.1 Ressourcenarten3.4.3.2 Aufwände schätzen3.4.3.3 Aufwand, Dauer und Belastung3.4.3.4 Ressourcen einlasten3.4.3.5 Ressourcen optimieren3.4.3.6 Ressourcenplanung agil3.4.4 Kosten und Finanzierung (4.5.7)3.4.4.1 Kostenplanung3.4.4.2 Kostenrechnung3.4.4.3 Projektkosten darstellen und berichten3.4.4.4 Kostenplanung agil3.5 Steuerung3.5.1 Übergänge in eine neue Phase/Abschnitte managen (4.5.10)3.5.2 Übergänge in eine neue Iteration/Abschnitte managen – Agile (4.5.10)3.5.3 Projektfortschritt bestimmen (4.5.10)3.5.4 Projektfortschritt bestimmen im Agilen (4.5.10)3.5.5 Projektplan mit Ist-Daten abgleichen (4.5.10)3.5.5.1 Earned-Value-Analyse3.5.5.2 Kostenprognosen und Kostentrendanalyse (KTA)3.5.5.3 Meilensteintrendanalyse (MTA)3.5.6 Berichte (4.5.10)3.5.6.1 Statusbericht3.5.6.2 Abschlussbericht3.5.6.3 Erfahrungsberichte3.5.7 Änderungsmanagement (4.5.10)3.5.8 Qualität (4.5.6)3.5.8.1 Ziele Qualitätsmanagement3.5.8.2 Qualitätsplan für das Projekt entwickeln3.5.8.3 Der kontinuierliche Verbesserungsprozess3.5.8.4 Qualitätssicherung in agilen Projekten3.5.9 Beschaffung (4.5.9)3.5.9.1 Relevante Vertragsarten für Projekte (Zivilrecht)3.5.9.2 Vertragsmanagement3.5.9.3 Make-or-Buy-Entscheidungen3.5.10 Change und Transformation (4.5.13)3.6 Abschluss (4.5.10)3.6.1 Produktabnahme3.6.2 Abschlussanalyse und Evaluation3.6.3 Erfahrungssicherung (Lessons Learned)3.6.4 Projektauflösung3.6.5 Projektabschluss in agilen ProjektenDanksagungDie AutorenLiteraturverzeichnisIhre 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-16624-6

Bestell-Nr. 10604-0002

ePub:

ISBN 978-3-648-16625-3

Bestell-Nr. 10604-0101

ePDF:

ISBN 978-3-648-16626-0

Bestell-Nr. 10604-0151

Karen Dittmann/Konstantin Dirbanis

Projektmanagement (IPMA®)

2. Auflage, Oktober 2023

© 2023 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.

Willkommen im Buch!

Dieses Buch haben wir für alle geschrieben, die in das Thema Projektmanagement einsteigen wollen. Den Einstieg kannst Du entweder mit einem »IPMA® Level D«-Kurs oder den Kurs »Basiszertifikat (GPM)« machen. Für beide Kurse liefert dieses Buch eine Basis. Falls Du zunächst einen ersten Eindruck bzw. Überblick über Projektmanagement bekommen möchtest, kannst Du es einfach durchlesen.

Die Grundlage für dieses Buch ist der internationale Projektmanagementstandard der IPMA® in der aktuellen Version der ICB4.0 (Individual Competence Baseline) sowie die Weiterentwicklung der GPM von 2023. Der internationale Standard der ICB4.0 gliedert sich in drei Kompetenzbereiche. Dementsprechend ist auch dieses Buch in diese drei Bereiche mit den übernommenen Farbcodierungen gegliedert:

Kompetenzbereich Perspective (Kontext)Kompetenzbereich Perspective (Kontext)

Kompetenzbereich People (Persönliches und Soziales)Kompetenzbereich Persönliches uns Soziales

Kompetenzbereich Practice (Methoden und Technisches)Kompetenzbereich Methoden und Technisches

Die drei oben genannten Kompetenzbereiche sind in der ICB weiter in unterschiedliche Kompetenzelemente (Competence Elements, CE) gegliedert. Diese Kompetenzelemente haben in der ICB4.0 eine Standardnummerierung. Die Standardnummerierung der CE haben wir in dieses Buch übernommen und kennzeichnen damit die jeweiligen Buchkapitel, indem wir die CE-Kürzel jeweils in Klammer ankündigen. Dadurch ist der Bezug der Buchinhalte zur aktuellen Version der ICB4.0 sichergestellt. Mehr zur ICB4.0 und zu anderen Projektmanagementstandards in Kap. 1.2.6 Projektmanagementstandards.

Der Standard der IPMA® ist hybrid. Das bedeutet, er enthält sowohl klassische (planbasierte) als auch agile (wertbasiert) Methoden und Kompetenzen. Die Begriffe »klassisch« und »planbasiert« werden in diesem Buch synonym verwendet. Klassisches Projektmanagement ist ein fest etablierter, seit Langem gültiger Begriff, der aus den Köpfen von Projektmanagern und Projektmanagerinnen nicht so leicht zu verdrängen ist. Planbasiertes ProjektmanagementPlanbasiertes Projektmanagement dagegen ist der mittlerweile korrektere Begriff, vor allem in Abgrenzung zum agilen Projektmanagement, bei dem detaillierte langfristige Pläne eher in den Hintergrund rücken.

Inhalt, der sich auf agiles oder hybrides Projektmanagement bezieht, ist mit diesem Symbol markiert.

Kursiv gedruckte Textpassagen ohne Quellenangabe sind dem Projektmanagement-Lexikon nach Motzel entnommen oder stellen Definitionen der Autoren dar. Alle anderen Zitate sind kursiv dargestellt mit Quellenangabe. Die Definitionen werden zudem in grauen Kästen gekennzeichnet.

In dieses Buch haben wir unsere langjährige Trainererfahrung bezüglich des Inhaltes, der Methodiken und der Didaktik einfließen lassen. Damit unterstützten wir Dich bei der Erschließung des sehr komplexen Themas Projektmanagement.

Im Download-Bereich des Buches stehen Dir zahlreiche Vorlagen für den Praxiseinsatz zur Verfügung. Sie können die Grundlage für Deine ganz persönliche Projektarbeit bilden.

1 Kompetenzbereich Perspective (Kontext)

Dieses Kapitel handelt von den Einflüssen, die von außen an ein Projekt herangetragen werden und es mitbestimmen. Diese Einflüsse können organisatorisch, gesellschaftlich und/oder politisch sein und sind im Kontext zur Projektarbeit zu berücksichtigen. Nur wer diese Einflüsse und Wechselwirkungen kennt, kann sie strukturiert nutzen und angemessen, innerhalb seiner Projektarbeit, darauf reagieren.

1.1 CE Strategie (4.3.1)

Projekte und die Strategie eines Unternehmens stehen in einem engen Zusammenhang. Deshalb befasst sich das erste Kompetenzelement der ICB4 (GPM 2016) und das erste Kapitel dieses Buchs mit dem Thema Strategie.

Die Strategie eines Unternehmens wird als langfristiges Marktverhalten definiert, welches sich an dessen Unternehmenszielen ausrichtet. Die Unternehmensstrategie trägt dazu bei, dass das Unternehmen sich gegenüber Mitbewerbenden abgrenzen und behaupten kann. Sie wird in einzelne strategische Ziele heruntergebrochen und in Form von Projekten umgesetzt.

1.1.1 Mission, Vision und Strategie

Die Mission beschreibt im Idealfall die Gegenwart, die Vision einen gewünschten, idealen Zustand in der Zukunft, der sich aus der Mission ableitet. Die Strategie ist der langfristige Weg (3–5 Jahre) zur Erreichung der Mission unter gleichzeitiger Berücksichtigung der Vision.

Mission [engl.: Mission]Mission

»Auftrag, Beauftragung eines Unternehmens/einer Organisation zu einem bestimmten Handeln, zu einer Zielerreichung. Beschäftigt sich mit der Frage: Wozu sind wir hier? Was ist unsere Aufgabe?« (Motzel)

Die Mission eines Unternehmens bildet das Fundament. Sie beschreibt seine Daseinsberechtigung und den Zweck als Auftrag zur Erreichung der Vision. Warum gibt es dieses Unternehmen, was treibt uns dauerhaft an und warum ergibt es Sinn, dieses zu erhalten? Was ist sein Nutzungsversprechen für die Umwelt, die Kundinnen und Kunden? Ohne eine bewusste Mission werden Vision und Strategie beliebig.

Vision [engl.: Vision] Vision

»Anschaulich geschilderte Vorstellung/Zukunftswunsch, dient zur Ausrichtung allen Handelns und Entscheidens. Soll einen positiv motivierten Zustand erzeugen und eine Richtung vorgeben, mit denen sich die Menschen eines Unternehmens/einer Organisation identifizieren können.« (Motzel)

Die Vision zeigt in die Zukunft und beantwortet die Frage, wohin sich das Unternehmen/die Organisation hin entwickeln will. Sie gibt den Idealzustand vor, der künftig erreicht werden soll. Die Kernbotschaften einer gut formulierten Vision beschreiben folgende Fragen:

Wer wollen wir sein?

Was wollen wir getan haben?

Welche Probleme unserer Kundinnen/unser Kunden/unserer Stakeholder wollen wir gelöst haben?

Wo wollen wir unser Unternehmen/unsere Organisation in der Zukunft (5–10 Jahren) sehen?

Zuerst wird die Mission definiert. Diese beschreibt den heutigen Zustand, bis sie vom Unternehmen geändert wird. Darauf basierend entwickelt das Unternehmen seine Vision, ein konkret beschriebener Zustand, den das Unternehmen zukünftig erreichen möchte.

Beide sollen Orientierung schaffen und Richtung geben. Weisen Mission und Vision in die gleiche Richtung, dann motivieren sie die Mitarbeitenden und fokussieren die Ausrichtung und die darauf basierenden Aktivitäten eines Unternehmens.

Abb. 1:

Zusammenhang zwischen Mission, Vision und Strategie eines Unternehmens

Strategie [engl.: Strategy]Strategie

»Grundsätzliche, langfristige und dokumentierte Verhaltensweise (Maßnahmenkombination), die geplant ist, um auf der Basis der Mission die Vision zu erreichen.« (Motzel)

Die Projekte eines Unternehmens sollten seiner Strategie folgen und an dieser ausgerichtet sein. Stehen Projekte konträr zu diesen strategischen Führungselementen einer Organisation, entsteht sog. »wertevernichtende Komplexität«. Für den Abgleich zwischen strategischen Zielen und durchzuführenden Projekten ist das strategische Management eines Unternehmens zuständig.

Beispiele:

Will ein Automobilunternehmen, welches bisher nur PKW hergestellt hat, nun auch Motorräder produzieren, sollte dieses Vorhaben mit der Strategie des Unternehmens abgeglichen werden.

Erhält ein pazifistisch geprägtes Beratungshaus einen Auftrag aus dem Bereich Rüstung, sollte die Organisation sich bewusst für oder gegen diesen Auftrag aussprechen.

Die Übereinstimmung zwischen den Projektzielen und der Unternehmensstrategie sollte der Auftraggeber mit folgenden Fragen überprüfen, bevor er sein Projekt zur Genehmigung beim Portfolioboard (s. Kap. 1.2.3 Projekte, Programme und Portfolios) einreicht:

Werden die Erfolgsfaktoren (s. Kap. 1.1.2 Standard-Erfolgsfaktoren eines Projektes) eines Projektes von der Strategie des Unternehmens getragen?

Kann der Business Case (s. Kap. 1.1.3 Business Case) mit der Strategie des Unternehmens in Einklang gebracht werden?

Welche Faktoren des Projektumfeldes (s. Kap. 3.3.7.1 Projektumfeldanalyse) haben ihren Ursprung in der Strategie des Unternehmens? Gibt es Widersprüche zwischen Umfeldfaktoren und Strategie?

Es ist Aufgabe des Auftraggebers und auch des Portfoliomanagements, jedes neu initiierte Projekt daraufhin zu prüfen, ob es die Vision des Unternehmens unterstützt. Nur so kann verhindert werden, dass Projekte durchgeführt werden, welche den Unternehmenserfolg nicht fördern.

1.1.2 Standard-Erfolgsfaktoren eines Projektes

Basierend auf Untersuchungen der GPM (2007) sind folgende, in Abb. 2 dargestellte Faktoren für den Erfolg von Projekten verantwortlich. Diese sind in Unternehmen nicht immer gegeben. Beispielsweise finden wir nicht überall qualifiziertes Projektpersonal, welches zum Erfolg eines Unternehmens beitragen kann. Nach den Erfahrungen der Autorin und des Autors haben sich diese Faktoren bis heute nicht geändert.

Abb. 2:

Standard-Erfolgsfaktoren

Diese Standard-Erfolgsfaktoren sollten ein Auftraggeber und eine Projektleitung kennen und dahin gehend überprüfen, ob sie im eigenen Unternehmen gegeben sind. Andernfalls muss das Projektumfeld entsprechen angepasst (z. B. das Projektpersonal zu qualifizieren) und die Projektplanung daran ausgerichtet werden (z. B. bei einem konfliktreichen Organisationsprojekt ein umfassendes Projektkommunikationssystem aufbauen).

Zusätzlich ist es Aufgabe der Projektleitung, gemeinsam mit dem Auftraggeber weitere kritische Erfolgsfaktoren (KEF) zu definieren und im Projektdesign (s. Kap. 3.3.2 ProjektdesignProjektdesign (4.5.1)) zu berücksichtigen.

1.1.3 Business Case

Der Business Case wird in der Initialisierungsphase vom Auftraggeber erstellt. Er formuliert, warum es sinnvoll ist, das Projekt durchzuführen, oder eben auch nicht (dann wird das Projekt nicht gestartet). Somit muss der Business Case auch immer einen Bezug zur Unternehmensstrategie haben.

Business Case [engl.: Business Case]Business Case

»Geschäftsvorgang mit Nachweis über die Berechtigung, die Ziele, den Nutzen und die Wirtschaftlichkeit bzw. Rentabilität eines Projekts. Dieser Nachweis wird üblicherweise bei der Projektdefinition entwickelt, während der Projektselektion kontinuierlich überprüft und am Projektende ausgewertet. Der Business Case wird auf der Basis von Unternehmens- bzw. Geschäftsfeldstrategie und Projektselektion gebildet und bezieht den Anwendungserfolg eines Projekts bzw. die Projektfolgen mit ein.« (Motzel)

Abb. 3: Business-Case-Formular

Der Business Case hat immer einen Bezug zur wirtschaftlichen Motivation, warum ein Projekt durchgeführt werden soll. Dies kann entweder die Umsetzung eines strategischen Ziels (Basis für mögliche, künftige Umsätze) oder die Notwendigkeit einer vorgegebenen Änderung (extern oder intern) im Unternehmen sein, die durch rechtliche oder organisatorische Anforderungen begründet ist (sog. Zwangsprojekte).

Beispiele:

Entwicklung eines neuen Werkstoffes oder einer Technologie, mit denen in der Zukunft neue Geschäftsfelder oder Kunden erschlossen werden können (zusätzliche Umsätze);

Zusammenführung von zwei Einkaufsbereichen, um Kosteneffekte zu nutzen (interne Änderung);

Prozess- bzw. Systemanpassungen um neue/geänderte Gesetze einzuhalten, z. B. DSGVO (externe Änderung).

1.1.4 Nutzwertanalyse

Mithilfe einer NutzwertanalyseNutzwertanalyse kann der Auftraggeber Alternativen aufzeigen und qualitativ bewerten:

Sollen wir Software A oder B einsetzen?

Wollen wir ein Bauteil selbst entwickeln oder einkaufen?

Sollen wir unsere Produktion von Deutschland in Land A oder in Land B verlagern?

Im Gegensatz zu einer Pro-Contra-Auflistung werden die Entscheidungskriterien nicht nur genannt, sondern auch bewertet und gewichtet. Die Kriterienliste der Nutzwertanalyse kann sowohl wirtschaftliche als auch nicht-wirtschaftliche Faktoren umfassen. Sie dient als Basis einer nicht monetären Entscheidung, die auf mehreren, unterschiedlich gewichteten Faktoren basiert.

Abb. 4:

Beispiel einer Nutzwertanalyse zur Auswahl eines neuen CRM-Systems

CRM-System

(Software zum Customer Relationship Management)

Die Qualität einer Nutzwertanalyse hängt davon ab, ob sie die relevanten Kriterien enthält und die Perspektive der wichtigsten Stakeholder widerspiegelt. Die relevanten Kriterien müssen im Team bzw. von der auftraggebenden Person bewertet werden. Die Stakeholderanalyse Stakeholderanalyse(s. Kap. 3.3.7 Stakeholder (4.5.12)) ist eine typische Methode als Basis der Kommunikationsplanung, die normalerweise erst in der Detailplanungsphase angewandt wird. Im Zusammenhang mit der Nutzwertanalyse kann es durchaus angebracht sein, die Stakeholderanalyse in einer ersten Version schon in der Initialisierungsphase zu erstellen. So können die Stakeholder in einer frühen Projektphase ihre Perspektive in die Nutzwertanalyse einbringen und gleichzeitig vom Projektteam und von der Projektleitung besser bezüglich ihrer Erwartungen und Befürchtungen eingeschätzt werden.

Bezogen auf den Business Case ist die Nutzwertanalyse ein wichtiges Instrument, um den Umfang und die Zielsetzung des Projektes zu definieren. In den Kriterien und der Gewichtung sollte wiederum die Unternehmensstrategie Berücksichtigung finden.

Beispiele:

Ein Unternehmen möchte in den nächsten drei Jahren seine Digitalisierung voranbringen. Das Kriterium User-Freundlichkeit (s. Abb. 4) wird deswegen höher gewichtet als z. B. die Anschaffungskosten des CRM-Systems.

Ein anderes Unternehmen muss aus wirtschaftlichen Gründen eine Einsparoffensive starten, um deutlich seine Kosten zu reduzieren. In diesem Fall werden die Kriterien in der Nutzwertanalyse bezüglich der Kosten sicherlich höher gewichtet werden, als in Abb. 4 dargestellt.

1.2 CE Governance-Strukturen und -Prozesse (4.3.2)

Dieses Kompetenzelement (CE) beschreibt Strukturen, Systeme und Prozesse von Unternehmen, welche Einfluss auf deren Projekte haben. Dabei bezieht sich das CE sowohl auf temporäre Vorhaben (Projekte) als auch auf permanente Systeme und Strukturen (Linienorganisation). Kenntnisse der Strukturen und Prozesse helfen der Projektleitung, das eigene Projekt zu verstehen, in die Unternehmensorganisation einzubetten und zu managen.

1.2.1 Temporäre Vorhaben

1.2.1.1 Begriff »Projekt«

Im täglichen Sprachgebrauch sind »Projekte« allgegenwärtig. Man spricht von dem Projekt »Wohnung aufräumen«, widmet sich dem Projekt »ein Instrument lernen« oder ist im Projekt »Familie« involviert. Doch sind dies alles echte Projekte?

Wir wollen den Projektbegriff schärfen und Vorhaben mit Projektcharakter von Aufgaben abgrenzen. Für die Bearbeitung von Aufgaben in der Linienorganisation wäre die Disziplin des Projektmanagements ein unnötiger Overhead und bei einem Kosten-Nutzen-Vergleich unwirtschaftlich. Bei echten Projekten hilft Projektmanagement, den Erfolg mit den gewünschten Ergebnissen sicherzustellen.

Populäre Definition (aus einer Firmenbroschüre)

Ein Projekt ist ein:

einmaliges,

komplexes,

zeitlich begrenztes Vorhaben,

zu dessen Realisierung unterschiedliche Ressourcen (Personen, Arbeitsgruppen etc.) herangezogen werden müssen.

Definition nach DIN 69901 Teil 5

Das Projekt wird als »Vorhaben« bezeichnet, welches durch seine Einmaligkeit gekennzeichnet ist. Ihm werden folgende Merkmale zugeschrieben:

Zielvorgaben

Zeitliche, finanzielle, personelle oder andere Begrenzungen

Eine projektspezifische Organisation (PM4, GPM 2019)

Definition nach IPMA®/ICB4

»Ein Projekt ist definiert, als einmaliges, zeitlich befristetes, interdisziplinäres und organisiertes Unterfangen, um festgelegte Arbeitsergebnisse im Rahmen vorab definierter Anforderungen und Randbedingungen zu erzielen« (GPM)

Kennzeichen von Projekten

Fasst man die genannten Definitionen zusammen, kann man Projekten folgende Merkmale zuschreiben:

NeuartigkeitNeuartigkeit(Einmaligkeit)

Projekte sind einmalige Vorhaben. Da nur teilweise auf Bekanntes zurückgegriffen werden kann, bestehen erhöhte Risiken, und ein Risikomanagement ist erforderlich.

KomplexitätKomplexität

Projekte sind ganzheitliche, vielschichtige Vorhaben mit vielen Abhängigkeiten. Sie sind durch eine Vielzahl von Zielen, Einflussfaktoren und Wirkungszusammenhängen gekennzeichnet (Komplexitätsmerkmale sind produktabhängig – z. B. ist ein Flugzeug in sich schon eine komplexe Maschine oder man erkennt Komplexität an der Größe und Vielzahl der Beteiligten).

Zeitliche Befristung

Projekte sind zeitlich befristet mit klar definierten Terminen für Anfang und Ende. Sie erfordern deshalb spezifische organisatorische und personelle Regelungen in Abgrenzung zu den Linienaufgaben.

Projekte lassen sich in Phasen (Zeitabschnitte) gliedern und mit Meilensteinen (Zeitpunkte) unterteilen. Sie haben eine befristete Projektorganisation, die nach dem Projekt wieder aufgelöst wird.

Interdisziplinäre Projekte erfordern interdisziplinäre Zusammenarbeit in Teams (bereichs-, hierarchie-, standort- und länderübergreifend).

Begrenzte Ressourcen

Projekte sind in ihrer Ressourcenausstattung begrenzt (Personal – Sachmittel – Budget).

ZielsetzungZielsetzung

Projekte haben eindeutige und abgegrenzte Ziele. Die Anforderungen werden hinsichtlich der Lieferobjekte beschrieben. Es werden Leistung (Qualität), Kosten, Termine und ggf. auch die Projektdurchführung berücksichtigt.

Tätigkeiten mit Projektcharakter unterscheiden sich also von den Routinetätigkeiten einer Linienorganisation. Während bei Linientätigkeiten immer wiederkehrende Aufgaben möglichst effizient in einem definierten Prozess abgearbeitet werden sollen (z. B. Produktion am Fließband oder Bearbeitung von Kundenaufträgen), besteht bei Projekten die Herausforderung, einmalige und komplexe Vorhaben in Form eines Projektes zu lösen.

Seine Wohnung aufzuräumen, ­entspricht nicht den Charakteristika eines Projekts. Das Lernen eines Instrumentes, sowie Kinder großzuziehen dagegen schon eher!

Letztendlich bedarf es der Entscheidung desPortfolioboard Portfolioboards, ob ein Vorhaben ausreichend Projektmerkmale erfüllt und deshalb als Projekt mit Projektmanagementaufgaben durchgeführt werden soll oder ob für das Vorhaben Methoden des Linienmanagements angewandt werden sollen. Nicht alle oben angeführten Projektmerkmale (Kennzeichen) müssen erfüllt sein, damit das Vorhaben Projektcharakter hat. Letztendlich entscheidet jedoch das Portfolioboard, ob es als Projekt oder Aufgabe durchgeführt werden soll. Ist ein Projektmanagement-Handbuch vorhanden, innerhalb dessen für das Unternehmen PM-Definitionen beschrieben sind, werden diese als Basis für diese Entscheidung genutzt.

1.2.1.2 Begriff »Projektmanagement«

Projektmanagement ist eine eigene Managementdisziplin zur (Durch-)Führung von Projekten und umfasst sämtliche Tätigkeiten, während der gesamten Lebensdauer des Projektes. Durch die zeitliche Befristung des Projektes ist auch diese Führungsaufgabe auf die Projektdauer befristet.

Definition aus einer Firmendokumentation

Projektmanagement ist eine auf ein Projekt bezogene umfassende Führungsaufgabe, die alle Führungstätigkeiten einschließt, die für die Einhaltung der Qualität, der Funktionalität, in der vorgegebenen Zeit und im Budget erforderlich sind und somit zum Gelingen des Projektes beitragen.

Definition nach DIN 69901 Teil 5

Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Initialisierung, Definition, Planung, Steuerung und den Abschluss von Projekten.

In dieser Definition hat Führung etwas mit »Durchführen« zu tun. Somit umfasst das Projektmanagement sämtliche Tätigkeiten in Zusammenhang mit der Durchführung des Projektes.

Definition nach IPMA®/ICB4

»Das Projektmanagement befasst sich mit der Anwendung von Methoden, Tools, Techniken und Kompetenzen für ein Projekt, um Ziele zu erreichen. Es wird mithilfe von Prozessen umgesetzt und umfasst die Integration verschiedener Phasen des Projektlebenszyklus. …« (GPM), wobei die IPMA® keine Prozesse vorgibt.

Definition nach DIN ISO DIN ISO 21500:2016

»Projektmanagement ist die Anwendung von Methoden, Hilfsmitteln, Techniken und Kompetenzen in einem Projekt. Es umfasst das […] Zusammenwirken der verschiedenen Phasen des Projektlebenszyklus.«

1.2.1.3 Projektarten

Der Begriff »Projekt« umfasst den Bau eines Kernkraftwerkes genauso wie den Abteilungsumzug oder die Organisation eines Open-Air-Konzertes. Inhalte, Anzahl der Beteiligten, »Grad« der Veränderung für die Beteiligten, strategische Bedeutung des Projektes, Budget und Zeitrahmen sind wesentliche Unterscheidungskriterien für die Unterscheidung von Projekten.

Der Einsatz von Projektmanagementmethoden ist immer ein administrativer OverheadOverhead, den man sich unter Abwägung von Kosten und Nutzen leisten muss. Er muss in Relation zum Projektumfang stehen und sich in Summe, durch die geschaffene Effizienz der Projektdurchführung, rentieren. Dementsprechend sollte es selbstverständlich sein, diesen Overhead mit maßgeschneiderten Methoden und Instrumenten so gering wie möglich, jedoch auch so umfangreich wie nötig zu gestalten. Abhängig von der Projektart ist es wichtig, die richtige Auswahl und den Umfang für den adäquaten Instrumenten- und Methodeneinsatz zu finden (entsprechende »Flughöhe«).

Unterscheidung anhand des Inhalts:

Projektart

Merkmale/Beschreibung

InvestitionsprojekteInvestitionsprojekte

Sachanlagen werden gebaut oder beschafft (z. B. Gebäude, Anlagen, Großmaschinen)

Oft hohe Investitionskosten, Beauftragung meist durch Ausschreibung, öffentliches Interesse vorhanden

Planungsfokus: Finanzierung, Kostenplanung und -Controlling

Beispiele: Bau Staudamm, Erneuerung der Serverlandschaft in einem Unternehmen, Infrastruktur TK-Netz-Anbieter

OrganisationsprojekteOrganisationsprojekte

Aufbau- oder Ablauforganisationsstrukturen sollen geschaffen oder verändert werden

Wirkt sich auf Mitarbeitende im Unternehmen (in Summe oder Teile) aus

Interessen von Stakeholdern spielen eine große Rolle (z. B. Teilnehmende eines Musikfestivals)

Planungsfokus: Stakeholdermanagement, Kommunikationsplanung

Beispiele: Unternehmensfusionen, Reorganisation von Abteilungen, Einführung neuer Prozesse, Aufbau einer neuen Abteilung, Organisation von Events aller Art

F&EF&E Projekte

(Forschung und Entwicklung)

Zur Neuentwicklung oder Verbesserung von Produkten, Werkstoffen oder Dienstleistungen

Unbekanntes Verhältnis von Input und Output und damit geringe Planungssicherheit

Hoher Grad an Neuartigkeit

Planungsfokus: Umgang mit Neuartigkeit, interaktives Vorgehen mit regelmäßigen Feedbackzyklen zum kontinuierlichen Lernen und Weiterplanen

Beispiel: Produktentwicklung auf Basis neuer Technologien, wissenschaftliche Forschungsprojekte, Entwicklung eines Medikaments, Analyse des Nutzerverhaltens

Tab. 1: Klassifizierung der Projekte anhand des Inhaltes

Zusätzlich wird auch der Begriff der IT-Projekte genutzt, welcher jedoch zu unspezifisch ist, da er lediglich einen Bezug zur IT erkennen lässt. »IT-Projekte« können sich sehr unterschiedlich gestalten und vielschichtig sein. Der Aufbau einer Serverfarm oder der deutschlandweite Roll-out von Laptops für Lehrer, die Homeschooling anbieten, haben den Charakter eines Investitionsprojektes. Die Einführung eines großen Buchhaltungssystems sollte als Organisationsprojekt betrachtet werden, weil die Menschen in ihren Aufbau- und Ablaufstrukturen betroffen sind. Die Entwicklung eines neuen Softwaresystems auf der »grünen Wiese« trägt die Merkmale eines F&E-Projektes.

Also sollten IT-Projekte entsprechend den oben genannten Projektarten mit ihren spezifischen Eigenschaften zugeordnet werden und nicht als neue Projektart »IT-Projekt« definiert werden.

1.2.1.4 Projektklassen

Neben den Projektarten werden ergänzend auch Projektklassen unterschieden. Das ist dann von Vorteil, wenn ein Unternehmen innerhalb einer Projektart, z. B. vorwiegend Organisationsprojekte, eine Unterscheidung für eine bessere Einordnung und Vergleichbarkeit der Projekte haben möchte. Mit der Unterscheidung nach Projektklassen können die im Unternehmen vorhandenen PM-Standards individuell und maßgeschneidert an die jeweilige Projektklasse angepasst und wiederverwendet werden.

Klassifizierung nach der Projektgröße

In diesem Buch werden wir eine Vielzahl an unterschiedlichen Tools und Methoden kennenlernen. Nicht in jedem Projekt ist es sinnvoll, den gesamten Methodenkoffer in vollem Umfang anzuwenden. Kleine Projekte können sehr gut mit einigen ausgewählten Methoden in geringem Umfang organisiert werden: z. B. einer einfachen Zieldefinition, einem Phasenplan, einem tabellarischen Projektstrukturplan (PSP).

Für größere Projekte sind die in diesem Buch beschriebenen CEs mit den dazugehörigen Tools und Methoden in einer starken Ausprägung vollumfänglich notwendig und müssen vielleicht noch um weitere spezifische Methoden ergänzt werden. Andernfalls ist eine erfolgreiche Projektdurchführung nicht möglich.

Es ist daher zweckmäßig, nicht nur Projektarten, sondern auch Klassen zu definieren, um die unterschiedliche »Größe« der Projekte individuell zu berücksichtigen. Aus Gründen der Ergebnisorientierung und einer gewünschten Effizienz wollen wir nicht mit »Kanonen auf Spatzen schießen«.

Doch wie klassifiziert man die Größe eines Projektes? Nach Aufwand, Dauer, Bedeutung, Komplexität, Budget, Anzahl involvierter Parteien …?

Da jedes Unternehmen einzigartig ist, definiert es firmeninterne Klassifizierungsmerkmale für die Projektklassen der eigenen Projekte.

Klassifizierung nach Größe

Vereinfachtes Firmenbeispiel:

Projektklassen

C

B

A

Aufwand in PT*

50 bis 100

101–1000

Ab 1000

PM-Methoden

Steckbrief

Phasenplan

Wie C-Projekte

Zusätzlich:

PSP, Ressourcenplanung

Stakeholderanalyse

Wie B Projekte

Zusätzlich:

Kostenplanung Risikoanalyse

Monatliches Reporting an Vorstand

Ausbildungslevel der Projektleitung

IPMA® Level D

IPMA® Level C

IPMA® Level B

Tab. 2: Klassifizierung der Projekte anhand der Größe

*Alle Vorhaben unter 50 Personentagen (PT) Aufwand werden als Aufgaben und nicht als Projekte betrachtet.

Je nach Projektklasse wird die Vorgehensweise im Bezug auf den Methodeneinsatz für die Projekte verbindlich vorgegeben. Diese Vorgaben können sich beziehen auf:

den Einsatz und Umfang von bestimmten Projektmanagementmethoden,

die Qualifikation (Ausbildungslevel) der eingesetzten Projektleitung,

Bedarf eines Steuergremiums (z. B. Lenkungsausschusses),

Beschreibung der AKVs (Rollenbeschreibung) der Projektrollen,

vorgegebene Chancen-Risiko-Analyse mit Risikomanagement,

…

Klassifizierung nach Priorität

Neben der Klassifizierung nach der Größe des Projektes kann auch nach der Notwendigkeit (Durchführungsgrund) oder nach dem Beitrag zum Unternehmenserfolg klassifiziert werden.

Beispiele:

Klassifizierung nach Projektpriorisierung: 1 – 2 – 3 (z. B. 1 = gesetzlich erforderlich, 2 = strategisch, 3 = Kostenoptimierung)

Klassifizierung nach dem Produktlebenszyklus, z. B. der »BCG-MatrixBCG-Matrix« der Boston Consulting Group ( Question Marks, Stars, Cash Cows und Poor DogsPoor DogCash CowStarQuestion Mark

Mit der Projektklassifizierung können Unternehmen Projektmanagement standardisieren und gleichzeitig eine Möglichkeit der Skalierung für die unterschiedlichen Projektklassen schaffen. Dabei ist die Art der Skalierung nicht jedes Mal neu zu definieren.

Ergänzend besteht die Möglichkeit, über die unternehmensindividuellen Projektklassen das eigne Projektportfolio aufzubauen und dadurch transparenter zu steuern.

Klassifizierung nach Kundenprojekt oder internem Projekt

Kundenprojekte werden von einem externen Dienstleister nach formaler Beauftragung ganzheitlich oder durch Zuarbeit durchgeführt. Unternehmensinterne Projekte finden komplett innerhalb der eigenen Organisation statt und werden größtenteils mit eigenen Ressourcen durchgeführt.

Projektart

Merkmale/Beschreibung

Extern

(Kundenprojekte, AuftragsprojekteAuftragsprojekte)

Auftraggeber befindet sich außerhalb der eigenen Organisation

Ziel ist die Leistungserstellung meist auf der Basis eines Werkvertrags, welche zur Beendung des Projektes von der auftraggebenden Person abgenommen werden muss (Produktabnahme)

Rechtlicher Vertrag zwischen auftraggebender und auftragnehmender Person als Grundlage der Projektbeauftragung ist üblich

Planungsfokus: Leistungsdefinition und -controlling zur Erfüllung des Werkvertrags, Pflege der Kundenbeziehung

Beispiele: Maschinenbauunternehmen beauftragt die Erstellung eines Internetportals durch eine Agentur oder lässt sich ein neues Bürogebäude bauen

Intern

Auftraggeber gehört dem Unternehmen selbst an (Geschäftsleitung, Projektlenkungsgremien, Management) beauftragt z. B. die IT-Abteilung seines Unternehmens, ein neues CRM-System einzuführen

Anstoß und Finanzierungsbeträge i. d. R. von intern (zur Umsetzung eines strategischen Vorhabens können diese aber auch von außen kommen, z. B. Gesetzbeschluss, der in den IT-Prozessen berücksichtigt werden muss, sog. Zwangsprojekte)

Meist ist kein formaler rechtlich bindender Auftrag vorhanden

Planungsfokus: Einbinden des Projektes in die interne Unternehmensstruktur und Kommunikation, Abgleich mit der Unternehmensstrategie (Business Case)

Beispiele: Entwicklung neues Produkt, Organisation Betriebsfeier, Umstellung DSGVO, Produktanpassung zur Einhaltung neuer Abgasnormen

Tab. 3: Klassifizierung der Projekte anhand des Auftraggebers

Externe Projekte folgen etwas anderen Regeln als sog. interne Projekte. An dieser Stelle soll nur auf ein paar wichtige Punkte eingegangen werden:

Doppelte Projektorganisation: Meist existiert sowohl auf der beauftragenden Seite (Kundin oder Kunde) als auch auf der ausführenden Seite (Dienstleister) eine komplette Projektorganisation mit Auftraggeber, Projektleitung und Team.

Eine detaillierte Projektplanung wird nur auf der Seite des Dienstleisters durchgeführt. Auf Kundenseite gibt es meist nur eine Grobplanung zum Angebotscontrolling und eine Planung der möglichen Zuarbeit.

Das Projekt beginnt auf der Seite des Kunden viel früher (Initialisierungsphase) als auf der Seite des Dienstleisters. Der Dienstleister wird erst in das Projekt integriert, wenn viele Entscheidungen über Umfang, Zeitrahmen, Budget und Projektdurchführung bereits getroffen sind.

Eine Projektleitung auf Seite des Dienstleisters sollte die Besonderheiten eines Kundenprojektes kennen und sie entsprechend in der Risiko- und Stakeholderanalyse sowie im Rahmen anderer Aspekte der eigenen »Dienstleister-Projektplanung« berücksichtigen.

1.2.2 Permanente Systeme und Strukturen

1.2.2.1 Stammorganisation

Stammorganisation [engl.: Permanent or Parent Organization]Stammorganisation

»Synonyme: BasisBasisorganisation-, BetriebsorganisationBetriebsorganisation

Ständige (projektunabhängige) Organisation, z. B. eines Unternehmens, Betriebs oder einer Behörde, im Gegensatz zur (temporären) Projektorganisation. Grundsätzlich sind darunter sowohl die Aufbauorganisation als auch die Ablauforganisation und alle diesbezüglichen, auf Dauer angelegten Regelungen zu verstehen. Der Begriff wird in der Praxis aber oft ›nur‹ für Organisation im institutionellen Sinne verwendet.« (Motzel)

Abb. 5: Beispiel Stammorganisation mit Projekt

Im Gegensatz zur Projektorganisation haben Stammorganisationen eine längere Existenzberechtigung und behaupten sich in ihrem Umfeld. Projektbeteiligte können aus der Stammorganisation oder von externen Stellen kommen und nach Projektende wieder dorthin zurückkehren.

Die von der Stammorganisation gestellten Projektmitglieder sind z. B. Projektleitung, Mitglieder des Projektkernteams und erforderliche Experten. Dadurch übernimmt das Projekt zwangsläufig die Kultur der Stammorganisation.

Dies ist auch der Grund, warum die Grundregeln der Stammorganisation von den Projektbeteiligten (Projektmanager, Teammitglieder, etc.) gekannt werden sollten. Kommunikation, Integration des Projektes in das Unternehmen verlaufen dann viel reibungsloser, weil eine ähnliche Kultur vorliegt.

1.2.2.2 Lenkungsausschuss

Lenkungsausschuss [engl.: Steering Committee]Lenkungsausschuss

»Synonym: SteuerungsgremiumSteuerungsgremium, SteuerungsausschussSteuerungsausschuss, SteuerkreisSteuerkreis, LenkungskreisLenkungskreis

Übergeordnetes Entscheidungsgremium, z. B. für ein einzelnes Projekt oder Programm oder für eine Gruppe von Projekten und/oder Programmen (Projektportfolio). Für ein einzelnes Projekt kann der Lenkungsausschuss ein internes Gremium des Projektträgers aus bevollmächtigten Vertretern des Auftraggebers/Investors sein, ggf. aber auch externe Projektbeteiligte miteinbeziehen. Der Projekt-Lenkungsausschuss sollte so klein wie möglich gehalten werden; er dient dem Projektleiter als Berichts-, Entscheidungs- und Eskalationsgremium.« (Motzel)

Abb. 6: Stammorganisation und Projektorganisation

Der Lenkungsausschuss wird vom Projektauftraggeber geleitet. Seine Zusammensetzung wird durch Teile des Managements der Stammorganisation ergänzt. Stakeholder mit hoher Macht und hohem Konfliktpotenzial können als partizipative Stakeholdermaßnahme in den Lenkungsausschuss berufen werden (s. Kap. 3.3.7 Stakeholder (4.5.12)). Durch die Mitarbeit im Lenkungsausschuss haben sie eine stärkere Möglichkeit der Mitgestaltung und Beeinflussung und dadurch weniger Gründe, dem Projekt kritisch gegenüberzustehen.

In kleineren unternehmensinternen Projekten kann ein Lenkungsausschuss auch nur aus dem Teamleiter, dem Projektleitenden und evtl. einer zusätzlichen Führungskraft, wie z. B. einem Produktmanager oder Abteilungsleiter, bestehen.

1.2.2.3 Projektmanagementbüro

»Sag mir, wie ein Projekt beginnt und ich sage Dir, wie es endet.«Projektmanagement-Weisheit

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

»Hinweis: Die Benennungen ›Projektbüro‹ und ›Projektmanagement-Büro‹ werden in der Praxis häufig synonym benutzt, obwohl Unterschiedliches darunter verstanden wird. Die Unterschiede betreffen sowohl die institutionelle Einrichtung als auch die damit verbundenen Aufgabenstellungen. In der Praxis findet sich – je nach Sichtweise und Projekt(e)situation – das folgende Spektrum an Interpretationen:

(1) Zentrale Verwaltungsstelle für ein einzelnes Projekt – oft auch physisch als ›Büro‹ gemeint (Ò Projektsekretariat, Projektassistenz).

(2) Projektexterne Projektcontrolling-Stelle für ein einzelnes Projekt oder ggf. für mehrere Projekte.

(3) Servicestelle für das Projektmanagement einer Organisation oder Organisationseinheit mit der Aufgabe, Mitarbeiter im Projektmanagement auszubilden, Prozesse zu vereinheitlichen, Standards zu entwickeln und/oder einen Pool von Projektleitern bereitzustellen.« (Motzel)

Der Begriff »Projektmanagementbüro (PMO)« steht für ein Linienteam, welches die Projektorganisation und Projektprozesse projektübergreifend verantwortet. Es unterstützt die ihm zugeordneten Projekte und schafft Transparenz über das Projektportfolio. Deshalb spricht man auch von der Supportfunktion des PMO:

Administrative Funktion: Service und zentrale Dienstleistungen

Kontrollfunktionen: Steuerung des Portfolios anhand von standardisierten Kennzahlen und einheitlichen Statusberichten

Koordinationsfunktion: Schnittstellen und Portfoliomanagement

Optimierungsfunktion: kontinuierliche Verbesserung von Methoden, eingesetzter Software und der Qualifikation des Projektpersonals

Abb. 7:

Funkionen des Project Management Office

In manchen Organisationen wird der Begriff »Projektbüro (PO)« synonym mit dem Begriff »Projektmanagementbüro (PMO)« verwendet. Dies ist jedoch nicht korrekt, da das PO für ein einzelnes Projekt, das PMO jedoch für alle Projekte einer Organisation zuständig ist. Auch die AKV (siehe Kapitel 3.3.5.6) unterscheiden sich grundsätzlich.

1.2.3 Projekte, Programme und Portfolios

Unternehmen, welche Projekte professionell durchführen (projektorientierte Unternehmen), ergänzen die Projektlandschaft neben Projekten auch mit Programmen und Projektportfolien.

Projekt

Programm

Portfolio

Anzahl pro Firma(Beispiel)

50–100

1–5

1

Leitung

Projektmanagement

Programmmanagement

Portfoliomanagement

Dauer

Projektdauer

Programmdauer

Keine Begrenzung (kein Start/Ende)

Ziel

Umsetzung eines strategischen Ziels oder eines Zwangsprojektes

Übergeordnetes Programmmanagement mehrerer gemeinsam strukturierter Projekte, die zusammenhängend gemeinsam zur Erreichung eines oder mehrerer strategischen Ziele durchgeführt werden. Nutzung von Synergien zwischen diesen Projekten (z. B. einheitliche Governance, gemeinsame Ressourcenplanung, einheitliches Stakeholder-/Risikomanagement etc.) 

Steuerung aller Projekte/Programme einer Organisationseinheit oder des gesamten Unternehmens zur Erfüllung der Unternehmensstrategie, basierend auf dem jährlichen Portfolio-Budget und der Ressourcenverfügbarkeit der Organisation

Tab. 4: Vergleich Projekt, Programm und Portfolio

In einem projektorientierten Unternehmen wird normalerweise nicht nur ein Projekt, sondern es werden mehrere Projekte überlappend und parallel durchgeführt. Mit der Projektlandschaft werden die strategischen Ziele des Unternehmens umgesetzt.

Programme

Unternehmen, die bereits Erfahrung im Management von Einzelprojekten haben, bilden bei Bedarf zusammenhängende Programme. In Programmen werden mehrere Projekte strukturiert und zusammengefasst, welche gemeinsam zur Erreichung eines oder mehrerer strategischen Ziele beitragen sollen.

Beispiel: Digitalisierung

Ein mittelständisches Unternehmen hat sich zum Ziel gesetzt, die eigene Digitalisierung auszubauen. Dafür wird ein Programm aufgesetzt. Diesem Programm werden mehrere Projekte zugeordnet, die alle zur Digitalisierung beitragen:

Umstellung der Telefonie auf mobile Endgeräte,

Einführung eines einheitlichen CRM-Systems (Customer Relationship Management),Customer Relationship Management

Gesichertes WLAN in allen Firmengebäuden und Räumen,

Homeoffice-Zugänge über VPN (Virtual Private Network),

Umstellung der internen Server auf externe Cloud Lösungen,

…

Die Programmleitung übernimmt eine Projektleitung mit »IPMA® Level B«-Zertifikat. Die Projektleitenden haben alle ein »IPMA® Level C«-Zertifikat. Zusätzlich wird die Programmleitung durch ein Programm Office unterstützt, welches die übergeordnete Koordination und Steuerung der Einzelprojekte übernimmt, auf die Einhaltung von Qualitätsstandards achtet, große Teile der Stakeholderkommunikation zentral durchführt und somit die Einzelprojekte entlastet.

Durch Bildung eines Programmes werden Synergien zwischen den Projekten transparent gemacht und können somit gehoben werden. Die Qualität des Programmes lässt sich zentral besser überwachen und aufrechterhalten als in mehreren voneinander unabhängig geführten Einzelprojekten. In das Unternehmen hinein wirkt ein Programm mächtiger als mehrere Einzelprojekte. Damit können wichtigen Themen, die vielleicht auf Widerstand stoßen könnten, einfach und besser durchgesetzt werden.

Mit Programmen sollte jedoch nicht inflationär umgegangen werden, da die Programmorganisation wichtige und umfangreiche Ressourcen bindet. Werden zu viele Projekte zu Programmen erklärt, verlieren sie ihre Bedeutung und Wirkkraft.

Projektportfolio

Alle Projekte und Programme innerhalb eines Unternehmensbereiches oder des Gesamtunternehmens werden in einem Projektportfolio organisiert. Jedes einzelne Projekt oder Programm muss sich »bewerben«, um in das Portfolio des Unternehmens aufgenommen zu werden. Dies geschieht mit dem genehmigten Projektsteckbrief oder dem intern erteilten Projektauftrag. Das Portfoliomanagement entscheidet über die Aufnahme anhand unterschiedlicher Kriterien, wie z. B.:

Beitrag zur Umsetzung der Unternehmensstrategie (Ò Lohnt es sich, das Projekt durchzuführen, ist die Wirtschaftlichkeit oder Wichtigkeit gegeben?)

Aktuelle Ressourcenverfügbarkeit von Projektpersonal (Ò Haben wir momentan genügend Ressourcen, oder müssen wir noch warten, bis andere Projekte abgeschlossen sind?)

Vorhandenes Portfolio-Budget des Unternehmens zur Durchführung von Projekten

(-> Wie verteilt sich das Portfolio-Budget auf die einzelnen Projekte und Programme? Welche werden neu finanziert, weiterfinanziert oder gestoppt?)

Können mehrere Projekte zu einem Programm zusammengeschlossen werden, um durch Synergien die Durchführung effizienter und effektiver zu gestalten?

…

Der Portfoliomanager steuert mit seinem Projektportfolio die strategische Umsetzung der Unternehmensziele. Oft wird das Projektportfoliomanagement auch als eine Teilaufgabe des PMO (Project Management Office) gesehen, womit die PMO-Leitung auch die Rolle eines Portfoliomanagers einnimmt.

Manchmal werden Programm- und Portfoliomanager verwechselt. Sie unterscheiden sich jedoch sehr in ihren Aufgaben und Verantwortungen:

Programmmanager

Portfoliomanager

Position

Kapitän des Programms

Navigator über die Projektlandschaft

Fokus

Programm

Gesamtsicht über die Projekte

Aufgaben

Führungsaufgaben

Muss unmittelbar in die Projekte eingreifen, wenn die Situation es erfordert 

Koordinationsaufgabe

Analysiert und stellt die Probleme der Projektleiter dem Auftraggeber und dem Projekt-Board dar 

Budget-Verantwortung

Hat die Budget-Verantwortung

Hat keine Budget-Verantwortung, wacht über das Gesamtbudget 

Personalverantwortung

Hat die Personalverantwortung

Analysiert die Personalverantwortung in der Projektlandschaft 

Aufgabendauer

Aufgabe endet mit Abschluss des Programms 

Daueraufgabe, solange die Projektlandschaft im Unternehmen zu koordinieren ist 

Herausforderungen

Ist bei externen Projekten dem rauen Wind des Kunden ausgesetzt 

Muss sich mit der Unternehmenspolitik, Macht und seiner eigenen Ohnmacht in den einzelnen Projekten auseinandersetzen 

Tab. 5: Aufgaben und Verantwortungen der Programm- und Portfoliomanager

1.2.4 Projektablauf- und -aufbauorganisaiton

Die temporären Projektorganisationsformen folgen einer jeweils für sie typischen definierten Aufbau- und Ablauforganisation.

AufbauorganisationAufbauorganisation [engl.: Project Organizational Structure]

Synonym: Projektaufbauorganisation

Gesamtheit der festgelegten Verantwortungsträger und der zugehörigen verbindlichen Regelungen für Zuständigkeiten, Befugnisse, Weisungsrechte und Berichtspflichten in einer Organisation, in der Regel dargestellt in einem Organigramm.

Die Projektaufbauorganisation ist das Ergebnis der Organisationsgestaltung im Projekt in Bezug auf die »statischen« Aspekte der Projektorganisation – im Gegensatz zur Projektablauforganisation in Bezug auf die »dynamischen« Aspekte. Dennoch kann sich die Projektaufbauorganisation je nach Erfordernis während der Projektabwicklung (z. B. in einzelnen Projektphasen) verändern. Allgemeine Gestaltungsprinzipien von Aufbauorganisationen sind »Zentralisation« und »Dezentralisation«.

Eine Projektaufbauorganisation beschreibt die organisatorischen Einheiten und Rollen im Projekt. Diese können folgende sein:

Arten der Projektorganisation,

Projektmanagementbüro (PMO),

Lenkungsausschuss (Synonyme: Lenkungskreis, Steuerkreis, Steering Commitee)

Einzelne Projektrollen (beschrieben über AKV oder RACI-MatrixRACI-Matrix)

Aufbauorganisationen werden in Organigrammen hierarchisch dargestellt und beschrieben, deren Weisungsrecht von oben nach unten zeigt. Die grafische Darstellung entspricht der Berichts- und Eskalationspflicht sowie den gewünschten Führungsebenen.

Ablauforganisation [engl.: Process Organization]

Synonym: Projektablauforganisation

Definition, Anordnung, Ausgestaltung und Beschreibung der Abläufe (Prozesse) und Regeln für die Durchführung eines Vorhabens, z. B. eines Projekts, und gleichzeitig das Ergebnis dieser Tätigkeiten einschließlich der entsprechenden Vereinbarungen (Arbeits- und Verfahrensanweisungen). Die Projektablauforganisation ist das Ergebnis der Organisationsgestaltung im Projekt in Bezug auf die »dynamischen« Aspekte der Projektorganisation – im Gegensatz zur Projektaufbauorganisation in Bezug auf die »statischen« Aspekte.

Organisatorische Abläufe (Prozesse) werden in Flussdiagrammen dargestellt (z. B. Flow-Chart).Flow-Chart Beispiele von definierten Prozessen im Projektmanagement sind:

Projektmanagementphasen der DIN

Projektgenehmigung

Zielfindungsprozess

Budgetfreigabe

Änderungsmanagement

Ressourcenbeschaffung

Controlling

Produktabnahmeprozess

Stakeholdermanagement

Chancen-/Risikomanagement

Sowohl die Aufbau- als auch die Ablauforganisation sind stark vom jeweiligen Projektdesign geprägt und variieren je nach Projektart, Projektklasse und gewählter Projektorganisation. Die Definitionsmöglichkeiten für die jeweils individuellen Projekte eines Unternehmens sind in dessen Projektmanagement-Handbuch beschrieben.

1.2.5 Projektmanagement-Handbuch (Projektmanagement-Manual)

Unternehmen, die regelmäßig Projekte durchführen, entwickeln eigene, firmenspezifische Projektmanagementstandards, die für alle Projekte relevant sind. Die Basis hierfür bieten zum einen internationale Projektmanagementstandards (z. B. IPMA®, PMI, PRINCE2 usw.) und zum anderen Branchenspezifika, die individuell formuliert werden. Zusammengefasst werden diese Standards in einem Projektmanagement-HandbuchProjektmanagement-Handbuch.

Abb. 8:

Struktur eines Projektmanagement-Handbuchs

Das Projektmanagement-Handbuch kann auch folgende andere Bezeichnungen haben: z. B. Projektmanagement-Leitfaden, Projektmanagement-Manual, Unternehmensrichtlinie PM, Designpapier PM etc.

Die Mitarbeitenden des PMO erstellen das Projektmanagement-Handbuch und überarbeiten es regelmäßig im Sinne eines kontinuierlichen Verbesserungsprozesses. Dadurch fließen laufend Ergänzungen und neue Anforderungen ein. Das PMO bildet sein Projektpersonal auch auf der Basis des Projektmanagement-Handbuchs aus.

Eine Abgrenzung des Projektmanagement-Handbuchs gegenüber dem Projekthandbuch ist, dass sich das Projekthandbuch lediglich auf ein spezifisches Projekt bezieht. Das Projektmanagement-Handbuch hingegen gilt als Regelwerk für alle Projekte im Unternehmen. Insofern basiert das Projekthandbuch jedoch auf dem Projektmanagement-Handbuch und benutzt es als »Blaupause«, um sämtliche unternehmensinternen Vorgaben für die Projektdurchführung zu nutzen und einzuhalten.

1.2.6 Projektmanagementstandards

Um die unterschiedlichsten Projekte in ihrer Vielfalt und Ausprägung individuell abbilden zu können, existieren verschiedene internationale Projektmanagementstandards. Sie unterscheiden sich vereinfacht wie folgt:

kompetenzbasiert

prozessbasiert

agile

Ein weiterer Unterschied erfolgt durch die Abgrenzung von Personenzertifizierungen im Gegensatz zu einer Zertifizierung von Prozessen.

Abb. 9:

Übersicht Projektmanagementstandards und Zertifizierungen

IPMA® IPMA®

Die International Project Management Association (IPMA®) ist eine Dachorganisation, welche über 70 nationale Ländergesellschaften hinweg die Professionalisierung von Projektmanagement weiterentwickelt. Deutschland wird durch die GPM (Gesellschaft für Projektmanagement) in der IPMA® vertreten. Basierend auf ihrer Zusammenarbeit formuliert sie in regelmäßigen Abständen einen neuen PM-Standard (ICB, Individual Competence Baseline), welcher die Grundlage für international abgestimmte Zertifizierungsverfahren ist.

Die IPMA® entwickelt Standards, die kompetenzbasiert sind. Sie beziehen sich auf die Handlungskompetenz von Personen und Organisationen.

Abb. 10:

ICB als kompetenzbasierter Standard.

Die ICB enthält keine konkreten Prozesse oder Methoden, sondern definiert Handlungskompetenzen, die eine Projektleitung zum erfolgreichen Leiten von Projekten braucht. Die ICB ist branchenunabhängig formuliert. In den Qualifizierungen erlernen die Projektleitenden abhängig von Branche und dem konkreten Projekt, Methoden und Vorgehensweisen einzusetzen. Die Qualifizierung und Zertifizierung legen Wert auf die Darstellung des Könnens: Übertragung des PM-Wissens auf ein eigenes Projekt (Report), Fallstudien, Assessments (Role Based Interview) und nicht nur auf die Abfrage von Wissen.

Der aktuelle Standard der IPMA® ist die ICB4.0. Er teilt sich in drei Kompetenzbereiche und 28 Kompetenzelemente auf:

Abb. 11:

Die 28 Kompetenzelemente der ICB4.0 mit Kennzeichnung Relevanz Basiszertifikat. Das »Eye of Competence« ist Eigentum der IPMA® und urheberrechtlich geschützt. Der Abdruck erfolgt mit freundlicher Genehmigung des Rechteinhabers.

Die 28 Kompetenzelemente gelten für alle Zertifizierungen, von Level D bis Level A. Je nach Level wird jedoch auf einer unterschiedlichen Kompetenzstufe qualifiziert und zertifiziert.

Abb. 12:

Kompetenzstufen

Für das Basiszertifikat werden nur ausgesuchte Kompetenzelemente, vorwiegend aus dem Bereich Practice, in der Zertifizierung berücksichtigt.

Die drei Kompetenzbereiche sind mit drei unterschiedlichen Farben markiert und dadurch auch optisch gut zu unterscheiden. Wir haben für dieses Buch die Farbcodes der drei Bereiche übernommen, um eine bessere Erkennbarkeit und Orientierung der drei Kompetenzbereiche zu unterstützen.

Der IPMA®-Standard ist »hybrid«. Das bedeutet, die Kompetenzelemente umfassen sowohl klassische (planbasierte) als auch agile Methoden.

PMI

Das Project Management Institute (PMI) ist die an Mitgliedern größte unter den standardisierenden Organisationen. Ihr Standard wird im PMBOK Guide beschrieben und ist im Gegensatz zur ICB prozessbasiert. Das PMI ist zentral in den USA angesiedelt.

PRINCE2

Der PRINCE2-Standard PRINCE2(Projects in Controlled Environment) wurde in England entwickelt. Ursprünglich als verbindlicher Standard für IT-Projekte in Regierungsprojekten, wird er mittlerweile auch in anderen Branchen eingesetzt. Der Standard ist ebenfalls prozessorientiert.

PM²

Seit 2014 gibt es einen Projektmanagementstandard, den die Europäische Union definiert hat. Der Standard bezieht sich auf Methoden von IPMA®, PMI und PRINCE2. Der Standard soll speziell die Qualität von EU-Projekten verbessern.

Scrum

Es gibt mehrere agile Standards (z. B. Kanban, Design Thinking (Gürtler/Mayer 2013), LeSS, SAFe, Nexus). An dieser Stelle wird stellvertretend Scrum beschrieben. Der Scrum Standard wird im Scrum Guide als Leitfaden (Sutherland/Schwaber 2020) dokumentiert. Scrum folgt einer inkrementell iterativen Vorgehensweise. Das bedeutet, dass nach einer initialen Planung, in kontinuierlichen Arbeits- und Feedback-Zyklen (Sprints) nach jedem Sprint ein fertiggestelltes Inkrement ausgeliefert wird.

Der Scrum Guide enthält die Definition von Scrum und dient als Rahmenwerk für den Einsatz des agilen Frameworks. Er beschreibt alle Elemente von Scrum und ermöglicht den Praxiseinsatz für die erforderlichen Prozesse, Techniken und Methoden.

1.2.7 Normen zum Projektmanagement

DIN 69901

Die DIN-Normenreihe 69901:2009-01 »Projektmanagement –Projektmanagementsysteme« beschreibt unterschiedliche Aspekte des Projektmanagements. In den Teilen 1–5 werden Grundlagen, Prozesse, Methoden, Datenmodell und Begriffe definiert. Die Norm ist branchenunabhängig formuliert. Die DIN-Norm ist ein Dokument, das Anforderungen des Verfahrens festlegt. Sie schafft somit Klarheit über deren Eigenschaften und sichert die Qualität.

DIN ISODIN ISO 21500:2016-02

Die DIN ISO 21500:2016 ist eine deutsche Norm. Sie basiert auf der ISO-Norm 21500, welche als internationaler Leitfaden zum Projektmanagement in der letzten Form 2012 aktualisiert wurde. Sie beschreibt Begriffe, die im Projektmanagement als bewährte Praxis allgemein für alle Projekte gelten. Die ISO 21500 gilt als kleinster gemeinsamer Nenner der bekannten Weltstandards wie PMI, IPMA® oder PRINCE2. Die Leitlinie beschreibt damit die wesentlichen, allgemein anerkannten Bestandteile des Projektmanagements, in einer äußerst komprimierten und verständlichen Form. Einzelpersonen können sich zu dieser Norm von der IHK zertifizieren lassen. Unternehmen können ihr Projektmanagementsystem an der ISO 21500 ausrichten, auditieren und zertifizieren lassen. Die aktuellen Definitionen nach DIN können im Internet eingesehen werden.

1.3 CE Compliance, Standards und Regularien (4.3.3)

Compliance, also die Regeltreue von Unternehmen sich an betriebswirtschaftliche und rechtswissenschaftliche Regeln, Richtlinien und Verordnungen (auch unternehmensintern) zu halten, gewinnt in den letzten Jahren immer mehr an Bedeutung. Durch regelkonformes Verhalten vermindert eine Projektleitung Risiken und steigert die Effizienz sowie Effektivität des Projektes.

Dabei unterstützt sie gleichzeitig die Einhaltung der rechtsstaatlichen Regeln und schützt das Unternehmen vor möglichen Strafzahlungen bei Nichteinhaltung.

Compliance [engl.: Compliance]

»Die Kompetenz Compliance, Standards und Regularien definiert, wie der Einzelne die externen und internen Einschränkungen in einem bestimmten Bereich wie z. B. einem Land, einem Unternehmen oder einer Branche interpretiert und sie aufeinander abstimmt.« (ICB4)

»Ordnungsgemäße Einhaltung von vorgegebenen Gesetzen und Regeln. Seit der ICB4.0 ist ›Compliance, Standards und Regulations‹ ein Kompetenzelement (Perspectives 3), übersetzt in die NCB 4.0 mit ›Compliance, Standards und Regularien‹. Dieses Kompetenzelement definiert die Interpretation und Anwendung von internen und externen Rahmenbedingungen, insbesondere Restriktionen. Compliance wird dabei als Prozess gesehen, wie Vorgaben adäquat umgesetzt werden. Diese Vorgaben können formal oder informell bzw. verpflichtend oder freiwillig sein.« (Motzel)

»Standards und Vorschriften beeinflussen und definieren die Art und Weise wie Projekte, Programme und Portfolios organisiert und gesteuert werden sollen, um durchführbar und erfolgreich zu sein.

Standards und Vorschriften stehen in Verbindung mit Anforderungen in Compliance, die die gesetzlichen und rechtlichen Vorschriften einschließen, Verträge und Vereinbarungen, geistiges Eigentum und Patente, Sicherheit, Gesundheit und Umweltschutz (SGU) sowie berufliche Standards.« (ICB4)

Abb. 13: Das Projekt und sein gesetzlicher (sanktionsfähiger) Ordnungsrahmen (PM4, GPM 2019)

1.3.1 Datenschutz und Datensicherheit

Im Verlauf eines Projektes verantwortet die Projektleitung die Einhaltung aller Regelungen zum Datenschutz und zur Datensicherheit. Dies betrifft sowohl personenbezogene Daten der Projektmitarbeitenden, Anwender, Arbeitskolleginnen und -kollegen als auch die vertrauliche Behandlung von überlassenen Daten von z. B. Kunden, Lieferanten oder Partnern.

Der Datenschutz für Deutschland wird im Bundesdatenschutzgesetz (BDSG) geregelt und in der DSGVO (Datenschutzgrundverordnung) ausgeführt.

Gegenstand und Ziel der DSGVO ist der Datenschutz, welcher folgende gesetzliche Regelungen, bezogen auf personenbezogene Daten, umfasst:

Schutz vor unerlaubter Erhebung,

Schutz vor unerlaubter Speicherung,

Schutz vor unerlaubter bzw. missbräuchlicher Verarbeitung,

Schutz vor unerlaubter Weitergabe,

Schutz des Rechts auf informelle Selbstbestimmung,

Schutz der Privatsphäre,

Schutz des Persönlichkeitsrechts bei der Datenverarbeitung.

Um Datenschutz gewährleisten zu können, ist die Datensicherheit eine wichtige Voraussetzung. Ziel der Datensicherheit ist es, digitale Informationen und technisch Daten und IT-Systeme jeglicher Art in ausreichendem Maße gegen unberechtigten Zugriff, Verlust, Beschädigung, Manipulation, Diebstahl und andere Bedrohungen zu sichern.

1.3.2 Vorschriften für Sicherheit, Gesundheit und Umweltschutz

Das deutsche Arbeitsschutzgesetz (ArbSchG) setzt die EU-Richtlinien zum Arbeitsschutz um. Die vollständige Bezeichnung des Arbeitsschutzgesetzes lautet:

»Gesetz über die Durchführung von Maßnahmen des Arbeitsschutzes zur Verbesserung der Sicherheit und des Gesundheitsschutzes der Beschäftigten bei der Arbeit.«

Ziel des Arbeitsschutzgesetzes ist es, die Gesundheit aller Mitarbeitenden zu verbessern. Im Arbeitsschutzgesetz sind unter anderem Gefährdungsbeurteilungen, die Überwachung der Wirksamkeit von Präventionsmaßnahmen und Unterweisungen festgeschrieben.

Beispiele wichtiger ArbeitsschutzvorschriftenArbeitsschutzvorschriften und deren Verordnungen:

Arbeitsschutzgesetz (ArbSchG)

Arbeitsstättenverordnung (ArbStättV)

Baustellenverordnung (BaustellV)

Betriebssicherheitsverordnung (BetrSichV)

Gefahrstoffverordnung (GefStoffV)

Daneben gelten noch andere gesetzliche Regelungen und rechtsverbindliche Vorschriften, deren Einhaltung in der Verantwortung der Projektleitung in Abstimmung mit dem Personalbereich steht:

Beispiele ArbeitsrechtArbeitsrecht:

Arbeitszeitgesetz (ArbZG) – beachten der täglichen Höchstarbeitszeit

Mutterschutzgesetz (MuSchG) – Beschäftigungseinschränkungen bei Schwangerschaft (SGB IX)

Jugendarbeitsschutzgesetz (JarbSchG) – schutzwürdige Belange Jugendlicher/Praktikanten

Urlaub (BurlG)

Arbeitnehmerüberlassung (AÜG)

Arbeitnehmerentsendung (AentG)

Beispiele GesundheitsschutzGesundheitsschutz:

Infektionsschutzgesetz (InfSG)

Lebensmittelhygieneverordnung

Unfallverhütungsvorschriften (§ 15 SGB VII)

Verordnung zur arbeitsmedizinischen Vorsorge (ArbMedVV)

UmweltschutzUmweltschutz:

Regelungen gemäß den Anforderungen des Umweltschutzgesetzes (USG) einschließlich der Einhaltung gesetzlicher Grenzwerte bei Emissionen und der Einhaltung behördlicher Auflagen.

Sozialversicherungsrecht:Sozialversicherungsrecht

Vermeidung von Scheinselbstständigkeit freier Mitarbeitender,

Meldepflicht zur Sozialversicherung für Arbeitnehmer (§ 28a SGB IV),

Mini-Job-Zentrale bei geringfügig Beschäftigten.

1.3.3 Gefährdungsanalyse

Die Begriffe der Gefährdungsanalyse oder Gefährdungsbeurteilung werden in der Literatur oft synonym verwendet.

Laut der BfGA (Beratungsgesellschaft für Arbeits- und Gesundheitsschutz mbH) umfasst die Gefährdungsbeurteilung:

»… als zentrales Element des betrieblichen Arbeitsschutzes die systematische Beurteilung der für die Beschäftigten mit ihrer Arbeit verbundenen Gefährdungen und Belastungen. Sie bildet damit eine wesentliche Grundlage für die Ableitung zielgerichteter Arbeitsschutzmaßnahmen. Die gesetzliche Basis für die Gefährdungsbeurteilung ist das Arbeitsschutzgesetz (§§ 5, 6)

Anhand der Ergebnisse der Gefährdungsbeurteilung sind die erforderlichen Maßnahmen zur Verbesserung des Arbeitsschutzes festzulegen. Betriebe mit zehn oder mehr Beschäftigten müssen die Ergebnisse und die Überprüfung dokumentieren.«

Es sind im Arbeitsschutzgesetz keine Fristen zur Wiederholung der Gefährdungsanalyse beschrieben. Eine regelmäßige Überprüfung und Wiederholung ist jedoch ratsam, um so Verbesserungsmöglichkeiten erkennen zu können.

1.3.4 Compliance-Anforderungen einzelner Wirtschaftssektoren

Unternehmen haben die Bereitschaft, die staatlichen Stellen bei der Durchsetzung dieser Regeln zu unterstützen (z. B. Geldwäschebekämpfung, Vermeidung der persönlichen Vorteilsnahme, etc.).