www.bt-magazin.de 4.2011 Heft 7

Expertenwissen für It-architekten, Projektleiter und Berater

Detlev Klage:

„Das Verständnis für

Architektur zählt.“

BUSINESS VALUE

Wertschöpfung durch IT?

Kostentransparenz im EAM-Modell

Der ROI der Cloud

Wertschöpfung durch IT?

Sonderdruck fürwww.codecentric.de

www.bt-magazin.de2 bt | 4.2011

Festpreisprojekt

Erfolgreiche Festpreisprojekte durch flexiblen Inhalt

Business Value trotz Festpreis Viele Projekte scheitern und erzielen nicht den erhofften Business Value. Gerade bei Fest-

preisprojekten besteht die Gefahr, dass die Festlegung auf Zeit, Kosten und Inhalt dazu führt,

die Qualität, Kundenzufriedenheit und den Geschäftswert aus den Augen zu verlieren. Nach

Meinung des Autors kann nur durch einen flexiblen Umgang mit dem Inhalt der Business Value

eines Projekts maximiert werden – trotz festem Preis.

3bt | 4.2011www.bt-magazin.de

AUtor: MIrKo NoVAKoVIc

Individualsoftware zu bauen ist komplex, bietet aber auch das größte Potenzial, hohen Geschäftswert zu erzeugen. Unternehmen können damit Wettbewerbs-vorteile realisieren, wenn die neu entwickelte Software beispielsweise Geschäftsprozesse effizienter umsetzt als die Mitbewerber oder ein ganz neues Produkt im Markt positioniert werden kann. Hierbei handelt es ich um ei-nen echten Geschäftswert, weil das Unternehmen mit-hilfe der Software entweder günstiger produzieren kann oder ein Alleinstellungsmerkmal hat, das zu höheren oder stabilen Preisen führt. In der Vergangenheit haben wir uns als IT allerdings einen schlechten Ruf erarbeitet, da solche Projekte oft scheitern oder zumindest nicht den erhofften Geschäftswert erzielen. Mit dem Modell des „Festpreisprojekts“ sollte das Risiko für den Kun-den minimiert werden, allerdings mit geringem Erfolg. Grund hierfür ist der falsche Fokus dieser Projekte. Das grundsätzliche Problem mit Festpreisprojekten ist, dass in den meisten Fällen eben nicht nur der Preis festge-schrieben wird, sondern auch Inhalt und Termin. Das wird im Projektmanagement gerne auch „Magisches Dreieck“ genannt. Das Management dieser drei Ziel-größen führt in klassischen Festpreisprojekten dazu, dass eben nicht mehr der Geschäftswert im Fokus des Projekts steht:

Das „Change Management“ beschäftigt sich mit der •inhaltlichen Abgrenzung des Projekts. Der Kunde soll genau das erhalten, was er im Pflichtenheft aufgeschrie-ben hat. Abweichungen von dieser „Baseline“ werden als Änderung erfasst und weichen somit vom Umfang des Festpreisprojekts ab. Je später solche Änderungen im Projektverlauf eingestellt werden, desto teuerer ist in der Regel deren Umsetzung. Viele Kalkulationen von Festpreisen gehen schon beim Angebot davon aus, dass das Projekt nur über die Änderungen profitabel wird. Oft werden Änderungen deshalb auch vom Kunden nicht beauftragt, mit der Konsequenz, dass weniger Geschäftswert erzeugt wird oder teilweise sogar keiner, weil nicht die Software gebaut wird, die der Kunde be-nötigt, sondern die, die zu Beginn des Projekts spezifi-ziert wurde.Die Qualität und insbesondere die nicht funktionalen •Anforderungen werden in Projekten meist nur rudi-mentär oder zu ungenau spezifiziert. Ein typisches Beispiel hierfür ist, dass gerne gesagt wird, dass eine Anwendung schnell und sicher sein soll. Leider ist „schnell“ keine feste Größe, sodass beispielsweise die Antwortzeit einer Webanwendung von acht Sekun-

