Projekterfolg als Herausforderung
Bereits am Anfang meiner Tätigkeit als PMO Leiter hat mich die Frage nach dem Projekterfolg beschäftigt. In meiner Laufbahn in Unternehmen, aber auch als Berater habe ich viele Projekte scheitern sehen. Die Frage stellt sich doch für alle Projektleiter und Führungskräfte, was letztlich den Erfolg oder Scheitern eines Projektes bestimmt – Der heilige Gral? Viele Dinge sind hier denkbar und auch in der Literatur untersucht: die Fähigkeiten und Erfahrung des Projektleiters, die Unterstützung des Managements, die (un)klare Zielsetzung oder andere Rahmenbedingungen des Projekts.
Projektgrösse als Problem
Doch eine sehr einfache Erfolgsgrösse, die recht leicht zu beeinflussen ist, wird oft ausser Acht gelassen: die Projektgrösse.
Wie der Presse zu entnehmen, scheitern nicht nur derzeit viele Grossprojekte durch hohe Budget- oder Zeitüberschreitungen. Der Berliner Flughafen oder Stuttgart 21 sind die bekanntesten Beispiele aus Deutschland. Auch aus meiner Laufbahn kenne ich besonders Grosse Softwareprojekte, die kritisch verlaufen.
Projekte splitten als Lösung!?
Und doch wäre die Lösung meist recht einfach: Die Stückelung von Projekten in kleinere Teile. Für IT und Veränderungsprojekte konnte ich dieses Konzept sehr erfolgreich erproben und dessen Nützlichkeit testen. So können Organisationsprojekte in ein Konzeptprojekt und ein Implementierungsprojekt unterteilt werden. Implementierungen in separate Unterprojekte je Land oder Niederlassung. IT Projekte in ein Vorprojekt zur organisatorischen Klärung der Anforderungen, ein Spezifikationsprojekt und ein Entwicklungsprojekt (oder bei agilen Verfahren in noch kleinere geschlossene Entwicklungsloops). Dies bringt oft zahlreiche Vorteile:
- Projekte müssen nicht mühsam gestoppt werden, wenn sie keinen Sinn mehr machen. Ein kleineres Projekt kann einfach auslaufen, ohne ein Folgeprojekt zu starten. Die hilft, die gerade in Grossunternehmen so wichtige Gesichtswahrung für Verantwortliche sicherzustellen.
- Die Projektaufgabe wird kleiner und kann daher einfacher bearbeitet werden. Projektteams können kleiner gehalten werden, Projektleiter benötigen weniger Erfahrung und Kenntnisse, um die Aufgabe zu meistern.
- Risiken können begrenzt werden, da nicht alle Aspekte gleichzeitig geklärt werden müssen. dies ist gerade bei Changeprojekten oder IT Projekten hilfreich, da hier zu grosse Änderungen oft Widerstände hervorrufen, wenn die Notwendigkeit zur Änderung nicht breit im Unternehmen bereits verstanden und akzeptiert ist.
Auch das neue Buch von Nassim Nicholas Taleb, “Antifragile” greift das Thema auf, was mich motiviert hat, diesen Blogeintrag zu schreiben. Taleb beschreibt in seinem Buch das Phänomen fragiler Systeme. Er geht dabei auch auf das Thema grosser Projekte ein. Er nutzt in seinem Buch zur Beschreibung des Themas Fragilität, gerade von großen und komplexen Einheiten, ein sehr plastisches Beispiel, nämlich die Verletzungsgefahr beim wiederholten Sprung aus unterschiedlicher Höhe. Springt man aus 10cm Höhe 100mal, so ist die Verletzungsgefahr recht gering und insbesondere deutlich geringer als bei einem einmaligen Sprung aus 5 Metern Höhe. Das Risiko ist bei letzterem weit grösser; es steigt nicht linear sondern überproportional an. Ähnlich kann dies auch für Projekte Anwendung finden.
Eine Herausforderung allerdings kann in der Anwendung im Unternehmensalltag sein, die richtigen Schnittflächen für Projektsplits zu finden, wenn man hierzu wenig Erfahrungen hat. Hier kann externe Unterstützung hilfreich sein. Auch kann es oft im traditionellen Konzernumfeld nicht so einfach sein, mehrmals Budget fürs gleicht Thema zu bekommen oder auch die gleicht Management-Attention, wenn das Budget nicht auffällig gross ist.
Was meinen Sie zu diesem Thema? Haben sie Erfahrungen?
lieber Oliver,
so sehr ich dieser taktik zustimme – nämlich in allen projekten, wo dieses splitting anwendbar ist, solche aufteilungen auch vorzunehmen – halte ich sie gleichzeitig auch für eine art “wunschdenken”!
warum?
viele projekte sind groß und komplex: vernetzt, vielschichtig, dynamisch nicht klar vorhersehbar.
nun lässt sich komplexität durch teilen aber nicht reduzieren. im gegenteil, sie erhöht sich durch das einführen einer weiteren abstraktionsebene und deren notwendige re-integrationsleistung ihrer “einzelteile” zu einem ganzen.
“salami-scheiben” haben etwas sympathisch sequenzielles und überschaubares – nur ist diese saubere schnittführung denke ich oft nicht möglich.
und mit meiner privat-meinung zu einem projekt wie BER, würde ich sagen:
solange in projekten bzw. deren kultur die möglichkeit der realitätsverweigerung besteht – etwa durch verantwortliche mit einer (politischen) haltung von:
“geht nicht gibt’s nicht.”
reden wir doch viel mehr von dummheit, als von schlechtem oder gescheitertem projektmanagement.
sunshine!
Jan A. Poczynek
Hallo Jan,
danke für deine Punkte. Es ist sicherlich nicht leicht, immer die richtige Schnitt-Technik zu finden und vielleicht sind Scheiben zu trivial und oft “Scherenschnitte” nötig, da gebe ich dir recht.
Wenn es allerdings gelingt, ähnlich wie im Softwarebereich inzwischen mit agilen Methoden üblich, eher iterativ vorzugehen, eher kleinere Schritte zu gehen, so reduziert das die Komplexität und das Risiko enorm.
Oft genügt es sogar vielleicht, rein das wording zu ändern und aus verschiedenen Projektphasen eines umfangreichen und lagen Projektes eher mehrere kleinere zu machen. Die gezielte Suche nach möglichen Schnittebenen und Stoppunkten kann, auch wenn sie letztlich hie und da nicht zu einem guten Schnitt führt dennoch hilfreich sein, ein Projekt einmal aus anderen Perspektiven zu ergründen.
[…] Projektgrösse und Projekterfolg […]