Sanierung notleidender Projekte - Henning Zeumer Projektmanagement

Zeit für Veränderung…

Große Dinge werfen ihre Schatten voraus, und so möchte ich Sie heute schon auf wichtige Veränderungen in meinem Service-Portfolio aufmerksam machen.

Die letzten Jahre haben gezeigt, dass meine Erfahrung und Expertise immer mehr von Gutachten und Sanierungen für notleidende Projekte und Programme in Anspruch genommen werden. Es bleibt zu wenig Zeit für ein breites Service-Portfolio.

Deshalb habe ich mich entschieden, mich noch mehr auf mein Spezialgebiet zu konzentrieren. Für die vielen anderen Fälle, in denen erfahrene, professionelle Projektmanager gebraucht werden, habe ich mein Netzwerk „PM-Professionals“ noch mehr verstärkt. Alle bisherigen Dienstleistungen werden also unter diesem Label und meiner qualitätssichernden Supervision für Sie weiter zur Verfügung stehen.

Die Veränderungen werden Sie auch in meiner Internet-Präsenz wiederfinden, die ich gerade grundlegend umgestalte. Es ist also auch Zeit (und für Sie auch noch einmal die Gelegenheit), von meiner „alten“ Webseite und dem breiten Überblick auf mein Service-Portfolio Abschied zu nehmen. Über den Launch der neuen Seiten werde ich Sie in ca. 2-3 Wochen rechtzeitig informieren.

Danke für Ihr bisheriges Vertrauen – ich freue mich schon jetzt auf die vielen großen Dinge, die ich gemeinsam mit Ihnen angehen darf !

Aus Fehlern lernen: Troubled Project Recovery

Kennen Sie das? Sie beginnen eine neue Aufgabe, und alles kommt Ihnen irgendwie sehr bekannt vor. Erfahrung eben…

Als ich vor fast 30 Jahren nach dem Studium mein Berufsleben begann, entschied ich mich bewusst gegen ein Trainee und eine fachlich begrenzte Einstiegsposition bei einem einzelnen Unternehmen, sondern für das breite Lernen in einer Unternehmensberatung aus vielen guten und auch schlechten Beispielen.

Aus Erfahrungen lernen

Nach wenigen Jahren Praxis sammelte ich auf dem Weg von der Ladentür bis zum Chefbüro eines neuen Klienten in der Regel bereits eine Handvoll Vorschläge zur Verbesserung der Verkaufs- und Ertragssituation des Unternehmens. Die vielfältige Erfahrung hatte mich Best Practices gelehrt, wie man den Kunden der beratenen Firma möglichst wenig Steine in den Weg legt, um ihr Geld auszugeben.

Hennig Zeumer 72 dpi 17704 - Projektsanierung, Erfahrung Mit den Jahren hat sich mein Beratungsschwerpunkt hin zum Projektmanagement verändert. Gewachsen ist der Erfahrungsschatz an guten und schlechten Beispielen, hinzugekommen sind Best Practices, die mit international anerkannten PM-Standards methodisch unterfüttert sind. Meine Basis für eine erfolgreiche Projektsanierung…

Mit Erfahrung beraten

Wenn ich heute zu einem notleidenden Projekt gerufen werde und eine erste Bestandsaufnahme gemacht habe, offenbaren sich meist schnell eine Auswahl von Problemen aus einer Reihe von typischen Fehlern, die in allen Krisenprojekten immer wieder anzutreffen sind, unabhängig von Branche oder Projektart. Hier kann dann die Projektsanierung ansetzen.

Welches sind die häufigsten Ursachen für eine Schieflage?

