Direkt zum Hauptbereich

Was muss man bei Projekten mit mehreren Vertragspartnern beachten? Teil (2/2)

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.

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

Beliebte Posts aus diesem Blog

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Wie starte ich ganz konkret mit einem neuen Scrum Team?

Manche Agilisten fühlen sich überfordert, schnell ein Scrum-Team aufzusetzen. Sie haben ein Seminar nach dem anderen besucht und kennen so viele Techniken und Methoden, dass sie am Ende gar nichts davon anwenden. Das war nicht der Sinn des Scrum Guides. Hier ist mein Vorschlag für einen Teamstart.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Wie verändert man das Mindset einer Organisation?

Ist in der Veränderungsarbeit das Ziel das Ziel? Oder doch eher der Weg?