Skip links

Agile und Festpreisprojekte: Wie es funktionieren kann!

Agi­le Metho­den haben sich zu einem äußerst belieb­ten Instru­ment für die Pro­jekt­ab­wick­lung ent­wi­ckelt. Ob für “time & mate­ri­als”, Fest­preis­pro­jek­te oder ver­gleich­ba­re Pro­jek­te, Unter­neh­men set­zen Agi­le Metho­den in immer grö­ße­rem Maße ein. Wäh­rend ein brei­ter Kon­sens über die Zweck­mä­ßig­keit von agi­len Metho­den in time & mate­ri­als Pro­jek­ten besteht, sor­gen die Mei­nun­gen über die Kom­pa­ti­bi­li­tät mit Fest­preis­ver­trä­gen noch immer für eini­ge Dis­kus­sio­nen. Wie lösen Teams der­zeit die­se Her­aus­for­de­run­gen und war­um ent­schei­den sie sich für eine agi­le Vor­ge­hens­wei­se und Fest­preis­pro­jek­te.

War­um Agi­le?

Im Gegen­satz zum sequen­ti­el­len Was­ser­fall­mo­dell kon­zen­triert sich Agi­le auf klei­ne­re, aber häu­fi­ge Wert­stei­ge­run­gen. Kun­den und Dienst­leis­ter ent­schei­den sich immer wie­der für die­sen mul­ti-funk­tio­na­len Ansatz als fle­xi­ble, schnel­le und reak­ti­ons­schnel­le Metho­de für ihre Entwicklungs‑, War­tungs- und Sup­port­pro­jek­te.

War­um Fest­preis?

Der Fest­preis­ver­trag ist eine Ver­ein­ba­rung über die Erbrin­gung von Dienst­leis­tun­gen für den Kun­den zu einem fes­ten Preis. Bei einem Fest­preis­pro­jekt wer­den alle drei Kom­po­nen­ten (Kos­ten, Zeit und Umfang) zu Beginn des Pro­jekts fest­ge­legt und bestimmt. Eine Ände­rung einer Kom­po­nen­te wirkt sich unwei­ger­lich auf die ande­ren bei­den aus, wes­halb die Ände­rungs­kon­trol­le von ent­schei­den­der Bedeu­tung ist. Es wird nicht ange­nom­men, dass sich die zu Beginn des Auf­trags fest­ge­leg­ten Kos­ten wäh­rend der Pro­dukt­ent­wick­lungs­pha­se ändern.

Die Aus­sicht auf finan­zi­el­le Pla­nungs­si­cher­heit macht die­se Art von Ver­trä­gen für die Kun­den beson­ders attrak­tiv. Die Ver­ant­wort­li­chen gehen jedoch oft davon aus, dass ein Fest­preis einen bestimm­ten Zeit­rah­men und einen genau­en Arbeits­um­fang garan­tiert. In der Rea­li­tät ist dies jedoch nur sel­ten der Fall, vor allem weil häu­fig Ände­run­gen vor­ge­nom­men wer­den, um den Erwar­tun­gen der Kun­den und des Mark­tes bes­ser gerecht zu wer­den.
In den fol­gen­den Abschnit­ten die­ses Blogs wer­den wir erör­tern, wie ein Fest­preis­pro­jekt mit­hil­fe von Agi­le erfolg­reich durch­ge­führt wer­den kann.

Der Mythos: Agi­le funk­tio­niert nicht in Fest­preis­pro­jek­ten!

Das Argu­ment lau­tet, dass Agi­li­tät zwar Fle­xi­bi­li­tät in Bezug auf die zu erle­di­gen­de Arbeit (d. h. Ände­run­gen des Umfangs) bie­tet, in Fest­preis­pro­jek­ten aber bereits alle drei Kom­po­nen­ten (Kos­ten, Umfang und Zeit) fest­ge­legt sind.

