Anwendungsbereiche für „Formale“ und Agile Projektmethodiken.
Bei der Wahl des richtigen Vertragstyps gibt es nicht mehr nur „einen“ Vertragstyp, der in Betracht kommt. Fachliche Aspekte der zu wählenden Projektmethodik stehen im Vordergrund, sie bedingen dann die Auswahl des juristischen Modells und der inhaltichen Ausgestaltung des Vertrags.
Als „formale“ Projektmethodike bezeichneich Methodiken, die wie die Kaskade einen starren, formalisierten Prozeß beschreiben. Daß dieser in der Praxis beinahe nie eingehalten wird, ist erstmal nicht zu berücksichtigen. Diese Methodiken spiegeln vieles wieder, was der Jurist aus dem Werkvertragsrecht kennt. Ein klarer, fest definierter Erfolg soll erreicht werden, ganz bestimmte Prozesse zu seiner Erreichung sind einzuhalten. Eine starre Methodik wäre z.B. ein Fixpreis Projekt „Werkvertrag gegen Pflichtenheft“.
Agile Projektmethodiken zeichnen sich dadurch aus, daß das Ziel des Projekts nicht starr ist, daß die Mitwirkung des Kunden bei der Planung zwingend erforderlich ist und die Planung eben integraler Bestandteil des Prozesses ist, der dem Vertragsabschluß folgt.
Es handelt sich bei der nachfolgend geschilderten Aufzählung um meine persönliche Einschätzung, die sich aus den letzten Jahren ergeben hat. Dabei ist natürlich zu berücksichtigen, dass die Einsatzfelder der agilen Projektmethodiken in den letzten Jahren zunehmen. Diese hat sich aber bestimmt noch nicht zahlenmäßig so weit verbreitet, dass ich über wirklich ausreichend statistisches Material verfüge, um hier abschließend Aussagen machen zu können.
Nach meiner Einschätzung setzen agile Projektmethodiken voraus, dass
– beide Vertragsparteien genügend fachlich versierte Mitarbeiter beschäftigen, welche sich mit Projekten auskennen. Der hohe Kommunikationsaufwand und auch der Umstand, dass man die Aussagen der jeweiligen Vertragspartner richtig bewerten können muss, bedingt nach meiner Aufassung, dass agile Projekte sich vor allem dann eingen, wenn „onsite“ gearbeitet wird.
– das Projekt schnelle Ergebnisse liefert. Das Wort Ergebnis ist hier weniger im Sinne eines Erfolges zu verstehen, der vorab von den Parteien definiert wurde, sondern darin, dass der Auftraggeber durch die Präsentation der einzelnen Prototypen zufrieden gestellt wird.
– der Auftraggeber selbst in der Lage ist, bei der Planung ständig mitzuwirken. Auch deshalb der oben genannte Hinweis, dass agile Projektmethodiken eigentlich nur dann sinnvoll einsetzbar sind, wenn der Auftraggeber über ausreichend Personal verfügt, welches in der Lage ist das fachliche Anforderungsprofil zu erstellen und zu überprüfen.
– der Scope der einzelnen Arbeitsanschnitte überschaubar ist, da sonst die von den agilen Projektmethodiken geforderten engen Zyklen des Abgleichs und der Erstellung nicht eingehalten werden können.
Agile Projektmethodiken sollten nicht eingesetzt werden, wenn
– zwingende fachliche oder gesetzliche Anforderungen zu erfüllen sind. Agile Projektmethodiken zeichnen sich dadurch aus, dass nicht ein vorab feststehender Erfolg erreicht wird, sondern dass die Kundenzufriedenheit im Laufe des Projektes erreicht und gehalten wird. Wo es aber nicht um die näher definierbare Kundenzufriedenheit, sonder darum geht, dass mit einer bestimmten Summe Geld ein bestimmter Erfolg erreicht wird, sind vermutlich Formalprojektmethodiken wie die Kaskade oder Vmax die bessere Wahl.
-jegliche Changes beim Kunden zu langwierigen internen Abwegungsverfahren führen. Es macht einfach keinen Sinn, agile Projektmethodiken zu wählen, wenn die Mitarbeiter des Kunden jedes Mal lange warten müssen, bevor sie das „Go“ für den nächsten Schritt oder die Erstellung des nächsten Prototypes erhalten. Dann kann man ebenso gut nach der Vmax-Methode in bestimmten Zyklen arbeiten und eine Festvorgabe einhalten.
– nur wenig Kommunikation mit dem Kunden stattfindet oder die Gefahr besteht, dass grundsätzliche Missverständnisse mit dem Kunden auftreten.Agile Projektmethodiken funktionieren eigentlich nur dann, wenn viel Kommunikation zwischen den Parteien stattfindet und die Möglichkeit besteht, auftretende Missverständnisse schnell zu beseitigen. Entsprechende Missverständnisse können auch bei formalen Projektmethodiken auftreten. Man kann allerdings mit Recht einwenden, dass diese Kriterien für fomalisierte Verfahren gelten, weil grundsätzliche Schwierigkeit bei der Interpretation von Lasten- und Pflichtenheft auch nur durch einen hohen Aufwand an Kommunikation zwischen den Parteien zu vermeiden sind.
– die einzelnen Zyklen zu lang brauchen. Eine der großen Vorteile der agilen Projektmethodiken besteht darin, dass Abweichungen zwischen den Vorstellungen des IT-Unternehmens und des Kunden schnell transparent werden. Die grüßte Sorge des Kunden besteht in IT-Projekten immer darin, dass die Programmierer des IT-Unternehmens monatelang in einem Keller verschwinden und dann strahlend mit einem Produkt auftauchen, welches kein Mensch gebrauchen kann. Der schnelle Abgleich zwischen der Vorstellungswelt des Kunden und dem zu erstellenden Produkt ist ein wesentlicher Vorteil agiler Methodiken. Falls allerdings zu lange Zeitspannen vergehen, kann dieser Abgleich nicht stattfinden, dies spricht aber eher dafür, dass man egal in welcher Welt man sich befindet – in der formalisierten oder in der agilen Projektmethodik – man die Entwicklungszyklen nicht zu weit anwachsen lässt.
