Projektmanagement


IT-Projekte

Eine Welle des Scheiterns kündigt sich an

Moritz Iversen ist freier Journalist in München.
Es geht nicht um out of Time und out of Budget: Wir sprechen von spektakulären Misserfolgen, die Lieferketten unterbrechen und Karrieren ausbremsen.
Auch im Jahr 2022 werden viele große IT-Projekte scheitern. CIOs können mit taktischen Maßnahmen gegensteuern.
Auch im Jahr 2022 werden viele große IT-Projekte scheitern. CIOs können mit taktischen Maßnahmen gegensteuern.
Foto: Amanda Carden - shutterstock.com

Cassandra hatte keine Freunde - es war noch nie eine dankbare und beliebte Rolle im Unternehmen, Katastrophen und Misserfolge zu prognostizieren. Daher schreibe ich diesen Bericht in dem vollen Bewusstsein, dass der Inhalt auf taube Ohren stoßen und der potenzielle Nutzen meiner Ratschläge auf dem Stapel "Ich wünschte, wir hätten..." zu finden sein wird. Meine These: Es wird einen Tsunami von Projektkatastrophen geben, der sich schnell auf die Gestade der Unternehmen zubewegt, und es gibt nicht viel, was man tun kann, um ihn aufzuhalten.

Die Art von Projektkatastrophen, von denen ich spreche, sind nicht die normalen Fälle, in denen das Budget überschritten und der Zeitplan gesprengt wird. Vielmehr geht es um die spektakulären Misserfolge, die Lieferketten unterbrechen, die Finanzberichterstattung verzögern und die Karrieren von scheinbar kompetenten Führungskräften zerstören. Die Art von Misserfolgen, die sich einstellen, wenn Unternehmen eine Implementierung in Betrieb nehmen, die sich im Nachhinein als leichtsinnig herausstellt.

Vier Vorboten des Untergangs

Warum bin ich so überzeugt, dass viele ProjekteProjekte auf Kollisionskurs mit dem Scheitern sind? Hier sind vier Anzeichen für die sich anbahnende Katastrophe: Alles zu Projektmanagement auf CIO.de

Das doppelte Volumen. Zwischen Mai und September des vergangenen Jahres wurden doppelt so viele Großprojekte gestartet wie in einem normalen Jahr. Als Covid-19 Anfang 2020 in die Unternehmen einbrach, legten viele Organisationen ihre großen IT-gestützten Transformationsprogramme erst einmal auf Eis. Anfang 2021 brach schließlich der Damm, und große Programme, die 2020 beginnen sollten, wurden aufgenommen. Gleichzeitig haben Unternehmen den Startschuss für ihre 2021 geplanten Programme gegeben. Voilà! Das bedeutet, dass sich die Zahl der potenziellen Projektkatastrophen verdoppelt hat. Da die Zeitspanne für die Erstimplementierung großer Initiativen im Durchschnitt 12 bis 18 Monate beträgt, ist der Tisch für 2022 gedeckt.

Die Aktualitätsverzerrung. Wann haben Sie das letzte Mal von einem gescheiterten Start eines Großprojekts gelesen? US-Projekte wie Select Comfort, National Grid, Cover Oregon oder Los Angeles Department of Water and Power (LADWP) sind seit einigen Jahren aus dem Blickfeld verschwunden - lange genug, um aus dem Gedächtnis der Führungsetage zu verschwinden. Organisatorische Hybris ist eine mächtige Kraft, die oft ein Gegengewicht zur realen Wahrscheinlichkeit von Katastrophen bildet. Wenn es keine Nachrichten über Katastrophen gibt, verblasst die potenzielle Bedrohung. Es gibt einen Grund, warum alle erst einmal vorsichtiger fahren, nachdem sie einen Autounfall gesehen haben.

Die Talentlücken. Fast alle größeren Katastrophen beim Go-Live lassen sich auf mangelnde Erfahrung der leitenden Projektmitarbeiter zurückführen. Die Fähigkeit, Risiken zu erkennen und zu kommunizieren, ist aber von entscheidender Bedeutung, um sie zu mindern. Da sich die Anzahl der Projekte verdoppelt hat, ist die Fähigkeit der Systemintegratoren, hochqualifizierte Mitarbeiter für alle Programme zu finden, stark eingeschränkt worden. In Verbindung mit der "Great Resignation" und der Fluktuationsrate, die sich in den vergangenen sechs Monaten zumindest in den USA verdoppelt hat, wird deutlich, dass das Situationsbewusstsein für diese Programme drastisch gesunken ist.

Unerprobte Methoden. Wir haben gesehen, dass viele Projekte während der Pandemie mit Tests der integrierten Systeme zu kämpfen hatten. Der Grund für die Produktivitätseinbußen liegt oft in der fehlenden räumlichen Zusammenführung der Projektteams. Wenn sie nicht direkt zusammenarbeiten, können Teammitglieder nicht so schnell von ihren Nebenleuten lernen, und Tipps und Tricks werden nicht so leicht weitergegeben. Denken Sie nun an die Zeit nach der Einführung und an die potenziellen Auswirkungen auf Tausende von Nutzern, die möglicherweise nicht die Superuser im Zimmer nebenan haben, die sie durch den Start begleiten. Es gibt keinen Grund zu der Annahme, dass die gleichen Probleme, die wir bei den Tests gesehen haben, nach dem Deployment auf wundersame Weise behoben wären.

Wie lassen sich IT-Katastrophen vermeiden?

Gibt es Möglichkeiten, den Tsunami der Katastrophen zu vermeiden? Die Antwort lautet unter dem Strich leider: Nein, denn die Würfel sind bereits gefallen. Allerdings gibt es taktische Möglichkeiten, die bei einzelnen Programmen eingesetzt werden können, um eine Katastrophe zu verhindern. Hier einige einfache Empfehlungen:

Halten Sie Ihren Rücken frei. Bitten Sie beispielsweise Ihren Systemintegrator, eine Präsentation über die Lessons Learned aus größeren Programmkatastrophen zusammenzustellen. Sie müssen nicht der Bote sein, der erschossen wird. Legen Sie diese Präsentation dem Lenkungsausschuss lieber früher als später vor, um zu zeigen, dass Sie geeignete Maßnahmen zum Schutz des Unternehmens ergreifen.

Legen Sie frühzeitig Startkriterien fest. Zu viele Programme legen die Startkriterien erst zwei bis drei Monate vor dem geplanten Start fest. Wenn dies der Fall ist, lautet das Kriterium: "Was können wir vor dem Go-Live erreichen?" und nicht: "Wo sollten wir sein?". Dies gilt insbesondere für Projekte, die unter Budgetdruck stehen.

Unabhängige Perspektive. Das "Go-Live"- oder "Gipfelfieber" ist real - fragen Sie nur die Familien derer, die beim Versuch, den Gipfel eines Berges zu erklimmen, ums Leben gekommen sind. Ein gutes Urteilsvermögen wird leicht durch Schätzungen versunkener Kosten (die sich nie mehr amortisieren) und unhaltbare Best-Case-Szenario-Planungen getrübt. Eine unabhängige Sichtweise kann sehr ernüchternd wirken.

Dieser Artikel basiert auf einem Beitrag unserer Schwesterpublikation cio.com

Zur Startseite