C0110

Um was geht’s?

ADKAR ist ein Umsetzungsmodell für Änderungsmanagement

---

---

Kurze Erinnerungshilfe

• Modell für Durchführung von Änderungsmanagement
• ADKAR ist die Abkürzung für fünf Gruppen
  • A – Awareness
  • D – Desire
  • K – Knowledge
  • A – Ability
  • R – Reinforcement
• Die fünf Gruppen haben unterschiedliche Schwerpunkte im Modell
• Die Gruppen lassen sich noch weiter einteilen in
  • Gegenwart, Transition und Zukunft bzw.
  • Vorbereitung, Action, KVP

---

Langversion

---

ADKAR ist ein Modell für Veränderungsmanagement, entwickelt von Prosci, einer renommierten Organisation im Bereich des Change Managements. Das Akronym ADKAR steht für die fünf wesentlichen Phasen, die eine Person durchlaufen muss, um eine erfolgreiche Veränderung im Unternehmen oder im persönlichen Bereich zu erreichen: Awareness (Bewusstsein), Desire (Wunsch), Knowledge (Wissen), Ability (Fähigkeit) und Reinforcement (Verstärkung).

Die erste Phase, Awareness, bezieht sich auf das Bewusstsein über die Notwendigkeit der Veränderung. Hier ist es entscheidend, dass die betroffenen Personen verstehen, warum die Änderung notwendig ist. In der zweiten Phase, Desire, geht es um den Wunsch, an der Veränderung teilzunehmen und sie zu unterstützen. Dies ist oft die schwierigste Phase, da Widerstand gegen Veränderungen überwunden werden muss.

Die dritte Phase, Knowledge, umfasst das Wissen, das benötigt wird, um die Veränderung umzusetzen. Dies kann Schulungen, Anleitungen oder andere Lernressourcen beinhalten. Ability, die vierte Phase, bezieht sich auf die Fähigkeit, die Veränderung in der Praxis umzusetzen. Hier wird das erworbene Wissen angewendet.

Die letzte Phase, Reinforcement, dient dazu, die Veränderung zu festigen und sicherzustellen, dass sie nachhaltig ist. Dies kann durch Feedback, Anerkennung und Belohnungen erfolgen. Das ADKAR-Modell betont die Bedeutung der individuellen Reise durch den Veränderungsprozess und bietet einen strukturierten Ansatz, um sicherzustellen, dass Veränderungen effektiv und dauerhaft umgesetzt werden.

---

Zum Weiterlesen

• Hier die Webseite von Prosci: https://www.prosci.com/methodology/adkar

---

Copyright Gita GmbH. Alle Rechte vorbehalten.

Um was geht’s?

Nachfolgend eine Übersicht von gängigen Begriffen rund um das Tun, das Durchführen – die Integration. In Deutsch und in Englisch.

Reflektionsfragen

• Können Sie jeden der unten stehenden Begriffe zuordnen?
• Gibt es einen Begriff, den Sie noch nie gehört haben?

Develop Project Charter	Projektauftrag entwickeln
Monitor and Control Project Work	Projektarbeit überwachen und steuern
Perform Integrated Change Control	Integrierte Änderungssteuerung durchführen
Project Integration Management	Integrationsmanagement in Projekten
Project Management Plan	Projektmanagementplan
Develop Project Management Plan	Projektmanagementplan entwickeln
Direct and Manage Project Work	Projektdurchführung lenken und managen
Manage Project Knowledge	Projektwissen managen
Configuration Management System	Konfigurationsmanagementsystem
Project Statement of Work	Leistungsbeschreibung des Projekts
Requested Change	Beantragte Änderung
Forecast	Prognose
Lessons Learned	Gesammelte Erfahrungen
Lessons Learned Knowledge Base	Wissensspeicher der gesammelten Erfahrungen
Work Performance Reports	Arbeitsfortschrittsberichte

---

Copyright Gita GmbH. Alle Rechte vorbehalten.

Um was geht’s?

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 dem Produkt 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

ProcessGroupsPracticeGuide (PGPG), Prozess 7.2 – Perform Integrated Change Control

---

Copyright Gita GmbH. Alle Rechte vorbehalten.

Um was geht’s?

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?

---

Zum Weiterlesen

• ProcessGroupsPracticeGuide (PGPG), Prozess 7.1 – Monitor and Control Project Work
• Practice Standard for Project Configuration Management 
• Managing Change in Organizations: A Practice Guide

---

Copyright Gita GmbH. Alle Rechte vorbehalten.

Um was geht’s?

Der „Blick zurück“ ist mit das wichtigste Element im gesamten Projektmanagement-Zyklus. Nur leider wird dieser Blick viel zu selten gewagt…

---

---

Kurze Erinnerungshilfe

• Lektionen, die gelernt wurden – und die hoffentlich einen Impuls für künftige Projekte geben.
• Gerne als Workshop, auch als Event.
• Es geht ums Lernen, nicht um Schuldzuweisung.
• Welche Fragen können wir uns bei Lessons Learned stellen?
  • Was hat gut geklappt, was hat funktioniert?
  • Was kann künftig verbessert werden?
  • Welche Probleme hätten vermieden werden können? (Gibt Ideen fürs Risikomanagement?)
  • Welche Probleme haben wir vermieden? (Auch: wo war Risikomanagement erfolgreich?)

