Das Framework für die digitale Transformation von objectiF RPM – Teil 6: Planung

Alle guten Dinge sind 3; multipliziert mit 2 erhalten Sie 6. Super, wir können alle trotz Hitzewelle rechnen! Willkommen also zum 6. und letzten Teil der Blog-Reihe mit dem Thema: Digitale Transformation, für die objectiF RPM ein spezielles Framework inkl. eines ausführlichen Beispiels bereitstellt.

In den vorherigen Beiträgen haben ich Ihnen bereits erklärt, wie Stakeholder, Bedarfe und Nutzen sowie Geschäfts- und Lösungsanforderungen im Beispielprojekt Northern Country Stores ermittelt und dokumentiert worden sind. Außerdem wurde eine Lösung mit Hilfe von Blockdiagrammen entworfen. Um sich die Beiträge anzusehen, folgen Sie einfach den Links in dieser Liste:

1. Überblick
2. Strategieanalyse
3. Ableitung und Priorisierung von Geschäftsanforderungen
4. Lösungsabgrenzung
5. Anforderungsdefinition an die Lösung und Entwicklung der Systemarchitektur
6. Planung des Projekts

Heute geht es weiter mit der Planung und Steuerung des Projekts, womöglich eines der spannendsten Themen. Schließlich ist das Management solch weitgreifender Change-Vorhaben mit einer enormen Komplexität verbunden:

Releases müssen geplant, Teams zusammengestellt und die Arbeit verteilt werden, Fortschritt und Status des Vorhabens müssen übersichtlich und nachvollziehbar überwacht werden. Und ganz wichtig:

Das Projekt geht auch nach dem ersten Release weiter, erstreckt sich über mehrere Jahre. Also sollten Sie auf eine Skalierung, d. h. Erweiterung des Vorhabens um Teams, Releases, Aktivitäten, Sprints und Backlogs, vorbereitet sein. Wie ist das Beispielprojekt Northern Country Stores für die digitale Transformation vorgegangen?

Klassisch oder agil – das ist die Frage

Zunächst einmal hat das Projekt entschieden, sowohl klassisch als auch agil zu arbeiten, also hybrides Projektmanagement zu betreiben. So werden z. B. das Requirements Engineering und die Lösungsbewertung als klassische Aktivitäten behandelt. Im Gegensatz zur Planung gemäß dem Wasserfallmodell schließt das Projekt diese jedoch nicht an einem bestimmten Tag ab, um darauf basierend die Lösung zu entwickeln. Denn es weiß:

Anforderungen ändern sich immer wieder und auch die Lösung muss regelmäßig hinterfragt werden, um das Projekt erfolgreich und mit zufriedenen Stakeholdern abzuschließen. Daher ziehen sich diese Aktivitäten kontinuierlich durch das Vorhaben. Zum besseren Verständnis werfen wir einen Blick auf das Gantt-Chart (Sie finden übrigens alle wichtigen Funktionen zur Planung und Steuerung in der Themenleiste von objectiF RPM):

Gantt-Chart des Change-Vorhabens

Als erstes fällt Ihnen vielleicht die Einfärbung in lila von vier Aktivitäten im Gantt-Chart auf. Damit wird ausgedrückt, dass es sich um eine spezielle Art von Aktivtäten handelt – nämlich um Initiativen, ein Begriff aus der Business Analyse. Mit Hilfe von Initiativen strukturieren Sie den Projektplan eines Change-Vorhabens. Sie setzen dort Features der Lösung um und müssen dafür natürlich entscheiden, welche das sind und die Arbeit auf Ihre Teams verteilen.

Feature + Team = Featureteam

Das Projekt Northern Country Stores verfolgt eine Entwicklung mit Hilfe von Featureteams. Das bedeutet: ein Team entwickelt ein Feature der Lösung. Wenn Sie sich noch an die Blockdiagramme für die Lösung aus dem vorherigen Beitrag erinnern, dann besteht das angestrebte System aus vier Kernkomponenten. Für die Entwicklung von drei der Komponenten hat das Projekt jeweils eine Initiative angelegt. Die Umsetzung der vierten Komponente (mobile App) wandert in die Initiative zum Application Service. Das hat folgenden Hintergrund:

Die angestrebte Lösung erfordert, dass Kunden eine App auf ihrem Smartphone installieren. In der App erzeugen diese einen QR-Code, mit Hilfe dessen sie sich beim Betreten des „intelligenten“ Stores identifizieren. Daher entwickelt ein Team in der Initiative die mobile App und das andere den Application Service, der die notwendigen Funktionen für den Einkauf im Shop ausführt (z. B. Kundenbesuch anlegen, Kundenfoto ausgeben, Kundenbesuch abrechnen usw.). Um diese Aufteilung noch besser darzustellen, sind die Team-Aktivitäten grün eingefärbt.