Mangelhafte Auftragsklärung, meist verbunden mit unkontrollierten Änderungen: Das Problem beginnt oft schon beim Vertrieb, mit unrealistischen, mit den Ausführenden nicht abgestimmten Erwartungen, und/oder wenn die Basis der Planungen unvollständige oder widersprüchliche Anforderungen waren. Dann kann kein Plan aufgehen, dann sind Verluste schon zu Beginn des Projekts vorprogrammiert !
Mangelhafte Unterstützung durch das Management und die Organisation: Der Projektmanager soll liefern, bekommt aber von seiner Organisation nicht genügend oder nicht die richtigen Ressourcen, hat keine Kompetenzen zum Durchgriff oder für Entscheidungen, oder wird mit Herausforderungen, die nicht im Projekt lösbar sind, allein gelassen. Oft gründen diese Probleme in gewachsenen Strukturen und in der Unternehmenskultur, die nicht genügend Reife für ein Businessmodell haben, in dem das Geld in Projekten nicht nur abgewickelt, sondern verdient werden muss. Alle Teile des Unternehmens müssen den Projekterfolg ohne Einschränkungen auch wollen !
Fehlendes PM-Knowhow und/oder Führung auf Seiten des Projektleiters: Diese „Schuldzuweisung“ ist für (fast) alle Beteiligten die einfachste, löst aber nicht das Problem. In vielen Fällen ist der Projektleiter ein begnadeter und erfahrener Fachexperte, kennt aber die vielen sinnvollen Methoden und Hilfsmittel für gutes Projektmanagement nur wenig. Oft ist er auch zeitlich mit seinen vielen Fachaufgaben im Konflikt, um seinen Job als PM richtig auszuführen. Im Zweifelsfall konzentriert er sich dann auf das, was er am besten und sichersten kann – und das Management des Projekts bleibt auf der Strecke, mit allen Folgewirkungen !
Unterentwickelte Infrastruktur für Projekte: Es muss nicht einmal an geeigneten Standards und Werkzeugen fehlen. Viele Unternehmen haben bereits ein Projekthandbuch und viele Vorlagen und Prozesse für ihre Projekte, verwenden diese aber nicht konsequent. Vielfach tritt dieser Fehler im Zusammenhang mit den vorstehenden auf, zeigt sich in individuell unterschiedlicher Anwendung, unklaren Kompetenzen, unkoordiniertem Resourcing, und/oder schlechter Kommunikation zwischen Team und den beteiligten Abteilungs-Silos. Wenn die Voraussetzungen und Umgebungsfaktoren für Projektarbeit nicht stimmen, können Projekte nur schwer erfolgreich sein !

Achsbruch - Projektsanierung, Erfahrung Dies ist nur eine kleine Auswahl, und die Vielfalt der Facetten und Kombinationen sind für den Projektfachmann immer wieder faszinierend, ihre scheinbar gottgegebene Wiederholung in so vielen Projekten bestürzend. Was da an Geld verbrannt wird – so viel kann kein guter Projektmanager der Welt kosten…

Auf der Erfahrung aufbauen

Sind die Schwachstellen aber erkannt, dann kann man sie gemeinsam und gezielt in der Projektsanierung angehen. Manchmal braucht es etwas Zeit, die Säge zu schärfen, bevor man in den Wald geht, oder einen Zaun zu bauen, um dann die Hühner wieder einzufangen. Aber in aller Regel lernen die Beteiligten aus ihren Fehlern am meisten, können mit etwas Anstrengung und gutem Willen auf allen Seiten das Projekt noch zu einem befriedigenden Ergebnis und Deckungsbeitrag führen. Und das Unternehmen behält, wenn es die Lessons Learned ernst nimmt, ein wertvolles Asset, um künftigen Schieflagen in seinen Projekten wirksam vorzubeugen.

Lesen Sie mehr über meine Expertise bei der Projektsanierung für gefährdete Projekte – klicken Sie hier …

Programm vs. Projekt – der richtige Management-Ansatz vermeidet Schieflage

Häufig werde ich gefragt, wo denn der Unterschied zwischen Programm- und Projektmanagement liege. In der Tat sind die Grenzen zwischen Programm vs. Projekt in der Praxis oft fließend, werden die Strukturen, Rollen und Aufgaben nicht immer trennscharf definiert und gelebt. Und genau da liegen die Fallstricke für einen Programm-Manager, die Erwartungen der Stakeholder zu erfüllen, weshalb ich heute einmal ein wenig zur Veranschaulichung beitragen möchte.

Zu komplex für Projektmanagement-Methoden

Programme sind große, komplexe Initiativen, die in mehreren „Teilprojekten“ einzelne Module eines neuen Ergebnisses erstellen, anpassen und einführen sollen. Dazu ist meistens eine großangelegte Datenerfassung und ‑Migration oder ein Um- bzw. Einbau bestehender Anlagen und Ausrüstung nötig. Weiter muss man oft das (die) in mehreren Schritten einzuführende System (Anlage) bereits operativ betreiben und auch nach Abschluss der (Teil-)Implementierungen (weiter) supporten bzw. warten. Ein Programm umfasst also mehrere einzelne Komponenten, die aufeinander aufbauen und nur zusammen den letztendlich gewünschten Nutzen ergeben. Außerdem geht es im Allgemeinen schon von der Dimension und Dauer her über ein normales Projekt hinaus.

