Ein Drittel aller Informatikprojekte scheitert - die Lösung: eine "scheinbar unmögliche" Kombination.

Transkript

1 GoldwynReport.com Ein Drittel aller Informatikprojekte scheitert - die Lösung: eine "scheinbar unmögliche" Kombination. von Michael Gasche, mimacom ag Requirement Engineering, Agilität und Individualsoftwareentwicklung Eine unmögliche Kombination? Die Projektkosten und -termine sind definiert, die während eines Workshops erarbeiteten Anforderungen liegen vor und es gilt nun einen geeigneten Auftragnehmer zu finden, der anhand dieser Anforderungen ein Festpreisangebot unterbreiten und aufgrund der Terminsituation möglichst schnell mit der Realisierungsphase beginnen kann. Das Projekt ist eigentlich schon unter Dach und Fach einzig die in den Angeboten definierte Projektdauer scheint den Auftraggeber vom Projektziel zu trennen. Nur allzu oft ist dies jedoch nicht der Fall! Traurige Statistik: 1 Drittel aller Softwareprojekte scheitert Ein Drittel aller Softwareprojekte scheitert. Ein weiterer Drittel wird zwar beendet, jedoch wird das verspätete oder kostenüberhöhte Ergebnis lediglich akzeptiert und Frustration ist möglicherweise täglicher Begleiter der Anwender. Diese Feststellung liegt bereits 8 Jahre zurück 1 und aktuelle Statistiken weisen auch keine ermutigendere Zahlen auf. Wie kann das sein? Immer wieder spriessen neue IT-Projektmethoden, welche die Projektrisiken verringern sollen. Auch in technischen Belangen verfügt man immer mehr über effiziente Entwicklungswerkzeuge und -plattformen, welche die Softwareherstellung vereinfachen soll. Dennoch scheint sich die Chronik der Softwareherstellung ständig zu wiederholen: ein von drei Softwareprojekten scheitert und ein weiteres kann nur mit beiden zugekniffenen Augen als erfolgreich bezeichnet werden. Gemäss Peter Bienert 2 lassen sich die Ursachen für gescheiterte Projekte in 4 Gruppen unterteilen: Falsches Verständnis vom Projekt Kenntnismangel und Vernachlässigung der Mitwirkungspflichten Unterschätzung der sich während des Projektes verändernden Geschäftsprozesse und die damit verbundenen Abweichungen vom Leistungsbeschrieb Vertrauen in Verträge anstatt in Konzepte 1 Buch Secrets of software success, ISBN Peter Bienert 1

2 Für Auftragnehmer und Auftraggeber gleichermassen ist eine Verinnerlichung dieser Ursachen meist nur über das eigene Empfinden und später über die manifestierte schmerzliche Erfahrung möglich. Der klassische Projektrahmen ist zu starr Ein Projekt wird üblicherweise bei Vertragsaufsetzung durch Termine, fixer Preis, Dauer, Ressourcen und Anforderungen des Auftraggebers beschrieben. Es fragt sich jedoch, ob ein solcher Rahmen einem Individualsoftwareprojekt gerecht wird. Ein Projekt kommt zudem meistens erst zustande, wenn die Dringlichkeit einer Problemlösung bereits schon sehr hoch ist. Dies erhöht die Gefahr, dass zu viele Anforderungen in zu kurzer Zeit umgesetzt und gerade zu viele Fliegen mit einer Klatsche erledigt werden sollten. Die heutigen agilen Geschäftsprozesse und das oft erst mit der Entstehung der Individualsoftwarelösung erarbeitete Wissen des Auftraggebers und Auftragnehmers für die Gestaltung der Lösung hemmt den Fortschritt oder bringt ein Projekt sogar zum Stillstand. Dies äussert sich oft wie folgt: sich in Änderung befindliche Softwarekomponenten müssten bereits schon wieder aufgrund neuer Anforderungen geändert werden. Der Koordinationsaufwand nachfolgender Tätigkeiten erhöht sich dabei zwangsläufig: Formulierung der Änderung Design Neue Abhängigkeiten prüfen Einfluss der Abhängigkeiten auf andere Komponenten oder Subsysteme prüfen und auflösen Realisierung Komponententest / Fachlicher Regressionstest Einspielung eines neuen Software Release auf einem Test- und später evtl. auf eine Produktionssystem Die nicht absehbaren Änderungen, die zur gewünschten Vollständigkeit der Funktionalität führen, die das aus heutiger Sicht gültige Projektziel unterstützen und die zum Zeitpunkt der Anforderungsphase nicht erfasst werden konnten, können nun fatale Folgen haben, wenn die am Anfang getroffenen Projektrahmenbedingungen ein solches Vorgehen nicht unterstützen: Die Operativität des Auftraggebers sinkt, da er selbst ungeplante Aufwände leisten muss, um die Anforderungen auszuformulieren. Die Aufwände des Auftragnehmers steigen oft, da solchen Mehrleistungen meistens nicht vollumfänglich Rechnung getragen werden kann. Die Motivation des Projektteams leidet. Emotionen blockieren lösungsorientierte Taten. Hier würde die Einsicht beider Parteien genügen, dass es durchaus Sinn machen kann, den Projektrahmen und das Vorgehen während des Projektes den wirklichen Umständen anzupassen. Dies geschieht jedoch in der Realität eher selten. Auch wenn Softwareprojekte gerne etwas salopp mit Projekten aus anderen Fachrichtungen, wie beispielsweise der Baubranche verglichen werden, so darf man nicht vergessen, dass man von einer Sache höchster Virtualität spricht. Ein Laie kann sich aufgrund einer Hochbauzeichnung schneller ein Bild eines Hauses als einer Software anhand von UML- und Flussdiagrammen machen. Vorgefertigte Prototypen können 2

