Um den Abschluss und die Abschlussarbeiten am Projektende oder auch am Phasenende – je nach Projektgröße.
Oder auch: Wenn ein Schiff in den Hafen einfährt, ist der Törn noch lange nicht vorbei. Das Ankerbier gibt es erst, nachdem der Kahn sauber am Kai liegt.
Kurze Erinnerungshilfe
Klärt, was alles am Ende eines Projekts (oder einer Phase) geschehen muss.
Produktübergänge in die Linie.
Teamrückführung, Entlassung in die Linie.
Administrativer Abschluss, z. B. Projektdoku ablegen und letzten Statusbericht abgeben.
Formale Entlastung des Teams und des Projektleiters.
Feiern – im Sinne des Teamzusammenhalts wichtig.
Lessons (which I have) Learned. Ist etwas anderes als der administrative Abschluss.
Die Abnahme liegt häufig vor dem Abschluss, da erst mit der Abnahme durch den Kunden das Projekt abgeschlossen werden kann.
Kurze Erinnerungshilfe
Wie bereiten wir das Projektende vor? Üblicherweise durch eine Abschlussphase.
Normalerweise sind wir vorher mit demProdukt fertig, der Kunde hat es abgenommen.
Aber damit ist das Projekt nicht beendet, es ist noch einiges zu tun.
Wenn wir das nicht ordentlich machen, kann es teuer werden, da das Projekt nie zu Ende geführt mutiert und zum Zombieprojekt wird.
Kurze Erinnerungshilfe
Produkt abnehmen – der Anfang vom Ende.
Produkt übergeben, evtl. mit Dokumentation und Schulung.
Administrativ abschließen
Projektabschlussbericht erstellen – Soll-Ist-Vergleich zwischen Ziel und Ergebnis.
Team entlasten
Sun-Set-Meeting durchführen
Projektleiter entlasten
Team in die Linie zurückführen
Feedback aus/an Linie, Steuerungskreis, Kunde…
Lessons Learned durchführen.
DevOps im agilen Kontext
Der klassische Gedanke ist geprägt von der (Produkt-)Erstellung und (Linien-) Übergabe, wie hier beschrieben. Könnte prinzipiell auch für agile Projekte gelten, da die Erstellungsform zunächst keinen Einfluss auf das Produkt hat.
Aber: Am Ende eines Sprints findet sich idealerweise ein „potentially shippable product“. Wenn also tatsächlich nach jedem Sprint das im Echtbetrieb befindliche Produkt eine Aktualisierung erfährt, dann muss ein ganz anderes Augenmerk auf die Verzahnung und Integration von Entwicklung (Development) und Betrieb (Operations) gelegt werden. Das ist dem Schlagwort „DevOps“ gemeint.
Reflektionsfragen
Wie hängen Abnahme und Abschluss zusammen?
Wie wird idealerweise der Übergang der Verantwortlichkeiten geregelt?
Was genau führt zu Zombieprojekten?
Wie könnten Zombieprojekte beendet werden?
Zum Weiterlesen
PMBOK Guide, 6.Ausgabe, Prozess 4.6 – Projekt oder Phase abschließen
Kein Plan hat jemals den ersten Kontakt mit dem Feind überlebt – Originalzitat von Generalfeldmarschall von Moltke.
Es ist also nicht die Frage, ob es Änderungen gibt, sondern wie sie organisiert werden.
Kurze Erinnerungshilfe
Änderungen an Inhalt und Umfang, Kosten und Terminen.
Wichtig ist in diesem Zusammenhang das Konfigurationsmanagement. In der Praxis häufig bei komplexen technischen Produkten anzutreffen.
Konfigurationsmanagement beschreibt, welche Versionen der Einzelteile eine gültige Konfiguration ergeben.
Konfigurationsmanagement kann auch auf das Projektmanagement selbst angewendet werden.
Kurze Erinnerungshilfe
Wieder ein Planungsthema: Wie möchten wir in unserem Projekt Change Management durchführen?
Aspekte eines Change Management Plans könnten sein:
Wo können wir bei Änderungen was drehen? (Zielhierarchie, Abklärung des Dreizwangs)
Für welche Änderungen gilt der Change-Prozess?
Wie wahrscheinlich sind Änderungen und wie groß könnten sie sein?
Welchen Aufwand wird das Änderungsverfahren an sich benötigen?
Wer hat welche Rolle, welche Verantwortlichkeit, welche Befugnisse?
Wie zeichnen wir die Changes auf, wie überwachen und wie berichten wir sie?
Welche Arten bzw. Kategorien von Changes gibt es? Und wie gehen wir jeweils damit um?
Wie werden Änderungen evaluiert?
Wie und wann wird die Projektdokumentation aktualisiert?
Wie wird das Projektteam über Änderungen informiert?
Wichtig: Nicht alles muss für jedes Projekt zutreffen.
Kurze Erinnerungshilfe
Folgende Fragen sollten im Change Management Plan geklärt werden:
Wann ist ein Change ein Change?
Nur bei Veränderungen der Rahmenbedingungen?
Oder auch bei Abweichungen vom Plan?
Liegt ein Change vor, dann sollte man:
Change analysieren und bewerten.
Bewertung der Gesamtauswirkung zur Entscheidung dem Steuerkreis vorlegen.
Entscheiden lassen.
Entscheidung umsetzen.
Gesamtsystem konsistent halten.
Zur Konsistenz:
Alle Projektmanagementartefakte müssen zueinander passen.
Was muss bei einem Change alles geändert werden?
Das Konsistent-halten kann auch als Konfigurationsmanagement gesehen werden.
Konfigurationsmanagement: Welche Version von welchem „Teil“ passt zu welcher Version eines anderen „Teils“ und bilden zusammen eine gültige Gesamtkonfiguration?
Change & Agile Projekte
Eine der wichtigsten Merkmale agiler Projekte sind die so genannten „Build-In Changes“. Durch die Repriorisierung des Backlogs nach jedem Review ist tatsächlich ein Change-Automatismus geschaffen, der seines Gleichen sucht.
Daher wäre es ein Verbrechen am agilen Ansatz, Backlogs einzufrieren oder nur durch Change Requests zu ändern. Dann ist fraglich, ob überhaupt noch Agilität stattfindet.
Allerdings lauert hier auch die Gefahr, dass sich die Entwicklung und die Backlogs voneinander loslösen. Es findet dann eine schleichende Erweiterung des Inhalts und Umfangs statt (Scope Creep), der dann auch zur teuren und Never-Ending-Story mutieren kann.
Insbesondere in hybriden Projekten müssen Ansätze gefunden werden, die trotz Agilität einen Change Prozess beinhalten. Ein durchgängiger Methodenansatz liegt hierfür aber derzeit nicht vor.
Reflektionsfragen
Wer entscheidet über Änderungen?
Wer bereitet Änderungen auf?
Welche Rolle haben die Projektverantwortlichen im Änderungsprozess
Wie ließe sich in einem agilen (Teil-)Projekt ein geschickter Änderungsprozess implementieren, ohne die Kreativität der Agilität zu gefährden?
Es geht darum, die Arbeit, wie sie im Projektmanagementplan oder auch anderen Planungsschritten festgelegt wurde, anzuleiten und auszuführen. Das Projektschiff wird nun durch die raue See der Projektrealität gesteuert.
Die eigentliche Projektarbeit
Mit Hilfe der bereits besprochenen Instrumente und Werkzeuge wird nun die Projektarbeit auf Basis der Planungen gemanagt und gesteuert, unabhängig vom Projekttyp und der Strategie. Es gilt der klassische PDCA-Deming Cycle, der ausgehend von einer Planung (Plan) die Durchführung veranlasst (Do) und die Ergebnisse überwacht (Check), um ggfs. korrigierend einzugreifen und zu handeln (Act).
Nachfolgend noch eine kurze Diskussion bzw. Illustration zum Thema Abweichung – am Beispiel des Kurses eines Segelboots.
Kurze Erinnerungshilfe
Was bedeutet denn Abweichung vom Plan eigentlich?
Wenn wir nicht genau im Plan sind, muss das keine Abweichung vom Plan bedeuten:
Wir sind immer noch in den vereinbarten Varianzen, in den akzeptierten Schwankungsbreiten.
Oder: Wir haben eine echte Abweichung und führen eine Korrektur durch, um zurück zum Plan zu kommen.
Oder: Wir habe eine echte Abweichung – und planen ab jetzt neu für den Rest.
Reflektionsfragen
Was ist ein Work Authorization System und was ein Project Management Information System?
Wie unterscheiden sich Steuerungsaufgaben im agilen System und im klassischen Projekt?
Zum Weiterlesen
PMBOK Guide, 6.Ausgabe, Prozess 4.3 – Projektdurchführung lenken und managen sowie Prozess 4.4 – Projektarbeit überwachen und steuern
Der Projektmanagementplan (öfters auch mit PMP(!) abgekürzt) beinhaltet alle relevanten Informationen zur Ausführung des Projekts. Dort würde unter anderem auch festgehalten werden, mit welchem Verfahrensansatz das Projekt durchgeführt wird.
Kurze Erinnerungshilfe
Beinhaltet:
die relevanten Basispläne
alle Managementpläne
gewählter Projektansatz (agil, hybrid, klassisch)
gewählter Lebenszyklus
verwendete Prozesse
Drei (klassische) Basispläne:
Termin
Budget
Inhalt und Umfang (Scope Statement, WBS, WBS Dictionary)
Achtung! Es wird eine Unterscheidung getroffen zwischen dem Projektmanagementplan und weiteren Projektdokumenten, die nicht zum Umfang des Projektmanagementplans gehören.
Reflektionsfragen
Welche Ziele und welchen Zweck hat der Projektmanagementplan?
Hat ein agiles Projekt auch einen Projektmanagementplan?
Aus wie vielen Artefakten besteht der Projektmanagementplan? Was sollte mindestens drin sein und was kann alles drin sein?
Wovon hängt es ab, wie umfangreich der Projektmanagementplan ausfällt?
Wer ist für den Projektmanagementplan verantwortlich?
Der Projektauftrag (oder auch mit dem englischen Begriff die Charter) ist die formelle Freigabe der Trägerorganisation, Mittel und Ressourcen für die Durchführung des Projekts einzusetzen. Von einer für diese Aufgabe benannten Person – dem Projektverantwortlichen.
Immer interne Freigabe
Das Prinzip der internen (!) Projektfreigabe ist simpel – und genau darin liegt seine Schwierigkeit.
Die deutsche Übersetzung Projektauftrag des englischen Begriffs Charter ist schon missverständlich, da ein Projektauftrag immer irgendwie nach „Vertrag“ klingt. Die Charter hat seine Analogie aber im Wort Charta – und das ist so eine Art Grundlage.
Für die Freigabe des Projektes wäre eine schriftliche Dokumentation natürlich ideal. Wir behalten aber im Hinterkopf, dass wenn der Chef eine Mitarbeiterin in der Kaffeeküche anspricht und sie bittet, das Projekt, das gerade eben ins Haus geflattert ist, zu übernehmen, dann ist das auch eine Charter.
Die Charter wird immer von einem Sponsor herausgegeben. Je nach Trägerorganisation verbirgt sich dahinter ein riesiger formaler Prozess oder eben auch nur die Kaffeeküche.
Fakt ist, dass mit der Charter das Projekt startet. Jetzt gibt es das Projekt, jetzt wurde aus der Kollegin in der Kaffeeküche die Projektleiterin dieses Vorhabens. Jetzt geht die Verantwortung für die Durchführung über und jetzt kommen all die Instrumente, Methoden, Techniken und Werkzeuge des Projektmanagements zum Einsatz.
Wie lauten die Minimalanforderungen an eine Charter? Nun, wie in der Küche auch: Was soll gekocht werden und wer ist der Koch? Also:
Projektziel
Projektverantwortliche(r)
Wenn bereits weitere Informationen vorliegen (Rahmenbedingungen, gesetzliche Vorgaben, Zeiteinschränkungen, Risiken, Anforderungen usw.) gehören die natürlich auch dazu.
Reflektionsfragen
Wer erstellt die Charter eigentlich?
Wie unterscheiden sich Business Case und Vertrag mit einem externen Kunden von einer Charter?
Werden agile Projekte auch gechartert?
In Scrum gibt es den Begriff Charter nicht. Wie lösen Sie dieses Dilemma?
Zum Weiterlesen
PMBOK Guide, 6.Ausgabe, Kapitel 4, die Einleitung und cProzess 4.1 – Projektauftrag entwickeln
Der Begriff „Stakeholder“ klingt im ersten Moment sehr präzise. Ist er aber nicht. Da ja irgendwie jeder und alle Stakeholder in unterschiedlichen Situationen sein können, kann mit dem Begriff Stakeholder auch immer eine sehr spezielle und eingegrenzte Personengruppe gemeint sein. Je nach Kontext sind unterschiedliche Aspekte, Gruppen und „Arten“ zu betrachten.
Die Unterscheidung auf dieser Seite dient dem besseren Verständnis, warum im Projektgeschäft ständig und dauernd von Stakeholdern die Rede ist, obwohl diese in unterschiedlichen Rollen und Funktionen vorkommen.
Es gibt grundsätzlich beliebig viele und noch andere Unterscheidungen und Klassifizierungen, die je nach Projektumfeld ebenfalls ihre Berechtigung haben:
Passive und aktive Stakeholder
Interne und Externe Stakeholder
usw.
Und wie immer ist die Realität unschärfer und es kann natürlich auch ein Stakeholder in zwei Gruppen gleichzeitig auftauchen.
Betrachten wir nun die unterschiedlichen Stakeholdergruppierungen:
Die Business-Treiber-Stakeholder
Typisierung: Das sind alle, die das Projekt wollen, es unterstützen, Anforderungen haben und sich etwas von dem Projekt versprechen. Aber auch ihre Interessen platzieren möchten, politischen Einfluss nehmen oder Lobbyarbeit betreiben.
Einfluss aufs Projekt: Groß, da sie die Grundlage für die Exisitenzberechtigung des Projekts bilden.
Vorkommnis: Start des Projekts, Vorprojektphase, typische Sparringspartner der Business Analysten. In der Business Analyse gibt es eine eigene Domaine, die sich nur dem Thema widmet, wie man diesen Stakeholdern ihre Anforderungen herauskitzelt (das heißt tatsächlich so!)
Aus Sicht der Projektleitung: Das Verständnis der Projektmotivation ist immer sehr hilfreich, allerdings ist der Grad der Einflussnahme vom Projekt zu diesen Stakeholdern eher gering. Meist ist das Thema ja auch schon platziert, wenn eine Projektmensch die Bühne betritt.
Die Endbenutzer bzw. Kunden
Typisierung: Das sind alle diejenigen, die ganz am Ende mit dem Projektprodukt zu tun haben werden. Die es also nutzen und für ihre Zwecke einsetzen werden. Diese Stakeholder treten in einem klassischen Projekt eher gar nicht oder nur indirekt auf, in einem agilen Projekt wird versucht, frühzeitig mit dieser Gruppe ins Gespräch zu kommen, um die Entwicklung zu beeinflussen. Typisch ist die Teilnahme der Kunden an agilen review-Meetings.
Einfluss aufs Projekt: Im klassischen Projekt meist (leider) nicht so stark wie im agilen Projekt. Wenn das Projektprodukt aber nicht für einen breiten Markt gemacht wird, sondern z.B. eine Spezialanfertigung für eine Fachabteilung ist, dann kann auch im klassischen Umfeld eine starke Interaktion stattfinden.
Vorkommnis: Idealerweise während des gesamten Projektes. Im klassischen Umfeld meist erst ganz am Ende, dann, wenn alles fertig ist. Daher wird versucht, während der Projektlaufzeit die Aspekte dieser Stakeholdergruppe im Qualitätsmanagement aufzufangen („Voice of the Customer“, „Qualität ist, wenn der Kunde zurückkommt und nicht das Produkt“, …)
Aus Sicht der Projektleitung: Eine Berücksichtigung dieser Stakeholdergruppe fällt vielen im Projektgeschäft schwer. Hängt aber stark vom Projekttyp ab und auch von der Methodik.
Die Aufsichtsgremien und Strukturen
Typisierung: Das sind alle diejenigen Stakeholder, die die Projektausführung überwachen und steuern, als Eskalationsinstanz dienen und dem Projekt den Durchführungsrahmen geben. Typischerweise der Lenkungskreis oder Steuerkreis. Diese Stakeholder können ganz eigene Interessenslagen haben und nicht den Produkterfolg an erster Stelle sehen, sondern eher die geräuschlose Projektabwicklung.
Einfluss aufs Projekt: Groß, da ja die Steuerungsebene
Vorkommnis: Während der gesamten Projektlaufzeit. Wird im Projektkontext über das Thema Governance, Struktur, Linie/Projekt, Projektorganisation, PMO usw. abgehandelt.
Aus Sicht der Projektleitung: Da die Steuergremien dem Projekt allgegenwärtig sind, ist die Gefahr, diesen Stakeholder zu vergessen, kaum vorhanden.
Das direkte Arbeitsumfeld
Typisierung: Das sind alle Personen bzw. Personengruppen, die direkt mit dem Projekt zu tun haben, also das Projektteam und der engere Dunstkreis drumrum.
Einfluss aufs Projekt: Groß, da dort die Projektarbeit erfolgt.
Vorkommnis: Während der gesamten Projektlaufzeit. Die Themen dieser Stakeholdergruppe sind Teambuilding, Motivation, Kommunikation, Delegation, Führung, Konflikt, Gruppendynamik, usw.
Aus Sicht der Projektleitung: Extrem wichtig. Vor allem durch den Anspruch an die Projektleitung, eine laterale Führungskraft zu sein. Im agilen Umfeld auch gerne Servant Leadership genannt. Die eigentliche Herausforderung im Projektgeschäft.
Das indirekte Arbeitsumfeld
Typisierung: Das sind alle diejenigen, die sich im weiteren Dunstkreis des Projekts bewegen, aber nichts direkt mit dem Projekt zu tun haben. Die Arbeitskollegen, andere Abteilungen, Stabsstellen, andere Niederlassungen, aber auch z.B. Lieferanten.
Einfluss aufs Projekt: Natürlich viel geringer, werden dadurch aber leicht vergessen und können sich schnell zu einer sehr einflussreichen Stakeholdergruppe entwickeln, die dem Projekt nicht unbedingt wohlgesonnen sein muss.
Vorkommnis: Während des gesamten Projekts, zu Beginn noch in geringerem Ausmaß. Typischer Gegenstand einer neutralen und allgemeinen Stakeholderbetrachtung.
Aus Sicht der Projektleitung: Wird leicht übersehen und ist meist Gegenstand von Kommunikationsüberlegungen, also z.B. im Intranet oder Mitarbeiterzeitschriften.
Projektgegner
Typisierung: Das sind all diejenigen Stakeholder, die qua Amt gegen das Projekt sind, meist auch öffentlichkeitswirksam und laut. Hierunter zählen Bürgerbewegungen, Umweltinitiativen oder andere NGOs. Aber wenn das Projekt zum Gegenstand hat, einen Standort zu schließen und die Abwicklung zu organisieren, dann gehören in diese Kategorie auch jede Menge interne Stakeholdergruppierungen wie Betriebsrat oder Mitarbeiterbewegungen.
Einfluss aufs Projekt: Groß. In Infrastrukturprojekten neigt man dazu, den Stakeholderbegriff nur auf diese Gruppe zu reduzieren, was bedauerlich ist.
Vorkommnis: Formen sich meist im ersten Drittel der Projektlaufzeit.
Aus Sicht der Projektleitung: Diese Stakeholder können ganz eigene Liefergegenstände im Projekt bewirken. Denken wir zum Beispiel an einen Informationspavillion wegen einer Baumaßnahme.
Outer Space
Typisierung: Das sind alle Stakeholder, die scheinbar nichts mit dem Projekt zu tun haben, oder deren Einfluss und Macht auf das Projekt nicht ernstgenommen wird.
Einfluss aufs Projekt: Gering bis gar nicht – wenn dem nicht eine Fehleinschätzung zu Grunde liegt.
Vorkommnis: Wird in der Regel vom Projekt nicht beachtet, maximal in der allgemeinen Kommunikation.
Aus Sicht der Projektleitung: Wahrscheinlich den Aufwand nicht wert, hier Zeit zu investieren. Die Gefahr liegt höchstens in einer Fehleinschätzung. Eine schwedische Schülerin wurde am Anfang auch belächelt…
