Konzepte – hach ja. Fein säuberlich und präzise spezifizierend sollen sie dienen als Grundlage für Festpreisangebote. Das Budget ist nun einmal limitiert und man will als Kunde eben ganz genau festgelegt haben was geliefert wird. Man scheut keine Aufwände ein Konzept-Dokument auszuarbeiten welches man dem Dienstleister vorlegt. Speziell im Zusammenhang mit ECM und Alfresco tauchen immer wieder solche Dokumente in unsere Mailboxen auf – mit einer Bitte um Prüfung oder konkretem Angebot. Die Autoren hatten in den meisten Fällen keine oder wenig Erfahrung mit ECM – fachlich und auch technisch mit Alfresco.
In all unseren Fällen schien es mir absurd eine Aussage in Bezug auf Aufwand zu machen. Zu viele Fragen sind in der Regel noch ungeklärt – allen Bemühungen des Kunden zum trotz. Und wir sind ja auch nicht Gott, dass wir alles wissen. Außerdem zeigt die Praxis, dass wir auf dem Weg zum Ziel viel lernen und Entscheidungen revidieren. Als Dienstleister weiß man sowas natürlich und hält sich bei Festpreisangeboten Hintertürchen offen, so dass man bestimmte “Zusatzaufwände” als Change-Request eintüten kann.
Am Ende des Tages ist Fakt, dass der Großteil aller IT-Projekte unter den Aspekten Budget und Funktionalität in die in die Hose gehen. Wer es ganz genau wissen will kann Details in den Chaos Reports der Standish Group nachlesen. Analog zum CAP-Theorem verteilter Systeme müssen wir einsehen, dass es schlichtweg nicht möglich ist Zeitrahmen, Funktionsumfang und Preis eines IT-Projektes zu fixieren.
Einführung von Agilität
Das Agile Manifesto zeigt sehr schön auf wo Umdenken erforderlich ist. Natürlich ist uns klar, dass tradionelle Prozesse und Strukturen in Unternehmen den “neuen” agilen Anforderungen im Weg stehen. Ebenso ist klar, dass sich diese Umstände nicht von heute auf morgen ändern werden. Die Orientierung an den zwölf Prinzipien hilft uns ganz hervorragend bei der Projekt-Arbeit. Aus unserer Sicht muss nicht zwingend 100% Scrum nach Lehrbuch zum Einsatz kommen. Das Allerwichtigeste ist letztlich eine gut funktionierende Kommunikation. Und das kann durchaus auch in einem verteilten Team hervoragend funktionieren – MySQL sei als Bespiel genannt.
Wie sollte nun ein Projekt-Vertrag aussehen ?
Traditionell gibt es den Festpreis-Vertrag mit Change-Request Hintertürchen und den Time & Material Vertrag der unmittelbar nach angefallenem Aufwand abrechnet. Letzerer ist insofern für den Dienstleister bequem, als dass hier das Risiko voll beim Auftraggeber liegt.
Im Buch “Der agile Festpreis” wird ein für agiles Vorgehen konzipierter Vertrag als Evolution des traditionellen Festpreises vorgestellt. Preis und Fertigstellungstermin sind hier fix. Grundsätzlich setzt das Verständnis dieses Vertrages ein wenig an agilem Basiswissen voraus.
Im Gegensatz zu den traditionellen Verträgen sind in diesem Modell vorgesehen:
- Risiko Teilung zwischen den Parteien
- Checkpoint-Phase um zu prüfen ob die Zusammenarbeit funktioniert
- Ausstiegspunkte damit eine Partei auf Wunsch die Zusammenarbeit beenden kann
- Modell zur Steuerung des Projekt Inhaltes (Scope-Governance-Prozess)
- Scope-Eskalationsprozess falls keine Einigung in Bezug auf Inhalt möglich ist
What we really do
Die meisten unserer Kunden haben wenig Erfahrung mit Agile im weitesten Sinne. Im Rahmen eines einfachen Angebotes ist es mit Hinblick auf den Aufwand schlichtweg nicht sinnvoll dieses nach dem Modell des agilen Festpreises auszuarbeiten. Festpreise mit Aufwänden von mehr als zehn Personentagen machen wir in der Regel gar nicht. Bleibt also nur noch das gute alte Time & Material Angebot. Auch wenn der Kunde hier grundsätzlich das Risiko trägt, so kann man es doch signifikant minimieren indem man die kritischsten Dinge in sehr kurzen Iterationen von ein paar Tagen zuerst umsetzt. Erfreulicherweise ist es bei uns in jüngster Vergangenheit sogar so, dass einige Kunden welche mit einem Konzept und einer Festpreisanfrage auf uns zu kamen zu diesem Vorgehen haben umstimmen lassen. Ich glaube sie sind bisher mit den Ergebnissen zufrieden. ;)