Warum Software-Projekte scheitern: Die richtigen Fragen zur richtigen Zeit stellen

Ein Thema, das ich immer wieder sehe und das fast jedem Corporate, fast jeder Agentur, jedem Inhaber und besonders jedem Entwickler und Nutzer von Software bekannt ist: Funktionen, die niemand braucht. Fehlende Funktionen, die jeder braucht.

Eigentlich scheint es doch so einfach – und doch scheitert es immer wieder. Man hört das an vielen Aussagen von wirklich allen Beteiligten:

Chef: "Jetzt habe ich schon so viele Kohle ausgegeben und das ist nicht gelöst?"

CTO: "Ich habe doch schon am Anfang gesagt, das wird nichts. Wir hätten das inhouse regeln sollen."

Marketing: "Aber das sieht ja furchtbar aus. Das wird doch keiner benutzen?"

Sales: "Können wir das noch reinbringen? Das kann ich super verkaufen."

Developer: "Wozu sollen wir das hier weiter entwickeln? Das benutzt keiner."

Produktverantwortliche: "Warum sind hier eigentlich keine Sachen drin, die wir wirklich brauchten?"

Kollegen: "Hast du das Projekt gesehen? Da klappt gar nichts, das sieht furchtbar aus."

UX: "Warum hat uns keiner gefragt?"

und der Schlimmste: Benutzer: "Was soll ich damit?"

Woran scheitert gute Softwareentwicklung?

Es sind zu viele Dinge, die einander beeinflussen. Aber wenn ich mir angucke, was bei uns besser läuft als bei den meisten, würde ich es runterbrechen auf eine Aussage: Die Fähigkeit, früh die richtigen Fragen an die richtigen Rollen zu stellen. Ob das nun dazu führt, dass wir gesamtheitliche Systeme besser verstehen, oder weil wir das tun ist irrelevant.

Dadurch wird aus einem fehlenden oder falschen Scope von Anfang an der richtige Scope. Die Prozesse und Probleme sind definiert, es ist klar, warum etwas nötig ist. Dadurch können Features geplant und entwickelt werden.

Aber was sind die richtigen Fragen? Stellen andere Agenturen absichtlich die "falschen" Fragen? Vermutlich nicht. Es ist eine Frage von wissentlicher Verantwortung und Führung.

Wenn man davon ausgeht, der Kunde weiß genau, was er möchte, dann müsste man über diese Angelegenheiten gar nicht reden. Aber wenn man in der Realität Software entwickelt, merkt man eins schnell: Chefs ändern ihre Meinung. Produktowner ändern den Anwendungsfall. Nutzer ändern ihre Wünsche. Und manche Prozesse sind garnicht allen Stakeholdern bekannt, deswegen muss man ja auch mit jedem sprechen.

Da benötigt es eine Instanz, die führt. Die viel Erfahrung hat. Die versteht, was eine Anforderung wirklich ist – und was sich nur als eine tarnt.

Wie hole ich die richtigen Informationen heraus?

In diesem Sinne reden wir nun über dieses Thema in aller Detailtiefe. Wie hole ich aus mehreren unterschiedlichen Menschen auf unterschiedlichen Arbeitsebenen alle Informationen heraus, die zu einem Prozess gehören bzw. zu einem Problem? Wie nehme ich diese Informationen und strukturiere sie? Und was kann ich mit diesen Informationen machen?

Das sind Schritt 1 & 2 unserer typischen Agenturarbeit mit unseren Kunden. Wir betreuen mehrere kleine Unternehmen bis hin zu großen AGs und lösen Probleme dieser Kunden im Abo.

Lass uns das systematisch angehen. Wir gehen gemeinsam durch die beteiligten Kategorien.

---

Kategorie 1: Kommunikationsrichtlinien – Die 5 Phasen des Erstgesprächs

Ein strukturiertes Erstgespräch dauert ca. 2 Stunden und gliedert sich in 5 klare Phasen. Jede Phase hat ihre eigene Funktion und erfordert unterschiedliche Kommunikationstechniken.

Phase 1: Kennenlernen und Begrüßung (10 Min)

Das Gespräch beginnt mit persönlichem Geplänkel. Jeder erzählt ein bisschen über sich. Hier ist es wichtig rauszustellen, dass man ehrlich ist und das Kundenwohl im Sinn hat. Es geht darum, ein persönliches Gefühl aufzubauen – Vertrauen ist die Basis für alles Weitere.

Ich stelle uns kurz vor, ohne zu verkaufen. Erzähle, was wir machen, wie wir arbeiten. Ich erzähle von einem Projekt, was dem neuen sehr ähnelt. Ich erzähle von unserem pragmatischen Ansatz: Kundenwohl ist wichtiger als Profit. Ehrlichkeit wichtiger als der Auftrag. Nutzen wichtiger als mein Erfolg.

Max 3 Minuten. Mein Kunde kann 5-10 Minuten erzählen.

Dann die Agenda: "Ich würde heute gerne erstmal nur verstehen. Ich frage paar Fragen. Sie erzählen draus los. Keine Sorge, ich füge die Puzzleteile zusammen. Dann frage ich immer weiter, solange bis ich alles verstanden habe. Am Ende fasse ich zusammen und wir schauen, ob ich das auch richtig verstanden habe."

Das nimmt Druck raus. Der Kunde kann frei erzählen, ohne Verkaufsdruck.

Negativbeispiel aus Erfahrung: Sehe ich bei ganz vielen Agenturen. Diese Phase wird 30 Minuten lang gezogen. Lobpudeleien über die eigene Arbeit. Kein Proof, sondern Erzählung. Die Leute sind es leid. Falsches geheucheltes Interesse an der Gegenseite. Auch das merken alle sofort.