Apollo - Programm vs. Projekt

Und noch eine Besonderheit: Programme beginnen oft mit einer Vision, bei der noch niemand weiß, wie diese konkret Realität werden soll. Es gibt also nicht wie in Projekten eine Inhalts- und Umfangsbeschreibung, die man abarbeiten könnte, sondern diese muss erst entstehen: Viele Teilkomponenten müssen innerhalb des Programms erst erdacht und definiert werden, um dann später zum gemeinsamen Zielergebnis integriert werden zu können. Auch die Dauer eines Programms ist durch die Komplexität nicht immer festgelegt, und die sich auf dem Weg ergebenden Veränderungen können selbst das Ziel noch beeinflussen oder gar verändern.

Ein anschauliches Beispiel ist die erste Mondlandung, von J.F. Kennedy 1962 propagiert, noch im gleichen Jahrzehnt realisiert zu werden. Was es dazu gebraucht hat (Startrampe, Trägerrakete, Mondfähre, lebenserhaltende Systeme, Flugberechnung und -kontrolle usw.) musste erst erdacht und erfunden werden. Alle Flüge im Apollo-Programm vor Apollo 8 dienten ausschließlich der Erkundung und Erprobung des Systems vor der eigentlichen Mondreise. Und das Programm war mit dem Erfolg noch lange nicht abgeschlossen, sondern wurde zur weiteren Forschung und Verbesserung fortgeführt.

Den strategischen Nutzen maximieren

Nach der „reinen Lehre“ muss Programm-Management einen Mehrwert stiften, der durch das Management der einzelnen Komponenten nicht erreichbar ist. Die Aufgaben liegen insbesondere in der Koordination der Komponenten, dem Betrachten der Schnittstellen untereinander und mit der (Kunden-)Organisation, und darin, den Nutzen des Programms für den Kunden sicherzustellen. Ein Programm-Manager (PgM) muss zusätzlich zur operativen Leitung des Programms vor allem den Puls des Kunden fühlen, und abwägen, was am besten in die Strategie dessen Geschäfts passt. Seine strategische Nutzensicht unterscheidet ihn fundamental von der primär von der Lieferung geprägten Sicht eines Projektmanagers (PM).

Der Fokus auf die Maximierung des (Kunden-)Nutzens bedeutet auch, dass Änderungen nicht „notwendiges Übel“ am ursprünglich festgelegten (Projekt-)Inhalt und -Umfang sind, sondern implizit vorgesehen, so, wie sich die Notwendigkeit, z.B. in Gestalt zusätzlicher Komponenten, und/oder ein Zusatznutzen über die Laufzeit hinweg ergeben. Auch das unterscheidet PgM vom Multi- oder Super-PM, wo die Lieferleistungen und -Zeiträume zu Beginn festgelegt werden.

Programmmanager müssen anders denken als Projektmanager

Bei meinem Boarding war das Programm bereits in Schieflage: erster Meilenstein geplatzt, der Kunde verweigerte die Teilabnahme trotz Lieferung aller Features, weil ihm die Usability und Performance nicht genügte. Im Vertrag stand dazu nichts. Überdies gab es mittlerweile ein paar neue Features, die der Kunde auch gern haben, der Lieferant aber erst nach Abschluss des ersten Vertrags angehen wollte. Verfahrene Situation, Hektik im Key Account und bei den Vertragsanwälten, mein Vorgänger verlies das Programm…

Nun bekommt man nicht die Verantwortung für solch eine Riesen-Initiative, wenn man nicht als PM schon richtig gute Leistungen gezeigt hat. Aber das allein genügt für ein Programm meist nicht, wenn nicht zusätzliche PgM-Methodik und –Handeln hinzukommt.

Ich musste also meinen Auftraggeber überzeugen, aus dem Großprojekt ein richtiges Programm zu machen, mit dem Kunden vornehmlich über dessen Nutzen und Business Case zu reden, und nutzenstiftende Änderungen als zielführend zu antizipieren. Der Kunde wiederum musste sich auf kostenpflichtige Change Requests einlassen, auch wenn er vertragsmäßig gerade am längeren Hebel saß.

Programmmanager müssen anders denken als Projektmanager

