Design Thinking im IT-Projekt (HERMES kompatibel ;-) mit visuellen Analysen

Design Thinking im IT-Projekt (HERMES kompatibel ;-) mit visuellen Analysen

Fehler, die am Anfang von einem Projekt gemacht werden, sind die teuersten. Das ist eigentlich schon sehr sehr lange bekannt. Ebenso die Tatsache, dass man oft IT-Systeme und Applikationen baut, die am eigentlichen Bedürfnis der Kunden weit vorbei gehen (googeln Sie mal „Projekt Anforderungen Schaukel“, ein Klassiker!). Das heisst: wenn man am Anfang vom Projekt die Ziele und Anforderungen nicht richtig erfasst, dann wird es viel zu teuer und es dauert viel zu lange, bis man es merkt.

Projekt Anforderungen: was der Kunde eigentlich bräuchte…

Und trotzdem scheint es noch wenig Rezepte zu geben, mit denen man es besser macht. Gemäss der Chaos-Studie 2015 (das lohnt sich auch zu  googeln), sind zwar die kleineren, agilen Projekte erfolgreicher als die grossen, die gemäss Wasserfall-Modellen durchgeführt werden. Doch immer noch (und die Studie umfasst weltweit tausende von Projekten) ist die Erfolgsquote lediglich bei 58%!

Ergebnisse der Chaos Studie 2015 von der Standish Group: kleine, agile Projekte sind erfolgreicher

Stellen Sie sich mal vor, Ihr Bäcker würde nur 58 von 100 Brötchen richtig hinbekommen, 38 wären etwas scheps bis komisch, aber noch essbar, und die restlichen 4 gehen direkt vom Backofen in die Abfalltonne. Und bei den Zöpfen müsste er grad 29 direkt in die Tonne schmeissen, von drei Zöpfen ist jeweils 1 Zopf gut zum verkaufen, einer ist genügend um die Enten zu füttern (oder um Brösmeli herzustellen), und jeder dritte geht direkt in die Tonne. Beim Bäcker ist das gottlob nicht so (das wäre ja massiver Food-Waste!), aber wir machen das anscheinend so in unseren IT-Projekten. Ich finde, es wäre höchste Zeit, dass sich was ändert, was meinen Sie? Aber wie sollen wir das tun? Hier ein erprobter Vorschlag aus der Praxis.

Agil ist ja der grosse Hype (oder schon nicht mehr?). Auch für ein agiles Projekt brauchen Sie einen brauchbaren Backlog. Es ist genau der Backlog, nämlich die umzusetzenden Anforderungen (oder eben die richtigen UserStories), der am Anfang definiert werden muss.  Und wenn sie das schon falsch machen….

SCRUM-Prozess nach SCRUM.org

Gucken wir mal über den Zaun, wie machen es die anderen? Und da kommen wir eben zum Beispiel auf Design Thinking: ein kreativer Prozess, mit dem man zu guten (neuen, innovativen) Lösungen kommt, die genau auf die Benutzer- oder Kundenbedürfnisse zugeschnitten sind. (Auch den können Sie googeln, dabei helfen z.B. die Begriffe „Design Thinking scrum“). Sie beginnen also Ihr Projekt mit kreativen, innovativen Methoden und setzen es dann mit agilen Methoden (SCRUM) um. Soweit so gut: aber wie genau machen Sie das am Besten und wie passt das jetzt zu HERMES (wieder etwas zum googeln, es geht aber im Prinzip gleich mit allen Projekt-Management-Methoden)?

HERMES gemäss http://www.hermes.admin.ch

Ich will in diesem Artikel zeigen, wie die Prinzipien von Design-Thinking zu HERMES (inkl. agiler Entwicklung nach SCRUM) passen und mit welchen Methoden man zu den gewünschten Ergebnissen kommen kann.

Prozess des Design Thinking aus www.dschool-old.stanford.edu

