Symptome für Projekte die scheitern werden

Im Blog PM Hut gibt es einen interessanten Artikel von Satya Narayan Dash, in dem er einige Symptome beschreibt, wie man erkennen kann, ob ein Projekt zum Scheitern verurteilt ist.

Over 50% of IT projects fail. Most of the time, there are a number of early signs that the project will fail. We will discuss some of the symptoms for a project doomed to fail.

Though the concepts here are in more in sync with IT projects, the applicability of them is universal.

via 11 Signs That Your Project Will Fail – Part I – PM Hut //11 Signs That Your Project Will Fail – Part II – PM Hut .

Es werden folgende 11 Symptome benannt:

  • Es existiert keine echte Projektbeauftragung/-zielsetzung (no project charter): Es ist nicht klar, was die Ziele des Projektes sind und wie/ob das Projekt begonnen hat. Egal, wird fangen trotzdem an und ignorieren die (fehlende) Beauftragung. “Wer hatte eigentlich vor zwei Jahren die (dumme) Idee dieses Projekt zu starten?!”.
  • Keine Unterstützung durch das Top-Management (lack of senior management involvment):  Es interessiert die Entscheidungsträger nicht, was in dem Projekt passiert. In Folge werden Entscheidungen nicht gefällt bzw. verschleppt. Projekt findet sich in einer Sackgasse, es ist nicht klar, wie Projekte zu priorisieren sind. Keiner weiss, was das Top-Management genau will, da dieses nie Zeit investiert dies zu erklären. Ergebnis ist vorprogrammiert.
  • Unerfahrene und/oder überhebliche Projektleiter (unexperienced or ego-driven project managers): Entweder gibt es keine formale (und gute) Ausbildung oder die Projektleiter sind ob dieser Ausbildung überheblich. Oder die Person des Projektleiters leidet ganz einfach an unbegründeter und unheilbarer Überheblichkeit (“hier komme ich, Platz da, mein Projekt als erstes, meine Meinung zählt”).
  • Zentrale Projektmitarbeiter sind überlastet (over-allocated key team members):  Überlastung von Schlüsselpersonen wird ignoriert und im Effekt stoppt das ganze Projekt. Ist aber egal, sollen die Jungs doch die Wochenenden durcharbeiten, oder?
  • Risiken werden nicht aktiv bearbeitet (no risk management plan): Risiken? Nein, Risiken gibts hier nicht ;-)
  • Keinen Prozess für Änderungsmanagement (no change management plan): Änderungen? Sowas darf nicht vorkommen!
  • Fehlendes technisches Wissen im Projektteam (lack of technical expertise in the team): Jaja, können wir alles. Ist doch keine Raketenwissenschaft, da lest ihr euch ein. Jemand muss der erste sein (und Aufbau des Wissens immer schön auf das Projekt buchen).
  • Umfang des Projektes nicht formal geklärt (not having a formally accepted project scope): Jeder interpretiert seine persönliche Zielsetzung in das Projekt hinein, keine weiss wann das Projekt abgeschlossen ist. Umfang des Projektes wird durch das Top-Management schneller geändert, als dass die Änderungen dokumentiert werden können.
  • Projektplan ist nicht aktuell (not having an properly updated project plan): Keiner weiss, was der Plan ist und wo das Projekt steht. Schön.
  • Qualitätssicherung vernachlässigt (no quality management plan): Keiner kennt die Qualitätskriterien und die Anwendung geht mit ein paar “husch-husch” Tests in Produktion. Eine Planung und ein Management von Qualitätskriterien wird nicht konsequent durchgeführt.
  • Große Widersprüche bei der Projektinitiierung (problems in early take-off): In der Initialisierungsphase  wird kein Konsens hergestellt, jeder behält seine Position und Projekt wird trotzdem gestartet. Ausbaden darf es dann der Projektleiter und das Projektteam. Top-Management, welches strategische Richtungsfindungen in ein Realisierungsprojekt verschiebt und dann über explodierendes Budget klagt. Nettes Spiel.

Wer von euch hat diese Erfahrungen nicht schon selbst machen müssen? Es ist für mich immer wieder erstaunlich wie sich bekannte Probleme immer wieder wiederholen.

5 thoughts on “Symptome für Projekte die scheitern werden

  1. So richtig solche Aufzählungen sein mögen, ich mag sie trotzdem nicht, weil die Symptome von den grundlegenden Krankeiten fehlende Projektkultur und mangelhafte Kommunikation ablenken. Zum Beispiel an einem Risikomanagement kann ich beliebig rumdoktern und mir ein Risikoinventar und Risk Assessments um die Ohren schlagen, wenn die Einstellung dahinter nicht stimmt, bleibt die Veranstaltung relativ sinnlos, dann geht es nur mehr um reine Absicherung und Schuldzuweisung, was noch kein Projekt zum Erfolg geführt hat.

  2. Es gilt noch immer die goldene Regel: “Die ersten 90 % des Projekts beanspruchen 90 % der Zeit. Die letzten 10 % benötigen weitere 90 %.”

    In den meisten Punkten die genannt wurden, kann ich mich wieder finden und deshalb habe ich gelernt, das eine gute Planung und die Kommunikation mit den Stakeholdern die wichtigsten Voraussetzungen für ein erfolgreiches Projekt sind.

    • Ist leider immer wieder der Fall, v.a. interne CRs oder böse Überraschungen im Betrieb (Stichwort: Loadbalancer) lassen am Ende zusammen mit einer langen Abnahmephase den Aufwand explodieren ;-(

  3. Ich weiß, ich weiß … es liegt niemals am Software-Werkzeug selbst. Doch unsere Kunden berichten immer wieder, dass viele PM-Tools einfach zu kompliziert sind. Und wenn erstmal einige Teammitglieder ihre Informationen nicht mehr in den zentralen Infopool einpflegen, dann ist es nicht mehr weit zu dem o.g. kritischen Punkt “Projektplan ist nicht aktuell”. Es folgt der Blindflug!

    • Ja, das ist richtig. Die Werkzeuge müssen nicht nur ausreichend “mächtig” sein, sondern vor allem intuitiv und schnell bedienbar. Wenn dies nicht der Fall ist, dann bleiben Informationen aussen vor und vieles funktioniert nicht wie gedacht. Aus diesem Grund versuche ich auch immer, sowenig Details wie möglich (aber soviel wie unbedingt nötig) in meine Projektpläne aufzunehmen.

Comments are closed.