Unab­hän­gig von der gewähl­ten Metho­de (Agi­le oder Was­ser­fall) sind Fest­preis­pro­jek­te mit Her­aus­for­de­run­gen wie neu­en Ände­run­gen, Pro­jekt­ver­zö­ge­run­gen und Kos­ten­über­schrei­tun­gen ver­bun­den. Wenn das Pro­jekt erfolg­reich sein soll, wer­den die Teams es nicht schaf­fen, alle drei Kom­po­nen­ten zu fixie­ren. Viel­mehr müs­sen sie die Kos­ten durch zusätz­li­che Res­sour­cen erhö­hen, den Umfang redu­zie­ren oder den Zeit­plan ver­län­gern, um ihre Zie­le zu errei­chen.

Die Her­aus­for­de­run­gen bei agi­len Fest­preis­pro­jek­ten

Auch Agi­le ist kei­ne so ein­fa­che Metho­de. Ein typi­sches Bei­spiel ist eine Orga­ni­sa­ti­on, die zum ers­ten Mal mit der agi­len Metho­de arbei­tet und erwar­tet, dass das Pro­jekt pünkt­lich mit einem fest defi­nier­tem Umfang und fixen Kos­ten abge­schlos­sen wird. Auf hal­bem Weg durch das Pro­jekt tritt der Kun­de mög­li­cher­wei­se an das Ent­wick­lungs­team her­an und bit­tet dar­um, eini­ge Ände­run­gen ent­spre­chend den neu­es­ten Erkennt­nis­sen und Anfor­de­run­gen vor­zu­neh­men.

Ein fixer Pro­jekt­um­fang und ein fes­ter Zeit­plan erschwe­ren die Umset­zung sol­cher Ände­run­gen. Dar­über hin­aus gibt es zusätz­li­che Her­aus­for­de­run­gen, mit denen wir im wei­te­ren Pro­jekt­ver­lauf kon­fron­tiert wer­den kön­nen.

Leistungsumfang

Unkla­re oder “one-liner” Anfo­de­run­gen.
Die größ­te Her­aus­for­de­rung für die Teams ist, wenn sich der Umfang eines Fest­preis­pro­jekts ändert. Die Anfor­de­run­gen für Fest­preis­pro­jek­te sind zu Beginn des Pro­jekts manch­mal unklar oder unzu­rei­chend defi­niert. Die Teams legen die Anfor­de­run­gen in der Regel auf der Grund­la­ge ihrer eige­nen Erfah­run­gen und Kennt­nis­se fest, die im All­ge­mei­nen unter­schätzt wer­den kön­nen. Wenn in spä­te­ren Pha­sen des Pro­jekts die wah­re Kom­ple­xi­tät der Her­aus­for­de­rung zuta­ge tritt, haben die Teams meist kei­ne ande­re Wahl, als zusätz­li­che Stun­den zu leis­ten, um die Unter­schät­zung zu kom­pen­sie­ren.

Uner­war­te­te Ände­rungs­wün­sche tau­chen in der Mit­te eines Pro­jekts auf.
Plötz­li­che Anpas­sun­gen auf­grund aktu­el­ler Trends oder neu­er Prio­ri­tä­ten sind bei Fest­preis­pro­jek­ten fast die Regel. Auf­trag­ge­ber hal­ten sol­che Ände­run­gen für eine ord­nungs­ge­mä­ße Pro­jekt­ent­wick­lung für uner­läss­lich, erwar­ten aber kei­ne Ände­run­gen bei den Kos­ten oder dem Zeit­plan. Pro­jekt­teams zögern in der Regel, wenn sie mit sol­chen Ände­run­gen kon­fron­tiert wer­den, was sich wie­der­um auf die Kun­den­be­zie­hung und das Ver­trau­en aus­wirkt.

Abhängigkeit und Verantwortlichkeiten

