Projekterfolg 100% über 30 Jahre, wie geht das ?

Tatsächlich sind weder Tricks noch Hexenkunst noch sonst irgendetwas besonderes notwendig, um ein Projekt erfolgreich zu führen und abzuschliessen.

Und ich bin mir sicher, daß die meisten Projektleiter alle Voraussetzungen kennen aber aus persönlichen oder politischen Gründen wider besseres Wissen einige der Punkte nicht beachten (können ode wollen)

Lasst uns den Ausgangspunkt betrachten:

Es gibt (hoffentlich) ein definiertes Projektziel, Zeit und ein Budget. Wird einer der Punkte nicht erreicht, ist das Projekt nicht erfolgreich beendet worden.

Projektziel

Ein nicht genau definiertes Projektziel, bei dem vor allem nicht genau beschrieben ist, wann das Projekt erfolgreich abgeschlossen ist, kommt häufiger vor, als man erwarten sollte. Vor allem bei IT Projekten ist das Ziel häufig sehr schwammig. Beispiel: Relaunch eines Webauftritts, bei dem nichttechnische Teilprojekte existieren und der Auftraggeber noch gar nicht weiss, wie das neue Design aussehen wird.

Dadurch werden Zeit- und Kostenschätzungen unmöglich.

Als Projektleiter muss ich diesen Teil als ein eigenes Vorprojekt vorziehen.

Ein Projekt ohne genaue Abnahmebedingungen ist kein Projekt. Fehlen diese, ist die Abnahme vom Wohlwollen des Auftraggebers abhängig.

Warum starten viele Projekte trotzdem? Der Projektleiter hat vielleicht keine Wahl, da der Auftraggeber Weisungsbefugnis besitzt. Der Projektleiter ist nicht untergeben, benötigt aber dringend einen Auftrag. Der Projektleiter vertraut auf das gute Verhältnis zum Auftraggeber. Und ich bin mir sicher, daß es noch viele weitere Gründe gibt.

Keiner davon ist hilfreich.

Änderungen am Projektziel während der Laufzeit

Kein Projektplan überlebt die ersten Projekttage. Änderungswünsche kommen immer, es sei denn, es ist ein Wasserfallprojekt, wo der Kunde erst zum Ende sieht, was er bekommt.

Aber Änderungen am Projektziel bedeuten, daß es sich um ein neues Projekt handelt. Also IMMER Auswirkungen auf die beiden anderen Punkte überprüfen und ALLE Punkte anpassen. Nie Änderungen ohne diese Anpassungen aufnehmen.

Bei IT Projekten können diese Änderungen sogar durch das ausführende Team hervorgerufen werden. Teilweise unsichtbar durch Entwickler, die mehr Features einbauen als gewünscht, weil deren Implementierung gerade auf der Hand lag und nur wenige Stunden zusätzlich benötigt. Dafür aber mehr Testaufwand bedeutet und auch potentiell die Stabilität beeinträchtigt.

Featureritis kommt häufig vor und wird nicht immer rechtzeitig erkannt. Dieses Thema von Anfang an kommunizieren um zu verhindern, dass schon am Anfang eine Version 2 gebaut wird, die der Kunde vielleicht nichteinmal will.

Zeit

Projektleiter müssen damit leben, dass ausführende Parteien IMMER versuchen, entweder besonders gut auszusehen und deshalb Zeit knapp kalkulieren, um ein gutes Angebot abgeben zu können, oder die Zeit sehr hoch anzusetzen, weil sie ein extrem hohes Budget vermuten oder wissen.

Mit der zweiten Version kann man gut leben, die erste Version wird schnell zum Problem. Denn auf die Frage, zu wieviel Prozent eine Aufgabe abgeschlossen ist gibt es selten eine korrekte Antwort. Wie oft haben wir alle schon noch Stunden vor dem geplanten Ende gehört: Kein Problem, trotzdem Hürden bekannt sind, für die noch keine Lösung gefunden wurde.

Als Projektleiter dieses Thema von Anfang an auf den Tisch bringen und klar kommunizieren.