den vom Dienstleister gerne als schnell definiert wird, während der Kunde die Anwendung als langsam emp-findet. Diskussionen und Streitigkeiten sind dann vor-programmiert. Die Wartbarkeit einer Software lässt sich zudem sehr schwer spezifizieren und messen. Aber gerade in der Wartung fallen bis zu 90 Prozent der Kosten einer Software über den Lebenszyklus an, d. h. der Kunde merkt oft erst sehr spät, ob er gute Qualität erhalten hat oder nicht. Aus diesem Grund fällt gute Wartbarkeit einer Software dem Zeitdruck im Projekt zum Opfer.Die Kundenzufriedenheit spielt in klassischen Pro-•jekten kaum eine Rolle. Gerade der Anwender wird häufig nicht oder erst sehr spät in die Entwicklung einer Software eingebunden. Durch ein klassisches „Wasserfall“-Vorgehen ist ein Feedback auf Basis funktionierender Software auch schwierig, weil die Implementierungsphase erst sehr spät im Prozess be-endet wird. Wird dann festgestellt, dass der Anwen-der die Software anders benutzt als erwartet, führt das zu Änderungen, die durch den späten Zeitpunkt des Anwendertests nur mit hohen Aufwänden umge-setzt werden können. Oft werden die Anwender aber auch erst mit einbezogen, wenn Sie die fertige Soft-ware benutzen sollen.

Lösungsideen für die stärkere Fokussierung auf den Geschäftswert findet man in der agilen Softwareent-wicklung. Schon das Agile Manifest setzt den Fokus auf funktionierende Software, Zusammenarbeit mit dem Kunden und Reagieren auf Veränderung. Damit sich die se Werte in den Zielen eines Festpreisprojekts wie-derfinden, erweitern wir das Magische Dreieck um drei weitere Kerngrößen: Kundenzufriedenheit, Geschäfts-wert und Qualität.

Die Erweiterung des Magischen Dreiecks mit den Faktoren Zeit, Kosten und Inhalt um die drei neu-en Kennzahlen zu einem „Magischen Sechseck“ führt dazu, dass Projekte weniger „plangetrieben sind“ und mehr „wertgetrieben“ umgesetzt werden. Für ein Fest-preisprojekt bedeutet das allerdings, dass man einen Kompromiss eingehen muss, denn man kann nicht alle sechs Größen in einem Projekt fest vorgeben. Der hier vorgeschlagene Ansatz, der im Übrigen auch von den meisten agilen Ansätzen so gewählt wird, beruht darauf, dass man den Inhalt eines Projekts nicht konkret fixiert. Auf den ersten Blick hört sich das nicht praktikabel an, ist aber nach Meinung des Autors der einzig ehrliche und funktionierende Ansatz, um die anderen fünf Ziel-

www.bt-magazin.de4 bt | 4.2011

größen optimal zu bedienen. Die Diskussion soll mit drei Thesen starten, die in der Softwareentwicklung schon lange Bestand haben, aber sehr häufig nicht berücksich-tigt werden:

„For a new software system, the requirements will not •be completely known until after the users have used it.“ [1]„Uncertainty is inherent and inevitable in software de-•velopment processes and products.“ [2]„An interactive system can never be fully specified nor •can it ever be fully tested.“ [3]

Jeder, der schon einmal in Softwareprojekten gearbeitet hat, kann diese wissenschaftlichen Thesen in der Praxis bestätigen: Man kann in einem überschaubaren Auf-wand keine Software zu 100 Prozent spezifizieren: Ge-setze und Vorschriften ändern sich, neue Technologien und Produkte werden verfügbar, Menschen haben neue Ideen und Meinungen, Dinge, die auf dem Papier gut ausgesehen haben, stellen sich in der laufenden Software als nicht wirklich benutzerfreundlich dar oder man hat schlichtweg etwas falsch verstanden oder vergessen zu dokumentieren.

Trotzdem werden die meisten Softwareprojekte, ins-besondere die auf Festpreis basierenden, immer noch nach dem Wasserfallmodell implementiert und auf Basis des magischen Dreiecks geführt. Winston Royce, der die erste formale Beschreibung des Wasserfallmodells im Jahr 1970 veröffentlicht hat [4], beschreibt in seinem Ar-tikel bereits die Probleme dieser Vorgehensweise, an die er „zwar glaubt, aber die riskant ist und zu Fehlern ein-

