Top 25:
Warum Projekte ständig scheitern

Projekte scheitern immer wieder aus den selben Gründen. Hier die Top 25 der typischen Ursachen.

Projekte sind komplexe Angelegenheiten. Die Teilnehmer haben unterschiedliche Interessen und zeigen variierende Leistung. Dazu kommt, dass jeder von uns zu jedem Zeitpunkt in ziemlich viele Projekte involviert ist, schnell ist man bei fünf, sechs beruflichen, zwei bis drei in der Freizeit, ein paar im Verein, und dann gibt es noch Hobbies, Blogs, Reparaturen, Freunde und andere Begleiter. All das führt dazu, dass es bei Projekten immer wieder die folgenden typischen Probleme gibt (teilweise übernommen und erweitert u.a. von Matthew E. May und PM-Blog):

 

  1. Das Projektgrößen-Problem: Große Projekte werden niemals rechtzeitig oder im Kostenrahmen fertig.
  2. Das WM-Team-Problem: Nur sehr selten beendet man ein Projekt mit dem Team, mit dem man anfing.
  3. Das Teamgrößen-Problem 1: Wenn Du zu wenig Leute im Team hast, werden sie mit den Problemen nicht fertig.
  4. Das Teamgrößen-Problem 2: Wenn Du zu viele Leute im Team hast, erzeugen sie mehr Probleme als sie lösen können.
  5. Das Baumarkt-Problem: Projekte schreiten oft schnell voran, bis sie etwa 80 Prozent fertig sind. Dann bleiben sie für immer unfertig (Denk an Deine Umzugs-Provisorien!)
  6. Das Pareto-Problem: 80 Prozent des Projekts werden erst in den letzten 20 Prozent der zur Verfügung stehenden Zeit erledigt (in Anlehnung an Parkinson)
  7. Das Murphy-Problem 1: Wenn alles gut läuft, musst Du etwas übersehen haben.
  8. Das Murphy-Problem 2: Wenn das Projekt nicht mehr schlimmer laufen kann, wird es schlimmer laufen.
  9. Das Statusbericht-Problem: Projekt-Teams hassen wöchentliche Status-Berichte. Der Grund ist, dass es nichts zu berichten gibt.
  10. Das Planungsproblem 1: Ein sorglos geplantes Projekt wird dreimal so lange dauern wie erwartet.
  11. Das Planungsproblem 2: Ein sorgfältig geplantes Projekt wird doppelt so lange dauern wie erwartet.
  12. Das Planungsproblem 3: Wir halten uns zuwenig an einen Satz von Helmut von Moltke – Kein Plan überlebt den ersten Feindkontakt.
  13. Das Schätz-Problem: 10 Schätzungen derselben Tätigkeit werden zehn verschiedene Zeit- und mindestens 12 verschiedene Kostenaufwände ergeben.
  14. Das Überschätzungs-Problem: Wir akzeptieren ständig mehr Projekte als wir sollten, weil wir die Vorteile über- und unseren eigenen Aufwand unterschätzen.
  15. Das Über-Problem: Wir überladen uns beim Umfang und bei der Einschätzung unserer Skalen-Effekte und unserer Fähigkeiten.
  16. Das Unter-Problem: Wir unterschätzen die Zeit, die wir benötigen, untertreiben unseren Ressourcen-Einsatz und unsere Planungen.
  17. Das Spezialisten-Problem: Je komplexer das Projekt, desto weniger brauchst Du einen Spezialisten, um es zu leiten.
  18. Das Technik-ist-geil-Problem: Wir halten uns starr an Prozesse, Technologien und Abläufe und kümmern uns wenig um die beteiligten Menschen.
  19. Das Improvisations-Problem: Es gibt keine Prozesse und Methoden. Jeder macht, was er will, wann er will, wie er will – oder nicht. Je nachdem.
  20. Das Kommunikationsproblem 1: Es wird nicht ausreichend oder nicht effizient genug kommuniziert. Niemand weiß, was die anderen machen.
  21. Das Kommunikationsproblem 2: Es wird viel zu viel kommuniziert, ständig gibt es Meetings und E-Mails für alle. Keiner arbeitet. Alle kommunizieren.
  22. Das Wer-macht-was-Problem: Niemandem ist klar, wer welche Rolle hat. Jeder macht, worauf er Bock hat. Keiner macht, worauf er keinen Bock hat.
  23. Das Macht-mal-Problem: Der Umfang wurde vom Auftraggeber nicht eindeutig festgelegt. Es wird irgendwas gemacht.
  24. Das Unwichtigkeits-Problem 1: Das Projekt wird von den Entscheidern als unwichtig eingestuft. Genauso motiviert sind nun alle Mitarbeiter.
  25. Das Unwichtigkeits-Problem 2: Die Projektteilnehmer finden das Projekt doof. Genauso motiviert sind sie auch.

Was mich besonders interessiert: Kennt Ihr diese Gründe aus eigener Erfahrung? Und kennt Ihr weitere typische Gründe, warum Projekte scheitern?

 

