Das erste Scrum-Projekt ist für Kunde und Lieferant schon eine
interessante Herausforderung. In großen Konzernen brauche ich aber oft
mehrere Vertragspartner, um mein Projektproblem zu lösen. Die Webseite
wird von einer Agentur betreut, das SAP-System vom eigenen Rechenzentrum
und das Netzwerk von einem Dienstleister. Kann man dafür einen Vertrag
schließen?
Im ersten Teil habe ich auf das Rautenmodell von Shenhar und Dvir hingewiesen, dass uns für diese Situation wertvolle Hinweise gibt. Daraus lässt sich einiges für das Scrum-Projekt mit mehreren Vertragspartnern ableiten.
Zurück zu unserem Auftraggeber. Er hat die Wahl, einen Generalunternehmer zu beauftragen, der alle Flöhe hütet. Das ändert zwar das grundsätzliche Problem nicht, aber verlagert es zu einem anderen Vertragspartner. Allerdings müssen Generalunternehmer einen deutlichen Risikoaufschlag einplanen (z. B. 30%).
Wenn unsere Projektgruppe die Koordination selbst übernehmen möchte, sollte es auf folgende Dinge achten:
(1) Die Projektgruppe schließt mit allen Beteiligten einzelne Verträge ab oder holt entsprechende Angebote ein. In die Vereinbarungen fließen die Meetings und gemeinsamen Standards ein.
(2) Das Backlog muss besser gepflegt werden. Es reicht nicht aus, dass Storys für 1-2 Sprints ready sind. Wahrscheinlich brauchen wir Material für ein Quartal.
(3) Zu Beginn muss es einen gemeinsamen Workshop mit allen Beteiligten geben, um das Projektziel (Vision) und die Abhängigkeiten untereinander zu verstehen. Alle müssen aktiv ihre Erfahrungen austauschen, warum die Zusammenarbeit in der Vergangenheit schwierig war. Z. B. kann man von vielen Rechenzentren nicht erwarten, dass von einem Tag auf den nächsten Leitungen geschaltet oder virtuelle Maschinen installiert werden. Das Team muss sich auf wahrscheinliche Lieferzeiten einigen.
(4) Einmal im Quartal gibt es eine gemeinsame Releaseplanung, in der alle Teams ihre Backlogs vorstellen und in einzelnen Sessions Abhängigkeiten suchen und auflösen.
(5) Jedes Team muss so arbeiten, dass Abhängigkeiten von anderen vor Sprintbeginn aufgelöst sind. Sonst besteht höchstens eine Wahrscheinlichkeit von 50%, dass das Team im Review etwas liefern kann (Vorlieferant hat geliefert oder hat nicht geliefert).
(6) Die Product Owner müssen immer einen Plan B ausarbeiten. An welchen Themen soll das Team als nächstes arbeiten, wenn eine Vorlieferung ausbleibt.
(7) Ein wichtiger Standard ist, dass alle Teams die Schnittstellen ihrer "Bauteile" verhandeln. Das ist zwar erst aufwändiger, spart aber später Zeit, weil das Team alles hinter der Schnittstelle verändern darf, ohne andere fragen zu müssen.
(8) Eine große Motivation zur Zusammenarbeit macht das Geld aus. Überlicherweise werden Zahlungen an das Erreichen von Meilensteinen gebunden. Leider funktioniert das aus meiner Sicht nicht so gut, weil sich alle Beteiligten immer über die Qualität und Claims streiten. Der Lieferant A sagt, die Leistung wurde wie vereinbart abgeliefert. Aber aus irgendeinem Grund funktioniert sie bei Lieferant B und C nicht. Da ist wohl etwas in der Gesamtsteuerung schief gelaufen. Besser ist es aus meiner Sicht, die weitere Beteiligung am Projekt grundsätzlich in Frage zu stellen. Wenn die Arbeit mit einem Lieferant sehr schwierig war, wird er zwar für seine bisherigen Leistungen angemessen bezahlt, aber er bekommt keinen weiteren Folgeauftrag im Projekt. Dies muss man im Vertrag transparent machen ("Jede Projektphase wird gesondert beauftragt.").
(9) Es muss regelmäßige gemeinsame Reviews und Retrospektiven geben, um die Qualität und Velocity insgesamt zu erhöhen.
(10) Werkzeuge für automatisches Testen spielen eine noch größere Rolle. Durch automatische Tests fallen Abhängigkeiten und Fehler schneller auf.
(11) Allen Beteiligten müssen alle Standards bekannt sein und sich in der DoD und DoR wiederfinden.
Das Problem bei Systemprojekten ist selten, dass ein Lieferant nicht liefern will oder kann. Das Problem liegt in der Zusammenarbeit zwischen den Projektbeteiligten. Dies kann man durch die Art und Häufigkeit der Besprechungen, durch eine etwas genauere Vorbereitung, durch gemeinsame Standards und durch bewusste Haltepunkte steuern. Und diese Punkte lassen sich vertraglich regeln.
Im ersten Teil habe ich auf das Rautenmodell von Shenhar und Dvir hingewiesen, dass uns für diese Situation wertvolle Hinweise gibt. Daraus lässt sich einiges für das Scrum-Projekt mit mehreren Vertragspartnern ableiten.
Projekte mit mehreren Vertragspartner sind unsicherer
Als erstes müssen wir uns bewusst machen, dass dies eine andere Projektsituation ist, die mehr Aufwand erfordert. Um gemeinsam erfolgreich zu sein, müssen sich alle Beteiligten an mehr Regeln halten. Das ist ein Widerspruch zu dem bisherigen hemdsärmeligen Vorgehen. Die Grundaussage von Shenhar und Dvirs Buch ist, dass Projekte immer dann scheitern, wenn die Art, wie das Projekt gemanagt wird, nicht zur tatsächlichen Projektsituation passt. Sie haben extra ein Kapitel über Systemprojekte geschrieben, weil dies wohl besonders häufig unterschätzt wird.Zurück zu unserem Auftraggeber. Er hat die Wahl, einen Generalunternehmer zu beauftragen, der alle Flöhe hütet. Das ändert zwar das grundsätzliche Problem nicht, aber verlagert es zu einem anderen Vertragspartner. Allerdings müssen Generalunternehmer einen deutlichen Risikoaufschlag einplanen (z. B. 30%).
Wenn unsere Projektgruppe die Koordination selbst übernehmen möchte, sollte es auf folgende Dinge achten:
(1) Die Projektgruppe schließt mit allen Beteiligten einzelne Verträge ab oder holt entsprechende Angebote ein. In die Vereinbarungen fließen die Meetings und gemeinsamen Standards ein.
(2) Das Backlog muss besser gepflegt werden. Es reicht nicht aus, dass Storys für 1-2 Sprints ready sind. Wahrscheinlich brauchen wir Material für ein Quartal.
(3) Zu Beginn muss es einen gemeinsamen Workshop mit allen Beteiligten geben, um das Projektziel (Vision) und die Abhängigkeiten untereinander zu verstehen. Alle müssen aktiv ihre Erfahrungen austauschen, warum die Zusammenarbeit in der Vergangenheit schwierig war. Z. B. kann man von vielen Rechenzentren nicht erwarten, dass von einem Tag auf den nächsten Leitungen geschaltet oder virtuelle Maschinen installiert werden. Das Team muss sich auf wahrscheinliche Lieferzeiten einigen.
(4) Einmal im Quartal gibt es eine gemeinsame Releaseplanung, in der alle Teams ihre Backlogs vorstellen und in einzelnen Sessions Abhängigkeiten suchen und auflösen.
(5) Jedes Team muss so arbeiten, dass Abhängigkeiten von anderen vor Sprintbeginn aufgelöst sind. Sonst besteht höchstens eine Wahrscheinlichkeit von 50%, dass das Team im Review etwas liefern kann (Vorlieferant hat geliefert oder hat nicht geliefert).
(6) Die Product Owner müssen immer einen Plan B ausarbeiten. An welchen Themen soll das Team als nächstes arbeiten, wenn eine Vorlieferung ausbleibt.
(7) Ein wichtiger Standard ist, dass alle Teams die Schnittstellen ihrer "Bauteile" verhandeln. Das ist zwar erst aufwändiger, spart aber später Zeit, weil das Team alles hinter der Schnittstelle verändern darf, ohne andere fragen zu müssen.
(8) Eine große Motivation zur Zusammenarbeit macht das Geld aus. Überlicherweise werden Zahlungen an das Erreichen von Meilensteinen gebunden. Leider funktioniert das aus meiner Sicht nicht so gut, weil sich alle Beteiligten immer über die Qualität und Claims streiten. Der Lieferant A sagt, die Leistung wurde wie vereinbart abgeliefert. Aber aus irgendeinem Grund funktioniert sie bei Lieferant B und C nicht. Da ist wohl etwas in der Gesamtsteuerung schief gelaufen. Besser ist es aus meiner Sicht, die weitere Beteiligung am Projekt grundsätzlich in Frage zu stellen. Wenn die Arbeit mit einem Lieferant sehr schwierig war, wird er zwar für seine bisherigen Leistungen angemessen bezahlt, aber er bekommt keinen weiteren Folgeauftrag im Projekt. Dies muss man im Vertrag transparent machen ("Jede Projektphase wird gesondert beauftragt.").
(9) Es muss regelmäßige gemeinsame Reviews und Retrospektiven geben, um die Qualität und Velocity insgesamt zu erhöhen.
(10) Werkzeuge für automatisches Testen spielen eine noch größere Rolle. Durch automatische Tests fallen Abhängigkeiten und Fehler schneller auf.
(11) Allen Beteiligten müssen alle Standards bekannt sein und sich in der DoD und DoR wiederfinden.
Das Problem bei Systemprojekten ist selten, dass ein Lieferant nicht liefern will oder kann. Das Problem liegt in der Zusammenarbeit zwischen den Projektbeteiligten. Dies kann man durch die Art und Häufigkeit der Besprechungen, durch eine etwas genauere Vorbereitung, durch gemeinsame Standards und durch bewusste Haltepunkte steuern. Und diese Punkte lassen sich vertraglich regeln.
Kommentare
Kommentar veröffentlichen