Kategorie: Projektmanagement

Nachdem wir uns im letzten Beitrag um das Änderungsmanagement gekümmert haben, wird es nun zeit sich mit dem Projektabschluss zu beschäftigen.

Ein Projekt zu starten ist oft aufregend, ein Projekt sauber zu beenden dagegen wird gerne unterschätzt – dabei ist genau das ein wesentlicher Erfolgsfaktor.
PRINCE2 legt deshalb großen Wert auf einen strukturierten Projektabschluss, bei dem Ergebnisse gesichert, Erkenntnisse dokumentiert und offene Punkte übergeben werden.

Denn ein Projekt ohne klaren Abschluss bleibt eine Baustelle – in den Köpfen, in den Prozessen und oft auch in den Budgets.

Was bedeutet „Projektabschluss“ in PRINCE2?

Der Projektabschluss ist kein spontaner letzter Arbeitstag, sondern ein definierter Prozess mit klaren Aufgaben und Verantwortlichkeiten:

• Absicherung der Übergabe an den Betrieb oder die Organisation
• Bewertung, ob das Projekt die Ziele erreicht hat
• Dokumentation von Lessons Learned
• Abschlussbewertung des Business Case
• Administrative Schließung von Verträgen, Systemen, Dokumentationen

Ziel: Das Projekt wird geordnet übergeben – alle wissen, dass es beendet ist, und was daraus folgt.

Wann wird der Projektabschluss eingeleitet?

Der Abschlussprozess beginnt nicht „irgendwann am Ende“, sondern strukturiert:

• Sobald alle Produkte geliefert oder die relevanten Arbeitspakete abgeschlossen sind
• Wenn absehbar ist, dass das Projektziel erreicht (oder nicht mehr erreichbar) ist
• Vor Ablauf der letzten Managementphase

Der Projekt Manager initiiert dann den Abschlussprozess.

Aufgaben im PRINCE2-Projektabschluss

1. Vorbereitung der Übergabe
   • Produkte abnahmebereit?
   • Dokumentation vollständig?
   • Verantwortlichkeiten für den Betrieb geklärt?
2. Leistung und Ziele bewerten
   • Vergleich: Soll-Ist-Ergebnisse
   • Prüfung: Qualitätskriterien erfüllt?
   • Abgleich: Nutzen realistisch erreichbar?
3. Lessons Learned dokumentieren
   • Was lief gut?
   • Wo gab es Herausforderungen?
   • Was kann die Organisation daraus lernen?
4. Empfehlung für den weiteren Betrieb
   • Pflege, Support, Verantwortlichkeiten klären
   • Offene Risiken oder Folgemaßnahmen benennen
5. Formale Projektfreigabe
   • Entscheidung des Lenkungsausschusses
   • Offizielle Beendigung des Projekts
   • Schließung von Verträgen, Budgets und Systemzugängen

Rollen im Abschlussprozess

Rolle	Aufgabe im Abschluss
Projekt Manager	Organisation, Dokumentation, Abstimmung
Project Board	Entscheidung über Abschluss, Bewertung
Project Assurance	Unabhängige Prüfung der Ergebnisse
Betrieb / Nutzer	Übernahme der Projektprodukte

Praxisempfehlungen für den Projektabschluss

• Abschlussbericht nie vergessen: Enthält Status, Bewertung, offene Punkte
• Übergabemeeting fest einplanen: Betrieb und Nutzer aktiv einbinden
• Lessons Learned strukturiert erheben: Workshop statt lose Sammlung
• Business Case kritisch prüfen: Nutzen realistisch? Oder Anpassungen nötig?
• Saubere Dokumentationsübergabe: Für spätere Projekte oder Audits wichtig

Lessons Learned: Mehrwert für die Organisation

Der Abschlussbericht bleibt nicht im Aktenschrank – sondern liefert:

• Input für künftige Projekte (Best Practices, Fehlervermeidung)
• Optimierungspotenzial für Prozesse oder Schnittstellen
• Empfehlungen für das organisatorische Wissensmanagement

Praxistipp: Lessons Learned sollten immer an ein PMO, Prozessverantwortliche oder Wissensplattformen übergeben werden – sonst versanden sie.

Fazit: Projekte erfolgreich abschließen, heißt sie nicht einfach beenden

Ein sauberer Projektabschluss schafft:

• Klarheit bei allen Beteiligten
• Verlässliche Übergabe an die Organisation
• Nachhaltige Nutzung der Ergebnisse
• Verbesserungen für zukünftige Projekte

PRINCE2 liefert dafür den Rahmen – strukturiert, nachvollziehbar und praxisnah.

Abschluss der Serie & Ausblick

Mit dem Thema Projektabschluss endet unsere strukturierte Übersicht über die zentralen Bestandteile eines PRINCE2-Projekts.

In weiteren Beiträgen vertiefen wir ausgewählte Themen, z. B.:

