Vertrauen hat zwei Aspekte – nicht immer weisen diese in dieselbe Richtung?

Dass Vertrauen für die erfolgreiche Zusammenarbeit in Projekten wichtig ist, gehört zu den Allgemeinplätzen. Win-Win ist ein oft gehörter Begriff, dahinter steckt das spieltheoretische Modell des Gefangen-Dilemma. Ausführlicher habe ich mich mit diesem Thema in zahlreichen Trainings beschäftigt, eine Zusammenfassung kann man auf meiner Website hier nachlesen.

Ich meine allerdings, man sollte zwei Arten von Vertrauen unterscheiden. Das in Analogie zum Kommunikationsmodell von Watzlawick, das Sach- und Beziehungsebene unterscheidet.

  • Vertrauen auf der Beziehungsebene: Ist meist gemeint, wenn man von Vertrauen spricht. Man schreibt anderen Ehrlichkeit, Zuverlässigkeit, Fairness etc. zu (oder eben nicht).
  • Vertrauen auf der Sachebene: Traue ich jemand eine Leistung zu (Arzt, Pilot, ProjektleiterIn oder Teammitglied, Berater, …).

Beide Aspekte korrelieren in der Praxis: wir gehen davon aus, dass jemand, der etwas gut kann, das auch für einen guten Zweck einsetzt. Es gibt aber auch Experten, denen man auf der Beziehungsebene ganz und garnicht traut. In Projekten kann man aber unter den gegebenen Rahmenbedingungen auf ihre Mitwirkung oft nicht verzichten.

Wir sollten beim Staffing von Projekten zwischen diesen beiden Arten von Vertrauen klar unterscheiden und darauf achten, dass die Sachebene nicht zu kurz kommt. Lauter „nette“ Leute können ein Projekt in den Sand setzen. Man muss manchmal einen schwierigen Mitmenschen bewusst einsetzen und ertragen. Es geht in Projekten eben nicht nur um social skills, wenn man das Projektteam zusammenstellt.

Gibt es Wechselwirkungen zwischen diesen beiden Arten des Vertrauens?

Wenn wir das Bild zu diesem Beitrag interpretieren, so können wir davon ausgehen, dass der Vater das Vertrauen des Sohnes nicht enttäuschen will. Er könnte jedoch daneben greifen. Dann wäre das Vertrauen in seine Fähigkeit, zum richtigen Zeitpunkt zuzupacken (Vertrauen auf der Sachebene), enttäuscht worden. Ob das auch Auswirkung auf das Vertrauen auf der Beziehungsebene hat, hängt von vielen Faktoren ab, z.B. der Häufigkeit solcher Ereignisse. Auch wenn es sich um zwei grundsätzlich voneinander unabhängige Faktoren handelt, sind Wechselwirkungen nicht auszuschließen. Wer z.B. nicht in der Lage ist, seine Fähigkeiten realistisch einzuschätzen und daher immer wieder Zusagen macht, die nicht halten, muss mit einem Vertrauensverlust auf der Beziehungsebene rechnen.

Die Karrierestrategie als Geschäftsmodell darstellen

Wenn man seine berufliche Zukunft plant, gibt es eine Reihe von inhaltlichen Entscheidungen zu treffen. Dazu habe ich in einem anderen Blog-Beitrag schon einiges gesagt. Wer das lieber als Podcast konsumieren will, findet unten die Links zum Podcast, der dieses Thema behandelt.  Podcasts für IT-Projektmanager und IT-Projektmanagerinnen von mir gibt es auf allen gängigen Podcast-Plattformen.  Die Links gibt es hier.

Die andere Frage ist, welche Themen man dabei bearbeitet und wie man das Ergebnis darstellt. Ich sehe die EKS-Strategie als die beste inhaltliche Leitlinie für die Erarbeitung der Karrierestrategie. Genauso sehe ich den Ansatz des Business Model Canvas als Best Practice bei der Darstellung von Strategiekonzepten.