Nur gemeinsam und mit Blick auf den Nutzen, den die Investition für den Kunden bringen soll, macht eine solche Sinn – schon bei Projekten, und noch viel mehr bei Programmen. Das ist im harten Business-Alltag sicher manchmal ein Spagat, denn auch für den Auftragnehmer muss es sich ja rentieren. Wo sich im Projektmanagement zwei PMs, einer von Kunden- und einer von Lieferantenseite, meist gut ergänzen, ist im Programm oft ein gemeinsamer PgM als Stakeholder-Manager, Gesamtnutzen-Maximierer und Regisseur das bessere Setup.

Die Haupt-Stakeholder beider Seiten sitzen überdies häufig genug zusammen und beraten mit Blick auf einen gemeinsamen Interessenausgleich, wohin die Reise gehen soll. Dann wird der PgM zum Berater des Boards, Verantwortlicher für das Sicherstellen des Nutzens und Schnittstellen-Koordinator für die Programm-Komponenten. Nicht sinnvoll ist es, sich als Super-/Multi-PM auf die letztere Funktion zu beschränken, denn dann entkoppeln sich Delivery und angestrebter Nutzen schnell.

Der Erfolg entscheidet sich schon beim Setup

Damit wird aber auch implizit deutlich, dass bereits das Setup einer Initiative entscheidend ist, ob es richtig gemanagt werden kann oder nicht. Ein Down-Sizing von Programmen zu Groß- oder Multi-Projekten wird genauso wenig erfolgreich sein wie der Versuch, ein Programm mit Projektmanagement-Mitteln und -Denken zum Ziel zu führen. Der richtige Management-Ansatz von Anfang an vermeidet spätere Schieflage – und wenn es bereits passiert ist, kann ein Wechsel das Mittel der Wahl zur Stabilisierung sein. Man muss es aber verstehen, was ein Programm ausmacht…

Lesen Sie mehr zum Thema – klicken Sie hier …

4 häufigste Probleme in notleidenden Projekten

Das Center for Business Practices (Havertown, USA) hat im April 2006 in einer Umfrage unter 84, meist in den USA arbeitenden Projektmanagern insgesamt 3.874 Projekte untersucht. Die Unternehmen schlossen durchschnittlich Projekte im Wert von $65 Millionen innerhalb eines Jahres ab. 47% der Projekte gerieten in Not, wurden saniert oder abgebrochen. Hier die 4 häufigsten Probleme in notleidenden Projekten bzw. deren Hauptsymptome:

Kritische Probleme, Meilensteine zu erreichen oder Leistungsgegenstände zu erstellen
Hohes Risiko, dass das Projekt nicht den angenommenen Nutzen liefern wird
Die Fertigstellung des Projektes wird unakzeptabel lange hinter Plan erfolgen bzw. das Projekt liegt unakzeptabel weit hinter dem Zeitplan
Kritische oder stark steigende technische Probleme im Projekt

Bei der Frage, wie das Projekt gerettet werden könne, antworteten die Projektmanager in 24% der Unternehmen, dass zur Sanierung von notleidenden Projekten ein standardisierter Prozess vorhanden sei, in 31% der Unternehmen existiert für diesen Fall keinerlei Plan…

Einer weiteren Studie des Hauses zufolge über 16.110 Projekte mit einem Gesamtwert von $29,8 Milliarden werden 7% der Projekte leidlich zum Ende gebracht, 25% bleiben gefährdet bis zum Schluss und 6% scheitern gänzlich. Und 33% der Projektausgaben entfallen auf Maßnahmen zur Rettung in Eigenregie bzw. zur Kompensation von durch die Projektkrisen verursachten Probleme.

pmevidence - Probleme in notleidenden Projekten Eine Studie der Standish Group (CHAOS Research 2006) bestätigt diese Ergebnisse nahezu: 46% gefährdeten Projekten stehen 35% erfolgreiche, aber auch 19% gescheiterte Initiativen gegenüber. Eine Tendenz zu erfolgreicheren Projekten sei aber in den letzten Jahren dank zunehmend besserer Ausbildung der Projektmanager und Einführung von projekt-unterstützenden Strukturen in den Unternehmen deutlich spürbar.

Die Ausgaben für professionelles Projektmanagement rechnen sich also gegen die größten Probleme in notleidenden Projekten !

Lesen Sie mehr zu diesem Thema…