Wie und wo gestaltet man einen Rollout in einem Hermes Projekt?

Projektmanagement für Profis – Ein Rollout einer Softwarelösung, welche zuvor in einem Projekt entwickelt wurde, stellt hohe Anforderungen an die Projektabwicklung. Man muss nicht nur die Entwicklungspartner, wie auch eine grössere Anzahl

Projekt-Software Rollouts mit Hermes
Projekt-Software Rollout in der Hermes Phase Einführung

Kunden managen. Wo man eine Mehrfacheinführung in ein Projekt nach Hermes einplant und umsetzt, ist ein kritischer Erfolgsfaktor für den Projekterfolg! Der Rollout kann auf verschiedene Art und Weise in aufgesetzt werden. Dieser Artikel beleuchtet die Vor- und Nachteile der jeweiligen Varianten.

Wie und wo gestaltet man einen Rollout in einem Hermes Projekt?

Wo genau in einem Projekt der Rollout vorgesehen und abgewickelt wird, hängt von der jeweiligen Projektkonstellation ab. Grundsätzlich erkenn

t der erfahrene Projektleiter aber vier verschiedene Möglichkeiten, die Mehrfacheinführung in einem Projekt anzusiedeln:

  1. Aufbau eines separaten Rollout Teilprojekts.
  2. Zwei Projekte: Zunächst Lösung entwickeln, danach ein Einführungsprojekt (Szenarien: IT-Standardanwendung oder IT-Infrastruktur)
  3. Einbau des Rollouts in der Phase ‘Realisierung’.
  4. Einbau des Rollouts in der Phase ‘Einführung’. (Die Varianten können kombiniert werden)

 

Rollout als Teilprojekt

Der Rollout wird als Teilprojekt mit einem Teilprojektleiter geführt. Da bei Phasenübergängen auch Aenderungen in der Projektorganisation erfolgen können, kann das Teilprojekt für den Rollout erst in der Realisierungsphase gebildet werden.

Vorteile:

  • Der Rollout ist direkt in der Projektlinie eingeordnet
  • Einfachere Kommunikation
  • Nähe zum Entwicklungsteam/projekt
  • Der Rollout  ist sicher auch als Projektziel vorhanden.
  • Finanzierung muss so frühzeitig sichergestellt sein

Nachteile:

  • Möglicher Zielkonflikt zwischen Entwicklungsziel und Rolloutzielen
  • Management der Finanzierung. Rollouts werden i.d.R. von den Kunden/Bezügern bezahlt
  • Weniger Aufmerksamkeit, da Rollout als ‘Anhängsel’ angesehen werden kann.
  • Das Entwicklungsprojekt kann vielen Stakeholdern ausgesetzt sein und so wird die Komplexität erhöht.
  • Längere Projektdauer

 

Rollout als eigenständiges, nachgelagertes Projekt führen

Vorteile:

  • Klar umrissenes Ziel
  • Weniger Beeinträchtigung des Entwicklungsprojekts
  • Vor dem Rolloutprojekt kann eine Stabilsierungsperiode eingefügt werden. Das Entwicklungsprojekt kann sauber abgeschlossen werden und die Lösung kann ‘stabilisiert’ werden
  • Das neue Projekt ermöglicht einen zielgerichten Wechsel der Ressourcen
  • Eine “Multi-Auftraggeber Finanzierung” ist einfacher zu bewerkstelligen, da die Kunden gleichberechtigter sind (der ‘grosse Sponsor der Entwicklung’ ist nicht mehr da)

Nachteile:

  • Durch zwei Projekte kann die ‘finanzielle Totalsicht’ leiden
  • Changes und Produkteänderungen können nicht im gleichen Projekt gefixt/entwickelt werden.
  • Mangelnde Finanzierung führt zu einem ‘Rohrkrepierer’ für den Rollout. Insbesondere dann, wenn das Rollout zentral finanziert wird und das vorgegangene Entwicklungsprojekt über den Kosten lag.
  • Gefahr der Verzettelung, da es ggf mehrere gleichwertige Kundenorganisationen gibt, welche den Rollout finanzieren.
  • Der Projektauftraggeber muss ‘stark’ sein, wenn er mit dem gleichen Rollout mehrere Kunden bedient.
  • Zeitlich zu spät nachgelagertes Rollout-Projekt führt ein Produkt ein, welches inzwischen veraltet ist.
  • Mehrere Offerten, mehrere Verträge, mehrere Vertragsverhandlungen.
  • Bei grösseren Vorhaben, welche öffentlich ausgeschrieben werden müssen kann das verkorkste Schweizer Beschaffungsrecht dazu führen, dass nicht der optimale Rolloutpartner (aus Optik der Lösung) den Zuschlag erhält.

Der Rollout in der Hermes Phase ‘Realisierung’

Vorteile:

  • Die Lösung kommt früh in Produktion (das ist sehr, sehr vorteilhaft und senkt häufig die Kosten*)
  • Agilität wird gefördert
  • Nähe zum Entwicklungsteam. Direktes Feedback an die Entwickler
  • Performance und Stabilität wird frühzeitig erprobt.
  • Es werden von Anfang an mehrere Software-Releases geplant

Nachteile:

  • Die Lösung ist ggf. noch nicht stabil genug und deswegen
  • patchen von bereits erfolgten Rollout-Lösungen (sofern die Lösung nicht zentral gehalten wird)
  • Die produktiven Infrastrukturen müssen frühzeitig in der Phase Realisierung abgenommen und aufgebaut werden
  • Durchlaufen von mindestens zwei Abnahmezyklen, einmal Abnahmezyklus für Beginn des Rollouts (Infrastruktur und V1 der Lösung) und einmal Abnahmezyklus bei Projektende (Finale Version der Lösung ) nach dem letzten getätigten Rollout.

* je früher eine Lösung produktiv genommen werden kann, umso eher spielen sich die produktiven Prozesse ein. Es passiert nach wie vor häufig, dass erst bei der produktiven Nutzung verdeckte Fehler erkannt werden. Wenn man das erst in der Einführungsphase merkt, dann kostet das idR. umso mehr. Weiter erfolgt die Produktivnahme häufig mit einem weniger komplexen Produkt (V1). Deswegen läuft die Produktivnahme einfacher ab und die Organisation wird ggf weniger überfordert, bzw. sie kann iterativ mit n-Releases lernen.

Der Rollout in der Hermes Phase ‘Einführung’

Vorteile:

  • Man realisiert zunächst fertig.
  • Es sind keine separaten Abnahmezyklen nötig, es reichen die ‘Gates’ bei Phasenwechsel .
  • Weitere Stakeholder können erst nach Phasenwechsel Einführung begrüsst werden. Die Gefahr, dass etwas ‘Umgebogen wird’ ist tiefer.
  • Die Finanzierung durch mehrere Parteien kann besser aufgeteilt werden. Zusätzliche Zahler kommen so erst in der Einführungsphase mit ins Projekt.
  • Man macht weniger miteinander, insbesondere bei kleineren Projekten (über)fordert man weder das Projektteam, noch die Linie

Nachteile:

  • Man realisiert zunächst fertig.
  • Lange Phasendauer
  • Performance Issues oder versteckte funktionale Fehler werden spät entdeckt, sofern vorhanden
  • Da Entwicklung abgeschlossen, können ggf Ressourcen für Fixes und Changes fehlen.

Lesen Sie den ausführlichen Beitrag: ‘Software Projekt Rollouts mit Hermes 5‘.

——-

Wie setzen Sie Ihren Rollout auf? Schreiben Sie mir doch einen Kommentar! Vielen Dank und liebe Grüsse, P. Stacho

 

 

Noch mehr Knowhow zu Hermes vom Geschäftsmann 2.0

Software Projekt Rollout mit der Projektmethode Hermes

