Zunächst muss ich Sie leider enttäuschen - diese Frage kann niemand vollständig beantworten. Eines haben aber alle Projekte dieser Art gemeinsam - je schneller gehandelt wird, desto höher sind die Erfolgschancen - und desto geringer ist der Verlust.

Einige typische Beispiele:

• Das Projekt ist nur in Teilen wirtschaftlich sinnvoll machbar:
  Technisch geht fast immer alles. Wenn aber Zeit und Geld dabei völlig aus dem Ruder laufen, ist der Turnaround angesagt. 
   

• Die Rahmenbedingungen für das Projekt passen nicht:

  • Unrealistische Zeitvorgaben:
    Beinahe der Normalfall für komplexe Großprojekte. Durch "politische" Streichung von Risikopuffern reicht die Zeit nicht aus.
  • Zu wenig Budget:
    Natürlich auch ein Klassiker, der meistens mit unrealistischen Zeitvorgaben einher geht. Der Hintergrund ist meistens auch "Politik" - Risikobeträge werden gestrichen.

  • Unerfahrene Projektmitarbeiter:
    Ich habe leider mehr als einmal erlebt, dass talentierte aber unerfahrener Projektleiter in kritischen Projekten geradezu "verheizt" wurden. 

  • Muss-Partner: 
    Es kommt vor, dass für Projekte "Muss-Partner" für spezielle Projektleistungen vorgegeben werden. In meiner Praxis ging das fast immer schief.

  • Äußere Zwänge:
    Vielen noch bekannt - das Jahr 2000. Nach meiner Erfahrung wird man mit solchen Zwängen meistens fertig. Warum ? Weil sich alle Beteiligten darauf mit ganzer Kraft und gemeinsamen Konsens konzentrieren.

  • Das Projekt rechnet sich für den Anbieter nicht:
    Da die Projektmarge nicht stimmt, muss der Anbieter Mittel und Wege finden. Das führt zu beliebigen Krisensituationen. Ich habe mal einen interessanten Tipp dazu gehört: "In Ausschreibungen sollte gelten: "Nicht der billigste - sondern der zweit-billigste bekommt den Zuschlag".

  • Das Projekt hat eine zu lange Laufzeit:
    Projekte mit einer Laufzeit von über zwei Jahren sind Premium-Kandidaten für Projektkrisen. Das liegt am immer schneller voranschreitenden Wissensverfall und der zunehmenden Komplexität der IT-Welt. Hier hat der agile Ansatz deutliche Vorteile gegenüber dem klassischen Vorgehen. 

• Konsens der Unwissenden:
  
  Es gibt Projekte, da weiß die halbe Firma, das es so nicht funktionieren kann. Es ist - aus welchen Gründen auch immer - aber oportun nichts zu wissen. Also läuft das Projekt weiter, bis dis Blase platzt. Die besten Informationen zu solchen Projekten findet man nicht im Projektreport, sondern auf dem Flur oder in der Kaffeeküche.
   
• Fata-Morgana-Projekt:
  
  Das habe ich bisher nur einmal erlebt. Ein Projekt, das über 6 Jahre lief und zu keinem Ergebnis kam. Warum ?
  • Weil die Projektmitarbeiter des Anbieters alles taten, um ihren Job in ländlicher Idylle zu erhalten.
  • Weil der Kunde gegenüber seiner Zentrale unbedingt ein Projekt zur Ablösung seiner Alt-Anwendung vorzeigen musste. Ansonsten wäre SAP eingeführt worden. Und an die Alt-Anwendung hatten sich alle gewöhnt.
• Die Anwendung des "Gillette Prinzips":
  
  Da der Projektumfang größerer IT-Projekte  zu Beginn nie völlig klar und eindeutig beschreibbar ist, kalkulieren viele Projektanbieter spätere Änderungen mit ein - oder provozieren diese Änderungen sogar, d.h.:
  • Niedriges initiales Projektangebot gegen den Mitbewerb,
  • Geld wird durch Folgegeschäft (Änderungen - Change Requests)  ohne Mitbewerb verdient.

Dieses Konzept wurde Anfang 1900 als Gillette oder Razor-Blade Model bekannt (billige Rasierer -teuere Rasierklingen). Allerdings muss man feststellen, dass die gängige Ausschreibungspraxis für Projekte mit Orientierung am Tiefstpreis dieses Vorgehen geradezu provoziert.

Jedes Projekt nach dem Gilette Prinzip neigt zur Krise, da der Kunde nicht mit hohen Folgekosten durch Änderungen rechnet, der Anbieter aber davon lebt.

• Das Change- und Transformation Management fehlt:
  
  Wenn ein Projekt vorwiegend technisch - ohne ausreichende Berücksichtigung des geschäftlichen Umfeldes - geplant wird, passiert folgendes:
   

  • Geschäftsprozesse stolpern oder kollabieren - da nicht ausreichend berücksichtigt bzw. angepasst.
  • Der Betrieb der Lösung ist instabil - da zu spät geplant.
  • Die betroffenen Mitarbeiter finden sich nicht wieder - da Sie nicht einbezogen bzw. zu spät informiert wurden.
  • Angrenzende Systeme laufen fehlerhaft - da wichtige Schnittstellen  übersehen wurden.

Change- und Transformation Management erschöpft sich häufig im Training betroffener Mitarbeiter -  das reicht aber nicht.

• Fehlendes Multi-Projektmanagement:
  
  Meistens sind Projekte nicht alleine auf der Welt. Es gibt Abhängigkeiten zu anderen Projekten und Prozessen. Fehlt die Rolle eines Programmmanagers oder zumindest einer Integrationsinstanz, ergeben sich erhebliche Terminprobleme. Oft geht fehlendes Multi-Projektmanagement mit mangelhaftem Transformation Management Hand in Hand.
   

• Sondersituation der Firma oder des Projektumfelds
  
  Befindet sich die Firma oder das Projektumfeld in eine Sondersituation, strahlt das auf betroffenene Projekte aus. Dazu gehören Firmenübernahmen, die zu Konsolidierungsprojekten führen (z.B. Zusammenführung von ERP-Systemen). Solche Projekte sind bereits von der Sache her kompliziert und stehen in der Regel unter besonderen Zwängen (z.B. vorgegebene Endtermine, vorgegebene Kosten, Muß-Anforderungen), die mit den eigenlichen Projektinhalten nichts zu tun haben. 
  Andere Beispiele finden sich bei Mergern, Carve Outs oder der Auflösung von Geschäftsfeldern. Mögliche Projektkrisen wirken dann negativ zurück auf die Sondersituation der Firma.

Hier finden Sie mein Unterstützungsangebot zur Bewältigung von Sondersituationen in Projekten.