“Owner­ship” von ande­ren inter­nen Teams oder Dritt­an­bie­tern.
An einem gro­ßen Fest­preis­pro­jekt sind sehr wahr­schein­lich mehr als ein Team und mög­li­cher­wei­se zusätz­li­che Dritt­an­bie­ter betei­ligt. Es muss ein gemein­sa­mer Rah­men geschaf­fen wer­den, in dem alle Teams das glei­che Ver­ständ­nis von Dring­lich­keit und Ver­ant­wor­tung für ihre jewei­li­gen Auf­ga­ben haben. Wenn nur ein Team mit dem Rest nicht syn­chro­ni­siert ist, reicht es aus den Pro­jekt­fort­schritt sofort zu behin­dern.

Einbindung der Auftraggeber

Kun­den wir­ken wäh­rend der Ent­wick­lungs­pha­se nicht aktiv mit.
Kun­den haben in der Regel den Ein­druck, dass die Offen­le­gung der Pro­jekt­an­for­de­run­gen zu einem frü­hen Zeit­punkt im Pro­jekt jede akti­ve Betei­li­gung über­flüs­sig macht. Dies beein­träch­tigt eine erfolg­rei­che Zusam­men­ar­beit (z. B. bei der Klä­rung mög­li­cher Zwei­fel und Rück­fra­gen) und kann zu Ver­zö­ge­run­gen füh­ren. Die Kun­den nei­gen dazu, sich nicht beson­ders auf Sprint-Reviews oder Demos zu kon­zen­trie­ren, aber bei der abschlie­ßen­den Pro­dukt­über­prü­fung stel­len sie fest, dass es nicht das ist, was sie woll­ten. Dies kann zu wei­te­ren Ver­zö­ge­run­gen füh­ren, da das Team die Funk­ti­on über­ar­bei­ten muss, um die Erwar­tun­gen zu erfül­len.

Fehlendes Agile-Wissen in den Teams beim Kunden

Agi­le Metho­den gibt es schon seit fast zwei Jahr­zehn­ten.
Eini­ge Unter­neh­men wis­sen immer noch wenig dar­über oder zögern, sie zu nut­zen. Dies stellt eine erheb­li­che Her­aus­for­de­rung dar, wenn es dar­um geht, Agi­le in Fest­preis- und ande­ren ähn­li­chen Pro­jek­ten zu imple­men­tie­ren. Wie bereits erläu­tert, den­ken Unter­neh­men ohne Agi­le-Kennt­nis­se manch­mal, dass ihre Auf­ga­be erle­digt ist, sobald sie dem Anbie­ter den Fest­preis­ver­trag und die Anfor­de­rungs­lis­te über­ge­ben haben. Sie erwar­ten dann nicht nur, dass das Pro­jekt pünkt­lich gelie­fert wird, son­dern auch, dass alle Ände­rungs­wün­sche kei­ne Aus­wir­kun­gen auf die End­kos­ten haben.

Erfolg­rei­cher Umgang mit den Her­aus­for­de­run­gen in agi­len Fest­preis­pro­jek­ten

Wäh­rend das tra­di­tio­nel­le Was­ser­fall-Fest­preis­pro­jekt drei fes­te Kom­po­nen­ten hat (Umfang, Zeit und Kos­ten), wird bei agi­len Fest­preis­pro­jek­ten der Umfang durch die Grös­se des Pro­jekts ersetzt. Wie wir wis­sen, wer­den agi­le Pro­jek­te in der Regel in Sto­ry Points gemes­sen. Die Fest­le­gung der Grö­ße (in Sto­ry Points) hilft den Kun­den, den Umfang auf der Grund­la­ge von aktu­el­len Ent­wick­lun­gen des Geschäfts zu ändern, vor­aus­ge­setzt, der neue Umfang erhöht nicht die Gesamt­grö­ße des Pro­jekts (in Sto­ry Points).

Umgang mit Ver­än­de­run­gen

