Eine erfolgreiche Vereinbarung für agile Projekte – das agile.agreement

 

 

Agilität ist in aller Munde. Unabhängig davon ob man Agilität als gut oder schlecht empfindet, Fakt ist – es werden immer mehr Projekte mit agilen Methoden umgesetzt. Damit ergeben sich für uns alle neue Herausforderungen – wir müssen gemeinsam lernen, die Agilität richtig einzusetzen. Damit wir dies erfolgreich tun können, müssen wir verstehen, dass eine agile Form der Projektabwicklung auf verschiedenen Ebenen angegangen werden muss – u.a. auch in deren Beschaffung sowie auf der kooperativen und kommerziellen Seite, die sich in einem Vertrag widerspiegelt. In diesem Beitrag möchte ich aufzeigen, wie ich zur Einsicht gekommen bin, dass die Beschaffung von agilen Projekten und damit verbunden die Verträge nicht wie konventionelle Projekte gestaltet werden können. Selbstverständlich in einer gekürzten Form *schmunzeln*.

 

Als ich begann, unsere ersten Kundenprojekte agil umzusetzen – damals noch als Lieferant von Software – habe ich eines gelernt:

 

 

Dem Kunden war es egal, WIE wir das Projekt umgesetzt haben, solange wir den gewünschten Leistungsumfang, zum gewünschten Termin im vorgesehenen Budget einhielten.

 

 

Unsere Kunden liessen sich zu Beginn nicht von der Agilität begeistern, obschon wir doch soooo davon begeistert waren.

 

Wir mussten einen Weg finden, unsere Kunden insbesondere auf der kommerziellen Seite genügend Sicherheit zu vermitteln, damit sie sich ohne wahrnehmbares grösseres Risiko auf eine agile Projektabwicklung einlassen konnten. Diese Herausforderung war zugleich die Geburtsstunde des agile.agreements.

 

Wir begannen deswegen, ein neues Vertragswerk und Mechanismen für die Abwicklung agiler Projekte zu entwickeln, mit dem wir unsere Kunden davon überzeugen konnten, dass diese Abwicklungsform für sie keine Nachteile, sondern viele Vorteile hatte. Wir schufen gegenüber unseren Kunden Sicherheit und Vertrauen, indem wir in unseren Verträgen für agile Projekte viel ausführlicher und präziser als bisher die Kooperation im Projekt, das Projektvorgehen, den Umgang mit dem Ungewissen resp. der Komplexität und die Absicherung unserer gegenseitigen kommerziellen Risiken regelten. Wir nannten diese Aspekte die «Rules of Game» (Spielregeln). Unsere Überzeugung ist:

 

 

Je unklarer der Leistungsumfang, desto ausführlicher und präziser müssen die «Rules of Game» geregelt sein.

 

 

 

Damit war die Basis gelegt. Mithilfe des agile.agreements konnten wir breiter und erfolgreicher als zuvor Kunden für unsere agile Projektvorgehensweise gewinnen. Natürlich konnten wir nicht alle Kunden davon überzeugen, das war auch nie unsere Absicht. Und außerdem eigneten sich auch nicht alle Projekte für eine agile Projektabwicklung – das muss ich an dieser Stelle nicht weiter erläutern. Schließlich konnten wir aber denjenigen Kunden, die sich darauf einließen, Sicherheit und Verlässlichkeit vermitteln, damit sie genügend Vertrauen aufbauen konnten, sich mit uns auf einen neuen Weg der Projektabwicklung einzulassen. Interessanterweise empfand ich diese Kundenbeziehungen immer als die partnerschaftlicheren und persönlicheren.

 

Einige Jahre später wechselte ich in die Beratung und begann, mich auch mit der öffentlichen Beschaffung von komplexen Software Projekten auseinanderzusetzen.

 

Ich erkannte für mich relativ schnell, dass die Beschaffung solcher komplexer Projekte mit den konventionellen Beschaffungsansätzen nicht möglich resp. suboptimal war.

 

Das Ganze verstärkte sich zusätzlich, wenn man ein agiles Projektvorgehen zur Umsetzung wählte, das sich ideal für die Umsetzung komplexer Projekte eignete. Es lag für mich auf der Hand, dass alle «intellektuellen Dienstleistungen», die auf einer «kreativ schöpferischen Leistung» basieren, die genau gleichen Herausforderungen in deren Beschaffung hatten.

 

In Verlaufe dieser Auseinandersetzung kam mir die Idee, dass genau das, was wir jahrelang mit dem agile.agreement praktizierten, die Lösung für dieses Problem war. Denn bei der Beschaffung komplexer Projekte ist der Leistungsumfang oft unklar und muss im Projekt zusammen mit dem künftigen Partner (agil) entwickelt werden.

 

Dies bedeutet, dass sich die Ausschreibung statt auf die zu beschaffende Software auf die Beschaffung der richtigen Kooperation (richtigen Partner, Kooperation, Vorgehen, Sicherheit, Vertrauen etc.) fokussieren sollte.

 

Denn der Erfolgsfaktor eines (agilen) Projektes ist, den für sich richtigen Partner (Lieferanten) zu finden, der in der Lage ist, die gestellte Problemstellung (Leistungsumfang, Termin, Budget) zusammen zu lösen. Die Software resp. das Produkt, das zur Lösung beiträgt, ist sekundär. Dies ist ein Paradigmawechsel, wenn man sich heute die gängige Praxis der Ausschreibungen von Softwareprojekten über die Ausschreibungsplattform simap.ch ansieht. Für alle Skeptiker noch dies:

 

 

Die heutigen gesetzlichen Rahmenbedingungen für die Beschaffung in der öffentlichen Hand sind zwar verbesserungswürdig, lassen jedoch genügend Spielraum offen, damit wir sofort mit der Umsetzung solcher «neuartigen» Ausschreibungen beginnen können.

 

 

Ich selbst durfte dies bereits mehrfach in Ausschreibungen der öffentlichen Hand in der Schweiz beweisen.

 

So möchte ich alle diejenigen, die sich mit meinem Beitrag angesprochen fühlen, dazu aufrufen, die eigene Beschaffungspraxis zu hinterfragen und zu ändern und eure Kollegen dazu zu ermutigen, den gleichen Weg zu gehen. Dazu gehören die Schaffung neuer Eignungs- und Kriterienkataloge inkl. der Preisbewertung, sowie Verträge in der Art des agile.agreements, die sich auf die Kooperation mit dem Partner fokussieren. 

 

Es braucht die Einsicht, dass sich komplexe Projekte nicht mittels endloser Spezifikationen erschlagen lassen, sondern getreu dem agilen Manifest:

 

«Kooperation vor Spezifikation»

• Regle zuerst die Kooperation, das Vorgehen und den Umgang mit dem Ungewissen (Komplexität), damit Du für Dein Projekt den richtigen Partner findest, um in einer partnerschaftlichen Zusammenarbeitsform erfolgreich zu sein.
• Beschreibe danach den groben Rahmen des Leistungsumfangs nach EDUF (Enough Design Upfront) statt BDUF (Big Design Upfront), damit ein gemeinsames Zielbild der zu lösenden Problemstellung vorliegt.

 

Good practices der Rules of Game:

 

 

 

Mehr Informationen sowie ein kostenloser Download von Unterlagen sind unter www.agileagreement.com verfügbar.

 

Thomas Molitor, Senior Consultant & Partner bei crossmind inc., Co-Founder von agilist.cooperative