Abrechnung und Vertragsarten bei agilen Softwareprojekten ­čçę­čç¬

Ein Thema, ├╝ber das man ungerne redet: Vertr├Ąge und Abrechnung. Denn wie rechnet man agile Softwareprojekte am sinnvollsten ab? Vor allem wenn der Aufwand 100 oder mehr Abrechnungstage betr├Ągt, ist es fast unm├Âglich einen fairen Preis zu finden. Im schlimmsten Fall versucht man dann, ein ohnehin schon sehr komplexes Projekt, noch komplexer zu planen und geht massiv mit Konzeption in die Vorleistung. Aber dabei gibt es doch schon einige Standardsituationen, an denen man sich orientieren kann.

Zielsetzung –

  • Grunds├Ątzlich m├Âchten wir im Vertrag einen Rahmen setzen, der Kooperation garantiert und Verletzungen von Kooperation ahndet.
  • Wir m├Âchten die anf├Ąnglich gegebene Komplexit├Ąt nicht durch einen noch komplexeren Plan oder Planungsprozess steigern.
  • Unsere Erfahrung zeigt: Empirie & Wissen zu L├Âsungen entsteht emergent w├Ąhrend des Projekts.
  • Wir m├Âchten teure Change Requests und der damit einherkommende Verwaltungs-Overhead vermeiden.
  • Wir streben hohen Business Value an – nicht die Diskussionem ├╝ber den Vertrag oder dessen Strafen.

Vertragsarten

Festpreis

  • Bezahlung nach Festpreis auf Basis eines Lasten-/Pflichtenheftes.
  • Bezahlung nach Abnahme.
  • Risiko 100% auf Dienstleister-Seite.
  • Anforderungen sind zum Teil nicht sch├Ątzbar.
  • Teuer f├╝r den Kunden
  • Kein Fokus auf Business-Value.
  • Teure Change-Requests.
  • Empirie & emergentes Wissen zu L├Âsungen entsteht w├Ąhrend Projekt.
  • Anforderungen ├Ąndern w├Ąhrend Projekt, da auch der Kunde lernt.

Das ist deutsches Werkvertragsrecht aus einer Zeit, als es noch keine Softwareentwicklung gab.

T&M – Time & Materials

  • Bezahlung Stundenweise
  • Solange bis das vereinbarte Projekt fertiggestellt ist.
  • Risiko liegt 100% auf Auftraggeber-Seite
  • Ohne weitere Elemente (Scrum, Eigenmotivation, etc.) gibt es wenig Anreiz f├╝r den Dienstleister hohen Business-Value zu liefern

Das ist das andere extrem. Je nach Situation, Klarheit von Anforderungen, M├Âglichkeiten des Kunden, kann reines T&M Sinn ergeben.

T&M mit Abbruch

  • T&M: Bezahlung Stundenweise
  • Kunde merkt nach einigen Sprints, dass nicht mehr viel Business Value zu holen ist.
  • Mit einem Vorlauf von z.b. 1 Sprint kann der Kunde jederzeit nach einem Sprint das Projekt beenden.
  • Vorlauf notwendig, damit der Dienstleister die Ressourcen umplanen kann.

Vorteile f├╝r beide Seiten, Kooperation wird gest├╝tzt.

“T&M on Steroids”

  • T&M: Bezahlung Stundenweise
  • Abrechnung nach abgeschlossenen Sprints
  • Kunde kann ohne Angabe von Gr├╝nden einen einzigen Sprint nicht bezahlen
  • Sonderk├╝ndigungsrecht des Dienstleisters, wenn der Kunde das 2. Mal einen Sprint nicht bezahlt.

Ergebnis: Verkettung beider Seiten in Kooperation. Der Kunde ├╝berlegt sich sehr genau, wann er einen Sprint nicht bezahlt. Der Dienstleister hat ein Interesse an guter, ergebnisorientierter Arbeit.

