Die fatalsten Planungsfehler in der Projektplanung und wie Sie diese vermeiden

In der scheinbar verwirrenden Vielfalt der Probleme, an denen Projekte scheitern, lassen sich immer wieder dieselben Muster feststellen. Wie können Sie es erkennen, wenn Ihr Projekt in Gefahr gerät? Was sind die typischen Risiken und wie können Sie diese vermeiden?

Der „Teufel“ steckt im Projekt-Detail

Ob Digitalisierungs-Projekte, ob Geschäftsmodell-Innovationen, ob Systemauswahl-Projekte: Der „Teufel“ des Scheiterns steckt oft bereits in der Projektplanung. Wer an dieser Planung spart oder nachlässig arbeitet, der stößt oft bereits vor Projektbeginn das „Tor zur Hölle“ auf – zur Hölle von Stress, Streit und schlaflosen Nächten, von überschrittenen Terminen, galoppierenden Mehrkosten, krassen Qualitätsmängeln, entnervten Kunden und Dienstleistern, panischen Vorgesetzten und Shareholdern.

Was sind das im Einzelnen für Fehler und Nachlässigkeiten, die das bestgemeinte Projekt stören oder gar zerstören?

Die folgenden Planungsfehler treten immer wieder auf und bereiten den Projektbeteiligten Probleme. Sie sind – und das ist die gute Nachricht – samt und sonders vermeidbar. Dazu weiter unten mehr.

Fehler bei der Zielformulierung

1. Die Projektziele sind schwammig formuliert. Ein Beispiel: Die Zielformulierung „effizientere Prozesse“ ist bei der Systemauswahl unbrauchbar. Es ist unmöglich, anhand objektiver Kriterien zu überprüfen, ob dieses Ziel erreicht wird oder wurde. Es fehlt eine Vorgabe, welche Prozesse effizienter ablaufen sollen, und eine Definition von „effizienter“: Sollen sie arbeitssparender, schneller oder kostengünstiger ablaufen?

2. Die Projektziele sind nicht transparent. Sie sind unvollständig ausgearbeitet oder, da selbst nicht verstanden, unverständlich.

3. Die Ziele sind nicht messbar und nicht mit Terminen hinterlegt. „Messbar“ muss nicht bedeuten, dass in jeder Zeile des Lastenheftes ein Euro- oder Prozentzeichen steht. Aber es ist gut, sich an der Galileo zugeschriebenen Vorschrift zu orientieren: „Messen, was messbar ist, und messbar machen, was noch nicht messbar ist.“

4. „Revenue > 50 Mio. Euro“ ist ein Ergebnis und kein realistisches Ziel.

5. Die Teammitglieder haben unterschiedliche Verständnisse der Projektziele. Dies ist zum Beispiel der Fall, wenn sie eine versteckte Agenda haben, über die sie nicht sprechen, oder weil die Vertreter der verschiedenen Unternehmensbereiche sehr unterschiedliche Vorstellungen von den Erfolgsfaktoren der Unternehmens-Leistungen haben. Typischerweise ist dies zwischen Produktmanagement und Vertrieb der Fall.

6. Die bereichsbezogenen oder individuellen Ziele der Projektbeteiligten konvergieren nicht, und dieser Mangel an Konvergenz wird nicht ausdiskutiert, bzw. es wird den Dienstleistern überlassen, diese Diskussion zu führen. Dies ist aber nicht deren Aufgabe, oder sie sind dafür nicht qualifiziert.

Fehlerhaft gesteuerte Scope-Anpassungen

Der „Scope“ eines Projekts ist dessen Umfang im Sinne eines Sets von Entscheidungen, welche Bereiche im weitesten Sinn inkludiert und, besonders wichtig, welche exkludiert sein sollen. Ein Beispiel: Auf einer Baustelle mit mehreren Losen oder Gewerken müssen vor Arbeitsbeginn die einzelnen Grenzen zentimetergenau voneinander abgegrenzt werden, damit sie im fertigen Bauwerk zusammenzupassen.

Scope-Anpassungen sind notwendig, denn im Verlauf eines Projekts werden die Beteiligten zunehmend „schlauer“, und es ist sinnvoll, von diesem Wissen Gebrauch zu machen – vor allem dann, wenn es dem Kunden nützt. Probleme gibt es nur dann, wenn die Möglichkeit solcher Scope-Anpassungen nicht von vornherein eingeplant wird – oder wenn diese schlecht gesteuert werden. Mit welchen Eventualitäten ist bereits im Projekt-Setup zu rechnen?

7. Der anfangs festgelegte Scope wird in einem schleichenden Prozess verändert. Langsam, aber sicher gerät er aus dem Fokus und verschiebt sich – nur für jeden Projektbeteiligten in unterschiedliche Richtung. Auf einmal redet jeder von einem völlig unterschiedlichen Projekt.

8. Wenn eine Scope-Anpassung beschlossen wird, muss sie allen direkt oder indirekt Projektbeteiligten klar kommuniziert werden können, da sie sich auf deren Arbeitsfelder und -kapazitäten drastisch auswirken könnte.

9. Auch die Projektziele und Messgrößen gilt es bei einer Scope-Anpassung nachzujustieren, damit beim Soll-Ist-Abgleich nicht der falsche Eindruck entsteht, das Projekt sei erfolglos, nur weil die ursprünglich anvisierten Ziele nicht erreicht wurden.

Falsches Verständnis von Agilität