Agi­les Vor­ge­hen ermög­licht auch in spä­te­ren Pha­sen der Ent­wick­lung Ände­run­gen. Vie­le Ände­run­gen kön­nen im Zusam­men­hang mit Markt­trends und Neu­prio­ri­sie­rung auf­tre­ten. Die bes­te Anpas­sungs­stra­te­gie besteht dar­in, mit dem Kun­den über den Tausch von Ele­men­ten mit nied­ri­ger Prio­ri­tät aus dem Pro­dukt-Back­log zu spre­chen, deren Grö­ße dem Wert der neu­en Ände­rung ent­spricht. Auf die­se Wei­se wird der Pro­zess, mit dem die Teams neue Ände­rungs­an­fra­gen anneh­men, ratio­na­li­siert. In die­sem Rah­men ist ein fes­ter Umfang für alle Pha­sen (ein­schließ­lich des End­ergeb­nis­ses) sinn­voll, da die Teams nun ein gleich gro­ßes Pro­dukt mit Mehr­wert lie­fern.

Workshop in der ersten Analysephasen

Die Anfangs­pha­se eines Fest­preis­pro­jekts ist immer kri­tisch. In die­ser Zeit orga­ni­sie­ren die Pro­jekt­teams Work­shops mit dem Kun­den, um die Lis­te der Back­log-Ele­men­te durch­zu­ge­hen und die Anfor­de­run­gen im Detail zu ver­ste­hen. Anschlie­ßend bit­tet das Team den Kun­den, die Abnah­me­kri­te­ri­en für jedes Back­log-Ele­ment zu defi­nie­ren. Nach die­sem Work­shop kann das Team eine genaue Grö­ßen­be­stim­mung vor­neh­men und die­se mit der im Pro­jekt­ver­trag fest­ge­leg­ten ursprüng­li­chen Grö­ße abglei­chen. Wenn es eine Abwei­chung in der Grö­ße gibt, kann das Team mit dem Kun­den über die Ent­fer­nung von Back­log-Ele­men­ten mit nied­ri­ger Prio­ri­tät ver­han­deln.

Verwenden Sie die MoSCoW-Technik

Die MoSCoW-Prio­ri­sie­rung ist eine belieb­te Tech­nik, um sich mit den Stake­hol­dern dar­über zu ver­stän­di­gen, wie die Anfor­de­run­gen zu mana­gen und zu lie­fern sind.
Agi­le Metho­den för­dern immer ein gesun­des Pro­duct Back­log — eines, in dem alle Ele­men­te prio­ri­siert und in Sto­ry Points ein­ge­teilt sind. Teams kön­nen die MoSCoW-Tech­nik mit ihren Kun­den anwen­den, um Back­log-Ele­men­te zu kate­go­ri­sie­ren, sobald sie den ers­ten Ana­ly­se­work­shop abge­schlos­sen haben.
Im All­ge­mei­nen soll­ten die wesent­li­chen Back­log-Ele­men­te (“Musts”) nicht mehr als 60 % des gesam­ten Pro­jekt­um­fangs aus­ma­chen. Unwe­sent­li­che, aber den­noch wich­ti­ge Back­log-Ele­men­te soll­ten nicht mehr als 20 % aus­ma­chen. Kurz gesagt, “Muss”- und “Soll”-Elemente soll­ten idea­ler­wei­se etwa 80 % des Pro­jekt­um­fangs aus­ma­chen. Daher müs­sen die Teams vor­aus­schau­end pla­nen, um alle Back­log-Ele­men­te abzu­schlie­ßen. Wenn die Pro­jekt­durch­füh­rung rei­bungs­los ver­läuft, soll­ten die Teams in der Lage sein, sowohl die “Muss”- als auch die “Soll”-Elemente zu lie­fern und dabei noch ein paar zusätz­li­che “Kann”-Elemente ein­zu­bau­en.
Mit die­ser Tech­nik kann das Team nicht nur ein funk­ti­ons­fä­hi­ges, hoch­wer­ti­ges Pro­dukt lie­fern, son­dern auch den Kun­den früh­zei­tig einen Markt­wert bie­ten, da die hoch­wer­ti­gen Pro­duk­te gelie­fert wer­den.