Kernstück dieser Methode ist das sogenannte „Business Model Canvas“, eine Matrix, in der die Elemente eines vollständigen Geschäftsmodells enthalten sind. Im Kern steht die „Value Proposition“. Das ist der Nutzen, der den Kunden angeboten wird. Hier als Beispiel eine solche Geschäftsmodelldefinition für Nespresso auf hoher Abstraktionsebene (Quelle: https://www.researchgate.net). Diese kann jeder aus der Kenntnis von Nespresso (What else?) gut nachvollziehen. Hier ein Youtube-Video von Alex Osterwalder zum  Geschäftsmodell von Nespresso.

Die Autoren sehen dieses Modell als Standardisierung der Darstellung von Geschäftsmodellen. Alex Osterwalders erste Folie in seiner Masterclass ist voller „Bla Bla Bla …“, weil über Geschäftsmodelle so oft unstrukturiert und vage gesprochen wird. Das Canvas ist ein generisches Modell für beliebige Inhalte. Regeln und Empfehlungen für die inhaltliche Gestaltung von Geschäftsmodellen bewegen sich auch auf einer eher formalen Ebene. Allerdings gibt es im Buch zahlreiche Beispiele, wie erfolgreiche Geschäftsmodelle aussehen. Der Vorteil der standardisierten Darstellungsform ist ja gerade: man kann Geschäftsmodelle miteinander vergleichen. Man kann sie übereinander legen und die Unterschiede herausarbeiten.  Damit wird die Bewertung von Entscheidungsalternativen leichter. 

Geschäftsmodell für mich als Person?

Manche werden einwenden, dass die eigene Karrierestrategie doch nicht als Geschäftsmodell zu sehen sei. Genau das ist aber eine unkluge Einschränkung der eigenen Möglichkeiten. In der EKS ist immer schon klar, dass die Strategieplanung für Unternehmen, Organisationen und Personen den gleichen Regeln folgt. Nur die Inhalte sind unterschiedlich.

Wir fokussieren hier auf die Karriereplanung für IT-Projektmanager. Das Modell kann man auch für sich als Vater/Mutter, Vereinsmitglied etc. anwenden, aber dafür sollten Sie das Buch konsultieren (Link am Ende des Beitrages). 

Wie kann man EKS und Business Model Canvas sinnvoll kombinieren?

Ich verschränke dieses Modell mit den Grundsätzen der EKS-Strategie. In dieser Kombination wird es noch wirksamer. Der formale Rahmen des Canvas und die Entscheidungsgrundlagen aus der EKS ergeben eine unschlagbare Einheit. Vergleichen wir also die Elemente des Business Model Canvas mit den Strategieentwicklungsphasen der EKS (die Links führen – wie schon gesagt – zu einem Podcast über dieses Thema):

Kunden (Customer Segments): Das ist die vielversprechendste Zielgruppe der EKS. 

Wertangebot (Value Proposition): Das größte Nutzenpotenzial der EKS.

Kanäle (Channels): In der EKS implizit in der Engpassanalyse enthalten, jedoch im Canvas mit Recht als eigenes Thema hervorgehoben.

Kundenbeziehungen (Customer Relationship): Hier gilt das gleiche wie bei den Kanälen.

Umsatz (Revenues): Die EKS geht davon aus, dass ein hoher Nutzen für die erfolgversprechendste Zielgruppe geradezu automatisch zu einem angemessenen finanziellen Erfolg führt, aber auch hier ist es sinnvoll, dem Ansatz des Canvas zu folgen und das explizit und detailliert zu planen.

Schlüsselressourcen (Resources): Hier gibt die EKS mit der Analyse der Ist-Situation, der eigenen Stärken und dem Herausarbeiten der „Differenzeignung“ (wo unterscheide ich mich – vorteilhaft – von anderen) sehr konkrete Anleitungen, die in die Erarbeitung des „Business Model YOU“ eingebracht werden können.

Schlüsselaktivitäten (Activities): Auch das eine sinnvolle Detaillierung, die in der EKS Ergebnis der Engpassanalyse ist, jedoch nicht als eigenes Ergebnis der Planung herausgehoben wird. 

Schlüsselpartner (Partners): Dieses Feld wird in der Phase 6 der EKS („Kooperationsstrategie„) intensiv und ausführlich bearbeitet.

Kosten (Costs): Eine sinnvolle Hervorhebung und Detaillierung, die in der EKS in der Analyse des internen Engpasses (Phase 4: Engpassanalyse) adressiert wird.

Was leistet die EKS, was das Business Model Canvas?

Wie sollte man vorgehen? Meiner Erfahrung nach ist es sinnvoll, die Phasen der EKS durchzuarbeiten und die damit verbundenen Empfehlungen zu berücksichtigen; mehr dazu in diesem Podcast. Die Ergebnisse werden im Business Model Canvas abgebildet. Dieses dient auch als Checkliste für die Vollständigkeit der Analyse. Wir haben beim Vergleich oben gesehen, dass das Canvas einige wichtige Elemente explizit adressiert, die in den EKS-Anleitungen nicht ausdrücklich angesprochen werden. 

Wichtig ist, dass beide Ansätze von den gleichen Grundprämissen ausgehen, sonst wäre die Kombination ja sinnlos. Es geht um das Anbieten eines überlegenen Nutzens für eine konkret definierte Zielgruppe. 

Wo die EKS weiter geht und auch konkreter wird, sind die Phasen 5 (Innovationsstrategie) und 7 (Entwicklung zum konstanten Grundbedürfnis). Das Business Model Canvas bekommt dadurch einen Zeitstempel und es wird klar, dass es ständig weiter entwickelt werden muss. Die EKS gibt hier eine Richtung vor. Diese Empfehlung beruht auf der Analyse von zahlreichen Karriereverläufen.  

Wo die EKS sich inhaltlich mehr festlegt, ist die Bewertung der Kooperation. Die EKS versteht sich ausdrücklich als Win-Win-Strategie, die Konfrontationen durch Spezialisierung ausweicht, sich gegen Mitbewerb allerdings durch die stetige Arbeit an der Verbesserung des eigenen Nutzenangebotes (Innovations- und Kooperationsstrategie) absichert. Konkurrenz wird abgewehrt, weil diese Überlegenheit in einem möglichst eng definierten Fokus einen Angriff auf die Marktposition eines der EKS folgenden Marktteilnehmers immer aussichtsloser werden lässt („Prinzip der schiefen Ebene“). Gerade durch die Fokussierung bleibt aber Platz für andere Anbieter mit komplementären Angeboten, mit denen man oft zum beiderseitigen Vorteil kooperieren kann. 

Wer lieber hört, als liest, hier der Link zu meinen Podcasts, in der jede Stufe genau und mit Praxisbeispielen beschrieben wird. 

Aber bald auch hier mehr zu diesem Thema, ich bleib’ dran! Im Mai besuche ich eine Masterclass mit Tim Clark, dem Hauptautor des Buches „Business Model You“, auch davon werde ich hier berichten.

5.6.2020: Nachtrag aus aktuellem Anlass! Ja, jetzt habe ich die Master-Class absolviert, es war ein sehr diverses Team von Malaysia bis Hawaii dabei. Tim Clark hat unsere Erwartungen nicht enttäuscht. Und jetzt bin ich ….

Business Model YOU Practitioner - Plakette

Noch ein Nachtrag aus aktuellen Anlass. Im Juni 2021 habe ich meinen Zugang zu diesem Thema in Richtung Teamentwicklung erweitert.  

Ich weiß, dass ich nicht weiß – was Agilität und Sokrates miteinander zu tun haben!

Projektmanagement soll Sicherheit geben

Jeder weiß, was das Ergebnis sein soll, was zu tun ist, wie der aktuelle Stand ist, wann was fertig sein wird. Natürlich kennt man auch den Aufwand und weiß rechtzeitig, ob es Abweichungen gibt oder geben wird. Soweit das Ideal – und wer wünscht sich das nicht?

Doch die böse Realität macht uns allzu oft einen Strich durch die Rechnung. Das geplante Ergebnis wird immer wieder verändert: Moving Target. Auch die Aufwandsprognose wird immer wieder korrigiert, leider in die falsche Richtung. Statusabfragen führen immer wieder zu hektischer Betriebsamkeit. Irgendwann ist der Aufwand für die Erstellung von Statusberichten so hoch, dass zu wenig Zeit bleibt, den Status durch Arbeit an den eigentlichen Aufgaben zu verbessern.

Die Reaktion darauf ist oft genug eine stärkere Formalisierung. Prozesse werden präzisiert, ihre Einhaltung strenger überwacht. Statusberichte werden immer detaillierter und in immer kürzeren Abständen verlangt. Der tägliche Statusbericht ist dann wohl die Krönung dieser Entwicklung, die als das typische „Mehr desselben“ im Sinne von Paul Watzlawick zu sehen ist. Wann immer ein neues Problem auftaucht, fordert das Management eine weitere Verschärfung der Kontrollmechanismen. Die Situation ist schlecht, sie wird jeden Tag schlechter, aber man weiß genau, wie schlecht.

Gibt es eine Methode, diesem Teufelskreis zu entgehen? Können wir unsere Planungs-, Schätz- und Steuerungsmethoden so verbessern, dass wir wirklich „alles im Griff“ haben? Die Antwort ist, ganz im Stil von Radio Eriwan: Im Prinzip ja. Der Schlüssel dazu liegt in der Frage, was wir als „alles im Griff“ verstehen. 

Weil nicht sein kann, was nicht sein darf

Mit Mark Twain müssen wir eines akzeptieren: „Prognosen sind schwierig, vor allem, wenn sie die Zukunft betreffen.“. Oder nehmen wir Albert Einstein: „Planen heißt, den Zufall durch den Irrtum zu ersetzen“. Oder Helmuth von Moltke: „Kein Plan übersteht die erste Feindberührung“. 

Diese Zitate kann man als defaitistisch abtun, sie sind es aber nicht. Sie lehren uns nur die Demut, die Begrenztheit unseres Wissens über die Zukunft zu akzeptieren und uns darauf einzustellen. Die großen Probleme entstehen, wenn wir uns weigern, die Begrenztheit unseres Wissens zu akzeptieren. Sokrates, zweifellos einer der klügsten Menschen, die jemals gelebt haben, hat seine Erkenntnisse in dem Satz: „Ich weiß, dass ich nicht weiß“, zusammengefasst. Das ist nicht Koketterie, um Widerspruch zu ernten. Je mehr man weiß, umso klarer sieht man die Begrenztheit des eigenen Wissens. 

Wenn wir aber diese Begrenztheit als Prämisse akzeptieren und unsere Vorgangsweise darauf abstimmen, sieht die Sache gleich viel besser aus. Ich nehme einen Vergleich, der nichts mit Projektmanagement zu tun hat. Wir akzeptieren unangenehme Erkenntnisse leichter, wenn sie nicht aus unserem ureigenen Kompetenzbereich kommen.

Wir müssen eine Last über eine unwegsame und uns unbekannte Route transportieren. Nun können wir vor Antritt der Fahrt beliebig viel Zeit investieren, um die Details dieser Route, jede Kurve, jede Steigung, jede Gefahrenstelle zu erkennen.

Mit diesem Wissen ausgestattet, treten wir die Fahrt an. Dummerweise sind unsere Informationen nicht immer korrekt, denn die Quellen sind rar. Dann ändert sich auch noch das Wetter und an einer Stelle kam es zu einer Hangrutschung. Viele unserer mühsam erhobenen Daten erweisen sich daher als falsch, jedenfalls zu dem Zeitpunkt, wo wir sie benötigen. 

Die richtige Balance finden

Was ist die Lösung? Einfach drauf los fahren? Natürlich nicht! Aber wir werden uns gut überlegen, welches Fahrzeug wir wählen, so dass wir eine ausreichende Bandbreite von schwierigen Straßenverhältnissen bewältigen können. Wir werden auch unsere Fahrkünste trainieren. Wenn das nicht rechtzeitig möglich ist, werden wir jemand engagieren, der mit dem gewählten Fahrzeug und den zu erwartenden Straßenverhältnissen auch im Worst-Case zurechtkommt.

Unsere Datensammlung werden wir daher darauf konzentrieren, die wahrscheinliche Häufigkeit und das maximale Ausmaß an Schwierigkeiten auf diesem Weg zu bestimmen. Darauf aufbauend werden wir unsere Schätzung der Fahrtdauer mit Risikozuschlägen versehen. Genügend Treibstoff für den LKW und genügend Getränke und Nahrung für uns nehmen wir an Bord.

Gesucht wird eine ausgewogene Mischung aus Datenanalyse und Planung – also Prognose – einerseits, Investitionen in unsere Leistungsfähigkeit bei der Bewältigung der zu erwartenden Probleme andererseits. Wir verzichten allerdings darauf, den genauen Ablauf unserer Fahrt im Voraus in allen Details zu planen und begnügen uns mit Bandbreiten. 

Damit akzeptieren wir Unsicherheiten. Wir gestehen uns ein, dass wir nicht alles im Voraus wissen und dass es zu unvorhergesehenen Herausforderungen kommen kann. 

Deterministische und systemische Planung

In kritischen Projektsituationen höre ich immer den Ruf nach einer besseren Planung. Nicht immer war ich in meiner Position gefestigt und mutig genug, die Frage zu stellen: Was meinen Sie mit „Planung“? Es wäre aber ohnehin nur eine rhetorische Frage gewesen, denn so gut wie immer ist damit ein Termin- und Aufwandsplan gemeint. Keine Frage, dass man eine solche Planung braucht, es braucht allerdings genauso eine Planung, wie diese Planwerte erreicht werden sollen. 

Machen wir uns das anhand des folgenden Modells anschaulich.

Die deterministische Planung versucht, eine exakte Prognose der drei Zielgrößen (Ergebnis, Termin, Budget) zu erstellen. Ob diese Prognose hält, hängt allerdings davon ab, wie gut die Produktionsprozesse (die inhaltliche Projektarbeit) und die Managementprozesse (also das Projektmanagement) funktionieren. Und diese benötigen für den Erfolg ausreichende Ressourcen, die zur richtigen Zeit am richtigen Ort in der benötigten Ausprägung zur Verfügung stehen müssen. 

Eine vollständige Planung muss alle diese Aspekte beinhalten, also auch die Projektarbeit als dynamisches System gestalten. 

Der agile Zugang zur Planung

Agile Projekte gewichten die Optimierung des dynamischen Systems höher als die Festlegung bzw. Prognose von Termin und Aufwand für im voraus fix definierte Ergebnisse. Die Prozesse sind immer die gleichen: Der Scope wird in überschaubare Einheiten (Epics, User Stories) heruntergebrochen. Diese bilden den Arbeitsvorrat (Backlog), der geclustert und priorisiert wird. Jedes Item erhält eine vorläufige Aufwandschätzung, die zunächst „nur“ die Aufwandsrelationen zwischen den Items abbildet („Storypoints“). Die Gesamtaufwandschätzung erfolgt mit eher globalen Methoden (Vergleichswerten, Top-Down-Schätzungen) und dient vor allem der Dimensionierung der Personalressourcen („agile Teams“) in Relation zur erwarteten Laufzeit.

Es wird allerdings darauf verzichtet, die Zwischentermine samt erwartetem Ergebnis im Voraus – womöglich mit dem Anspruch auf Vollständigkeit – zu planen. Dieser Versuch wird als sinnlos, weil zum Scheitern verurteilt, gesehen und daher unterlassen; man würde damit nur Zeit verlieren und wertvolle Ressourcen verschwenden. 

Die Gestaltungsvariablen sind die Inhalte, die schrittweise abgearbeitet werden. Dazu gibt es eine rollierende Planung; stets einen groben Plan bis zum Projektabschluss, einen genauen Plan immer nur für die nächsten Iterationen/Sprints. Anhand der tatsächlich erzielten Fortschritte wird die „Velocity“ (wie viele Storypoints schaffen wir je Iteration) immer genauer ermittelt und damit die Fertigstellungsprognose präzisiert. Und es wird akzeptiert, dass man unter den gegebenen Umständen nicht mehr liefern kann, als diese empirischen Daten aus dem konkreten Projekt zeigen. Das kann weniger sein, als es sein sollte. Obwohl für viele Manager nicht sein kann, was nicht sein darf (Christian Morgenstern), ist es am Ende doch immer so, wie es ist.

Eine kompakte Erläuterung, was Agilität im Projektmanagement beinhaltet, gibt es im Glossar des Projektmagazins.

Fahrt ins Blaue statt Planung?

Auftraggeber, die von traditionellem Projektmanagement („Wasserfallmodell“) geprägt sind, sind vom offenen Eingeständnis der Unwissenheit schockiert. Viele sehen zwar mittlerweile ein, dass agiles Vorgehen effizienter ist als das Planen und Abarbeiten von gefinkelten Terminplänen mit kunstvoll geschnittenen und einzeln geplanten Arbeitspaketen. Aber es muss doch trotzdem einen Plan geben, der sagt, was wann fertig sein wird und wieviel Aufwand damit verbunden ist. Gerade wieder habe ich erlebt, wie einem agilen Projekt Arbeitspaketdefinitionen aufgezwungen wurden. Eine sinnlose Aktion die Zeit kostet und nichts bringt. Es schaut zwar alles schön geplant aus, die Eckpunkte des magischen Dreiecks sind also determiniert. Aber ob das Projekt erfolgreich sein wird, hängt von Faktoren ab, die außerhalb dieser Planung liegen.

Wenn durch eine traditionelle Planung das Management (Auftraggeber, Projektcontroller, …) beruhigt werden kann (ich würde sogar sagen: „ruhiggestellt“), ist das OK. Es ist ein Opfer, das man bringen muss, um einen Schutzschild aufzubauen, hinter dem effizient am Ergebnis gearbeitet werden kann. Schlimm wird es nur, wenn diese Art von Planung Einfluss auf die tatsächliche Projektarbeit bekommt. Auch das habe ich schon erlebt und es ist die Hölle. Das hat schon Shakespeare gewusst: „Und ist es Wahnsinn, so hat es doch Methode“. Man weiß, wie das Stück endet: Fast alle, einschließlich Hamlet sind tot. 

Wenn man sich aber auf die agile Methodik einlässt und weiß, dass nicht nur die Qualität, sondern alle Ergebnisse nur durch Produktionsprozesse, nicht durch Kontrollen erzielt werden, ist das Ergebnis auch nach traditionellen Maßstäben besser. In gleicher Zeit wird mehr geliefert, der Aufwand ist geringer als er bei „klassischen“ Methoden gewesen wäre. Aber das erfährt man nur, wenn man sich darauf einlässt. 

Erfreulicherweise nimmt die Zahl der Top-Manager, die das verstanden haben, stetig zu. Und damit ergeben sich die Freiräume in der Projektarbeit, an der Effizient der Projektarbeit zu arbeiten und nicht Pläne zu erstellen, die Wissen über die Zukunft vortäuschen, das keiner hat und haben kann. Wenn ich weiß, dass ich nicht weiß, wie genau alles verlaufen wird, bin ich gerüstet, die unvermeidlichen Überraschungen frühzeitig zu erkennen und erfolgreich zu bewältigen. 

Wer meine Gedanken zu der Herausforderung des Planens in IT-Projekten als Podcast hören möchte kommt hier direkt zum Web-Player:

 

 

 

Anatomie eines erfolgreichen Projektes – Die 01:59 Challenge

Am 12. Oktober 2019 schaffte es Eliud Kipchoge, einen Marathon unter 2 Stunden zu laufen.  Um die Dimensionen zu veranschaulichen: er musste dafür knapp 422-mal die 100 m in 17 Sekunden laufen. Das sind 21 km/h, die meisten von uns könnten das höchstens mit dem Fahrrad schaffen.

Um so eine Leistung zu erbringen, braucht es letztlich genetisch determinierte körperliche Voraussetzungen, professionelles Training und mentale Fitness. Eliud Kipchoge hatte 2017 mit zwei anderen Läufern unter speziell dafür optimierten Bedingungen auf der Rennstrecke von Monza eine Zeit von 2:00.25 geschafft. Mit seinem Weltrekord von 2:01.39 im September 2018 in Berlin kam er der 2-Stundenmarke in einem regulären Rennen so nahe wie vor ihm noch kein Läufer. Daher entschied sich Eliud Kipchoge für einen neuerlichen Versuch, die 2-Stunden-Marke zu brechen. Als Termin peilte man Oktober 2019 an. 

Warum ausgerechnet in Wien?

Ursprünglich war London als Austragungsort geplant, wurde aber wegen der instabilen Wetterverhältnisse bald verworfen. Im Juni 2019 fiel die Entscheidung, den Rekordversuch diesmal in Wien durchzuführen. Die Gründe waren vielfältig, das Wetter zu dieser Jahreszeit (Regen, Wind), die Zeitzone, die Unterstützung der Stadt Wien waren einige der wichtigsten Argumente für diese Entscheidung. Mit einer Vorlaufzeit von nur 4 Monaten mussten dafür die notwendigen Voraussetzungen am Austragungsort geschaffen werden. Der Versuch in Monza hatte gezeigt, dass der Erfolg im Bereich des Möglichen lag, aber „Knapp verfehlt ist auch daneben“. Zudem war bekannt, dass es keinen neuerlichen Versuch geben würde, es musste also auf Anhieb klappen.

Der Rekordversuch in Wien fand im Gegensatz zu Monza in der Öffentlichkeit statt. Die Prater Hauptallee in Wien, eine 4,3 km lange, schnurgerade, ebene Strecke mit den Wendepunkten Lusthaus und Praterstern wurde dafür gewählt. Der Start fand auf der Reichsbrücke statt, so wie auch der Vienna City Marathon. Hier die Streckenführung (© VCM – Gerhard Wehr):

Was hier so einfach und logisch aussieht, verursachte doch schon einige der Herausforderungen. Der Straßenbelag der Hauptallee erwies sich teilweise als zu holprig, die Umrundung des Lusthauses als zu eng. Der Praterstern hat eine Senke und ist außerdem ein neuralgischer Verkehrsknotenpunkt, den man nicht so ohne weiteres sperren kann. Das ist aber nur ein kleiner Ausschnitt, die zu bewältigenden Herausforderungen waren vielfältig und oft auch unerwartet. 

So auch die Konfiguration des Laufs: das Führungsfahrzeug mit der Laserprojektion und das umgekehrte V der Pacemaker waren Ergebnis umfangreicher Analysen und Experimente. Einen unmittelbaren Eindruck davon gibt dieses Video. Ich danke Johanna Ettl für diese eindrucksvolle Dokumentation aus nächster Nähe. 

 

Die 01:59 Challenge als Projekt betrachtet

Das war ein Projekt der besonderen Art. Wie wurde dieses geplant und abgewickelt? Was können wir daraus für unsere Projekte lernen? Das ist auch für jene interessant, die mit Marathon nichts am Hut haben. 

 Ich habe dazu einen Artikel im Projektmagazin geschrieben: Die 1:59 Challenge – Anatomie eines erfolgreichen Projekts. Der vollständige Artikel ist nur für Abonnenten zugänglich. Ein Abo kann ich sehr empfehlen, es gibt verschiedene Abo-Modelle.

Wer einen Sonderdruck haben möchte, trägt sich am Ende bitte in meine Mailing-Liste ein und bekommt den Sonderdruck sofort zum Download. 

Lessons learned für die Projektmanagement-Community

Vorweg die Schlussfolgerungen, die ich aus der Analyse dieses außerordentlichen Projektes für uns Projektmanager gezogen habe: 

    • Es ist wichtig, dass der Projektauftraggeber hinter einem Projekt steht und inhaltlich versteht, welche Herausforderungen in einem Projekt zu bewältigen sind.

    • Die Identifikation aller Beteiligten mit dem Projektziel erspart viel an Overhead, sei es im Bereich der Planung, der Projektsteuerung oder des Controllings.

    • Partnerschaftliche Zusammenarbeit von motivierten Profis ist die beste Voraussetzung für Höchstleistungen. Allerdings ist die Kette so stark wie ihr schwächstes Glied. In jedem Teilprojekt steckte das Potenzial, das Gesamtvorhaben zum Scheitern zu bringen.

    • In Abwandlung von Peter Drucker gilt: „Culture eats methodology for breakfast“. Nur durch eine Projektkultur, die auf Höchstleistung ausgerichtet ist, kann ein Ziel, das scheinbar jenseits der Machbarkeitsgrenze liegt, erreicht werden.

    • Alle Projektmanagementleistungen wären wertlos, wenn der zentrale Prozess, hier die Leistung von Eliud Kipchoge – aus welchem Grund auch immer – nicht zustande gekommen wäre.

Das Titelbild hat mir Vienna City Marathon zur Verfügung gestellt.
©  VCM – Michael Gruber. 

Und hier noch eine persönliche Anmerkung, ich war auch hier 😉

Interessiert am vollständigen Artikel? Gerne. Bitte hier eintragen und ein Sonderdruck kommt sofort zum Download.

Und noch ein Nachtrag vom Berlin Marathon am 25. 9. 2022. Er steigert sich weiter, hier die unglaublichen letzten Minuten zum Ziel und das Siegerinterview:

Risikomanagement – Was uns (nicht nur, aber umso deutlicher) die Corona-Krise lehrt

Das Thema Risikomanagement ist in Zeiten der Corona Krise besonders aktuell und relevant. Ich muss allerdings gestehen, dass ich dazu ein sehr ambivalentes Verhältnis habe.

Einerseits halte ich dieses Thema für sehr wichtig, habe mich auch schon mehrmals in diesem Blog mit diesem Thema beschäftigt. Im folgenden Text gibt es dazu Links an der entsprechenden Stelle. Andererseits halte ich das, was ich in Projekten, jedenfalls in meinem Erfahrungsbereich, unter dem Titel Risikomanagement erlebt habe, für verzichtbar und in weiten Teilen für eine Zeitverschwendung.

Risikomanagement – Die Standards

Das Risikomanagement beinhaltet lt. ISO21500 folgende Prozesse:

  • Ermitteln der Risiken
  • Risikobewertung
  • Risikobehandlung
  • Risikocontrolling.

PMI definiert Risikomanagement im PMBOK etwas ausführlicher:

1) Risk Management Planning: Es wird festgelegt, wie das Risikomanagement im konkreten Projekt organisiert wird.