• PRINCE2 Agile in der Umsetzung
• Umgang mit schwierigen Projektsituationen
• Zusammenspiel von ISO-Normen und PRINCE2
• Übergang vom Projekt in den Betrieb

Möchten Sie Ihre Projekte professionell abschließen?

Wir unterstützen Sie dabei, Projekte strukturiert zu übergeben, Lessons Learned nutzbar zu machen und den Betrieb optimal vorzubereiten.

Sprechen Sie uns an – für Projekte, die sauber enden und Mehrwert hinterlassen.

(Der Beitrag wurde von KI strukturiert und das Teaserbild von KI generiert)

Nachdem wir uns im letzten Beitrag über die Phasensteuerung und Toleranzen unterhalten haben, schauen wir uns diesmal die Änderungen in Projekten an.

In der Umsetzung eines Projekts gehören Änderungen ehr zum Standard als zur Ausnahme. Selten bleibt etwas in der eigentlichen Umsetzung so, wie es am Anfang geplant war. Anforderungen ändern sich, neue Erkenntnisse entstehen, Prioritäten verschieben sich.

Die Frage ist nicht, ob sich etwas ändert – sondern wie wir damit umgehen.

PRINCE2 bietet mit dem Change Control Approach einen strukturierten Weg, Änderungen kontrolliert, nachvollziehbar und transparent zu behandeln – ohne dass das Projekt aus dem Ruder läuft.

Was ist ein „Change“ im Sinne von PRINCE2?

Ein Change ist jede vorgeschlagene Abweichung von einem vereinbarten Projektergebnis oder Produkt – ganz gleich, ob sie aus dem Projektteam, von Stakeholdern oder von außen kommt.

Typische Beispiele:

• Neue Funktion oder Feature-Wunsch
• Änderung eines Liefertermins
• Anpassung von Qualitätskriterien
• Austausch eines Produkts gegen eine Alternative
• Nachträglicher Scope-Reduktionsvorschlag

PRINCE2 unterscheidet dabei drei Reaktionstypen:

Änderungsart	Beschreibung
Request for Change	Geplante, formale Änderungsanfrage
Off-Specification	Geplante Liefergegenstände, die nicht wie erwartet sind
Problem/Issue	Unerwartete Ereignisse, die sofortige Reaktion erfordern

Warum strukturierter Umgang mit Änderungen wichtig ist

Unkontrollierte Änderungen – oft als „Scope Creep“ bekannt – gefährden nicht nur Zeit und Budget, sondern auch Qualität und Vertrauen.

Ziele des Änderungsmanagements:

• Vermeidung von Parallelentscheidungen oder Bauchgefühl-Änderungen
• Bewertung von Auswirkungen auf Zeit, Kosten, Qualität, Nutzen und Risiko
• Sicherstellung, dass Änderungen bewusst und begründet freigegeben werden
• Transparenz gegenüber allen Projektbeteiligten und Steuerungsgremien

Wie läuft der Änderungsprozess ab?

PRINCE2 empfiehlt einen klaren Ablauf:

1. Erfassen der Änderung
   Jeder Change wird dokumentiert – z. B. in einem Issue Report oder Änderungsprotokoll.
2. Bewertung der Auswirkungen
   Der Projekt Manager prüft zusammen mit Fachstellen die Konsequenzen auf:
   • Budget
   • Zeitplan
   • Qualität
   • Nutzen (Business Case)
   • Risiko
3. Entscheidung
   • Innerhalb der Toleranzen: Entscheidung durch Projekt Manager
   • Außerhalb der Toleranzen: Vorlage an den Lenkungsausschuss und ggf. der Change Authority, wenn vorhanden
4. Durchführung und Kontrolle
   Freigegebene Änderungen werden in die Pläne integriert und in einem Configuration Item Record dokumentiert.
5. Nachverfolgung
   Änderungen werden regelmäßig auf ihre Wirkung überprüft – ggf. wird erneut nachgesteuert.

Beteiligte Rollen

Rolle	Aufgabe im Änderungsprozess
Projekt Manager	Erfassung, Bewertung, Vorlage zur Entscheidung
Project Board	Entscheidung bei Auswirkungen auf Toleranzen
Projekt Assurance	Prüfung der Konsequenzen (z. B. Qualität, Business Case)
Change Authority*	Optionale Instanz für dezentrale Entscheidungsbefugnisse

*Die Change Authority kann delegiert sein – z. B. an eine Fachabteilung oder den Projekt Manager – für kleinere Änderungen.

Empfehlungen für die Praxis

• Standardisiertes Änderungsformular: Vermeidet Informationslücken
• Änderungsregister (Change Log): Alle Entscheidungen nachvollziehbar halten
• Konfigurationsmanagement verknüpfen: Was wurde wann wie verändert?
• Klarer Eskalationsmechanismus: Wer entscheidet was?
• Keine Diskussion ohne Impact-Bewertung: Fakten schaffen Entscheidungen

