In diesem Artikel erfährst du, wie du durch die Beteiligung von Menschen die Resilienz im Unternehmen fördern kannst. Denn, nicht nur Projekte und Produkte sondern die ganze Organisation werden zum Erfolg gebracht, wenn ihr Menschen mit verschiedensten Expertisen daran beteiligt. Ich kenne es zur Genüge: da sitzen fähige Menschen zusammen und überlegen sich, wie ein Feature umgesetzt oder eine Veränderung gestaltet werden sollen. Wenn sie es dann vorstellen, wird oft klar, dass es an der Realität, der Machbarkeit oder der Brauchbarkeit vorbei ist. Obwohl die Idee super ist. Und es passiert dabei immer noch zu oft, dass die Stimme der Menschen, die diese Veränderung betrifft, vergessen oder bewusst überhört wird.
In meiner Zeit als Product Ownerin in der Software-Entwicklung verschiedenster Unternehmen habe ich folgendes feststellen dürfen: Gebe ich Menschen die Möglichkeit, sich an einem Thema aktiv zu beteiligen, weil ich ihren Wertbeitrag erkannt habe, blühen sie regelrecht auf. So ein schönes Gefühl, weil ich Menschen zum Einen involviere und so die Motivation eines jeden einzelnen stärke. Und zum Anderen, weil die Beteiligung von Menschen quasi eine Garantie dafür ist, dass am Ende etwas gutes entsteht. Ich konnte den Spirit erleben und spüren, der dadurch wächst. Wenn diese Art der Beteiligung nicht förderlich für die Resilienz im Unternehmen ist, weiß ich auch nicht weiter…
Zwei Beispiele möchte ich hier näher unter die Lupe nehmen:
Im Unternehmen A sollte ein internes System eingeführt werden.
Es handelt sich um ein Tool, um die Prüfung von Anträgen neuer Kund*innen durchzuführen und zu automatisieren. Hierbei ging viel Zeit für die manuelle Arbeit verloren. Zu Beginn saß ich als Product Ownerin mit meinem Entwicklungs-Team zusammen und wir besprachen, wie wir´s bauen werden. Was geschah, als wir die erste Version vorstellten? Die anwendenden Personen aus dem Customer Care beschwerten sich massiv über die für sie völlig unbrauchbare Struktur und Usability im Allgemeinen.
Hier entstand der Grundgedanke, den ich bis heute als eins meiner Herzensthemen betrachte: Beteiligt die Menschen, die die Veränderung tangiert an den Entscheidungen im Entwicklungsprozess und teilt eure Gedanken zu unumstößlichen Themen sofort mit.
Wir führten also einen Regeltermin ein, an dem zwei Menschen aus dem Customer Care (also die wesentlichen Nutzenden des Systems), jemand aus dem Entwicklungsteam und ich als Product Owner (ich zog die Fäden und Anforderungen im Anschluss mit dem Team glatt) teilnahmen. Wir deckten gemeinsam Fehler und Zeitfresser im Ablauf auf und entwickelten Ideen zur Behebung und Optimierung. In Stakeholder-Reviews gab es Schulungen für das gesamte Team von Customer Care, Fragen konnten geklärt und verfehlte Erwartungen besprochen und zeitnah korrigiert werden.
Im Unternehmen B ging es um ein vereinfachtes Login
Vorher gab es mehrere Plattformen, in welche sich ein und derselbe Mensch mit verschiedenen Usernamen und Passwörtern einloggen musste – dies sollte nun vereinfacht werden. Da ich ja aus der Vergangenheit bereits wusste, wie energetisierend die Zusammenarbeit wirken kann, führte ich das cross-funktionale Refinement ein. In diesem Termin, in dem die einzelnen Features (und es waren verdammt viele) besprochen und die Kriterien zur Umsetzung definiert wurden, saßen die jeweiligen Fachbereiche bzw. Menschen mit unterschiedlichen Sichtweisen auf das Thema zusammen. Hierzu gehörten Customer Care (als direktes Sprachrohr zur Kundschaft), IT (als technischer Sparring), Marketing (für die Kommunikation), QA (die kennen das System in und auswendig) und natürlich ich als Product Ownerin (Sprachrohr zwischen IT und Unternehmen). So konnten Fehlgedanken sofort aufgedeckt und Prozesse direkt korrigiert und mit den rechtlichen Bestimmungen übereinander gelegt werden. Auch während des Entwicklungsprozesses tauschten wir uns regelmäßig aus.
Das größt- und bestmögliche Feedback war nach dem Launch eine Nachricht aus dem Customer Care, die in etwa so lautete: Leute, wir haben kaum Support-Tickets bezüglich des neuen Login, während unser Backlog an Tickets zu allen anderen Themen stetig wächst. Unsere User scheinen alles zu verstehen, technische Fehler wurden im Vorhinein gefunden und wir wünschen uns derlei Zusammenarbeit auch in Zukunft und am besten mit allen Abteilungen und Entwicklungsteams.
Beteiligung von Menschen bringt Motivation und Zufriedenheit und stärkt ganz sicher die Resilienz von Unternehmen
Warum ist es nun sinnvoll, Menschen aus den verschiedenen Abteilungen in EINEM Termin zu versammeln bzw. im Projekt dauerhaft in einem Team zusammenzufassen?
1. Verantwortung durch gemeinsame Aufteilung der Rollen
Es gibt eine klare und im Team (bestenfalls im Unternehmen) kommunizierte UND akzeptierte Rollenverteilung (Information vs. Eskalationsstufe, Beratung vs. Entscheidungshoheit), siehe auch die RACI-Matrix weiter unten. So wissen alle Personen im Termin und Team, wie der Termin oder das Projekt ablaufen und wer welche Möglichkeiten der Intervention hat.
2. klares Verständnis durch frühe Information
Ihr schärft das Verständnis aller füreinander und die Hintergründe zu technischen Restriktionen sowie Abhängigkeiten. Ich kenne es zur nur zu gut, dass Dinge geplant und umgesetzt werden und am Ende meckern „alle“, weil es entweder gar nicht das ist, was erwartet wurde ODER es anders umgesetzt wurde, weil technische Limitierungen es so verlangten – ohne es zu kommunizieren.
3. Chance auf Erfolg durch Involvement
Ihr erhöht das Involvement, weil dadurch die Erfahrung aller Menschen zählt. Jeder weiß etwas und wir können so viel voneinander lernen, in dem wir zuhören und eine Idee nicht sofort wegwischen. Die besten Ideen sind entstanden, weil Menschen etwas anders machen und um die Ecke denken – nicht, weil sie tun, was sie schon immer tun. Durch Hinterfragen kommen wir oft unserem eigentlichen Bedürfnis auf die Schliche und können herausfinden, warum wir diese Idee gerade wirklich unpassend finden. Ist die Idee wirklich doof oder sind wir neidisch, dass wir sie nicht hatten. Oder fühlen wir uns unterlegen und „dumm“, weil jemand anderes die Idee hatte und wir es eigentlich von uns erwarten? Fühlen wir uns „schon wieder nicht gehört?“ Oder, oder…, die Gründe dafür sind mannigfaltig – schaut mal genau hin!
4. Fürsprechende finden und Vertrauen erhöhen
Durch die frühe Einbindung der betroffenen Personen werden Hindernisse und „Verweigerungsoptionen“ frühzeitig erkannt und Fürsprechende gefunden. Diese Personen sind Gold wert in jeder Hinsicht. Wir erkennen, an welchem Punkt wir möglicherweise Bedürfnisse von Beteiligten übergehen oder Konsequenzen übersehen. Und wir finden Menschen, die für uns die Aktion „bewerben“.
5. Wissensverteilung und Akzeptanz durch breite Streuung
Wer an diesen Terminen und Projekten beteiligt ist, hat einen Wissensvorsprung und kann diesen nutzen, um in der eigenen Abteilung und dem Unternehmen Innovationen zu fördern, aber auch dafür zu sorgen, dass das Wissen breit verteilt wird und nicht nur in der IT hängen bleibt. Das technische Verständnis wächst und somit das Vertrauen in die IT bzw. die Produktentwicklung.
Nun hast du schon ein paar Argumente dafür an die Hand bekommen, warum die Resilienz im Unternehmen gestärkt wird, wenn ihr die Beteiligung von Menschen fokussiert. Ich möchte dir ein kleines und feines Tool an die Hand geben, mit dem du die Beteiligung strukturieren kannst – es gibt dabei kaum etwas anstrengenderes, als wenn Verantwortlichkeiten nicht geklärt sind. Und das tust du mit dem RACI-Modell.
Dein Tool für eine bessere Struktur in der Beteiligung von Menschen
Es kann sein, dass du Menschen aus der Organisation im Entwicklungsprozess benötigst, die nicht zwingend fester Bestandteil des Teams sind. Auch ich habe nicht alle der o.g. Menschen in das Team integriert, sie jedoch fest in den Prozess verankert und ihre Verantwortlichkeit mit ihnen definiert.
Zur besseren Aufteilung der Verantwortlichkeiten bietet sich die RACI-Matrix an, welches du VOR Projektbeginn bzw. bei Gründung des Produktteams gemeinsam definierst. Mache dir im Vorhinein klar, welche Aufgaben es zu verteilen gibt und wofür du die RACI-Matrix aufstellen möchtest. „Mal probieren…“ gilt hier nicht, du möchtest schließlich im Unternehmen oder im Projekt die Resilienz durch die Beteiligung fördern und nicht einfach nur zusammensitzen. Zur besseren Greifbarkeit nutze ich ein reales Thema aus dem Unternehmen A.
Die Entwicklung des internen Systems mit der RACI-Matrix
Responsible / Richtige Ausführung
Wer trägt die Verantwortung für die Erledigung der Aufgabe(n)?
Diese Rolle wird derjenigen Person zugeteilt, die für die Ausführung einer Aufgabe verantwortlich ist. Also diejenigen Menschen, die am Ende eine Aufgabe erledigen, erfüllen und das Ergebnis präsentieren.
Tipp: Suche dir Menschen mit verschiedenen „Reifegraden“ dafür. So verteilst du Wissen und sorgst dafür, dass erfahrene Personen den anderen etwas beibringen, sodass diese dann bald größere oder schwierige Aufgaben übernehmen können.
Accountable / 1. Ansprechpartner*in
Wer ist verantwortlich für die Steuerung und Umsetzung der Aufgabe(n)?
Diese Rolle ist in meinen Augen die wichtigste im Projekt oder in der Produktentwicklung und in diesem Fall der Product Owner, es kann auch eine Führungsperson oder jemand aus Projektmanagement sein. Diese Rolle ist verantwortlich für:
- den Forstschritt des Projekts
- die Steuerung der zu erledigenden Aufgaben innerhalb des Oberthemas (meist „Projekt“)
- die Erreichung des Gesamtziels
- die Information der Beteiligten
Tipp: es kann nur EINE Person geben, die diese Rolle innehält. Alles andere ist zu viel Abstimmung und in der Regel schiebt eine Person die Verantwortung auf die andere. „Ich dachte du machst das.“ ist dann einer der häufigsten Sätze.
Consulted / Consultant (beratend) tätig
Wer übernimmt die Verantwortung für die „richtigen“ Informationen?
Bei der Verteilung dieser Rolle ist es wichtig, dass du dir die Frage stellst, wer ernsthaft etwas dazu beitragen kann. Auch wenn die Resilienz durch Beteiligung erhöht wird, kennst du den Spruch mit den Köchen und dem Brei…es geht also vielmehr darum, die richtigen Leute reinzuholen.
Tipp: Du kannst mit ein paar einfachen Fragen klären, wen du dazu holen solltest:
- Beziehst du diesen Menschen mit ein, weil dieser hierarchisch über dir steht? (Tu dir und allen anderen den Gefallen und mach es bitte nicht. Wenn dieser Mensch damit nicht einverstanden ist, ist das ein anderes zu lösendes Thema und kein Beitrag zum Projekt)
- Gibt es wirklich niemanden sonst, der oder die dir bessere Informationen liefern kann?
- Ist diese Person loyal dir und deinem Projekt gegenüber?
- Hat die Person genug Zeit, um in dem Zeitrahmen zu unterstützen, wie es nötig ist?
Informed / Informiert
Wer benötgt welche Informationen?
Hierbei geht es drum, zu definieren, wer im Rahmen der Aufgabe zu informieren ist. Wenn du meinen Beitrag zu den Meetingregeln gelesen hast, weißt du, wer zwingend erforderlich und wer optional ist. Natürlich soll die verantwortliche Person die Informationen verteilen, jedoch sind die Informationsempfangenden nicht an einer Entscheidungsfindung beteiligt. Achte darauf, dass du so wenig wie möglich Personen in den oberen Reihen stehen hast – es wird schnell unübersichtlich und du kommst nicht mehr hinterher mit Schlichten und sortieren sämtlicher Meinungen. Und ja, in der Regel sind es Meinungen, da fundierte Kenntnisse oder Zahlen und Fakten nur selten vorliegen.
Beispielhaft könnte die Matrix so ausschauen
Es sollte nicht zu kleinteilig werden. Auch wenn die Beteiligung von Menschen im Unternehmen nicht zuletzt die Resilienz eines Projektes erhöht, kann es schnell im Chaos enden. Der eigentliche Vorteil der Struktur in Unübersichtlichkeit kehrt sich dann um und niemand weiß mehr, wofür sie oder er nun zuständig ist.
| Aufgabe | Customer Care | Entwicklungs-Team | Legal | Product Owner |
|---|---|---|---|---|
| Planung | C (nutzen das System) | C (erkennen techn. Abhängigkeiten) | I (wissen, wann sie was zu tun haben) | R / A (kann R auch an jemanden übergeben) |
| interne Kommunikation & Schulung | I (untereinander) im Laufe des Projekts ändert es sich zu R (nachdem eine Person geschult wurde, teilt sie es den anderen mit) | C (gibt´s Besonderheiten, die zu beachten sind?) | I (wissen, ob die DSGVO betroffen ist) | R / A (wird A höchstwahrscheinlich im Laufe des Projekts an Customer Care abgeben) |
| Compliance Prüfung | I (erfahren mögliche Grenzen in der Umsetzung) | I (wissen, was zu beachten ist) | R (prüfen, ob DSGVO oder andere Richtlinien betroffen sind) | A (die Prüfung ist schlichtweg zu erledigen) |
| Programmierung | C (bei Fragen zur Nutzung können diese sofort beantwortet werden) | A (setzen das Ganze um) | I (erfahren den technischen Fortschritt und wissen, wann es live geht) | A (überwacht den Fortschritt) |
Zu guter Letzt…
Einen wichtigen Hinweis möchte ich dir noch mitgeben. Auch, wenn du Aktionen zur Verbesserung im Unternehmen sammelst, z.B. zur Gestaltung des Offices oder Versorgung des Außendienstes, definiert am besten Verantwortlichkeiten. Wer setzt was bis wann um? Wenn ihr diejenigen beteiligt, die es am Ende betrifft, dann sollten sie auch an der Umsetzung beteiligt sein. Die Aktion läuft sonst Gefahr, an euch hängen zu bleiben und Bittstellende und Problem-Orientierung anstatt Selbstverantwortung und Motivation zu fördern. Meckern ist einfach und kann jeder Mensch. Um Lösungen zu finden, braucht es die richtigen Fragen und das entsprechende Format. Wenn ihr wirkliche Veränderung wollt, in der Menschen sich aktiv daran beteiligen, beteiligt sie auch in der Umsetzung.
Dies ist der erste Teil der Serie zur Beteiligung in Unternehmen durch die Entwicklung von Produktteams mit der RACI-Matrix als Vorbereitung. Im nächsten Artikel dreht es sich dann um die Beteiligung am Prozess als solcher.
Brauchst du Inspiration für Beteiligung oder Resilienz im Unternehmen?
Ich freue mich, mit dir gemeinsam die Matrix aufzustellen und Möglichkeiten zu entwickeln, dein Projekt durch Beteiligung zum Erfolg zu führen.