| |||
| | | |
| |
Wann ist ein Projekt erfolgreich?
Ein wichtiges Indiz für die mangelnde Qualität des Problembewusstseins ist die Tatsache, dass sich kaum jemand ernsthaft überlegt, ob es überhaupt ein Projekt gibt, das 100% der definierten Anforderungen - aber auch nicht mehr als diese - umsetzt, das sein Budget um höchstens 10% überzieht und im Rahmen der terminlichen Abmachungen endgültig und vollständig fertig wird. Ich denke, die Frage, die sich uns stellt, lautet nicht, worin sich erfolgreiche Softwareprojekte von erfolglosen unterscheiden. Die Frage ist vielmehr, was der eine oder andere von uns vor diesem Hintergrund noch als erfolgreich bezeichnet haben möchte. Die Standish Group hat darauf ihre eigene Antwort gegeben. Manch einer von uns aber wäre froh, wenn er nur schon die Typ-2-Projekte erfolgreich nennen dürfte. Verfügt er doch in seinem Umkreis über keine Erfahrungen mit Typ-1-Projekten. Er hat noch nie ein Typ-1-Projekt gesehen. Softwareprojekte werden zuweilen als erfolgreich bezeichnet, wenn die Überschreitungen unter 30% gehalten werden können oder der Anwender nur ein Viertel des Ergebnisses reklamiert. Softwareentwickler neigen oft dazu, solche Projekte als gelungen einzustufen, aber die Mitglieder unserer Anwendergemeinde sind weniger nachsichtig. Anwender sind daran gewöhnt, gesteckte Ziele in ihren Fachbereichen mit einer Konsequenz zu erreichen, die man im Softwarebereich nicht kennt. (DeMarco) In Bauprojekten gilt bereits eine Überschreitung von 6-10 % als krasser Misserfolg, ganz zu schweigen von mangelhaften Ergebnissen, die von einem real existierenden Bauherrn sowieso nicht akzeptiert werden. Erfolg ist eine "Singularität" Typ-1-Projekte im Sinne der Standish Group sind selten. Man begegnet ihnen in einem durchschnittlichen Manager- oder Informatikerleben wohl nie. Es handelt sich um Singularitäten, für die eigene Gesetze gelten. Aus diesen Projekten wird man nicht viel lernen können. Dass sie gelungen sind, kann auch Zufall sein. Lassen wir sie beiseite (1). Das Dilemma Anders herum gefragt: Ist ein Softwareprojekt schon erfolgreich, wenn es ein lauffähiges System - und nicht mehr als das - hervorbringt?
Warum gewähren die Auftraggeber und Nutzer als "Besiegte" dem Softwareprojekt den von diesem erbetenen Pyrrhusfrieden überhaupt? Ich weiß es nicht und denke, es hat nicht viel Sinn, sich darüber lange Zeit aufzuhalten. DeMarco sagt es sehr schön: Zu viele Softwareprojekte erreichen in wichtigen Punkten ihr Ziel nicht, sodass der "Erfolg" eines Projekts nachträglich neu definiert wird, damit niemand den Mut verliert. Wenn wir nicht einmal in der Lage sind, universell einklagbar anzugeben, was ein erfolgreiches Softwareprojekt ist, warum klagen wir denn über den Misserfolg? Täuscht sich unser Geist, wenn er festzustellen meint, hier laufe etwas schief? Diese Unsicherheit in Bezug auf die Gesamtbeurteilung spricht sehr für die These der allgemeinen Verwahrlosung des Denkens im Umfeld der Softwareprojekte. Gordischer Knoten Das Problem gleicht dem Gordischen Knoten. Entwirren lässt es sich nicht. Wäre Cobbs Aussage zutreffend und wüssten wir - wie behauptet - wirklich, warum Projekte scheitern und wie man es verhindern kann, so gründete das ganze Debakel nur in der aus irgendwelchen Gründen mangelhaften Umsetzung unseres Wissens. Cobbs Paradox wäre gar keines! Im Grunde wirft uns Cobb doch bloß vor, undiszipliniert und verantwortungslos zu handeln. Stimmt. Und stimmt auch wieder nicht: Einerseits können manchenorts Disziplin und Verantwortungsbewusstsein noch stark und gewinnbringend gefördert werden, andererseits haben das andere längst getan, haben damit aber nur wenig erreicht. Man kann nicht beweisen, dass es eine absolute Disziplin und ein maximal ausgeprägtes Verantwortungsbewusstsein bei allen Beteiligten nicht doch schaffen würden, den Augiasstall auszumisten. Man kann aber eine absolute Disziplin und ein maximal ausgeprägtes Verantwortungsgefühl nicht etablieren, und schon gar nicht in einer Welt, die im Übrigen allem Militärischen spinnefeind geworden ist. Ein Zukunftsschock Wann erleben wir den Zukunftsschock im Bereich der Softwareprojekte? Das heißt, an welchem Punkt öffnet sich die Schere zwischen Disziplinierbarkeit und Verantwortbarkeit und dem entsprechenden Bedarf zwecks nachhaltiger Verbesserung der Lage endgültig? Vor dem Reifepunkt, wo die Fähigkeit zur Selbstdisziplinierung und Übernahme von Verantwortung den Bedarf noch zu decken vermag, könnte der IT-Frosch noch aus dem Topf herausspringen. Rechts davon ist es dann um ihn geschehen. Je näher wir der Ausschöpfung des Potenzials der Erfolgsfaktoren der Standish Group kommen, umso größer wird der Bedarf an Selbstdisziplinierung und Übernahme von Verantwortlichkeit bei allen Beteiligten im Unternehmen. Genau an dem Punkt, an dem die Unternehmung glaubt, die Situation voll im Griff zu haben - am Reifepunkt - erwartet sie der Zukunftsschock. Es folgen Stagnation, Resignation und Zynismus. Dass der Reifepunkt erst dann, wenn das gesamte Potenzial der Erfolgspunkte ausgeschöpft ist, zu erwarten sei, ist eine der absurden Illusionen, die Fröschen und IT-Menschen gemeinsam ist. Paradigmenwechsel Darum gibt es ja überhaupt den Paradigmenwechsel, weil es nämlich an einem bestimmten Punkt unökonomisch wird, ihn nicht zu vollziehen und stattdessen weiterzumachen wie bisher. Es nützt nichts, wenn man ein Pferd nach allen Regeln der Kunst zu reiten versteht, um mit ihm in einem Dressur-Grandprix an den Start zu gehen, wenn das Pferd, das man aufgezäumt hat, ein Ackergaul ist. Stellen wir uns noch einmal die Frage: Wann ist ein Projekt erfolgreich?
Pyrrhusfriede Ehrlicherweise müssen wir Folgendes zugeben:
Das genau ist die Formel, die den Frosch bewegt, in dem Topf, in dem das Wasser immer heißer wird, sitzenzubleiben. Anmerkungen 1) Wer dennoch ein solches Projekt kennt, gehört zu den happy few. Der Leiter eines solchen Projekts darf sich das Verdienstkreuz der Softwareentwicklung an die Brust heften. 2) Pyrrhus, König von Epirus, siegte 279 v. Chr. bei Ausculum in Süditalien über die Römer, erlitt dabei aber so schwere Verluste, dass er die Besiegten um Frieden bitten musste. Die Bitte wurde vom römischen Senat abgewiesen. 04/2002, Adrian W. Fröhlich
| | | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| © 1999-2010 FEiG & PARTNER | Nutzungsbedingungen | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |  |  | |  | |  | |  | |  | |  | |  | |  | |   |
|
| ||
| know how news veranstaltungen | |
| ||
| ||
| ||
| ||
|