Umgang mit der Änderung von Prozessen

Agi­les Vor­ge­hen ermög­licht auch in spä­te­ren Pha­sen der Ent­wick­lung Ände­run­gen. Vie­le Ände­run­gen kön­nen im Zusam­men­hang mit Markt­trends und Neu­prio­ri­sie­rung auf­tre­ten. Die bes­te Anpas­sungs­stra­te­gie besteht dar­in, mit dem Kun­den über den Tausch von Ele­men­ten mit nied­ri­ger Prio­ri­tät aus dem Pro­dukt-Back­log zu spre­chen, deren Grö­ße dem Wert der neu­en Ände­rung ent­spricht. Auf die­se Wei­se wird der Pro­zess, mit dem die Teams neue Ände­rungs­an­fra­gen anneh­men, ratio­na­li­siert. In die­sem Rah­men ist ein fes­ter Umfang für alle Pha­sen (ein­schließ­lich des End­ergeb­nis­ses) sinn­voll, da die Teams nun ein gleich gro­ßes Pro­dukt mit Mehr­wert lie­fern.

Workshop in der ersten Analysephasen

Die Anfangs­pha­se eines Fest­preis­pro­jekts ist immer kri­tisch. In die­ser Zeit orga­ni­sie­ren die Pro­jekt­teams Work­shops mit dem Kun­den, um die Lis­te der Back­log-Ele­men­te durch­zu­ge­hen und die Anfor­de­run­gen im Detail zu ver­ste­hen. Anschlie­ßend bit­tet das Team den Kun­den, die Abnah­me­kri­te­ri­en für jedes Back­log-Ele­ment zu defi­nie­ren. Nach die­sem Work­shop kann das Team eine genaue Grö­ßen­be­stim­mung vor­neh­men und die­se mit der im Pro­jekt­ver­trag fest­ge­leg­ten ursprüng­li­chen Grö­ße abglei­chen. Wenn es eine Abwei­chung in der Grö­ße gibt, kann das Team mit dem Kun­den über die Ent­fer­nung von Back­log-Ele­men­ten mit nied­ri­ger Prio­ri­tät ver­han­deln.

Verwenden Sie die MoSCoW-Technik

Die MoSCoW-Prio­ri­sie­rung ist eine belieb­te Tech­nik, um sich mit den Stake­hol­dern dar­über zu ver­stän­di­gen, wie die Anfor­de­run­gen zu mana­gen und zu lie­fern sind.
Agi­le Metho­den för­dern immer ein gesun­des Pro­duct Back­log — eines, in dem alle Ele­men­te prio­ri­siert und in Sto­ry Points ein­ge­teilt sind. Teams kön­nen die MoSCoW-Tech­nik mit ihren Kun­den anwen­den, um Back­log-Ele­men­te zu kate­go­ri­sie­ren, sobald sie den ers­ten Ana­ly­se­work­shop abge­schlos­sen haben.
Im All­ge­mei­nen soll­ten die wesent­li­chen Back­log-Ele­men­te (“Musts”) nicht mehr als 60 % des gesam­ten Pro­jekt­um­fangs aus­ma­chen. Unwe­sent­li­che, aber den­noch wich­ti­ge Back­log-Ele­men­te soll­ten nicht mehr als 20 % aus­ma­chen. Kurz gesagt, “Muss”- und “Soll”-Elemente soll­ten idea­ler­wei­se etwa 80 % des Pro­jekt­um­fangs aus­ma­chen. Daher müs­sen die Teams vor­aus­schau­end pla­nen, um alle Back­log-Ele­men­te abzu­schlie­ßen. Wenn die Pro­jekt­durch­füh­rung rei­bungs­los ver­läuft, soll­ten die Teams in der Lage sein, sowohl die “Muss”- als auch die “Soll”-Elemente zu lie­fern und dabei noch ein paar zusätz­li­che “Kann”-Elemente ein­zu­bau­en.
Mit die­ser Tech­nik kann das Team nicht nur ein funk­ti­ons­fä­hi­ges, hoch­wer­ti­ges Pro­dukt lie­fern, son­dern auch den Kun­den früh­zei­tig einen Markt­wert bie­ten, da die hoch­wer­ti­gen Pro­duk­te gelie­fert wer­den.

