Nach dem ersten positiven Auftaktgespräch beim Kunden kommt die Ernüchterung: Die technischen Fragen bleiben unbeantwortet, die Unsicherheit wächst. In Teil 2 unserer Blogserie „Anforderungsmanagement im Public-Sektor“ treffen sich Architekt Adam (ARCH) und Anforderungsmanager Manfred (AM) erneut – und sprechen über den Kern jeder guten Anforderungsanalyse:

Zweites Treffen: Zwischen Erwartung und Wirklichkeit

Ort des Geschehens: Wieder ein Treffen beim Sport – Gelegenheit für einen ehrlichen Rückblick auf das erste Kundengespräch.

AM: Und, wie ist es gelaufen?
ARCH: Ach ja, der Kick-Off war eigentlich ganz gut. Deine Tipps haben mir echt geholfen, vielen Dank noch mal dafür! … Allerdings hat es danach Probleme gegeben. Nachdem wir die von dir genannten Punkte geklärt hatten, bin ich dann eingestiegen und habe die Anwesenden gefragt, welche Datenbank sie brauchen. Das konnten sie nicht beantworten. Da war ich schon überrascht. Dann habe ich sie gefragt, wie die Software betrieben wird und wie ihre Mengengerüste sein werden. Konnten sie auch nicht beantworten. Sie haben auch gar nicht verstanden, warum ich die Fragen stelle, schließlich entscheiden das doch die Bieter. Wie kann man nur so engstirnig sein, dachte ich bei mir! Wenn sie entsprechende Informationen nicht ins Angebot packen, werden sie ggf. sehr unterschiedliche Angebote bekommen. Ggf. fliegt ein eigentlich guter Anbieter so raus, weil er falsche Annahmen getroffen hat.

AM: Ja, das erlebe ich immer wieder. Man muss halt verstehen, dass die Leute, mit denen wir reden, meist keine technische Expertise haben. Ihnen ist nicht klar, dass eine Zehnerpotenz im Mengengerüst oder ein paar Prozentpunkte in der Verfügbarkeit im Zweifel auch zu um Faktoren höheren Kosten führen können. Zwischen Sätzen wie „ich kann auf alle historischen Börsenkursänderungen zugreifen und bekomme den aktuellen Stand verlässlich innerhalb von Millisekunden“ und „ich zeige immer den letzten bekannten Stand des DAX auf dem Desktop an“ liegen ggf. Millionen von Euro.
Wie habt ihr das gelöst? Was habt ihr gemacht, als ihr das erkannt habt?
ARCH: Wir haben das Meeting erstmal beendet, weil wir schon über die Zeit waren. Gestern haben wir uns dann noch einmal intern beratschlagt. Meine Projektleiterin meint, wir müssen wohl weiter vorne anfangen. Da waren wir uns alle nach kurzer Diskussion einig. Wie würdest du vorgehen? Du sagst ja, du kennst das Problem?

AM: Ja klar. Zuerst ist es eine völlig normale Situation. Ich ertappe mich z. B. auch immer wieder dabei, dass ich denke, beim Kunden erwarten sie die eierlegende Wollmilchsau und alles in „schick“ und „aufwändig“. Andererseits hat man ja auch schon viel gemacht und gesehen und hat auch eine bekannte Standardlösung parat – die ist aber ggf. nicht das ist, was gewollt ist. Und so denken Ansprechpersonen in den Behörden in der Regel meist auch nicht. Die kommen meist erst einmal mit ihrem spezifischen Problem und haben eine optimale Lösung im Kopf, die dann auch noch bezahlbar sein soll.

Die Frage hinter der Frage: Perspektivwechsel im Anforderungsmanagement

AM: Mir hilft dann immer, dass ich mich frage: Wie denkt der Kunde? Was ist die Frage hinter der Frage? Was genau macht den Unterschied? Was sorgt dafür, dass deine Ansprechpersonen mit dem Ergebnis zufrieden sind oder nicht? Beispiel: Der Wunsch wäre ein Webshop , in dem Produkte verkauft werden können. Nun gibt es in der betreffenden Organisation eine unzählige Anzahl Produkte, die in vielen verschiedenen Datenbanken gepflegt sind – falls sie überhaupt in einer Datenbank sind. Das kann zum Beispiel daran liegen, dass die Produkte von verschiedenen Fachabteilungen entwickelt und betreut werden und jede Fachabteilung hat ihre eigene Anwendung.
ARCH: OK, was willst du damit sagen, komm mal zum Punkt. Ich brauche eine konkrete Idee für mein Problem.

