IPMA(R) Level D - Report E-Book

Maik Uhlig

• Herausgeber: BoD - Books on Demand
• Kategorie: Fachliteratur
• Sprache: Deutsch

Seitenzahl: 260

Veröffentlichungsjahr: 2025

Beschreibung

Das Handbuch erklärt alle Themen des Reports nach dem neuen Leitfaden (Februar 2025). Mit vielen Beispielen und Tipps für die Praxis und Bezug auf die alternative Darstellung in hybriden Reports.

Leseprobe

Inhalt

Vorwort zur zweiten Auflage

Geleitwort von Romy Kopsch, COO mycareernow GmbH

1 Management Zusammenfassung

1.1 Angaben zum Projekt

1.1.1 Big Picture

1.1.2 Project Canvas

1.2 Eigene Position im Projekt

2 Strategie 04.03.01

2.1 Beschreibung des Business Case zum Projekt

2.2 Nennung der kritischen Erfolgsfaktoren des Projekts

3 Governance, Strukturen und Prozesse 04.03.02

3.1 Begründung, warum es sich bei dem Vorhaben um ein Projekt handelt.

3.2 Nennung der Projektart des Projektes und Begründung der Einordnung

3.3 Nennung und Begründung der Klassifizierung des Projekts aus Sicht der Organisation

3.4 Nennung der Strukturen der Organisation

3.4.1 Der Lenkungsausschuss: (LA)

3.4.2 Programm-Management

3.4.3 Projektportfolio-Management

3.4.4 Projektoffice (PO)

3.4.5 Projektmanagementoffice (PMO)

4 Anforderungen und Ziele 04.05.02

4.1 Steckbrief

4.2 Ziele

4.2.1 Beispiel Ziele

4.3 Zielkonflikt

4.3.1 Zielidentität

4.3.2 Zielkomplementarität

4.3.3 Zielneutralität

4.3.4 Zielkonkurrenz

4.3.5 Zielantinomie

5 Stakeholder 04.05.12

5.1 Projektumfeld

5.2 Schnittstellen

5.2.1 Ansprechpartner:

5.2.2 Auswirkung auf andere PM-Methoden:

5.3 Stakeholder-Portfolio

5.4 Stakeholder-Interessen

6 Macht und Interessen 04.03.04

6.1 Stakeholder-Bewertung

6.1.1 Macht durch Belohnung (REWARD POWER)

6.1.2 Macht durch Zwang (COERCIVE POWER)

6.1.3 Macht durch Legitimation (LEGITIMATE POWER)

6.1.4 Macht durch Identifikation (REFERENT POWER)

6.1.5 Macht durch Wissen (EXPERT POWER)

6.1.6 Macht durch Informationsvorsprung (INFORMATIONAL POWER)

6.2 Machtpromotoren

7 Chancen und Risiken 04.05.11

7.1 Projektrisiken

7.2 Maßnahmen

7.3 Chance

8 Projektdesign 04.05.01

8.1 Erfolgskriterien

8.2 Vorgehensweise

8.2.1 Planbasiert

8.2.2 Hybrid

9 Organisation, Information und Dokumentation 04.05.05

9.1 Projektorganisationsform

9.1.1 Auswahl und Begründung

9.1.2 Visualisierung

9.1.3 Agile Visualisierung

9.2 Rollen

9.3 Kommunikationsmatrix

10 Ablauf und Termine 04.05.04 Teil 1

10.1 Phasenplan

10.1.1 Wasserfallmodell

10.1.2 V-Modell

10.1.3 Produktionsentstehungsprozess (PEP)

10.1.4 Eigene Vorgehensweise:

10.1.5 Beispiel Phasenplan

10.1.6 Beispiel hybride Darstellung

10.2 Phasenbeschreibung

11 Leistungsumfang und Lieferobjekte 04.05.13

11.1 Projektstrukturplan / Product-Backlog

11.1.1 Gliederungsformen

11.1.2 Tipp

11.1.3 Arbeitspakete

11.1.4 Beispiel Projektstrukturplan

11.1.5 Hybrider Projektstrukturplan und Product Backlog

11.2 Gliederungsform / Detaillierung

11.2.1 Beispiel Funktionsorientierte Gliederung

11.2.2 Beispiel Objektorientierte Gliederung

11.2.3 Beispiel Geografische Gliederung

11.2.4 Beispiel Phasenorientierte Gliederung

11.2.5 Beispiel für hybride Begründung

11.3 Arbeitspaket / User-Stories

11.3.1 Forschrittsgradmessung Methoden

11.3.2 Beispiel Arbeitspaket

11.3.3 Beispiel Userstories

12 Ablauf und Termine 04.05.04 Teil 2

12.1 Ablaufplan

12.1.1 Beispiel Ablaufplan

12.1.2 Beispiel hybrider Ablaufplan

13 Ressourcen 04.05.08

13.1 Personalressourcen

13.1.1 Beispiel Personalressourcen

13.2 Sachmittel

13.2.1 Beispiel Sachmittel Tabelle

13.3 Ressourcenganglinie

13.3.1 Beispiel Ressourcenganglinie

14 Kosten und Finanzierung 04.05.07

14.1 Aufwandsermittlung

14.1.1 Methoden

14.1.2 Aufwandsübersicht

14.1.3 Beispiel Aufwandsermittlung

14.1.4 Hybride Aufwandsermittlung

14.2 Kostenganglinie

14.3 Kostensummenlinie

15 Planung und Steuerung 04.05.10

15.1 Statusbericht / Fortschrittsbericht

15.1.1 Beispiel Statusbericht:

15.1.2 Hybrides Beispiel Statusbericht

16 Persönliche Kommunikation 04.04.03

16.1 Kommunikationsmodell

16.1.1 Nachrichtenquadrat (F. Schulz v. Thun)

