Projektmanagement für UX-Experten

Ausgangslage

UX-Experten kommen grundsätzlich aus 3 Fachrichtungen: Psychologie, Design und Informatik. Ganz flach formuliert heisst das (ohne Beschränkung der Allgemeinheit), die ersten verstehen die Nutzer, die zweiten verstehen, wie diese zu überzeugen sind und die dritten, wie das Ganze umzusetzen ist. Jeder von uns vereint unterschiedliche Ausprägungen davon in seiner individuellen Expertise und seiner Überzeugung, wie Themen und Aufgaben erarbeitet und bewältigt werden.

Meine letzten Gespräche an UX Meetups und am Last Thursday Talk im Januar haben mich motiviert, das Thema Projektmanagement einmal zu behandeln. Nicht alle Researcher und Research-Interessierte haben augenscheinlich das gleiche Interesse und den gleichen Zugang zu systematischer Planung von Vorgehen. Sowie der praktischen Verankerung der eigenen Aufgaben in einen übergeordneten Projektplan – ob das ein Wasserfall-Projektplan ist oder ein agiles Vorgehensmodell. Vom Management des UX-Projekts ist noch oft die Sprache, aber UX-Aktivitäten sind Teil eines grösseren Ganzen. Wir tragen bei zur Entwicklung von Produkten und sind Teil einer übergeordneten Vorgehensweise.

In diesem kleinen Abriss versuche ich zu skizzieren, was im jeweiligen Thema ein Produkt- oder Projektmanager häufig tut und was der Beitrag der UX-Experten sein sollte oder sein kann. Dabei schaue ich auf die folgenden Eckpfeiler:

• Finanzen, Budget und Controlling
• Zeitplan
• Rollen und Ressourceneinsatz
• Qualitätsmanagement
• Kundenmanagement
• Risikomanagement

Finanzen, Budget und Controlling

Jedes Projekt oder Vorhaben ist auf eine bestimmte Zeit mit einem bestimmten Budget ausgestattet. Dabei ist es durchaus normal zwischen Personal- und Sachmittelbudget zu unterscheiden. Bei den Personalkosten gibt es zudem interne und externe Kosten. Beide Töpfe können unterschiedlich stark belastet sein. In der Regel ist es weniger «schlimm», wenn interne Personalkosten überschritten werden als wenn es externe Personalkosten sind, also die Ausgaben für externe Mitarbeiter, die einen direkten Geldabfluss für das Unternehmen bedeuten (Cash-out). Sind aber Stellenprozente und interne Planstellen nicht mehr verfügbar, kann es durchaus sein, dass es leichter ist, Externenbudgets anzuzapfen.

Was soll jetzt ein UX-Experte mit dem Wissen? Wenn UX-Experten nicht zum Stammbesatz des Projekts oder des Produktteams gehören – also ab der Erstplanung, gibt es regelmässig Auseinandersetzungen darüber, wie lange denn UX-Arbeiten dauern und ob das so sein muss. Das passiert auch, wenn die UX-Experten intern in das Team geholt werden. Bisweilen ist dann das Zahlen eines internen Stundensatzes notwendig, womit das Gesamtbudget gegebenenfalls überschritten wird oder gefährdet wird.

Deshalb finde ich es notwendig, dass zu Beginn der gemeinsamen Arbeit geklärt wird, mit wie viel Aufwand man für was rechnet, wann die Aufwände anfallen und vielleicht sogar, unter welchen Umständen diese Einschätzung gefährdet ist. Ein regelmässiges Monitoring, ob man sich noch im vereinbarten Rahmen befindet und warum vielleicht nicht, ist sehr wertvoll auch für den Projektleiter oder Scrum Master, um ggf. zusätzliches Budget zu beantragen oder Aufwandstreiber abzustellen. Aufwandstreiber können stark fordernde, aber nicht wichtige Stakeholder sein oder derartiges.

Zeitplan

Beim Zeitplan ist das oberste Gebot Mitdenken. Priorität zwei sollte für den UX-Experten direkt Mithelfen sein. Der Zeitplan des Vorhabens enthält in der Regel Meilensteine und wichtige Gremientermine oder Grossraumplanungen (Big Room Plannings) und Systemdemos. Es lassen sich aber auch andere Eckdaten finden oder sollten zumindest darauf erkenntlich sein: Termine mit wichtigen Stakeholders oder vorbereitende Deadlines, dass das Team sich noch abstimmen kann beispielsweise. Wenn UX-Experten sich nicht bewusst sind, welche Termine «hart» sind und welche tatsächlich ein bisschen flexibler, wird es schwierig, Teil des Ganzen zu sein.

