Sonntag, 7. Juli 2013

Kontextaspekt Stakeholder

These: Systemkontextanalyse öffnet die Augen für optimale Software

Artikelübersicht
1. Teil Kontextaspekt Stakeholder.
2. Teil Nutzerrollen, Personas und extreme Charaktere.
3. Teil Organisationsstrukturen.


Im Folgenden werde ich ein Modell und eine Schablone zur Erfassung von Stakeholdern entwickeln. Im Post Welche Arten von Kontextobjekten gibt es? ist der Begriff des Stakeholders bereits definiert worden. Man kann ihn im Deutschen auch Interessenhalter nennen, also eine Person, die ein direktes oder indirektes Interesse an dem betrachteten Projekt besitzt.



Chris Rupp sagt, die einfachste Art Stakeholder zu erfassen, sind Tabellen [S96, RUPP07]. Dort werden sämtliche wichtigen Attribute erfasst. Ich versuche, mich dem Stakeholder mit einem visuellen Modell zu nähern. Anhand der Anfangskontakte in einem Projekt und mit Hilfe von Checklisten möglicher Stakeholder werden die ersten konkreten Personen gefunden. Rupp beschreibt eine Menge von Stakeholderrollen, die es zu bedenken gilt. [S93, RUPP07] Diese sind auch auf über die Homepage www.sophist.de zu finden.

Am Anfang erzeugt man eine Person über das folgende Symbol. Im Körper befindet sich das Aktionsfeld mit dem ersten Aktionsbutton. In diesem Fall ist es ein Briefumschlag. Dieser soll den Zugang zu den Grunddaten der Person symbolisieren. (Name, Adressen, Telefon, Email, etc.)


Eine große Menge erfasster Stakeholder muss nach verschiedenen Kategorien klassifiziert werden. Dadurch wird es möglich, sie entsprechend ihrer Wichtigkeit für verschiedene Ziele zu betrachteten. Eine sehr wichtige Kategorie ist dabei der (direkte oder indirekte) Bezug zum Projekt.

Eine Person, die sehr von dem Projekt betroffen ist, wird größer dargestellt, als eine Person, die nicht so stark vom Projekt betroffen ist. Empfehlenswert ist es dabei, drei Betroffenheitsgrade zu wählen: stark, mittel, schwach.


Weitere Informationen, die Aussagen über die Projektbetroffenheit darstellen, werden hinter einem neuen Aktionsbutton abgelegt, der durch ein großes P ( für Projekt) gekennzeichnet ist. Rupp schlägt folgende Informationen vor : Rolle des Stakeholders, Beschreibung, konkrete Vertreter, Verfügbarkeit, Wissensgebiete, Begründung [S.96, RUPP07]. [VIG11] schlägt außerdem eine Klassifizierung in Anforderungsverantwortliche, Fachexperten und Systembetroffene vor [S17-18, VIG11]. Diese Klassifizierung wird ebenfalls hinter dem Aktionsbutton für die Projektbetroffenheit durchgeführt.

[VIG11] führt außerdem eine Kategorisierung nach der Akzeptanz dem Projekt gegenüber durch. Dadurch werden die politischen Projektverhältnisse besser sichtbar. In meinem Modell stelle ich diese Akzeptanzgruppen durch verschiedene Farben dar. Rot sind die Gegner des Projektes, Grau die Unentschlossenen, Blau die Unterstützer und Grün die Promotoren. Interessen und Ziele, politische Standpunkte sowie persönliche Kernanforderungen an das Projekt werden ebenfalls hinter dem Aktionsbutton Projekt abgelegt.


Außerdem können nun verschiedene Beziehungen zwischen den Stakeholder gezeichnet werden. [VIG11] erwähnt die folgenden Typen:

Die Stakeholder haben freundschaftliche Beziehungen zueinander. Zur besseren Sichtbarkeit ist der Beziehungspfeil grün.
Die Stakeholder sind verfeindet. Zur besseren Sichtbarkeit ist der Beziehungspfeil rot.
Die Stakeholder stehen loyal zueinander.


