Verantwortlichkeiten des Stakeholder-Managements besprechen

Abgeschlossen

Es ist für Functional Consultants üblich, mit Stakeholdern zu interagieren, obwohl jedes Projekt anders ist. In der Regel geschieht dies gemeinsam mit anderen Teammitgliedern wie Projektmanagern und Lösungsarchitekten. Diese Kommunikation mit den Stakeholdern findet in Meetings, E-Mails, Workshops und Dokumentationen statt. Die Teamleitung sollte jedes Teammitglied darüber informieren, welche Arten von Stakeholder-Kommunikation für die Projektrolle erwartet werden.

Workshops durchführen

Workshops können starten, bevor die eigentliche Projektarbeit beginnt. Das Sammeln von Anforderungen, das Bestätigen von Anforderungen und das Sammeln weiterer Anforderungen können innerhalb eines Kundenworkshops durchgeführt werden.

Arbeiten Sie mit dem Entwicklerteam zusammen, um sicherzustellen, dass die Anforderungen verstanden und ausgeführt werden. Identifizieren und sammeln Sie Informationen von Ihren Experten, holen Sie ihren Input zu den Bereichen des Systems ein, die Sie den Endbenutzern hervorheben sollten, um ihre Begeisterung zu wecken. Ermutigen Sie das Management, den Benutzern Anreize für die Systemakzeptanz zu bieten, z. B. durch einen Wettbewerb, verfolgte Geschäftsziele usw. Finden Sie messbare Möglichkeiten, das Engagement und die Akzeptanz der Benutzer zu verfolgen, um sowohl das System zu präsentieren als auch potenzielle Bereiche für Verbesserungen in einer späteren Phase zu ermitteln.

In Workshops bereiten wir unsere Stakeholder auch auf die Übernahme des Systems vor, das wir für sie entwickelt haben. Manchmal erfolgt dieser Wissenstransfer vom Entwickler zum Maintainer. Es könnte sich auch um das Onboarding neuer Benutzer handeln. Nicht jedes Projekt hat eine eigene Ressource für die Planung dieser Workshops. Als Verbinder zwischen Technologie und Geschäft ist der Functional Consultant auf diese Rolle bestens vorbereitet.

Der Functional Consultant unterstützt häufig bei der Bereitstellung von Schulungen für Endbenutzer. Der Grund dafür ist seine einzigartige Position, durch die er sowohl Technologie als auch das Geschäft versteht und diese Kluft mit den Benutzern überbrückt.

Lösungsüberprüfung erstellen und bereitstellen

Eine Lösungsüberprüfung ermöglicht es, den Fortschritt der Beteiligten in Richtung eines Ziels aufzuzeigen. Abhängig von der genauen Bereitstellungsmethode werden Sie wahrscheinlich inkrementelle Überprüfungen des Fortschritts durchführen. Eine Lösungsüberprüfung könnte auch beinhalten, den Teammitgliedern einen Machbarkeitsnachweis vorzulegen, um ihren Input und ihre Unterstützung zu erhalten.

Der Lösungsarchitekt wird dabei wahrscheinlich die Leitung übernehmen, aber die Feinheiten einer Lösungsüberprüfung liegen oft beim Functional Consultant. Suchen Sie bei der Planung einer Lösungsüberprüfung nach Möglichkeiten, nicht nur Zustimmung, sondern auch echtes Feedback zu erhalten. In dieser Zeit sollten kleinere Kurskorrekturen eingeplant werden, wenn eine Funktion nicht wie geplant erschienen ist oder vielleicht nicht so reibungslos funktioniert wie im Entwurf. Haben Sie kein schlechtes Gefühl, wenn in diesem Überprüfungszyklus nötige Kurskorrekturen festgestellt werden. Aus genau diesem Grund gibt es Überprüfungen. Das Wichtigste ist, wie wir mit dem Feedback umgehen.

Demos und Machbarkeitsnachweis (Proofs of Concept, POCs) erstellen

Wenn Sie damit beginnen, sich die Lösung vorzustellen, ist es vielleicht ein guter Zeitpunkt, eine Demo zu präsentieren, um die Anforderungen mit Ihren Stakeholdern zu validieren und das Vertrauen in die Plattform zu stärken. Wenn ein Kunde Vertrauen in die Plattform hat, ist er eher bereit, Ihre Lösungsvorschläge mit Begeisterung anzunehmen. Wenn Sie einen iterativen Lösungsansatz verwenden, könnten Sie dafür mehrere kleine Machbarkeitsnachweise erstellen. Microsoft Power Platform macht die Erstellung eines Machbarkeitsnachweises einfach.