16.1.2 Sender-Empänger-Modell (Shanon & Weaver)

16.1.3 Eisbergmodell (angelehnt an S. Freud)

16.1.4 Axiom-Modell (P. Watzlawick)

16.1.5 Beispiel Kommunikationsmodell

17 Erklärung betreffend die eigenständige Ausführung dieser Arbeit

18 Übersicht der verwendeten Abkürzungen

19 Glossar

20 Anlagen und Abbildungen

21 Tabellenverzeichnis

22 Abbildungsverzeichnis

Vorwort zur zweiten Auflage

Es ist ungewöhnlich, bereits ein Jahr nach der Erstveröffentlichung eine 2. Auflage vorzulegen. Doch dieser Schritt ist ein klares Zeichen für den dynamischen Austausch mit Ihnen, den Leserinnen und Lesern und mehreren Hundert von mir augebildeten Kursteilnehmern, die diese Prüfung erfolgreich abgelegt haben. Ich habe so viele wertvolle Rückmeldungen aus der Praxis – direkt aus den eingereichten und erfolgreich bewerteten Reports meiner Kursteilnehmer – erhalten, dass ich diese neuen Erkenntnisse so schnell wie möglich einarbeiten und für alle verfügbar machen wollte. Mein Dank gilt daher allen Kursteilnehmern, die mit ihren unermüdlichen Fragen und ihrem Feedback maßgeblich zur Weiterentwicklung dieses Buches beigetragen haben.

Was ist neu in der 2. Auflage?

Die Erfahrungen aus dem ersten Jahr haben gezeigt, wo das Buch bereits sehr gut unterstützt und an welchen Stellen es noch präziser werden kann. Konkret bedeutet das für Sie:

Praxiserprobte Inhalte: Das Feedback zu zahlreichen echten Reports ist direkt in die Überarbeitung geflossen. Sie profitieren von den typischen Stolpersteinen und den Erfolgsfaktoren, die sich in der Prüfungspraxis gezeigt haben.

Fokussierte Kapitel: Einige Abschnitte, wie die zur Wirtschaftlichkeitsberechnung, wurden gestrafft, da sie sich als weniger prüfungsrelevant herausgestellt haben. Dafür wurden andere Themen, beispielsweise die Formulierung operativer Ziele, ausgebaut und mit weiteren Beispielen angereichert.

Vertiefte Hybrid-Expertise: Um die Anleitung für hybride Projekte weiter zu fundieren, habe ich mittlerweile das Zusatzzertifikat hybrid+ bei der PM-ZERT erfolgreich abgelegt. Das daraus gewonnene, aktuelle Wissen lasse ich gezielt in die Kapitel einfließen, die sich mit der Darstellung hybrider Elemente im Report befassen.

Korrekturen und Präzisierungen: Selbstverständlich wurden auch Ungenauigkeiten und Fehler der Erstauflage korrigiert, um Ihnen die bestmögliche Qualität zu sichern.

Im Zentrum dieses Buches steht die klare und transparente Struktur des aktuellen IPMA-Reports. Wir werden uns gemeinsam und schrittweise durch die offizielle Word-Vorlage arbeiten, die von der PM-ZERT zum Download angeboten wird. Einfacher geht es kaum!

Dabei berücksichtigen wir selbstverständlich auch hybride Vorgehensweisen und agile Elemente, die für moderne Projekte unerlässlich sind. Ich werde für jedes Kompetenzelement die Anforderungen erklären, das nötige Hintergrundwissen vermitteln und Ihnen mit praxiserprobten Beispielen Denkanstöße für Ihren individuellen Report geben.

Ein Leitfaden, keine Kopiervorlage

Ein wichtiger Hinweis zum Schluss: Der Report ist eine Prüfungsleistung, die Sie eigenständig und ohne fremde Hilfe anfertigen müssen. Dieses Buch ist Ihr Begleiter und Werkzeugkasten, um diese Aufgabe erfolgreich zu meistern.

Meine Beispiele und Vorlagen sind als Impulsgeber und Starthilfe gedacht. Der eigentliche Wert Ihres Reports liegt in der individuellen Auseinandersetzung mit Ihrem Projekt. Jedes Projekt ist einzigartig (sonst wäre es kein Projekt), und deshalb sollte auch jeder Report ein Unikat sein. Assessoren erkennen standardisierte Texte und Tabellen sofort – zeigen Sie stattdessen Ihre persönliche Kompetenz!

Ich lade Sie herzlich ein, auch auf meiner Webseite vorbeizuschauen, wo ich alle im Buch genannten Links direkt zur Verfügung stelle und regelmäßig Neuigkeiten veröffentliche, die dieses Buch ergänzen. Außerdem möchte ich auf den Podcast verweisen, der all diese und weitere agile Themen unter der Berücksichtigung einer abzulegenden Prüfung in lockerer Atmosphäre begleitet.

Ich freue mich, wenn ich Sie mit diesem Buch auf Ihrem Weg zum erfolgreichen IPMA Level D Report unterstützen darf.

Maik Uhlig

Ungarn, 2025

Geleitwort von Romy Kopsch, COO mycareernow GmbH

Klassisches Projektmanagement ist eine essenzielle Fähigkeit in unserer Wirtschaftswelt. Egal, ob es um die Einführung einer Software, die Konzipierung von Produkten, das Aufsetzen von Marketingkampagnen oder die Durchführung von Events geht –tiefes Know-How im Projektmanagement ist wesentlich für den Erfolg.

Maik kennen wir seit vielen Jahren und bewundern ihn für seine Leidenschaft beim Thema Projektmanagement. Mit einer großen Klarheit kann er komplexe Themen greifbar darstellen und komplizierte Themen leicht vermitteln. Gemeinsam haben wir über 1500 Menschen erfolgreich durch die diversen Zertifizierungen geführt. Dabei hat er stets durch seine Fachlichkeit und seiner Freude am Thema überzeugt.

