Foto: James Sakaguchi - shutterstock.com
Das letzte Jahr war in vielen Unternehmen durch den Umgang mit der Corona-Krise geprägt. Große Teile der Belegschaft wurden sofern möglich ins Home-Office geschickt. Task Forces auf allen Ebenen sorgten dafür, dass der operative Geschäftsbetrieb nicht gefährdet ist. Projekte zur Veränderung und Transformation, sofern diese keinen direkten Corona-Bezug hatten und nicht eh schon "eingefroren" wurden, traten in den Hintergrund. Für einige Projekte hat das katastrophale Folgen: Denn nach der Corona-Krise ist vor der Projekt-Krise (oder man steckt schon mittendrin).
Schieflage im Projekt erkennen
Die erste Hürde, über die gesprungen werden muss, ist die Feststellung und das Eingeständnis, dass ein Projekt überhaupt in Schieflage geraten ist. Gerade durch das dezentrale Arbeiten im Home-Office ist dies oft schon eine Herausforderung. In vielen Projekten herrscht die Angst vor "rot" vor. Projektverantwortliche möchten dem Management zeigen, dass Sie ein Projekt "im Griff haben". Deshalb werden in Statusberichten sehr häufig anstatt "roter" Ampeln gelbe oder sogar grüne Ampelfarben gezeigt. Die Deadline für die Abgabe oder Produktivsetzung von Software liegt schließlich noch in weiter Ferne. Und so lange das Budget nicht aufgebraucht ist, besteht weiter Gestaltungsmöglichkeit. Am besten trifft es die Aussage eine Projektleiters, dessen Projekt in vielen Facetten komplett an die Wand gefahren ist: "Die Ampel ist eigentlich nicht gelb sondern dunkelgelb".
Je schlimmer die Situation desto mehr wird versucht, unter den Teppich zu kehren. Damit wird die Hürde zu "roten Ampeln" immer höher und Meilensteine werden regelmäßig weiter verschoben, um vermeintlich genug Zeit zu gewinnen, die Probleme zu lösen. Leider fließt bald mehr Zeit in Entschuldigungen und Vertuschung als in die Lösungen der sich immer weiter auftürmenden Probleme.
Ein derartiges, sich immer weiter verzögerndes IT-Projekt mit grünen Ampeln kann ganz leicht vom Top-Management falsch interpretiert werden: Das Projektteam ist im Perfektionismus verfangen und traut sich mit dem vermeintlich guten Produkt nicht an den Markt. In bester Absicht "hilft" die Geschäftsleitung nun, in dem sie einen zügigen Go Live erzwingt.
Obwohl das Risiko und auch das ungefähre Ausmaß der aus dem Go Live folgenden Katastrophe absehbar ist, wagt das Projektteam nicht zu widersprechen, denn die ehemals kleine Notlüge ist inzwischen zu groß. In derartigen Konfliktsituationen ist es ein normaler Reflex, Probleme zu verdrängen. "Es wird schon gut gehen" wird zum Mantra und der Vogel Strauß zum heimlichen Projekt-Maskottchen.
- 1. Unklare Arbeitslast
Bryan Fagman vom Anbieter Micro Focus sagt, dass viele Projekte an einem nicht klar umrissenen Arbeitsaufwand scheitern. Schleichen sich hier Unschärfen ein, leidet das ganze Projekt. Im schlimmsten Fall bleibt undefiniert, wann es überhaupt abgeschlossen ist. Fagman mahnt deshalb an, Ziele im Dialog mit den Kunden klar zu benennen. - 2. Undefinierte Erwartungen
Alle Beteiligten müssen von Beginn an wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind – sonst droht ein Fiasko. Tim Garcia, CEO des Providers Apptricity, nennt zwei entscheidende Dinge, die alle Team-Mitglieder vorab wissen sollten: was getan wird und wie man weiß, wann das Projekt abgeschlossen ist. „Ohne eine dokumentierte Vereinbarung, die Antworten auf diese beiden Fragen liefert, ist ein Projekt von Anfang an in Gefahr“, sagt Garcia. - 3. Fehlende Management-Unterstützung
Die Unterstützung aus der Firmenspitze sollte unbedingt gesichert sein. Befindet man sich dahingehend mit der Chef-Etage nicht in Einklang, mindert das die Erfolgsaussichten beträchtlich, meint Brad Clark vom Provider Daptiv. - 4. Methodik nach Schema F
Im Projekt-Management wird gemeinhin mit standardisierten Schlüsselaufgaben und Leistungen gearbeitet. Darin lauert nach Einschätzung von Robert Longley, Consultant beim Beratungshaus Intuaction, aber auch eine Gefahr. Die Standard-Ansätze seien meist auf Projekte einer bestimmten Größe ausgerichtet. Sie passen möglicherweise nicht mehr, wenn man sich an größere Projekte als in der Vergangenheit wagt. - 5. Überlastete Mitarbeiter
„Team-Mitglieder sind keine Maschinen“, sagt Dan Schoenbaum, CEO der Projekt-Management-Firma Teambox. Projekte können auch daran scheitern, dass Mitarbeiter mit Arbeit überfrachtet werden. Vermeiden lässt sich das, indem man sich vorab ein klares Bild über die Stärken der Team-Mitglieder macht und auf eine sinnvolle Verteilung der Aufgaben achtet. - 6. Ungeteiltes Herrschaftswissen
Projekte leben davon, dass Informationen nicht monopolisiert, sondern miteinander geteilt werden. Das geschieht oft dann nicht, wenn Ergebnisse erst nach langer Anlaufzeit geliefert werden müssen. Tim Garcia von Apptricity rät deshalb dazu, Projekt in kurze Phasen einzuteilen. An deren Ende sollte es jeweils Resultate geben, mit denen das ganze Team weiterarbeiten kann. - 7. Unklare Entscheidungsfindung
Im Verlauf eines Projektes sind Änderungen der ursprünglichen Roadmap oft unvermeidbar. Es sollte beim Change Management aber klar dokumentiert werden, wer wann was geändert hat und wie die neue Marschrichtung aussieht. - 8. Fehlende Software
Exel-Spreadsheets nötigen Projekt-Manager zu manuellen Korrekturen und führen oft zu Problemen bei der Status-Aktualisierung. Insofern ist es befreiend, mit Project Management Software zu arbeiten, die für automatische Updates sorgt und von lästigen manuellen Berichten entlastet. Dazu rät Brian Ahearne, CEO des Anbieters Evolphin Software. - 9. Gefahr des Ausuferns
Change Requests sind alltäglich im Projekt-Leben, aber sie haben leider oft einen unerfreulichen Nebeneffekt: den Hang, Fristen und Budget-Rahmen immer weiter auszudehnen und auf Dauer zu Demotivation und Frust auf allen Seiten zu führen. Um dieser Entwicklung Einhalt zu gebieten, sind neben klaren Zielvorgaben auch tägliches Monitoring und ein definierter Prozess für gewünschte Veränderungen sinnvoll. Das empfiehlt in jedem Fall Sandeep Anand, der beim Software-Entwicklungshaus Nagarro für Project Governance verantwortlich ist. - 10. Nicht "Nein" sagen können
Im Sinne des Unternehmens sei es manchmal nötig, Anfragen abzulehnen, sagt Markus Remark vom Provider TOA Technologies. Gut sei es deshalb zu wissen, wie man "nein" sagt. Am besten habe man für solche Fälle auch gleich eine konstruktive alternative Lösung parat. - 11. Mangelnder Zusammenhalt
Projektarbeit ist Team-Arbeit. In der Praxis gerieren sich manche Projekt-Teams aber wie in Eifersüchteleien gefangene Sportmannschaften ohne Erfolg, beobachtet Berater Gordon Veniard. Der Fokus auf das eigentliche Ziel gehe verloren. Stattdessen beschuldigen sich Grüppchen gegenseitig, für Probleme und schlechte Leistungen verantwortlich zu sein. Um das zu verhindern, ist Führung durch den Projekt-Manager gefragt. Und der sollte es verstehen, sein Team mitzunehmen und in Entscheidungen einzubinden. Ohne Kommunikation sei das Desaster programmiert, so Hilary Atkinson vom Provider Force 3. - 12. Vergessener Arbeitsalltag
Hilary Atkinson hat nach noch einen weiteren Kommunikationstipp parat: Projekt-Manager sollten nicht vergessen, ihre alltäglichen Aufgaben zu erledigen. Wer als Verantwortlicher keine Meeting-Termine verkündet, Status-Berichte vergisst und E-Mails unbeantwortet lässt, riskiert unnötige Verzögerungen. - 13. Zu häufige Meetings
Meetings, in denen der Status Quo besprochen wird, können nerven – vor allem dann, wenn sie zu oft stattfinden oder zu lange dauern. Wichtige Informationen lassen sich durch Collaboration Tools häufig besser an die Team-Mitglieder bringen, meint Liz Pearce, CEO des Providers LiquidPlanner. Ihr Tipps: Meeting auf die Entscheidungsfindung beschränken. In ihrem Unternehmen gebe es lediglich zweimal in der Woche ein Treffen, um neue Aufgaben zu verteilen und Prioritäten zu definieren. - 14. Gut genug ist nicht immer gut
Sergio Loewenberg vom IT-Beratungshaus Neoris macht Nachlässigkeiten in der Qualitätssicherung als Problem aus. Es sei günstiger, Fehler zu vermeiden anstatt Geld und Zeit ins Ausmerzen ihrer negativen Folgen stecken zu müssen. Wer auf hohe Qualitäts-Standards achte, vermeide späteres Nacharbeiten und die Gefahr eines schlechten Rufes. - 15. Nicht aus Fehlern lernen
Liz Pearce mahnt außerdem an, mit Hilfe entsprechender Tools eine mehrstündige Analyse nach Ende des Projektes durchzuführen. Nur Teams, die sich des ständigen Lernens verschreiben, seien dazu in der Lage, die Fehler der Vergangenheit in der Zukunft zu vermeiden. - 15 Fehler beim Projektmanagement
Es gibt unzählige Wege, ein IT-Projekt an die Wand zu fahren. Unsere amerikanische Schwesterpublikation CIO.com hat 15 davon gesammelt – und verrät dankenswerterweise auch, wie man die Probleme beheben kann. Diese Tipps sind in der Bilderstrecke zu finden.
Projektkrisen erfolgreich meistern
In vielen Fällen kommt es aber gar nicht erst zum Go Live. Stattdessen "dümpelte" das Projekt in den Sphären der Corona-Pandemie vor sich hin oder wird mit unklarem Zielerreichungsstand gestoppt. Das Motto "Arzt, hilf Dir selbst" funktioniert hier nicht in der Regel nicht mehr - es entsteht ein Bedarf nach objektiver Betrachtung der Situation durch unabhängige Dritte. Sanierungswürdigkeit, Sanierungsfähigkeit sowie ggf. erforderliche Veränderungen unter Berücksichtigung der spezifischen Ursachen müssen eingeschätzt werden. Dabei geht es nicht darum, jemanden den "Schwarzen Peter" zuzuschieben, sondern einen für alle Beteiligten Parteien vertretbaren Weg aus der Situation zu finden.
Für den Fall, dass das Projekt grundsätzlich sanierungswürdig und die mit der Umsetzung verbundenen Ziele nach wie vor angestrebt werden, ist es wichtig hierbei den Blick nach vorne zu richten und den Turnaround hinzubekommen. Jedoch sollte man als Basis für eine Turnaround-Strategie mit Handlungsoptionen trotzdem auch verstehen, was die eigentlichen Ursachen der Symptome sind. Sonst ist die Wahrscheinlichkeit hoch, dass nach dem Neuaufsatz gleich der Wurm bereits im Apfel ist. Auf Basis der Erkenntnisse sind inhaltliche und strategische Handlungsoptionen entlang der kurz- und mittelfristigen Ziele zu erarbeiten und zu bewerten. Für einen Rettungsschirm als Ergebnis eines Reviews empfiehlt sich hierbei ein Vorgehen in vier Schritten:
1. Datensammlung und Dokumentenanalyse
Für eine erste Bestandsaufnahme, müssen sämtliche, während der Projektlaufzeit entstandenen Dokumente gesammelt bereit gestellt werden. Hierzu zählen insbesondere Dokumente die die Projektgovernance, Scope und Planung, ggf. bereits diskutierte Lösungsansätze sowie die Entwicklung des Projekts dokumentieren (Statusberichte, Lenkungsausschussunterlagen, Entscheidungslogs, Eskalationen). Die Beurteilung, was wichtig ist und was nicht, sollte der mit dem Review beauftragten Partei überlassen werden - ansonsten läuft man Gefahr durch einen BIAS die Objektivität einzuschränken.
2. Tiefeninterviews, Software Process Analytics und Ursachenanalyse
Im nächsten Schritt empfiehlt es sich persönliche und vertrauliche Interviews mit Teilnehmern auf allen Hierarchiestufen der beteiligten Parteien zu führen um weitere Informationen zu sammeln. Hierbei sollte kein zu enges Korsett hinsichtlich der Inhalte vorgegeben sein, sondern vielmehr die Interviewees erst einmal frei von ihren Eindrücken berichten können. Hierdurch geben die Befragten häufig Informationen, die mit gezielten Fragen nicht ans Tageslicht gekommen wären.
Erst im zweiten Schritt ist es dann sinnvoll, sich die bereits erarbeiteten Ergebnisse anzusehen. Dies kann auch eine Analyse der bislange entwickelten Software umfassen, um die Situation zu objektivieren und das "Licht" einzuschalten. Digitale Analyseplattformen bilden hierfür die Basis. Zumindest sollten z.B. mit Hilfe von Process Mining die zu Grunde liegenen Softwareprozesse analysiert werden. Qualitative Informationen aus Interviews sowie quantitative Einblicke aus der Ergebnisbetrachtung liefern den Input für die Identifikation der Ursachen, die zur aktuellen Situation geführt haben.
3. Bewertung und Ableitung von Handlungsoptionen
Für das erfahrene Auge eines professionellen Projekt-Reviewers und auf Basis eines die Analyse leitenden Project Review Frameworks ergibt sich aus den erhobenen Informationen ein Muster der Ursachen für die Krise und es kann definiert werden an welchen Stellen es aus Projektmanagement-Sicht anzusetzen gilt. Typischerweise lassen sich diese den folgenden Themenbereichen zuordnen:
Kommunikation und Stakeholdermanagement
Projektziele, -scope und -anforderungen
Projektmanagement und -vorgehen
Projektteam, -ressourcen und -organisation
Projektergebnistypen (Anforderungen, Architektur, Code, Testfälle, …)
Die inhaltlichen Handlungsoptionen ergeben sich in den meisten Fällen auch bereits aus den erhobenen Informationen, denn der grundsätzliche Raum an Lösungsmöglichkeiten ist in der Regel begrenzt und wurde oft bereits eingehend diskutiert. Oftmals fehlt es hier lediglich an einer objektiven und strukturierten Gegenüberstellung zur Bewertung und an einem Ausblick hinsichtlich zeitlicher Planung und Kosten der einzelnen Optionen.
Lesetipp: Stakeholder Projektmanagement - So bringen Sie IT und Fachabteilung unter einen Hut
4. Entwicklung einer Turnaround-Strategie
Liegen die grundsätzlichen inhaltlichen Handlungsoptionen vor, wird im ausgewählten Teilnehmerkreis und moderiert von "außen" entschieden welcher inhaltliche Weg einzuschlagen ist. Hierbei kann es je nach Situation sinnvoll sein, eine vorgelagerte Machbarkeitsstudie zu einer oder auch zu mehreren Optionen durchzuführen, bevor man wieder mit voller Kraft gen Umsetzung und Golive strebt. Hinsichtlich der Ursachenanalyse aus Projektmanagement-Sicht sind in den meisten Fällen personelle Entscheidungen zu treffen. Vor diesem Hintergrund und auf Basis einer gesunden Fehlerkultur sollten entsprechende Maßnahmen diskret und nicht in der "großen Runde" diskutiert und umgesetzt werden. Denn offenes "Bashing" ist nicht nur unschön für die Betroffenen Personen, sondern hilft auch nicht dabei das bereits vorhandene Problem im Nachhinein zu beheben - vielmehr schafft es eine Kultur der Angst bei den verbliebenen oder den neuen Projektmitgliedern und motiviert neu aufkommende Probleme nach Neuaufsatz gleich wieder unter den Teppich zu kehren.
Guter Rat ist nicht teuer
Objektivität und Erfahrung sind wesentliche Erfolgsfaktoren für einen Projektreview denn kritische Projektverläufe lassen die beteiligten Personen nicht unberührt - oftmals herrschen auch gegenteilige Meinungen oder Agenden vor. Daher lohnt es sich das Review durch eine neutrale, möglichst unbeteiligte Partei durchführen zu lassen. Neben einem neutralen Blick zählt hier die Erfahrung in der Sanierung von IT-basierten Projekten. Im Vergleich mit den Kosten des Projekts lohnt sich die Investition. Übrigens: wer proaktiv vorbauen möchten, der lässt gerade bei größeren Projekten und auch bei grünen Ampeln den Zustand durch periodische "Health Checks" überprüfen. Auf diese Weise kann einer Krise frühzeitig vorgebeugt werden. (bw)