Zusammenarbeit zwischen Teams und Drittanbietern

Es ist von ent­schei­den­der Bedeu­tung, dass alle Teams das Ver­ständ­nis für die Dring­lich­keit und die Ver­ant­wor­tung für das Pro­jekt tei­len. Eine wich­ti­ge Tak­tik in die­sem Rah­men ist die Fest­le­gung von häu­fi­gen Mei­len­stei­nen und die Zuwei­sung der Ver­ant­wor­tung für jeden Mei­len­stein an ver­schie­de­ne Teams. Regel­mä­ßi­ge Sta­tus-Updates für jedes Team sind ent­schei­dend, um gemein­sa­me Mus­ter bei Her­aus­for­de­run­gen zwi­schen den Teams zu erken­nen und so früh­zei­tig gemein­sa­me Lösun­gen zu fin­den. Die kon­se­quen­te Über­prü­fung eines Abhän­gig­keits­ver­zeich­nis­ses und eines Risi­ko­re­gis­ters ist eben­falls uner­läss­lich, wenn ein Team den Kun­den vor mög­li­chen Ver­zö­ge­run­gen war­nen und sei­ne Auf­ga­be recht­zei­tig abschlie­ßen will.

Zusammenarbeit mit dem Kunden

Kein Pro­jekt kann ohne die kon­se­quen­te Ein­be­zie­hung aller Betei­lig­ten erfolg­reich sein. Wenn der Kun­de regel­mä­ßig an den Sprint-Reviews teil­nimmt, kann er den Teams bereits in einer frü­hen Pha­se des Pro­jekts wert­vol­les Feed­back geben. Dies kann auch Nach­ar­bei­ten in spä­te­ren Pha­sen ver­hin­dern. Die Kun­den soll­ten auch bereit sein, auf Fra­gen oder Zwei­fel der Teams ein­zu­ge­hen.

Agile Kundenschulung

Es ist von ent­schei­den­der Bedeu­tung, dass Kun­den zu Beginn eines Pro­jekts in der agi­len Metho­dik geschult wer­den. Anders als bei der tra­di­tio­nel­len Was­ser­fall­me­tho­de müs­sen die Kun­den ver­ste­hen, dass Agi­le ihre stän­di­ge Betei­li­gung wäh­rend des gesam­ten Pro­jekt­ver­laufs erfor­dert, wenn ein Pro­jekt erfolg­reich sein soll. Sie müs­sen auch die Bedeu­tung der Rol­le des Pro­duct Owners und sei­ner Arbeit begrei­fen, wenn es dar­um geht, den Teams bei der Prio­ri­sie­rung des Back­logs und der Pla­nung ihrer Arbeit im Sprint zu hel­fen.

Fazit: Fest­preis­pro­jek­te wer­den sich unab­hän­gig von der Metho­dik immer als Her­aus­for­de­rung erwei­sen.

Wenn ein Pro­jekt in Agi­le rich­tig durch­ge­führt wird, kann es zu einem Segen für die­se Vor­ha­ben wer­den, da die Wahr­schein­lich­keit, dass sie erfolg­reich sind, viel höher ist. Wir haben an meh­re­ren agi­len Fest­preis­pro­jek­ten gear­bei­tet und dabei Erfol­ge als auch sowohl Fehl­schlä­ge erlebt. In allen Pro­jekt­pha­sen gab es Her­aus­for­de­run­gen, und um sie zu bewäl­ti­gen, haben wir vie­le der oben beschrie­be­nen Tech­ni­ken ein­ge­setzt. Außer­dem unter­stützt uns wäh­rend der gesam­ten Zeit ein fan­tas­ti­sches Team.