Anfangen tun wir mit empathize: wir fühlen uns in unsere Benutzer, Kunden, Betreiber etc. ein. In HERMES ist das passende Ergebnis im Prinzip die Stakeholder-Anlayse. Doch wir gehen noch etwas weiter: aus der Toolbox vom Strategyzer Business Model Canvas (auch googeln, lesen, kaufen, anwenden 😉 nehmen wir aus dem Value Proposition Design die Idee, dass wir die Syteme so designen, dass sie die Probleme der Stakeholder lösen (Pain Relievers for Customer Pains), deren Wünsche erfüllen (Gain Creators for Customer Gains) und ihre Arbeit erleichtern (Products and Services to enable Customer Jobs). Wir erheben also zusammen mit den Stakeholdern auch deren Wünsche, Probleme und ihre Aufgaben. Daraus können wir für die Stakeholder passende Ziele und Anforderungen ableiten. Auch die Kommunikation wird einfacher: wir wissen, wo der Schuh drückt und mit welcher Sprache und welchen Zielen wir auf die Stakeholder zugehen können.

Value Proposition Design
Value Proposition Design gemäss Strategyzer

Man kann dazu natürlich die (wirklich tollen) Vorlagen von Strategyzer verwenden, oder aber man kann diese Arbeit mit Visuellen Analysen, mit Figuren, Post-Its oder speziell dafür designten Karten (VA-Cards von der projektpraxis) machen.

Visuelle Analyse aus der Praxis mit Karten und Figuren (anonymisiert): Stakeholder 1

Die Karten haben den Vorteil, dass man sie in späteren Analysen wieder verwenden kann (bis hin zur Verwendung im Backlog), Figuren haben den Vorteil, dass man sich die Ergebnisse sehr gut merken kann und dass die gemeinsame Erarbeitung einer solchen Analyse Spass macht (ein wichtiger Erfolgsfaktor für kreative, innovative Prozesse). Wir empfehlen eine Kombination der Methoden. Das fassbare Ergebnis einer solchen visuellen Analyse sind die Post-Its oder die Karten und vor allem die Fotos der gesamten Analyse, die sich als sehr gute Grundlage für die Dokumentation eignen. Die weniger fassbaren Ergebnisse sind der gemeinsame Prozess der Lösungsfindung, die Einigkeit, die man erzielt, die gemeinsame Definition, wie es sein soll und der Entscheid, dass das Ergebnis jetzt so stimmt für alle. Und diese Ergebnisse bleiben allen Teilnehmenden sehr lange (teilweise jahrelang) in Erinnerung.

Besprechung der Ergebnisse einer visuellen Analyse: die Projektteilnehmenden haben sich auf eine gemeinsame Sicht geeinigt und diskutieren diese

In einem ersten Schritt (Analyse Stakeholder 1) wird mit dem Projektleitenden und dem Projektauftraggeber definiert, welche Projektteilnehmenden zum Projekt eingeladen werden.

Stakeholder Analyse 1: erste Analyse der benötigten Projektteilnehmenden

Danach wird mit diesen Projektteilnehmenden (dem ganzen Projektteam) die Stakeholder-Analyse ergänzt (mit ihren Wünschen, Schwierigkeiten und der Definition ihrer Aufgaben). Eine erste Version der Ziele für das Projekt und der Anforderungen wird definiert.

Stakeholder-Analye 2 und erste Version von Zielen und Anforderungen

Wenn wir so alle unsere Stakeholders besser kennen gelernt haben und aus ihren Wünschen, Schwierigkeiten und Aufgaben bereits eine erste Reihe von Zielen und Anforderungen herausgelesen haben, können wir in die Phase define übergehen.

Im HERMES werden die Ergebnisse dieser Phase in der Studie festgehalten: vollständige Ziele und Anforderungen, Ist-Analyse, Systemkontext etc. Mit visuellen Analysen sollte man mit der IST-Analyse beginnen: wiederum in einer Darstellung mit Figuren und/oder Karten. Zu den Stakeholdern (Figuren) kommen jetzt noch IT-Systeme (z.B. Server, PC, Netzwerke), Applikationen, Prozesse und Dokumente hinzu. Meist haben wir in der aktuellen Situation mehrere Schwierigkeiten, denn sonst müsste man nichts ändern. Durch die gemeinsamen Darstellung in der visuellen Analyse, z.B. mit dem gesamten Projektteam (inkl. Benutzervertreter und Betreiber) der aktuellen Situation kann im Projektteam ein erster Konsens entstehen: „Wir das Projektteam haben eine gemeinsame Sicht auf die aktuelle Situation und wissen, wo wir stehen.“ Das erfüllt wiederum den Anspruch aus dem Design Thinking, dass man die unterschiedlichen Sichten in den Prozess mit einbeziehen soll. Aus der Ist-Analyse lässt sich der Systemkontext (Ist) sehr einfach extrahieren, aber auch dass sollte gemeinsam gemacht werden, denn es ist ein wichtiger Prozess, dass man die unterschiedlichen „Kreise“ (Scope) gemeinsam definiert.

Ist-Analyse und Systemkontext

Jetzt kann man schon langsam in den kreativen Prozess der Lösungsfindung mit Varianten (Phase ideate vom Design-Thinking) übergehen. Mit der Methode der visuellen Analysen mit Figuren und/oder Karten läuft das ganz reibungslos und einfach. Durch die Verwendung von visuellen Methoden mit farbigen Karten und/oder Figuren sind die Teilnehmenden der Analysen bereits in einem kreativen Gemütszustand (lösungsorientiert). Die Aufgabe ist es jetzt, die Figuren und/oder Karten aus der Ist-Situation einfach so lange umzubauen und zu ergänzen bis möglichst wenig Probleme da sind und bis alle der Meinung sind, so ist es gut und so sind die vorher erhobenen Wünsche und Ziele erfüllt. Wir nennen diese Analyse „Happy-End“, wobei man natürlich mehrere Varianten erarbeiten kann. Mit dem Titel „Happy-End“ assoziiert man einerseits einen Zustand, in dem alle mit dem Ergebnis happy sind (eine Vorausnahme des Projekterfolges)und andererseits ermöglicht einem die Kontrolle „ob jetzt alle happy sind“ auch, zu sehen, ob die Situation vollständig und widerspruchsfrei dargestellt wurde.

Happy-End (Varianten) und überarbeitete Liste der Ziele und Anforderungen

Am Schluss werden noch aus den Ergebnissen der Visuellen Analysen die konsolidierte Liste von Zielen und Grob-Anforderungen überprüft und ergänzt. Nach den Analysen können anhand der Fotos und der Karten oder Post-Its die Ergebnisse in Listen und Grafiken übertragen werden, und fliessen damit direkt in die entsprechenden Dokumente (u.a. Studie) ein. Da diese Ergebnisse gemeinsam erarbeitet wurden, braucht es praktisch keinen Vernehmlassungs-Prozess mehr: es wird lediglich überprüft, ob die Übersetzung der Analysen in das Dokument korrekt passiert ist. Der Konsens wurde bereits durch die gemeinsame Analyse gefunden.

Im ganzen wird der Prozess durch 4 Workshops durchgeführt:

  1. Durch die allerersten Stakeholder-Analyse bekommt man das Projektteam überhaupt erst zusammen: wen muss oder sollte man einladen?
  2. Die Stakeholder-Analyse mit Wünschen, Problemen und Aufgaben wird dann im Projektteam wiederholt resp. ergänzt, damit man eine vollständige Sicht hat
  3. Im selben oder einem nächsten Workshop stellt man die Ist-Situation und den Systemkontext dar.
  4. Im letzten Workshop werden dann verschiedene Happy-End Varianten erarbeitet. Wenn alle relevanten Stakeholder mit am Workshop dabei sind, könnte am selben Workshop direkt der Variantenentscheid gefällt werden.

Im Idealfall kann so eine Phase Initialisierung von einem HERMES Projekt in wenigen Workshops, mit einer Durchlaufzeit von wenigen Wochen abgeschlossen werden. Aus den Einzelteilen der Analysen (z.B. den Karten/Post-Its mit den Wünschen) können jetzt die passenden User-Storys für das Backlog gemacht werden und ein praktisch nahtloser Übergang in die agile Entwicklung ist gewährleistet. Im Design Thinking Prozess haben wir jetzt die Phasen empathize, define und ideate durchlaufen. Die Phasen protype und test durchlaufen wir gemäss HERMES in der Phase Konzept und im SCRUM auch in jedem Sprint.

Möchten Sie es ausprobieren? Gerne zeigen wir Ihnen die Methoden und deren Zusammenhänge (und Ergebnisse) an einem praktischen Beispiel. Nehmen Sie noch heute Kontakt auf und vereinbaren Sie einen Demo-Termin.

Haben Sie den Artikel hilfreich und interessant gefunden? Wir freuen uns über jeden Kommentar und auch auf Hinweise, wie man das noch verbessern könnte.