---

Reflektionsfragen

• Wie halten Sie es mit dem „Blick zurück“
• Wann sollte denn am Besten von diesen Erkenntnissen wieder Gebrauch gemacht werden?
• Tun Sie das?
• Ist Ihr Lessons-Learned frei von Schuldzuweisungen?
• Ein echter Verbesserungsturbo?

---

Zum Weiterlesen

ProcessGroupsPracticeGuide (PGPG), Prozess 6.2 – Manage Project Knowledge und 8.1 – Close Project or Phase

---

Copyright Gita GmbH. Alle Rechte vorbehalten.

Um was geht’s?

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

ProcessGroupsPracticeGuide (PGPG), Prozess 6.1 – Direct and Manage Project Work sowie Prozess 6.2 – Manage Project Knowledge

---

Copyright Gita GmbH. Alle Rechte vorbehalten.

Um was geht’s?

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?

---

Zum Weiterlesen

ProcessGroupsPracticeGuide (PGPG), Prozess 5.1 – Develop Project Management Plan

---

Copyright Gita GmbH. Alle Rechte vorbehalten.

Um was geht’s?

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

ProcessGroupsPracticeGuide (PGPG), Kapitel 4 sowie Prozess 4.1 – Develop Project Charter

---

Copyright Gita GmbH. Alle Rechte vorbehalten.

Um was geht’s?

Nachfolgend eine Übersicht von gängigen Begriffen rund um Risikomanagement. In Deutsch und in Englisch.

Reflektionsfragen

• Können Sie jeden der unten stehenden Begriffe zuordnen?
• Gibt es einen Begriff, den Sie noch nie gehört haben?

Manage Communications	Kommunikation managen
Plan Communications Management	Kommunikationsmanagement planen
Project Communications Management	Kommunikationsmanagement in Projekten
Communication Management Plan	Kommunikationsmanagementplan
Communication Methods	Kommunikationsmethoden
Communication Models	Kommunikationsmodelle
Communication Requirements Analysis	Analyse der Kommunikationsanforderungen
Communication Technology	Kommunikationstechnologie
Monitor Communications	Kommunikation überwachen
Communication Constraints	Kommunikationsbeschränkungen
Information Management Systems	Informationsmanagementsysteme

---

Copyright Gita GmbH. Alle Rechte vorbehalten.

Um was geht’s?

Wir gehen nochmals auf den Begriff Stakeholder ein und führen unsere ersten Prozessschritte durch: Die Stakeholder-Identifikation und -Analyse.

---

---

Kurze Erinnerungshilfe

• Welche Erwartungen haben die Stakeholder an mich? (Nicht ich an die Stakeholder.)
  • Empathischer Perspektivenwechsel: Wenn ich einer meiner Stakeholder wäre, was würde ich dann erwarten?
• Wie kann ich das Engagement der Stakeholder beeinflussen?
  • Wo hätte ich den Stakeholder gerne? Wie kann ich meine Stakeholder dazu bringen, mich zu unterstützen?
  • Welche Stakeholder könnten Einfluss auf mein Projekt nehmen?
• Wie kann ich den Stakeholder verorten? Z.B. Macht/Einfluss-Diagramm als „Landkarte“.

---

Kommen wir jetzt zur ersten Aufgabe dieses Prozesses:

---

Kurze Erinnerungshilfe

• Ähnlich aufgebaut wie das Risikoregister.
• Übliche Punkte im Register sind:
  • Stakeholder
  • die Stakeholderwartungen
  • Power/Interest der Stakeholder und
  • ihre aktuelle Haltung
• Power/Interest wird qualifiziert.
• Wie mit der Haltung verfahren wird, ist eine Fallentscheidung.
• Stakeholder werden häufig in Gruppen zusammengefasst (Alle Nachbarn, die Mitarbeiter, die für die Verschmelzung sind, …)
• Erwartungsgruppierungen zu bilden ist die hohe Kunst der Stakeholderanalyse.

---

Sind alle Stakeholder bekannt, müssen sie auch noch klassifiziert werden. Darum geht es jetzt um die

---

Kurze Erinnerungshilfe

• Erstellen einer Stakeholderlandkarte.
• Eingangsvoraussetzung: Übersicht der Stakeholder; die Interessenslage der jeweiligen Stakeholder ist bekannt.
• Auswahl geeigneter Dimensionen, z.B. Macht und Interesse.
• Achtung! Dimensionen immer in Bezug auf das Projekt sehen!
• Quadranten des Diagramms geben den ersten Hinweis auf die Strategie zum Umgang mit den dort definierten Stakeholdern.
• Achtung! Analyse nicht mit Aktion verwechseln!

---

Reflektionsfragen

• Wer kann alles Stakeholder sein?
• Mit welchen Methoden kann ich Stakeholder identifizieren und klassifizieren?
• In welchem Kontext werden die Stakeholder betrachtet?
• Bin ich selbst im Projekt mein eigener Stakeholder?

---

Zum Weiterlesen

ProcessGroupsPracticeGuide (PGPG), Prozess 4.2 – Identify Stakeholders

---

Copyright Gita GmbH. Alle Rechte vorbehalten.