Gregor Groß

Gregor Gross

Gregor Gross

Gregor Groß kam im Jahre des Herrn 1973 zur Welt, kurze Zeit nach dem Tode Bruce Lees. Ob es dabei wirklich zu einer Seelenwanderung kam, ist bis heute ungeklärt. Keine vierunddreißig Jahre später jedenfalls führte ihn sein Weg über einen asiatischen Zwischenstopp nach Brisbane, Australien, wo er Vertrauen in seine kreativen Fähigkeiten fasste.

Seitdem interessiert sich Gregor für Kreativität (darüber bloggt er auf www.denkpass.de) und dafür, wie man Aufgaben richtig organisiert und delegiert, ohne die Kreativität seiner Mitarbeiter zu behindern. Über dies und ähnliche Themen bloggt er hier auf imgriff.com.

Ansonsten versucht Gregor, tagsüber in einer seiner Firmen (alpha-board.de macht Elektronik-Design und Fertigungsservice, mashamo.de exklusive Kinder- und Babymode ohne Kitsch und Schnörkel, lieblingskaro.de Kinderzimmer-Ausstattung, Bettwäsche und Spielzeug im Karo-Look) möglichst viel zu lächeln und dabei kompetent zu wirken, prokrastiniert am liebsten mit Baseballstatistiken und Tageszeitungen und bildet sich Gottweisswas auf seinen Risotto ein.

Sonntagmorgens, wenn ihn seine Söhne um 5:32 Uhr unsanft wecken, wünscht er sich ein Zeitmanagement, das ihm Zeit zum Schlafen verschafft.

Gregor ist via Kontaktseite zu erreichen.

Mehr lesen

teamspir.it: Logbuch für die täglichen Erfolge als Team

9.8.2013, 2 Kommentareteamspir.it:
Logbuch für die täglichen Erfolge als Team

Im eigenen Agenturalltag haben die Gründer von teamspir.it allzu oft «nebeneinander statt miteinander» gearbeitet. Aus dem eigenen Bedürfnis heraus, den Austausch von Fortschritten, Wissen und konstruktivem Feedback zu fördern, ist teamspir.it entstanden.

Trello Praxis-Check: Wohlwollende, aber kritische Gedanken mit Blick auf den Alltag

10.4.2013, 4 KommentareTrello Praxis-Check:
Wohlwollende, aber kritische Gedanken mit Blick auf den Alltag

Ein kostenloses, genial einfach zu bedienendes Collaboration Tool, mit dem man Projekte effizient führt, und dank dem alle Beteiligten ihre Aufgaben, Dokumente usw. mit links im Griff behalten? Ja, aber…

Trello: Projektplanung im Team mit flexiblen Listen

5.4.2013, 4 KommentareTrello:
Projektplanung im Team mit flexiblen Listen

Bis vor ein paar Wochen war mir Trello völlig unbekannt. Doch plötzlich taucht das Tool fast täglich irgendwo in einem Gespräch oder in einem Blog auf. Und ausnahmslos alle schwärmen davon, wie einfach und flexibel sich damit Projekte planen lassen. Was ist da dran?

MySimplePlan: Rasch Projektpläne auf dem iPad erstellen

11.7.2014, 1 KommentareMySimplePlan:
Rasch Projektpläne auf dem iPad erstellen

Statt den ersten Entwurf eines Projektplans auf ein Blatt Papier zu kritzeln, bietet MySimplePlan als Alternative eine einfache iPad-App. Nicht mehr, aber auch nicht weniger.

The Circle: Getting Things Done auf das absolute Minimum reduziert

24.7.2013, 23 KommentareThe Circle:
Getting Things Done auf das absolute Minimum reduziert

Getting Things Done von David Allen ist bekannt wie ein bunter Hund. Dass GTD - wie alle anderen Produktivitätsmethoden auch - immer eine sehr individuelle Angelegenheit ist, beweisen die unzähligen Variationen, die davon entstanden sind. Drei Wochen mit «The Circle».

Trello Praxis-Check: Wohlwollende, aber kritische Gedanken mit Blick auf den Alltag

10.4.2013, 4 KommentareTrello Praxis-Check:
Wohlwollende, aber kritische Gedanken mit Blick auf den Alltag

Ein kostenloses, genial einfach zu bedienendes Collaboration Tool, mit dem man Projekte effizient führt, und dank dem alle Beteiligten ihre Aufgaben, Dokumente usw. mit links im Griff behalten? Ja, aber…

