Variante 1: Der Product Owner ist der Prince2-Projekt-Manager
In einem weniger komplexen Projekt bietet es sich an, den Product Owner zum Prince2-Projekt-Manager zu machen. Er ist dann für das Ergebnis verantwortlich. Dabei darf er das Team nach eigenem Ermessen führen beziehungsweise organisieren. Insofern kann er durchaus zulassen, dass sich das Team nach Scrum selbst organisiert - jedenfalls, solange es innerhalb der Toleranzen seines Auftrags agiert.
Auf diese Weise bekommt das Projekt das Beste aus beiden Welten. Es hat einen Projekt-Manager, der während des Projekts das Tagesgeschäft im Auftrag des Lenkungsausschusses steuert. Sollte sich abzeichnen, dass - insbesondere zwischen den Sprints beziehungsweise Arbeitspaketen - der Handlungsspielraum (hinsichtlich Kosten, Nutzen, Qualität, Risiken etc.) überschritten wird, muss der Projekt-Manager die "Lenker" um eine Entscheidung bitten. Schließlich kann es durchaus sein, das sich die Fortsetzung des Projekts nicht lohnt.
Als Projekt-Manager und Arbeitspaket-Verantwortlicher ist der Product Owner Bindeglied zwischen dem Senior Management und der agilen Detail- oder Lieferebene. Der Prince2-Rahmen sorgt dafür, dass es auf der Teamebene nicht zu viele Überraschungen gibt, weil das Projekt zielgerecht gelenkt wird.
Sowohl Arbeitspakete als auch das Tagesgeschäft werden vom Product Owner fachlich geführt. In den Arbeitspaketen geht es um die technische Umsetzung der fachlichen Anforderungen. So steht der Nutzen des Fachbereichs immer im Vordergrund des Projekts.
Die täglichen Scrum-Meetings machen viele E-Mails und weitere Besprechungen auf der Arbeitspaket-Ebene überflüssig. Die Kommunikation bleibt allerdings nur effektiv, so lange das Team klein ist. Außerhalb der Arbeitspakete kommt deshalb wieder Prince2 ins Spiel. Das sorgt für eine effektive Kommunikation und Zusammenarbeit zwischen
-
Lenkungsebene (Lenkungsausschuss) beziehungsweise darüber liegender Programm- oder Unternehmensebene;
-
Steuerungsebene (Projekt-Management in unterschiedlichen Phasen) und
-
Lieferebene (Arbeitspakete, Sprints).
Hier findet der Austausch nicht ständig, sondern nur im Ausnahmefall und zielgerichtet nach Rollen statt. So leidet das Projektumfeld nicht unter einer Kultur à la: "Jeder muss mit jedem über alle Details sprechen". Falls zwischen den Arbeitspaketen viele Abhängigkeiten bestehen, kann der Lenkungsausschuss nach Prince2 Entscheidungen auch an einen Änderungsausschuss delegieren.
- Spielregeln für das Projekt-Team
Diese Spielregeln sorgen für eine offene Kommunikation und bieten auch im Konfliktfall eine Orientierung. - Projektauftrag klar definieren
Der Projektauftrag ist das A und O der Projektdurchführung. Er bildet die Grundlage für die Abnahme der Projektergebnisse und damit den Projekterfolg! - Projekt in steuerbare Arbeitspakete schneiden
In jeder Phase des Projekts den Überblick bewahren. - Betroffene zu Beteiligten machen
Ein offenes Ohr für die Projektbeteiligten erhöht die Akzeptanz der zukünftigen Nutzer. - Projekt(kern)team klein halten
Auch bei der Durchführung eines Projektes gilt: Zu viele Köche verderben den Brei. - Umgang mit Change Requests definieren
Hinterfragen Sie Änderungswünsche während der Projektdurchführung kritisch und prüfen Sie sie auf ihre Sinnhaftigkeit. - Abnahme-Prozess formalisieren
Keine Kritik ohne Verbesserungsvorschlag: Ein Feedback-Formular mit Pflichtfeld "Verbesserungsvorschlag" sorgt für Konstruktivität im Feedback-Prozess. - Projektmanagement leben
Kommunikation, Kommunikation und nochmal Kommunikation! - Management of Change: „Hypercare“ einplanen
Ein speziell hierfür ernannter Ansprechpartner hilft über Probleme und Sorgen in den ersten Tagen nach der Systemeinführung hinweg. - Übergabe in den Betrieb sicherstellen
Eine geregelte Übergabe ermöglicht den reibungslosen Betrieb des IT-Systems. - Lessons Learned
Die Erfahrungen sollten am Ende eines Projekts zusammengetragen werden, um für die nächsten Projekte zu lernen.