Erfolgreiche IT-Projekte zu absolvieren ist keine Selbstverständlichkeit. Immer wieder müssen Projektlaufzeiten verlängert werden und mehr Geld als ursprünglich geplant hinein gepumpt werden, damit ein Projekt überhaupt zu einem Ende kommt. Und selbst dann ist das Ergebnis im Vergleich zu den ersten Erwartungen sehr ernüchternd. Nur Veränderungen an der richtigen Stelle des Entwicklungsprozesses können mitunter wahre Wunder bewirken. Allerdings wird diese richtige Stelle nicht immer erkannt, sondern versucht, einen oder mehrere Schuldige für den Misserfolg zu finden. Wir möchten in diesem Artikel zeigen, dass gut gewählte Investitionen das Erreichen der Projektziele vereinfachen können und somit die Zahl der erfolgreich abgeschlossenen Projekte gesteigert werden kann.

Wir gehen dabei von einem imaginären Projekt in einem imaginären Unternehmen aus, das leider gescheitert ist. Welche Lehren aus dem Misserfolg gezogen werden, zeigen wir in diesem kleinen „Bühnenstück“.

Das Dilemma

Es war an einem schwülen Sommertag, als die Geschäftsleitung, vertreten durch Herrn Dr. Hohestier, die Verantwortlichen des Projekts zu einem Meeting zusammenholte. Die Stimmung war bedrückt. Die meisten ahnten bereits, was kommen würde.

„Ich habe schlechte Neuigkeiten“ eröffnete Herr Dr. Hohestier „Aufgrund der schlechten Performance in diesem Entwicklungsprojekt, der noch zu erwartenden hohen Kosten und der niedrigen Wahrscheinlichkeit zumindest einen Teilerfolg mit diesem Projekt zu erreichen, habe ich mich entschlossen, das Projekt mit sofortiger Wirkung abzubrechen. Mir ist bewusst, dass dadurch die bereits getätigten Aufwände umsonst waren, aber eine Alternative sehe ich nicht.“

O.K., die Geschichte klingt eher nach dem Anfang eines minder unterhaltsamen Romans als einem Tatsachenbericht. Fakt ist aber: Derartiges passiert in der Welt der Systementwicklung. Und das nicht gerade selten.

Die Standish Group veröffentlicht in regelmäßigen Abständen ihren Chaosreport, in dem sich diese Aussage widerspiegelt. Der Chaos Summary Report 2009 zeigt, dass nur etwa ein Drittel der Projekte erfolgreich, also im Rahmen des festgelegten Budgets und Zeitplans, abgeschlossen wurden und dabei auch noch die Anforderungen erfüllten. Diese Projekte sind also wirklich so gelaufen, wie man sich das gedacht hatte. Und da es sich dabei lediglich um ein Drittel aller Projekte handelt, ist das bereits als ein Erfolg anzusehen. Hut ab – weiter so.

Die Hälfte der Projekte wurden zwar abgeschlossen – puh, immer noch besser als unser anfänglicher Krimi – aber leider nicht so wie geplant. Terminverzug, höhere Kosten oder Auslieferung von Systemen, die nicht alle gewünschten bzw. geforderten Funktionalitäten zur Gänze erfüllen, zeichnen diese Projekte aus. So wirklich zufrieden kann man mit dem Ergebnis also nicht sein. Manchmal muss der Auftraggeber des Systems sehr geduldig wenn nicht sogar leidensfähig sein.

Und der Rest? Nun der hat es nicht geschafft. Diese Projekte wurden ohne nennenswertes Ergebnis abgebrochen. Das bedeutet Zeit und Geld wurden in den Sand gesetzt. Das Engagement der beteiligten Mitarbeiter wurde verbrannt.

Aber kehren wir zu unserem Meeting zurück und beobachten, was weiter passiert.

Dr. Hohestier: „Wir werden natürlich nicht einfach abwarten, wie das nächste Projekt sich entwickeln wird. Daher haben wir uns vorgenommen, die Design- und Implementierungsabteilungen neu zu organisieren und mit neuen Mitarbeitern zu verstärken. Wir sind fest davon überzeugt, dass wir sogar in kurzer Zeit die Probleme in den Griff bekommen werden und die nächsten Projekte erfolgreich abschließen können. Meine Damen und Herren, Sie sehen also, es wird sich was tun. Ihnen allen einen schönen Tag noch.“

Die Schuldigen werden gesucht