Fazit: PRINCE2 sorgt für Änderung mit System

Änderungen gehören zum Projekt – sie zeigen, dass das Projekt lebt.
Aber sie brauchen einen strukturierten Umgang, damit sie nicht zur Dauerbaustelle führen.

PRINCE2 stellt dafür einen klaren Rahmen bereit – mit Zuständigkeiten, Prozessen und Transparenz.

Nächster Beitrag der Serie

Im nächsten Teil beleuchten wir das Thema Projektabschluss nach PRINCE2: Wie beenden wir Projekte strukturiert – mit Lerneffekten, sauberer Übergabe und ohne offene Enden?

Möchten Sie mehr Kontrolle im Änderungsprozess?

Wir unterstützen Sie beim Aufbau eines pragmatischen Änderungsmanagements – mit Templates, Rollenklärung und Entscheidungshilfen für die Praxis.

Sprechen Sie uns an – für Projekte, in denen Flexibilität nicht mit Beliebigkeit verwechselt wird.

(Der Beitrag wurde von KI strukturiert und das Teaserbild von KI generiert)

Sie haben ein Projekt nach PRINCE2 vorbereitet: Der Business Case ist definiert, die Projektstruktur steht, Phasen und Toleranzen sind geplant, die Governance ist etabliert.
Nun soll das Projekt nicht klassisch-linear, sondern agil umgesetzt werden.

Müssen Sie jetzt alles neu machen? Nein. Genau hier setzt PRINCE2 Agile an.

PRINCE2 Agile ist kein neues Framework, sondern eine Erweiterung des bestehenden PRINCE2-Modells – gezielt für Organisationen, die agile Methoden integrieren möchten, ohne auf strukturierte Steuerung und Governance zu verzichten.

Was bleibt bestehen?

Die vollständige PRINCE2-Struktur bleibt erhalten:

• Prinzipien (z. B. „kontinuierliche geschäftliche Rechtfertigung“)
• Themen (Business Case, Qualität, Risiken, Organisation etc.)
• Prozesse (Vorbereitung, Initiierung, Steuerung, Abschluss)
• Rollen(Executive, Projekt Manager, Project Board etc.)
• Toleranzmodell und Phasensteuerung

Diese Managementebene bleibt stabil – dort wird nicht „agil gemacht“, sondern geführt und entschieden.

Was ändert sich mit PRINCE2 Agile?

Die operative Umsetzung innerhalb der Phasen wird agil gestaltet.
Dort, wo im klassischen Modell die Teammanager aktiv sind, übernimmt jetzt ein agiles Delivery-Team – organisiert z. B. nach Scrum, Kanban oder SAFe.

Agile Elemente im Projekt:

• Product Backlog statt Lastenheft
• Sprints / Iterationen statt sequenzieller Arbeitspläne
• User Stories statt seitenlanger Spezifikationen
• Definition of Done & Ready
• Daily Stand-ups, Reviews, Retrospektiven

Wichtig: Diese Methoden betreffen die operative Ebene – nicht die Projektsteuerung.

Schnittstelle: Teammanager vs. Agile Delivery Team

In PRINCE2 wird operative Arbeit durch Teammanager verantwortet. In PRINCE2 Agile wird diese Rolle ersetzt durch:

• Product Owner (PO) – priorisiert Anforderungen, spricht für die Nutzer
• Scrum Master (SM) – moderiert, schützt den Prozess
• Entwicklungsteam – selbstorganisiert, liefert Inkremente

Der Projekt Manager bleibt zentrale Steuerungseinheit. Er formuliert Erwartungen an Ergebnisse (z. B. durch Sprint-Ziele) und kommuniziert mit dem Project Board.

Die operative Umsetzung – das Wie – bleibt dem agilen Team überlassen.

Konkrete ToDos zur Einführung von PRINCE2 Agile

Maßnahme	Ziel	Verantwortlich
Agile Rollen einführen	Struktur im Team	Projekt Manager
Backlog aufbauen	Anforderungen operationalisieren	Product Owner
Sprintstruktur definieren	Timeboxing ermöglichen	Scrum Master
Working Agreement erstellen	Erwartungsklärung	PO + PM + Team
Visualisierung etablieren	Transparenz schaffen	Team
Governance beibehalten	Entscheidungspunkte sichern	PM + Project Board
Review-Formate etablieren	Feedbackschleifen aktivieren	PO + Team

Integrationsempfehlungen

• Phase ≠ Sprint: Eine PRINCE2-Phase kann mehrere agile Iterationen enthalten. Entscheidend ist, dass sie mit einem Entscheidungspunkt endet.
• Arbeitspaket = Sprint-Ziel: Das klassische Work Package wird durch inkrementell definierte Lieferobjekte ersetzt.
• Berichte ≠ Reports: Der Fortschritt wird visuell (Burn-Down, Taskboard) und durch Sprint-Reviews dargestellt – nicht durch Word-Dokumente.
• Governance bleibt klassisch: Entscheidungen, Budgetfreigaben und Eskalationen erfolgen nach PRINCE2.