Projektmanagement für Profis – Ein Rollout einer Softwarelösung, welcher zuvor mit einem Projekt entwickelt wurde stellt hohe Anforderungen an die Projektabwicklung, sind ja nicht nur die Entwicklungspartner, sondern auch eine grössere Anzahl Kunden involviert. Das Einpassen so eines Rollouts in die Projektmethode Hermes (und umgekehrt) ist ein kritischer Erfolgsfaktor für die Ausbreitung und schlussendlich für den Projekterfolg! Am Besten integriert man den Rollout mit einem separaten Prozess in der Hermes-Phase “Einführung”.

Projekt-Software Rollouts mit Hermes
Projekt-Software Rollouts mit Hermes

Definition Software Projekt Rollout

Ein Projekt Software Rollout – das Ausrollen – einer Software Projektlösung unterscheidet sich stark von der Distribution einer Standardsoftware oder gar von Hardwarekomponenten. Projekte für die letzteren zwei haben einen ‘klaren Verteilungscharakter’ und starten von Anfang an als Distributionsprojekte. Dieser Artikel behandelt nicht die letzteren zwei Arten von Vorhaben, sondern die Verbreitung einer selbst entwickelten oder eingekauften einer selbst adaptierten Lösung unter der Berücksichtigung der Projektmethode Hermes.

Kurz: Projektsoftware Rollouts sind Vorhaben, bei welchen die Lösung zunächst entwickelt wird und anschliessend mehreren Kunden zur Verfügung gestellt wird. Dabei ist es verhältnismässig egal ob es sich dabei um Individualsoftware handelt oder um die Adaption bestehender Software.

Hermes und Software Projekt Rollouts

Weder die Hermes Phasen noch die Hermes Module  kennen ein explizites Projekt-Element, welches den Software Rollout konkret beinhaltet. Es gibt das Standardzenario IT-Standardanwendung, darin sind die Verteilungsaktivitäten inhärent berücksichtigt.

Doch kein Projektauftraggeber, geschweige den ein Projektleiter wählt zu Beginn eines Softwareprojektes dieses Szenario, in diesem Moment ist der Entwicklungsfokus zu stark im Vordergrund.  Und ein Hermes Szenario Wechsel ist bei laufendem Projekt nicht vorgesehen und sowieso ein Unding. Wieso? Weil bei einem Wechsel von Projektabwicklungsszenarien geänderte Anforderungen vorliegen würden. Somit hätte das Projekt auch auch neue, von den ursprünglichen Zielen stark abweichende Projektziele!

Wie und wo gestaltet man einen Rollout in einem Hermes Projekt?

Grundsätzlich gibt es mehrere Lösungsmöglichkeiten

  1. Aufbau eines separaten Rollout Teilprojekts.
  2. Zwei Projekte: Zunächst Lösung entwickeln, danach ein Einführungsprojekt (Szenarien: IT-Standardanwendung oder IT-Infrastruktur) umsetzen.
  3. Einbau des Rollouts in der Phase ‘Realisierung’.
  4. Einbau des Rollouts in der Phase ‘Einführung’.

Wo nun genau der Rollout im Projekt geplant und durchgeführt wird, hängt von der jeweiligen Projektsituation ab. Jede Wahl hat Ihre Vor- und Nachteile, auf welche der Geschäftsmann 2.0 in einem späteren Beitrag eingehen wird. Dieser Beitrag dreht sich um die Umsetzung des Rollouts in der Einführungsphase.

 

Der Rollout im Detail

Der Rollout – auch Mehrfacheinführung genannt – sollte standartisiert erfolgen, aber nicht so starr, dass das Projekt nicht auf die Eigenschaften des Kunden eingehen kann. Das hier vorgestellte Template führt den Rollout in der Hermes-Einführungsphase durch. Dies hat den Vorteil, dass die produktiven Infrastrukturen abgenommen sind und bereits komplett zur Verfügung stehen. Man sollte aber unbedingt darauf achten, dass im ‘Mutter- oder Hauptprojekt’ Budgets für Entwicklungsleistungen vorgehalten werden, denn häufig bringen die Kundeneinführungen zusätzliche Erkenntnisse und Produktanforderungen zu Tage, welche in der Software dazuprogrammiert werden müssen. Natürlich müssen solche Leistungen über einen ordentlichen Change-Management (KM-Prozess) ins Projekt einfliessen, dazu gibt es im hier vorgestellten Rolloutmodell auch eine entsprechende, zentrale Rolle, welche sich genau um solche Sachen kümmert.

Projekt-Software-Rollout-Entscheide-MilestonesRollout Phasen und Module – Der Rollout selber hat auch Phasen und Module. In der Vorbereitungsphase wird der Kunde im Projekt begrüsst (onboarding). Anschliessend wird ein Scoping durchgeführt, quasi eine Analyse der Kundensituation. Die Vorbereitungsphase wird dann mit den Formalitäten (Verträge, Vereinbarungen, Termine) abgeschlossen.

Nach dem Entscheid zur Durchführung startet die eigentliche Rolloutphase. Hier fallen neben der Einführung der Lösung auch noch kleinere Anpassungen an. Diese können Kleinstentwicklungen sein oder die Integration von Drittanwendungen. Man sollte hier darauf achten, dass der Administrativaufwand für diese Tätigkeiten nicht überhand nimmt, aber trotzdem genügend dokumentiert ist, dass eine Betriebsabnahme und Betriebsübergabe erreicht wird. Abgeschlossen wird der Rollout durch die Freigaben und Betriebsübergaben.

Troubleshooting und Supervision sind das Öl im Rolloutgetriebe. Das Ziel ist es, diesen Prozess möglichst rasch und reibungsfrei zu durchlaufen, denn haben die Rollout-Teams eine einzelne Einführung hinter sich gebracht, wartet meistens schon die Nächste aufs Team. Verzögerungen können in so einem Setup zu Domino-Effekten führen und das Rolloutportfolio-Management und der Teilprojektleiter machen dann nichts anderes als laufend neu planen und kommunizieren unliebsame Verzugsmeldungen an ‘wartende’ Kunden. Zu diesem Zweck sollten unbedingt Ressourcen für das Troubleshooting eingesetzt werden, analog zum SCRUM-Master bei agilen Vorhaben (Siehe Hermes und SCRUM). Die Supervision beinhaltet das aktive Qualitätsmanagement, damit das Rollout-Team und die Rolloutkoordinatoren vom Qualitätsmanagement entlastet werden. Der Supervisor stellt die Qualität, die Abnahmen und die Qualitätsprüfungen aktiv sicher, er ist nicht nur ein Kontrolleur sondern er bringt selber auch Mehrwert.

Rolloutstrukturplan und Ablaufmodell als Vorlagen. Wie so etwas abläuft und geplant werden kann, sieht man am Besten in den in diesem Beitrag verfügbaren Powerpointpräsentation und dem Rolloutstrukturplan. Die Präsentation zu den Rollouts beinhaltet eine Übersicht, Informationen zur organisatorischen Eingliederung, Rollen im Rollout und Details zum Steckbrief.

Zum Aufzeigen des Ablaufs eines Rollouts dient der Rolloutstrukturplan (RSP). Der Geschäftsmann 2.0 hat ein entsprechendes Beispiel beigelegt. Dieses ist genau gleich wie der Projektstrukturplan Hermes aufgebaut, mit einer “Work Breakdown Structure” Gliederung. Die Abarbeitung des Rolloutstrukturplans wird am Besten auf einem ‘Steckbrief’ dokumentiert, welcher am Besten auf einer Wikiseite geführt wird.

Der Rollout und Tools – Taskmanagement

Die Produktivnahme des mehr oder weniger gleichen Produkts bei vielen Kunden ist klar repetitiv. Ist mal ein Template in einem Taskmanagementsystem wie Jira, Trello oder Asana angelegt, dann kann das institutionelle Projektmanagement stark vereinfacht werden. Der Wandel zu Projektmanagement 2.0 mit Hilfe solcher Tools ist heute (2016) übrigens in vollem Gange 😉 !

Braucht ein Rollout einen Projektleiter?