Insbesondere geplante Nutzerinterventionen, also beispielsweise Interviews oder Nutzertests und wann deren Ergebnisse zu erwarten sind, sind mit dem Gesamtzeitplan zu harmonisieren. So ist es sicher schlau, auch Research-Ergebnisse an Systemdemos zu zeigen oder Zwischenabstimmungen so zu legen, dass ein Nutzertest gerade ausgewertet ist, um im Projektteam die nächsten Schritte zu besprechen. Je nach Grösse des Vorhabens gibt es vielleicht auch Subteams, die auf ein und dieselben Nutzer «losgehen». Um so wichtiger, dass man sich hier ein bisschen abstimmt. Stellt euch vor, die Nutzer sind Mitarbeiter und werden im Stundentakt von unterschiedlichen Personen nach ihrem Nutzungsverhalten «untersucht»… Existiert so ein Gesamtplan nicht, sollten auch UX-Teammitglieder einen solchen einfordern.

In der Regel wird sich ein Projektleiter, Product Owner oder Product Manager dieser Aufgabe angenommen haben. In Unternehmen, die sich IT-Projekte noch nicht so gewöhnt sind und/oder keine spezialisierten Projektleiter eingesetzt werden, hilft es dem Gelingen des geplanten Produkts, wenn zumindest die eigenen Aktivitäten einmal auf einem Plan ersichtlich sind. Es ist als UX-ler also durchaus erlaubt, schnell in einem Tool der Wahl (meistens reicht das PowerPoint) die geplanten Nutzerinterventionen, Konzeptphasen etc. auf einem Zeitstrahl abzubilden. Und ja: agil heisst nicht planlos!

Rollen und Ressourceneinsatz

Kleine Abgrenzung zum Anfang: Für mich sind beide Wörter – sowohl «Rolle» als auch «Ressource» – schwierige Wörter, die solange ich zurückdenken kann, immer eng verzahnt mit Abgrenzung, Bremsen, Stillstand und sinnloses Ärgern zu tun hatten. Solange in Vorhaben noch über AKVs (Aufgaben, Kompetenzen, Verantwortungen) gesprochen wird, passiert inhaltlich nichts. Darüber hinaus ist das Wort «Ressource» in Zusammenhang mit Menschen für mich persönlich eine Herausforderung. Besonders strub wird das Ganze, wenn Projektleiter formulieren: «Ich besetze keine Menschen, nur Rollen.» Ich befürchte, die Kraft eines gut zusammenpassenden Teams wird da massiv unterschätzt. Aber gut mit diesem kleinen Einschub.

Den Ressourcenbedarf und die Besetzung im Team bestimmt nicht immer der Product Manager oder Projektleiter. Wenn also die Ressourcierung ausserhalb des Projekt- oder Produktrahmens passiert, ist die Teamzusammenstellung konsequent ein Fortschrittsrisiko. Vor Jahren hatte ich einen Projektleiter kennengelernt, der sich im Verlauf des Projekts rechtfertigte: «Ich bekomme Stifte und mit denen male ich dann. Wenn das Bild dann komische Farben hat, ist das nicht meine Verantwortung.» In seinem Fall stimmte das, aber er hat es trotzdem nicht auf sich sitzen lassen und Personen aus dem Team ersetzt, wenngleich das ein Kraftakt war.

Als UX-Experten werden wir oft an Projekte «angeflanscht» und noch längst nicht allerorts von Anfang an auf ein Projekt gesetzt. Und sehr wahrscheinlich sind wir Teil von mehr als einem Projekt. Um so klarer muss dem gesamten Team sein, wann mit uns zu rechnen ist und wann nicht. Gehen die Planwerte nicht auf, muss eskaliert werden. Das bedeutet nicht mehr und nicht weniger als dass jemand mit mehr Entscheidungskompetenz Aufmerksamkeit auf die Thematik legen muss. Also: keine Angst vor Eskalation. Die Rollenthematik ist insbesondere mit dem Projektleiter aber auch mit dem gesamten Team anzuschauen, vor allem wenn überlappende Rollen wie Business Analysten oder Requirements Engineers beteiligt sind.

Qualitätsmanagement

In den meisten Kontexten hatte Qualitätsmanagement meiner Erfahrung nach mit der Sicherstellung der Anschlussfähigkeit der Lieferobjekte zu tun. Hier helfen Fragen wie: Können die Entwickler die Informationen entnehmen, die sie brauchen? Haben sie den Zugang zur Designspezifikation? Können Business Analysten gegen die vorhandenen Edge Cases prüfen? Kann der PO mit dem Artefakt Stakeholdermanagement betreiben? Die Angemessenheit der Qualität gegenüber dem Verständnis des Entscheiders ist eine weitere Herausforderung.