2) Risk Identification: Beim Projektstart und dann als regelmäßig wiederholter Prozess im weiteren Verlauf des Projektes werden Risiken identifiziert. Wie oft und wer daran beteiligt ist, muss im Planungsprozess definiert werden.

3) Qualitative Risk Analysis: Die identifizierten Risiken werden hinsichtlich ihrer Eintrittswahrscheinlichkeit (Probability) und ihrer Auswirkung (Impact) bewertet. So können sie Risikoklassen zugeordnet werden, die Entwicklung der einzelnen Risiken kann im Längsschnitt verfolgt werden.

4) Quantitative Risk Analysis: Eine quantitative Risikoanalyse wird in der Regel nur bei hoch priorisierten Risiken durchgeführt. Es werden idealerweise monetäre Größenordnungen ermittelt. Die Logik ist ähnlich jener, mit der ein Versicherungsunternehmen die Versicherbarkeit eines Risikos und die dafür erforderliche Prämie ermittelt.

5) Risk Response Planning: Geeignete Gegenmaßnahmen werden definiert für den Fall, dass ein Risiko schlagend wird, es also zum Problem wird. Es kann auch entschieden werden, dass ein Risiko in Kauf genommen werden muss, ohne dass man Gegenmaßnahmen mit hinreichender Wirksamkeit definieren kann.