13 Kommentare

  1. ich sage nur, mache entwerder was alle machen, oder etwas was niemand macht !
    zu viel rum exprementieren bringt manchmal auch nix und kostet viel!

  2. Die Wahre Kunst bei der Projektplanung ist IMO die Beseitigung des augenscheinlichen Widerspruchs zwischen einer strengen Projektplanung mit Hilfe eines Projektplanungstools und einer flexiblen Aufgabenbearbeitung nach GTD Methoden. Das benötigt auf der einen Seite mitdenkende Mitarbeiter, die das Grundproblem verstehen und auf der anderen Seite Projektplaner, die Pufferzeit richtig einschätzen. Diese müssen ausreichend groß genug sein, um das Projekt robust gegen Störungen zu machen, dürfen aber nicht so groß sein, dass sie zum Bummeln einladen.

  3. Eine perfekte Zusammenfassung, pointiert auf den Punkt (oder die Punkte) gebracht!!!!

  4. Sehr schöne Top25 — zum Lachen auf der einen Seite, aber auf der anderen Seite leider auch zu wahr!

    Anhand dieser Zusammenstellung würde ich mir nun einen Fortsetzungsartikel wünschen, in welchem diese Punkte beleuchtet und vorbeugende Maßnahmen aufgezeigt werden.

  5. 26. Das Spezifikations-Problem: Der Auftraggeber verändert die Ziele oder Spezifikation des Projekts während der Projektlaufzeit mehrfach.

    Zu den Punkten 10 und 11: Die vielfach validierte, klassische Regel zur Kalkulation von Projektzeitplänen lautet:

    1. Schätze den Zeitbedarf für das Projekts nach bestem Wissen und Gewissen und entsprechend deiner Erfahrungen.

    2. Verdopple diesen Zeitraum und

    3. Erhöhe auf die nächsthöhere Zeiteinheit.

    Aus einem geschätzten Zeitrahmen von drei Tagen werden also nach Verdopplung und Erhöhung auf die nächste Zeiteinheit sechs Wochen. Damit liegt man dann – einschließlich der diversen Unabwägbarkeiten auf Auftraggeberseite – meist einigermaßen richtig. Der Sage nach soll diese goldene Regel einer Studie aus dem IBM-Umfeld entstammen, für die man eine große Zahl von Projekten im Nachhinein ausgewertet hat.

  6. absolut… ich hänge gerade in 2 projekten drin, in denen min. 50 % dieser punkte zutreffen….

  7. Und nun 25 Tage lang zu jedem Problem eine Lösung.

  8. Es fehlt die 80-80 Regel:
    Die ersten 80% Zielerreichung benötigen 80% von Budget und Zeit.
    Die restlichen 20% benötigen die anderen 80%.

  9. @mitch: Das ist doch Punkt 6 – Pareto!

    @Sven Drieling, @asaaki: Eigentlich sollte es das gewesen sein. Aber jetzt finde ich auch, dass ich noch was folgen lassen muss. Es werden 1-3 Artikel kommen, wo ich wahrscheinlich die Bekämpfungsstrategien dieser Probleme thematisch bündele.

    @Jens Arne Männing: Danke für Punkt 26! Der ist natürlich ein Klassiker!

    @alle: Danke für alle eure Kommentare. So macht Schreiben Spaß!

    • @pareto problem: meistens bleiben viele TN an unwesentlichen dingen hängen……ich seh das hautproblem darin, dass zu beginn nicht ausreichend geklärt wurde, wer wofür zuständig ist und dass die kompetenzbereiche nicht ressourcenorientiert verteilt wurden……das bedingt lähmendes arbeiten……ich glaub die lösung liegt in einer entschleunigten und aufwändigen auftragsklärung, kompetenzzuteilung und teamfindung

  10. @Gregor: nicht ganz, Pareto ist 80/20. Meine eigene Erfahrung ist 80/80 – das ist Pareto kombiniert mit Regel 1.

  11. Sehr viel Wahres! 18.b und 19 treten auch gerne mal gemeinsam auf: Prozesse sind unklar und um die Leute kümmert sich auch niemand. Ich kenne aber auch Unternehmen, in denen die Projektarbeit vorbildlich läuft. Es geht also auch anders.

  12. Feine Sammlung. Ich habe noch:
    1) Das Steuerungsparadigma “Projekt” ist inadäquat: Problem zu groß, zu schlecht abgrenzbar, Randbedingungen zu dynamisch, … . Man fasste die Ziele besser als Strategie oder in der Umsetzung als Programm.
    2) Die Triple Constraints (Ziel, Termin, Budget) werden schon beim Start durch Management oder Vertrieb so verzogen, dass kein Projektleiter das Projekt im veränderten Rahmen noch zum Erfolg führen könnte.

2 Pingbacks

  1. [...] Anlehnung an die kürzlich auf imgriff.com geposteten 25 Probleme, die immer wieder zum Scheitern von Projekten führen, haben ich einmal versucht, die 15 [...]

  2. [...] Link zum Blogeintrag (übrigens ein insgemsamt sehr empfehlenswerter Blog!!!) Dieser Eintrag wurde veröffentlicht in Uncategorized und verschlagwortet mit Projektmanagement von pwebhofer. Permanenter Link zum Eintrag. [...]

Kommentar schreiben

Wir sind sehr an einer offenen Diskussion interessiert, behalten uns aber vor, beleidigende Kommentare sowie solche, die offensichtlich zwecks Suchmaschinenoptimierung abgegeben werden, zu editieren oder zu löschen. Mehr dazu in unseren Kommentarregeln.

* Pflichtfelder