Bisweilen schiessen wir über das Ziel hinaus, wenn eine administrative Applikation «eine Seele» erhält und diese zweifelsohne aufwändige Arbeit daran nicht geschätzt werden kann. Den umgekehrten Fall gibt es natürlich auch: Wenn die Hoffnungen des Projektteams an einem anderen Ort des Spektrums liegen. Dann wurde oft nicht user-centered Design sondern user-only Design angewendet. Qualitätsmanagement ist daher aus meiner Sicht auch Stakeholdermanagement und steht in direktem Zusammenhang mit Erwartungen im Team, in der Organisation und bei den Nutzern.

Kundenmanagement

Wer ist denn eigentlich der Kunde? Ob du so wie ich bei einem Dienstleister bist und UX-Arbeit im Auftrag leistest, intern einer zentralisierten UX-Organisation angehörst oder vollständig einem Produkt oder Projekt zugeordnet bist, beantworte dir immer diese Frage sehr genau. Denn der Kunde ist es, der über erfüllt/nicht erfüllt entscheidet. Und das ist nicht primär der Nutzer. In agilen Vorgehensmodellen wird einem die Analyse ein bisschen erleichtert: der PO steht stellvertretend für den Kunden, dahinter jedoch stehen bisweilen weitere wichtige Stakeholder. Deren Stimme von Zeit zu Zeit einmal direkt zu hören, hilft oft ungemein. Besonders wenn das Gefühl aufkommt, dass der PO alternierend seine Meinung ändert.

In klassischen Vorgehensmodellen, aber auch in agilen, wenn die Organisation selbst noch hierarchisch ist, eskalieren die meisten Projektmitarbeiter intuitiv über ihre Linie und nicht über die Projektorganisation. Dadurch können unbekannte Personen plötzlich sehr sichtbar im Projekt werden. Meiner Erfahrung nach bewegen sich besonders Fachexperten (so wie wir UXler) recht unbeholfen durch sowohl die Aufbauorganisation als auch die Ablauforganisation. Deshalb hier meine wichtigsten Aufgaben, die wir als Teammitarbeiter auch erledigen sollten oder es einfordern sollten:

Aufbauorganisation:

• Wem gehört das Produkt nach der Entwicklung?
• Wer stellt Ressourcen bereit?
• Wer zahlt das gesamte Vorhaben?
• Welche Helfer werden aus der Organisation benötigt (z.B. Content Manager oder Marke)?
• Wie werden diese Personen informiert und involviert?
• Welchen Auftrag hat die Aufbauorganisation? (Beisst sich das mit meiner Rolle oder mit Aufgaben der Ablauforganisation?)

Ablauforganisation:

• Wenn ich eine Dienstleistung/Zuarbeit einer anderen Einheit im Unternehmen benötige, wie muss ich vorgehen? Bisweilen muss ein Vorgesetzter mal in CC gesetzt werden oder ein zentraler Wissensträger muss seinen Segen geben, bevor die Arbeit durchgeführt wird.
• Wie organisieren wir uns im Team, wenn bestimmte Personen in den Ferien sind?
• Wie sieht das Vorgehen der Organisation aus (Vorgehen Aufbauorganisation vs. Ablauforganisation)? Welche Phasen gibt es? Wo befinden sich Nutzerinterventionen?
• Wo befinden sich Informationen zum Projekt und wie komme ich zu den Informationen (Projektablage). —> Wie trage ich dazu bei, nicht auf einer Insel zu arbeiten, auf die niemand zugreifen kann
• Wie bin ich erreichbar? —> Bei externen MA: interne vs. externe Mails
• Wann stehe ich als Person der Organisation zur Verfügung? (Nicht prozentual, sondern auf Wochentage bezogen)
• Welchen Auftrag hat die die Ablauforganisation, welchen Auftrag habe ich?
• Ist eine Vision vorhanden? Muss diese allenfalls geschärft werden?

Beziehungsebene

Schliesslich gibt es zu allem in diesem Kontext objektiv sichtbaren Zusammenhängen noch die Beziehungsebene unter den Stakeholders. Der kann nicht mit dem, wenn die in einem Raum sind, gibt es nur Chaos, der Chef übernimmt nach 15 Sekunden den Lead über dein Folienset… Alle solche Informationen mal auf eine visuelle Beziehungskarte gelegt, hilft vor allem in längeren Vorhaben oder bei Produktentwicklungen, die über mehrere Jahre gehen, Überblick über die Interessen und Befindlichkeiten zu bekommen. Es ist selten sehr angenehm für einen Stakeholder, mal schwarz auf weiss zu sehen, dass er eine gestörte Beziehung zu einem Peer hat (Peer = eine Person auf der gleichen hierarchischen Stufe unter demselben Vorgesetzten), deshalb ist so eine Kartierung oft besser kein offizielles Dokument. ?