6) Risk Monitoring and Control: Das Risikomanagement ist ein kontinuierlicher Prozess über den gesamten Projektlebenszyklus hinweg. Potenzielle oder eingetretene Risiken sollten laufend idenfiziert und proaktiv auf Grundlage des „Risk Response Planning“ gelöst werden.

Soweit so gut, das sind logische, wenn auch sehr generische Vorgänge. Man kann wenig dagegen sagen, es hat aber auch keinen hohen Erkenntniswert. Ich habe in meiner Praxis regelmäßig erlebt, dass als Ergebnis der Risikoidentifikation eine lange Liste von sehr konkreten, allerdings relativ trivialen Risiken vorlag. Die dazu erarbeiteten Kategorisierungen, Quantifizierungen und Maßnahmenpläne waren von geringer Relevanz für die weitere Projektarbeit. Ich habe auch nie erlebt, dass bei Auftreten von Problemen jemand diese Dokumente zur Hand genommen und daraus die zu setzenden Maßnahmen abgeleitet hätte.

Risikomanagement – die Lehren aus Corona

Was lernen wir aus dem bisherigen Verlauf der Corona Krise für das Risikomanagement? Wenn das Problem groß genug ist, dann ändern sich die Logiken, in denen agiert wird. Der Wiener Stadtrat für Gesundheit Peter Hacker im Interview mit dem Falter sagt das ganz klar: „Es gibt keine Bedienungsanleitung, wie man durch die Krise kommt, sehr wohl aber eine Organisationsfestlegung. In der Krise geht die Organisation weg von der Matrixstruktur hin zu einer in letzter Konsequenz militärischen Ordnung.“