3 hier Abhilfe schaffen und für den Auftraggeber als Entwürfe dienen. Allerdings müssen auch hier mehrere Entwurfsiterationen in Kauf genommen werden. Ein Fehler in der Gleichung? Umdenken ist gefragt. Es fällt auf, dass das durch den Projektrahmen (Termine, fixer Preis, Dauer, Ressourcen, ungenügende Anforderungen) starr gemachte Projekt eine unheimliche Flexibilität aufweisen sollte. Ein Fehler in der Gleichung? Wohl kaum! Auftraggeber und Auftragnehmer müssen hier umdenken. Das preisgünstigste Angebot kann sehr schnell zum Teuersten werden und im schlimmsten Fall sind der Nutzen und die Wirtschaftlichkeit des laufenden Projektes nicht mehr erkennbar. Eine Übereinkunft, welche greifbare Projektkosten und Aufwände, sowie die nötige Flexibilität im Projekt beschreibt, soll angestrebt werden. Die beiden Geschäftspartner sollen sich durch Teilergebnisse schrittweise dem Projektziel nähern. Es ist dabei nicht zwingend nötig, dass sämtliche Anforderungen genauestens bei der Vertragsunterzeichnung schon vorliegen. Unter Umständen hat der Auftragnehmer weder die Zeit noch das Wissen, wie Anforderungen an eine Software sinnvoll formuliert werden sollen. Dementsprechend sollte ein Vertrag auch so aufgesetzt werden, dass er dem Projektziel dient: Ein kontinuierliches Requirement Engineering (Ständiges kümmern um Anforderungen an eine Lösung) soll während des Projektes durch den Auftragnehmer und Auftraggeber durchgeführt und Kosten sollen auf Teilergebnisse aufgeteilt werden. Projekttermine können dabei so gewählt werden, dass beispielsweise ein agiles Vorgehen 3 möglich ist. Ein solches Vorgehen eignet sich, wenn Anforderungen an die zu erstellende Softwarelösung erst während der Realisierung formuliert werden können. Dabei muss nicht ausgeschlossen werden, dass ein Teil bereits exakt spezifizierter Anforderungen vor der Realisierung vorliegen (Vorprojekt), die mit Hilfe eines Festpreisangebotes (geklärter Festpreis) umgesetzt werden können. Die dann während des Projektes formulierten Anforderungen werden spezifiziert und daraus erfolgt jeweils ein kleines Festpreisangebot. D.h. es wird nicht ein möglichst früher Endtermin ermittelt, sondern mehrere Termine, welche es dem Auftraggeber erlaubt, Teile (z.b. fachliche Komponenten) der Software nach Prioritäten in die Geschäftsprozesse einzuführen. Die Anwenderakzeptanz kann so erhöht werden, da nicht erst am Ende des Projektes die ganze Lösung eingeführt wird und der Anwender sich schrittweise mit den Funktionen vertraut machen kann. Dies bietet auch die Möglichkeit, dass wichtige Usability Anforderungen zur rechten Zeit erkannt werden. Eine solche Vorgehensweise ist schlussendlich absehbarer und meist auch erfolgreicher, als ein Projekt, das nur aus Verkaufskontexten besteht, die bei Erreichung des Endtermins die Lösung aller Probleme verheissen. Eine übereinstimmende Vision des endgültigen Gesamtsystems beider Parteien ist hier viel wichtiger. Die Mitwirkungspflicht des Auftraggebers muss hier jedoch von Anfang an definiert und deren Wichtigkeit unterstrichen werden. Wie aber kann eine solche Übereinkunft getroffen werden? Was ist die Motivation für die beiden Geschäftspartner? 3 Präsentation Festpreisvertrag und agil nützt nicht viel?, Stefan Roock & Henning Wolf, 3