Das Meeting wurde gesetzt. Der Gegenüber hat sich die Zeit genommen. Er will loslegen. Vorstellungen hat noch nie jemand gemocht. In der Schule nicht und auch nicht im Arbeitsleben. Es wird schon schnell klar, wer wer ist und warum wir da sitzen.

Phase 2: Problemschilderung – Der Kunde erzählt (20-30 Min)

Jetzt lasse ich den Kunden sein Problem in eigenen Worten schildern. Die zentrale Frage: "Was möchtest du lösen? Was ist das Problem?" Der Kunde soll sich NICHT beherrschen, sondern in Redefluss kommen. Ich notiere dabei alles, was er erzählt, und bringe es parallel in eine Struktur.

Die Einstiegsfrage: Ich beginne mit einer offenen Frage, die nicht mit Ja oder Nein beantwortet werden kann: "Erzähl mir in deinen Worten, was das Problem ist. Was möchtest du lösen?" Diese Frage gibt dem Kunden Raum, frei zu erzählen, ohne dass ich ihn in eine bestimmte Richtung lenke.

Ich vermeide Fragen wie "Brauchen Sie eine Software für X?" – das würde ihn zu früh auf eine Lösung festlegen.

Aktives Zuhören: Während der Kunde erzählt, zeige ich Aufmerksamkeit durch nonverbale Signale. Ich nicke, mache kurze Bestätigungslaute wie "Mhm", "Verstehe", "Aha". Wichtig: Ich unterbreche NICHT. Auch wenn mir etwas unklar ist oder ich eine Frage habe – ich lasse ihn erstmal ausreden. Der Redefluss ist wichtiger als sofortige Klarheit. Fragen kommen später.

Wenn der Kunde eine Pause macht oder aufhört zu erzählen, nutze ich kurze Ermutigungen: "Erzähl weiter", "Das ist interessant, was passiert dann?" oder "Kannst du das noch etwas genauer beschreiben?" Das Ziel ist, dass er wirklich in Fahrt kommt und alles rauslässt, was ihm auf dem Herzen liegt.

Notiz-Technik: Während der Kunde spricht, notiere ich parallel. Ich nutze eine einfache Struktur: Keywords und kurze Stichpunkte, keine vollständigen Sätze. Ich organisiere die Notizen in Kategorien:

Problembeschreibung: Was ist das eigentliche Problem?
Beteiligte Personen/Rollen: Wer ist involviert?
Aktueller Prozess: Wie läuft es jetzt?
Schmerzpunkte: Was nervt besonders?
Wünsche/Ideen: Was schwebt dem Kunden vor?

Ich nutze keine Mindmap oder komplexe Struktur – das würde mich zu sehr ablenken. Einfache Listen reichen. Wichtig: Ich notiere sowohl wörtliche Zitate (in Anführungszeichen) als auch meine eigene Interpretation. Die Zitate helfen später, die genaue Wortwahl des Kunden zu verstehen. Meine Interpretation hilft mir, Zusammenhänge zu erkennen.

Woran erkenne ich: "Jetzt kommt er in Fahrt" vs. "Er hält sich zurück"?

Wenn der Kunde in Fahrt kommt:

Er wird konkreter, erzählt Details
Er wird emotionaler (Frustration, Begeisterung wird spürbar)
Er erzählt Geschichten, Beispiele aus dem Alltag
Er redet schneller, wird lebendiger
Er stellt selbst Fragen oder macht Vorschläge

Wenn er sich zurückhält:

Er gibt kurze, knappe Antworten
Er bleibt sehr allgemein ("Das ist halt so")
Er wirkt reserviert, distanziert
Er erzählt einfach nicht viel – nicht weil er nicht will, sondern weil er nicht weiß, was er erzählen kann
Er lenkt ab oder wechselt das Thema

Wenn ich merke, dass er sich zurückhält, frage ich ganz konkret nach dem Problem im Alltag: "Erzähl mir mal von einem typischen Tag, an dem dieses Problem auftritt. Was passiert da genau? Wer ist beteiligt? Wie fühlst du dich dabei?" Oder: "Beschreib mir mal die letzte Situation, in der du gedacht hast: 'Das nervt, das muss anders werden.' Was ist da passiert?"

Red Flags: Kunde sagt "Wir brauchen Feature X" statt "Wir haben Problem Y"

Das ist ein klassisches Problem. Wenn der Kunde direkt mit einer Lösung kommt ("Wir brauchen eine App für..."), hat er das Problem möglicherweise noch nicht richtig durchdacht. Oder er hat schon eine vorgefertigte Lösung im Kopf, die vielleicht gar nicht das eigentliche Problem löst.

Ich reagiere darauf so: "Okay, ich verstehe. Lass mich kurz nachfragen: Was ist das Problem, das du mit dieser App lösen möchtest? Was passiert aktuell, das dich stört?" Ich lenke das Gespräch zurück zum Problem, nicht zur Lösung. Erst wenn ich das Problem wirklich verstanden habe, können wir über Lösungen sprechen.

Weitere Red Flags:

"Das haben wir schon mal versucht" (ohne zu erklären, was das Problem war)
"Alle anderen machen das so" (ohne zu begründen, warum)
"Das muss einfach funktionieren" (ohne zu erklären, was "funktionieren" bedeutet)
Vage Aussagen ohne konkrete Beispiele

Wie gehe ich damit um, wenn mehrere Personen im Call sind und sich widersprechen?