Wir erleben auch, wie die Maastricht-Kriterien ausgesetzt werden. Aus der Budgetdisziplin der deutschen und österreichischen Bundesregierung wird ein: „Koste es, was es wolle“ (oder auch: „Whatever it takes“). Niemand hätte das vorweg in einem „Risk Response Planning“ von den Verantwortlichen schriftlich zugesagt bekommen. Das gilt auch für alle möglichen Maßnahmen, die jetzt gesetzt wurden und noch gesetzt werden. All das zeigt deutlich, wo die Grenzen der Vorausplanung liegen. Das gilt nicht nur in der Politik, sondern auch im Projektmanagement.

Augen zu und durch?

Wir sollten uns bewusst sein, dass die Risiko-Identifikation nur einen beschränkten Ausschnitt der tatsächlich möglichen Herausforderungen abbildet. Das ist kein Zufall, sondern eine Gesetzmäßigkeit. Ein Teil davon ist Verdrängung, als Bürger der Stadt Sigmund Freuds kenne ich mich damit aus.

Tom DeMarco und Timothy Lister haben das in ihrem höchst lesenswerten Buch zum Risikomanagement als allgemeines Phänomen beschrieben: „Leute, die sich auf den Blödsinn einlassen, Risiken zu ignorieren, gehen wählerisch vor. Typischerweise werden all die kleineren Risiken (diejenigen, die sich hoffentlich durch geschicktes Management abfangen lassen) peinlich genau aufgelistet, analysiert und überwacht. Nur die wirklich bösen Risiken werden ignoriert“. Mehr dazu hier.

Es ist allerdings nicht immer und nicht nur ein vermeidbarer Fehler. Die wirklich essentiellen Risiken zeichnen sich ja gerade dadurch aus, dass sie schwer vorhersehbar sind. Wer hätte sich noch vor einem Monat vorstellen können, was in der Welt und insbesondere in Europa passiert und was es  an Maßnahmen gibt, um die Ausbreitung des Corona Virus zu stoppen.

Das richtige Verhältnis von Planung und Improvisation finden

Vor Jahren hat mich Jörg Finsinger, Professor für Finanzwissenschaften in Wien, mit seiner Warnung aufgerüttelt: „Je genauer du geplant hast, umso wuchtiger trifft dich der Zufall“.

Anders formuliert: Eine sehr genaue Planung führt oft dazu, dass man einen Tunnelblick bekommt. Man glaubt, alles vorhergesehen zu haben. In einer Analyse industrieller Großprojekte hat ein norwegisches Autorenteam kritisch angemerkt, dass klassisches Projektmanagement sich zu sehr auf das Einhalten eines Planes reduziert: „Depending on the nature of the strategy, project control may be reduced to the classical perspective which ensures the work scope is either carried out on time and within budget or is expanded to include requirements related to operability and business value“. Mehr dazu und die Quelle in einem anderen Blogbeitrag hier.

Es ist bemerkenswert, dass die Standish Group, deren Chaos-Report seit 1994 jährlich die Erfolgs- bzw. Misserfolgsquote von IT-Projekten darstellt, ihre Kriterien des Scheiterns 2015 angepasst hat. Die Kriterien OnBudget, OnTime und OnTarget wurden ersetzt durch Valuable, OnGoal und Satifsfactory. Damit sollte vermieden werden, dass Projekte negativ bewertet werden, deren Zielsetzung sich im Verlauf des Projektes weiter entwickelt hat. Das ist bei allen Projekten regelmäßig der Fall. Auch bei kleineren Projekten.

Risikomanagement erfordert Investition in die Leistungsfähigkeit des Teams

Was ist meiner Erfahrung und Meinung nach der entscheidende Ansatz für ein wirksames Risikomanagement? Es geht darum, die Leistungsfähigkeit des Projektes, des Projektteams, der Projektorganisation beim Umgang mit Risiken und Problemen zu erhöhen. Je mehr Reserven es in einem Projekt gibt, umso mehr Risiken kann man abfangen, umso mehr Probleme kann man lösen.

Risikoregister sind etwas Statisches, sie schreiben das Wissen über die Risiken zu jeweils einem Zeitpunkt. Es geht aber darum, die Prozesse und Ressourcen eines Projektes so zu optimieren, das Risiken möglichst nicht schlagend werden. Wenn doch, dann muss die Fähigkeit gegeben sein, die Probleme zu lösen. Entscheidend dafür sind die Soft-Facts, insgesamt also die Projektkultur.  Wenn schon in der laufenden Arbeit eines Projektes Konflikte auf der Tagesordnung stehen, wenn eine Kultur der Schuldzuweisung, des Abwälzens von Verantwortung etc. etabliert ist, wird dieses Projekt bei tatsächlich auftretenden Problemen früh einknicken. Umgekehrt: Je  positiver die Projektkultur ausgeprägt ist im Sinne einer Hochleistungsorganisation, umso mehr wird dieses Projekt schaffen und überstehen.

Erfolgsfaktor Stakeholdermanagement

Andererseits muss uns klar sein: Es gibt für jedes auch noch so leistungsfähige Projekt eine Grenze der Belastbarkeit. Man kann diese nicht unendlich erhöhen. Wenn diese Grenze überschritten wird, kommt es darauf an, wie gut das Stakeholder Management  funktioniert hat. Sind die entscheidenden Stakeholder bereit und in der Lage, auf unvorhergesehene Situationen rasch und kompetent zu reagieren?

Risikomanagement muss ein dynamischer Prozess sein. Es kann nicht eine Bestandsaufnahme in Form von Listen sein. Es muss dort ansetzen, wo  tatsächlich im Projekt gearbeitet und entschieden wird.

Risikomanagement in agilen Projekten

Interessant ist, dass im Reference Guide von SAFe  das Stichwort Risikomanagement zwar vorkommt, dort jedoch am ausführlichsten mit dem Thema „Agile Kontrakte“ verbunden ist. Dort wird eine gemeinsame Übernahme der Risikobewältigung als Vertragsgrundlage vorgeschlagen. Vor dem Versuch, Risiken auf einen der Projektbeteiligten abzuwälzen, wird gewarnt. Das kann man als generelle Empfehlung sehen.

In der Projektarbeit ist im Modell von SAFe die Einschätzung von Risiken ein Teil des PI-Plannings. Dort  müssen von jedem Teilnehmer in einer bestimmten Phase des Workshops die Risiken genannt werden, die das Erreichen der Ziele gefährden könnten. Allerdings nennen hier jene die Risiken, die auch für deren Bewältigung verantwortlich sein werden. Und es ist ein interaktiver Prozess, keine Auflistung. Das Ergebnis dieses Arbeitsschrittes ist eine eventuelle Anpassung der Planung, so dass am Ende alle der Meinung sind, man könne unter den gegebenen Umständen die definierten Ziele tatsächlich erreichen.

