Wie Nutzererwartungen in digitalen Projekten gemanagt werden können

    Wie können digitale Projektmanager die Nutzererwartungen innerhalb von Projekten in der Softwareentwicklung managen? Welche Strategien helfen im Rahmen von Projektverlauf und Budget, bei zeitgleichem Balanceakt von Nutzererfordernissen und -anforderungen unrealistische Erwartungen zu vermeiden?

    Abonnieren Sie unseren Blog

    Betrachten Sie zunächst die Implementierung einer neuen Technologie oder Plattform. Als Unternehmensberater entsteht nach einer abgeschlossenen Runde von Workshops oft die Erwartung, dass ein Elefant plötzlich rosafarben zu sein und außerdem fünfbeinig wie ein aufgescheuchtes Huhn herumzutanzen hat. Während die anfängliche Begeisterung in ungeahnte Höhen schnellt, stellen sich eben diese Erwartungen oft als unrealistisch heraus. Das Wahrgenommene wird zur Wirklichkeit – von der brandneuen Software wird erwartet, alle bestehende (Nutzer-)Probleme ausnahmslos zu lösen und das Leben dieser unglaublich einfach zu gestalten. 

    Ob von einer digitalen Plattform, Website- oder Content-Management die Rede ist – unbestreitbar bleibt dabei die Tatsache, dass eine wichtige Hürde bei der erfolgreichen Implementierung eines Projekts im Management der Nutzererwartungen liegt. Wenn ein Projekt mit großen Versprechen und/oder unfertig abgeliefert wird, steigt die Unzufriedenheit der Nutzer mit der daraus resultierenden Softwarelösung, was sogar dessen zukünftige Annahme aufs Spiel setzen kann. Es ist wahrlich keine leichte Aufgabe für digitale Projektmanager, die Erwartungen vom Ideenfindungsprozess bis hin zum Launch stetig auszubalancieren.   

    Folgend werden wir vier spezielle Strategien näher unter die Lupe nehmen, wodurch Projektmanager eben diesen Risiken entgegenwirken und das Management der Endnutzererwartungen zur vollen Zufriedenheit erfüllen können.

    1. Ziehen Sie die Nutzer über das gesamte Projekt hinweg mit ein

    Wann?
    Über alle Phasen des Projektes hinweg: die Problemdefinition (das „Warum”), die Geschäftsanalyse (das „Was“), die Anforderungsanalyse (das „Wie“), das Testen der Nutzerakzeptanz, die Vorbereitungen zum Launch und sogar nach dem Go-Live.

    Wie?

    • Hören Sie Ihren Nutzern zu: Sie kennen ihr eigenes Geschäft am besten und können Ihnen praktisch umsetzbare Erkenntnisse liefern, die Ihnen keine Geschäftsdokumentation bieten kann.
    • Zuweisen von Key-User: Eine Begrenzung der Zahl der beteiligten Nutzer ermöglicht dem Projekt eine schnelle Abwicklung, ein zügigeres Treffen von Entscheidungen sowie eine gesteigerte Produktivität innerhalb des Projekts.
    • Halten Sie nach “Botschaftern ” innerhalb der Nutzercommunity Ausschau: Diese können das Produkt jederzeit über Ihre Teams vorstellen/einführen und schnell allgemeine Frustration ausmachen – Sie fungieren als Ihre Ohren und Augen.
    • Arbeiten Sie mit den Benutzern zusammen, und nicht an ihnen: dies ist der einzige Weg, sie von Anfang an für sich zu gewinnen.

    Warum?
    Die Endnutzer Ihres Kunden sind auch Ihre eigenen Endkunden. Sie sollten es tunlichst vermeiden, ein Produkt zu erschaffen, womit keiner arbeiten möchte.

    2. Seien Sie ehrlich

    Wann?
    Auch wenn Sie “schlechte Nachrichten” überbringen müssen, sollten Sie dies lieber früh als spät tun. Es mag selbstverständlich klingen, aber bedenken Sie stets, klar zu kommunizieren und waghalsige Versprechungen zu vermeiden.

    Wie?
    Ein Gehör für die Nutzer zu haben bedeutet nicht notgedrungen, dass alles implementiert wird, wonach gefragt wird. Hier ist das Management von Erwartungen besonders wichtig: Versprechen Sie nichts, was Sie nicht abliefern können! Wenn Sie etwas nicht wissen, teilen Sie es mit, und kommen Sie darauf zurück, sobald Sie es tun. Wenn etwas innerhalb der Projektgrenzen nicht möglich sein sollte (z. B. technische Machbarkeit, Budget, Anpassungsoptionen), erklären sie weshalb und teilen auch Sie die logische Schlussfolgerung hinter der Antwort mit.

    Warum?
    Ebenso wie in unseren persönlichen Beziehungen schätzen es Kunden, wenn Unternehmen einer klare Linie folgen. Eine realistische Idee darüber zu haben, was sich gerade innerhalb eines Projekts abspielt, stellt den Schlüssel zu Ihren Teammitgliedern dar, da so ihre Erwartungen entsprechend gemanagt werden können. Außerdem unterstreicht das Anerkennen aller Bedenken oder Probleme abermals Ihre Einsatzbereitschaft für das Projekt und bietet Ihrem Kunden weitere Gründe, Ihrem Unternehmen zu vertrauen.

    3. Anforderungen sollten stets priorisiert werden

    Wann?
    Gängigerweise geschieht dies, bevor das Projekt die Entwicklungsphase erreicht. Die Problemdefinition samt ihrer wichtigsten Erfolgsfaktoren zusammen mit den geschäftlichen Anforderungen verdeutlicht Ihnen bereits, worauf Sie Ihre Prioritäten legen sollten. Sind diese ein Mal gesetzt bzw. abgesegnet worden, können diese auf detaillierter Ebene definiert werden (die Nutzeranforderungen).

    Wie?
    Es besteht eine Anzahl an Priorisierungstechniken für Softwareanforderungen. Darunter fallen die einfache Abstimmung, das MoSCoW-Verfahren, das Minimum Viable Product (MVP) im Vergleich zum Non-MVP-Verfahren, usw. Wählen Sie das Verfahren aus , das am besten zum Projekttyp passt. Während eines Priorisierungsverfahrens werden die gewichtigsten Gespräche zwischen Ihren geschäftlichen Stakeholdern geführt. So wird das Ergebnis bestimmen, was möglicherweise auf dem Spiel steht, falls sich die Umstände ändern sollten.

    Warum?
    So können alle Beteiligten nachvollziehen, worauf der Fokus liegt, falls sich einige Projektparameter verändern sollten (z. B. Budget, Ressourcen, Zeit oder andere). Von meiner Erfahrung als Beraterin können Sie mir glauben, wenn ich Ihnen sage, das dies so gut wie immer der Fall ist. Das Wichtigste ist, dass alle Mitglieder des Projektteams darüber im Bilde sind, worauf es wirklich ankommt, was den größten Nutzen mit sich bringt und was lediglich ein nettes Extra bietet (in einer ersten Phase). Und dass diesbezüglich ein Konsens erzielt werden sollte, um spätere Diskussionen zu vermeiden.

    4.  Stellen Sie sicher, dass die Vision des Projekts geteilt wird

    Wann?
    Was wäre, wenn Sie fünf Projektmitglieder oder Endnutzer fragen würden, warum das Projekt abgewickelt wird? Wie gestaltet sich das Hauptziel der Implementierung dieses Projekts? Sie können kaum von allen fünf dieselbe Antwort erwarten, da es sich in der Realität meist ganz anders abspielt. Jeder sollte sich der Problemdefinition von Anfang an bewusst sein, damit diese während des gesamten Projekts nicht missverstanden werden kann.

    Wie?
    Ein gemeinschaftliches Ziel dient Personen als Orientierungshilfe und gibt ihnen im Rahmen ihrer Arbeit einen Sinn für ihre alltäglichen Aufgaben. Mit anderen Worten: Menschen benötigen eine Vision sowie Führung. Dasselbe gilt auch für digitale Projekte. Die Benutzer wollen erfahren, warum genau sie ein neues Produkt kennenlernen oder das Fehlerhafte hervorheben sollen. Sie wollen erfahren, warum manche Features nicht bereitgestellt wurden. Wenn die Vision auf der Strecke bleibt, können Teammitglieder ihre Motivation verlieren oder Aktivitäten ausüben, die nicht mit den Hauptzielen des Projekts im Einklang stehen. So werden Zeit, Ressourcen und Geld an falscher Stelle ausgegeben.

    Warum?
    Je länger das Projekt braucht und je mehr Personen darin involviert sind, desto schwieriger kann sich das Erreichen des gemeinschaftlichen Ziels oder der „Vision“ herausstellen. Es stellt aber ebenso die richtige Zutat zum erfolgreichen Management von Nutzererwartungen bereit.

    Schlusswort

    Stehen Sie kurz davor, ein neues digitales Projekt ins Leben zu rufen? Oder fungieren Sie als Business- oder Funktionsanalyst in einem aktuellen Projekt? In diesem Fall kann eine Plausibilitätsprüfung niemals schaden. Sie werden sich womöglich fragen wollen: „Was, wenn ich eine Diskrepanz zwischen Projektergebnissen und den Erwartungen der Endbenutzer feststelle?“ Behalten Sie im Hinterkopf: seien sie von Anfang an ehrlich. Menschen lieben es zu sehen, dass ihr Feedback berücksichtigt wird. Und nun ist es Zeit, in Aktion zu treten!

    Veröffentlicht auf 10/01/19    Zuletzt aktualisiert am 11/01/19

    #Projektmanagement

    Über den Autor

    Katy Willems is Business Consultant at AMPLEXOR, based in Belgium. Specializing in Business Process Analysis, she focuses on capturing all the business and functional aspects of projects and translating them into solid technology solutions. Katy has over 5 years of project experience when it comes to delivering a solid business or functional analysis report.

    ABONNIEREN SIE UNSEREN BLOG

    Beteiligen Sie sich an dieser Diskussion