Das Modell ist für weitere Kategorien offen. Im Aktionsfeld können weitere Aktionsbuttons eingefügt werden. Vorstellbar ist zum Beispiel ein Aktionsbutton für Kontakte. Dahinter könnten sich Termine, Gesprächsprotokolle und Interviews verbergen. Auch die Beziehungspfeile sind erweiterbar. Mit Hilfe dieser Symbole kann man sich schnell eine einfache Übersicht über die politischen Verhältnisse innerhalb einer Stakeholder-Map verschaffen.

Zur besseren Darstellung und weiteren Kategorisierung können Personen zu Gruppen zusammengefasst werden. Beziehungen, die von Personen in der Gruppe zu Personen außerhalb der Gruppe laufen, enden am Gruppensymbol. Beziehungen zwischen Personen innerhalb der Gruppe werden nicht dargestellt. Mit Hilfe dieses Symbols kann man Hierarchien in das Modell einbauen und somit verschieden differenzierte Betrachtungsebenen. Die Aktionsbuttons im Aktionsfeld der Gruppe bieten Zugang zu Listendarstellungen der entsprechenden Informationen.


  • [RUPP07] Chris Rupp & SOPHISTen: „Requirements Engineering und – Management“, 4. aktualisierte und erweiterte Auflage, Carl Hanser Verlag, München, Wien, 2007
  • [VIG11] Uwe Vigenschow, Björn Schneider, Ines Meyrose: „Soft Skills für Softwareentwickler“, 2. überarbeitete und erweiterte Auflage, dpunkt.verlag GmbH, Heidelberg, 2010


folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Kommentare:

  1. Interesting Visualisation! Wir haben unsere eigene Methode zur Stakeholder Analyse und wollen diese bald auf unserer Lern Platform digital zugänglich machen. Vielleicht interessant in Kooperation mit diesem Visualisierungsmodel?

    http://stakeholderdialogues.net/learning/toolbox/

    Jade Buddenberg

    AntwortenLöschen
  2. Vielen lieben Dank! Finde Eure Ideen toll. Eine Zusammenarbeit wäre bestimmt eine schöne Sache. Bin auf Xing und Twitter zu finden.

    AntwortenLöschen
  3. Hi.
    Ich mag Visualisierungen und finde es einen praktikablen Ansatz, der hier skizziert ist.
    Persönlich würde ich aber die folgende Aussage schärfen:
    "... Stakeholder ... eine Person, die ein direktes oder indirektes Interesse an dem betrachteten Projekt besitzt..."

    Ich denke, es geht hier verstärkt um den Einfluss, den ein Stakeholder auf die Anforderungen hat.
    Eine Person kann durchaus auch Interesse am Projekt haben, wenn sie aber keinen Einfluss auf die Anforderungen oder Abstimmungen derselben nehmen kann, würde ich diese eher "klein" zeichnen, aka als nicht-relevante Stakeholder aufnehmen.

    Vielleicht wäre ja "Einflussnehmer" eine Alternative zu "Interessehalter" ??

    AntwortenLöschen
  4. Hi.

    Ich bin nicht sicher, ob eine Visualisierung sehr viel weiter hilft.
    Grundsätzlich gibt eine Tabellenform i.d.R. etwas mehr her - und bietet mehr Übersicht.

    In der Archimate 2.0 Spezifikation der Open Group findet sich darüber hinaus ein sehr detailliertes Modellierungswerkzeug für Stakeholder:
    http://pubs.opengroup.org/architecture/archimate2-doc/chap10.html

    Es unterstützt die Modellierung von Treibern, Analysen, Zielen, Anforderungen und Beschränkungen für Stakeholder und Stakeholder Gruppen.
    Prinzipiell ein sehr ausgereiftes Model - aber wieder ist die grafische Darstellung bei mehr als 7-10 Objekten nicht mehr wirklich handlebar.

    Zumal man Stakeholderanalysen ohnehin niemals in schriftlicher Form ohne Kommentar herausgeben sollte. Sie sind hochpolitisch und bedürfen immer einer sachlichen Erläuterung. Sonst will man sich bald des Requirements Engineers entledigen ;-)

    AntwortenLöschen