lädt“. Er beschreibt in seiner Ver-öffentlichung, dass Änderungen zu einem späten Zeitpunkt in der Regel elementare Änderungen am Design haben können und man dann mit 100 Prozent mehr Auf-wand und Kosten rechnen muss. Seine Aussage zeigt eindrücklich, welche Gefahr ein Festpreisprojekt birgt, wenn man den Inhalt schon zu Beginn des Projekts spezifiziert und den Inhalt der Spezifikation (Pflichtenheft) als Basis für den Vertrag zwischen Kunden und Dienstleister nimmt.

Ein weiterer Punkt ist nicht nur das hohe Risiko bei späten Än-derungen an der ursprünglichen Definition der Anforderungen, sondern auch, dass die Anforde-

rungen nicht den Bedürfnissen der Anwender entspre-chen. Die Standish Group hat in ihrer Studie „CHAOS Report 2009“ herausgefunden, dass 45 Prozent der Funktionen einer Software nie benutzt werden. 20 Pro-zent werden sehr selten und 16 Prozent manchmal be-nutzt. Nur 20 Prozent der Funktionen einer Software werden laut dieser Studie immer oder oft genutzt. Das bedeutet im Umkehrschluss auch, dass 80 Prozent der erstellten Software keinen Business Value erzeugen. Das ist ein Resultat aus der Befolgung eines Plans und der fehlenden Fokussierung auf den Geschäftswert. Das Ziel in Projekten sollte es daher sein, den Anteil der Software, der Geschäftswert erzeugt, deutlich zu erhö-hen. Folgt man den obigen Thesen und den daraus re-sultierenden Problemen in Festpreisen, dann wird klar, dass man das nur über den Inhalt machen kann. Man muss akzeptieren, dass man komplexe Anwendungen nicht vollständig spezifizieren und deshalb die Ermitt-lung der Anforderungen nur gemeinsam und empirisch mit den Stakeholdern durchführen kann.

Konkret bedeutet das, dass man kurze Feedback-schleifen in das Projekt einbauen muss, um die Kom-plexität von Softwareprojekten beherrschen zu können und das Risiko zu minimieren. Nach Humphrey kann dieses Feedback aber nur auf Basis lauffähiger Soft-ware erfolgen, da erst beim Benutzen des Systems An-forderungen validiert werden können. Das bedeutet, dass man die Software auf Basis eines iterativen und inkrementellen Prozesses umsetzen muss, damit die Anwender das notwendige Feedback geben können. Die Kombination iterativer und inkrementeller Ansät-ze führt zu einem Entwicklungsprozess, der Software

Abb. 1: Das Magische Sechseck

INFORMIEREN SIE SICH

jETZT ÜBER

UNSERE NÄCHSTEN

WORKSHOPS

UND

SCHULUNGEN

Mehr dazu unter: www.codecentric.de

cc_BusinessTech_AZ_210x297 RZ_2.indd 1 10.05.11 11:49

www.bt-magazin.de6 bt | 4.2011

in kleinen, funktionalen Einheiten (Inkremente), in sich wiederholenden Zyklen (Iterationen) ausliefert. Die Länge der Iteration sollte dabei vier Wochen nicht überschreiten. Das verkürzt die Dauer für die Rück-meldung, limitiert aber auch das Risiko auf den Inhalt eines Monats.

Ein Projekt startet deshalb am besten mit einer Unter-menge der zu Beginn bekannten Systemanforderungen und implementiert ein einfaches und ausbaufähiges er-stes Inkrement. Auf diese Weise steigt das Wissen über die sinnvollen Anforderungen an das System mit jeder Iteration, und dieses Wissen kann in die Planung der nächsten Inkremente einfließen. Für die Auswahl der Funktionen, die in das nächste Inkrement einfließen, sollten der Business Value und das Risiko als Priorisie-rung herangezogen werden. Das bedeutet, dass immer die Funktionen als Nächstes umgesetzt werden sollten, die am meisten Nutzen für den Kunden liefern oder das höchste Risiko für das Projekt bedeuten, sodass diese frühzeitig im Projekt evaluiert werden können.