Mein Resümée

Insgesamt lernen wir also aus den aktuellen Erfahrungen einer weltweiten Krisensituation, dass es auf Faktoren wie Leistungsfähigkeit, Organisationskultur und Resilienz ankommt. Risikolisten und vorweg definierte Maßnahmen zur Bewältigung dieser Risiken helfen in der akuten Problemsituation wenig. Diese zu erstellen ist allerdings ein durchaus sinnvolles Element zum Aufbau einer krisenresistenten Projektkultur. Auch hier gilt: Der Weg ist das Ziel.

In einem aktuellen Podcast habe ich einige meiner Projekterfahrungen zum Thema Risikomanagement aufgearbeitet.

Agilität beginnt im Kopf – das Mindset ist entscheidend!

Das Cartoon von Scott Adams bringt die lange Zeit gängigen Vorurteile über agiles Projektmanagement großartig auf den Punkt. Man arbeitet einfach drauf los und ansonsten muss man nichts wissen. Heute ist in der Projektmanagement-Community schon längst klar, das agile Methoden des Projektmanagements ein umfassendes Regelwerk beinhalten.

Es geht unter Profis nur noch um das WIE, nicht mehr um das OB. Dass agile Methoden gerade in großen Projekten eine noch größere Hebelwirkung als Erfolgsfaktor haben, hat die Standish Group empirisch belegt. Die Erfolgsrate von agilen Projekten ist deutlich höher als jene von Projekten nach dem „klassischen“ Paradigma (kurz meist „Wasserfallmodell“ genannt). 

Kürzlich wurde ich eingeladen, die mentalen Voraussetzungen für erfolgreiche agile Projekte darzustellen. Als gelernter Psychologe, der ja Technik und Projektmanagement erst im zweiten Bildungsweg erlernt hat, sah ich das als eine Herausforderung, der ich mich gerne stellte.

Ich habe 5 Elemente des agilen Mindsets beschrieben, die mir wichtig scheinen. Es sind dies:

  1. Wir wollen begeisterte Anwender
  2. Wir übernehmen Verantwortung
  3. Pläne sind Hypothesen
  4. Das Missverständnis ist der Normalzustand
  5. Wir müssen liefern.

Nachfolgend zu jedem Element ein Bild mit einer erläuternden Tonspur dazu.

 
 

Prinzipien agiler Projektarbeit habe ich in diesem Blogpost vorgestellt und gegen den Vorwurf der Beliebigkeit habe ich hier argumentiert.

Die Details zu den Ergebnissen der Standish Group gibt es hier.

DILBERT © 2007 Scott Adams. Used By permission of ANDREWS MCMEEL SYNDICATION. All rights reserved.

Podcast: Play in new window | Download

Ergebnisverantwortung in agilen Projekten – wer trägt diese?

Folgender Satz stand im Angebot eines renommierten IT-Unternehmens: „Dem agilen Vorgehen folgend tragen wir keine Ergebnisverantwortung“. Heißt das also: Agile Projekte übernehmen keine Verantwortung für das Ergebnis und damit für den Erfolg eines Projektes? Ich dachte, Scott Adams hätte es ironisch gemeint, als er agil mit „no more planning, no more documentation. Just start writing code and complaining“ beschrieb? Wurde wieder einmal die Satire von der Realität übertroffen?

Nun wäre es unseriös, einen einzigen Satz aus dem Zusammenhang zu lösen und darauf eine Polemik aufzubauen. Also blicken wir etwas tiefer, wie das gemeint sein kann und was davon einer ernsthaften Prüfung standhält.

Ursprung ist wohl die richtige Aussage, dass bei agilen Projekten der Leistungsumfang nicht im gleichen Detaillierungsgrad festgelegt wird wie bei klassischen Projektverträgen, die im Kern einen Werkvertrag beinhalten. Mein Kollege Philip Weihs und ich haben das in einem Vortrag für Juristen in einer Grafik so dargestellt.

Magisches Dreieck des Projektmanagements: agil und traditionell. Unterschiedliche Punkte sind fix

Allerdings war das nicht als Abschied von jedweder Ergebnisverantwortung Erfolg gemeint, wir wollten nur klarstellen, dass es unterschiedliche Prioritäten bei der Fixierung von Parametern gibt, je nach Vorgehensmodell. Als Kriterium des Projekterfolges sehen wir alle drei Parameter des „magischen Dreiecks“, insofern beinhaltet Erfolgsverantwortung mehrere Dimensionen.

Richtig ist, dass agile Projekte von Beginn an eingestehen, dass nicht alles im Voraus bekannt und fixiert ist. Dazu habe ich in einem anderen Beitrag schon ausführlich Stellung genommen.

Was ist an der zitierten Aussage also richtig? Was ist in einem IT-Projekt zu entscheiden und zu gestalten, um erfolgreich zu sein? Hier die wichtigsten Faktoren, die Gegenstand einer Planung sind, an denen auch der Erfolg des Projektes gemessen wird.

Warum – „Business Case“

Was – „Scope“

  • Welche Geschäftsprozesse sollen in welchem Ausmaß unterstützt werden?
  • Welche Teile des Anwendungsportfolios sollen abgelöst werden?

Wann – „Roadmap“

  • In wie vielen Etappen wird das Gesamtvorhaben umgesetzt?
  • Gibt es Teilproduktivsetzungen oder eine Big-Bang-Umstellung?

Wie – „Funktionalität“

  • User Interface Design
  • Benutzerführung (Style Guide, Behavior Guide)
  • Automatisierungsgrad von Teilprozessen (Workflow, Geschäftsregeln, Algorithmen …)

Womit – „Technologie“

  • Standard-Software und/oder Individualentwicklung
  • Java, .NET …
  • Mobility, Apps …

Wenn ein IT-Unternehmen einem Kunden ein Angebot macht, so nimmt der Einfluss und damit die Ergebnisverantwortung vonseiten des Kunden von oben nach unten ab, der Einfluss des IT-Unternehmens umgekehrt zu. Erfolg ist daran zu messen, dass in allen Bereichen ein zufriedenstellendes Ergebnis erzielt wird. Dafür müssen die Planungsvorgaben und die Arbeitsergebnisse so sein, dass das Projektergebnis insgesamt den Zweck erfüllt, für den das Projekt gestartet wurde.

Die Standish Group misst den Erfolg von IT-Projekten an den Kriterien „OnTime“, „OnBudget“ und „Satifactory“. Und nun genau zu unserer Ausgangsfrage: „This means the project was resolved within a reasonable estimated time, stayed within budget, and delivered customer and user satisfaction regardless of the original scope“ (Chaos Report 2015,  Hervorhebung von mir).

Wir sehen also, dass die Variabilität des Scope in agilen Projekten genau dazu dient, den Erfolg sicherzustellen. Denn je größer und wichtiger das Projekt für ein Unternehmen ist, umso größer die Wahrscheinlichkeit, dass sich wesentliche Rahmenbedingungen während des Projektverlaufes ändern und daher eine Änderung des ursprünglichen Scope notwendig ist, um das eigentliche Projektziel zu erreichen. Natürlich ist damit nicht gemeint, dass eine Scopeänderung „passiert“, also die Folge einer Fehlentwicklung der Projektarbeit ist. Es geht hier um bewusste Reaktionen auf geänderte Voraussetzungen oder um neue Erkenntnisse, wie die Projektziele besser zu erreichen wären als durch das strikte Festhalten am ursprünglichen Scope. Daran zeigt sich auch, dass Werkverträge für große IT-Projekte nicht nur für den Auftragnehmer ungünstig sind, sondern auch für den Auftraggeber. In Wirklichkeit sogar besonders ungünstig für den Auftraggeber, denn die Fesseln, die man einem Projekt angelegt hat, binden auch den Kunden. Er bekommt zuverlässig etwas geliefert, was er so nicht gebrauchen kann, nur weil man gegen jegliche Änderung hohe Hürden (aufwändige und träge Change-Request-Verfahren) errichtet hat.

