Der Chaos-Report der Standish Group berichtet regelmäßig über den hohen Anteil an IT-Projekten, die ihre Ziele nur mit großen Abweichungen erreichen und solchen, die überhaupt scheitern. Wie immer man die Kriterien definiert und wie zutreffend die Zahlen auch sein mögen, dass IT-Projekte sehr oft mit erheblichen Schwierigkeiten zu kämpfen haben und ihren Auftraggebern ebenso erhebliche Probleme bereiten, ist unbestritten.
Die Ursachen dafür sind vielfältig. Ich habe schon mehrfach gezeigt, dass vertragliche Regelungen entscheidend zum Gelingen oder Scheitern von Projekten beitragen können. Hier ein umfassender Beitrag dazu mit einigen weiterführenden Links.Wesentliche Faktoren laut Standish Group sind die Projektgröße und die Vorgehensmethodik, ein grundlegender Faktor die sogenannte „Decision Latency“ (Dauer und Aufwand für Entscheidungen sind der Bedeutung der Entscheidung angepasst).
Heute möchte ich mich nicht mit den Ursachen des Scheiterns befassen, sondern mit der Art des Umganges mit Problemen der Projektabwicklung.
Es gibt keine Probleme, nur Herausforderungen
Dieser Satz sollte in jedem Bullshit Bingo einen Sonderpunkt einbringen. Denn es gibt im wirklichen Leben sehr wohl Probleme und es gilt der geniale Satz von Forrest Gump: „Shit happens“.
Ja, es ist natürlich wichtig und richtig, Probleme (auch) als Herausforderungen zu betrachten. Aber dazu muss man Probleme als solche benennen, analysieren und auf dieser Grundlage lösen.
Das Wort „Problem“ zu tabuisieren erinnert mich an das Neusprech („Newspeak“) in Orwells 1984. Wenn etwas sehr schlecht ist, dann ist es „Doppelplusungut“. Diese Sprache wurde von der totalitären Regierung entwickelt, um den gedanklichen Spielraum der Bürger zu beschränken und den Ausdruck von Kritik im Keim zu ersticken. Das funktioniert, schon 1921 hat Ludwig Wittgenstein festgestellt: „Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.“
Also meine erste dringende Empfehlung: Akzeptiere, dass es Probleme gibt und fürchte dich nicht davor, diese offen als solche anzusprechen. Positives Denken ist nicht Schönfärberei, sondern mutiger Umgang mit Problemen.
Es gibt kein Richtig und Falsch
Immer wieder höre und lese ich diesen Satz. Doch ist dieser Kalenderspruch wirklich ein nützlicher Rat?
Also zunächst ist diese Behauptung einfach falsch. Ich bringe ein krasses Beispiel: Ich gehe ins Krankenhaus wegen eines Meniskusproblems im linken Knie. Als ich aufwache, stelle ich fest, dass mein rechtes Knie operiert wurde. Als ich mich darüber beschwere, sagt der Chirurg zu mir: „Es gibt kein Richtig oder Falsch“?
Nun ernsthaft. Es ist gut, bei der Bewertung von Personen, Plänen, Ereignissen etc. vorsichtig zu sein und immer daran zu denken, dass der erste Eindruck täuschen kann und dass auch ich falsch liegen kann. Ich hatte in den Anfängen meiner Berufslaufbahn einen Chef, der Diskussionen sehr oft und sehr schnell mit dem Statement: „Ich weiß wie’s geht!“ abdrehte. Oft hatte er damit objektiv recht, für die Kreativität und Motivation des Teams war das allerdings kein Turbo. In Druck- oder Gefahrensituationen ist es notwendig und berechtigt, die Entscheidungsfindung einer qualifizierten Person zu überlassen, aber solche Situationen sind die Ausnahme.
Ich weiß natürlich, was mit diesem Spruch gemeint ist. Es ist ein Aufruf zu Toleranz, Geduld, Respekt für unterschiedliche Werte etc. Aber man schüttet das Kind mit dem Bade aus, wenn man das auf alle Arten von Entscheidungen ausdehnt. Wenn ich als Product Owner eine Priorisierung treffe, so ist es im Vorhinein nicht erkennbar, ob diese im Sinne der Ziele und Rahmenbedingungen des Projektes optimal war. Aber das heißt nicht, dass es egal ist, wie ich priorisiere.
Die Theory of Constraints (TOC) definiert klare Kriterien, wie ich zu priorisieren habe: Entlaste den Engpass und ordne alle Aktivitäten dem Bedarf der Engpass-Ressource unter. Es ist nicht leicht, diese Kriterien auf Basis der verfügbaren Informationen korrekt umzusetzen, man kann sich irren oder aufgrund unerwarteter Ereignisse entwickelt sich die Situation anders als erwartet. Aber spätestens in der Retrospektive kann ich erkennen, ob meine Entscheidungen dazu beigetragen haben, die Projektziele zu erreichen, also richtig waren oder falsch.
Auch SAFe gibt Regeln zur Priorisierung vor, nämlich WSJF („Weighted Shortest Job First“) gemäß der Formel: WSJF = Cost of Delay / Job Size. Allerdings ist die Ermittlung der Werte nicht trivial. Allein der leichter abzuschätzende Aufwand für die Umsetzung (Job Size) kann bekanntlich oft erheblich von der Schätzung abweichen. Das heißt natürlich nicht, dass ich bei der Festlegung von Prioritäten genauso gut würfeln kann, weil es ja kein Richtig oder Falsch gibt.
Bitte keine Schuldzuweisungen
Zu einem ordentlichen Projektmanagement gehören Lessons Learned. Aber auch schon während der Laufzeit eines Projektes kommt es immer wieder zu Situationen, wo über Probleme (Pardon: Herausforderungen) gesprochen wird. Der Standardsatz jedes Moderators in solchen Meetings ist die Aufforderung, von Schuldzuweisungen abzusehen. Was ist das Problem?
Jedes größere Projekt findet in einem explizit definierten rechtlichen Rahmen statt. In allen Projektverträgen, die ich jemals gesehen habe, kommt das Wort „Verschulden“ nicht nur einmal vor.
Ich nehme ein aktuelles Beispiel aus einer öffentlichen Ausschreibung: „Der Auftraggeber hat Anspruch auf Geltendmachung einer vom Grad des Verschuldens unabhängigen Vertragsstrafe in Höhe von € #####. … Vertragsstrafen können vom Auftraggeber bis zur Klärung des Verschuldens einbehalten werden“. Es wird ganz klar davon ausgegangen, dass es ein Verschulden geben kann und dass dieses unterschiedlich stark ausgeprägt sein kann. Und es wird unterstellt, dass das Verschulden einem Vertragspartner zugewiesen werden kann, ja sogar muss.
Solange die Probleme eines Projektes nicht so groß sind, dass Juristen einbezogen werden, kann man den Verzicht auf Schuldzuweisungen bei gutem Willen aller Beteiligten praktizieren. Hat man es mit großen Risiken und entsprechend großen Unternehmen als Auftragnehmer zu tun, wird dort im Hintergrund immer ein juristisches Monitoring ablaufen, das alles daran setzt, ein Verschulden des Auftragnehmers abzuwehren.
Solange es darum geht, ein Projekt zum Erfolg zu führen, ist der Verzicht auf Aussagen, die eine explizite Schuldzuweisung sind, unabdingbar. Nur so kann man zu einer lösungsorientierten Diskussion kommen; andernfalls würden die Vertreter des Auftragnehmers bestreiten, dass es ein Problem gibt (ach ja, es gibt ja ohnehin keine Probleme, nur Herausforderungen ). Wenn das nicht gelingt, dann würden sie die Ursache der Probleme in von ihnen nicht beeinflussbaren Faktoren verorten oder dem Auftraggeber zuordnen.
Da selten völlig klar ist, wie ein Problem entstanden ist und vor allem, wie es am besten behoben werden kann, wird mit solchen Auseinandersetzungen wertvolle Zeit verbraucht. Es werden ohnehin knappe Ressourcen gebunden und damit wird das Problem größer als es anfangs war. In diesem Sinne ist es richtig, Schuldzuweisungen so lange wie möglich zu unterdrücken. Auch ich mache das, weiß allerdings aus mehrfacher Erfahrung, dass dieses Schutzschild irgendwann brechen kann.
Ist ein Projekt gescheitert und geht es nicht mehr um Lösungsfindung, sondern um Schadensbegrenzung für die beteiligten Unternehmen, wird nur noch in den vertraglich definierten Kategorien des Verschuldens argumentiert und alles unternommen, um dieses dem jeweils anderen Vertragspartner zuzuweisen.
Der Verzicht auf Schuldzuweisungen im Interesse einer lösungsorientierten Projektarbeit ist ein Balanceakt, den man als Projektmanager*in bewältigen muss. Man schafft einen geschützten Raum und verteidigt diesen so lange wie möglich gegen die „feindliche“ rechtliche Umwelt. In agilen Projekten ist diese Herausforderung besonders groß, wenn nämlich der vertragliche Rahmen den Prinzipien agiler Projektarbeit nicht entspricht. Wenn es möglich ist, sollte man also schon bei der Vertragsgestaltung mitwirken, dann kann aus der feindlichen eine förderliche rechtliche Umwelt werden. Das ist der Grund, warum ich mich im Netzwerk agile.agreement engagiere, mehr dazu hier.
Wie geht man mit Fehlleistungen um?
Ich habe den Chatbot von PMIbefragt, wie man in Lessons Learned damit umgehen soll, wenn ein Teammitglied einen groben Fehler gemacht hat, der für den Projektverlauf erhebliche Folgen hatte. Das war die Antwort, der ich absolut zustimmen kann:
Um in den Lessons Learned mit einem groben Fehler eines Teammitglieds umzugehen, der erhebliche Folgen für den Projektverlauf hatte, sollten Sie einen systematischen und konstruktiven Ansatz verfolgen. Hier sind einige Schritte, die Sie berücksichtigen sollten:
- Objektive Analyse: Beginnen Sie mit einer objektiven Analyse des Fehlers. Identifizieren Sie die genauen Umstände und Faktoren, die zu dem Fehler geführt haben, ohne Schuldzuweisungen vorzunehmen.
- Transparente Kommunikation: Besprechen Sie den Fehler offen und ehrlich im Team. Stellen Sie sicher, dass alle Beteiligten die Situation verstehen und die Auswirkungen des Fehlers erkennen.
- Lernmöglichkeiten: Nutzen Sie den Fehler als Lernmöglichkeit. Diskutieren Sie, was anders gemacht werden könnte, um ähnliche Fehler in der Zukunft zu vermeiden.
- Prozessverbesserung: Überprüfen Sie die bestehenden Prozesse und Verfahren. Identifizieren Sie Schwachstellen und implementieren Sie Verbesserungen, um die Wahrscheinlichkeit ähnlicher Fehler zu minimieren.
- Unterstützung und Schulung: Bieten Sie dem betroffenen Teammitglied Unterstützung und Schulung an, um sicherzustellen, dass es die notwendigen Fähigkeiten und Kenntnisse hat, um ähnliche Fehler in der Zukunft zu vermeiden.
- Dokumentation: Dokumentieren Sie den Fehler und die daraus gezogenen Lehren in den Lessons Learned. Dies hilft, das Wissen für zukünftige Projekte zu bewahren und anderen Teammitgliedern zugänglich zu machen.
Was kennzeichnet eine positive Fehlerkultur
Bei einem meiner frühen Beratungsprojekte wurde ich in das soeben eingeführte Qualitätsmanagementsystem des Kunden integriert und musste bzw. durfte an der Mitarbeiterschulung teilnehmen. Das System war das von Crosby & Associates und der Kernsatz dieses Systems lautet: „Lieber gleich richtig“. Mit dem Schlagwort „Null-Fehler“ bzw. „Zero-Defect“ wurde diese Strategie bekannt.
Interessant ist allerdings, dass dieser Ansatz in IT-Projekten aktuell keine Rolle spielt. In mehreren Großprojekten, die ich in verschiedenen Rollen begleitet habe, war eine Bug-Statistik selbstverständlicher Teil des Projektcontrollings. Alle Einwände von Anwendervertretern, dass die Fehlerzahl zu hoch sei, wurden als Zeichen mangelnden Verständnisses für das Wesen von Softwareentwicklung weggewischt. Es gibt keine fehlerfreie Software, das weiß man doch!
Ich lese immer wieder in einem Buch von Tom deMarco, das ich generell sehr empfehlen kann. Das Buch gibt es nur noch antiquarisch, das aber sehr preisgünstig und unkompliziert.
Dort berichtet er von einem Gespräch mit zwei Softwareentwicklern, die vor Jahren ein Programm entwickelt hatten, bei dem kein einziger Fehler gefunden worden war. „Ich fragte einen von ihnen, wie er sich denn diesen phänomenalen Erfolg erklärt, ein Programm ohne jeden Bug schon beim ersten Versuch auszuliefern. Er gab mir folgende Antwort: Ähhh, wir haben gar nicht gewusst, dass Bugs erlaubt sind.“ (a.a.O., S. 333). Und weiter schreibt Tom DeMarco: „Es ist unter Softwareentwicklern allgemein bekannt, dass sie niemals den allerletzten Bug aus einem Programm herausbekommen werden. Bugs werden als traurige Lebensweisheit hingenommen. Wir hoffen, sie eines Tages auszumerzen, können sie aber nie endgültig besiegen. Ich bin mehr und mehr über den Gedanken beunruhigt, dass diese fatalistische Haltung Bugs gegenüber kein produktiver Bestandteil unserer Vorgehensweise ist, wie wir an das Problem herangehen, sondern ein Teil des Problems selbst. Ich glaube, wenn wir damit aufhören, uns selbst einzureden, dass Bugs erlaubt sind, würde es weniger davon geben.“ (ebenda, S. 334).
Ja, Fehler kommen vor, aber es sind Fehler und wir müssen einen Lernprozess in Gang setzen, denselben Fehler nicht zweimal zu machen. Um Missverständnissen vorzubeugen: Es geht überhaupt nicht darum, Leute für Fehler niederzumachen. Aber es kann nicht sein, dass man Fehler verschleiert und schönredet.
Ich bin dafür, die Worte „Fehler“ und „Problem“ sehr wohl zu verwenden. Es hilft allerdings, anstatt von Schuld lieber von “ Verantwortung“ zu sprechen. Das hilft. Wenn man allerdings vor Gericht steht, geht es um Schuld. Dann ist das Projekt aber ohnehin schon gescheitert und unser Beitrag als Projektmanager*in ist nicht mehr gefragt.