Projektübergabe: Fehler vermeiden bei der Übernahme eines Projektes

Projektübergabe: Fehler vermeiden bei der Übernahme eines Projektes

Bei gutefrage.net hab ich neulich einen interessanten Thread entdeckt in dem es um die Problematik einer Projektübernahme geht. In der Tat kenne ich wenig Fachliteratur, die sich mit diesem Thema auseinandersetzt (ich nehme hier auch gerne Literaturtipps entgegen).

Ein guter Grund sich damit mal näher zu beschäftigen: Im Grunde muss man hier zwei Arten der Übernahme unterscheiden. Ausschlaggebend ist meines Erachtens die Motivation, aus der heraus das Projekt vom eigentlichen Projektleiter nicht zu Ende geführt wird:

1.) Das Projekt befindet sich in Schieflage und der Projektsponsor versucht, durch den Wechsel das Projekt zu retten. Dafür kann es offenkundige Ursachen haben, wie Beschwerden durch Keystakeholder (z. B. den Kunden), verpasste Termine, übertretene Budgets… oder auch verborgene Ursachen, dass z. B. einfach das Vertrauen nicht mehr vorhanden ist, dass das Projekt mit Erfolg beendet wird. Wichtig ist jedenfalls, dass hier immer zusätzliche Aufgaben auf den neuen Projektleiter zukommen und er nicht einfach dieses Projekt weiterführen kann, als ob es keine Probleme gegeben hätte.

2.) Die Ursache ist in anderen äußeren Umständen zu suchen. Der vorhergehende Projektleiter soll ein anderes Projekt übernehmen, verlässt das Unternehmen oder den Standort… Hier sollte man auf alle Fälle nachprüfen, ob nicht doch Gründe aus Punkt 1 im Verborgenen vorliegen. Wichtig ist dabei, nicht den Vorgänger vorzuverurteilen. Ich habe leider immer wieder Projektleiter gesehen, die hier versucht haben, sich zu profilieren in dem sie die Arbeit des Vorgängers schlecht gemacht haben. In meinen Augen geben sie damit sehr viel über ihre eigenen Skills preis. Jeder weiß, wenn man lange genug sucht, findet man an jedem Projekt etwas zu bemängeln…

In beiden Fällen sind folgende Schritte zu empfehlen:

1.) Zunächst sind die Projektdokumente bei Übernahme zu protokollieren. Mein absoluter Favorit ist hier ein Projekt, dessen Dokumentation aus einer Sammlung von Mails besteht. Besondere Beachtung sollten man dabei meines Erachtens folgenden Dokumente schenken:

• Project Charter / Projektauftrag: Hier sollten zumindest die Projektziele benannt sein (wir bieten hier im Übrigen in unserem Downloadbereich ein entsprechendes Template an, von dem ich glaube, dass es allen Belangen einer detaillierten Project Charter genügt). Zusätzlich ist hier zu prüfen, ob alle genehmigten Änderungen zu den Zielen ausreichend dokumentiert sind.

• Stakeholder- und Risikoliste: Sind die Dokumente vorhanden, werden die identifizierten Stakeholder und Risiken gemanaged? Wie alt ist die letzte Aktualisierung? Wie und durch wen wurden die Listen bisher gepflegt?...Auch hier möchte ich auf unser Tool im Downloadbereich und unser Video auf YouTube hinweisen.

• Projektplan, damit ist nicht nur der Schedule Plan gemeint, sondern auch die anderen Bestandteile, wie Kosten-Plan, Kommunikations-Plan, Procurement-Plan, Risiko-Plan, Qualitäts-Plan, Ressourcen-Plan… Sind diese noch aktuell und gepflegt?

2.) Dann sollte man den aktuellen Projektstatus dokumentieren. Ab hier sollte man meines Erachtens sich selber ein Bild machen. Das heißt, die Aussagen des Vorgängers können maximal noch ein Ausgangspunkt sein.

• Sprechen Sie mit den Stakeholdern, erfragen Sie die aktuelle Wahrnehmung und nehmen Sie selber die Erwartungen der Stakeholder auf. Man kommt auch nicht umher zu prüfen, ob wirklich alle Stakeholder identifiziert wurden. Binden Sie die nicht involvierten Stakeholder ein, bevor diese gegen das Projekt arbeiten!

• Prüfen Sie den Projektplan, passt er zu Ihrem Vorgehen, gibt es Differenzen von IST zu SOLL? Halten Sie die Ziele für erreichbar? Falls Sie für den Plan nicht gerade stehen können, planen Sie neu und reporten Sie diesen geeignet. Sie sollten aber jede Änderung genau begründen können, man wird Sie natürlich vergleichen und entsprechend sollte man Antworten haben, wenn man z.B. den Zeitplan oder das Budget ändern möchte. Meiner Erfahrung nach hat man für diesen Prozess ca. 2 Wochen Zeit, danach werden alle davon ausgehen, dass die Ursachen bei Ihnen zu suchen sind. Noch ein Tipp: Probleme reporten kann jeder- Projektmanager sollten aber Lösungen bieten.

Jetzt sollten wir also noch die zusätzlichen Schritte betrachten, die nötig sind, wenn der bisherige Projektleiter aus Gründen der Projektentwicklung gehen musste. Dazu sind alle bisher genannten Schritte notwendig, nur noch disziplinierter! Zusätzlich sollten Sie die Ursache für die vorhandenen Probleme finden, sonst ist es nur eine Frage der Zeit, bis man Sie auswechselt. Untersuchungen, warum Projekte scheitern, gibt es viele. Ich möchte hier aber noch meine Erfahrung wiedergeben, die natürlich gegenüber groß angelegten Studien auf wesentlich weniger Projekten beruht. Meines Erachtens sind die Fehlerquellen, die für das Scheitern von Projekten die Ursache sind, folgende:

1.) Mangelhafte Kommunikation: Stakeholder arbeiten aktiv gegen das Projekt, weil sie nicht berücksichtigt wurden und wichtige Informationen nicht erhalten.

2.) Risiken sind nicht gemanaged worden und konnten entsprechend ihren Einfluss auf Projekte voll auswirken.

3.) Konsequenzen aus Entscheidungen sind nicht ausreichend wiedergespiegelt worden. Leider fällt es vielen Projektmanager nach wie vor schwer, gegenüber dem Steeringboard und dem Projektsponsor unbequeme Wahrheiten auszusprechen und knicken in Diskussionen trotz besseren Wissens schnell ein.

4.) Ressourcenengpässe bei konkurrierenden Projekten: Oft wird dieser Punkt von verantwortlichen Projektleitern zuerst genannt, dahinter verbirgt sich aber meist einer der zuvor genannten Punkte.

Eine Sache zum Schluss: Es lohnt immer ein zweiter Blick. Wer feststellt, dass der Vorgänger Fehler gemacht hat, sollte nicht zu schnell urteilen. Fehler haben immer ein großes Potential, dass man nutzen sollte. Das gilt nicht nur für eigene Fehler. Wer auch fremde Fehler analysiert, baut meist ein Verständnis für den Anderen auf und erspart es sich, denselben Fehler selbst machen zu müssen.

Weiterhin viel Erfolg wünscht Markus

Kommentieren