www.bt-magazin.de   4.2011 Heft 7                Expertenwissen für It-architekten, Projektleiter und Berater             ...
FestpreisprojektErfolgreiche Festpreisprojekte durch flexiblen InhaltBusiness Value trotzFestpreisViele Projekte scheitern...
AUtor: MIrKo NoVAKoVIcIndividualsoftware zu bauen ist komplex, bietet aber             den vom Dienstleister gerne als sch...
lädt“. Er beschreibt in seiner Ver-                                                                                   öffe...
ICH                IE S            NS    RM IERE BER             Ü         NINFO jETZT CHSTE              Ä         RE N S...
in kleinen, funktionalen Einheiten (Inkremente), in          Wichtig dabei ist, dass sowohl Planung als auch Schät-sich wi...
NOtIzENwww.bt-magazin.de   bt | 4.2011   7
codecentric AGKölner Landstraße 1140591 DüsseldorfTel: +49 (0) 211.9941410Fax: +49 (0) 211.9941444E-Mail: info@codecentric...
Nächste SlideShare
Wird geladen in …5
×

Sonderdruck codecentric btm_4_2011_novakovic_mon

489 Aufrufe

Veröffentlicht am

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
489
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Sonderdruck codecentric btm_4_2011_novakovic_mon

  1. 1. www.bt-magazin.de 4.2011 Heft 7 Expertenwissen für It-architekten, Projektleiter und Berater : Detlev Klage dnis für „Das Verstän hlt.“ Architektur zä BUSINESS VALUESonderdruck fürwww.codecentric.de Wertschöpfung durch IT? Kostentransparenz im EAM-Modell Der ROI der Cloud
  2. 2. FestpreisprojektErfolgreiche Festpreisprojekte durch flexiblen InhaltBusiness Value trotzFestpreisViele 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. NachMeinung des Autors kann nur durch einen flexiblen Umgang mit dem Inhalt der Business Valueeines Projekts maximiert werden – trotz festem Preis.2 bt | 4.2011 www.bt-magazin.de
  3. 3. AUtor: MIrKo NoVAKoVIcIndividualsoftware zu bauen ist komplex, bietet aber den vom Dienstleister gerne als schnell definiert wird,auch das größte Potenzial, hohen Geschäftswert zu während der Kunde die Anwendung als langsam emp-erzeugen. Unternehmen können damit Wettbewerbs- findet. Diskussionen und Streitigkeiten sind dann vor-vorteile realisieren, wenn die neu entwickelte Software programmiert. Die Wartbarkeit einer Software lässtbeispielsweise Geschäftsprozesse effizienter umsetzt als sich zudem sehr schwer spezifizieren und messen. Aberdie Mitbewerber oder ein ganz neues Produkt im Markt gerade in der Wartung fallen bis zu 90 Prozent derpositioniert werden kann. Hierbei handelt es ich um ei- Kosten einer Software über den Lebenszyklus an, d. h.nen echten Geschäftswert, weil das Unternehmen mit- der Kunde merkt oft erst sehr spät, ob er gute Qualitäthilfe der Software entweder günstiger produzieren kann erhalten hat oder nicht. Aus diesem Grund fällt guteoder ein Alleinstellungsmerkmal hat, das zu höheren Wartbarkeit einer Software dem Zeitdruck im Projektoder stabilen Preisen führt. In der Vergangenheit haben zum Opfer.wir uns als IT allerdings einen schlechten Ruf erarbeitet, • Die Kundenzufriedenheit spielt in klassischen Pro-da solche Projekte oft scheitern oder zumindest nicht jekten kaum eine Rolle. Gerade der Anwender wirdden erhofften Geschäftswert erzielen. Mit dem Modell häufig nicht oder erst sehr spät in die Entwicklungdes „Festpreisprojekts“ sollte das Risiko für den Kun- einer Software eingebunden. Durch ein klassischesden minimiert werden, allerdings mit geringem Erfolg. „Wasserfall“-Vorgehen ist ein Feedback auf BasisGrund hierfür ist der falsche Fokus dieser Projekte. Das funktionierender Software auch schwierig, weil diegrundsätzliche Problem mit Festpreisprojekten ist, dass Implementierungsphase erst sehr spät im Prozess be-in den meisten Fällen eben nicht nur der Preis festge- endet wird. Wird dann festgestellt, dass der Anwen-schrieben wird, sondern auch Inhalt und Termin. Das der die Software anders benutzt als erwartet, führtwird im Projektmanagement gerne auch „Magisches das zu Änderungen, die durch den späten ZeitpunktDreieck“ genannt. Das Management dieser drei Ziel- des Anwendertests nur mit hohen Aufwänden umge-größen führt in klassischen Festpreisprojekten dazu, setzt werden können. Oft werden die Anwender aberdass eben nicht mehr der Geschäftswert im Fokus des auch erst mit einbezogen, wenn Sie die fertige Soft-Projekts steht: ware benutzen sollen.• Das „Change Management“ beschäftigt sich mit der Lösungsideen für die stärkere Fokussierung auf den inhaltlichen Abgrenzung des Projekts. Der Kunde soll Geschäftswert findet man in der agilen Softwareent- genau das erhalten, was er im Pflichtenheft aufgeschrie- wicklung. Schon das Agile Manifest setzt den Fokus auf ben hat. Abweichungen von dieser „Baseline“ werden funktionierende Software, Zusammenarbeit mit dem als Änderung erfasst und weichen somit vom Umfang Kunden und Reagieren auf Veränderung. Damit sich des Festpreisprojekts ab. Je später solche Änderungen diese Werte in den Zielen eines Festpreisprojekts wie- im Projektverlauf eingestellt werden, desto teuerer ist derfinden, erweitern wir das Magische Dreieck um drei in der Regel deren Umsetzung. Viele Kalkulationen von weitere Kerngrößen: Kundenzufriedenheit, Geschäfts- Festpreisen gehen schon beim Angebot davon aus, dass wert und Qualität. das Projekt nur über die Änderungen profitabel wird. Die Erweiterung des Magischen Dreiecks mit den Oft werden Änderungen deshalb auch vom Kunden Faktoren Zeit, Kosten und Inhalt um die drei neu- nicht beauftragt, mit der Konsequenz, dass weniger en Kennzahlen zu einem „Magischen Sechseck“ führt Geschäftswert erzeugt wird oder teilweise sogar keiner, dazu, dass Projekte weniger „plangetrieben sind“ und weil nicht die Software gebaut wird, die der Kunde be- mehr „wertgetrieben“ umgesetzt werden. Für ein Fest- nötigt, sondern die, die zu Beginn des Projekts spezifi- preisprojekt bedeutet das allerdings, dass man einen ziert wurde. Kompromiss eingehen muss, denn man kann nicht alle• Die Qualität und insbesondere die nicht funktionalen sechs Größen in einem Projekt fest vorgeben. Der hier Anforderungen werden in Projekten meist nur rudi- vorgeschlagene Ansatz, der im Übrigen auch von den mentär oder zu ungenau spezifiziert. Ein typisches meisten agilen Ansätzen so gewählt wird, beruht darauf, Beispiel hierfür ist, dass gerne gesagt wird, dass eine dass man den Inhalt eines Projekts nicht konkret fixiert. Anwendung schnell und sicher sein soll. Leider ist Auf den ersten Blick hört sich das nicht praktikabel an, „schnell“ keine feste Größe, sodass beispielsweise die ist aber nach Meinung des Autors der einzig ehrliche Antwortzeit einer Webanwendung von acht Sekun- und funktionierende Ansatz, um die anderen fünf Ziel-www.bt-magazin.de bt | 4.2011 3
  4. 4. 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-Abb. 1: Das Magische Sechseck derungen an der ursprünglichen Definition der Anforderungen, sondern auch, dass die Anforde-größen optimal zu bedienen. Die Diskussion soll mit drei rungen nicht den Bedürfnissen der Anwender entspre-Thesen starten, die in der Softwareentwicklung schon chen. Die Standish Group hat in ihrer Studie „CHAOSlange Bestand haben, aber sehr häufig nicht berücksich- Report 2009“ herausgefunden, dass 45 Prozent dertigt werden: Funktionen einer Software nie benutzt werden. 20 Pro- zent werden sehr selten und 16 Prozent manchmal be-• „For a new software system, the requirements will not nutzt. Nur 20 Prozent der Funktionen einer Software be completely known until after the users have used werden laut dieser Studie immer oder oft genutzt. Das it.“ [1] bedeutet im Umkehrschluss auch, dass 80 Prozent der• „Uncertainty is inherent and inevitable in software de- erstellten Software keinen Business Value erzeugen. Das velopment processes and products.“ [2] ist ein Resultat aus der Befolgung eines Plans und der• „An interactive system can never be fully specified nor fehlenden Fokussierung auf den Geschäftswert. Das can it ever be fully tested.“ [3] Ziel in Projekten sollte es daher sein, den Anteil der Software, der Geschäftswert erzeugt, deutlich zu erhö-Jeder, der schon einmal in Softwareprojekten gearbeitet hen. Folgt man den obigen Thesen und den daraus re-hat, kann diese wissenschaftlichen Thesen in der Praxis sultierenden Problemen in Festpreisen, dann wird klar,bestätigen: Man kann in einem überschaubaren Auf- dass man das nur über den Inhalt machen kann. Manwand keine Software zu 100 Prozent spezifizieren: Ge- muss akzeptieren, dass man komplexe Anwendungensetze und Vorschriften ändern sich, neue Technologien nicht vollständig spezifizieren und deshalb die Ermitt-und Produkte werden verfügbar, Menschen haben neue lung der Anforderungen nur gemeinsam und empirischIdeen und Meinungen, Dinge, die auf dem Papier gut mit den Stakeholdern durchführen kann.ausgesehen haben, stellen sich in der laufenden Software Konkret bedeutet das, dass man kurze Feedback-als nicht wirklich benutzerfreundlich dar oder man hat schleifen in das Projekt einbauen muss, um die Kom-schlichtweg etwas falsch verstanden oder vergessen zu plexität von Softwareprojekten beherrschen zu könnendokumentieren. und das Risiko zu minimieren. Nach Humphrey kann Trotzdem werden die meisten Softwareprojekte, ins- dieses Feedback aber nur auf Basis lauffähiger Soft-besondere die auf Festpreis basierenden, immer noch ware erfolgen, da erst beim Benutzen des Systems An-nach dem Wasserfallmodell implementiert und auf Basis forderungen validiert werden können. Das bedeutet,des magischen Dreiecks geführt. Winston Royce, der die dass man die Software auf Basis eines iterativen underste formale Beschreibung des Wasserfallmodells im inkrementellen Prozesses umsetzen muss, damit dieJahr 1970 veröffentlicht hat [4], beschreibt in seinem Ar- Anwender das notwendige Feedback geben können.tikel bereits die Probleme dieser Vorgehensweise, an die Die Kombination iterativer und inkrementeller Ansät-er „zwar glaubt, aber die riskant ist und zu Fehlern ein- ze führt zu einem Entwicklungsprozess, der Software4 bt | 4.2011 www.bt-magazin.de
  5. 5. ICH IE S NS RM IERE BER Ü NINFO jETZT CHSTE Ä RE N S UNS E S HOP W ORK ND U NGEN ULU SCH Mehr dazu unter: www.codecentric.de
  6. 6. in kleinen, funktionalen Einheiten (Inkremente), in Wichtig dabei ist, dass sowohl Planung als auch Schät-sich wiederholenden Zyklen (Iterationen) ausliefert. zung wertorientiert ausgerichtet sein müssen und mitDie Länge der Iteration sollte dabei vier Wochen nicht der Ungenauigkeit im Umfang des Projekts umgehenüberschreiten. Das verkürzt die Dauer für die Rück- können – sprich, kurzfristig detailliert und langfristigmeldung, limitiert aber auch das Risiko auf den Inhalt grobgranular sind.eines Monats. Ein Projekt startet deshalb am besten mit einer Unter- FazItmenge der zu Beginn bekannten Systemanforderungen Den Geschäftswert in Projekten und insbesondere inund implementiert ein einfaches und ausbaufähiges er- Festpreisprojekten zu optimieren bedeutet, den Fokusstes Inkrement. Auf diese Weise steigt das Wissen über auf den Inhalt des Projekts zu reduzieren und nebendie sinnvollen Anforderungen an das System mit jeder Zeit und Kosten auch Qualität, KundenzufriedenheitIteration, und dieses Wissen kann in die Planung der und den Geschäftswert als wichtige Kennzahlen zurnächsten Inkremente einfließen. Für die Auswahl der Steuerung eines Projekts aufzunehmen. Iterative, inkre-Funktionen, die in das nächste Inkrement einfließen, mentelle Vorgehensmodelle helfen, die Feedbackzyklensollten der Business Value und das Risiko als Priorisie- der Stakeholder zu reduzieren und die Erfahrung mitrung herangezogen werden. Das bedeutet, dass immer der erstellten Software in die Weiterentwicklung einflie-die Funktionen als Nächstes umgesetzt werden sollten, ßen zu lassen. So passt sich der Inhalt des Projekts andie am meisten Nutzen für den Kunden liefern oder das den tatsächlichen Bedarf des Kunden an. Grundlage da-höchste Risiko für das Projekt bedeuten, sodass diese für ist aber Vertrauen zwischen Kunde und Dienstleis-frühzeitig im Projekt evaluiert werden können. ter, denn nur so kann die Ungewissheit über den Inhalt In diesem Artikel wird absichtlich nicht der Einsatz eines Projekts bei einem Festpreis überbrückt werden.agiler Vorgehensmodelle wie Scrum oder XP fokus- Hat man dieses Vertrauen nicht, sollte man auch keinensiert, denn nicht nur agile, sondern auch klassische Festpreis verhandeln, denn dann wird der Geschäfts-Vorgehensmodelle wie der Rational Unified Process wert ins Hintertreffen geraten.oder das V-Modell erlauben ein iteratives und inkre-mentelles Vorgehen und können damit die Basis füreinen solchen Business-Value-fokussierten Ansatz Links & Literatursein. Wichtig ist allerdings noch zu erwähnen, dass [1] A Discipline for Software Engineering, Watts S Humphrey,für die Umsetzung in der Praxis sowohl handwerk- 1995 [2] the Uncertainty Principle in Software Engineering, Hadar Zivliche Fertigkeiten benötigt werden, um Software in u.a.: http://www.ics.uci.edu/~ziv/papers/icse97.pskurzen Iterationen von maximal vier Wochen auslie- [3] the Paradigm Shift from Algorithm to Interaction, Peter Weg-fern zu können, als auch spezielle Praktiken für das ner: http://www.cs.brown.edu/people/pw/papers/ficacm.psPlanen und Schätzen des Projekts. Gerade die klas- [4] Managing the Development of Large Software Systems, Winston royce: http://www.cs.umd.edu/class/spring2003/sischen Vorgehensmodelle vernachlässigen das Soft- cmsc838p/Process/waterfall.pdfwareentwicklungs-„Handwerk“, was nach Meinung [5] Agile Estimating and Planning, Mike cohn, 2005des Autors einer der Gründe ist, warum RUP und dasV-Modell meistens in ihrer Wasserfallausprägung ein-gesetzt werden. Der Umgang mit evolutionären Archi-tekturen, die es ermöglichen, auf Änderungen gut zureagieren, ein hoher Automatisierungsgrad aller Test-stufen, die kontinuierliche Integration der Anwendungund der professionelle Umgang mit Code sind Beispielefür Praktiken, die ein Entwicklungsteam kennen undbeherrschen muss, damit eine iterative, inkrementelle Mirko NovakovicEntwicklung funktionieren kann. ist Vorstand und Mitgründer der code- Bei Festpreisen ist aber weiterhin das Planen und centric AG. Er arbeitet seit 15 Jahren in großen und kleinen SoftwareprojektenSchätzen ein wichtiger Bestandteil, um Zeit und Kosten und bevorzugt dabei schlanke Prozesse,zu Beginn eines Projekts gut vorhersagen zu können. Architekturen und Frameworks.Auch hier kann man sich agiler Praktiken bedienen, diebeispielsweise Mike Cohn in seinem Buch [5] über dasPlanen und Schätzen in agilen Projekten beschreibt.6 bt | 4.2011 www.bt-magazin.de
  7. 7. NOtIzENwww.bt-magazin.de bt | 4.2011 7
  8. 8. codecentric AGKölner Landstraße 1140591 DüsseldorfTel: +49 (0) 211.9941410Fax: +49 (0) 211.9941444E-Mail: info@codecentric.dewww.codecentric.deblog.codecentric.de

×