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