Ein einzelner Rollout sollte keinen Projektmanager benötigen, so etwas sollte auf Sachbearbeiter oder Projektmitarbeiter-Ebene durchführbar sein. Ob ein Projektmanager für mehrere Rollouts abgestellt werden sollte, das hängt von der Komplexität der einzuführenden Lösung und vorallem auch von den Ansprüchen der Kunden ab. Häufig wird die Arbeit rund um das Kundenmanagement unterschätzt.

Hingegen braucht ein  Rolloutprojekt oder Rolloutteilprojekt klar eine Führungskraft in der Funktion des Projektleiters.

Eine Spezialität: Der Rollout-Strukturplan und der Steckbrief

Auf diese Projektdokumente wurde bereits oben hingewiesen, hier noch einmal: Der Rolloutstrukturplan, auch RSP genannt, ist der Modellablauf eines Rollouts, welcher ja n-mal bei n-Kunden durchgeführt wird. Auf diesem Rolloutplan basiert der Steckbrief. Die Anlehnung eines Steckbriefs an ein Kanban ist dabei durchaus Absicht. Damit kann der Rolloutmanager oder Rolloutkoordinator auf einen Blick erkennen, wo der Rollout sich im Prozess befindet. Andererseits sind alle benötigten Informationen zum Rollout x auf ‘einem Blatt’, somit kann die Abwicklungsgeschwindigkeit beschleunigt und der Prozess erheblich vereinfacht werden. Der Steckbrief ist häufig eine Wikiseite. Alternativ können Steckbriefe generisch entstehen, nämlich als ein Report im Taskmanagementsystem. Dieser Report beinhaltet dann einfach die Summe der abzuarbeitenden Tasks pro Rollout xyz.

Downloads: Powerpoint-Präsentation zu Rollouts / Rolloutstrukturplan im Excel Format

Der Geschäftsmann 2.0 wünscht viel Erfolg beim Ausrollen!

———

 

Noch mehr Knowhow zu Hermes vom Geschäftsmann 2.0

 

Noch Fragen zu Rollouts?

Wir haben konkrete Erfahrungen zur erfolgreichen Abwicklung von Rollouts, sollten noch Fragen bestehen, dann beantwortet der Geschäftsmann 2.0 diese gerne!

Ihr Name (Pflichtfeld)

Ihre E-Mail-Adresse (Pflichtfeld)

Betreff

Ihre Nachricht

 

So Long, Euer Geschäftsmann 2.0 Palo Stacho

Der Hermes 5 Projektmanagementplan auf einen Blick (H5-PMP)

Dieser Blogpost ist für Projekt-Profis relevant:

Der PMP in Hermes 5 vereint die frühere Hermes Dokumente PHB/PPL, hier die Kapitelgliederung auf einen Blick:

  1. Projektbeschreibung
  2. Szenario mit Phasen und Meilensteinen
  3. Organisation
  4. Projektergebnisstrukturplan
  5. Szenario (inkl. P-Strukt.plan, P-Phasen, Rollen, Ergebnisse, Abhängigkeiten)
  6. Prüfplan
  7. Terminplan
  8. Kostenplan
  9. Ressourcenplan
  10. Beschaffungsplan
  11. Kommunikation (Berichtswesen, Reporting, Kommunikationsplanung)
  12. Vorgaben, Methoden und Werkzeuge
  13. Anhang
    • Qualitätssicherung
    • Risikomanagement
    • Dokumentenmanagement
    • Dokumentenablage
    • Namenskonventionen
    • Versionen von Dokumenten

Interesse bei Supervision und Coaching von Projekten? Just contact me here.

Mehr zu Hermes 5 

SCRUM prüfen für Vorgesetzte – 10 Checkfragen für agile Projekte (Auch für Hermes 5 Projekte)

Als Abschluss zum Thema Projektmanagement hat der Geschäftsmann 2.0 mal den Kopf schräg gehalten und hat sich überlegt, womit bzw. wie man als Sponsor / Führungskraft / Projektauftraggeber ein agiles Projekt checken oder kontrollieren könnte. Dabei ist Ihm folgendes eingefallen (ohne Anspruch auf Vollständigkeit):

  1. Das Produkt hat keine Soll- / Nice-to-have Features sondern nur Must-Funktionalität (Fehlende Streichkandidaten)
  2. Eine schwache oder fehlende Definition of Done
  3. Fehlendes Burndown-Chart
  4. Das Resultat des Sprints sind Produkte ohne Mehrwert für das Business (‚Wir bauen noch an der Infrastruktur‘)
  5. Ablieferung von nicht ausführbaren/exekutierbaren Artefakten (Programme, welche im CI eingecheckt sind, funktionieren nicht ohne Weiteres – Checkfrage: Zeig doch mal am Bildschirm, was du heute/zuletzt eingecchekt hast)
  6. Der Produktowner wurde im aktuellen Sprint noch nicht gesehen
  7. Die funktionale Beschreibung der Soll – Lösung ist zu grob (Alle User Stories sind immer noch Epics)
  8. Im SCRUM-Team findet man niemand, welcher testet und dies teamintern abnimmt
  9. Das Daily-Scrum (Daily stand up) Meeting findet lediglich unregelmässig statt oder es sind nicht alle Team-Mitglieder zugegen.
  10. Die Sprints dauern immer verschieden lange (Wie will man so die Sprint-Velocity vorhersagen können?) und man kann Ihnen kein Protokoll der Sprint-Retrospektive vorlegen.
  11. Was habe ich sonst noch vergessen? Sagt es mir (aus Optik Führungskraft/Sponsor) – Der Geschäftsmann 2.0 freut sich auf Euer Feedback!

Mehr Lesenswertes vom Gmann 2.0 zu Hermes 5 

Wehr mehr über Fehler bei Scrumprojekten erfahren möchte siehe hier

Gefährdet Hermes 5 die öffentliche Hand auf Ihrem Weg zur Verwaltung 2.0?

In der Verwaltung  funktioniert SCRUM nicht Palo, zumindest nicht für ganze Projekte. Ich hatte letzthin ein ‘agiles’ Vorhaben zu verantworten, bei welchem aus einem Dutzend geplanten Sprints über 40 wurden!“ (Zitat einer Führungskraft im öffentlichen Dienst)*

So etwas ist in der Tat ein Albtraum  – die Ohnmacht des Managers, die Hilflosigkeit und die ständige Frage „Hört denn das nie auf, dieses Projekt?“  gehören sicher zu den Kehrseiten des Managerlebens, über welche die Presse in der Regel nicht so viel zu schreiben weiss. Klar –  als Journalist ist man bei Verrichtung seiner Tätigkeit eine Einzelmaske und dazu noch vogelfrei, da liegt es auf der Hand, wenn man nichts von Führungsverantwortung kennt und dazu nichts zu schreiben weiss.

Doch zurück zur Sache: Das Zitat am Anfang des Textes widerspiegelt die Befürchtungen vieler, wenn gar nicht der meisten Vorgesetzten, welche mit der Entscheidung konfrontiert sind, ob diese ein Projekt mit agilen Methoden (allem voran mit SCRUM) oder mit „klassischem“ Projektmanagement durchführen wollen.  Diejenigen Organisationen -insbesondere die Verwaltungseinheiten des Bundes und der Kantone – welche das Projektmanagementmodell Hermes 5 anwenden, müssen sich diese Frage gar nicht stellen, denn in H5 ist Scrum / Agile Methoden lediglich in der Realisierungsphase vorgesehen – Leider.

„Schnell was machen und dann am Markt austesten“ – das gibt es bei H5 nicht. Und der Geschäftsmann 2.0 bedauert das zutiefst. Warum? Weil „lean“ & „agile“ zwei elementare Eigenschaften der digitalen Revolution und des Social Business sind. Darum! Und dieses Blog dreht sich ja hauptsächlich um die ZwoNull (2.0).  Klar, Hermes 5 ist „leaner“ geworden, das ist unbestritten.  Und es gibt Projekte, welche sich nicht für eine schlanke Abwicklung eignen, auch das ist klar. Auch wird die öffentliche Hand mit der Anwendung von agilen Projektabwicklungsmodellen nicht plötzlich eine „Agile Verwaltung 2.0“. Dafür braucht es schon mehr.