Agil mit Festpreis

  • Beiden Parteien ist bewusst, dass kein fixes Feature-Set geliefert werden kann. Das Budget aber ist fix definiert.
  • Es kann kein Gesamtwerk definiert werden.
  • Eine einzelne User Story stellt ein Mini-Gewerk dar, auf das Gew├Ąhrleistungsregeln angewandt werden.
  • Team kann User Stories ablehnen, wenn diese aus ihrer Sicht nicht ausreichend spezifiziert/sch├Ątzbar sind.
  • Abnahme des Mini-Gewerks im Sprint-Review. Bei Nicht-Abnahme (weil Story nicht erreicht!) kommt die Story zur├╝ck ins Backlog und wird z.b. f├╝r den n├Ąchsten Sprint wieder eingeplant.
  • Monatlicher Retainer aufgrund der erbrachten Leistungen
  • Wird eine bereits realisierte User Story durch eine neue erweitert/ersetzt, so beginnt die Gew├Ąhrleistung neu.

Gew├Ąhrleistung verteilt sich auf mehrere Mini-Gewerke statt auf ein gro├čes Gewerk. Entkopplung der Bezahlung von Gew├Ąhrleistung/Abnahme. Nur wenn im Nachhinein, also im Betrieb, etwas Abgenommenes nachweislich nicht stimmt, muss kostenlos gefixt werden.

Money For Nothing, Changes For Free

  • Standard fixed price und T&M f├╝r Changes.
  • Tausch von Features gleichen Aufwands (SP), sofern noch nicht begonnen. (Changes For Free)
  • Neue Features m├Âglich, wenn Low Prio Features mit gleichem Aufwand wegfallen.
  • H├Ąlt der Kunde sich nicht an Scrum, wandelt sich das Projekt in reines T&M.
  • Beide Parteien k├Ânnen sich auf SP-Sch├Ątzungen einigen. Ansonsten Umwandlung in T&M.
  • Wenn Kosten eines Features teurer als Business-Value, dann Abbruch des Projekts.
  • Ausgleich f├╝r fr├╝hzeitige Beendigung des Projekts: 20% des ├╝brig gebliebenen Budgets geht zus├Ątzlich an den Dienstleister (Money for Nothing)

Lohnt sich nur bei Optimierung auf Business-Value. Und nur wenn klar ist, dass das Budget nicht bis zum Ende aufgebraucht werden soll. Lohnt sich nicht, wenn das Budget sowieso gut und sinnvoll genutzt werden kann.

Fazit

Am wichtigsten ist, dass keine Gew├Ąhrleistung auf ein ganzes Produkt gegeben wird, sondern das Risiko auf einzelne User Stories / Features heruntergebrochen wird. Weil man als Dienstleister sonst in die Problematik kommt, dass st├Ąndig neue Features gew├╝nscht sind. Ist das Budget dann mal fix definiert, k├Ânnen einzelne Features immer noch getauscht oder anders priorisiert werden.

Disclaimer: Ich bin kein Anwalt und das ist nat├╝rlich keine Rechtsberatung. Der Beitrag ist angelehnt an einen Vortrag von Mayflower ÔÇô aber in einer etwas ├╝bersichtlicheren Form ­čÖé. F├╝r noch mehr Lekt├╝re sei das Buch┬áDer agile Festpreis*┬áempfohlen.

Join the Conversation

4 Comments

  1. Es sollte im Fazit neben den User Stories / Features auch “Inkrements” (kleinteilige aber ├╝berpr├╝fbare “Teilprodukte”) in Betracht gezogen werden.

  2. Spannend geschrieben.

    Besonders die ersten Beiden sind sicherlich interessant “Festpreis” und “Time & Material” (l├Ąsst sich sicherlich mit “Bezahlung nach Aufwand” ├╝bersetzen).

    Die anderen Abrechnungsmodelle sind sicherlich auch anwendbar. Meistens machen das meiner Meinung nach grosse Unternehmen oder deren IT Abteilungen/ Fachabteilungen, welche eine Art Absicherung haben wollen, gegen├╝ber Management-R├╝ckfragen.

    Alles hat sicherlich seine Legitimit├Ąt ­čÖé

    Vielen Dank f├╝r die ├ťbersicht.

Leave a comment

Your email address will not be published. Required fields are marked *