Erfahrungen aus Projekten und daraus abgeleitete Forderungen

Erfahrung 1: Je mehr ein Projekt „ab Fliessband“ gemacht wird, desto weniger Aufmerksamkeit kommt ihm zu. Gemeint sind z.B. lange Projekte, im Verlauf derer die Mitarbeiter anfangen, alles routinemässig zu erledigen, oder Projekte, die zum Tages- und Kerngeschäft eines Unternehmens gehören.
Konsequenz: Die Erstmaligkeit eines Projekts herausstreichen. Projekte kurz halten, in Teilprojekte aufsplitten. Wechselnde Projektleiter, Berater, Mitarbeiter.

Erfahrung 2: Verminderte Aufmerksamkeit äussert sich dann z.B. dadurch, dass Anfragen und Anforderungen („Requests“) überhört und ignoriert werden.
Beispiele:

  • In einer Krisensituation bat ich einen Projektmitarbeiter, mir die verabredeten Zeiten der Konferenzgespräche zu mailen. Ich erhielt sie nie.
  • Der Kunde bat immer wieder, dass ein Vertreter des Projektmanagements, das aus Globalisierungsgründen weit ab vom Geschehen war, vor Ort sein soll. Der Lieferant hat sich nicht einmal die Mühe gemacht, die Forderung zu diskutieren.
  • Der Kunde bat, das System durch einen Sicherheitsspezialisten überprüfen zu lassen. Auch das hat der Lieferant nicht einmal zur Kenntnis genommen. Als das System gehackt wurde, war es leider zu spät.

Vieles wird natürlich „überhört“, weil es unangenehm ist und Kosten verursachen würde. Bei der Vertragsverhandlung war dem Kunden noch nicht klar, wie wackelig ihm das System erscheinen wird, so dass er das Bedürfnis nach einem Sicherheitscheck haben könnte. Der Lieferant will sich die diesbezüglichen Kosten sparen.

Konsequenz: Mehr Sorgfalt während den Vertragsverhandlungen! Haftung und Verantwortung explizit ansprechen. Projektführerschaft klären. Ist der Lieferant Projektführer, muss der Kunde den Projektprozessen des Lieferanten folgen. Andernfalls muss der Lieferant „Regiearbeiten“ („Time & Material“) abrechnen können.

Erfahrung 3: Man macht sich zu lange vor, alles im Griff zu haben. In oben erwähnten Fall, wo ein System gehackt wurde, noch bevor das entsprechende Integrationsprojekt abgeschlossen war, nahm das Management des Lieferanten erst nach dieser Krise an den Konferenzgesprächen teil.
Dass sich das Management kaum um Projekte kümmert hat seinen Grund auch darin, dass Eskalationen, die vom Projektleiter ausgehen, vom Management nur punktuell aufgenommen werden, während sie sich im Projekt hochschrauben. In einer Serie von Eskalationen ist jede eine Folge der Vorgängereskalation. Die Dringlichkeit und Schwere der Projektsituationen nehmen zu. Beim Management kommen aber alle Eskalationen gleich dringlich an, weil sich das Management zwischen zwei Eskalationen mit anderen wichtigen Geschäften befasst. So denkt sich das Management wohl bei jeder Eskalation (ausser der ersten):

Ach, jetzt eskaliert dieser weinerliche Typ von Projektleiter schon wieder. Kann der denn nicht endlich Ruhe geben?

Konsequenz: Der Projektmanager muss sich immer auch um das Projektumfeld kümmern. Das Projektumfeld ist alles im Unternehmen, das nicht zum Projekt gehört. Wenn das Umfeld nicht zum Projekt passt, funktioniert das Projekt nicht. Ein guter Projektmanager versucht daher, das ganze Unternehmen zu führen und nicht nur das Projekt. Das muss er sich bei der Übernahme des Projekts vor Augen halten. Gibt es mehrere Projektmanager im Unternehmen, kann es zu Kollisionen kommen. Der CEO muss Schiedsrichterfunktion übernehmen und wird so in die Projekte eingebunden.

Erfahrung 4: Oft sind die Prozesse beim Kunden und beim Lieferanten nicht aufeinander abgestimmt, was zu Verzögerungen im Projekt führen kann. Beispielsweise verlangte der Lieferant, dass Produktefehler via Hotline kommuniziert werden. Von dort gehen sie direkt zu der Entwicklung. Beim Kunden kann aber nur das Backoffice die Hotline des Lieferanten erreichen, nicht aber das Engineering, das für die Projekte zuständig ist. Resultat: Der Projektleiter des Kunden kommuniziert zum Projektleiter des Lieferanten. Dieser hat nur einen informellen Draht zu der Entwicklung, so dass die Fehlerberichte des Kunden möglicherweise versanden.
Konsequenz: Im Projektkickoff müssen die Prozesse über das Projekt hinaus diskutiert werden. Sie gehören zum Projektkontext. In Projekten mit mehreren Lieferanten und Unterlieferanten wird es immer Schnittstellenprobleme zwischen den vielen Unternehmen geben. Ein Projekt ist eine Supply Chain, nur gibt es noch keine Softwarelösungen dafür. Bis es soweit ist, müssen Multiparteienprojekte unbedingt Personen beschäftigen, die Koordinationsfunktionen haben und von allen Parteien gleichmässig bezahlt werden.

Das sind zum Teil schmerzhafte Forderungen, die ich da stelle, daher werden sie wohl auch überhört und ignoriert. Sie könnten ja noch Kosten verursachen! Solange diese Forderungen jedoch nicht umgesetzt werden, werden Projekte weiterhin schlechte Resultate liefern und Milliarden Zusatzkosten verursachen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.