Ich bin Scrum Master / Product Owner – was muss ich jetzt wissen?

Wenn Sie Scrum Master oder Product in einem PRINCE2 Agile-Projekt sind, gilt:

• Sie agieren im operativen Bereich, innerhalb der jeweiligen Projektphase
• Sie arbeiten eng mit dem Projekt Manager zusammen und Ihrem Agilen Gegenstück (Scrum Master, Product Owner, je nachdem welche Rolle Sie ausfüllen)
• Sie verantworten Ihre regulären Anforderungen im Scrum, wie bisher auch
• Sie unterstützen Ihren Projekt Manager dabei, die Anforderungen aus den Work Packages in konkrete Sprints herunterzubrechen
• Sie eskalieren Abweichungen an den Projekt Manager, sobald Ihre Toleranzen oder die des Teams ausgeschöpft sind

Ihr Fokus bleibt auf dem Team – der Projekt Manager verantwortet Kommunikation und Steuerung gegenüber der Organisation.

Für viele Scrum Teams wird dies keine neue Entwicklung sein, da sie im Grunde häufig so arbeiten und einem Projekt Manager unterstehen. PRINCE2 Agile gibt diesem nur einen messbaren Rahmen, der für mehr Klarheit sorgt.

Dabei gilt – wie immer: ein offener Austausch mit dem Projekt Manager über Kapazitäten, Fortschritt und Risiken ist zentral für das Zusammenspiel.

Fazit: PRINCE2 Agile bringt beides zusammen

• Governance bleibt – Agilität kommt hinzu
• Steuerung wird erhalten – Umsetzung wird flexibler
• Projekt Manager und agiles Team arbeiten nicht gegeneinander, sondern nebeneinander

PRINCE2 Agile ist damit ein struktureller Brückenschlag – keine Umstellung, sondern eine gezielte Ergänzung.

Mehr erfahren?

Wir helfen Ihnen bei der Einführung von PRINCE2 Agile – sei es im Training, in der Projektvorbereitung oder im operativen Coaching.

Sprechen Sie uns an – wir machen Governance und Agilität anschlussfähig.

(Der Beitrag wurde von KI strukturiert und das Teaserbild von KI generiert)

Bisher haben wir geklärt, worum es im Projekt geht, warum es sinnvoll ist, wer verantwortlich ist und wie mit Qualität und Risiken umgegangen wird.
Aber wie behalten wir im operativen Alltag wirklich die Kontrolle? Wie stellen wir sicher, dass Projekte nicht „durchlaufen“, sondern gesteuert werden?

PRINCE2 liefert mit dem Konzept der Phasensteuerung und Toleranzen ein praxistaugliches Modell, um genau das sicherzustellen.

Warum Phasen?

Projekte sind komplex. Wer sie von Anfang bis Ende „in einem Guss“ plant und durchführt, verliert schnell die Übersicht.
PRINCE2 strukturiert deshalb Projekte in Managementphasen – klare Abschnitte mit definierten Zielen, Zuständigkeiten und Kontrollpunkten.

Am Ende jeder Phase wird evaluiert:

• Haben wir geliefert, was geplant war?
• Sind Zeit, Kosten und Qualität im Rahmen?
• Müssen wir etwas anpassen?

Nur wenn der Lenkungsausschuss (Project Board) zufrieden ist, wird die nächste Phase freigegeben.

Wichtig: Eine Managementphase muss nicht synchron zur Umsetzung verlaufen. Sie kann z. B. mehrere agile Iterationen oder Sprintzyklen umfassen, oder auch reine Planung und Entscheidungsfindung beinhalten. Entscheidend ist nicht die operative Struktur, sondern der Projektsteuerungspunkt nach außen.

Wie sich die Teams innerhalb einer Phase organisieren – ob klassisch, agil oder hybrid – ist ihnen überlassen. Die Managementphase definiert lediglich den äußeren Steuerungsrahmen.

Einen tieferen Einblick in das Zusammenspiel von PRINCE2 und agilen Methoden geben wir in einem separaten Beitrag zu PRINCE2 Agile.

Was sind Toleranzen?

Innerhalb jeder Phase erhält der Projekt Manager Steuerungsspielraum in Form von Toleranzen. Das bedeutet: Solange Zeit, Kosten, Qualität, Umfang, Risiken und Nutzen sich innerhalb festgelegter Toleranzgrenzen bewegen, darf das Projekt eigenständig weiterlaufen.

Beispiele für Toleranzen:

Steuergröße	Beispielhafte Toleranz
Zeit	± 5 Arbeitstage
Kosten	± 10.000 €
Qualität	Muss-Kriterien vs. Kann-Kriterien
Umfang	Nur bestimmte Features können gestrichen werden
Risiko	Nur bekannte Risiken ohne externe Eskalation

