Was ist ein Meilenstein in HERMES?
Alle Meilensteine sind Ergebnisse, die im Projektverlauf die Entscheidungspunkte markieren. Jede Entscheidungsaufgabe endet mit einem Meilenstein; je nach Modul gibt es verschiedene Entscheide und damit verschiedene Meilensteine.[1] Ein Meilenstein ist also kein Kalenderdatum, sondern der dokumentierte Zustand «entschieden».
Die projektstrukturbezogenen Meilensteine entsprechen Quality Gates. Vor ihrer Erreichung wird über Ergebnisse und Vorgehen entschieden, die Einhaltung der Vorgaben geprüft und die Übereinstimmung mit den strategischen Zielen der Stammorganisation sichergestellt.[2] Damit ist HERMES verwandt mit Stage-Gate-Modellen, bleibt aber enger mit Rollen und Ergebnissen verknüpft.
- Liste Projektentscheide
- Zwei Dokumente, die während des ganzen Projekts geführt werden: die Liste Projektentscheide Steuerung für Entscheide der Steuerungsebene und die Liste Projektentscheide Führung für Entscheide der Führungsebene. Erfasst werden Entscheid, erreichter Meilenstein, zugrundeliegende Dokumente, Entscheidungsträger und Datum.
Die Meilensteine der Projektstruktur
Diese Meilensteine geben jedem HERMES-Projekt seine Struktur und liegen an den Übergängen der Phasen. Bei jeder Freigabe werden die Ressourcen — finanziell, personell, Infrastruktur — für die nächste Phase durch den Auftraggeber freigegeben.[1] Wer welche Freigabe verantwortet, ergibt sich aus dem Rollenmodell im Kapitel HERMES-Rollen.
| Meilenstein | Zeitpunkt | Ebene | Grundlage |
|---|---|---|---|
| Projektinitialisierungsfreigabe | Projektbeginn | Steuerung | Projektinitialisierungsauftrag, Checkliste |
| Durchführungsfreigabe | Ende Initialisierung | Steuerung — Stammorganisation und Auftraggeber | Durchführungsauftrag, Checkliste |
| Phasenfreigabe | Ende Konzept, Ende Realisierung (klassisch) | Steuerung | Phasenbericht, QS- und Risikobericht, Checkliste |
| Releasefreigabe (optional) | Pro Release (agil) | Steuerung | Releasebericht, QS- und Risikobericht, Checkliste |
| Phasenfreigabe Abschluss | Ende Einführung oder Umsetzung | Steuerung | QS- und Risikobericht, Checkliste |
| Projektabschluss | Ende Abschluss | Steuerung | Projektschlussbeurteilung, QS- und Risikobericht, Checkliste |
| Projektabbruch | Während der Lösungsentstehung | Steuerung | Checkliste, Projektschlussbeurteilung, Projekterfahrungen |
Der erste Meilenstein hat eine besondere Bedeutung: Mit dem Projektinitialisierungsauftrag und seiner Freigabe wird die Projektorganisation überhaupt erst in Kraft gesetzt; sie wird danach laufend angepasst, insbesondere mit dem Durchführungsauftrag, und spätestens mit dem Entscheid Projektabschluss aufgelöst.[5] Die Checklisten für diese Entscheide gehören zum Modul Projektsteuerung und stehen auf HERMES Online bereit. Flenio bietet aufbereitete Fassungen, etwa die Checkliste Phasenfreigabe, die Checkliste Releasefreigabe und die Checkliste Projektabbruch.
Modulspezifische Entscheide
Entlang der Phasen gibt es weitere Entscheide, die den Projektverlauf bestimmen. Sie variieren je nach Art des Vorhabens und gehören zu den fachlichen Modulen:[1]
| Entscheid | Modul | Ebene | Typischer Zeitpunkt |
|---|---|---|---|
| Weiteres Vorgehen | Projektgrundlagen | Führung | Initialisierung, nach der Studie |
| Produktkonzept | Produkt | Führung | Konzept bzw. Umsetzung |
| Lösungsarchitektur | IT-System | Führung | Konzept bzw. Umsetzung |
| ISDS-Konzept | ISDS | Führung | Konzept bzw. Umsetzung |
| Ausschreibung | Beschaffung | Steuerung | Konzept bzw. Umsetzung |
| Zuschlag | Beschaffung | Steuerung | Konzept bzw. Umsetzung |
| Vorabnahme | Einführungsorganisation | Führung | Realisierung bzw. pro Release |
| Abnahme Migration | IT-Migration | Führung | Einführung bzw. pro Release |
| Betriebsaufnahme | Einführungsorganisation | Steuerung | Einführung bzw. pro Release |
| Abnahme | Einführungsorganisation | Führung | Nach der Betriebsaufnahme |
Die Ebene ergibt sich daraus, in welcher Liste der Entscheid dokumentiert wird. Beschaffungsentscheide und die Betriebsaufnahme liegen bei der Steuerung, weil sie die Organisation nach aussen binden oder den Betrieb verändern.
Meilensteine klassisch und agil im Vergleich
Das Referenzhandbuch zeigt die Meilensteine am Beispiel eines IT-Entwicklungsprojekts in beiden Vorgehensweisen:[1]
Klassisch
- 1Projektinitialisierungsfreigabe, Weiteres Vorgehen, Durchführungsfreigabe
- 2Konzept: Lösungsarchitektur, ISDS-Konzept, Phasenfreigabe
- 3Realisierung: Vorabnahme, Phasenfreigabe
- 4Einführung: Abnahme Migration, Betriebsaufnahme, Abnahme, Phasenfreigabe Abschluss
- 5Abschluss: Projektabschluss
Agil
- 1Projektinitialisierungsfreigabe, Weiteres Vorgehen, Durchführungsfreigabe
- 2Umsetzung, pro Release: Lösungsarchitektur und ISDS-Konzept (bei Bedarf), Vorabnahme, Abnahme Migration, Betriebsaufnahme, Abnahme, optional Releasefreigabe
- 3Phasenfreigabe Abschluss
- 4Abschluss: Projektabschluss
Der Unterschied liegt weniger in den Entscheiden als in ihrer Wiederholung: Agil fallen Vorabnahme, Betriebsaufnahme und Abnahme pro Release an. Die Releasefreigabe gibt dem Auftraggeber zusätzlich die Möglichkeit, jeden Release explizit zu steuern — ob sie verlangt wird, wird bereits in der Initialisierung festgelegt und im Projektmanagementplan dokumentiert.[1]
Wann wird ein Projekt abgebrochen?
Der Entscheid Projektabbruch ist in jeder Phase der Lösungsentstehung vorgesehen. Das Referenzhandbuch nennt für die Phasenenden typische Gründe:[1]
- Fehlende Wirtschaftlichkeit
- Zu hohe Risiken
- Fehlende Realisierbarkeit
- Rechtliche oder politische Bedenken (am Ende der Initialisierung)
- Fehlende Übereinstimmung mit Zielen, Strategien und Prioritäten der Organisation
Auch ein Abbruch wird geordnet abgeschlossen: Projektschlussbeurteilung und Projekterfahrungen werden erstellt, damit die Stammorganisation aus dem Abbruch lernt. Am Ende der Realisierung gilt zusätzlich eine harte Regel: Sind die Einführungsrisiken nicht vertretbar, kann die Einführung nicht erfolgen.
Nachhaltigkeit und Reporting an den Meilensteinen
Beim Meilenstein Weiteres Vorgehen und bei weiteren Meilensteinen wird die Erreichung der Nachhaltigkeitsziele als Bewertungskriterium mitberücksichtigt. Das Reporting erfolgt über den ganzen Projektverlauf im Einklang mit den Vorgaben der Stammorganisation zu Inhalt und, soweit machbar, Frequenz.[1] Für die Freigabe-Meilensteine bedeutet das: Die Unterlagen sollten dieselben Kennzahlen zeigen, die die Stammorganisation auch im Portfolio verwendet.
Welche Checklisten gehören zu den Entscheiden?
Zu fast jedem Entscheid gehört in HERMES eine Checkliste. Sie macht transparent, was vor dem Meilenstein geprüft sein muss, und wird zusammen mit dem Entscheid dokumentiert. Laut Referenzhandbuch gibt es Checklisten zu diesen Entscheiden:[1]
| Modul | Checklisten |
|---|---|
| Projektsteuerung | Projektinitialisierungsfreigabe, Durchführungsfreigabe, Phasenfreigabe, Releasefreigabe, Phasenfreigabe Abschluss, Projektabschluss, Projektabbruch |
| Projektgrundlagen | Weiteres Vorgehen |
| Beschaffung | Ausschreibung, Zuschlag |
| Produkt | Produktkonzept |
| IT-System | Lösungsarchitektur |
| ISDS | ISDS-Konzept |
| Einführungsorganisation | Vorabnahme, Abnahme, Betriebsaufnahme |
| IT-Migration | Abnahme Migration |
Die Checklisten sind kein Selbstzweck. Sie sind das gemeinsame Verständnis darüber, wann ein Entscheid reif ist — und damit eine wirksame Absicherung gegen Freigaben auf unvollständiger Grundlage. Wer sie zu Beginn der Phase mit dem Auftraggeber durchgeht, weiss, worauf es am Ende ankommt.
Meilensteine in Programmen
Ist ein Projekt Teil eines Programms, kommen die Meilensteine des Programms hinzu. Das HERMES-Programmphasenmodell kennt die Phasen Programminitialisierung, Programmdurchführung und Programmabschluss mit eigenen Meilensteinen wie dem Programminitialisierungsauftrag, der Programmdurchführungsfreigabe, Phasenfreigaben und dem Programmabschluss.[4] Die Projekte darin behalten ihre eigenen Meilensteine; jedes Projekt bleibt aus Sicht der Controlling- und Vorgabestellen ein eigenständiges Controllingobjekt.
Für die Planung heisst das: Projekt- und Programm-Meilensteine müssen aufeinander abgestimmt sein. Die Phase Programmabschluss kann erst freigegeben werden, wenn alle Projekte abgeschlossen sind.[5] Ein verzögertes Projekt verzögert damit das ganze Programm — ein Grund mehr, Projektfreigaben früh zu terminieren.
Meilensteine lernen und prüfen
Meilensteine sind ein Kernthema jeder HERMES-Ausbildung. Die Foundation-Lernziele der Bundeskanzlei verlangen etwa, die phasen- und releasespezifischen Meilensteine eines ganzen Projekts im Szenario Dienstleistung/Produkt Entwicklung erklären zu können.[3] Wer die Freigabelogik verstanden hat, versteht HERMES: Das Projekt läuft nicht von Termin zu Termin, sondern von Entscheid zu Entscheid. Einen Überblick über alle Methodenelemente bietet der HERMES-Leitfaden.
Typische Fehler bei Freigaben
Freigaben verlieren ihre Wirkung, wenn sie zur Formalität werden. Diese Muster tauchen in HERMES-Projekten immer wieder auf und lassen sich mit wenig Aufwand vermeiden:
- Die Freigabe wird mit einer Statusinformation verwechselt: Der Auftraggeber nimmt Kenntnis, entscheidet aber nicht ausdrücklich über Fortsetzung und Ressourcen.
- Der Entscheid fällt auf unvollständiger Grundlage, weil Phasenbericht oder QS- und Risikobericht erst kurz vor der Sitzung verteilt werden.
- Entscheide werden in Sitzungsprotokollen versteckt statt in der Liste der Projektentscheide geführt — später ist nicht mehr nachvollziehbar, wer was auf welcher Grundlage entschieden hat.
- Die Releasefreigabe ist im Projektmanagementplan vorgesehen, aber im Releaseplan nicht terminiert.
- Auflagen aus einer Freigabe werden nicht als Aufgaben erfasst und bleiben bis zum nächsten Gate liegen.
Der gemeinsame Nenner: Ein Meilenstein ist erst erreicht, wenn der Entscheid dokumentiert ist und seine Folgen — Ressourcen, Auflagen, Termine — im Projekt angekommen sind. Wer das konsequent umsetzt, braucht weniger Eskalationen und hat bei jeder Revision eine lückenlose Spur.
Eine Phasenfreigabe gut vorbereiten
Freigaben scheitern selten am Inhalt, häufiger an der Vorbereitung. Eine Freigabeunterlage sollte fünf Fragen beantworten, bevor sie dem Auftraggeber vorgelegt wird:
- 1Sind die Ergebnisse der Phase vollständig und von den verantwortlichen Rollen abgenommen?
- 2Stimmen Ziele, Kosten und Termine noch mit dem Durchführungsauftrag überein — und wenn nicht, liegt ein Änderungsantrag vor?
- 3Wie beurteilt das Qualitäts- und Risikomanagement den Stand, und welche Massnahmen empfiehlt es?
- 4Welche Ressourcen werden für die nächste Phase beantragt, und sind die Schlüsselpersonen verfügbar?
- 5Gibt es Gründe, die eine Fortsetzung in Frage stellen, und sind sie transparent dargestellt?
In Flenio lassen sich Gates als eigene Meilensteine in der Timeline führen und nachfolgende Aufgaben mit Abhängigkeiten daran binden; so wird sichtbar, was eine verschobene Freigabe auslöst. Den Rahmen für die Dokumentation bildet die Liste Projektentscheide Steuerung.