Demos können – je nach vorgeschlagener Lösung – unterschiedliche Formen und Ausprägungen annehmen. Die folgenden Ansätze sind einige der häufigsten:

  • Sofort einsatzbereit – Eine sofort einsatzbereite Demo zeigt einfach eine oder mehrere der Apps ohne Anpassungen. Diese Demo wird häufig von Ressourcen für die Vorverkaufsphase durchgeführt und bezieht den Lösungsarchitekten nicht mit ein. Es handelt sich bei dieser Demo auch um eine effektive Methode, um Kunden über die wichtigsten Produktfunktionen auf den neuesten Stand zu bringen. Der Nachteil dieses Ansatzes ist, dass er dem Kunden nicht dabei hilft, sich seine Lösung in der App vorzustellen. Sie können die negativen Seiten dieses Ansatzes abschwächen, indem Sie relevante Beispieldaten ihres Geschäfts aufnehmen.
  • Vorgefertigte Demo – Viele Partner spezialisieren sich auf bestimmte Branchen oder Lösungsbereiche und investieren in die Entwicklung von vorgefertigten Demos, die ihr eigenes geistiges Eigentum enthalten und die standardmäßige Basislösung mit dem von ihnen entworfenen Zusatznutzen versehen. Dieser Ansatz hilft dem Kunden, den jeweiligen Problembereich zu erkennen, da in diesem häufig die vertikale Sprache in der App verwendet wird. Oft verbirgt dies Dinge, die für den Lösungsbereich nicht geeignet sind und den Kunden ablenken könnten.
  • Prototyp – Dieser Ansatz geht vom Standardzustand aus und führt eine minimale Anpassung der App an die Kundenbedürfnisse durch, um diese angemessen zu berücksichtigen. Der Hauptvorteil hier ist es, dass eine Geschichte während der Demo erzählt werden kann, auf die sich der Kunde beziehen kann, wenn er versucht, seine speziellen Ziele zu erreichen.
  • Machbarkeitsnachweis – Machbarkeitsnachweise sollten erstellt werden, um zu beweisen, dass ein Konzept funktioniert und in der Regel eine bestimmte Komponente oder Aktivität in der vorgeschlagenen Lösung beinhaltet. Im Gegensatz zu einem Prototyp, der in der Regel einen unkomplizierten Weg bis zur Fertigstellung hat, können mit Machbarkeitsnachweisen mehrere Ansätze ausprobiert werden, um das gewünschte Ziel zu erreichen.

Es ist üblich, „Prototyp“ und „Machbarkeitsnachweis“ austauschbar zu verwenden. Aus Kundensicht spielt der Unterschied in der Regel keine Rolle. Ihr Ziel sollte es dabei sein, eine Geschichte zu erzählen und Ihre vorgeschlagene Lösung zum Leben zu erwecken, damit der Kunde erkennt, dass sein Problem durch die vorgeschlagene Lösung gelöst wird. Sie sollten auch versuchen, das Risiko zu verringern, indem Sie unbekannte Faktoren eliminieren.

Behalten oder entfernen

Wenn Sie einen Prototyp oder einen Machbarkeitsnachweis erstellen, sollten Sie wissen, dass schnelle Erfolge möglicherweise nicht gleichzeitig eine Best Practice für produktionsbereite Lösungen darstellen. Dies bedeutet nicht, dass Best Practices schwer zu befolgen sind, aber für eine schnelle Präsentation einer Idee ist es wahrscheinlich eher nötig, eine schnelle Idee zu entwickeln, als eine umfassendere Lösung zu planen. Sie sollten sich im Voraus entscheiden, denn wenn Sie die Anlagen übernehmen möchten, müssen Sie sicherstellen, dass sie Ihren Standards entsprechen und keine Abstriche gemacht werden, die nicht leicht behoben werden können.

Erwartungen verwalten

Da es einfach ist, schnell eine Demo zusammenzustellen, um Ihre vorgeschlagene Lösung zu präsentieren, ist es wichtig, die Erwartungen zu verwalten. Es kommt nicht selten vor, dass eine Demo präsentiert wird und der Kunde sagt „Super! Wann können wir live gehen?“ Der beste Weg für die Verwaltung besteht darin, direkt zu sagen, dass das Gezeigte zwar vollständig wirkt, aber nicht über die Sicherheit, Automatisierung und andere Verbesserungen verfügt, die für die Implementierung erforderlich sind. Der wichtige Punkt ist, dieses Gespräch zu führen und nicht davon auszugehen, dass der Kunde weiß, dass eine Demo nur eine Demo ist.