Einen Tag später haben der Projektleiter Herr Unterhändler, der wohl auch zukünftige Projekte leiten soll, und der Leiter der Design- und Implementierungsabteilung Herr Sündenbock eine Besprechung. Es geht vor allem um das Thema, was Herr Sündenbock in seiner Abteilung verbessern muss, damit solche Pleiten in den kommenden Projekten nicht wieder passieren.

Herr Unterhändler: „Die Chefetage ist natürlich ziemlich sauer. Immerhin war die Projektlaufzeit fast drei Jahre, bevor die Notbremse gezogen wurde. Da haben wir ziemlich viel Geld in den Sand gesetzt. Das dürfen wir auf keinen Fall nochmal zulassen. Ich habe mich ein bisschen umgehört, und mir wurde empfohlen, ein eher agiles Vorgehen in den Projekten zu versuchen. SCRUM [1] z. B. arbeitet mit kurzen Iterationen, die vielleicht drei Wochen dauern. Am Ende jeder Iteration kann man dann sehen, ob in der Implementierung was Brauchbares entsteht oder nicht. Wenn nicht, können wir eben schon nach drei Wochen eingreifen und nicht erst nach Monaten oder sogar Jahren.“

Agile Vorgehen haben hier natürlich klare Vorteile, da schon relativ früh Ergebnisse produziert werden. Die hier vorgestellte Methode SCRUM zerlegt die Entwicklung eines Systems in kleine überschaubare Happen, die in Iterationen entwickelt werden. Das System entsteht also Schritt für Schritt und man kann schon nach ein paar Iterationen absehen, ob die gesetzten Ziele erreicht werden. Man wird also nicht erst nach langer Projektlaufzeit mit irgendwelchen Ergebnissen überrascht, sondern weiß schon frühzeitig, was auf einen zukommt.

Herr Sündenbock: „Sicher können wir uns noch verbessern und sollten die kurze Auszeit zwischen den Projekten nutzen, um unser Vorgehen zu überdenken. Und der Ansatz in der Entwicklung mit agilen Methoden zu arbeiten, klingt vielversprechend. Es ist natürlich besser, eine Fehlentwicklung nicht erst nach drei Jahren zu stoppen, sondern die Irrungen und Wirrungen schon nach einer Woche oder drei Wochen aufzudecken. Aber ich möchte auch darauf hinweisen, dass wir sehr viel Zeit dadurch verloren haben, da sich alle paar Tage die Erwartungen, was wir überhaupt realisieren sollen, geändert haben bzw. die Anforderungen an das System einfach unklar waren. Ich würde in den drei Wochen lieber etwas realisieren, was auch tatsächlich benötigt wird. Somit sollten wir uns auch damit befassen, wie wir die Anforderungsanalyse erfolgreich meistern. Wir könnten in kurzen Interrationen Anforderungen realisieren, die wirklich vom Stakeholder stammen und ausreichend reflektiert sind“ (Abb. 1).

 

Tatsächlich lassen sich mehr als die Hälfte (ca. 65 %) der Fehler in Softwareprodukten auf Unzulänglichkeiten in der Analyse zurückführen. Demnach kann ein agiles Vorgehen in der Realisierung die negativen Auswirkungen zwar eindämmen, aber nicht endgültig beseitigen. Das erreicht man nur, indem man das Übel an den Wurzeln packt. Also dort ansetzt, wo die Fehler tatsächlich entstehen.

Um eine Explosion der kritischen Faktoren Kosten und Zeit zu vermeiden, müssen die Ursachen von Analysefehlern und Defiziten beseitigt werden.

Herr Sündenbock: „Wenn die Kollegen uns genauere Angaben machen könnten, was wir implementieren sollen, würde uns das sehr helfen, und vor allem sollten sie sich erst Gedanken machen und dann zu uns kommen. Was wir an Zeit verloren haben! Es gab Zeiten im Projekt, in denen fast unsere gesamten Ressourcen dazu eingesetzt wurden, bereits fertige Softwarekomponenten abzuändern, nur weil die Vorstellungen sich geändert haben. Vielleicht haben die Stakeholder und wir erst verstanden, was das System leisten soll, als wir anhand des bestehenden Ergebnisses gesehen haben, was wir definitiv nicht verwenden können. Die wirklichen Anforderungen allerdings in einem derartigen Ausschlussverfahren zu ermitteln, kann sich kein Unternehmen leisten.“