Was passiert bei Abweichungen?

Sobald eine Toleranz über- oder unterschritten wird, spricht man von einer Ausnahme. In diesem Fall muss der Projekt Manager an den Lenkungsausschuss berichten und eine Entscheidung einholen – z. B. eine Freigabe für neue Mittel, eine Anpassung des Zeitplans oder eine Repriorisierung der Features, welches gegebenenfalls auch in einer Streichung bestimmter Anforderungen münden kann.

Praxistipp:
Toleranzen sollten bewusst verhandelt werden. Zu eng? Mikromanagement. Zu weit? Kontrollverlust. Die Balance liegt im Vertrauen und in der Projektumgebung.

Wie setzen wir das in der Praxis um?

Wir strukturieren Projekte gemeinsam mit unseren Kunden typischerweise in:

1. Vorbereitungsphase (Projektstart, Setup)
2. Planungsphase (Anforderungsdefinition, Lösungsauswahl)
3. Umsetzungsphase(n) (1-n Phasen Entwicklung, Rollout, Tests)
4. Übergabe-/Abnahmephase (Go-Live, Schulung, Projektabschluss)

Jede Phase endet mit einem Phasenabschlussbericht und einem Entscheidungspunkt, ob und wie es weitergeht.

Die Toleranzen werden:

• im Projektauftrag festgelegt (Rahmenbedingungen)
• für jede Phase präzisiert (z. B. in Checklisten oder im Controlling-Dashboard)
• aktiv überwacht (z. B. durch das Projektbüro oder in Projekt-Weeklys)

Was bringt das?

Phasensteuerung und Toleranzen:

• strukturieren das Projekt
• schaffen klare Erwartungen
• geben dem Projekt Manager Handlungsfreiheit
• ermöglichen dem Lenkungsausschuss gezielte Steuerung
• reduzieren Risiken durch vordefinierte Eingriffspunkte

Nächster Beitrag der Serie

Im nächsten Teil unserer Serie gehen wir auf das Thema Änderungsmanagement ein – und zeigen, wie PRINCE2 dafür sorgt, dass Änderungen kontrolliert und nachvollziehbar bleiben.

Möchten Sie Projekte strukturierter steuern?

Wir helfen Ihnen, Phasenstrukturen und Toleranzmodelle auf Ihre Organisation anzupassen – ob für klassische Projekte oder hybride Vorhaben.

Sprechen Sie uns an – für Projekte, die planbar bleiben, auch wenn sich alles verändert.

(Der Beitrag wurde von KI strukturiert und das Teaserbild von KI generiert)

In den letzten Beiträgen haben wir Struktur, Entscheidungen und Qualität beleuchtet – nun folgt ein Thema, das nicht nur schützt, sondern aktiv gestaltet: Risikomanagement. Es geht dabei nicht nur um Gefahren – sondern auch um Chancen, die gezielt genutzt werden können.

PRINCE2 kombiniert pragmatische Werkzeuge mit einem systematischen Ansatz. In der Praxis orientieren wir uns zusätzlich an den internationalen Grundsätzen der ISO 31000, um Risiken und Chancen effektiv zu managen.

Warum ist Risikomanagement unverzichtbar?

Projekte bewegen sich fast immer in Unsicherheit: neue Technologien, neue Teams, ambitionierte Zeitpläne oder externe Abhängigkeiten. Wer Risiken erkennt, bevor sie eintreten, gewinnt wertvolle Zeit und Handlungsspielraum – und kann professionell steuern, statt hektisch zu reagieren.

Risikomanagement bedeutet: Handlungsfähigkeit durch Voraussicht. Und: Chancen erkennen, bevor sie verpuffen.

Was versteht PRINCE2 unter Risikomanagement?

Risiken im PRINCE2-Kontext sind potenzielle Abweichungen vom Plan, die sich negativ oder positiv auf den Projekterfolg auswirken können.

• Negative Auswirkungen = klassische Risiken
• Positive Auswirkungen = Chancen

Ziel ist es, Risiken zu vermeiden oder zu mindern – und Chancen aktiv zu nutzen.

PRINCE2 verlangt dafür:

• eine Risikopolitik
• einen projektindividuellen Risiko-Management-Ansatz
• ein Risikoregister
• die laufende Steuerung und Überwachung

Orientierung an ISO 31000

Die Norm ISO 31000 liefert Prinzipien und Leitlinien für ein organisationsweites Risikomanagement. In Projekten lassen sich daraus folgende Best Practices ableiten:

• Risiken und Chancen werden in Entscheidungen eingebettet
• Die Verantwortung für Risiken liegt auf allen Ebenen
• Kommunikation und Transparenz sind Kernelemente
• Das Risikomanagement ist dynamisch und iterativ

Wir nutzen ISO 31000 bewusst ergänzend zu PRINCE2 – vor allem in regulierten oder komplexen Projektumfeldern.

Alternative zur ISO 3100

