Viele Projekte starten nicht mit zu wenig Klarheit, sondern mit falscher Klarheit. Im Erstgespräch liegt oft bereits ein Zielbild auf dem Tisch, manchmal sogar eine konkrete Lösungsrichtung. «Wir möchten die Spesenerfassung modernisieren. Mitarbeitende sollen Belege per App erfassen, die Daten später ins ERP fliessen – schlank starten, ausbaufähig bleiben.» Das klingt nicht naiv. Es klingt vorbereitet, plausibel, anschlussfähig.
Genau darin liegt das Risiko. Denn was wie ein klarer Auftrag wirkt, ist meist eine Mischung aus Problemannahmen, Lösungsideen, technischen Vorgaben und impliziten Erwartungen – ohne dass das Problem dahinter je ausgelotet wurde.
Was ist eigentlich das Problem? Die Mitarbeitenden, die mühsam erfassen? Die Buchhaltung, die nachbearbeitet? Die Datenqualität? Oder geht es vor allem um eine technische Modernisierung? Und was wird vom Projekt erwartet – ein Prototyp, ein belastbares Vorprojekt, ein umsetzbares Konzept oder bereits eine erste produktive Lösung?
Diese Unterschiede wirken klein. Sind sie nicht.
Auf dem Erstgespräch baut das Angebot auf, die empfohlene Flughöhe, das Vorgehen, das Erwartungsmanagement – und später die Frage, woran das Ergebnis gemessen wird.
Was hier nicht sichtbar wird, verschwindet nicht. Es taucht später wieder auf: als Scope-Diskussion, als Enttäuschung, als technische Überraschung. Oder als Produkt, das formal geliefert wurde, aber nicht das trifft, was eigentlich gemeint war.
Das klassische Problem Statement ist wertvoll. Es zwingt dazu, nicht sofort in Lösungen zu springen, und fragt nach Nutzer, Problem und gewünschter Wirkung.
In vielen B2B-Vorhaben reicht das nicht. Sie starten selten auf der grünen Wiese, sondern in bestehenden Systemen, mit Prozessen, Abhängigkeiten, Rollen, Daten, Budgetannahmen und Erwartungen. Technik ist dort nicht die spätere Umsetzung. Manchmal ist sie Teil des Problems, manchmal die Grenze des Lösungsraums, manchmal der eigentliche Grund, warum das Vorhaben gestartet wurde.
Dazu kommt eine typische Gesprächsdynamik: Nach einem kurzen Ausflug ins Business rutscht das Gespräch schnell in die Technik – Systeme, Schnittstellen, Datenmodelle. Das ist wichtig. Aber ohne Gesprächsführung bleibt unklar, wie diese technischen Themen mit Problem, Zielbild und Projekterwartung zusammenhängen.
Genau dafür habe ich ProblemDraft weiterentwickelt.
ProblemDraft ist eine Erweiterung des Proto-Problem-Statements für Vorhaben, die nicht auf der grünen Wiese starten. Die Methode strukturiert das Erstgespräch entlang dreier Perspektiven – Business, Technik, Projekterwartungen – nicht, um das Gespräch in ein Raster zu pressen, sondern weil alle drei ohnehin im Raum stehen.
Dadurch entsteht keine Spezifikation, sondern eine sortierte Ausgangslage – getrennt nach Problemannahme, Lösungsannahme, technischer Rahmenbedingung und Projekterwartung.
Der wichtigste Punkt: Jede Aussage bleibt zuerst eine Annahme. Nicht eine Anforderung, nicht eine Planung, nicht eine Tatsache.
Das ist mir wichtig: ProblemDraft ist kein Verhör und kein Filter, der Aussagen sofort korrigiert. Die Methode nimmt ernst, was der Auftraggeber mitbringt – Ziele, Sorgen, technische Hinweise, bestehende Ideen, Erwartungen.
Alles bekommt einen Ort. Aber nicht alles bekommt sofort denselben Status. Manches wird später validiert, manches relativiert, manches gehört erst in den Lösungsraum, manches ist schon fürs Angebot entscheidend. So entsteht ein besseres Gespräch – nicht, weil man sagt «das ist falsch», sondern weil man sichtbar macht: Das ist eine Annahme, sie hat Folgen, wir klären, ob sie trägt.
Zurück zur Spesenerfassung. Wird früh von einer App mit Belegscan gesprochen, klingt das konkret. Aber eine App löst nicht automatisch uneinheitliche Freigaben, fehlende Kostenstellen oder eine ungeprüfte ERP-Schnittstelle – und auch nicht die Erwartung, dass die Buchhaltung weniger Arbeit hat.
Vielleicht ist die App trotzdem richtig. Vielleicht ist sie nur ein Teil der Lösung. ProblemDraft macht genau das früh sichtbar: Wo steht ein Lösungsansatz im Raum, ohne dass klar ist, auf welches Problem er antwortet?
Ein Lösungsansatz, der auf kein klar erfasstes Problem zurückführbar ist, ist ein Warnsignal. Keine Anforderung.
ProblemDraft erzeugt kein fertiges Problem Statement, sondern eine gemeinsame Annahmenbasis. Im externen Projektkontext ist das entscheidend: Diese Annahmen beeinflussen das Angebot, die Flughöhe, das Vorgehen und später die Bewertung des Ergebnisses. Was im ersten Gespräch vergessen geht, wird später teuer – im Angebot, in der Umsetzung, nach der Lancierung.
ProblemDraft verhindert nicht jede Unsicherheit. Aber es verhindert, dass Unsicherheit als Klarheit verkauft wird.
Nicht, weil danach alles klar ist. Sondern weil endlich sichtbar wird, was noch nicht klar ist.