Die Zertifizierung Level D ist Maiks Spezialisierung, sie ist eine der anspruchsvollsten Projektmanagement-Zertifizierungen am Markt. Menschen, die hier erfolgreich sind, können in der Wirtschaft große Projekte verantworten und sich kompetent auf dem Arbeitsmarkt behaupten.

Der Report, welcher Bestandteil der IPMA-Prüfung ist, braucht klare Grundlagen. Diese vermittelt Maik hervorragend in diesem Buch. Dabei orientiert er sich an den neusten Vorgaben der GPM. Zu den besten Dozenten zu gehören und seine Teilnehmenden zu den besten Absolventen auszubilden ist sein stetiger Antrieb.

Mit diesem Handbuch unterstützt Maik aktiv alle Menschen, die ihre Zukunft klar und stringent gestalten möchten! Wir sind dankbar, unseren Weg gemeinsam mit Maik gehen zu können.

Romy Kopsch

COO mycareernow GmbH

www.mycareernow.de

Wir, das ist mycareernow. Wir sind Wegbereiter für beruflich erfolgreiche und glückliche Menschen an jedem Arbeitsplatz der Welt. Als Experte für digitale Weiterbildungen und berufliche Integration unterstützen wir unsere Kunden dabei, ihre eigenen Potenziale voll zu entfalten und spürbar erfolgreicher zu werden. Dabei ist der Grundsatz der Kundenzentrierung maßgeblicher Faktor bei unserem Tun.

Formale Anforderungen

Bevor wir inhaltlich in die Kompetenzelemente eintauchen, müssen wir die formalen Spielregeln klären. Die PM-ZERT als Zertifizierungsstelle gibt hier den Rahmen vor, an den wir uns exakt halten müssen. Diese Vorgaben sind nicht verhandelbar und die Grundlage für eine erfolgreiche Einreichung.

Die offiziellen Anmeldeunterlagen

Alle für Sie relevanten Dokumente stellt die PM-ZERT zentral zum Download zur Verfügung. Es ist essenziell, dass Sie immer die aktuellste Version direkt von der Webseite nutzen, da sich Versionen und Formulare ändern können.

Den Download-Bereich finden Sie hier:

https://www.pm-zert.de/anmeldung/anmeldeunterlagen

Zum Zeitpunkt der Erstellung dieser Auflage (Frühjahr 2025) sind die folgenden Dokumente relevant:

Leitfaden Zertifizierung Level D - V20 (Stand 28.02.2025)

Leitfaden Allgemein - V14 (Stand 03.03.2025)

Leitfaden Online-Prüfungen - V08 (Stand 28.02.2025)

Report Vorlage Level D Projektmanagement - V04 (Stand 24.03.2025)

Taxonomie Projektmanagement - V03 (Stand 28.02.2025)

Leistungsnachweis zur Zertifizierungsanmeldung - F01_V02R16 (Stand 28.02.2025)

Gebühren ab 01.05.2025

Rechtliche Erklärung des Zertifikanten - F01RE - V03 (Stand 28.02.2025)

Wichtige Hinweise zu den Dokumenten:

Werfen Sie unbedingt einen Blick in alle Leitfäden. Besonders wichtig für Ihre Anmeldung sind:

Die Excel-Datei "Leistungsnachweis": Diese müssen Sie für Ihre Anmeldung ausfüllen.

Die "Rechtliche Erklärung": Dieses Dokument ist neuer und dessen Bestätigung eine zwingende Voraussetzung für die Prüfungszulassung.

Der „Leitfaden Zertifizierung Level D“ ist Ihr zentrales Arbeitsdokument. Hier sind die entscheidenden quantitativen und formalen Regeln zusammengefasst und der erwartete Inhalt wird genau beschrieben. Der Report muss nicht mit der Word-Vorlage erstellt werden, das ist Ihre Entscheidung, aber er muss zwingend die Anforderungen des Leitfadens beinhalten.

In diesem Zusammenhang ist noch ein wichtiger Hinweis vonnöten, da es sonst in der Bewertung des Reports zu Problemen kommen kann. Wenn ein neuer Leitfaden erscheint, besitzt der ältere noch eine Gültigkeitsdauer, die sich mit dem neue überschneidet. In dieser Zeit können also Reports abgegeben werden, die entweder den alten noch gültigen Leitfaden oder schon den neuen Leitfaden berücksichtigen. Wenn Sie dieses Buch in den Händen halten und ein neuer Leitfaden erscheint, der beispielsweise die Seitenzahl ändert oder ein komplettes Kompetenzelement austauscht, dann können Sie diesen jetzt noch gültigen Leitfaden nutzen, um den Report zu erstellen, da im Normalfall die Gültigkeit noch mehrere Monate gewährleistet wird. Woher sollen jetzt aber die Assessoren wissen, welchen Leitfaden Sie benutzt haben? Dafür gibt es einen Eintrag auf dem Deckblatt des Reports, den wir hinzufügen müssen. Auch wenn es keinen neuen Leitfaden gibt.

Der Screenshot von diesem Deckblatt zeigt beispielhaft, wie eine solche weitere Zeile aussehen kann. Die Zertifizierungsrunde wird in der Anmeldung auch Rundennummer genannt und von PM-Zert zur Verfügung gestellt.

Die weiteren Einträge erkläre ich auf der Folgeseite, da sie auch zum Report gehören und besonders im Bereich der Versions-Angaben in beiden Tabellen zu Missverständnissen führen können.

Allemeine Angaben:

Name, Vorname: Sollte klar sein. Wenn Sie mehrere Vornamen haben, dann tragen Sie einfach den Vornamen ein, mit dem Sie sich angemeldet haben.

Titel des Reports: Das ist der kurze und bündige Titel, keine Beschreibung!

