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

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Selbstbewertungsfragen für den Alltag in Arbeitsgruppen aus Sicht von Mitarbeitenden

Welche Fragen können wir Mitarbeiter:innen stellen, um herauszufinden, ob agiles Arbeiten wirkt? Es gibt bereits eine Menge an Fragebögen. Aber ich bin nicht immer zufrieden damit.

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Microsoft Lists: mit Forms und Power Apps komfortabel mobil arbeiten

In meinem Kundenkreis sind viele Menschen, die den Arbeitsalltag nicht vorwiegend auf dem Bürostuhl sitzend verbringen, sondern "draußen" unterwegs sind. Vielleicht in Werkstätten oder im Facility-Management. Es ist so wichtig, dass die Schnittstellen zu den Abläufen im Büro gut abgestimmt sind. Microsoft 365 hat so einiges im Baukasten, man muss es nur finden und nutzen.  In diesem Artikel spiele ich ein Szenario durch, das auf Microsoft Lists, Forms und - für die Ambitionierteren - Power Apps setzt.

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.

Wie Agilität den Kundennutzen steigert - Einige Argumente für Berater:innen

In Zeiten wirtschaftlicher Unsicherheit fragen sich viele, ob agile Beratung noch eine Zukunft hat. Die Antwort liegt in der konsequenten Orientierung am Kundennutzen. Qualität setzt sich durch, wenn sie messbare Verbesserungen bei Umsatz, Kosten und Leistungsfähigkeit bewirkt, anstatt sich in Methoden und zirkulären Fragen zu verlieren. Dieser Artikel zeigt, wie agile Beratung nachhaltige Veränderungen in Unternehmen schafft und warum gerade jetzt gute Berater:innen gebraucht werden, um Organisationen widerstandsfähiger zu machen.

Warum eine Agile Transformation keine Reise ist

Die agile Transformation wird oft als eine Reise beschrieben. Doch dieser Vergleich kann viele Unternehmen in die Irre führen oder Bilder von unpassenden Vergleichen erzeugen. Transformationen sind keine linearen Prozesse mit einem klaren Ziel, sondern komplexe und dynamische Entwicklungen. Dieser Artikel zeigt, warum Agilität kein Weg mit einem festen Endpunkt ist.

Warum bringen Warum-Fragen so wenig?

Frust! Wieder gibt's am Ende des Meetings keine Lösungen, sondern nur Diskussionen darüber, wer was warum verbockt hat. Wieder geht nichts voran. Warum passiert uns das immer wieder? (Ha! Da ist sie wieder, die Warum-Frage.)