Wer mit der ISO 31000 nicht vertraut ist, oder sich die notwendigen Dokumente hierfür nicht extra kaufen möchte, dem empfehlen wir den BSI Standard 200-3, welcher eine Interpretation des BSI für Risikoanalyse darstellt und kostenlos verfügbar ist – auch wenn hier die Chancen nicht separat betrachtet werden.

Wie setzen wir das in der Praxis um?

Wir folgen einem strukturierten, fünfstufigen Ansatz – bewährt in PRINCE2 und anschlussfähig an ISO 31000:

1. Risiken und Chancen identifizieren

Wir analysieren gemeinsam mit Stakeholdern:

• Was kann das Projekt gefährden?
• Wo entstehen positive Effekte, die bisher nicht genutzt werden?

Beispielhafte Chancen:

• Automatisierung reduziert langfristig interne Aufwände
• Externe Projektkommunikation steigert die Markenwahrnehmung
• Innovationspotenzial durch agile Methoden oder neue Tools

Praxistipp:
Verwende Kategorien wie „technisch“, „organisatorisch“, „rechtlich“, „strategisch“. So werden Risiken und Chancen differenziert sichtbar.

2. Bewerten

Für jede Unsicherheit wird abgeschätzt:

• Wie wahrscheinlich ist der Eintritt?
• Wie stark wäre die Auswirkung?

Für Chancen:

• Was ist der potenzielle Gewinn?
• Lohnt sich die Investition in die Realisierung?

Ereignis	Eintritt	Auswirkung	Typ	Bewertung
Lieferverzögerung	hoch	mittel	Risiko	hoch
Datenschutzlücke	gering	hoch	Risiko	mittel
Prozessautomatisierung	mittel	hoch	Chance	hoch
Cross-Selling-Effekt	niedrig	mittel	Chance	gering

3. Maßnahmen planen

Für Risiken:

• Vermeiden, mindern, übertragen, akzeptieren

Für Chancen:

• Fördern, intensivieren, aktivieren, beschleunigen

Dabei definieren wir für jede Maßnahme:

• Verantwortliche Person (Risk/Opportunity Owner)
• Frühindikatoren und Prüfzeitpunkte
• Aufwand und erwartete Wirkung

4. Überwachen

Das Risikoregister ist ein lebendes Dokument. Es wird in regelmäßigen Projekt-Reviews aktualisiert:

• Risiken entfallen oder verändern sich
• Chancen entstehen durch Projektfortschritt oder Marktveränderungen
• Maßnahmen werden dokumentiert und neu bewertet

5. Kommunizieren

Transparenz ist der Schlüssel:

• Alle Beteiligten kennen relevante Risiken und Chancen
• Eskalationspfade sind klar
• Steuerungsgremien erhalten regelmäßig aktualisierte Risikoübersichten

Praxistipp:
Binden Sie Risiken fest in Ihre Projekt-Governance ein. Risiken, die nicht besprochen werden, bleiben bestehen – unabhängig davon, ob sie dokumentiert sind.

Zusammengefasst

Professionelles Risikomanagement:

• reduziert Unsicherheit
• erhöht Projektkontrolle
• eröffnet neue Handlungsspielräume

Risikomanagement ist keine Pflichtübung – sondern strategisches Führungsinstrument.

Nächster Beitrag der Serie

Im nächsten Teil zeigen wir, wie Phasensteuerung mit Toleranzen in PRINCE2 funktioniert – und wie man Projekte in überschaubare, steuerbare Abschnitte gliedert.

Möchten Sie Ihre Risiken und Chancen gezielt managen?

Wir unterstützen Sie beim Aufbau eines praxisnahen Risikomanagements – orientiert an PRINCE2, angereichert mit ISO 31000, aber vor allem: angepasst auf Ihre Realität.

Sprechen Sie uns an – wir helfen Ihnen, auf Unsicherheit vorbereitet zu sein.

(Der Beitrag wurde von KI strukturiert und das Teaserbild von KI generiert)

Im vorherigen Beitrag haben wir die Rollen im Projekt beleuchtet – wer ist wofür zuständig, wer liefert, wer prüft. Nun folgt die logische Fortsetzung: Wie laufen Entscheidungen im Projekt ab? Welche Meetings braucht es? Wer entscheidet wann – und auf welcher Grundlage?

PRINCE2 liefert dazu ein Governance-Modell, das Klarheit schafft, ohne Bürokratie aufzublähen. In der Praxis ist das ein entscheidender Erfolgsfaktor – besonders, wenn mehrere Parteien beteiligt sind.

Warum strukturierte Entscheidungswege wichtig sind

Projektentscheidungen treffen wir selten spontan. Oft hängt viel daran: Budget, Umsetzungszeit, Akzeptanz bei Nutzern. Ohne klare Gremien und Entscheidungsroutinen verzetteln sich Teams schnell oder laufen in Eskalationen.

