Der Stakeholder -Schlüsselfaktor für einen erfolgreichen Office 365 Einsatz

Viele Softwareprojekte wären wohl wesentlich erfolgreicher, hätten nicht so viele Menschen ihre Finger im Spiel. Aber es ist nunmal so, dass Software den Menschen unterstützen soll. Und der weiß meisten nicht so wirklich, was er eigentlich möchte. Da wird ungemein viel in die Erwartungen an die Software von den Anwendern rein impliziert, die Anwender sind sich untereinander selten einig wie das Ergebnis auszuschauen hat und geraten in einen Konflikt nach dem anderen. Mit dieser Situation professionell umgehen zu können ist Schlüsselfaktor für den Erfolg eines Softwareprojekts.

Der Stakeholder

Jemand, der bestimmte Erwartungen an ein Softwareprojekt stellt, ist ein sogenannter Stakeholder. Dabei unterscheiden sich die Definitionen von Stakeholdern in der Literatur durchaus. Zum Beispiel definiert Tom DeMarco in seinem Buch „Der Termin“ die Erwartungen eines Stakeholders als „magisches Dreieck“ zwischen Zeit, Kosten und Inhalt und Umfang. Diese Sichtweise ist die eines Projektmanagers. Im Requirements Engineering haben Christ Rupp und die Sophisten in ihrem Buch „Requirements- Engnineering und -Management“ folgende Definition:

Ein Stakeholder eines Systems ist eine Person oder eine Organisation, welche (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat.

Ein Stakeholder hat also ein bekundetes Interesse am System. Und er hat verschiedene Eigenschaften, die man kennen muss. Neben den Kontaktdaten gibt es noch einige weitere Eigenschaften, doch die folgenden drei sind meiner Auffassung nach die wichtigsten:

  • Funktion. An der Funktion kann man erkennen, welche Rollen und Zielgruppen der Stakeholder vertreten kann.
  • Relevanz. Ist der Stakeholder ein Entscheider oder Influencer? Diese Eigenschaft zu kennen ist wichtig, um die richtigen Stakeholder für das Projekt zu ermitteln.
  • Zeitliche Verfügbarkeit. Diese Eigenschaft ist in der Regel diejenige, die am ehesten unbeachtet bleibt.

Oftmals werden Stakeholder anhand ihrer Funktion und Relevanz ausgewählt, ungeachtet ihrer zeitlichen Verfügbarkeit- Hauptsache, man vergisst niemand „Wichtigen“.  Das kann schnell zu einem großen Fehler für das Projekt werden, denn nur Stakeholder mit der notwendigen Zeit bringen das Projekt weiter.

Ich versuche immer und soweit es mir möglich ist, zu Beginn eines Projektes eine Liste zu erstellen, in der ich zusammen mit der Projektleitung genau diese Eigenschaften festhalte und versuche die Liste solange zu erweitern, bis sie ausgewogen ist.

Office 365 und das Problem mit der Plattform

Nun handelt es sich bei Office 365 um eine Plattform und nicht um ein System für eine geschlossene Zielgruppe. Potenziell wird somit jeder Mitarbeiter im Unternehmen zum Stakeholder- eine Herausforderung, die sich bei jeder Plattform stellt. Daher empfiehlt es sich in einem ersten Schritt, Pilotgruppen für jede relevante Zielgruppe auszuwählen und somit die Liste der Stakeholder in einem verwaltbaren Ausmaß zu halten. Aber woran erkennt man eine wichtige Zielgruppe. Auch hierfür empfiehlt es sich, eine Liste zu erstellen und jeder potenziellen Zielgruppe verschiedene Eigenschaften zu verpassen. In einem Workshop mit der Projektleitung sollten für möglichst viele Organisationseinheiten eine Umfrage ausgefüllt werden, die verschiedene Eigenschaften gewichtet. Fragen können sein:

  • Wie hoch ist die Mobilität bei der Arbeit?
  • Wieviel Projektarbeit erfolgt im Arbeitsalltag?
  • Wie stark sind die Arbeitsschritte genormt?
  • Wie hoch ist der Kommunikationsaufwand im Arbeitsalltag?

Ergänzt um Beschreibungen von üblichen Arbeitsprozessen erhält man auf diese Weise verschiedene Profile für Zielgruppen im Unternehmen, die man auf mehrere Organisationseinheiten anwenden kann. Für jede Zielgruppe sucht man sich eine Pilotgruppe, mit der man den Einsatz der Office 365 Plattform konzeptioniert.

Office 365 und das Problem mit den unbekannten Anforderungen

Mit der Definition von Zielgruppen ist die Arbeit aber noch nicht getan, sondern fängt eigentlich gerade erst an. Denn nun geht es darum in Erfahrung zu bringen, wie man eine Office 365 Plattform für die jeweilige Zielgruppe optimal einrichtet. Ein Herr Kano von der Universität zu Tokio hat ein Modell entwickelt, mit dessen Hilfe man mit neuen Systemen sogar glückliche Gesichter erzeugen kann. Im sogenannten KANO- Modell werden Anforderungen und Eigenschaften eines Pordukts oder Systems anhand verschiedener Maßnahmen kategoriesiert.

  • Basis- Merkmale sind solche Anforderungen, die ein Stakeholder als minimale Anforderungen an ein System stellt. Wenn man diese Anforderungen abdeckt, funktioniert das System zwar, aber wirklich besser ist es nicht.
  • Leistungs- Merkmale machen das System dann schon deutlich besser, darüber freut sich der Stakeholder, Leistungs- Merkmale steigern die Akzeptanz einer Plattform.
  • Begeisterungs- Merkmale sind der Knaller für den Stakeholder. Dabei handelt es sich um wirklich tolle Features, mit denen der Stakeholder selbst gar nicht gerechnet hat.

Gemeinsam haben die Leistungs- und Begeisterungs- Merkmale, dass ein Stakeholder diese bei einer Befragung oft nicht formuliert. Spätestens bei den begeisterungs- Merkmalen weiß er ja selbst noch garnicht, dass er es so haben möchte. Es gibt also Anforderungen, die selbst dem Stakeholder unbekannt sind. Basis- Merkmale hingegen wird der Stakeholder nennen, nur machen die alleine das System nicht toll.

Natürlich gibt es verschiedene Methoden, um an die gewünschten Informationen zu gelangen. Diese Methoden eignen sich mal mehr und mal weniger gut, um Leistungs- und Begeisterungs- Merkmale zu erarbeiten. Allgemein eignen sich alle Kreativitätsmethoden wie Brainstorming oder die 6-3-5 Methode sehr gut, um den geheimen Wünschen der Stakeholder auf die Schliche zu kommen. Ganz im Gegensatz zu Interviews oder Fragebögen, bei denen es sich um normale Befragungsmethoden handelt. Leider haben Kreativitätsmtheoden ein Merkmal gemeinsam, wegen dem man im Requirements Engineering in bestimmten Situationen dann doch normale Befragensmethoden empfiehlt – die Stakeholder brauchen dafür Zeit. Daher ist es unbedingt notwendig, dass alle Stakeholder vor allen anderen Merkmalen insbesondere eine gute zeitliche Verfügbarkeit für das Projekt haben.

Office 365 und das Problem mit den unbekannten Funktionen

Hat man nun Anforderungen seiner Zielgruppen durch Kreativitätsmethoden sammeln können, gilt es diese nach Office 365 zu übertragen. Die Stakeholder kennen die Plattform nicht und interessieren sich in der Regel auch nicht für einzelne Funktionalitäten von Office 365. Daher wird es selten eine Anforderung geben, die sich genau mit einer Funktion von Office 365 beantworten lässt. Daher ist es eine wichtige Aufgabe im Projekt, Anwendungsfälle, sogenannte Use Cases, zu definieren. Ein Use Case beschreibt dabei, welche Office 365 Funktionen im Zusammenspiel gewisse Anforderungen einer Zielgruppe abdecken. Dabei liegt der Schwerpunkt auf der Bescheibung vollständiger Arbeits- Schritte und -Prozesse und nicht auf der Beschreibung einzelner Funktionen von Office 365. Funktionalen Balast, den die Stakeholder nicht brauchen, lässt man dabei einfach weg. Wenn keine Nebenversionierung gefordert ist, schaltet man Sie halt nicht ein, auch wenn das System es leisten könnte.

Fazit

Um mit dem Schlüsselfaktor „Stakeholder“ bei der Einführung von Office 365 Plattformen richtig umzugehen, benötigt es nur weniger Schritte.

  1. Zielgruppen definieren und Pilotgruppen zusammenstellen.
  2. Zeitliche Verfügbarkeit für Kreativitätsmethoden sicherstellen.
  3. Use Cases ableiten.
  4. Use Cases mit den Pilotgruppen testen.

Insbesondere zeitlich verfügbare Stakeholder sind wichtig, um optimale Use Cases zu ermitteln, die Office 365 zu einer gelungenen Plattform für das gesamte Unternehmen machen.

 

 

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s