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.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

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.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.

Wer liest, hat mehr vom Buch #12: Der Kopf ist rund... (Teil 1)

Welche Bücher waren oder sind für mich und meine Arbeit hilfreich, prägend und wichtig? Für mich sind das Bücher, die mir helfen, die Welt und ihre (v.a. menschlichen) Phänomene besser zu verstehen. Das bedeutet auch, mich, meinen Fokus und mein Denken zu hinterfragen und anzupassen. Kurz: Neues zu lernen. Und sei es noch so unangenehm und anstrengend.* /1/2/

Scrum und Kennzahlen (KPIs, Metriken)

In regelmäßigen Abständen hören wir die Frage, welche Kennzahlen (neudeutsch KPIs) bei Scrum sinnvoll sind. Zeit für einen längeren Beitrag, auf wichtige Ressourcen zu verweisen. Der Scrum-Guide selbst gibt dazu keine erschöpfende Auskunft. Und das hat seine Gründe.

Spielerisch lernen, was "agil" bedeutet: Das Ball Point Game

Seit einigen Jahren verwenden wir für unsere Organisationsentwicklungsprojekte agile Methoden. Ganz am Anfang eines Projekts möchten wir als externe Berater den Projektteilnehmern im Kundenunternehmen den Grundsatz "rasche Feedback-Zyklen statt eines perfekten Projektplans" nahe bringen. Die besten Erfahrungen haben wir dabei mit einem Spiel gemacht,  das die Besonderheiten dieses neuartigen Vorgehens schlagend demonstriert.