Gute Governance bedeutet, dass:

• Entscheidungen nachvollziehbar und dokumentiert getroffen werden
• die richtigen Personen im richtigen Moment involviert sind
• und dass Regeltermine Orientierung und Sicherheit geben

Welche Gremien sieht PRINCE2 vor?

Zentral ist der Lenkungsausschuss (Project Board) – das oberste Entscheidungsorgan im Projekt. Er setzt sich zusammen aus dem Auftraggeber (Executive), dem Senior User und dem Senior Supplier. Dieses Gremium gibt den Kurs vor und entscheidet bei:

• Phasenfreigaben
• Wesentlichen Änderungen (Change Requests)
• Eskalationen über Toleranzgrenzen

Der Projekt Manager steuert operativ – innerhalb der vom Lenkungsausschuss vorgegebenen Leitplanken (Toleranzen für Zeit, Kosten, Qualität etc.).

Typische PRINCE2-Meetings in der Projektsteuerung

Im Alltag etablieren sich bewährte Formate, die je nach Projektgröße und Organisation angepasst werden. Eine Auswahl:

Meeting-Typ	Teilnehmer	Zielsetzung	Frequenz
Kick-off	Alle relevanten Stakeholder	Gemeinsames Verständnis, Projektstart	Einmalig zu Beginn
Lenkungsausschuss-Sitzung	Project Board, Projekt Manager	Entscheidung über Freigaben, Eskalationen, Steuerung	Phasenweise (z. B. monatlich)
Weekly oder Biweekly Project Sync	Projekt Manager, Teammanager	Statusabgleich, Risiken, nächste Aufgaben	Wöchentlich / 14-täglich
Quality Review / Prüfrunde	Projekt Manager, Project Assurance	Prüfung von Zwischenergebnissen oder Meilensteinen	Bei Bedarf / phasenabhängig
Change Review Board (optional)	Project Board oder benanntes Gremium	Bewertung und Freigabe von Änderungsanträgen	Nach Bedarf
Lessons Learned / Projektabschluss	Projektteam, Project Board	Rückblick, Verbesserungspotenziale identifizieren	Einmalig am Ende

Praxistipp:
Alle Meetings haben ein definiertes Ziel, eine vorbereitete Agenda und idealerweise ein festes Zeitfenster. Entscheidungen werden protokolliert – in einfachen, nachvollziehbaren Dokumenten (z. B. in einem Projekttagebuch oder Entscheidungsprotokoll).

Governance für hybride Teams

Insbesondere bei der Zusammenarbeit mit Externen ist es wichtig, dass Governance nicht implizit bleibt. Wir machen Entscheidungswege sichtbar, besprechen Erwartungen frühzeitig und schaffen Schnittstellen zwischen Projektteam, Fachbereichen und Steuerungsgremien.

Tools wie folgende helfen dabei:

• Entscheidungsregister mit Status (offen, genehmigt, abgelehnt)
• Standardisierte Entscheidungsvorlagen
• Governance-Canvas für Workshops

Zusammengefasst

Projekt-Governance bedeutet: Entscheidungen werden planbar, transparent und nachvollziehbar getroffen. PRINCE2 bietet dafür eine klare Struktur – flexibel genug, um in jeder Organisation angewendet zu werden.

Nächster Beitrag der Serie

Im nächsten Teil schauen wir auf das Thema Qualitätsmanagement im Projekt: Wie wir Qualität nicht nur kontrollieren, sondern gezielt aufbauen und sichern.

Möchten Sie Ihre Projektentscheidungen sicher strukturieren?

Wir helfen Ihnen, passende Entscheidungsprozesse aufzusetzen – angepasst an Ihre Organisation, Ihre Kultur und Ihre Projektkomplexität.

Sprechen Sie uns an – wir zeigen Ihnen, wie Sie mit klarer Governance mehr Vertrauen und Effizienz in Ihre Projekte bringen.

(Der Beitrag wurde von KI strukturiert und das Teaserbild von KI generiert)

Im letzten Beitrag unserer Serie haben wir uns mit dem Business Case beschäftigt – der wirtschaftlichen Begründung eines Projekts. Doch selbst das beste Projektziel bleibt wirkungslos, wenn nicht klar ist, wer wofür verantwortlich ist.

Genau hier setzt PRINCE2 mit seinem differenzierten Rollenmodell an. Es geht nicht um Hierarchie, sondern um Klarheit: Wer entscheidet? Wer liefert? Wer prüft? Und wer unterstützt?

Warum sind klare Rollen so wichtig?

Projekte scheitern selten an fehlenden Ideen – oft aber an Unklarheit in der Zusammenarbeit. Unausgesprochene Erwartungen, doppelte Arbeit oder übersehene Zuständigkeiten führen zu Friktionen. Besonders dann, wenn interne Teams und externe Partner gemeinsam arbeiten, ist eine eindeutige Rollenverteilung entscheidend.