Agilität ist eine anerkannte Methode bei der Entwicklung von Software-Systemen und hat dort ihren legitimen Platz. Aber nicht in jedem beliebigen Projekt ist es sinnvoll, agil vorzugehen.

10. Der Begriff der Agilität wird inflationär und oftmals nur halb verstanden in den Mund genommen. Damit riskiert man bei einzelnen Beteiligten falsche Erwartungen an den Verlauf des Projekts.

11. Spätestens dann, wenn das Bekenntnis zur Agilität Unentschiedenheit oder Entscheidungsschwäche kaschieren soll, müssen die Projektverantwortlichen entschieden und auch mal couragiert gegensteuern. Wenn ein Projektteam je nach Tageslosung einmal nach links und einmal nach rechts gescheucht wird, dann hat das wenig mit „Agilität“ und viel mit Ressourcenverschwendung zu tun.

12. Agilität dient auch oft als Feigenblatt für eine gleichgültige Haltung gegenüber einem Projekt und dessen wichtigen Einzelheiten. „Agil“ vernachlässigen manchmal Entwickler die Dokumentation ihrer Vorgehensweise und ihrer Gründe für ihre einzelnen Entscheidungen. Sie müssen und wollen ja schnell vorankommen, und wer dokumentiert schon gern? Wenn also die Projektverantwortlichen im „agilen“ Projekt den Entwicklern weder den Raum noch die nötigen Werkzeuge für die Dokumentation bereitstellen, sondern im Gegenteil mit Verweis auf die Termine Druck machen oder wenn ihr Fokus komplett weg von der Dokumentation und hin zur Problemlösung wandert, züchten sie jene unbeherrschbaren Projektmonstren und unwartbaren Softwaremonstren, die sie abhängig machen von einzelnen Dienstleistern und deren Kosten bei bescheidener Performance ständig aus dem Ruder laufen.

13. Das disziplinierte Vorgehen, das ein formal agiles Vorgehen verlangt, wird oft unterschätzt. Ein Daily Scrum Standup darf nicht mehr als fünfzehn Minuten dauern. Stakeholder mit einem Hang zur Selbstdarstellung haben darin nichts verloren und müssen von vornherein ausgeschlossen werden.

Fehlende Kommunikations-Strukturen

In einem Entwicklungsprojekt muss anders kommuniziert werden als im täglichen Geschäft. Schon vor Projektbeginn sind Denkarbeit, Abstimmung und Konzeptionen für die Kommunikationsstruktur erforderlich.

14. Eine Kommunikationsstruktur umfasst unter anderem die Definition und Besetzung von Gremien, die Einrichtung von Kommunikationsroutinen und -wegen und oft die Anschaffung spezifisch geeigneter Software. All dies unterbleibt allzu oft.

15. Es ist eine große Herausforderung, in Projekten Tag für Tag transparent zu kommunizieren und die richtigen Personen mit den richtigen Informationen zum passenden Zeitpunkt zu versorgen. Oft scheitern Projektbeteiligte an dieser Aufgabe. Fehler und Frust können daraus resultieren.

16. Fatal wird es, wenn es keine Fehlerkultur gibt. Man will Innovation und innovativ arbeiten. Aber bei neuen, unbekannten Vorgehensweisen entstehen fast zwangsläufig Fehler. Wenn diese Fehler nicht akzeptiert oder sogar bestraft werden, werden keine neuen Methoden mehr ausprobiert, Fehler nicht eingestanden und unzureichend kommuniziert. Die Auswirkungen der nicht kommunizierten Fehler sind meist viel größer als der eigentliche initiale Fehler.

Erwartungen und Commitment

17. Es liegt auf der Hand, dass ein Projekt für die verschiedenen Beteiligten sehr unterschiedliche Bedeutung haben kann. Wenn darüber nicht beizeiten und während des Projekts wiederholt gesprochen wird, fehlen wichtige Informationen, was spätestens bei der Evaluierung den Betroffenen auf die Füße fallen kann.

18. Auch die Wichtigkeit eines Projekts ist meist sehr unterschiedlich. Für eine Person oder einen Bereich ist es das zentrale, das wichtigste Projekt des Jahrzehnts, für eine andere ist es ein randständiges und damit uninteressantes Projekt, und es wäre überzogen, von dieser dasselbe Engagement zu verlangen wie von der ersten.

19. Zu Beginn sollte gemäß dem relativen Stellenwert eines Projektes ebenso wie das einzubringende Commitment eines jeden Projektbeteiligten abgestimmt werden, um sicherzugehen, dass man während der Laufzeit die jeweiligen Leistungen auch beanspruchen und abrufen kann und niemand sich ohne Konsequenzen wegducken kann.

Wie wirkt Argestes Planungsfehlern erfolgreich entgegen?

Wir planen und visualisieren Projekte digital und kollaborativ. Dazu nutzen wir regelmäßig Mural Boards. Mural Boards erlauben sehr komplexe, ausführliche Visualisierungen und lassen sich bei klassischen und agilen Entwicklungsmethoden anwenden.

Unsere Planungsgrundlage ist meist ein Kundenworkshop zum Zweck der Definition von Zielen und Scope (klassisch) oder Projektvision (agil).

Ziele formulieren wir grundsätzlich SMART – das bedeutet:

• Spezifisch
• Messbar
• Akzeptiert
• Realistisch
• Transparent

Damit wir dabei möglichst direkt zum Ziel gelangen, haben wir eine umfassende Checkliste Projektplanung entwickelt. Diese ist kostenlos bei uns erhältlich. E-Mail an info@argestes.de genügt!