Zertifizierungsrunde: Die setzt sich normalerweise ganz einfach aus dem einem Z + Prüfungsjahr + laufende Nummer vierstellig mit führenden Nullen zusammen. Aber wie gesagt, die wird bei der Anmeldung zugewiesen und dann in die Zeile einfach eingetragen.

Die beiden Abkürzungen erkläre ich noch:

IZR – Inhouse-Zertifizierungsrunde, wenn Bildungsträger oder Organisationen mindestens 8 TN zur Prüfung anmelden und dafür einen extra Termin erhalten.

OZR – Offene Zertifizierungsrunde, wenn Sie sich einen der offenen Prüfungstermine von der PM-Zert-Seite gesichert haben.

Datum: Hier ist das Abgabedatum einzutragen. Wenn der einen Tag später hochgeladen wird, ist das kein Drama, aber es sollte stimmten und natürlich <= dem Abgabedatum sein.

Version des Reports: Im Normalfall 1.0, das erkläre ich gleich noch einmal genauer.

Version des Report-Leitfadens: Das ist unsere neue Zeile, die wir einfügen. Die Angaben stehen in der Fußzeile der Leitfadens. Wer mit Wort noch etwas unsicher ist, klickt einfach in die letzte Zelle (neben Version des Reports) und drückt die Tabulator-Taste, dann wird automatisch die nächste Zeile eingefügt.

Änderungshistorie des Reporterstellers

Wenn wir den Report anlegen, also die Datei herunterladen und beispielsweise die ersten Zellen im Deckblatt ausfüllen, dann starten wir mit der Vorversion 0.1. Wir nennen diese Ersterstellung und das betrifft alle Seiten.

Wenn wir den Report abschließen, handelt es sich um Version 1.0, das ist die Fertigstellung. Auch diese betrifft alle Seiten. Das Datum der Fertigstellung kann dem Abgabedatum entsprechen, aber auch ein paar Tage früher datiert werden. Wir nehmen im Normalfall einfach denselben Tag.

Warum ist das überhaupt notwendig?

Die Prüfung gilt als bestanden, wenn Sie im schriftlichen Test und im Report jeweils mindestens 9 von 14 Kompetenzen anerkannt bekommen haben.

Das wären dann aber insgesamt zu wenig Punkte für das Zertifikat, das erst ab 23 Punkten augestellt wird!

Wenn beispielsweise im Report 12 von 14 Punkten erreicht werden und in der schriftlichen Prüfung nur 10 von 14, dann gilt die Prüfung als bestanden, aber das Zertifikat wird nicht erteilt, weil 12+10 leider 22 und damit 1 Punkt zu wenig sind. Jetzt kommt der große Moment! Am Prüfungstag teilen die Assessoren uns mit, welche Kompetenzen sie nicht anerkannt haben und wo unser Fehler gelegen hat. Das notieren wir dann fleißig.

Wenn also etwa 3 Wochen nach der Prüfung das für uns nicht ausreichende Ergebnis verkündet wird, dann holen wir den Report, der nun mindestens 5 Wochen zurückliegt(!) wieder aus der Tasche und korrigieren die Fehler, die zum Abzug geführt haben. Dann erweiteren wir die Änderungshistorie und schreiben Version 2.0! Ein Beispiel wäre dann Korrektur Kostensummenlinie auf Seite XX oder XX-YY, wenn die Änderung mehrere Seiten betrifft. Müssen wir mehrere Punkte aufholen, dann können wir für jedes Kompetenzelement eine Zeile hinzufügen, die Version bleibt aber 2.0 und die laden wir dann noch einmal hoch. Dafür haben wir 12 Monate Zeit, ich empfehle aber dringend, diese Nachkorrektur so schnell wie möglich durchzuführen, da Sie nach einem Jahr gar nicht mehr so richtig wissen, was jetzt eigentlich falsch war und die Motivation für eine Neuabgabe eher sinkt… Und auch die Assessoren haben dann einen „völlig neuen“ Report vor sich. Die erinnern sich dann auch schneller an die Grundversion und kontrollieren dann einfach die korrigierten Seiten, auch sie eine Notiz von dem Report haben, die dann nach einem Monat frische zurückkommt als nach einem Jahr.

Und wenn die Korrektur anerkannt wird, dann wird der Punkt nachträglich gegeben und damit auch das Zertifikat erteilt.

Jetz schauen wir uns noch die restlichen Vorgaben an:

Umfang: max. 25 Seiten Netto-Text

Meine Erfahrung aus der Begleitung von hunderten Reports zeigt: Diese 25 Seiten reichen in der Regel vollkommen aus. Meist bewegen sich erfolgreiche Reports sogar eine Seite darunter oder treffen die 25 Seiten genau. Darf es eine Scheibe mehr oder weniger sein? Ja, auch das ist unproblematisch, wenn im Report freie Bereiche enstehen, weil ein Seitenumbruch durchgeführt wurde, um die Grafik auf der Folgeseite sauber darzustellen. Diese Freiräume werden dann berücksichtigt. Wer jetzt im nächsten Abschnitt zu den Methoden mitzählt, wird herausfinden, dass die empfohlene Seitenzahl bei insgesamt 23,5 liegt. Die 25-Seiten-Maximum-Regel hat also schon 1,5 Seiten Puffer eingebaut!

Wenn Sie jetzt aber 15 oder 35 abgeben, dürfen Sie davon ausgehen, dass bei 15 die Assessoren davon ausgehen werden, dass Sie einfach nicht genug wissen, um die Seiten auszunutzen und bei 35 werden sie den Report wohl höflich zurückgeben und um Kürzung bitten. Das ist im letzten Fall aber kein Durchfallen, das ist eine Ablehnung der Annahme des Reports durch die Assessoren. Daher ist es wichtig, nicht am letzten Tag der Frist um 23:59 den Upload zu starten. Zwei Wochen vorher sollte der Report schon hochgeladen werden, damit bei Rückmeldungen immer noch fristgerecht reagiert werden kann!