Nichts desto trotz wird in der Wirtschaft in den nächsten Jahren oder gar Jahrzehnten „Lean“ das Schlagwort sein und bleiben. Die Harvard Business Review (HBR) nannte letzthin, das Lean Startup Modell als „A New Strategy for the 21st Century Corporation“. Der Geschäftsmann 2.0 sieht das genau so und nicht erst seit er dieses Zitat in der HBR gelesen hat. Und er wünscht sich als Bürger, dass ebenfalls die öffentliche Hand agiler wird.

Langer Rede kurzer Sinn: Auf die Veränderungsprozesse bei der öffentlichen Hand hat Hermes 5 und Ihre fehlende Möglichkeit, ganze Projekte nach agilem Vorbild umzusetzen, wenig Impact. Da haben Communities, welche öffentlich Druck machen viel mehr Kraft! – Trotzdem hätte der Geschäftsmann 2.0 Freude, wenn man auch bei der Verwaltung “Schnell etwas machen könnte” 😉

Mehr Lesenswertes vom Gmann 2.0 zu Hermes 5 

So Long, Euer Geschäftsmann 2.0

*Anmerkung zu den “40 Sprints”: Der Geschäftsmann wartet noch auf die Diskussion mit dieser Führungskraft um zu erklären, dass wohl in diesem Fall der Fehler mit grösster Wahrscheinlichkeit nicht bei der Agilen Methode lag sondern wie so oft bei Projekten der Öffentlichen Hand seinen Ursprung viel früher hatte. Zwei Stichwörter: Ungenügende Businessanalyse oder mangelhaftes Pflichtenheft bei Vergabe (Das reicht jetzt aber, wenn schon widmet der Geschäftsmann 2.0 diesem Thema einen Post)

Hermes 5 hat viele Neuerungen, welche ist die Beste? – Der Projektinitialisierungsauftrag!

Dieser Blogpost ist für Projekt-Profis relevant:
h5-dokument_des_jahres

 

Der Geschäftsmann 2.0 hat sich mal Gedanken dazu gemacht, welches nun die ‚beste Neuerung‘ an Hermes 5 ist. Da brauchte er nicht lange zu überlegen: Für Ihn ist es der  Projektinitialisierungsauftrag (Liste der Vorlagen hier). Der Inhalt an sich ist nichts Neues, im Dokument sind die Ausgangslage, Ziele, Rahmenbedingungen und Sachmittel zu beschreiben.

hermes5_resultate_projektinitialisierungsauftragWeiter sind die Lieferobjekte der Projektinitialisierung drin zu terminieren (Liste der Stakeholder, Studie, Rechtsgrundlagenanalyse, Schutzbedarfsanalyse, Entscheid zur Variantenwahl inkl Checkliste, Projektmanagementplan, Projektauftrag , Entscheid Projektauftrag inkl Checkliste Projektfreigabe).

Doch warum findet der Geschäftsmann, dass dies DIE Neuerung im H5 ist? Weil dadurch das Projekt in zwei Teilvorhaben (wenn nicht noch mehr) unterteilt wird und so dem Auftraggeber eine echte „Sollbruchstelle“ geboten wird, ein Projekt frühzeitig zu beenden:

Haben Sie den Mut, ein Projekt abzubrechen! – Sie wissen meistens früh, ob’s gut kommt oder nicht…. …deswegen.

 

So Long, Euer Geschäftsmann 2.0

Mehr zu Hermes 5 

Verwenden von Hermes 5 Standardszenarien – Arbeiten mit Hermes-Online am Beispiel eines agilen IT-Entwicklungsprojekts (Teil 7)

Die Verwendung von Hermes-Online und deren vorhandenen Standardszenarien anhand des Beispiels des Szenario “IT-Entwicklung agil”.  Dieser Beitrag befasst sich mit der Webplattform www.hermes.admin.ch und ist vorallem für Projektmanagementprofis und Hermes-Spezialisten und -Interessierte gedacht.

Und tschüss... ...PC Programm Hermes Poweruser wird nicht mehr unterstützt
Und Tschüss… …PC Programm Hermes Poweruser wird nicht mehr unterstützt

Der Geschäftsmann 2.0 hat sich mal die Funktionalität und die Anpassbarkeit von Hermes online angeschaut. Denn das alte “Hermes – Poweruser”, welches man früher auf dem PC installiert hat, wird wohl nicht mehr unterstützt. Deswegen hat der Gmann sich mal so ein Testprojekt für sich angelegt. Für diejenigen, welche die Zeit nicht haben, so etwas durchzuspielen hat der Geschäftsmann nachfolgend die wichtigsten Printscreens beim Anlegen so eines Beispielprojektes eingebettet.

 

Erster Schritt: Auf Hermes Online entsprechendes Szenario auswählen:
http://www.hermes.admin.ch/anwenderloesung/szenarien-overview.xhtml

Hermes Online Rubrik "Anwenden" - Wir probieren mal "IT-Entwicklung Agil" aus. Siehe folgende Printscreens
Hermes Online Rubrik “Anwenden” – Wir probieren mal “IT-Entwicklung Agil” aus. Siehe folgende Printscreens

 

Optionaler Folgeschritt: Szenario anpassen
Hier kann man das Projekt vor dem Download “Customizen” oder personalisieren. Einerseits kann man Projektdaten eingeben, welche dann in allen Dokumenten und Vorlagen bereits eingebettet sind und zusätzliche, sogar eigene Elemente hinzufügen.

Wenn man vorgängig bei den Szenarien  den Button "Szenario anpassen" geklickt hat, kann man das Projekt Customizen
Wenn man vorgängig bei den Szenarien den Button “Szenario anpassen” geklickt hat, kann man das Projekt Customizen