Der Satz, den ich anfangs zitiert habe, müsste also so lauten: „Um unseren Teil der Ergebnisverantwortung wahrzunehmen, haben wir ein agiles Vorgehen gewählt. Wir sind aufgrund unserer Erfahrungen mit vergleichbaren Projekten davon überzeugt, dass wir auf diese Weise durch professionelle und vertrauensvolle Zusammenarbeit aller am Projekt Beteiligten den von Ihnen gewünschten Erfolg erzielen werden.“

Aber das klingt vielleicht zu kompliziert für die Ohren der Rechtsabteilungen auf beiden Seiten? Kann sein. Dazu mehr in einem anderen Beitrag.

Diese und andere Fragen, die zwischen Erfolg und Misserfolg eines IT-Projektes entscheiden, behandle ich in meinem Buch „12 Halbwahrheiten über IT-Projekte„.

Disciplined Agile – Ein Standard, der wirklich unterstützt!

Es gibt seit Jahrzehnten etablierte Standards für das Projektmanagement. Weltweit führend ist PMI (Project Management Institute), vor allem in der DACH-Region führt IPMA (International Project Management Association). In Großbritannien und einigen anderen Ländern dominiert PRINCE2 (Projects in Controlled Environments). Seit 2012 gibt es auch die international gültige ISO 21500, die sich weitgehend am Prozessmodell von PMI orientiert. Für IT-Projekte gibt es spezielle Standards, so wie den SWEBOK (Software Engineering Body of Knowledge) der IEEE oder das V-Modell XT der deutschen Bundesregierung.

Standards für agiles Projektmanagement

Agile Entwicklung folgt ebenfalls Standards. Dominierend ist derzeit Scrum für einzelne Projekte und SAFe für das Projektportfolio eines Unternehmens. Auch hier werden Begriffe und Standardprozesse einheitlich definiert.

Es gibt eine Reihe von Standards für die Abwicklung agiler IT-Projekte von PMI, IPMA und dem Agile Business Consortium (vormals DSDM). Scrum, Kanban und Extreme Programming erheben nicht den Anspruch, die Aufgaben des Projektmanagements vollständig abzudecken, sondern bieten methodische Anleitungen für die Abwicklung der Produktionsprozesse in Projekten. Kanban gilt nicht nur für IT-Projekte und kann auch in Linienorganisationen eingesetzt werden.

Scrum ist die gängigste und jedenfalls bekannteste Methode, um Software agil zu entwickeln.

SAFe zeichnet sich dadurch aus, dass es die Projektabwicklung vom Projektportfolio-Management über das Programm- bis hin zum Projekt- und Teammanagement in einem Standard zusammenfasst. In der Detailarbeit wird vor allem auf Scrum und XP (Extreme Programming) verwiesen. SAFe steht zwar in Konkurrenz zu anderen agilen Frameworks (zum Beispiel LESS: Large Scale Scrum), hat aber mittlerweile eine große Fangemeinde und wird professionell vermarktet.

Welchen Nutzen bringen Standards?

Welchen Nutzen ein Standard bringt, ist eine Frage der Handhabung. Standards verleiten vor allem unerfahrene oder aus anderen Gründen ängstliche Projektmitarbeiter dazu, das eigenständige Denken zu vernachlässigen. Oft genug achten zentrale Instanzen – etwa ein Project Management Office – darauf, dass bei der Projektumsetzung die vorgegebenen Normen genau eingehalten werden.

Wenn Standards als Vorgaben verstanden werden, die immer vollständig und ohne Abweichungen umzusetzen sind, vergeuden Unternehmen regelmäßig Aufwand für Themen, die in diesem Projekt irrelevant sind. Gleichzeitig besteht die Gefahr, die gerade in diesem Projekt wirklich kritischen Themen zu übersehen. PMI und PRINCE2 stellen zwar deutlich klar, dass in jedem Projekt eine individuelle Selektion entsprechend den konkreten Gegebenheiten zu erfolgen hat. Das wird aber in der Hitze des Gefechts leider oft übersehen.

Projektmanagement-Standards adressieren die für alle Projekte geltenden Herausforderungen und Lösungsansätze. Das liegt in der Natur solcher Standards und ist ihnen nicht vorzuwerfen. Jedes Projekt hat allerdings einen spezifischen Inhalt: die Errichtung eines Gebäudes, die Entwicklung und/oder Anpassung von Software, die Reorganisation eines Unternehmens oder die Einführung eines Produktes am Markt. Der Inhalt ist entscheidend: „Content is King!“

„Disciplined Agile“ ist ein umfassender Werkzeugkasten

PMI bietet unter dem Titel „Disciplined Agile“ (DA) ein Modell an, mit dem man agile Projektmanagement-Prozesse an die spezifische Situation eines Projektes anpassen kann. Im Gegensatz zu normativen Modellen wie SAFe oder Scrum ist DA ein Werkzeugkasten. Von der jeweiligen Ist-Situation ausgehend wird der beste Weg zu einer agilen Arbeitsweise („Way of Working“ – kurz WoW) in Projekten gesucht. Konformität zu SAFe ist ein mögliches Ergebnis dieses Prozesses, nicht jedoch eine Vorgabe und auch nicht der Endpunkt der Entwicklung, da es um einen kontinuierlichen Verbesserungsprozess („Guided Continuous Improvement“) geht. Meiner Meinung nach der beste Zugang zu diesem Thema, in Europa allerdings noch wenig bekannt.

Nun wollte ich das genau wissen und habe daher die Zertifizierung zum Disciplined Agile Senior Scrum Master (DASSM)  absolviert. Dazu gehört ein Test und der Nachweis von einschlägigen Erfahrungen in agilen Projekten. Es ist ein nennenswerter Aufwand, aber er lohnt sich, das kann ich nun aus eigener Erfahrung berichten. Ob diese Zertifizierung bei öffentlichen Ausschreibungen anerkannt wird, weiß ich  nicht. Dafür habe ich einige klassische Projektmanagement-Zertifizierungen aufzuweisen.

Hier noch das zentrale Buch zu „Disciplined Agile“. Dieses zu lesen lohnt sich sehr, habe ich vorher getan und dann beschlossen, das gleich zu vertiefen und die Zertifizierung zu machen. Ist auch der Prüfungsstoff, also auch in dieser Hinsicht kein verlorener Aufwand.

Die Analyse der Marktanteile agiler Frameworks lt. Gartner Report (Published 9 February 2021 – ID G00734564) zeigt allerdings, dass Disciplined Agile noch viel aufzuholen hat. Das populärste Framework ist SAFe, gefolgt von Scrum-of-Scrum-Varianten. Das ist wichtig zu wissen, ändert aber nicht meine Bewertung und meine Empfehlung zugunsten von Disciplined Agile.

Die Heisenberg’sche Unschärferelation gilt auch für Aufwandsschätzungen in IT-Projekten

Was hat Physik mit Aufwandsschätzungen in IT-Projekten zu tun? Wieder so ein absurder Vergleich, um Leser anzulocken? Ja, natürlich soll der Titel Neugier wecken, aber es gibt wirklich eine starke Analogie, die für die Praxis nützlich ist.

Zunächst die Unschärferelation im Original: Zwei komplementäre Eigenschaften eines Teilchens sind nicht gleichzeitig beliebig genau bestimmbar. Die Unschärferelation ist nicht die Folge technisch unzulänglicher Messverfahren und damit tendenziell behebbar, sondern sie ist prinzipieller Natur. Anders formuliert: die Messung des Impulses eines Teilchens ist zwangsläufig mit einer Störung seines Ortes verbunden, und umgekehrt. Andere Eigenschaften, die hier betroffen sein können, sind z.B. Energie und Zeit.