Das kommt häufig vor, besonders bei größeren Unternehmen. Wichtig: Ich lasse beide ausreden, bevor ich eingreife. Ich notiere beide Perspektiven parallel.

Dann frage ich aktiv nach: "Ich merke, ihr seht das unterschiedlich. Lass uns das kurz klären: Person A, du sagst X. Person B, du sagst Y. Was ist eure gemeinsame Sicht? Oder gibt es hier wirklich zwei verschiedene Probleme?"

Oft zeigt sich, dass:

Sie über verschiedene Aspekte des gleichen Problems sprechen
Sie unterschiedliche Prioritäten haben
Sie unterschiedliche Rollen/Perspektiven haben

Ich strukturiere das so: "Okay, ich verstehe. Person A beschäftigt sich mit Problem X, Person B mit Problem Y. Beides ist wichtig. Lass uns erstmal beide Probleme verstehen, dann schauen wir, wie sie zusammenhängen."

Wenn sie sich wirklich widersprechen und keine Einigung möglich ist, dokumentiere ich beide Positionen klar und schlage vor: "Das müssen wir noch klären. Ich notiere beide Sichtweisen. Vielleicht brauchen wir noch ein separates Gespräch, um das zu sortieren."

Negativbeispiel aus Erfahrung: Sehe ich bei vielen Agenturen. Sie lassen den Kunden einfach erzählen, ohne Struktur. Keine Notizen, keine Nachfragen. Am Ende des Gesprächs weiß niemand mehr, was eigentlich das Problem war. Oder sie springen sofort zu Lösungen: "Ah, dann brauchen Sie eine App für..." – ohne das Problem wirklich verstanden zu haben. Das führt zu Features, die niemand braucht.

Phase 3: Definitionsphase – Prozess Schritt für Schritt verstehen (40-60 Min)

Wenn der Kunde aufhört zu erzählen oder ich merke, er driftet direkt zu weit ab, übernehme ich. Ich habe nun einen groben Prozess auf dem Papier und will ihn bis in alle Tiefen verstehen. Also nehme ich mir alle Teilprozesse oder Elemente und frage immer wieder nach.

Wie überleite ich von Phase 2 zu Phase 3?

Ich mache eine klare Überleitung: "Okay, danke für die ausführliche Schilderung. Jetzt habe ich einen groben Überblick. Lass uns das jetzt Schritt für Schritt durchgehen, damit ich wirklich jeden Teil verstehe. Ich fange mit [erster Teilprozess] an – kannst du mir genau erklären, was dort passiert?"

Oder: "Gut, ich habe jetzt ein Bild. Jetzt möchte ich das systematisch durchgehen. Lass uns bei [Anfangspunkt] starten und jeden Schritt einzeln anschauen."

Wichtig: Ich mache deutlich, dass ich jetzt die Führung übernehme, aber der Kunde weiterhin der Experte ist. "Du bist der Experte für deinen Prozess, ich frage nur, damit ich es verstehe."

Wenn ich etwas nicht verstehe oder nicht alle Details klar sind, frage ich: "Aber nochmal dazu, was genau passiert hier in Realität aktuell?" Ich versuche das große Ganze zu sehen – das können die Kunden meist nicht. Also frage ich oft, wenn sie durch sind im Teilprozess:

"Das ist alles für diesen Teil?"
"Benutzt das sonst noch wer?"
"Muss man an sonst noch was denken?"

Visualisierung: Zeichne ich den Prozess live mit ihm zusammen?

Das kommt darauf an. Je nach Komplexität des Problems und Prozesses biete ich dem Kunden an, gemeinsam zu visualisieren. Bei komplexen Prozessen mit vielen Schritten und Abhängigkeiten mache ich das fast immer – dann nutze ich ein Whiteboard (physisch oder digital wie Miro, ist egal) und zeichne den Prozess Schritt für Schritt mit, während der Kunde erzählt.

Das hat mehrere Vorteile:

Der Kunde sieht sofort, ob ich es richtig verstanden habe
Wir können gemeinsam korrigieren ("Nein, das kommt vorher")
Es entsteht ein gemeinsames Bild, auf das wir uns beziehen können
Komplexe Abhängigkeiten werden sichtbar

Aber: Nicht jedes Mal sieht der Kunde meine Notizen. Manchmal schreibe ich einfach nur für mich mit. Ich schreibe alles untereinander runter – Stichpunkte, Keywords, Abläufe. Nebenbei, wenn Klarheit entsteht, male ich dann ein Flow-Diagramm, Prozess-Diagramm, Sequenz-Diagramm oder eine Mindmap – je nachdem was sich anbietet und wie komplex der Prozess ist.

Das ist wichtig zu verstehen: Die Visualisierung ist für mich, um den Prozess zu verstehen. Nicht immer muss der Kunde das sehen. Manchmal reicht es, wenn ich es für mich strukturiere. Ich entscheide je nach Komplexität und ob es einen Mehrwert für den Kunden bietet. Manchmal schafft es auch nur unnötige Reibung.

Fragetechniken für die Definitionsphase

Ich nutze konkrete Fragen, um tief zu verstehen. Hier sind Beispiele, die ich tatsächlich stelle:

Wer-Fragen (Stakeholder identifizieren):

"Wer ist an diesem Schritt beteiligt? Wer macht was?"
"Wer bekommt das Ergebnis? Wer nutzt es weiter?"
"Wer muss informiert werden, wenn hier etwas schief geht?"
"Wer entscheidet, ob dieser Schritt korrekt abgeschlossen ist?"

Was-Fragen (Ablauf klären):