In diesem Artikel wird absichtlich nicht der Einsatz agiler Vorgehensmodelle wie Scrum oder XP fokus-siert, denn nicht nur agile, sondern auch klassische Vorgehensmodelle wie der Rational Unified Process oder das V-Modell erlauben ein iteratives und inkre-mentelles Vorgehen und können damit die Basis für einen solchen Business-Value-fokussierten Ansatz sein. Wichtig ist allerdings noch zu erwähnen, dass für die Umsetzung in der Praxis sowohl handwerk-liche Fertigkeiten benötigt werden, um Software in kurzen Iterationen von maximal vier Wochen auslie-fern zu können, als auch spezielle Praktiken für das Planen und Schätzen des Projekts. Gerade die klas-sischen Vorgehensmodelle vernachlässigen das Soft-wareentwicklungs-„Handwerk“, was nach Meinung des Autors einer der Gründe ist, warum RUP und das V-Modell meistens in ihrer Wasserfallausprägung ein-gesetzt werden. Der Umgang mit evolutionären Archi-tekturen, die es ermöglichen, auf Änderungen gut zu reagieren, ein hoher Automatisierungsgrad aller Test-stufen, die kontinuierliche Integration der Anwendung und der professionelle Umgang mit Code sind Beispiele für Praktiken, die ein Entwicklungsteam kennen und beherrschen muss, damit eine iterative, inkrementelle Entwicklung funktionieren kann.

Bei Festpreisen ist aber weiterhin das Planen und Schätzen ein wichtiger Bestandteil, um Zeit und Kosten zu Beginn eines Projekts gut vorhersagen zu können. Auch hier kann man sich agiler Praktiken bedienen, die beispielsweise Mike Cohn in seinem Buch [5] über das Planen und Schätzen in agilen Projekten beschreibt.

Wichtig dabei ist, dass sowohl Planung als auch Schät-zung wertorientiert ausgerichtet sein müssen und mit der Ungenauigkeit im Umfang des Projekts umgehen können – sprich, kurzfristig detailliert und langfristig grobgranular sind.

FazItDen Geschäftswert in Projekten und insbesondere in Festpreisprojekten zu optimieren bedeutet, den Fokus auf den Inhalt des Projekts zu reduzieren und neben Zeit und Kosten auch Qualität, Kundenzufriedenheit und den Geschäftswert als wichtige Kennzahlen zur Steuerung eines Projekts aufzunehmen. Iterative, inkre-mentelle Vorgehensmodelle helfen, die Feedbackzyklen der Stakeholder zu reduzieren und die Erfahrung mit der erstellten Software in die Weiterentwicklung einflie-ßen zu lassen. So passt sich der Inhalt des Projekts an den tatsächlichen Bedarf des Kunden an. Grundlage da-für ist aber Vertrauen zwischen Kunde und Dienstleis-ter, denn nur so kann die Ungewissheit über den Inhalt eines Projekts bei einem Festpreis überbrückt werden. Hat man dieses Vertrauen nicht, sollte man auch keinen Festpreis verhandeln, denn dann wird der Geschäfts-wert ins Hintertreffen geraten.

Links & Literatur[1] A Discipline for Software Engineering, Watts S Humphrey,

1995[2] the Uncertainty Principle in Software Engineering, Hadar Ziv

u.a.: http://www.ics.uci.edu/~ziv/papers/icse97.ps[3] the Paradigm Shift from Algorithm to Interaction, Peter Weg-

ner: http://www.cs.brown.edu/people/pw/papers/ficacm.ps[4] Managing the Development of Large Software Systems,

Winston royce: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

[5] Agile Estimating and Planning, Mike cohn, 2005

Mirko Novakovicist Vorstand und Mitgründer der code-centric AG. Er arbeitet seit 15 Jahren in großen und kleinen Softwareprojekten und bevorzugt dabei schlanke Prozesse, Architekturen und Frameworks.

7bt | 4.2011www.bt-magazin.de

NOtIzEN

codecentric AG Kölner Landstraße 11 40591 Düsseldorf

Tel: +49 (0) 211.9941410 Fax: +49 (0) 211.9941444

E-Mail: info@codecentric.de www.codecentric.de blog.codecentric.de