Ein IT-Projekt ist – wie jedes Projekt – durch Ergebnis, Budget und Termin definiert. Manchmal wird dieses „magische Dreieck“ noch durch andere Parameter ergänzt, so z.B. Qualität. Meiner Meinung nach bringen solche Erweiterungen keinen Zusatznutzen, die angeführte Qualität ist z.B. ein Aspekt des Ergebnisses. Auch die Standish Group definiert den Erfolg eines Projektes durch die drei Parameter OnTime, OnBudget und OnTarget. Seit 2015 wurde OnTarget durch “with a satisfactory result“ ersetzt. Damit sollte der Kundennutzen in den Vordergrund gestellt werden; immer häufiger kann dieser nur durch Änderungen der ursprünglichen Ergebnisdefinition während des Projektes gesteigert werden. Die Standish Group zeigt überzeugend auf, dass agile Vorgehensmodelle deutlich erfolgreicher sind als traditionelle, starre Vorgangsweisen. Dazu habe ich schon vor einiger Zeit einen Blogbeitrag verfasst, daher müssen wir hier nicht näher darauf eingehen.

Die funktionalen Anforderungen bestimmen nur einen kleinen Teil des Projektaufwandes

Alle gängigen Methoden der Aufwandsschätzung stellen den Software-Entwicklungsaufwand in den Mittelpunkt und leiten diesen aus den funktionalen Anforderungen ab. Das gilt für klassische Methoden wie Function Point oder COCOMO ebenso wie für agile Ansätze mit Story Points. Die funktionalen Anforderungen bestimmen allerdings nur einen relativ kleinen Teil des Aufwandes.

Tom DeMarco, auch zu diesem Thema eine hervorragende Quelle für sinnvolle Vorgehensweisen, fordert ein Kostenmodell, das man Aufwandsschätzungen zugrunde legt. Dieses Kostenmodell ist ständig weiterzuentwickeln. Ihm liegt eine Struktur zugrunde, welche Faktoren wie und mit welcher Gewichtung in die Ermittlung des voraussichtlichen Aufwandes einfließen. Was sind solche Faktoren? Hier eine Liste aus meiner praktischen Erfahrung, trotz ihres Umfanges ohne Anspruch auf Vollständigkeit:

  • Die funktionalen Anforderungen der Anwender
  • Der Funktionsumfang verfügbarer Standard‑Software
  • Der Mix von Standardsoftware, Re-Use vorhandener Software und Individualentwicklung
  • Die Architektur der eingesetzten Standard‑Software oder die Architektur der eigenentwickelten Lösung
  • Die Produktivität der eingesetzten Entwicklungsplattform inkl. der dort verfügbaren Re-Use-Möglichkeiten externer und interner Software-Komponenten
  • Die nicht‑funktionalen Anforderungen, wie zum Beispiel Safety, Security, Performance und Usability
  • Die Qualität der Projektabwicklung (zum Beispiel angemessene Granularität der Planung, Projektleitung und Projektcontrolling)
  • Die Verfügbarkeit (Zeitpunkt, Ausmaß und Konstanz) geeigneter Personen für die zu besetzenden Projektfunktionen
  • Die Qualifikation der tatsächlich an der Projektarbeit beteiligten Personen (insbesondere Auftraggeber, Projektleiter, Geschäftsprozessanalytiker, Softwareentwickler, Tester)
  • Die Effizienz der Zusammenarbeit im Projekt, die Projektkultur insgesamt
  • Die Mikroorganisation der Projektarbeit (zum Beispiel Priorisierung, Vermeiden von Multitasking, Termindisziplin, Urlaubsplanung)
  • Nicht vorhersehbare Einflüsse aus dem Bereich der Produktlieferanten und externen Dienstleister
  • Die Vielfalt und Komplexität der Voraussetzungen für den Rollout, zum Beispiel in verschiedenen Unternehmen eines weltweit agierenden Konzerns oder auch nur in verschiedenen Abteilungen eines Unternehmens
  • Die Motivation und der Skill-Level der Anwender hinsichtlich ihrer Mitwirkung in allen Projektphasen (von der Erstellung des Business-Case über die Anforderungsanalyse bis zum Rollout).

Wie in der Quantenphysik gilt auch hier, dass es unmöglich ist, alle Parameter exakt zu bestimmen. Sie beeinflussen einander in einer nicht im Voraus bestimmbaren Weise. Wie bei der Unschärferelation handelt es sich auch hier nicht um einen Mangel der Schätz- und Messverfahren, sondern um eine prinzipielle Unmöglichkeit.

Die Lösung: Den Aufwand nicht schätzen, sondern managen

Der Abschied von klassischen Vorgehensmodellen ist nicht mehr aufzuhalten. Die negativen Erfahrungen mit Versuchen, alle drei Zielgrößen eines IT-Projektes im Voraus immer genauer zu bestimmen, zwingen zu einer völligen Abkehr von diesem Ansatz. Mit Paul Watzlawick: „Mehr desselben“ ist nicht die Lösung, damit vergrößert man das Problem.

Allerdings braucht man beim Start eines Projektes eine Größenordnung des erforderlichen Aufwandes, anders wäre der Business Case nicht berechenbar. Ebenso muss man das Staffing des Projektes am voraussichtlichen Aufwand ausrichten, wenn man mit zu kleinen Teams startet, kann in späteren Phasen eines Projektes nur noch mit Terminverschiebungen und Scope-Reduktion reagiert werden. Oft reduzieren solche Abweichungen aber den Wert des Projektergebnisses in einem nicht akzeptablen Ausmaß.

Ganz ohne Aufwandschätzung geht es also nicht. Aber analytische Methoden der Aufwandschätzung führen zu keinem brauchbaren Ergebnis. Man muss sich mit Expertenschätzungen und Benchmarks von vergleichbaren Projekten begnügen. Diese Schätzungen müssen mit ausreichenden Risikozuschlägen versehen werden und der Business Case muss auch diese Worst Case Szenarien vertragen. Das sind unerfreuliche Botschaften für die Projektauftraggeber, aber leider steht jedes andere Versprechen auf tönernen Füßen.

Das Vorgehensmodell macht den Unterschied

Der wirksamste Hebel für die Minimierung des Aufwandes in Relation zum erzielten Ergebnis ist die Art der Projektabwicklung. Dazu ein Fallbeispiel der Standish Group. Es wurden zwei gleichartige Projekte, die mit dem gleichen Budget gestartet wurden, miteinander verglichen. Das eine Projekt wurde „agil“ abgewickelt, das andere „klassisch“. Das agile Projekt endete mit einem Budget von 12,5 Mio, das klassische Projekt verbrauchte 45 Mio. Welche Aufwandsarten waren für diesen dramatischen Unterschied verantwortlich?

Der Aufwand für Projektmanagement unterschied sich in absoluten Zahlen um den Faktor 12 (13 % von 45 Mio sind 5,9 Mio, 4 % von 12,5 Mio sind 0,5 Mio). Der absolute Aufwand für die Software-Entwicklung unterscheidet sich hingegen nur um den Faktor 2 (15 % von 45 Mio sind 6,6 Mio, 25 % von 12,5 Mio sind 3,1 Mio). Man sieht also, dass vor allem die Overhead-Kosten in einem „klassischen“ Projekt dramatisch höher sind als in einem agilen Projekt.

Mit einer agilen Projektabwicklung muss allerdings auch eine Abkehr von klassischen Budgetierungsmethoden verbunden sein. Das Herunterbrechen des Scope auf Arbeitspakete wird nicht treffsicherer, wenn die Arbeitspakete nun Epics, Features und User Stories heißen. Es sind nach wie vor die funktionalen Anforderungen, eventuell auch nicht-funktionale Anforderungen, die dort abgebildet sind. Das ist, wie oben gezeigt, nur ein kleiner Teil der bestimmenden Faktoren für den Aufwand. Jeder Versuch, dieser Begrenztheit des Wissens auszuweichen, ist zum Scheitern verurteilt; wir verweisen wieder auf Heisenberg.

Daher braucht man ein grundsätzlich anderes Vorgehen. Ich kenne derzeit kein besseres Modell als „Beyond Budgeting“. In meinem Buch „12 Halbwahrheiten über IT-Projekte“ habe ich das ausführlich beschrieben.

Bei amazon gibt es das Buch als Kindle, Paperback (Softcover, schwarz-weiß) und als Premium-Ausgabe (Hardcover, durchgängig 4-Farbendruck).  Die Premium-Ausgabe gibt es auch im Buchhandel.