"Was passiert genau in diesem Schritt? Beschreib mir das Schritt für Schritt."
"Was sind die Inputs? Was kommt rein?"
"Was sind die Outputs? Was kommt raus?"
"Was passiert, wenn dieser Schritt fehlschlägt? Wie wird das gehandhabt?"

Wann-Fragen (Frequenz und Timing):

"Wie oft passiert das? Täglich? Wöchentlich? Bei jedem Auftrag?"
"Wann genau passiert das? Zu welcher Tageszeit? Zu welchem Zeitpunkt im Prozess?"
"Gibt es Zeiten, wo das häufiger passiert? Oder seltener?"
"Wie lange dauert dieser Schritt normalerweise?"

Warum-Fragen (Motivation verstehen):

"Warum passiert das so? Gibt es einen Grund für diese Reihenfolge?"
"Warum ist dieser Schritt wichtig? Was würde passieren, wenn er fehlt?"
"Warum macht das Person X und nicht Person Y?"

Was-wenn-Fragen (Edge Cases und Fehlerfälle):

"Was passiert, wenn die Daten fehlen? Wie wird das gehandhabt?"
"Was passiert, wenn Person X nicht verfügbar ist? Wer springt ein?"
"Was passiert, wenn dieser Schritt länger dauert als geplant?"
"Gibt es Situationen, wo dieser Schritt anders abläuft? Wann?"

Wie-Fragen (Status quo verstehen):

"Wie wird das aktuell gemacht? Schritt für Schritt."
"Wie kommunizieren die Beteiligten? E-Mail? Telefon? Persönlich?"
"Wie wird dokumentiert? Wo wird das festgehalten?"
"Wie wird kontrolliert, ob alles korrekt ist?"

Wie merke ich, dass ich tief genug bin? Wann ist ein Teilprozess "fertig verstanden"?

Ein Teilprozess ist fertig verstanden, wenn ich folgende Fragen beantworten kann:

Was passiert genau? (Ablauf klar)
Wer ist beteiligt? (Stakeholder identifiziert)
Wann/Wie oft passiert das? (Frequenz bekannt)
Was sind die Inputs? (Was kommt rein?)
Was sind die Outputs? (Was kommt raus?)
Was sind die Abhängigkeiten? (Was muss vorher passieren?)
Was sind die Ausnahmen? (Edge Cases bekannt)
Was passiert bei Fehlern? (Fehlerbehandlung klar)

Wenn ich alle diese Punkte verstanden habe, kann ich zum nächsten Teilprozess übergehen. Wenn nicht, frage ich weiter.

Wie gehe ich mit "Das weiß ich nicht" vom Kunden um?

Das kommt häufig vor, besonders bei komplexen Prozessen. Ich reagiere so:

"Okay, das ist in Ordnung. Wer könnte das wissen?" → Identifiziert nächste Ansprechpartner
"Ist das wichtig für das Problem, das wir lösen wollen?" → Prüft Relevanz
"Können wir das für später notieren?" → Dokumentiert offene Punkte

Ich notiere alle "weiß ich nicht"-Punkte explizit in einer Liste "Offene Fragen" und schlage vor: "Das müssen wir noch klären. Vielleicht brauchen wir noch ein Gespräch mit [Person X] oder ich recherchiere das."

Wichtig: Ich lasse mich nicht davon abhalten, weiterzumachen. Nicht alles muss sofort geklärt sein. Aber ich dokumentiere es klar.

Abhängigkeiten aufdecken: "Was muss vorher passiert sein?"

Das ist eine der wichtigsten Fragen. Ich frage systematisch:

"Was muss passiert sein, bevor dieser Schritt startet?"
"Wer muss was gemacht haben?"
"Welche Daten/Informationen brauchst du dafür?"
"Was passiert, wenn das nicht da ist?"

So entsteht ein Bild der Abhängigkeiten. Das ist später wichtig für die Umsetzung – man kann nicht alles parallel entwickeln, manche Dinge müssen in einer bestimmten Reihenfolge kommen.

Ich visualisiere das auch gerne: Pfeile zwischen den Schritten zeigen die Abhängigkeiten. Das macht schnell klar, wo die kritischen Pfade sind.

Negativbeispiel aus Erfahrung: Viele Agenturen fragen zu oberflächlich. Sie fragen "Wie läuft das ab?" und nehmen die erste Antwort als gegeben. Sie fragen nicht nach Edge Cases, nicht nach Fehlerfällen, nicht nach Abhängigkeiten. Oder sie fragen zu technisch: "Welche Datenbank nutzen Sie?" – das ist zu früh. Erst muss der Prozess verstanden sein, dann kommt die Technik. Das führt dazu, dass wichtige Details fehlen und später Probleme auftauchen, die niemand bedacht hat. Manche gehen hier schon in Lösungsvorschläge über. Hier werden viele Fehler gemacht.

Phase 4: Detailphase – Der schmale Grat (20-30 Min)

Hier muss man sehr aufpassen. Kunden verrennen sich nun und wollen alles erzählen über Prozesse hinaus und Details, die zum Problem gehören. Der Grad ist schmal. Alles, was zum Problem gehört, wird erzählt. Alles, wo wir merken "ne, nicht ganz", brechen wir hart ab: "Spannend, aber ich glaube, das ist für das nächste Gespräch erst wichtig."

Ruhig und ohne Emotion. Ich breche hier wirklich in sein Wort und beende es. Wenn man Kunden immer reden lässt, verreden sie sich. Tu ich auch oft genug, daher braucht man Führung an der Stelle.

Wie erkenne ich: "Das ist relevant" vs. "Das ist Ablenkung"?

Relevant ist alles, was:

Direkt zum Problem gehört, das wir lösen wollen
Den Kontext des Problems erklärt (warum ist das ein Problem?)
Die Auswirkungen des Problems zeigt (was passiert, wenn es nicht gelöst wird?)
Die Beteiligten am Problem betrifft
Die Rahmenbedingungen des Problems definiert (technisch, organisatorisch, rechtlich)

Ablenkung ist alles, was:

Zu technische Details enthält, die für die Problemlösung nicht wichtig sind
Politische Geschichten oder interne Konflikte sind (außer sie sind Teil des Problems)
Vergangene Projekte sind, die nichts mit dem aktuellen Problem zu tun haben
"Nice-to-Have" Features sind, die nicht zum Kernproblem gehören
Zu weit in die Zukunft geht (Visionen statt aktuelles Problem)

Konkrete Beispiele für typische Abschweifungen:

"Wir hatten mal ein Projekt, da..." → Vergangenheit, nicht relevant
"Technisch könnte man das so machen..." → Zu technisch, zu früh
"Der Chef will aber..." → Politik, nur relevant wenn es das Problem blockiert
"Später könnten wir auch..." → Zukunft, nicht jetzt relevant
"Das System hat noch diese Funktion..." → Feature-Liste statt Problem

Formulierungen zum Abbrechen

Ich breche bestimmt aber höflich ab:

"Das merke ich mir für später. Aber lass uns erstmal bei [aktuelles Thema] bleiben."
"Das klingt wichtig für die Umsetzung, aber erstmal müssen wir [X] verstehen. Können wir das für später notieren?"
"Stopp kurz – das ist schon zu tief. Lass uns bei [Y] bleiben, das ist jetzt wichtiger."
"Interessant, aber das ist ein anderes Thema. Lass uns das für ein separates Gespräch aufheben."
"Okay, ich verstehe. Aber für das aktuelle Problem ist das noch nicht relevant. Wir kommen darauf zurück, wenn wir soweit sind."

Wichtig: Ich bin ruhig und sachlich. Keine Emotion, keine Rechtfertigung. Einfach klar kommunizieren, dass wir jetzt bei einem anderen Thema sind.

Wie bleibe ich bestimmt aber nicht unhöflich?

Ich nutze eine ruhige, sachliche Stimme. Keine Aggression, keine Rechtfertigung. Ich erkläre kurz warum: "Das ist wichtig, aber wir müssen erstmal [X] klären, sonst verlieren wir den Faden."

Ich zeige Wertschätzung: "Das ist interessant, wirklich. Aber..." – Ich bestätige, dass ich zugehört habe, bevor ich ablenke.

Ich biete eine Alternative: "Können wir das für später notieren?" – Zeigt, dass es nicht unwichtig ist, nur nicht jetzt.

Was mache ich, wenn der Kunde beleidigt reagiert auf Unterbrechung?

Das passiert selten, aber wenn:

Ich bleibe ruhig und sachlich
Ich erkläre kurz: "Ich unterbreche nicht, weil es unwichtig ist, sondern weil wir sonst den Faden verlieren. Wir kommen darauf zurück."
Ich zeige Wertschätzung: "Ich verstehe, dass das wichtig für dich ist. Lass uns das für später notieren."
Wenn er weiter macht, werde ich noch bestimmter: "Ich verstehe, aber wir müssen jetzt bei [X] bleiben. Sonst schaffen wir es nicht, heute alles zu klären."

Meistens reicht es, wenn ich ruhig bleibe und klar kommuniziere. Wenn der Kunde wirklich nicht mitarbeitet, ist das ein Red Flag für die Zusammenarbeit generell.

Wie unterscheide ich "Nice-to-Have Details" von "Must-Know Details"?

Must-Know Details sind:

Was passiert genau? (Ablauf)
Wer ist beteiligt? (Stakeholder)
Was sind die Inputs/Outputs? (Daten, Informationen)
Was sind die Abhängigkeiten? (Was muss vorher passieren?)
Was sind die Ausnahmen? (Edge Cases)
Was passiert bei Fehlern? (Fehlerbehandlung)

Nice-to-Have Details sind:

Wie sieht die Oberfläche aus? (Design-Details, zu früh)
Welche Technologie? (Technische Details, zu früh)
Welche Farben? (Design, nicht relevant für Problem)
"Könnte man auch..." (Zukunft, Visionen)
Historische Geschichten (Vergangenheit, nicht relevant)

Die Frage ist immer: "Brauche ich das, um das Problem zu verstehen?" Wenn ja → Must-Know. Wenn nein → Nice-to-Have, für später.

Negativbeispiel aus Erfahrung: Viele Agenturen lassen den Kunden einfach weiterreden. Sie haben Angst, ihn zu unterbrechen, weil sie denken, das sei unhöflich. Das Ergebnis: Das Gespräch dauert 4 Stunden statt 2, am Ende hat niemand mehr den Überblick, und es wird über 20 verschiedene Themen gesprochen, die nichts miteinander zu tun haben. Oder sie lassen sich in technische Details verrennen, die für das Problemverständnis irrelevant sind. Das führt zu Scope Creep und Projekten, die nie fertig werden.

Phase 5: Abschlussphase – Zusammenfassung & Validierung (15-20 Min)

Ich fasse den Prozess in MEINEM Verständnis erneut zusammen und korrigiere Missverständnisse. Der Kunde bestätigt oder korrigiert meine Zusammenfassung. Das ist der wichtigste Schritt, um sicherzustellen, dass wir beide dasselbe verstanden haben.

Wie strukturiere ich die Zusammenfassung?