Ein Projekt braucht Struktur, um flexibel zu sein. Und das bedeutet: Jeder weiß, was von ihm erwartet wird – und was nicht.

Welche Rollen sieht PRINCE2 vor?

PRINCE2 unterscheidet bewusst zwischen drei Interessenlagen im Projekt: Business, User und Supplier. Daraus leiten sich die zentralen Rollen ab:

1. Auftraggeber (Executive)

Vertritt die geschäftlichen Interessen des Unternehmens, was das Projekt beauftragt. Trägt die letztliche Verantwortung für das Projekt und stellt sicher, dass es wirtschaftlich sinnvoll ist.

2. Lenkungsausschuss (Project Board)

Setzt sich zusammen aus:

• dem Auftraggeber (Executive)
• einem Vertreter der Nutzer (Senior User)
• einem Vertreter der Lieferanten (Senior Supplier)

Der Lenkungsausschuss trifft die übergeordneten Entscheidungen, priorisiert und genehmigt Meilensteine sowie Änderungen.

3. Projekt Manager (Project Manager)

Verantwortlich für die operative Steuerung. Koordiniert Ressourcen, Termine, Risiken, Berichte – und sorgt dafür, dass alles strukturiert abläuft.

4. Teammanager (Team Manager)

Führen konkrete Arbeitspakete aus. Häufig externe Dienstleister oder Fachverantwortliche im Unternehmen. Berichten an den Projekt Manager.

5. Projektsicherung (Project Assurance)

Unabhängige Kontrolle und Beratung. Unterstützt das Lenkungsgremium dabei, Qualität, Risiken und Fortschritte objektiv zu bewerten. Ist dabei näher am Tagesgeschäft als die Lenkungsverantwortlichen.

6. Projektunterstützung (Project Support)

Stellt die Infrastruktur sicher – etwa Tools, Berichte, Dokumentation oder Terminplanung. In größeren Projekten ein eigenes PMO.

Wie setzen wir das in der Praxis um?

In unseren Projekten starten wir in frühen Phasen mit einem Verantwortlichkeits-Workshop. Ziel ist es, nicht nur PRINCE2-Rollen zuzuweisen, sondern sie auch in die reale Organisationsstruktur zu übersetzen.

Wir verwenden dafür u. a.:

• RACI-Matrixen, um Verantwortlichkeiten bei Aufgaben greifbar zu machen:

Beispiel	R	A	C	I
Projektplan erstellen	Project Manager	Executive	Senior User	Team Manager
Testdurchführung	Team Manager	Project Manager	Project Assurance	Senior Supplier
Änderungsfreigabe	Project Manager	Project Board	Senior User, Senior Supplier	Project Support

• Rollenkarten zur schnellen Übersicht. Beispiel:
  Rollenkarte: Projekt Manager
  • Ziel: Umsetzung des Projekts im Rahmen von Zeit, Kosten, Qualität
  • Zuständigkeiten:
    • Koordination von Arbeitspaketen
    • Risikomanagement
    • Berichtswesen an den Lenkungsausschuss
    • Vorbereitung von Entscheidungen
  • Entscheidungsbefugnisse:
    • Entscheidungen im Rahmen der Toleranzen
    • Eskalation bei Überschreitungen
• Kick-off-Präsentationen, in denen Rollen visuell und narrativ vermittelt werden

Praxistipp:
Gerade bei externen Beteiligten lohnt es sich, nicht nur die Rolle zu klären – sondern auch die Kommunikationswege: Wer eskaliert wie, wann, wohin?

Warum ist das auch für Externe so entscheidend?

Berater, Dienstleister oder neue Projektbeteiligte kennen die internen Zuständigkeiten nicht aus dem Effeff. Eine klare Rollenstruktur hilft dabei, Reibungsverluste zu vermeiden und schafft Verlässlichkeit. Es ermöglicht externen Partnern, schnell effektiv mitzuarbeiten – ohne langwierige Abstimmungsschleifen.

Ausblick: Wie wird im Projekt entschieden?

Wenn Rollen und Zuständigkeiten klar sind, stellt sich zwangsläufig die nächste Frage: Wie wird im Projekt entschieden? Wer gibt was frei? Und wann treffen sich welche Gremien?

Genau darum geht es im nächsten Teil unserer Serie: Wir werfen einen Blick auf die Projekt-Governance nach PRINCE2 – und zeigen, wie regelmäßige Strukturen helfen, Entscheidungen transparent, nachvollziehbar und effizient zu gestalten.

Möchten Sie Ihre Projektrollen sauber strukturieren?

Wir helfen Ihnen, PRINCE2-konforme Rollenmodelle auf Ihre Organisation zu übertragen – verständlich, praktikabel und integriert in Ihre bestehenden Prozesse.

Kontaktieren Sie uns – und bringen Sie Struktur in Ihre Projekte.

(Der Beitrag wurde von KI strukturiert und das Teaserbild von KI generiert)