Projektstart – warum tun wir uns damit so schwer?
“Sage mir wie Dein Projekt gestartet ist und ich sage Dir, wie Du es voraussichtlich abschließen wirst.”
Alle Projektmanagement Methoden beschreiben Aktivitäten und/oder Prozesse für einen “optimalen” Projektstart. PRINCE2 widmet diesem Thema sogar zwei Prozesse: “Vorbereiten eines Projektes” und “Initiieren eines Projektes”. In dem Prozess “Vorbereiten eines Projektes” will man methodisch mit geringem Aufwand einschätzen, ob sich die angestrebte Projektidee überhaupt lohnt und ob es hierfür einen entsprechenden Business-Case gibt. Die Initiierungsphase mit dem Prozess “Initiieren eines Projektes” ist dafür gedacht, eine solide Grundlage für das Projekt zu schaffen, in dem der Projektmanager die internen Verfahren für z.B. Change- und Qualitätsmanagement festlegt, er in Abstimmung mit dem Lenkungsausschuss einen Kommunikationsplan erstellt und den Projektplan erarbeitet als Grundlage für die spätere Projektdurchführung und Projektsteuerung. Idealerweise werden diese Arbeiten von dem eingesetzten Management, z.B. Lenkungsausschuss überwacht, geprüft und genehmigt.
So die Theorie!
Die gelebte Praxis beim Projektstart
Ich beobachte in der Praxis immer wieder eine ganz andere Vorgehensweise: Die Organisationen sind getrieben durch Kunden und Markterwartungen. Aus Sicht von IT-Abteilungen und deren Projekten sind dies die Fachbereiche, welche möglichst schnell bestimmte Anforderungen umgesetzt haben wollen. Hier zwei kurz beschriebene Fälle:
Fall 1 – Einführung einer Software zur Prozesssteuerung in einem Health Care Unternehmen
Das Fatale an diesem Projektstart war, dass sowohl der Projektleiter als auch der Auftraggeber vor vollendete Tatsachen gestellt wurden. Die einzuführende Software zur zukünftigen Prozesssteuerung war schon ausgewählt. Der Dienstleister stand fest und die Verträge waren unterzeichnet. Was nicht fest stand, war
- die zu entwickelnden fachlichen Prozesse, auf welche die Software noch angepasst werden musste
- die Art der Zusammenarbeit mit dem Dienstleister
- der Scope des Projektes – dieser wurde in den ersten 2 Monaten von einem lokalen Einführungsprojekt in einen weltweiten Roll-out der Software verändert
Die zuarbeitenden Fachbereiche waren mit der Vorgehensweise und dem Prozessdesign überfordert. Zum Schluss stellt sich heraus, dass der Softwarehersteller/ Dienstleister nicht die notwendigen Ressourcen zur Erbringung der Leistungen hatte. Der Projektleiter stand quasi vor dem dritten Neubeginn des Projektes. Hinzu kamen Querelen mit Teilen des Managements.
Problemfelder:
- Die entscheidenden Personen des Projekt-Management-Teams waren nicht an allen wesentlichen Entscheidungen zum Projektstart beteiligt (z.B. Auswahl der Software und des Dienstleisters)
- Die Zusammenarbeit mit dem Dienstleister bzgl. des Projektmanagements war nicht definiert und vereinbart
- Für den Auftraggeber schien zu Beginn ein methodischen Vorgehen eher hinderlich
Fall 2 – Entwicklungsprojekt bei einem Automobilzulieferer
Die Herausforderungen bei diesem Projekt war es, ein Konsortium unter “einen Hut” zu bekommen. Der Projektmanager sah es nicht als notwendig an, eine zentrale Projektplanung zu erstellen, um so ein Projektcontrolling mit einer entsprechenden Fortschrittsmessung zu etablieren. Die Basis für die Fortschrittsmessung war ausschließlich die Rückmeldungen der Zeiten der einzelnen Partner. Eine Betrachtung des Fortschritts auf Basis der Arbeitspakete fand zu Beginn nicht statt. Des Weiteren wurde kein Lenkungsausschuss eingesetzt, in dem die verschiedenen Interessenvertreter vertreten waren.
Problemfelder:
- Keine aussagekräftige Fortschrittssteuerung möglich
- Bei notwendigen Entscheidungen und Eskalationen stehen nicht die richtigen Ansprechpartner zur Verfügung (keine klaren Rollen und Verantwortlichkeiten)
In beiden Projekten war die Startlinie schon überschritten, die Probleme, die während des Projektes auftreten, entstehen nicht während des Projektes sondern sind Ergebnisse von Versäumnissen zu Beginn des Projektes. Wie im “richtigen Leben” holen uns Versäumnisse oder Fehler meist später ein. Ich bin mir sicher, dass alle Leser dieses Beitrags auch Beispiele aufzeigen könnten, wo gemachte Fehler zu Beginn eines Projektes während des Projektverlaufs Probleme verursacht haben.
Einfach mal ins Wasser zu springen, führt nicht zum Erfolg
Was tun?
Aus meiner Erfahrung der letzten 20 Jahre sollte jeder Projektmanager bzw. Auftraggeber eines Projektes versuchen, folgende drei Kernfelder zu Beginn eines Projektes zu beachten:
- Auftragsklärung
- Verantwortlichkeiten klären –Verantwortlichkeiten der externen Partner
- Projektvision erstellen
Warum sind diese 3 Themenfelder so wichtig?
Auftragsklärung
Auftragsklärung ist ein essentieller Bestandteil der Projektplanung. Als Projektleiter muss ich die Erwartungen des Kunden bzw. Auftraggebers verstehen. Ich muss wissen: Gibt es eine genaue Beschreibung des Produktes (Spezifikation) oder gibt es nur wage Ideen, welche umgesetzt werden sollen. Ist ersteres der Fall, kann ich eine genaue Spezifikation mit Kriterien zu Abnahme erstellen. Gibt es nur wage Ideen, muss ich mit dem Auftraggeber bzw. Kunden vereinbaren, wie das Projektteam zu einer genaueren bzw. endgültigen Spezifikation kommt. Dies kann bedeuten, dass ich für die Planungsphase Zeit einplanen muss, um genau diese Informationen zusammen zu tragen. Versäumt man diesen Schritt, kann es sein, dass man die Erwartungshaltung des Auftraggebers bzw. Kunden nicht trifft und es zu vielen Diskussionen um das eigentliche Projektprodukt kommt.
Verantwortlichkeiten klären – Verantwortlichkeiten der externen Partner
Ein wesentlicher Erfolgsfaktor für einen guten Projektstart ist die Festlegung der Rollen und Verantwortlichkeiten der beteiligten Personen. Dies gilt sowohl für das „interne“ Projektteam als auch für die externen Dienstleister. Für den Projektleiter und seine Arbeit ist es von enormer Wichtigkeit, dass er mit dem Auftraggeber seiner Befugnisse abklärt. Er kann seine Spielräume für Befugnisse definieren z.B. welche inhaltlichen/fachlichen Entscheidungen kann ich selbst treffen, welche Spielräume habe ich als Projektmanager bezogen auf das Budget und an welchen Punkten benötige ich die Kompetenz des Lenkungsausschusses bzw. des Auftraggebers.
Hierbei bleibt anzumerken, dass dem Lenkungsausschuss mit dem Auftraggeber an der Spitze eine wesentliche Rolle bzgl. des Projekterfolgs zu kommt. PRINCE2 beschreibt z.B. den Auftraggeber / Project-Sponsor als „ultimative responsible“ für das Projekt. Der Auftraggeber ist auf Grund seiner Entscheidungskompetenz verantwortlich für den Projekterfolg – nicht der Projektmanager. Der Projektmanager hat die zentrale Verantwortung für das Tagesgeschäft – planen, delegieren, überwachen und steuern. Er kann keine grundlegenden Entscheidungen treffen. Diese Verantwortung liegt beim Management.
Projektvision erstellen
Auch wenn dieses Zitat schon etwas abgedroschen klingt: “Wenn Du ein Schiff bauen willst, dann rufe nicht die Menschen zusammen, um Holz zu sammeln, Aufgaben zu verteilen und die Arbeit einzuteilen, sondern lehre sie die Sehnsucht nach dem großen, weiten Meer.”¹
Diese Aussage ist auch für modernes Projektmanagement ein wesentlicher Faktor: Eine Vision für das Projekt zu haben. Wir wollen motivierte Projektmitarbeiter und keine Arbeitsroboter. Also ist es auch eine wesentliche Aufgabe des Managements, diese Mitarbeiter “abzuholen” und diesen das “große Ganze” zu erklären.
Eine Projektvision bietet allen Projektmitgliedern einen gemeinsamen Bezugsrahmen für das Projektvorhaben. Sicher ist es nicht einfach, für jedes operative Projekt eine Projektvision zu formulieren, dennoch ist es mehr als sinnvoll diese Zeit zu investieren.
Fazit
Gerade in den vielen IT-Projekten welche durch die Fachbereiche initiiert werden, welche einen großen Erfolgsdruck haben, tappen wir oft in die Falle, dass wir den dritten oder vierten Schritt vor dem ersten machen. Dies geschieht oft auf Grund eines hohen zeitlichen Drucks. Jedoch ist es oft sehr aufwändig und schwierig, Fehler im Projektverlauf zu korrigieren, welche ihre eigentliche Ursache im Projektstart haben. Deshalb müssen Projektorganisationen lernen, dem Projektstart – die ersten Schritte und Entscheidungen eines Projektes – als wesentliches Erfolgskriterium des Projektes anzusehen und diesem Teil des Projektes genauso viel Aufmerksamkeit zu schenken, wie der eigentlichen Produkterstellung.
Hinweise:
[1] Antoine de Saint-Exupéry (1900-44), französischer Flieger und Schriftsteller
“Wie funktioniert PRINCE2?” erfahren Sie hier.
Der Artikel bringt meiner Meinung nach in der Tat viele Missstände beim Projektstart auf den Punkt. Aus meiner Erfahrung geht er aber an der Praxis und auch an der Psychologie vorbei. Zwei Beispiele:
– Initiale Entscheidungen wie z.B. Auswahl von Partnern, Markteinführungsdatum oder Basistechnologien werden nach meiner Erfahrung aus strategischen Überlegungen von Geschäftsführern vorgenommen. Projektmanager oder gar Fachexperten sind in dieser Phase explizit nicht gewünscht.
– Verantwortung übergeben kann man nicht, da niemand Verantwortung übernehmen will.
Als Projektmanager ist man vor solche Tatsachen gesetzt. Man hat gar nicht die Möglichkeit, sie zu ändern. Das Aufzählen der Fehler im Artikel macht deshalb nur bedingt Sinn. Wirklich hilfreich wären Tipps, was man als Projektmanager tun kann, wenn der Projektstart nun mal so schlecht angesetzt ist wie er ist.
Ihre Meinung Herr Wendel teile ich voll und ganz. Die 3 angesprochenen Themenfelder sollten auch aus meiner Sicht am Anfang eines Projektes mit großer Sorgfalt behandelt und beachtet werden.
Aus meiner Erfahrung ist dies aber nicht immer möglich.
Immer wieder gibt es Faktoren die bedingen, dass es bereits einen Umsetzungstermin gibt bevor die eigentliche Anforderung komplett aufgenommen, formuliert und abgestimmt ist, also noch vor dem eigentlichen Projektstart. Dies kann aus den verschiedensten Gründen geschehen: mangelndes Verständnis ob des eigentlichen Themas, Termindruck seitens der Stakeholder, o.ä.
Derartige Umstände nehmen einem Projekt von Anfang an natürlich einen Teil der notwendigen Agilität, und bedingen einen der Umsetzung folgenden Nachlauf voller Fehlerbehandlung, der wenig effizient ist und nicht im Sinne des Projektes sein kann.
Konkret bezogen auf Ihr Fazit, sind aus meiner Sicht 2 Sachen wichtig: Zum einen Vertrauen gegenüber den Projektverantwortlichen und viel, viel Kommunikation!
Viele Grüße
Duncan Tietsche