Ich strukturiere die Zusammenfassung chronologisch nach dem Prozessablauf, den wir gemeinsam erarbeitet haben. Ich gehe Schritt für Schritt durch:

Problem: Was ist das eigentliche Problem?
Aktueller Prozess: Wie läuft es jetzt? (Schritt für Schritt)
Beteiligte: Wer ist involviert?
Schmerzpunkte: Was nervt besonders?
Auswirkungen: Was passiert, wenn das Problem nicht gelöst wird?
Offene Fragen: Was müssen wir noch klären?

Ich nutze die Visualisierung, die wir gemeinsam erstellt haben, als Referenz. "Lass mich zusammenfassen, was ich verstanden habe..." Dann gehe ich durch den Prozess, den wir gezeichnet haben.

Aktiv nach Feedback fragen: "Habe ich das richtig verstanden?"

Nach jedem größeren Abschnitt frage ich: "Habe ich das richtig verstanden?" oder "Stimmt das so?" Ich lasse Pausen, damit der Kunde Zeit hat zu reagieren.

Am Ende der Zusammenfassung frage ich explizit: "Gibt es etwas, was ich falsch verstanden habe? Oder etwas, was ich vergessen habe?" Ich ermutige aktiv zu Korrekturen: "Bitte korrigiere mich, wenn etwas nicht stimmt. Das ist wichtig."

Was mache ich, wenn der Kunde sagt "Ja, aber..." und ein neues Fass aufmacht?

Das passiert häufig. Der Kunde denkt: "Ah, jetzt fällt mir noch etwas ein!" Ich reagiere so:

Wenn es zum Problem gehört: "Okay, das ist wichtig. Lass uns das kurz aufnehmen." Ich notiere es und integriere es in die Zusammenfassung.

Wenn es ein neues Thema ist: "Das ist interessant, aber das ist ein anderes Problem. Lass uns das für ein separates Gespräch aufheben. Jetzt fokussieren wir uns erstmal auf [aktuelles Problem]."

Ich bleibe bestimmt: "Wir haben jetzt [aktuelles Problem] verstanden. Das andere Thema ist wichtig, aber wir müssen es trennen, sonst wird es zu komplex."

Nächste Schritte klar kommunizieren

Ich mache die nächsten Schritte explizit und verbindlich:

"Ich bereite das auf und schicke es dir bis [Datum]." → Konkretes Datum, nicht "bald"
"Wir brauchen noch ein Gespräch mit [Person X], um [Thema] zu klären." → Klar, wer und warum
"Ich melde mich in [X] Tagen mit [konkretes Ergebnis]." → Konkrete Timeline

Ich frage auch: "Passt das für dich? Können wir das so machen?" → Stellt sicher, dass beide Seiten zustimmen.

Offene Fragen explizit festhalten

Ich liste alle offenen Fragen explizit auf:

"Das müssen wir noch klären: [Liste]"
"Für die nächsten Schritte brauchen wir noch: [Liste]"

Ich mache klar, wer für was verantwortlich ist:

"Ich recherchiere [X]"
"Du klärst mit [Person Y] [Z]"
"Wir treffen uns nochmal für [Thema]"

Wie beende ich das Gespräch positiv aber verbindlich?

Ich beende mit einer positiven Zusammenfassung:

"Super, ich habe jetzt ein klares Bild. Das hilft mir enorm."
"Danke für deine Zeit und Offenheit. Das war sehr hilfreich."

Dann die nächsten Schritte nochmal kurz:

"Ich schicke dir bis [Datum] eine Zusammenfassung."
"Wir sprechen uns dann in [X] Tagen."

Ich frage: "Gibt es noch etwas, was dir wichtig ist, bevor wir aufhören?" → Gibt Raum für letzte Punkte.

Dann: "Perfekt. Dann bis [nächstes Datum/Zeitpunkt]. Danke nochmal!"

Post-Meeting: Wie schnell schicke ich die Dokumentation raus?

Ich schicke die Dokumentation innerhalb von 24-48 Stunden raus. Warum so schnell?

Die Erinnerungen sind noch frisch
Es zeigt Professionalität und Engagement
Der Kunde kann schnell korrigieren, wenn etwas falsch ist

Die Dokumentation enthält:

Zusammenfassung des Problems
Aktueller Prozess (mit Visualisierung)
Beteiligte Stakeholder
Schmerzpunkte
Offene Fragen
Nächste Schritte

Ich nutze ein einfaches Format: Markdown oder ein strukturiertes Dokument. Keine 50-seitigen Powerpoints. Klar, strukturiert, lesbar.

Negativbeispiel aus Erfahrung: Viele Agenturen fassen am Ende nicht zusammen. Sie sagen einfach "Okay, danke für das Gespräch" und gehen. Oder sie fassen zusammen, aber nur oberflächlich: "Also, Sie brauchen eine Software für X, richtig?" – ohne zu prüfen, ob sie wirklich alles verstanden haben. Das führt zu Missverständnissen, die erst später auffallen, wenn schon entwickelt wurde. Oder sie versprechen eine Zusammenfassung, schicken sie aber erst nach 2 Wochen – da hat der Kunde schon alles vergessen.

---

Kategorie 2: Dokumentation – Wie halte ich den Inhalt während und nach dem Gespräch fest?

Wie halte ich Prozesse, Probleme und Inhalte für mich selbst fest?

Während des Gesprächs notiere ich live in einer einfachen Struktur:

Keywords und Stichpunkte (keine vollständigen Sätze)
Wörtliche Zitate in Anführungszeichen
Meine Interpretation daneben
Strukturierung in Kategorien: Problem, Prozess, Stakeholder, Schmerzpunkte