Und das macht das Projekt so richtig teuer. Je später ein Fehler entdeckt wird, desto aufwändiger ist es, diesen wieder auszubügeln. Und dementsprechend muss mehr Budget eingesetzt werden, um den Fehler zu beheben (Abb. 2). Muss man, um einen Fehler bereits in der Analyse zu beheben, nur einen Personentag investieren, sind es im Betrieb bereits 100 PT. Rechnet man dies mit den immensen Personalkosten auf, kann so ein Fehler mit der Zeit ganz schön teuer werden.

 

Wir dürfen dabei aber nicht nur die monetären Kosten im Auge haben, sondern auch den möglichen Imageschaden, der durch zu spät erkannte Fehler entstehen kann. Man denke nur an große Rückrufaktionen in der Automobilbranche, bei denen manchmal mehrere 100 000 Fahrzeuge aufgrund von Fehlern zurückgerufen werden. Wer kauft schon ein Fahrzeug von einem Hersteller, der in der Presse über fehlerhafte Bremspedale zu einer unschönen Berühmtheit gelangt ist? Solche immensen Schäden sind Extrembeispiele, die aber leider recht häufig vorkommen. Ganz nach dem Motto „Kleinvieh macht auch Mist“ dürfen wir aber auch geringere Imageschäden nicht außer Acht lassen. Bei der Frage, ob mit einem Unternehmen in zukünftigen Projekten zusammengearbeitet werden soll, kann ein schlecht gelaufenes Projekt aus der Vergangenheit entscheidend sein.

Herr Unterhändler: „Sie meinen also, mit der Neuorganisation und Verstärkung unserer Design- und Implementierungsabteilung allein ist es nicht getan?“

Herr Sündenbock: „Mitnichten. Erst wenn wir es schaffen, die Anforderungen an die zu programmierende Software exakt und strukturiert aufzunehmen und uns darüber abzustimmen, können wir die Software auch vernünftig realisieren. Bevor wir überhaupt eine Codezeile beginnen, möchten wir wissen, was wir machen sollen. Im Moment raten wir das eher, als das wir es wissen.“

Herr Unterhändler: „Das heißt, wir sollten mehr Augenmerk auf die Analyse als auf Design und Implementierung legen?“

Herr Sündenbock: „Ja. Zwar möchte ich nicht behaupten, dass wir vollkommen schuldlos an dem Debakel sind, aber immer nur uns die Schuld in die Schuhe zu schieben, ist zu einfach. Selbst die am besten organisierten Spitzenprogrammierer sind machtlos, wenn ihnen niemand sagen kann, was eigentlich gewollt ist. Also plädiere ich dafür, an dieser Stelle zu arbeiten.“

Das eigentliche Problem wird erkannt

Vollkommen richtig erkannt, man kann einfach nicht erwarten, dass die Realisierung immer genau weiß, wie denn die Anforderungen lauten, die sie umsetzen müssen. Denn das ist stark von der Qualität der Basis, auf der die Realsierung aufsetzen kann, abhängig. Und die Basis ist nun einmal das Ergebnis aus der Analyse. Und genau dort gilt es herauszufinden, was eigentlich gewünscht wird. Denn „Wer nicht weiß was er will, braucht sich nicht über das zu wundern, was er bekommt.“ Ja gut, aber sind wir mal ehrlich, eine Analyse wird wohl immer durchgeführt werden. Mal mit größerem und mit geringerem Aufwand. Warum tauchen trotzdem solche Probleme auf?

Ein paar Tage später sitzt Hr. Unterhändler mit Herrn Dr. Hohestier zusammen und bespricht die nächsten Schritte. Herr Unterhändler hat dafür eine Präsentation vorbereitet, die er gerade vorstellt.

„… ich möchte an dieser Stelle nochmal betonen, dass eine gut strukturierte und wohl überlegt durchgeführte Analyse eine erhebliche Kostenersparnis in unseren Projekten bewirken kann.“ (Genau, Preisargumente sind beim Chef immer gut) „Mit den richtigen Analysetechniken und sauberen Analyseergebnissen reduzieren wir die Anzahl der Analysefehler, die, wenn sie unentdeckt bleiben, sehr teuer werden können. Auch reduzieren wir die Anzahl der Fehlentwicklungen, die durch Missverständnisse zwischen den Projektbeteiligten entstehen.“

Dr. Hohestier: „Aber wir haben doch bereits eine Analysephase, bevor es in die Realisierung geht.“

