Ziele, Informanten und Fesseln

„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

Konfliktmanagement – Vom Ursprung und Umgang mit Konflikten

Im Rahmen einer jeder Berufslaufbahn sowie auch im privaten Alltag sind Konflikte, also das Aufeinandertreffen zweier unterschiedlicher, sich widersprechender Auffassungen oder Interessen häufig nicht vermeidbar. Doch wie gelingt es Ihnen etwas Positives aus einem Konflikt zu ziehen und eine konstruktive Lösung zu finden? Wie entstehen Konflikte und wie gehen Sie mit Konflikten um? Antworten auf diese Fragen und noch weitaus mehr möchten wir Ihnen in dieser Blogserie rund um das Thema Konfliktmanagement vorstellen.

Weiterlesen

Requirements-Engineering kurz und knackig auf den Punkt gebracht

Wollten Sie schon immer mal das von den SOPHISTen gesammelte RE-Wissen von 556 Seiten kurz und knackig in geballter Form präsentiert bekommen?

Dann sind Sie mit dieser Blogserie an der richtigen Adresse, ganz egal wie jung/alt oder erfahren/unerfahren Sie derzeit auf dem Gebiet sind. Wir werden Ihnen ein Jahr lang in regelmäßigen Abständen von ca. 2 Wochen das Wissen aus unserem Buch „Requirements- Engineering und –Management – Aus der Praxis von klassisch bis agil“ kapitelweise und mundgerecht aufbereiten.

Cover RE-Buch 6. Auflage Weiterlesen

„Alles nix konkretes“ – Herausforderungen in Systems-Engineering Projekten – Lösungsorientierte Denkweise der Stakeholder

Es liegt in der Natur der Ingenieurswissenschaften in Lösungen statt in Problemen zu denken. Jemand hat ein Problem und konsultiert einen Ingenieur, damit dieser ihm eine Lösung liefert. Die Frage nach dem „Wie?“ ist wesentlich präsenter als die nach dem „Wozu?“. Dies könnte einer der Gründe sein, weswegen der gemeine Stakeholder dazu neigt lösungsorientiert zu arbeiten. Wichtig ist es jedoch, dass man zunächst das Problem versteht, abstrahiert und sich fragt:

 

– Wozu benötige ich etwas?

– Welchen Mehrwehrt habe ich davon?

Weiterlesen