Nach dem Gespräch strukturiere ich das in ein klares Dokument:

Problembeschreibung
Aktueller Prozess (Schritt für Schritt)
Beteiligte Personen/Rollen
Schmerzpunkte
Wünsche/Ideen
Offene Fragen

Ich nutze keine komplexen Tools während des Gesprächs – das würde ablenken. Einfache Notizen reichen. Nach dem Gespräch strukturiere ich es dann.

Wie bereite ich diese Informationen anschließend für Kollegen semantisch auf?

Ich strukturiere die Informationen so, dass Kollegen sie ohne Kontext verstehen können:

Executive Summary: Eine kurze Zusammenfassung (2-3 Sätze) – Was ist das Problem? Wer ist betroffen? Was ist das Ziel?

Problembeschreibung: Detailliert, aber strukturiert

Was ist das Problem?
Wer ist betroffen?
Was sind die Auswirkungen?
Warum ist es wichtig?

Aktueller Prozess: Schritt für Schritt, mit Visualisierung

Wie läuft es jetzt?
Wer macht was?
Was sind die Abhängigkeiten?

Stakeholder-Map: Wer ist beteiligt? Welche Rolle? Welche Interessen?

Schmerzpunkte: Was nervt besonders? Priorisiert nach Wichtigkeit

Offene Fragen: Was müssen wir noch klären?

Nächste Schritte: Was passiert als nächstes? Wer macht was?

Ich nutze klare Überschriften, Bullet Points, Visualisierungen. Keine langen Fließtexte. Strukturiert, scannbar, verständlich.

Live vs. Post-Dokumentation: Notiere ich während des Gesprächs oder danach?

Beides. Während des Gesprächs mache ich kurze Notizen:

Keywords, Stichpunkte
Wichtige Zitate
Strukturierung in Kategorien

Das hilft mir:

Den Faden nicht zu verlieren
Wichtige Punkte nicht zu vergessen
Dem Kunden zu zeigen, dass ich aufmerksam bin

Nach dem Gespräch strukturiere ich das dann vollständig:

Ausformulieren der Notizen
Strukturierung
Visualisierung
Vollständige Dokumentation

Warum nicht nur danach? Weil ich sonst zu viel vergesse. Warum nicht nur während? Weil ich sonst zu sehr mit dem Notieren beschäftigt bin und nicht richtig zuhöre. Die Balance ist wichtig.

Strukturierungsmethoden: Wie strukturiere ich den Prozess?

Wichtig zu verstehen: Zu diesem Zeitpunkt ist noch gar nicht klar, was die Lösung sein wird. Wir haben nur den Prozess verstanden. Vielleicht habe ich schon Ideen, aber hier entsteht noch nichts Konkretes.

Jeder kann strukturieren, wie er will. Im ersten Schritt beschreibe ich den Prozess textuell – Schritt für Schritt, wer macht was, wann passiert was. Das ist die Basis.

Dann unterstütze ich das mit Flow Charts, damit man einen Überblick bekommt. Je nach Komplexität:

Flow-Diagramm: Für lineare Prozesse mit klaren Schritten
Prozess-Diagramm: Für komplexe Prozesse mit Verzweigungen
Sequenz-Diagramm: Für Prozesse mit mehreren Beteiligten und Interaktionen
Mindmap: Für Prozesse mit vielen parallelen Strängen

Das Ziel ist, den Prozess zu verstehen und zu visualisieren. Nicht, die Lösung zu definieren. Das kommt später.

Wichtig: User Stories, Jobs-to-be-Done, Use Cases – das sind Methoden für später, wenn wir die Lösung entwickeln. Im Erstgespräch geht es nur um den Prozess. Nicht um Features, nicht um Lösungen, nicht um Must-Have vs. Nice-to-Have. Das ist zu früh.

Im Erstgespräch dokumentiere ich:

Den aktuellen Prozess (textuell + visuell)
Die Beteiligten
Die Schmerzpunkte
Die Abhängigkeiten
Die Edge Cases

Das reicht. Die Lösungsideen kommen später, wenn ich den Prozess wirklich verstanden habe.

Tools & Templates: Welche konkreten Tools nutzen wir?

Ich nutze einfache, pragmatische Tools:

Während des Gesprächs:

Notion oder einfaches Textdokument für Notizen
Miro oder Lucidspark für Visualisierung (wenn digital)
Physisches Whiteboard (wenn vor Ort)

Nach dem Gespräch:

Notion für strukturierte Dokumentation
Miro für Prozess-Visualisierungen
Einfache Markdown-Dateien für einfache Fälle

Ich nutze keine komplexen Tools – sie lenken ab und sind Overkill. Einfach, pragmatisch, funktional.

Templates nutze ich als Orientierung, nicht als starre Vorlage. Jedes Projekt ist anders, die Struktur muss passen.

---

Kategorie 3: Weiterführung – Mit wem rede ich auf Basis der Informationen weiter?

Woher weiß ich, mit wem ich nach dem Erstgespräch weiter reden muss?

Während des Gesprächs identifiziere ich alle Stakeholder:

Wer ist beteiligt am Prozess?
Wer ist betroffen vom Problem?
Wer hat Informationen, die ich brauche?
Wer ist Entscheider?

Ich notiere das explizit: "Stakeholder-Liste"

Name, Rolle, Relevanz für das Problem
Was weiß diese Person? Was brauche ich von ihr?
Priorität: Muss ich mit ihr sprechen? Oder reicht es, wenn der Erstkontakt sie fragt?

Dann priorisiere ich:

Muss ich sprechen: Entscheider, direkte Nutzer, technische Experten
Sollte ich sprechen: Indirekt betroffene, weitere Stakeholder
Kann der Erstkontakt klären: Weniger relevante Personen

Was mache ich nun mit den ganzen Informationen, die ich gesammelt habe?

Ich strukturiere die Informationen und nutze sie für:

Dokumentation: Vollständige Aufbereitung (siehe Kategorie 2)
Stakeholder-Mapping: Wer ist wer? Wer braucht was?
Problem-Analyse: Was ist das eigentliche Problem? Was sind die Ursachen?
Lösungsansätze: Welche Lösungen sind möglich? Was passt?
Nächste Schritte: Mit wem rede ich weiter? Was muss noch geklärt werden?

Ich nutze die Informationen nicht nur für mich, sondern bereite sie so auf, dass:

Der Kunde sie versteht und validieren kann
Mein Team sie nutzen kann für die Umsetzung
Alle Stakeholder auf dem gleichen Stand sind

Stakeholder-Mapping: Wie identifiziere ich alle relevanten Personen?

Ich erstelle eine Stakeholder-Map:

Kategorien:

Entscheider: Wer entscheidet über Budget, Go/No-Go?
Nutzer: Wer nutzt die Lösung täglich?
Experten: Wer hat das Fachwissen?
Betroffene: Wer ist indirekt betroffen?
Blockierer: Wer könnte das Projekt blockieren?

Für jede Person notiere ich:

Name, Rolle, Abteilung
Relevanz für das Problem (hoch/mittel/niedrig)
Was weiß sie? Was brauche ich von ihr?
Muss ich mit ihr sprechen? Oder reicht der Erstkontakt?
Priorität: Wann muss ich mit ihr sprechen?

Visualisierung: Ich nutze eine einfache Matrix:

X-Achse: Einfluss (niedrig → hoch)
Y-Achse: Interesse/Betroffenheit (niedrig → hoch)

Das zeigt schnell:

Wer ist wichtig und muss informiert werden?
Wer muss aktiv einbezogen werden?
Wer kann informiert bleiben?

Validierungsschleifen: Wann gehe ich zurück zum Erstkontakt?

Ich gehe zurück zum Erstkontakt, wenn:

Ich neue Informationen habe, die das Problem verändern könnten
Ich Widersprüche zwischen verschiedenen Stakeholdern feststelle
Ich offene Fragen habe, die nur der Erstkontakt beantworten kann
Ich eine Lösungsidee habe und Feedback brauche
Ich unsicher bin, ob ich etwas richtig verstanden habe

Ich mache das regelmäßig, nicht nur am Ende:

Nach jedem wichtigen Gespräch mit anderen Stakeholdern
Wenn sich neue Erkenntnisse ergeben
Vor wichtigen Entscheidungen

Ich kommuniziere klar: "Ich habe mit [Person X] gesprochen und [Erkenntnis Y] erfahren. Passt das zu dem, was du mir erzählt hast? Oder sehe ich das falsch?"

Interne Weitergabe: Wie bringe ich mein Team auf denselben Stand?

Ich bereite die Informationen so auf, dass mein Team sie ohne mich verstehen kann:

Executive Summary: Was ist das Problem? Was ist das Ziel? (2-3 Sätze)

Vollständige Dokumentation: Alle Details strukturiert (siehe Kategorie 2)

Visualisierungen: Prozesse, Stakeholder-Maps, Abhängigkeiten

Offene Fragen: Was müssen wir noch klären?

Nächste Schritte: Was passiert als nächstes? Wer macht was?

Ich nutze klare Struktur, keine langen Fließtexte. Bullet Points, Überschriften, Visualisierungen.

Ich mache ein kurzes Briefing mit dem Team:

Präsentiere die Dokumentation
Erkläre das Problem
Zeige die Visualisierungen
Beantworte Fragen
Kläre nächste Schritte

Kontinuierliche Abstimmung während der Umsetzung

Während der Umsetzung bleibe ich in Kontakt:

Regelmäßige Updates: "Hier ist der aktuelle Stand. Passt das noch?"
Fragen schnell klären: "Ich habe eine Frage zu [X]. Kannst du kurz helfen?"
Feedback einholen: "Hier ist ein erster Entwurf. Was denkst du?"
Anpassungen kommunizieren: "Wir haben [X] anders gemacht, weil [Y]. Passt das?"

Ich nutze kurze, regelmäßige Kommunikation statt langer Meetings. Slack, kurze Calls, schnelle Rückfragen.

Wichtig: Ich bleibe proaktiv. Ich warte nicht, bis Probleme auftauchen. Ich frage regelmäßig nach, ob alles noch passt.

---

Fazit

Die Fähigkeit, früh die richtigen Fragen an die richtigen Rollen zu stellen, ist der entscheidende Unterschied zwischen erfolgreichen und gescheiterten Software-Projekten. Es ist keine Magie – es ist ein strukturierter Prozess, den man lernen und anwenden kann.

Die 5 Phasen des Erstgesprächs geben dir einen klaren Rahmen. Die Dokumentationsmethoden helfen dir, die Informationen strukturiert festzuhalten. Die Stakeholder-Analyse zeigt dir, mit wem du weiter reden musst.

Aber am wichtigsten ist: Du musst führen. Du musst die Verantwortung übernehmen. Du musst verstehen, was eine Anforderung wirklich ist – und was sich nur als eine tarnt.

Das ist der Unterschied zwischen einer Agentur, die Features baut, die niemand braucht – und einer, die Probleme löst, die wirklich wichtig sind.

Posts

Warum Software-Projekte scheitern: Die richtigen Fragen zur richtigen Zeit stellen