Praxis-Tipp bei Platzmangel: Sollten Sie mit einer oder zwei Mehrseiten an die Grenze stoßen, hier eine einfache, aber wirkungsvolle Stellschraube: Reduzieren Sie die Seitenränder in Word auf 2 cm, da die „Report Vorlage Level D“ größere Abstände hat. Das kann auf 25 Seiten einen erheblichen Unterschied machen.

Anhang: max. 15 Seiten

Der Anhang ist für unterstützende Bilder, umfangreiche Grafiken oder große Tabellen gedacht, auf die Sie im Text verweisen können. Dies ist eine gute Möglichkeit, den Hauptteil schlank zu halten. Grafiken, die aber speziell verlangt werden, wie eine Kostensummenlinie oder das Gantt-Diagramm kommen in den Haupttext und sind Bestandteil der 25 Seiten.

Verzeichnisse (zählen nicht zum Seitenlimit)

Inhaltsverzeichnis, Abkürzungsverzeichnis, Tabellenverzeichnis und ein eventuelles Glossar werden nicht auf die 25 Text-Seiten angerechnet. Das ist beruhigend, bedeutet aber auch, dass Sie diese Verzeichnisse sauber anlegen müssen. Wenn Sie einen Anhang nutzen, gehört auch ein Anhangsverzeichnis dazu.

Formatierung von Tabellen und Abbildungen

Tabellen dürfen über mehrere Seiten (hochkant oder quer) laufen. Wichtig ist nur, dass die Tabellenüberschrift auf jeder Seite wiederholt wird, um die Lesbarkeit für die Assessoren zu gewährleisten.

Abbildungen (im Hoch- oder Querformat) müssen jeweils auf einer Seite dargestellt werden. Auch händische Zeichnungen sind erlaubt, solange sie klar lesbar sind. Meist ist das digitale Erstellen über Formen, SmartArt oder andere Tools jedoch der einfachere und sauberere Weg.

Fußzeile

Die wird tatsächlich nicht speziell beschrieben, also reicht eine Fußzeile mit der Seitenzahl und vielleicht noch dem Dokumentenname oder dem Projekt-Titel völlig aus. Links-Rechts-Unterscheidung wie in diesem Buch ist nicht nötig. Dokumentenname oder Projekttitel links und Seitenzahl rechts ist ok.

Dokumentenbezeichnung

Der Report bekommt laut allgemeinem Leitfaden (S. 11) einen festgelegten Namen: „Report_Name_Vorname_Geburtsdatum-JJJJMMTT-Vxx“.

In meinem Beispiel: Report_Uhlig_Maik_Geburtsdatum-19680215-V1.0

Wer noch einen Rechner hat, der mit einem Dieselaggregat läuft und in der Benennung keinen Punkt „.“ als Zeichen zulässt, lässt den dann einfach weg.

Es gibt auch immer wieder die Frage, ob der Geburtsdatum wirklich rein muss, also ob nicht Report_Uhlig_Maik_19680215-V 1.0 reicht. Ich weiß von mehreren Reports, die so abgegeben wurde und anstandslos bestanden haben, aber das Intermezzo „Geburtsdatum-“ kostet kein Geld, auch wenn es nicht so schön aussieht und überflüssig erscheint. Hier ist das Einhalten der Vorgabe niemals falsch.

Nachdem wir nun die formalen Spielregeln geklärt haben, können wir uns dem Herzstück widmen: dem Inhalt Ihres Reports.Abschnitt 1: Kontext des Projektes

1 Management Zusammenfassung

1 Management Zusammenfassung

1.1 Angaben zum Projekt

1.2 Eigene Position im Projekt

In diesem ersten Abschnitt geht es nur um den Kontext selbst und die Einordnung des Projektes.

Für die folgenden Anforderungen wird insgesamt eine Seite als Maximum vorgegeben. Das ist eine problemlose Einschränkung, eine Seite reicht völlig aus. Dabe ist zu beachten, dass der Erfüllungsgrad mit „Formal erforderlich“ angegeben wird, also „nur“ der Check, ob es vorhanden ist, es wird nicht bewertet.

1.1 Angaben zum Projekt

Folgende Angaben müssen gemacht werden:

Real / Fiktiv

Hat es sich um ein reales oder fiktives Projekt gehandelt? Diese Information hat überhaupt keine Auswirkung auf den Report selbst und kann daher ganz offen und ehrlich hinterlegt werden.

Abgeschlossen / Laufend / Geplant

Hier wird es schon etwas kniffliger, weil es in 15.1 um die Darstellung eines im Projekt angewendeten Kommunikationsmodells geht… Wenn es geplant ist, kann es dieses angewendete Modell ja gar nicht geben!

Auch der unter 14.1. geforderte Statusbericht über den Fortschritt eines gewählten Arbeitspaketes oder alternativ der erstellten Userstory kann noch kein Ergebnis haben!

Hier müsste dann in diesen Abschnitten klargestellt werden, dass es sich um eine Vorausschau handelt.

Mein Tipp: Wenn das Projekt fiktiv ist, was meistens der Fall sein sollte, wird das Projekt fiktiv beendet sein, wenn wir den Report schreiben, das ist die einfachste Lösung.

Liegt eine Vertraulichkeitserklärung vor und sind daher Eigennamen anonymisiert?