4 Motivation: Das übriggebliebene Drittel aller Softwareprojekte Die Anforderungen des Auftraggebers sollen zu jedem Zeitpunkt des Projektes berücksichtigt werden. Streng genommen lässt ein klassischer Projektrahmen die Berücksichtigung von neuen Anforderungen während der Realisierungsphase nur schwer zu oder die Berücksichtigung neuer Bedürfnisse führen zu Abweichungen bei den Terminen und Kosten. Hierbei kann leider schnell das Gefühl entstehen, dass das Projektziel gefährdet ist, obwohl andererseits auch entsprechende Anpassungen an den Leistungen vorgenommen werden. Das dadurch potentiell mehrmals entstehende und sich von Mal zu Mal vergrössernde Spannungsfeld soll eliminiert werden. Ein für Individualsoftwareprojekte adäquates agiles Vorgehen weist folgende Vorteile auf: Erhöht das Vertrauen der Vertragspartner Die Interessen des Auftraggebers decken sich besser mit den Interessen des Auftragnehmers Während der Realisierung kann mehr Innovation stattfinden Für den Auftragnehmer entstandene Mehrkosten werden nicht auf Wartung oder Weiterentwicklungen umgewälzt Mensch und Kommunikation kommen vor Tools und Prozessen Zeit wird für Zusammenarbeit anstatt Verhandlungen genutzt Die unterschiedlichen und mittlerweile auch schon in die Jahre gekommenen agilen Vorgehensweisen in der Softwareentwicklung sind nach wie vor die Modernsten. Dennoch haben auch diese Vorgehen ihre Schwächen: z.b. die Extreme Programming - Methode versucht ohne Entwicklungsprozesse auszukommen, was in Projekten ab mittlerer Grösse ( Mio. CHF) ohne weiteres als fahrlässig bezeichnet werden kann. Entscheidend ist, dass die Prinzipien einer agilen Vorgehensweise über dem konkreten agilen Softwareentwicklungsvorgehen stehen. Fazit: Anforderungen sind allgegenwärtig Ein während des Projektes fortlaufendes Requirement Engineering, bei welchem die daraus resultierenden Kosten nicht ständige Diskussion verursachen, sondern Programm sind, kann zum Erfolg führen. Die Vorteile des agilen Vorgehens sollen dabei möglichst genutzt werden, denn die Projekte der Individualsoftwareentwicklung unterliegen praktisch immer auch während des Projektes ändernden Wertschöpfungsketten. Es spricht auch nichts dagegen, beispielsweise eine gut definierte Projektführungsmethode wie HERMES 4 mit den Prinzipien des agilen Vorgehens in der Konzeptund Realisierungsphase zu verknüpfen. Es gilt nach wie vor: Das beste Angebot ist, je nach Belieben, zu unterbreiten oder auszuwählen

5 Personenbeschreibung Michael Gasche, dipl. Ing.FH, ist Senior Software Engineer und Projektleiter bei der Firma mimacom ag und ist weitgehend mit Führungsaufgaben und aus fachlicher Sicht unterschiedlichsten Softwareprojekten betraut. Mimacom wurde 1999 als Spin-Off der Fachhochschule Burgdorf gegründet und beschäftigt heute 30 Mitarbeiter und besitzt eine Niederlassung in Spanien. Das Software- Unternehmen hat sich seit der Gründung auf Open Source beziehungsweise JEE- / Java-Entwicklungen spezialisiert. Mit edoras verfügt es über eine technologisch und funktional ausgereifte Produktpalette und eine leistungsfähige Entwicklungsplattform, mit der modelbasiert und effizient Individualsoftware gebaut wird. Kontakt: Michael Gasche, michael.gasche@mimacom.ch Über Goldwyn Partners Group AG Die Goldwyn Partners Group AG ist ein unabhängiges Executive Search- und Recruiting-Unternehmen, welches seit 1998 erfolgreich in Information Technology, Banking & Financial Services und Finance & Controlling. Für einen hohen und nachhaltigen Vermittlungserfolg sorgen nebst einem extensiven Netzwerk auch ein effektives und kontextspezifisches Suchsystem sowie ein professionelles und agiles Consulting-Team. Um hochgesteckte Unternehmensziele zu erreichen, benötigen Firmen die richtigen Fachund Führungskräfte. Als neutraler Mittler bringt Goldwyn Partners Group AG qualifizierte Kräfte und interessante Unternehmen gezielt und kompetent zusammen