Aber es hilft dabei zu wissen, wen man für welches Begehr anspricht, wer wahrscheinlich helfen wird und mit welcher Argumentation. Wenn wir Glück haben, erstellen Business Analysten solche Zeichnungen oder mindestens eine Stakeholder Map mit den Achsen Einfluss und Interesse und versehen kritische Stakeholder mit einer roten Fahne (für Achtung). Haben wir das Glück nicht, aber es gibt trotzdem Business Analysten, können wir danach fragen und eine Auslegeordnung der Stakeholder einfordern. Passiert dann nichts, können wir gleich mal die Eskalation ausprobieren.

Noch eine kleine Anmerkung zu Stakeholders allgemein: Über den Verlauf eines Projekts/Vorhabens/einer Produktentwicklung verändert sich das Gefüge. Es werden mehr, bestimmte verlassen den Mikrokosmos, Beziehungen verändern sich. Deshalb muss man ab und zu mal überlegen, ob das alles immer noch so ist. Besprecht euch bei heiklen Situationen, Meetings oder dergleichen unbedingt mit den Projektverantwortlichen und allfälligen Teammitgliedern, die die entsprechenden Stakeholder besser kennen.

Risikomanagement

Das Risikomanagement ist in grossen Organisationen Teil der Managementmodelle. Dabei liefern Projektleiter regelmässig, z.B. monatlich oder zu bestimmten Meilensteinen, einen Rapport in ein Managementsystem. Das hilft einem übergeordneten Gremium, die Aufmerksamkeit höherer Entscheider zu kanalisieren und zu fokussieren. Aus meiner Optik lässt so etwas nach innen ins Projekt Risikomanagement zum Feigenblatt werden. Man bedient sich aus den Standardrisiken und schätzt die Schwere und Eintrittswahrscheinlichkeit auf einer vereinheitlichten Skala ein, sendet es «nach oben» und hört nichts mehr.

Es ist jedoch wichtig, sich im Vorhaben seiner Risiken bewusst zu sein, um Massnahmen zu ergreifen. Das Projekt-/Produktrisiko, für das wir uns zuständig fühlen müssen, ist die Nutzerakzeptanz. Fragen wir uns also, was diese noch beeinflusst. Ja, UX- und UI-Gestaltung, gut, das war der No-Brainer. Aber was ist mit der Hardware, Auflösung, Lesbarkeit, Verständlichkeit der Texte, Training, Vorgesetzteneinfluss, ein beteiligter Prozess, und und und… das können alles – so nenne ich das gerne – Verhinderer der UX-Auslieferung sein. Um diese im Griff zu behalten, können wir so vorgehen:

1. der erste Schritt, die Einflüsse auf die Nutzerakzeptanz in unserem Vorhaben aufzulisten,
2. der zweite, sie nach Eintrittswahrscheinlichkeit und Schwere der Auswirkungen bei Eintritt einzuschätzen,
3. der dritte, Massnahmen festzulegen, um die Risiken klein zu halten oder zu reduzieren, verhindern kann man sie meist nicht.

Die Darstellung in einem x-y-Diagramm hat mir visuell meist nicht geholfen, deshalb setze ich gern das Sonnensystem als Visualisierungshilfe ein. Sie hat auf Projektverantwortliche eine deutlichere Wirkung.

Noch mal alles in ganz kurz

• Finanzen, Budget und Controlling: sei planbar und schätze deine eigenen Aufwände gut ab
• Zeitplan: du bist Teil eines grösseren Ganzen, gehe auf Meilensteine des Teams ein
• Rollen und Ressourceneinsatz: Sprich über die Teamzusammensetzung und deine Aufwände, beides können Fortschrittsrisiken sein, die ein Projektverantwortlicher ohne dich vielleicht übersieht
• Qualitätsmanagement: die Definition von Qualität deiner Arbeit ist vielschichtig, wer Fiat 500 kauft, kann nicht Ferrari bekommen, trotzdem muss der Karren fahren (also umsetzbar sein)
• Kundenmanagement: Aubau- und Ablauforganisation sollten dir klar sein oder du musst zumindest einen Ansprechpartner dafür haben
• Risikomanagement: Kümmere dich um die Nutzerakzeptanz als Wert und visualisiere die Risiken, dass das Thema Sichtbarkeit und damit Massnahmen im Vorhaben erfahren kann

Was macht ihr, um euren Projekten zu helfen, Fahrt aufzunehmen und dauerhaft zu funktionieren? Ich freue mich auf eure Inputs, scheut euch nicht, euch zu melden ?