„Viele Projekte scheitern, bevor sie überhaupt begonnen haben“

Dieses Zitat von Tim Lister können wir mit unserer Beratungspraxis leider nur zu gut bestätigen.

Im letzten Artikel haben wir über agile Vorgehensmodelle gesprochen. Heute möchten wir näher auf die kurze aber sehr entscheidende Phase zu Beginn der Systementwicklung eingehen.

Zunächst einmal sollten Sie über den Kontext und die Grenzen des zu entwickelnden Systems Bescheid wissen, die Ziele des Projekts festlegen und ihre Anforderungsquellen kennen. Das können zum Beispiel Stakeholder, Dokumente oder auch Systeme im Betrieb sein. Ob Sie mit dem Kontext Ihres Systems, den Zielen oder dem Analysieren Ihrer Anforderungsquellen starten ist komplett Ihnen überlassen. Wichtig ist nur, dass Sie all diese Tätigkeiten ausführen, bevor es an die klassische Anforderungsermittlung geht.

Stellen Sie sich folgendes Szenario vor:

Morgens auf einer Abbruchbaustelle: Das Haus soll weg. Die Abrissbirne pendelt, Wände stürzen lautstark in sich zusammen, die Bauarbeiter husten und müssen aufpassen, nicht von fallenden Trümmerteilen erschlagen zu werden – als plötzlich der Bauleiter auftaucht und sie anherrscht: „Ihr reist das falsche Haus ab!“

Kennen Sie das? Sie arbeiten unter Zeitdruck und härtesten Bedingungen, um das System rechtzeitig fertig zu bekommen, Anforderungen ändern sich in letzter Minute, Tester arbeiten Tag und Nacht,um Fehler zu finden, die die Programmierer aufgrund des Zeitdrucks gemacht haben. Und dann nimmt der Kunde das System nicht ab oder es lässt sich am Markt nicht verkaufen. Oftmals liegt es daran, dass das Projekt zu schnell gestartet wurde und aus Zeitgründen mangelte es an einer konkreten Ziel-, Stakeholder- und Kontextanalyse.

Anhand diesen Szenarios wird uns klar – das Festlegen der Ziele hat für das Produkt einen großen Einfluss auf den Erfolg der Entwicklung. Denn ohne oder unklar definierte Ziele, haben wir keine Ausgangsbasis für die anschließende Anforderungsanalyse.

Ein weiterer wichtiger Aspekt für eine erfolgreiche Systementwicklung ist das Einbeziehen der Stakeholder. Stellen Sie ihn immer in den Mittelpunkt Ihrer Entwicklung. Wir definieren den Stakeholder wie folgt:

Stakeholder sind Ihre Informationslieferanten für Ziele, Anforderungen und Randbedingungen. Die einfachste Art, Stakeholder systematisch zu erfassen, sind Tabellen. Laut IREB (International Requirements Engineering Board) muss eine solche Tabelle die folgenden Werte beinhalten:

• Name
• Funktion (Rolle)
• weitere Personen- und Kontaktdaten,
• zeitliche und räumliche Verfügbarkeit während der Projektlaufzeit,
• Relevanz des Stakeholders,
• sein Wissensgebiet und – umfang
• seine Ziele und Interessen bezogen auf das Projekt

Um Ihre Stakeholder zu klassifizieren empfehlen wir Ihnen das Stakeholderanalysemodell von Babou Srinivasan, das die Stakeholder je nach Höhe von Einfluss und Motivation in die vier folgenden Gruppen unterteilt:

Abbildung 1: Die Stakeholderanalyse nach Einfluss und Motivation

Stakeholder mit hohem Einfluss und hoher Motivation – Integrieren Sie die Macher

Binden Sie diese Stakeholder so stark wie möglich ins Projekt ein, denn sie haben nicht nur den Willen, das Projekt zur allseitigen Zufriedenheit voranzutreiben, sondern auch die Macht, Entscheidungen durchzusetzen.

Stakeholder mit hohem Einfluss, aber geringer Motivation – Informieren Sie die Mächtigen

Investieren Sie genug Aufwand, um diese Stakeholder zufriedenzustellen, pflegen Sie gute Kontakte – aber vermeiden Sie es, sie mit zu vielen Informationen und Details zu langweilen.

Stakeholder mit geringem Einfluss, aber hoher Motivation – Nutzen Sie Projektseismographen

Halten Sie diese Stakeholder stets auf dem Laufenden über die Entwicklungen im Projekt und pflegen Sie eine gute Kommunikation, denn diese Stakeholder können Sie rechtzeitig auf das Entstehen gravierender Probleme hinweisen.

Stakeholder mit geringem Einfluss und geringer Motivation – Stellen Sie Informationen zur Verfügung

Vergessen Sie diese Stakeholder nicht, aber investieren Sie nicht zu viel Aufwand in ihre Pflege. Hier genügt es meist, die relevanten Informationen z. B. in einem Intranet online zur Verfügung zu stellen und die Möglichkeit des Zugriffs vorzusehen.

Mit der Dokumentation und der Kategorisierung unserer Stakeholder sind wir bereits ans Ende unseres fünften Artikels angelangt. Wenn Sie mehr Details zu den beschriebenen Inhalten wünschen oder Sie wissen möchten, wie genau Sie eigentlich die System- und Kontextgrenzen bestimmen, dann können Sie das hier Requirements- Engineering und –Management – Aus der Praxis von klassisch bis agil nachlesen.

Wir wünschen Ihnen viel Erfolg bei der Bearbeitung der Quizfragen

Bis zum nächsten Kapitel

Es grüßen Sie herzlichst Ihre SOPHISTen