Viele Organisationen erlauben die Verwendung von Namen, aber es gibt in unserem Report auch Auftraggeber und Stakeholder, die außerhalb unserer Organisation tätig sind. Von denen haben wir aber im Normalfall keine Freigabe für die Nennung ihrer Klarnamen. Daher sollte der Form halber hier eine entsprechende Erklärung abgegeben werden, dass eine Vertraulichkeitserklärung vorliegt und daher anonymisierte Namen verwendet werden. Auch in fiktiven Projekten! Wir gehen davon aus, dass das fiktive Projekt ein „echtes“ Projekt widerspiegelt, und da könnte eben auch diese Vertraulichkeitserklärung vorliegen. Es sollte nur darauf hingewiesen werden, dass die Vertraulichkeitserklärung fiktiv vorliegt.

Mein Tipp: Für die anonymisierten Namen denke ich an Freunde und Bekannte, deren Namen ich einfach leicht abwandle, mit denen ich aber eine typische Eigenschaft verbinde oder denen ich einfach in Gedanken die Aufgabe übertrage, die auch meine Stakeholder im Report haben. Das vereinfacht die Verwendung und ist eine große Hilfe bei der Stakeholderanalyse. Wenn meine Tante im Elisabeth-Krankenhaus im Empfang arbeitet und total lieb ist und immer gern hilft, dann nenne ich die Wareneingangs-Verantwortliche einfach Elisabeth Gern und kann sie als Stakeholderin gut einschätzen.

Zusätzlich kann ein Big Picture als Grafik erstellt werden.

Bei Scrum gibt es den Ansatz, die nicht getane Arbeit zu maximieren. Wenn die Angaben zum Projekt als Erfüllungsgrad nur bewerten, ob es vorhanden ist und ich mein Big Picture „zusätzlich erstellen darf“, dann ist es auch ohne Konsequenzen, wenn ich es nicht erstelle…

Dennoch ist es eine Möglichkeit und dieses Handbuch wäre kein Handbuch, wenn das Thema „Big Picture“ außer Acht gelassen werden würde.

1.1.1 Big Picture

„Ein Bild sagt mehr als 1000 Worte“

Wenn wir es schaffen, unser Projekt mit allen wichtigen Informationen (Aufgaben, Leistungen, Schnittstellen, Lieferobjekte, Erfolgskriterien, Risiken, Chancen, Stakeholder, …) als Übersicht darzustellen, hilft es allen Beteiligten, den Fokus auf die Gesamtheit zu bewahren. Dafür gibt es verschiedene Ansätze.

Das „Handbuch für Praxis und Weiterbildung im Projektmanagement“1 versteht unter einem Big Picture die plakative Visualisierung der wichtigsten Aspekte und Zusammenhänge, die eine gemeinsame Sicht verschafft, eine Diskussionsgrundlage bietet, das Verständnis aller Beteiligten vereint und unterschiedliche Sichtweisen, Prioritäten und Perspektiven offensichtlich macht. Außerdem ist es ein Überblick, der erkennbar macht, welche Informationen noch fehlen.

In dem höchst interessanten Buch „Projektmanagement am Rande des Chaos“2 verweisen die Autoren auf einen weiteren Vorteil eines Big Pictures, da sie empfehlen, Kommunikation „am Big Picture auszurichten“. Das ist tatsächlich eine gute Strategie, da alle bei einer Kommunikation, die bekanntlich auf mehreren Ebenen stattfindet, eine gemeinsam anerkannte sichtbare Ebene als Grundlage und Fokus nutzen.

Im Klassiker „Projektmanagement“ von Patzak & Rattay3 wird auch in der 7. Auflage aus dem Jahr 2018 das Big Picture noch als „Trend“ bzw. „neue Entwicklung“ bezeichnet und findet tatsächlich erst spät im Kapitel über hybrides Projektmanagement auf Seite 675 Beachtung.

Per se sind also sämtliche Darstellungen, die projektbezogene Informationen auf einen Blick liefern, ein Big Picture. Im Report werden wir einen Projektsteckbrief, einen Ablaufplan, einen Phasenplan und einen grafischen Projektstrukturplan in Baumstruktur oder alternativ einen Releaseplan, ein Product-Backlog oder ein KANBAN-Board erstellen, das sind alles Big Pictures. Hier ist eher ein grober Überblick gemeint, dafür gibt es viele Möglichkeiten, von denen ich beispielhaft eines ausgewählt habe, das sowohl in klassischen als auch in hybriden Projekten voll zum Einsatz kommen kann.

1.1.2 Project Canvas

In seinem Buch „THE MAKER PROJECT CANVAS“4 beschreibt John van Saders sehr ausführlich die Möglichkeiten, die sich mit der Darstellung eines Canvas ergeben. Für unser Projekt können wir uns auf die wesentlichen Merkmale eines Projekt-Canvas konzentrieren, das beispielsweise in einer interessanten Reihe „Guide +100 Business Model Templates“5 unter der einfachen Betitelung „Project Canvas“ ausführlich erörtert wird. Zusammenfassend ist dieses Modell eine Visualisierung der Schlüsselelemente eines Projektes. Es gibt viele Varianten, wichtig dabei ist der Unterschied zwischen dem Project-Canvas, also einer Visualisierung des Projektes und dem Busines-Modell-Canvas, welches das Geschäftsmodell eines Unternehmens darstellt. Grundsätzlich haben sich im Project Canvas die folgenden 11 Schlüsselelemente durchgesetzt:

Projektkontext

Zweck des Projekts: Was ist das Ziel des Projekts? Was soll erreicht werden?

Budget: Wie hoch sind die zu erwartenden Gesamtkosten des Projekts? Wie werden die Kosten aufgeschlüsselt?

Team: Wer sind die Mitglieder des Projektteams? Welche Rollen haben sie?

Umfeld: In welchem Umfeld wird das Projekt durchgeführt? Welche internen und externen Faktoren können das Projekt beeinflussen?

Projektplanung

Etappenziele: Welche Meilensteine müssen erreicht werden, um das Projekt erfolgreich abzuschließen?

Qualität: Welche Qualitätsstandards müssen erfüllt sein?

Ergebnis: Was ist das konkrete Ergebnis des Projekts? Was wird geliefert?