AM: Ich komme gleich zum Punkt. Die Frage hinter der Frage in meinem Beispiel könnte also sein: Warum möchte der Kunde einen Webshop? Möchte er ein neues Marktsegment erobern? Möchte er in seiner bestehenden Zielgruppe die Durchdringung erhöhen? Geht es dabei eventuell um eine eingeschränkte Produktauswahl? All diese Fragen können einen Hinweis auf die benötigte Technik liefern. Du darfst ihn also nicht nach der Technik fragen, sondern du musst dir überlegen, welche Kriterien du für eine Auswahl benötigst. Die musst du dann beim Kunden abfragen.
ARCH: Ich glaube, es ergibt so langsam Sinn. Wenn in deinem Beispiel der Kunde nur 2–3 Produkte in neuen Kundensegmenten verkaufen möchte, könnte eine Präsenz bei Amazon die Antwort sein. Wenn er aber für seine bestehende Kundengruppe einen neuen Verkaufskanal haben möchte ohne Provision zahlen zu müssen, dann ist wahrscheinlich ein eigener Webshop besser. Und vielleicht will er sogar das eine heute und das andere später?

AM: So ist es. Hast du schon eine Idee, wie du das bei deinem Kunden anwenden kannst?
ARCH: Ja und nein. Ein paar Fragen hinter den Fragen finde ich bestimmt. Aber was mache ich damit? Wie gehe ich damit auf den Kunden zu?

Struktur statt Frust: Die Checkliste als Brücke

AM: Du hattest ja nun schon einen ersten Termin mit dem Kunden, der nicht so gut gelaufen ist. Eine Option, die sich jetzt aus meiner Sicht anbieten würde, wäre z. B. eine Checkliste. So zeigst du, dass du zum einen natürlich weiter an einer Lösung interessiert und hoch engagiert bist, aber zum anderen beweist du auch, dass du die Analyse strukturiert und professionell vorantreiben kannst. Denk also über die Fragen hinter den Fragen nach und erstelle daraus eine Checkliste. Meistens fallen dir auch noch ganz andere Fragen ein, die sich deine Ansprechpersonen sich selbst noch gar nicht gestellt haben. Die kannst du direkt mit einfließen lassen. Mit ein bisschen Glück und moderativem Geschick erfährst du so, speziell durch die dadurch entstehende Diskussion, viel mehr darüber, wie das Bild im Kopf deines Gegenübers aussieht.
ARCH: Das mache ich, danke dir!

Icon: GlühbirneErkenntnis des Tages: Vom Verstehen zum Vermitteln

Ein zentrales Learning dieses Treffens: Fragen nicht wörtlich nehmen – sondern hinterfragen. Häufig fehlt gerade im öffentlichen Umfeld die technische Perspektive, um den Lösungsraum korrekt abzubilden. Hier hilft kein Bohren in technischen Details, sondern das Denken in Zielbildern und Entscheidungskriterien.

Eine gut vorbereitete Checkliste kann zum Dialog auf Augenhöhe führen – und zur Erkenntnis: Es gibt nicht den einen richtigen Weg, sondern viele mögliche. Wichtig ist nur, dass alle Beteiligten wissen, welchen Weg sie gehen wollen.


Wie geht es weiter?

Im nächsten Teil zeigt sich, wie diese neue Herangehensweise bei Adams Kunden ankommt – und warum es manchmal nicht nur an der Technik, sondern an der Kommunikation im Projekt scheitert. Bleiben Sie dran!


Bereits erschienen

Teil 1: Ein neues Projekt und viele offene Fragen
Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?
Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes
Teil 4: Was braucht man wirklich, um zu schätzen?
Teil 5: Testen vergessen?
Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!
Teil 7: Fazit und Ausblick

Alle Beiträge von Tim Teulings

Tim Teulings ist als Senior Solution Architekt bei OPITZ CONSULTING tätig. Er unterstützt Software-Entwicklungsteams dabei, schnell, einfach und entspannt Software aufzubauen, die perfekt zum Kunden passt. Am Ende stehen Ergebnisse, die der Kunde wirklich haben will – nicht nur eine Version 1.0. Die Themenbereiche Modernisierung und Integration gehören in dieser Funktion zu seinem täglichen Geschäft. Zu Tims Schwerpunkten zählen entsprechende Tools, Frameworks, Methoden, Vorgehen, Architekturen und Techniken.

Alle Beiträge von Richard Attermeyer

Richard Attermeyer arbeitet als Chief Solution Architect bei OPITZ CONSULTING. Er ist seit vielen Jahren als Entwickler, Architekt und Coach für die Themen Modernisierung, Architektur und agile Projekte tätig und hilft Unternehmen, mit motivierten Teams erfolgreiche Projekte zu realisieren.

Foto: Hilko Delonge, OPITZ CONSULTING
Alle Beiträge von Hilko Delonge

Hilko arbeitet bei OPITZ CONSULTING als Lead Business und IT Analyst. Er verfügt über langjährige Erfahrung im Bereich Requirements Engineering und arbeitet hier eng mit den Kunden an der Entwicklung und Formulierung von Fachanforderugnen in Digitalisierungsprojekten. Er verfügt nicht nur über Projekterfahrung, sondern treibt auch die stetige Weiterbildung der Business Analysten voran.

Schreibe einen Kommentar