Hr. Unterhändler: „Richtig, allerdings nur sehr rudimentär und mehr dem Prinzip ,machen wir mal was‘ folgend als wirklich durchdacht an die Aufgaben heranzugehen. Folglich leiden die Analyseergebnisse an Anforderungen in nur mäßiger Qualität, zum Teil unnötigen Anforderungen und – dem Hauptproblem – sich ständig ändernde Anforderungen.“

Genau, eine schlecht oder nur unzureichend durchgeführte Analyse hat mit vielen Problemen zu kämpfen. Dabei können sechs Hauptprobleme identifiziert werden:

• Unklare Zielvorstellungen: So unterschiedlich wie die Menschen sind, so unterschiedlich sind auch die Erwartungen an das zu entwickelnde System. Deshalb sollten von vornherein alle Stakeholder ermittelt werden. Erst wenn Repräsentanten aller Stakeholdergruppen ihre Ziele und Erwartungen an das System formulieren, gelangt man zu einer klaren und vollständigen Zielvorstellung. Eine allen bekannte Zielvorstellung des zu produzierenden Ergebnisses eines Projekts lässt alle Beteiligten in dieselbe Richtung laufen.
• Hohe Komplexität: Die immer komplexer werdenden Aufgabenstellungen bedingen, dass auch die unterstützenden Systeme durch wachsende Komplexität gekennzeichnet sind. Ferner existieren zwischen vielen Anforderungen komplizierte wechselseitige Abhängigkeiten, die nach einer detaillierten Analyse verlangen.
• Kommunikationsprobleme: Projektbeteiligte sprechen nicht alle die gleiche Sprache, denn Sprache ist kein genormtes Ausdrucksmedium. Jeder Mensch ist in seinem Sprachgebrauch von seiner Umwelt, seinem Fachgebiet, seinem Hintergrund, seinen Kenntnissen und seinen persönlichen Erfahrungen geprägt. Das kann man auch an alltäglichen Dingen sehen, Bestellen Sie doch mal in Berlin und in München einen Pfannkuchen und schauen was sie jeweils bekommen.
• Sich ständig ändernde Anforderungen: Kennen Sie das Gefühl, wenn sich eine nicht unerhebliche Anzahl von Anforderungen während des Projektes kontinuierlich verändert? Es ist normal, dass alle Stakeholder während des Projektes dazulernen und sich dies auch in den Anforderungen niederschlägt. Zudem bleibt die Welt um Sie herum nicht stehen und die Rahmenbedingungen des Projektes verändern sich. Da Änderungen sich sukzessive auf das ganze Projekt auswirken können, kann die Architektur des Systems langsam zerbröckeln. Das Flicken von Code macht Programme schwer wartbar und unverständlich.
• Schlechte Anforderungsqualität: Anforderungen in schlechter Qualität werden häufig falsch oder gar nicht verstanden. Das ermöglicht Fehlinterpretationen, die zu manch überraschendem Ergebnis führen.Zum Beispiel kann eine Anforderung mit folgendem Wortlaut: „Der Benutzer soll alle Kundendaten ändern können“ vollkommen falsch verstanden werden. Lag die Intention hinter der Anforderung darin, dass ein Benutzer die über ihn im System gespeicherten Daten ändern kann, so kann in diese Anforderung aber auch die Möglichkeit, das ein Benutzer die Daten eines anderen Benutzers ändern kann, hinein interpretiert werden. Zudem geht aus der Anforderung gar nicht hervor, dass der Benutzer dies im System tut.
• Die Kreativität und die oftmals vorhandene tief greifende Fachkenntnis von Entwicklern, die in vielen Fällen Projekte rettet, kann in anderen Fällen zu erhöhtem Aufwand und auch zu Fehlentwicklungen führen. Ausschmückungen und zusätzliche Funktionen (Englisch: gold plating) weisen auf die Tendenz einiger Entwickler hin, neue Funktionalitäten hinzuzufügen, die nicht in der Anforderungsspezifikation standen. Manchmal treffen diese nicht geforderten Zusatzfunktionen genau den Geschmack der Benutzer. Allzu oft allerdings finden Benutzer diese Funktionalität nicht nützlich, und der Aufwand für die Spezifikation, das Design, die Implementierung und den Test dieser Funktion war überflüssig.

Dr. Hohestier: „Verstehe, unser Ziel muss es sein, nicht nur zu analysieren, sondern eine professionelle Anforderungsanalyse mit erprobten und den Gegebenheiten angepassten Techniken durchzuführen.“