Projektdurchführung

Kunde: Wer ist der Zielkunde des Projekts? Was sind ihre Bedürfnisse und Erwartungen?

Ressourcen: Welche Ressourcen werden benötigt, um das Projekt durchzuführen?

Zeit: Wie lange wird das Projekt dauern? Wann sind die wichtigsten Termine?

Risiken und Chancen: Welche Risiken können das Projekt gefährden? Welche Chancen können genutzt werden?

In einem Big Picture stehen alle wichtigen Informationen auf einem Blick gruppiert zur Verfügung. Das erhöht den Fokus und kann in jeder Sitzung als Diskussionsgrundlage verwendet werden, um das Gesamt-Konstrukt nicht aus den Augen zu verlieren.

Bei allen Informationen im Big Picture handelt es sich aber im Normalfall um Schätzungen aus dem Anfangsstadium des Projektes. Das bezieht sich auf alle Terminplanungen und besonders auf das Budget. Ein Budget ist eine Schätzung, die sich im Laufe des Projektes mit Sicherheit noch ändern wird. Es sind keine Projektkosten! Kosten fallen an und werden ermittelt. Wenn am Ende die Projektkosten innerhalb des angangs geplanten Projektbudgets bleiben, ist alles gut gelaufen.

Planbasiert/Klassisch/Traditionell oder Hybrid?

Es wird darauf hingewiesen, dass es möglich ist, einen hybriden Ansatz mit Scrum oder Kanban zu wählen. Es ist aber nicht möglich, einen rein agilen Ansatz für das gesamte Projekt zu wählen. Eine explizite Erklärung wird hier nicht verlangt, diese kommt in 8.2 noch.

Grundsätzlich ist es wichtig, zu wissen, dass auch bei einer hybriden Projektwahl der Report größtenteils klassisch erstellt werden kann! Die in den einzelnen Kompetenzelementen erwähnten agilen Darstellungen sind fast alle alternativ wählbar! Für diese wird auch im weiteren Verlauf immer ein Beispiel hinter dem Beispiel der klassischen Darstellung gegeben, aber keine ausführliche Erörterung agiler Vorgehensweisen. Wer also ein hybrides Projekt wählt, sollte auch Kenntnisse im agilen Projektmanagement mitbringen, ansonsten könnte der Report eine Tortur mit vielen Abzweigungen und immensem zeitlichem Aufwand werden, da gleich zwei Projektmanagementmethoden gelernt und dann noch zusammengebracht werden müssten.

Hybride Reports unterscheiden sich nur in einigen Punkten von den klassisch geplanten Projekten:

In 9.1 kann die Projektorganisation frei visualisiert werden und muss nicht als Organigramm dargestellt werden.

In 10.1 und 10.2 muss beispielsweise zusätzlich zum Phasenplan mitgeteilt werden, in welchen Phasen agil gearbeitet wird.

In 11.1 kann anstelle des Projektstrukturplans auch ein hybrid codierter PSP erstellt werden und zusätzlich ein initiales Product Backlog mit Epics und weiteren agilen Elementen.

In 11.2 muss die Begründung dann auch auf die agile Darstellung angepasst werden.

In 11.3 können anstelle eine Arbeitspakets auch zwei User-Stories gewählt werden.

In 12.1 ist ein hybrider Ablaufplan mit Sprints möglich.

In 14.1 wird der Aufwand nicht für das Arbeitspaket, sondern für eine der User-Stories erstellt.

In 14.2 und 14.3 wird darauf hingewiesen, dass in hybriden Projekten die Kostengang- und Kostensummenlinie im Falle der Darstellung über den gesamten Projektzeitraum auch die entsprechende hybride Termin- und Ablaufplanung als Grundlage dienen soll. Dennoch kann auch in hybriden Projekten ein Arbeitspaket gewählt werden, um das zu umgehen.

In 15.1 wird der Fortschritts eines unter 11.1 beschriebenen Epics im initialen Product Backlog dargestellt.

Allgemein gilt: Hybride Projekte haben agile Anteile, sind aber dennoch klassisch zu verstehen und die Berichte werden auch einem traditionellen Management vorgelegt, das diese Dokumente verstehen muss!

Die hybride Vorgehensweise ist also nicht: In der KW XX – KW YY haben wir mal einen Sprint eingelegt… Das ist eine Grundsatzentscheidung für den Report!

1.2 Eigene Position im Projekt

Beschreibung der eigenen Rolle im Projekt

In einem Projekt gibt es verschiedene Rollen, die dazu beitragen, dass das Projekt erfolgreich abgeschlossen wird. Die Entscheidung der ICB 4, sich von einer berufsfixierten Sichtweise zu lösen, ist eine direkte Reaktion auf die globale Realität der Projektwirtschaft. Anstatt eine spezifische Position wie "den Projektmanagerin oder den Projektmanager" zu definieren, konzentriert sich der Standard auf die Kompetenzen, die Personen benötigen, um in der Domäne des Projektmanagements erfolgreich zu agieren.

Die Hauptgründe für diese Perspektive sind pragmatisch und konzeptionell tiefgreifend:

Uneinheitliche Berufsbezeichnungen: Die Titel für Personen, die Projekte leiten, variieren erheblich zwischen verschiedenen Ländern, Branchen und sogar innerhalb einzelner Organisationen. Bezeichnungen wie Projektleiter, Project Manager, Teilprojektleiter oder Projektkoordinator werden oft synonym oder mit unterschiedlichen Verantwortlichkeiten verwendet. Ein starrer, auf einem einzigen Berufsbild basierender Standard würde dieser Vielfalt nicht gerecht werden.

