Laut dem CHAOS Report 2015 der Standish Group Group verlaufen im IT-Bereich gerade mal knapp 30% aller Projekte vollkommen erfolgreich. Agil ausgeführte Projekte bringen es immerhin auf eine Erfolgsquote von knapp 40%. Wirklich zufriedenstellend ist aber auch das nicht. Eine (subjektive) Ursachenanalyse…
Ursache 1: Der Irrglaube an den Plan
Manche argumentieren an dieser Stelle damit, dass in unserer unhandbaren VUCA-Welt mittlerweile alle grösseren Projekte, und das nicht nur in der IT, zum Scheitern verurteilt sind. Ein unrühmliches Musterbeispiel hierfür ist der Flughafen BER.
VUCA hin oder her, Flughäfen wurden und werden weiterhin andernorts erfolgreich («on time» und «on budget») gebaut. Was beim BER wirklich schief gelaufen ist, und was genau so auch bei vielen IT-Projekten (selbst den agilen) schief läuft: Ein Irrglaube an einen umfangreichen Projektplan, der halt nun mal so umfangreich sein muss, weil es ja um so viel Geld geht. Solche umfangreichen Pläne lassen sich halt nur mühsam an all die Change Requests und Ungeplantheiten anpassen, die über die nicht minder umfangreiche Projektdauer eben so einprasseln.
Zunächst erfolgt dann unter diesem Irrglaube die Unwilligkeit den Plan über Bord zu schmeissen und grundlegend neu aufzusetzen. Als nächstes erfolgt früher oder später die unfreiwillige Erkenntnis, dass man all den unausweichlichen Change einfach nicht mehr bewältigen kann und die ganze Zeit- und Kostenplanung ins Uferlose ausartet. Salopp gessagt: Jede Plankorrektur erfordert gleich schon wieder zwei neue Plankorrekturen und so weiter…
Ursache 2: Kein Anfang und kein Ende
Gegen überbordenden Change während der Projektdauer hilft auch keine Stückelung in Sprints bzw. Iterationen, wenn Anfang und Ende des Projekts an sich schon nicht klar definiert sind. Übrigens macht genau diese zeitliche Begrenzung ein Projekt überhaupt erst aus.
A project is temporary in that it has a defined beginning and end in time. – PMI
Während bei Bauprojekten Anfang und (Soll-)Ende meistens klar definiert sind, trifft das bei IT-Projekten naturgemäss eher weniger zu. Zu fliessend ist hier der Übergang von der Erstellung der Projektergebnisse zu deren fortlaufender Nutzung.
Aus der Not heraus wird dann auf Workarounds zurückgegriffen, um halt doch irgendwie eine zeitliche Abgrenzung hinzubekommen. Wie gross die Verzweifelung hierbei ist, offenbart sich allein schon durch die willkürliche Betitelung dieser Vorhaben.: «Version 1»-Projekt, «Upgradeprojekt», «Wartungsprojekt», usw.
Ursache 3: Zu viel Ungewissheit über «Was?» und «Wie?»
Projekte funktionieren erfahrungsgemäss ganz gut, wenn zumindest entweder die gewünschten Projektergebnisse (das «Was?») oder die Mittel und Wege zu deren Erreichung (das «Wie?») klar definiert sind.
Bei IT-Projekten ist aber oftmals beides, «Was?» und «Wie?», nicht gänzlich im Detail bekannt und/oder es bestehen unter den Projektbeteiligten grundverschiedene Vorstellungen darüber. Diese Ungewissheit macht IT-Projekte dann komplexer, als sie sein müssten.
Iterative Vorgehensweisen können diese Komplexität zwar etwas abschwächen. Ist die Ungewissheit aber zu gross, reicht es nicht mehr aus, diese «nebenher» anzugehen. Zu «game-changing» sind die Erkenntnisse, die sich dann während der Projektausführung ergeben, als dass die ursprünglichen Projektziele in unveränderter Form noch weiterverfolgt werden können.
Die Lösung?
Für diese mannigfaltigen Problemen bei IT-Projekten gibt es sicherlich nicht DIE eine Lösung. Mit der #NoProjects-Bewegung haben sich mittlerweile jedoch einige Ansätze herausgebildet, mit denen sich diese Probleme zumindest proaktiv angehen lassen.
All diesen Ansätzen sind zwei fundamentale Eigenschaften gemein. Zum einen, handelt es sich nicht um umfassende Projektmanagement-Methodiken, sondern um niederschwellig anwendbare Projektmanagement-«Hacks» basierend auf bereits bekannten Praktiken und Prinzipien (vorwiegend aus Lean/Agile-Territorien).
Zum anderen, und das ist das wirklich neuartige, verwerfen diese Ansätze aber das altbekannte «Magische Dreieck» im Projektmanagement endgültig (nachdem es im agilen Projektmanagement bereits auf den Kopf gestellt worden ist). Das Dreieck, bestehend aus den drei Grössen Projektumfang (Scope), Kosten und Zeit, dient eigentlich als Orientierung für die Projektsteuerung. Die Idee hierbei ist, dass ein oder zwei Grössen, bspw. Kosten und Zeit, über das ganze Projekt hinweg möglichst konstant gehalten werden, während Change Requests und Ungeplantheiten über die variable Anpassung der verbleibende(n) Grösse(n) abgefangen werden.
#NoProjects-Ansätze dagegen akzeptieren, dass die Beschränkung auf diese Grössen und insbesondere auf die diesen Grössen naheliegenden «einfachen» Fragestellungen «Was bekomme ich?», «Wie viel kostet es?» und «Wann ist es fertig?» bei IT-Projekten in der Praxis selten zum Projekterfolg führt. Anstelle dieser einfachen Fragestellungen werden «schwerere» Fragestellungen gesetzt:
Diese alternativen Fragestellungen sind deswegen schwerer, weil sie viel schwerer qualitativ und quantitativ analysiert werden können. Sinnvolle Metriken müssen zudem in jedem Projekt erst neu gefunden werden. Eine (subjektive) Auswahl an Techniken und Tools, welche diese Herausforderungen zumindest etwas erleichtern:
Agreement & Certainty Matrix
Hierbei handelt es sich um eine zu den Liberating Structures zählende Moderationstechnik. Sie lässt sich hervorragend zu Projektbeginn einsetzen, um mit dem Projektteam die Komplexität des Projektinhalts zu erörtern. Insbesondere lässt sich damit relativ einfach aufdecken, inwiefern bezüglich dem «Was?» und «Wie?» bereits Gewissheit bzw. Übereinkunft besteht und wo noch Klärungsbedarf besteht. Auch kann das weitere Projektvorgehen so noch rechtzeitig an den spezifischen Klärungsbedarf angepasst werden.
(mehr erfahren)
Impact Mapping
Impact Mapping ist eine von Gojko Adzic eingeführte Technik, mit welcher sich alle Projektanforderungen auf ein einziges gemeinsames Business Goal zurückführen lassen (müssen). Zu diesem Zweck gibt die Technik eine festes Schema von zu bearbeitenden Fragestellungen vor. Die Antworten bzw. Annahmen zu diesen Fragestellungen sollen schrittweise validiert werden:
1. WARUM tun wir das? (das Business Goal)
2. WER kann die Erreichung des gewünschten Ziels positiv oder negativ beeinflussen?
3. WIE können die Akteure eine positive oder negative Beeinflussung vornehmen bzw. wie sollten sie das tun?
4. WAS kann die Organisation oder das Team machen, um die Zielerreichung zu unterstützen?
Mit diesem Schema lässt sich eine entsprechende Impact Map zeichnen. Dadurch wird im Projekt ein Fokus auf das Business Goal begünstigt.
(mehr erfahren)
Lean Canvas
Das Lean Canvas ist eine von Ash Maurya vorgestellte Modifikation des Business Model Canvas, welche die Ideen der von Eric Ries ausgelösten «Lean Startup»-Bewegung berücksichtigt. Die Modifikation besteht im Wesentlichen aus einer inhaltlichen Umdeutung von einigen der Canvas-Felder, so dass eine Anwendung der «Lean Startup»-Methode unterstützt wird. Mit dieser Methode können Geschäftsmodelle iterativ in kurzen Zyklen validiert und abgeändert (pivot) werden.
Besonders hilfreich ist die strikte Trennung des Problem/Solution Fit vom Product/Market Fit. Auf diese Weise können mögliche Lösungen zunächst auf Korrektheit und Vollständigkeit analysiert werden, bevor diese bereits voreilig unter dem Aspekt ihrer geschäftsrelevanten Vermarktbarkeit betrachtet werden. In diesem Kontext eignet sich das Lean Canvas auch ganz gut für die Projektarbeit.
(mehr erfahren)
Action Priority Matrix
Die Action Priority Matrix (oder auch Impact/Effort Matrix) ist ein Tool, mit welchem sich strategische Vorhaben priorisieren lassen. Ähnlich der Eisenhower-Matrix erfolgt die Priorisierung anhand von zwei Kriterien, die eine Matrix bestehend aus vier Quadranten mit entsprechenden Handlungsempfehlungen bilden. Für jedes Vorhaben wird der voraussichtlich Nutzen (Impact) dem voraussichtlich Aufwand (Effort) gegenübergestellt.
Diese einfache Visualisierung ist sehr übersichtlich und ermöglicht ein schnelles Aktualisieren der Priorisierung in regelmässigen Zeitabständen, bspw. wenn entweder zu dem Nutzen oder dem Aufwand mittlerweile erste Erfahrungswerte vorliegen. Die Matrix ist in erster Linie ein Tool für das Projektportfoliomanagement, kann genau so gut aber auch innerhalb eines Projektes für die Priorisierung von Anforderungen eingesetzt werden.
(mehr erfahren)
Fazit
Ist mit #NoProjects ein Projekterfolg stets garantiert? Selbstverständlich nicht, doch Projekte scheitern so wesentlich seltener und sehr viel früher. Im Vergleich zum klassischen Projektdenken ist #NoProjects allerdings auch der steinigere Weg, weswegen er (noch) nicht so oft gegangen wird.
Auch ist der vergleichsweise höhere Aufwand bei eher trivialen Projekten gar nicht gerechtfertigt. Wenn die Prämisse gilt, dass das Projekt desto schneller fertig ist, je mehr Leute man dran setzt, dann reicht natürlich auch «#Projects» aus. Nur sind die wenigstens IT-Projekte so trivial.
Wir von Deep Impact verfolgen grundsätzlich bei allen komplexen Vorhaben #NoProjects als Mindset und wenden unser hier vorgestelltes Toolset an, auch wenn die Rahmenbedingungen das uns nicht immer leicht machen. Unserer Erfahrung nach zahlt sich ein #NoProjects-Vorgehen für den langfristigen Projekterfolg aus.