Die Teams arbeiten agil in Sprints. Anhand der Zahlen im Gantt-Chart können Sie erkennen, wie hoch der Planaufwand aller Anforderungen des Sprints im Vergleich zum Planaufwand der Anforderungen des Team Backlogs ist. Der Wert 8/80 bedeutet so, dass aktuell 8 Personentage (PT) Aufwand bei den Anforderungen im Sprint eingeplant sind und der Sprint insgesamt mit 80 PT plant.

Entstehen da Fragezeichen in Ihrem Kopf? Das kann ich verstehen. Denn wie wissen die Teams überhaupt, welche Aufgaben sie erledigen müssen? Wie entstehen die Team und Sprint Backlogs? Keine Sorge, hier eine schnelle Erklärung.

Der Weg vom Change Backlog zum User Story Board der Teams

Aller Anfang ist das Anlegen einer neuen Anforderung. Die neue Anforderung wird im Beispielprojekt Northern Country Stores automatisch im obersten Backlog, also dem Backlog des gesamten Change-Vorhabens, gespeichert (Change Backlog). Nach Scrum entspräche das dem Product Backlog.

Nachdem Sie die Anforderung mit einem Aufwand „bewerten“, ordnen Sie diese dem Backlog einer Initiative zu. Dort soll sie also umgesetzt werden. objectiF RPM bietet für diesen und alle weiteren Planungsschritte eine spezielle Backlog-Ansicht. Links sehen Sie immer das obere bzw. aktuelle Backlog, rechts das oder die darauffolgenden Backlogs. Als Kette ausgedrückt, wandert eine Anforderung im Verlauf des Projekts wie folgt:

Change Backlog > Initiative Backlog > Team Backlog > Sprint Backlog > User Story Board

Backlog-Sicht in objectiF RPM: Links sehen Sie das Product Backlog, rechts zwei Backlogs der Initiativen

Je detaillierter die Anforderung wird, desto weiter wandert sie in der Kette nach rechts, bis sie auf dem User Story Board eines Teams landet. Ein User Story Board ähnelt einem Kanban Board, auf dem die Anforderungen den jeweiligen Zuständen zugeordnet sind.

Mit Hilfe von Drag & Drop ziehen Sie Anforderungen in die nächsten Backlogs, um sie dafür einzuplanen.

Wenn Sie übrigens einen Überblick über den aktuellen Stand des Projekts mit den wichtigsten KPI und Auswertungsdiagrammen erhalten möchten, dann nutzen Sie einfach Dashboards.

Dashboard des gesamten Change-Projekts

Integration der Features und Skalierung des Projekts

Die Aufgaben sind an die Teams verteilt und diese können unabhängig voneinander ihre Features entwickeln. Super! Am Ende müssen diese Features aber auch als Gesamtsystem funktionieren und die Lösung in Form von Stores muss „ausgerollt“ werden. Auch das hat das Projekt bei der Planung berücksichtigt. So gibt es die klassischen Aktivitäten Release 2018 integrieren und Release 2018 einführen inkl. der dazugehörigen Meilensteine. Die Integration findet hier parallel zur Entwicklung statt, um Fehler oder „böse Überraschungen“ am Ende zu vermeiden. Zudem denkt das Projekt bereits an das zweite Release, in dem es um die Lieferung der Waren und die effiziente Einräumung in Regale gehen soll. Für diesen Zweck hat es bereits eine weitere Initiative (Delivery Service) erstellt.

Um später schnell und einfach Teams hinzuzufügen, neue Team Backlogs und Sprint Backlogs sowie User Story Boards anzulegen, bietet objectiF RPM ein starkes Hilfsmittel: Muster.

Im Beispielprojekt können Sie z. B. ein Muster auf eine Initiative anwenden und damit mit wenigen Handgriffen notwendige Arbeitsmittel für ein neues Team anlegen.

Hier wird ein Muster auf der Initiative Delivery Service angewendet

Fazit

Wir haben eine lange Reise hinter uns, die uns an viele spannende Orte der digitalen Transformation geführt hat:

• Die Strategieanalyse, in der wir Stakeholder, Bedarfe und Nutzen analysiert sowie erste Geschäftsanforderungen und einen Lösungsentwurf ermittelt haben
• Das Requirements Engineering mit paralleler Entwicklung der Systemarchitektur (oder auch „Die zwei Berge des Twin Peak Model“), durch die wir Lösungsanforderungen dokumentiert und die Lösung ausgearbeitet haben
• Und schließlich die Planung und Steuerung des Projekts, wo wir mehrere Featureteams gemanagt haben.

Das Projekt zur digitalen Transformation hat trotz hoher Komplexität strukturiert, nachvollziehbar und kontrolliert gearbeitet. Ein neuer, intelligenter Store ist entstanden und Politik sowie Bürger sind zufriedengestellt. Vielen Dank, dass Sie mich auf dieser Reise begleitet haben!

Vielleicht wollen Sie selbst das Vorhaben Northern Country Stores weiter erkunden. Dann lade ich Sie herzlich dazu ein, ein kostenloses Trial von objectiF RPM herunterzuladen.