Printscreen Unten: Elementeauswahl (Nur verfügbar wenn “Szenario anpassen” gewählt wurde.

Folgeschritt bei der "Szenario-Anpassung": Auswahl der Standardelemente des Szenario. Auf dem Folgebildschirm kann man sogar noch eigene Elemente ins Szenario einbinden (kein Printscreen).
Folgeschritt bei der “Szenario-Anpassung”: Auswahl der Standardelemente des Szenario. Auf dem Folgebildschirm kann man sogar noch eigene Elemente ins Szenario einbinden (kein Printscreen).

 

Folgeschritt: Sprach und Bestandteileauswahl vor dem Download

Vor dem Download des Standardszenario: Sprach- und Bestandteileauswahl
Vor dem Download des Standardszenario: Sprach- und Bestandteileauswahl

 

Am Schluss wird das Zip-File generiert (Printscreen unten). Dieses kann nach wenigen Sekunden im Browser runtergeladen werden. Die Grösse variiert zwischen 2-4 Megabytes und beinhaltet alle nötigen Dokumnente und Vorlagen.

Vor dem Download des Standard Szenario Hermes 5: Das Zip-File wird generiert
Vor dem Download des Standard Szenario Hermes 5: Das Zip-File wird generiert

 

Nach dem Download: Struktur des Hermes 5 Zipfiles (Printscreen unten) mit dem Standard-Szenario. Der Inhalt des Zip-Files mit Hunderten von Files und Vorlagen und Guidelines, welche nach dem Download extrahiert werden müssen und in ein separates Verzeichnis abgelegt werden können. Da der Extrakt mit einem index.html File daher kommt, lassen sich die Dokumente auch auf einem Web-Server ablegen!

Struktur des downgeloadeten Hermes-Zipfiles: Beachte start_de.html - Alle Inhalte können gebrowsed werden. Gut!
Struktur des downgeloadeten Hermes-Zipfiles: Beachte start_de.html – Alle Inhalte können gebrowsed werden. Gut!

 

Die persönliche Hermes 5 – Projekthomepage:
Bei Doppelklick auf das asu dem Zip-File entpackte index.html zeigt die persönliche Projekthomepage. Hier die Hauptseite des Beispielprojektes des Geschäftsmannes 2.0 mit entsprechender Personalisierung. Beachte die Seitennavigation und die Elemente gegliedert nach Projektphase und Modul.

Im Browser aufgerufenes Index.html des extrahierten Hermes 5 Zip-Files
Im Browser aufgerufenes Index.html des extrahierten Hermes 5 Zip-Files
Modul Entwicklung Agil: Nicht gerade berauschende Anzahl von Aufgaben/Elementen. Phase Initialisierung ist leer.
Runtergescrollt: Der Teil IT-Entwicklung Agil dieses index.html: Nicht gerade berauschende Anzahl von Aufgaben/Elementen. Phase Initialisierung ist leer.

 

Die tiefste Ebene auf der persönlichen Hermes 5 Projekthomepage. Am Beispiel unten der Aufgabe “Sprints durchführen” wird die unterste Navigationsebene gezeigt. Hier sieht man die Aufgaben und die beteiligten Rollen / Aktivitäten / Beziehungen

Tiefste Navigationsstufe am Beispiel Detailaufgabe "Sprint durchführen"
Tiefste Navigationsstufe am Beispiel Detailaufgabe “Sprint durchführen”

 

Im Download mitgelieferte Vorlagen (Auszug). Im untenstehenden Printscreen sieht man die Vorlagen, welche nach dem Generieren im zip-File mitgeliefert wurden. Jede Vorlage kann man anklicken und dann steht das Dokument zum Editieren zur Verfügung. Weiter unten schauen wir uns kurz den Projektmanagementplan und das Dokument Prototypendokumentation an.

Auszug aus den mitgenerierten Vorlagen, welche nach dem Download des Hermes 5 Zip-Files zur Verfügung stehen.
Auszug aus den mitgenerierten Vorlagen, welche nach dem Download des Hermes 5 Zip-Files zur Verfügung stehen.

 

Vorlage Projektmanagementplan. Nachfolgend kurz ein Printscreen der Seite 1, des Inhaltsverzeichnisses und eines interessanten Teils des Dokuments, nämlich der Risiko-Matrix

Printscreen aus Vorlage  "PROJEKTMANAGEMENTPLAN"
Printscreen aus Vorlage “PROJEKTMANAGEMENTPLAN”
Inhaltsverzeichnis des neuen Hermes 5 Lieferobjektes - Projektmanagementplan
Inhaltsverzeichnis des neuen Hermes 5 Lieferobjektes – Projektmanagementplan
Auszug Projektmanagementplan Hermes 5: Risikomatrix
Auszug Projektmanagementplan Hermes 5: Risikomatrix

 

Vorlage Prototypendokumentation. Nachfolgend zu guter Letzt ein Printscreen des Dokuments “Prototypendokumentation”. Nur damit man ein zweites Dokument zum Vergleich hat:

Erste Seite Dokument Protoypendokumentation
Erste Seite Dokument Protoypendokumentation

Für ganz Gwundrige:

So das war’s. Im nächsten Beitrag geht es noch kurz um die Würdigung des Moduls.
So Long, Euer Geschäftsmann 2.0

Beitragsserie Hermes 5:

  1. Einleitung und Anlass
  2. Eine kurze Übersicht für PM-Profis und Hermes-Kenner
  3. Anstelle Tailoring: Szenarien und Module
  4. Die Unterschiede von Hermes 5 zu Hermes 2003 – Grobübersicht
  5. Hermes 5 und agile Softwareentwicklung (SCRUM) – Ein Lösungsansatz
  6. Wie geht es weiter mit Hermes 5 (Juni 2013)
  7. Verwenden von Hermes 5 Standardszenarien –  Beispiel eines agilen IT Projekts
  8. Kurzübersicht & Würdigung Hermes 5 Standardszenario “IT Entwicklung Agil”

Hermes 5 – Wie geht es weiter? – Werden Projekte damit nun besser? (Teil 6)

Werden Projekte, welche mit Hermes 5 abgewickelt werden, erfolgreicher? Das ist schon möglich. Denn Hermes 5 ist eine evolutionäre und gute Weiterentwicklung von Hermes 2003. Und es gibt ein breiteres und professioneller aufgebautes Schulungsangebot. Und die Anwenderseite / Stammorganisation wird bei Hermes vermehrt in die Pflicht genommen, das ist sehr gut so! (Hier hat es aber ein rieesen ABER, siehe ganz unten)

Nun, wie weiter? Die heute noch fehlende Community wird sicher weiter aufgebaut. Die Plattform Hermes-Online wird in Zukunft sicher noch komplettiert. Es empfiehlt sich, an Kursen wieder die Schulbank zu drücken und ganz stark Interessierte können auch am Nationalen Hermes-Symposium in Bern teilnehmen….

… und man kann im Internet weiterstöbern: Nützliche Links / Ressourcen:

Grundlagenkurs: http://www.sml.zhaw.ch/de/management/zso/weiterbildung/weiterbildungskurse-wbk/hermes-kurse-uebersicht/hermes-5-grundlagen-und-zertifizierung-foundation.html

Schulung ZHAW zur Verwendung von Hermes in „Nicht IT-Projekten“: http://www.sml.zhaw.ch/de/management/zso/weiterbildung/weiterbildungskurse-wbk/hermes-kurse-uebersicht/hermes-5-anwendung-in-nicht-it-projekten.html

Schulung ZHAW Hermes-Vertiefungskurse http://www.sml.zhaw.ch/de/management/zso/weiterbildung/weiterbildungskurse-wbk/hermes-kurse-uebersicht/hermes-5-vertiefungskurse.html

Agiles Hermes: Leider kann der Geschäftsmann 2.0 keine weitergehenden Links anbieten, es hat im Web aus seiner Sicht keine weitergehende Information mit befriedigender Qualität zu diesem Thema!

Zu guter Letzt kommt noch das ‚ABER‘: Der Geschäftsmann hat ja noch ein „aber“ gehabt oben bei der Frage, ob nun Projekte, welche mit Hermes 5 abgewickelt werden, besser werden: Firmen aus der Privatwirtschaft profitieren sicher stark von dieser verbesserten Version der Projektmanagement-Methode. Oeffentliche Verwaltungen, insbesondere die allgemeine Bundesverwaltung werden weiterhin mehr Mühe haben, mit externen Dienstleistern erfolgreiche Projekte zu machen. Doch das liegt nicht an der Projektmethode sondern an den Allgemeinen Geschäftsbedingungen des Bundes.  So wie diese AGBs aufgesetzt sind, sind sie nicht gesund für Projekte! Wieso? Weil man die

Alle Partner brauchen ausgeglichene Rechte & Pflichten. AGB BV verunmöglichen dies.
Alle Partner brauchen ausgeglichene Rechte & Pflichten. AGB BV verunmöglichen dies.

Seite des Bundes in den AGB zu stark „schützt“ und den Bund als Leistungsbezüger (Im Hermes Kontext ist das dann wohl häufig der „Anwender“ und/oder der „Betreiber“) viel zu wenig in die Pflicht nimmt. Erst wenn alle Projektpartner austarierte Rechte und Pflichten haben, erst dann hat der Projekterfolg eine saubere Basis. Und diese Basis ist bei Anwendung der AGB Bundesverwaltung nicht gegeben.

So, Long Euer Gmann 2.0

Beitragsserie Hermes 5:

  1. Einleitung und Anlass
  2. Eine kurze Übersicht für PM-Profis und Hermes-Kenner
  3. Anstelle Tailoring: Szenarien und Module
  4. Die Unterschiede von Hermes 5 zu Hermes 2003 – Grobübersicht
  5. Hermes 5 und agile Softwareentwicklung (SCRUM) – Ein Lösungsansatz
  6. Wie geht es weiter?

Hermes 5 und agile Softwareentwicklung (SCRUM) – Ein Lösungsansatz (Teil 5)

Projektmanagement und agile Softwareentwicklung – allem voran mit SCRUM – in einem Atemzug zusammen zu nennen, das tönt auf den ersten Blick nach dem Versuch der Quadratur des Kreises, sprich: Das geht eigentlich nicht. Wieso ist dem so?

Projektmanagement bedeutet Vorgaben, Termine, Budget, Fristen, von Oben nach Unten, der Projektleiter als Antreiber, ZackZack!

SCRUM hingegen bedeutet: Alle Macht dem IT-Entwicklungsteam. Das Team kann dem Product-Owner erst nach einigen Sprints sagen, wann und mit welchem Aufwand das Produkt voraussichtlich fertig wird. Es gibt keinen IT-Projektleiter, da ist “nur” der Product-Owner quasi als mitbeteiligter Auftraggeber. Da ist das Team, welches so zusammengesetzt ist, dass es in der Lage ist, selbstständig das Produkt zur Serienreife zu bringen. Und da ist der Scrum-Master, welcher die Stolpersteine beseitigt und das Team auf gleicher Augenhöhe (nicht von oben herab) coachen tut. Die Schönheit und Genialität dieses Ansatzes offenbart sich einem erst auf den zweiten Blick: Aufgrund der kurzen Sprints, welche von Anfang bei Sprintende ein ausführbares Produkt liefern müssen (Auch wenn bei den ersten Sprints das lauffähige Produkt in einem absolut unbrauchbaren Zustand geliefert wird), kann der Auftraggeber bereits sehr früh darüber entscheiden, ob sich das Team auf dem richtigen Weg befindet. Und: Es gibt keinen Projektleiter, es ist das Team welches sagt, was es bis wann liefert. Somit gibt es keine “Von oben nach unten Direktive”, das Team commited sich quasi mit Haut und Haaren zu den versprochenen Lieferterminen und kann sich nicht mehr hinter dem PL verstecken und sagen: “Der Projektleiter hat uns unmöglich zu haltende Vorgaben gegeben”.

Somit könnte man schliessen, dass die Rolle des Projektleiters nicht mit dem Scrum-Team in Einklang zu bringen ist. Es ist wie Öl und Essig. So etwas bindet einfach nicht. Die Sache ist aber die Gleiche wie bei der Salatsauce: Ein Salat schmeckt nicht – nur mit Öl. Genau so wenig schmeckt er nur mit Essig! Was also tun?

Scrum & Projektmanagement – Es gibt eine Lösung dafür: Im Gespräch mit einem der Hermes Methoden Spezialisten, dem Bernhard Kruschitz von der BKI konnte der Geschäftsmann einen absolut machbaren Approach umreissen, um Projektmanagement und agile Softwareentwicklung vereinen zu können!

Also: Der Auftraggeber und der Gesamtprojektleiter / Programmleiter braucht auf der einen Seite irgendwelche Planungsgrössen, Anhaltspunkte und Finanz- / Zeitschätzungen zum Produkt. Das Scrum-Team hingegen braucht die Freiheit bei der Produkteerstellung und die Möglichkeit, sich selber – ohne Zwang von oben – zu den Terminen und Aufwänden committen zu können (Das Team legt sich den Zwang selber auf). Und damit beides erfüllt werden kann, a.verfügbare Planungsgrössen für die Oberleitung und b. das Commitment und die Freiheit des Scrum-Teams, macht man während der Initialisierungsphase eben eine “IT-Studie” (früher hat man das Prototyp genannt).

Bei dieser Studie (dies ist ein mit Hermes5 neu eingeführtes Deliverable in der Phase Initialisierung) wird der Kern des Entwicklerteams gebildet und man gibt dem Team zwei oder drei Sprints frei. Mit jedem Sprint wird die Qualität der Storypoints besser und am Ende von Sprint 2 oder Sprint 3 sollte man dann ein Product Backlog haben, welches nicht mehr mit so grossen Unsicherheiten behaftet sein sollte.

Reserven – Jetzt hat man eine Planungsgrösse, welche man mit guten Reserven ausgestattet in den Projektmanagementplan übernehmen kann und das agile Scrum-Team hat bereits zu Beginn der Realisierungsphase eine viel höhere Sicherheit beim entwickeln und schätzen!

Hier noch ein Wort an die Auftraggeber: Die besten Auftraggeber, welche der Geschäftsmann bei seinen ca. 50 Projekten hatte, waren diejenigen, welche beim Projekt finanzielle und zeitliche Reserven eingeplant hatten. Es ist nicht nötig, diese Reserven zu kommunizieren, aber es ist gut, diese zu haben.

Fazit: Eine Entwicklungsstudie am Ende der Initialisierungsphase kann nicht nur dazu dienen einen funktionalen Prototyen zu entwickeln, sondern die dabei anfallenden Schätzgrössen (welche eine bessere Planungssicherheit bei der Projektplanung ermöglichen) können auch den Einsatz von agilen Softwareentwicklungsmethoden wie Scrum während der Realisierungsphase (welcher nun ein definiertes Zeitfenster eingeräumt werden kann) ermöglichen.

Zu guter Letzt: SCRUM & Hermes 5

So stellt sich Hermes Agile Softwarentwicklung im Hermes-Kontext vor
So stellt sich Hermes Agile Softwarentwicklung im Hermes-Kontext vor Quelle: Hermes 5

Agiler SW-Entwicklung wird im Hermes 5 Referenzhandbuch ab Seite 161 ein eigenes Kapitel geschenkt. Dort ist ersichtlich, dass die Autoren es als nicht möglich erachten SCRUM für den ganzen Projektzyklus zu verwenden sondern nur für dein Teil, nämlich wenn Software entwickelt wird. Das ist durchaus ein legitimer Ansatz. Nur dann gibt es für die Zeit, wenn Software entwickelt wird zumindest im Umfeld der Entwicklung keinen Projektleiter, nur das sehen die Hermes-Autoren, sie können sich nicht vorstellen, dass es Projekte oder Teilprojekte ohne PL gibt. So ist es auch irgendwie verständlich, dass im Hermes 5 Referenzhandbuch an folgenden Stellen aus Optik des Gmanns 2.0 Schwächen aufweist:

S. 63 / S. 51 Bei “Entwicklung Agil” führt der Projektleiter das Product Backlog, und er führt das “Protokoll” bei Sprints. Ein PL hat an beiden Orten eigentlich nichts verloren.

S. 113 “Die Einführung von SCRUM hat einen klaren Start und ein klares Ende”. Ja, SCRUM hat auch ein klares Ende, aber SCRUM kennt keinen vorgängig bekannten, klaren Endtermin das sieht man erst nach Sprint 2 oder 3 wann man etwa fertig sein könnte (Nämlich dort wo das Burndownchart die 0 Linie kreuzt)

S. 113 bei Sprints durchführen heisst es im Absatz “Hermes Spezifisch”: Die Projektleitung überträgt dem SCRUM-Team die Verantwortung für die Durchführung eines Sprints“. Hier sollte es eher heissen: “Der Product-Owner (den es im Hermes ja so nicht gibt) überträgt dem SCRUM-Team die Verantwortung für die Erstellung des Produkts.

Beitragsserie Hermes 5:

  1. Einleitung und Anlass 
  2. Eine kurze Übersicht für PM-Profis und Hermes-Kenner
  3. Anstelle Tailoring: Szenarien und Module
  4. Die Unterschiede von Hermes 5 zu Hermes 2003 – Grobübersicht
  5. Hermes 5 und agile Softwareentwicklung (SCRUM) – Ein Lösungsansatz
  6. Wie geht es weiter?

Fragen dazu oder Lust auf Mehr?: Update 18.3.2014 Aufgrund der regen Nachfrage gibt es nun dedizierten Hermes-Bereich mit Erfahrungen und Tipps: http://geschaeftsmann20.com/projektmanagement Fragen beantwortet der Geschäftsmann gerne hier.

So Long, Euer Geschäftmann 2.0, welcher neben dem zertifizieren PL auch zertifizierter Scrum-Master und Scrum Product Owner ist….

Die Unterschiede von Hermes 5 zu Hermes 2003 – Grobübersicht (Teil 4)

Delta Hermes 2003 zu Hermes 5 – Dieser Artikel eignet sich nur für Hermes Profis. Hier werden die Unterschiede von Hermes 5 zu Hermes 2003 angeschaut. Die Angaben sind ohne Gewähr und repräsentieren lediglich die persönlichen Beobachtungen des Geschäftsmannes 2.0, welcher das Thema im Detail analysiert hat und als Projektleiter mit jahrelanger Hermes-Erfahrung (und Hermes-Zertifikat), die ‘alte’ Version auch noch kennt. Vorneweg: Der Gmann 2.0 meint, Hermes 5 ist gut! Besser als das ‘alte’ Hermes 2003.

  1. Man unterscheidet neu zwischen Stammorganisation und Projektorganisation
  2. Im Projekt soll nun der Betreiber von Anfang an mit dabei sein (Triumvirat Ersteller, Betreiber und Anwender)
  3. Die komplette Ergebnisorientierung der Methodik wurde mit dieser Version endlich geschafft
  4. Es gibt nicht mehr nur Hermes-Systementwicklung und Hermes-Systemadaptation sondern Szenarien: IT-Standardanwendung, IT-Individualanwendung, Dienstleistung/Produkt, Geschäftsorganisation und ein individuelles Szenario.
  5. Ganz wichtig: Szenarien bestehen aus Modulen, Module bestehen aus Aufgaben, Aufgaben beinhalten Ergebnisse.
  6. Es gibt neu auch ein Szenario “IT-Individualanwendung agil” – wobei dieses mit Vorsicht zu geniessen ist (Siehe folgenden Post dieser Blogserie). Man beachte aber trotzdem die Seiten 161ff – Kapitel Agiles PM mit HERMES und SCRUM
  7. Die Phase Voranalyse ist verschwunden
  8. Der Term Tailoring ist verschwunden, dafür gibt es neu die Module und im Speziellen das Kapitel “Planung” (Planungsanleitung S. 154)
  9. Es braucht nicht immer alle Module  (Die mit einem * braucht’s immer)
  10. Der Projektplan und das Projekthandbuch wurden im Projektmanagementplan zusammengefasst
  11. Dem Umstand, dass Projekte in ein Projektportfoliomanagement eingebettet sein können wird neu auch Rechnung getragen (S. 18 / S. 147ff) und hat mehr Gewicht (siehe Grafik)
  12. Es gibt ein neues Lieferobjekt Projekteskalationsprozess
  13. Beschaffung” ist nun auch ein Hermes-Lieferobjekt, Nein, Entschuldigung es ist sogar ein Modul! (Was man nicht sieht, ist ob die Beschaffung produktespezifisch oder produkteneutral durchgeführt werden kann/muss/darf)
  14. Es gibt neu ein Deliverable “Studie” während Initialisierungsphase – Was man früher in der Voranalyse machte, macht man jetzt in der Initialisierung mit der Studie
  15. Somit gibt es auch keinen “Bericht Voranalyse” mehr, das Ergebnis heisst neu “Studie”.
  16. Das Gleiche ist mit dem “Bericht Konzept” passiert, dieses Ergebnis gibt es Hermes 5 nicht mehr. Neu kommt dem wohl – zumindest im Szenario IT-Individualentwicklung – die Aufgabe “Systemkonzept erarbeiten” am nächsten. Die Resultate dieser Aufgabe sind “Situationsanalyse”, “Systemanforderungen”, “Detailstudie” und “Systemarchitektur”
  17. Der Projektauftrag ist jetzt nicht mehr eine Handlung, sondern ein Dokument
  18. Das ehemalige Submodell Projektmarketing ist verschwunden – Neu hat man Stakeholdermanagement und Kommunikation und das gibt dann auch neue Ergebnisse wie z.B eine
  19. Stakeholdermanagement-Liste
  20. Das ehemalige Submodell Riskmanagement ist neu ein Teil der Projekt-Governance (S. 143)
  21. Die Ergebnisse Systemanforderungen und die Systemarchitektur wurden nun zusammengefasst in “Systemkonzept erarbeiten” (Aufgabe)
  22. Die Phasen Initialisierung und Konzept haben die fast die gleichen Prüfkriterien und die gleichen Abbruchkriterien.
    • Prüfkriterien: Bei der Initialisierung prüft man ob man das Projekt starten soll
    • Prüfkriterien: Bei der Konzeptpahse prüfr man, ob man das Projekt realisieren soll
    • Abbruchkriterien: Bei beiden Phasen prüft man ob man abbrechen soll: “Mögliche Gründe für eine Beendigung sind Unwirtschaftlichkeit, zu hohe Risiken, fehelende Realisierbarkeit, fehlende Übereinstimmung mit den Zielen und Strategien der Organisation”
  23. ERST in der Phase Konzept sind die ungefähren Projektkosten bekannt! (s. 19)
  24. Viele neue Module anstelle einige wenige alte Submodelle. Die ehemaligen Submodelle
    • Konfigurationsmanagement
    • Risikomanagement
    • Qualitätssicherung
    • Projektmarketing

    sind nun alles Aufgaben im Modul Projektführung

  25. Wie gesagt sind Projektmarketing und Riskmanagement sind wieder in die Projektführung ‚zurückgewandert’ (S.30 Projektführung), es gibt aber klar die Rolle eines Qualitäts- und Risikomanagers (S. 67)
  26. Die Stammorganisation hat zwei neue Organisationseinheiten zu betreiben:
    • Kompetenzzentrum Projektmanagement, Synonym ist PMO (Projektmanagementoffice)
    • Controlling & Vorgabestellen (z.B eine Governance-Abteilung)
  27. Bei “Entwicklung Agil” führt der Projektleiter das Product Backlog, auch führt er “Protokoll” bei Sprints (Der Geschäftsmann 2.0 ist damit wirklich nicht einverstanden, das ist schlicht und einfach Nonsens. Es gibt keinen PL bei agiler Softwareentwicklung und wenn eine Hermes Rolle das Product Backlog führen müsste, dann wäre es wohl am ehesten die Rolle “Geschäftsprozessverantwortlicher” oder vielleicht noch der “Business Analyst” (Mehr zu “agil” im nächsten Beitrag “Hermes 5 und Agile SW-Entwicklung“).
  28. Konfigurationsmanagement heisst neu “Änderungsmanagement führen” (S. 77)
  29. Die ehemalige Konfigurationsidentifikation und der KM-Plan sind teilweise in das Dokument Änderungsstatusliste eingeflossen
  30. Es gibt eine Reihe neu benannter Konzepte: Produktkonzept, Betriebskonzept, Integrationskonzept, Einführungskonzept, Geschäftsorganisationskonzept, Migrationskonzept, Testkonzept, Systemkonzept
  31. Das Systemkonzept ist ein Merge von Systemarchitektur und Systemanforderungen (welche es aber auch immer noch als eigenständige Deliverables gibt)
  32. Das Referenzhandbuch H5 geht auch (eben schön im Sinne der Ergebnisorientierung) explizit auf Entscheide ein. Es wird beschrieben dass Entscheide zu treffen sind bei:
    • Entscheid zu SCRUM
    • Entscheid zu ISDS-Konzept
    • Entscheid zum Projektabschluss
    • Entscheid zum Zuschlag
    • Entscheid zur Abnahme der Migration
    • Entscheid zur Abnahme
    • Entscheid zur Ausschreibung
    • Entscheid zur Betriebsaufnahme
    • Entscheid zur Projektfreigabe
    • Entscheid zur Variantenwahl
    • Entscheid zur Vorabnahme
  33. Der Projektauftrag (ist neu ein Dokument und kein Vorgang) beinhaltet weite Teile der Kapitelstruktur des ehemaligen Dokuments Voranalyse.
  34. Es gibt auch neu einen Projektinitialisierungsuaftrag
  35. Das Projekthandbuch und der Projektplan sind neu in den Projektmanagementplan eingeflossen
  36. “Neue” Optiken sind ebenfalls in Hermes 5 eingeflossen
    1. Nachhaltigkeit (S. 149)
    2. Finanzielle Steuerung und Führung (S. 153)
    3. Release Management
    4. Vorgehen bei Programmen – Programm Management

 

h5-PTDC0001
Hermes 5 und Projektporfoliomanagment

Hä? Nicht verstanden – Einige Sachen hat der Geschäftsmann 2.0 im neuen Hermes 5 Referenzhandbuch nicht begriffen, nicht verstanden oder er meint diese seien falsch:

  • S. 83 Entscheid zu SCRUM treffen – nicht verstanden
  • S. 113 “Die Einführung von SCRUM hat einen klaren Start und ein klares Ende“. Nicht begriffen – Ja, klar hat SCRUM auch ein klares Ende, aber SCRUM kennt keinen klaren Endtermin, oder?
  • S. 113 bei Sprints durchführen heisst es im Absatz “Hermes Spezifisch”: Die Projektleitung überträgt dem SCRUM-Team die Verantwortung für die Durchführung eines Sprints” – nicht verstanden. Sollte es nicht eher heissen: “Der Product-Owner (den es im Hermes ja so nicht gibt) überträgt dem SCRUM-Team die Verantwortung für die Erstellung des Produkts? –> Man versteht, wieso das bei Hermes 5 so ist, denn ab S. 161 gibt es ein Spezialkapitel zu Hermes und SCRUM und dort sieht man, dass die Autoren es als nicht möglich erachten SCRUM für den ganzen Projektzyklus zu verwenden sondern nur für den Teil, wenn entwickelt wird.

Fazit: Einiges bleibt gleich, vieles ist neu und das meiste ist besser: Hermes 5 ist ein Gewinn!

Beitragsserie Hermes 5:

  1. Einleitung und Anlass
  2. Eine kurze Übersicht für PM-Profis und Hermes-Kenner
  3. Anstelle Tailoring: Szenarien und Module
  4. Die Unterschiede von Hermes 5 zu Hermes 2003 – Grobübersicht
  5. Hermes 5 und agile Softwareentwicklung (SCRUM) – Ein Lösungsansatz
  6. Wie geht es weiter?

Mehr zu Hermes 5: Update 18.3.2014 Aufgrund der regen Nachfrage gibt es nun einen Hermes-Bereich, mit Grundlagen, Erklärungen, Mindmaps, Lernhilfen und sogar mit echten Prüfungsfragen: http://geschaeftsmann20.com/projektmanagement

Hermes 5: Modulübersicht (Teil 3)

Ein Szenario DL/Produkt beinhaltet die obigen Hermes 5 Module
Ein Szenario DL/Produkt beinhaltet die obigen Hermes 5 Module. Quelle: Hermes 5

Es geht weiter mit der 6-teiligen Serie zur überarbeiteten Projektmanagmentmethodik Hermes 5. Kommen wir zur Strukturierung, wenn man ein dediziertes Projekt abwicklen will. Früher nannte man dieses Aufsetzen “Tailoring”. Dieses Tailoring ist verschwunden. Neu gibt es Szenarien:  IT-Standardanwendung, IT-Individualanwendung, IT-Agil, Dienstleistung/Produkt und ein Szenario für Organisationsprojekte. Dazu gibt es Module und die Aktivität Planung.

Folgende Module sind neu standardmässig in Hermes 5 verfügbar:

  1. Beschaffung (8tung erst in Phase Konzept, somit kennt man erst dann die Kosten)
  2. inführungsorganisation (8tung: Hier ist z.B die Systemabnahme drin)
  3. Entwicklung Agil
  4. Geschäftsorganisation
  5. IT-Betrieb
  6. IT-Migration
  7. IT-System
  8. Informationssicherheit und Datenschutz
  9. Produkt
  10. Projektführung
  11. Projektgrundlagen
  12. Projektsteuerung
  13. Testen

Planung eines Projektes: Wenn man das Szenario und die benötigten Module bestimmt hat, wird die Projekt Planung durchgeführt. Mit der Planung wird das Projekt an den spezifischen Kontext angepasst. Man generiert den PSP, passt diesen an und geht dann zum PMP über. Beschrieben ist dieses Vorgehen auf Seite 154 des Hermes Handbuchs und es ersetzt schlussendlich das früher bekannte Tailoring.

Delta Hermes 2003 vs Hermes-5: Im nächsten Beitrag folgen die offensichtlichsten Unterschiede von Hermes 5 zum ‘alten’ Hermes 2003, oder besuchen Sie die Projektmanagement – Subsite.

 

Beitragsserie Hermes 5:

  1. Einleitung und Anlass 
  2. Eine kurze Übersicht für PM-Profis und Hermes-Kenner
  3. Anstelle Tailoring: Szenarien und Module
  4. Die Unterschiede von Hermes 5 zu Hermes 2003 – Grobübersicht
  5. Hermes 5 und agile Softwareentwicklung (SCRUM) – Ein Lösungsansatz
  6. Wie geht es weiter?

Hermes 5: Eine kurze Übersicht für PM-Profis und Hermes-Kenner (Teil 2)

Hermes 1995, Hermes 2003 SE & SA und nun Hermes 5. Die Exemplare des GM2.0
Abgegriffen: Hermes 1995, H-2003 SE & SA und nun Hermes 5. Die Exemplare des GM2.0

Folgende Punkte von Hermes 5 sind dem Geschäftsmann 2.0 sofort ins Auge gestochen: Die Modularisierung fällt auf, es wird mit sogenannten Einsatz-Szenarien von Hermes gearbeitet: IT-Standardanwendung, IT-Individualanwendung, Dienstleistung/Produkt und ein Szenario für die Geschäftsorganisation (Organisationprojekte) ist ebenfalls vorhanden Im Gegenzug ist der Term „Tailoring“ aus dem Wortschatz verschwunden. Es ist geplant mit Social Media und mit Newsletter eine Community rund um Hermes aufzubauen, was eigentlich auch Sinn macht. Aktuell ist das aber noch nicht Realität, der Geschäftsmann hat weder auf LinkedIn, Xing, Twitter oder Facebook etwas Brauchbares finden können! Siehe letzter Beitrag dieser Serie (Nr. 6)

Das Phasenmodell besteht „nur“ noch aus den Phasen Initialisierung, Konzept, Realisierung und Einführung. Man hat versucht die Verbindlichkeit der Stakeholder zu steigern, deswegen werden die Betreiber von Anfang an im Projekt miteinbezogen und der Projektauftrag ist neu ein Dokument und nicht nur lediglich ein „Akt“ (Der gegebene Auftrag eben) So wie in den früheren Hermes-Versionen. Die aktivitätenlastigen, früheren Submodelle (PM, SE, QS, RM, Mktg) sind in den Hintergrund getreten und man fokussiert mehr auf Ergebnisse.

Weiter gefällt dem Geschäftsmann 2.0 ebenfalls die explizit erwähnte Unterscheidung zwischen der Stamm-Organisation und der Projektorganisation, auch wenn er gleichzeitig das vorallem bei der eidgenössischen Verwaltung bekannte LB- / LE- Modell nirgends wiedererkennen konnte. Auch findet er es gut, dass den Projektauftraggebern nahe gelegt wird, einen Hermes 5 Kurs zu besuchen 😉 . Weniger gut hingegen findet er, dass nun bei diversen Rollen eine „Hermes-Zertifizierung“ verlangt wird, das ist schlicht und einfach Geldmacherei!

Module: Im nächsten Beitrag wird die neue Aufteilung in Module beschrieben und später folgen dann die offensichtlichsten Unterschiede von Hermes 5 zum ‘alten’ Hermes 2003 betrachtet. Wer nicht warten will, der kann sich ja auch dieses Youtube-Video anschauen

Beitragsserie Hermes 5:

  1. Einleitung und Anlass (Dieser Beitrag)
  2. Eine kurze Übersicht für PM-Profis und Hermes-Kenner
  3. Anstelle Tailoring: Szenarien und Module
  4. Die Unterschiede von Hermes 5 zu Hermes 2003 – Grobübersicht
  5. Hermes 5 und agile Softwareentwicklung (SCRUM) – Ein Lösungsansatz
  6. Wie geht es weiter?