Fokus auf den Menschen und seine Kompetenzen: Die ICB 4 verfolgt den Ansatz, dass Projekte von Menschen gemacht werden. Im Zentrum stehen daher die individuellen Handlungskompetenzen, die eine Person in eine Projektsituation einbringt, unabhängig von ihrem formalen Titel. Der Standard beschreibt, was jemand können muss, um in einem Projekt erfolgreich zu sein, und nicht, welche Berufsbezeichnung er oder sie tragen sollte.

Projektmanagement als temporäre Aufgabe: Viele Fach- und Führungskräfte übernehmen die Rolle des Projektmanagers nur für die Dauer eines bestimmten Vorhabens. Ein Ingenieur, ein Marketingexperte oder ein IT-Spezialist kann temporär die Leitung eines Projekts übernehmen, ohne seinen ursprünglichen Beruf aufzugeben. Die ICB 4 ermöglicht es, die für diese temporäre Rolle notwendigen Projektmanagement-Kompetenzen zu definieren und zu entwickeln, ohne ein komplettes Berufsbild vorauszusetzen.

Flexibilität in modernen Arbeitswelten: Agile und hybride Projektmanagementansätze erfordern oft eine flexible Rollenverteilung innerhalb eines Teams. Die starre Zuweisung eines "Projektmanagers" als einzige verantwortliche Person wird zunehmend durch Modelle ersetzt, in denen sich Teammitglieder je nach Bedarf und Kompetenz in unterschiedliche Rollen einfinden.

Der kompetenzbasierte Ansatz der ICB 4 unterstützt diese Flexibilität.

Welche Rollen stehen beispielsweise zur Auswahl?

1. Projektleitung: Sie ist für die Planung, Durchführung und Überwachung des gesamten Projekts verantwortlich. Sie koordiniert die Teammitglieder, Ressourcen und Aktivitäten, um sicherzustellen, dass das Projektziel erreicht wird.

2. Projektteam: Das Projektteam besteht aus Personen, die die verschiedenen Aufgaben und Aktivitäten im Rahmen des Projekts durchführen. Die Mitglieder können in unterschiedlichen Fachbereichen arbeiten, je nach den Anforderungen des Projekts.

3. Arbeitspaketverantwortliche: Diese Rolle beschreibt speziell für die Übernahme der Verantwortung eines Arbeitspaketes, da Projekte aus mehreren bis sehr vielen Arbeitspaketen besteht und diese einfach nicht mehr von einer Person verantwortet werden können.

Es ist wichtig, dass die Verantwortlichkeiten und Aufgaben jeder Rolle klar definiert sind, um sicherzustellen, dass das Projekt effektiv und effizient abläuft. Je nach Projektart und -umfang können auch zusätzliche Rollen erforderlich sein.

In unserem Report werden wir aber mit diesen Rollen auskommen, die Frage ist nun am Ende nur: Welche Rolle haben wir eingenommen? Die Antwort ist denkbar einfach:

Projektleitung, da wir für die Planung, Durchführung und Überwachung des gesamten Projekts verantwortlich sind und die Teammitglieder, Ressourcen und Aktivitäten koordinieren, um sicherzustellen, dass das Projektziel erreicht wird. Aber Sie können auch eine andere wählen!

Was bedeutet das für Sie und Ihren Report?

Die IPMA geht davon aus, dass erfolgreiches Projektmanagement nicht das Ergebnis eines starr definierten, immer gleichen Tätigkeitsprofils ist. Jedes Projekt ist anders, hat einen anderen Kontext, andere Stakeholder und andere Herausforderungen. Eine Person, die ein Projekt zum Erfolg führt, handelt daher nicht nach einem starren Regelwerk. Stattdessen koordiniert sie die Projektarbeit, indem sie situativ die richtigen Kompetenzen anwendet.

Stellen Sie sich die drei Kompetenzbereiche (Perspective, People, Practice) wie einen Werkzeugkasten vor. Ihre Aufgabe in einem Projekt ist es nicht, jeden Tag acht Stunden lang den Hammer zu schwingen (also eine starre Rolle auszufüllen). Ihre Aufgabe ist es, für jede Herausforderung – sei es eine Budgetverhandlung, ein Konflikt im Team oder ein technisches Problem – das passende Werkzeug auszuwählen und es fachgerecht einzusetzen.

Genau das müssen Sie in Ihrem Report beweisen:

Nicht,

dass

Sie "Master of Desaster

6

" mit einem Schild an der Tür waren.

Sondern

wie

Sie durch die gezielte Anwendung der einzelnen Kompetenzelemente Ihr Projekt gesteuert und zum Erfolg geführt haben.

Dennoch wird hier einmal der Begriff „Projektleitung“ oder etwas Ähnliches verwendet, um die Position als solche zu erkennen.

Von wem wurde diese Rolle zugewiesen?

Diese Antwort ist eng mit der Art des Projektes verbunden, die wir noch im Laufe sehr genau besprechen werden. In Kurzform aber gibt es folgende drei Möglichkeiten, wie das Projekt organisiert wird, was wiederum Auswirkungen hat, von wem wir normalerweise die Rolle zugewiesen bekommen.

1. Stabs-Projektorganisation

2. Autonome Projektorganisation

3. Matrix-Projektorganisation

1. Stabs-Projektorganisation

In dieser Organisation besitzt die Projektleitung keine disziplinarischen Weisungsbefugnisse und trifft keine Entscheidungen für Termine, Kosten oder Ergebnisse, verfügt also auch nicht über die fachliche Weisungsbefugnis. Ein solches Projekt ist für den Report eher ungewöhnlich, aber nicht auszuschließen. Auftraggeber könnte eine öffentliche Behörde sein.

2. Autonome Projektorganisation

Hier hat die Projektleitung die alleinige und vollständige Entscheidungsbefugnis (disziplinarisch und fachlich) und damit auch die volle Verantwortung für das Projekt. Auftraggeber ist meist eine externe Firma, also ein klassischer Auftrag.

3. Matrixprojektorganisation