Herr Unterhändler: „Korrekt. Wir benötigen die richtigen Techniken, um Anforderungen zu ermitteln, zu dokumentieren, zu prüfen und zu verwalten. Zusammengefasst spricht man dabei vom Requirements Engineering.“

 

Zusammengefasst beinhaltet das Requirements Engineering (RE) alle durchzuführenden Tätigkeiten, um die relevanten Anforderungen zu erhalten (Abb. 3). All die Tätigkeiten können in vier Haupttätigkeiten zusammengefasst werden, die in Abbildung 4 dargestellt werden.

 

Requirements Engineering ist also mehr, als nur einfach so einen Prosatext zu schreiben. Professionelles Requirements Engineering sorgt dafür, dass alle relevanten Anforderungen aufgedeckt werden und verständlich dokumentiert werden. Dafür werden verschiedenste Mittel eingesetzt, z. B. eine Satzschablone, mit deren Hilfe Anforderungen einfach, schnell und in guter Qualität erzeugt werden können. Außerdem bedient sich das Requirements Engineering Hilfsmitteln, von denen man eigentlich meinen würde, sie werden nur in der Architektur oder dem Design verwendet. Die Rede ist hier von Modellen (z. B. UML-Modellen) [3], [4] als Dokumentationsmittel. Im Requirements Engineering werden natürliche Sprache und Modelle intelligent gemischt, sodass die Anforderungen exakter und besser vor Fehlinterpretationen geschützt sind. Idealerweise erlaubt dies, die Analyseergebnisse nahtlos in ein sauberes Design zu überführen.

Dr. Hohestier: „Sehr schön. Dann lassen Sie uns unverzüglich an das Problem herangehen und unser Requirements Engineering professioneller aufsetzen. Denn Sie haben mich jetzt überzeugt, dass dies ein Meilenstein zum Erfolg unserer Projekte ist. Ach ja und die Neuorganisation der Design- und Entwicklungsabteilung setzen wir erst einmal aus. Damit haben wir schon zu viele Ängste vor Entlassungen geschürt, die wie sich jetzt herausgestellt hat, unbegründet sind.“

Fazit

Natürlich sind Herr Dr. Hohestier, Herr Unterhändler und Herr Sündenbock von uns frei erfundene Charaktere, und Ähnlichkeiten mit lebenden Personen sind gewollt. Falls Ihnen die Situation und die Gespräche bekannt vorkommen, dann leben Sie in unserer realen IT-Welt. Holperige oder schleppend verlaufende Projekte aufgrund mangelhafter Analyse sind keine Seltenheit. In vielen Entwicklungsprojekten wird dem Requirements Engineering, dem professionellen Umgang mit Anforderungen, zu wenig Aufmerksamkeit gewidmet. Welche Auswirkungen das haben kann, haben wir in diesem Artikel gezeigt. Machen Sie sich über das Requirements Engineering in Ihren Projekten Gedanken, denn schließlich kann dies über Erfolg oder Nichterfolg entscheidend sein. Im privaten Umfeld handeln Sie genauso. Bevor Sie sich bei Ihrem Lieblingsitaliener eine Pizza bestellen, überlegen Sie sich doch auch, was ihnen schmecken würde, worauf Sie allergisch reagieren und für welche Zutaten Sie Ihre Frau kritisierend anblicken wird und belassen Ihre Bestellung nicht bei „eine Pizza bitte“. Sobald eine Vorstellung existiert, die enttäuscht werden könnte, macht es Sinn, sie zu artikulieren. Sie wollen schließlich keine negativen Überraschungen erleben. Wenn Sie ein Haus bauen wollen, dann werden Sie auch das Haus von einem Architekten planen lassen, bevor überhaupt das Loch für das Fundament gegraben wird.

Geben Sie also dem Requirements Engineering genügend Spielraum in Ihren Projekten, damit solche extrem negativen Projekterfahrungen bei Ihnen keine Chance haben. Wenn Sie mehr zum Thema Requirements Engineering wissen wollen, besuchen Sie uns auf unserer Webseite unter www.sophist.de. Zusätzlich können Sie zwei Probekapitel aus dem Buch „Requirements-Engineering und -Management: Professionelle, iterative Anforderungsanalyse für die Praxis.“ erhalten. Senden Sie dafür einfach eine kurze Mail an heureka[at]sophist.de.

Aufmacherbild: „hand destroying house made of color wooden blocks“  von Shutterstock / Urheberrecht: Artsem Martysiuk