Wenn Unternehmen eine Agentur oder einen Entwicklungspartner für ein Softwareprojekt anfragen, glauben viele zunächst, sie müssten möglichst viele Funktionen auflisten. Je länger die Liste, desto besser die Anfrage, so die Hoffnung. In Wirklichkeit passiert oft das Gegenteil. Lange Listen erzeugen den Eindruck von Vollständigkeit, obwohl die eigentliche Projektlogik unscharf bleibt. Am Ende sind die Angebote detailliert formuliert, aber inhaltlich nur schwer vergleichbar.
Das Problem liegt nicht darin, dass Anforderungen fehlen. Das Problem liegt darin, dass sie auf der falschen Ebene beschrieben werden. Eine gute Anfrage beschreibt nicht nur, was das System können soll. Sie macht auch sichtbar, welches Geschäftsproblem gelöst werden muss, welche Nutzer beteiligt sind, wo Entscheidungen entstehen und welche Randbedingungen nicht verhandelbar sind. Erst damit kann ein Anbieter Aufwand, Risiko und sinnvolle Release-Grenzen realistisch einschätzen.
Gerade wenn mehrere Agenturen im Rennen sind, ist diese Vorarbeit enorm wertvoll. Sie spart nicht nur Zeit im Auswahlprozess. Sie schützt auch davor, ein Projekt mit falscher Sicherheit zu starten, nur weil ein Angebot besonders präzise aussieht.
Vergleichbarkeit entsteht aus einem gemeinsamen Problemverständnis
Angebote werden nur dann wirklich vergleichbar, wenn alle Beteiligten dieselbe Aufgabe vor Augen haben. Das klingt banal, scheitert aber oft an kleinen Unschärfen. Für die eine Agentur ist das Projekt eine klassische Webanwendung. Für die andere ist es ein interner Workflow mit Rechte- und Prozesslogik. Ein dritter Anbieter versteht es primär als Design- und Frontend-Projekt. Alle drei Perspektiven können Teile der Wahrheit enthalten, führen aber zu völlig unterschiedlichen Lösungen.
Deshalb sollte Ihre Anfrage zu Beginn in einfachen Worten beantworten, warum das Projekt überhaupt gebraucht wird. Welcher Engpass besteht heute? Was funktioniert im aktuellen Ablauf nicht? Woran merken Mitarbeitende, Kunden oder Partner den Mangel täglich? Eine klare Ausgangslage hilft Anbietern, Prioritäten richtig zu setzen. Ohne sie wird aus der Anfrage schnell ein Interpretationsspiel.
Beschreiben Sie zuerst den Kernablauf, nicht die Oberfläche
Viele Briefings beginnen mit Menüs, Modulen und Ansichten. Das ist verständlich, weil Oberflächen leicht zu benennen sind. Für die Qualität des Angebots ist jedoch der Kernablauf viel wichtiger. Was stößt einen Vorgang an? Wer ist beteiligt? Welche Entscheidungspunkte gibt es? Welche Informationen müssen vorliegen? Wo enden Standardfälle und wo beginnen Ausnahmen?
Wenn dieser Ablauf sauber beschrieben ist, lassen sich Screens, Rollen und Datenfelder viel besser ableiten. Umgekehrt funktioniert das nur selten. Wer nur mit Oberflächen startet, beschreibt meist Symptome, nicht die zugrunde liegende Prozesslogik. Das führt zu Angeboten, die visuell konkret wirken, aber operative Risiken verdecken.
Gerade bei internen Tools, SaaS-Produkten oder Freigabeprozessen sollten Sie daher den Weg eines Vorgangs durch das System nachzeichnen. Nicht als technisches Diagramm, sondern als verständliche Handlungskette. Dieser Schritt macht später einen enormen Unterschied bei Scope, Aufwand und Priorisierung.
Muss-Anforderungen sind nicht dasselbe wie Wunschfunktionen
Ein häufiger Fehler in Agenturanfragen ist die fehlende Trennung zwischen unverzichtbar und wünschenswert. Alles landet auf derselben Ebene, oft mit der Absicht, möglichst nichts zu vergessen. Für Anbieter ist das jedoch problematisch. Wenn alles wichtig klingt, ist nichts sauber priorisiert. Dann werden Angebote entweder übervorsichtig kalkuliert oder auf zu optimistischen Annahmen aufgebaut.
Eine stärkere Anfrage benennt deshalb klar, was für einen ersten belastbaren Release wirklich notwendig ist. Dazu gehören Kernnutzer, Pflichtprozesse, relevante Rollen, notwendige Nachvollziehbarkeit, Integrationen mit echter Geschäftsrelevanz und nicht verhandelbare Sicherheitsanforderungen. Darüber hinaus können Sie Erweiterungen, Komfortfunktionen und spätere Ausbaustufen separat markieren.
Diese Trennung hilft nicht nur den Anbietern. Sie hilft auch Ihnen intern. Oft wird erst beim Schreiben der Anfrage sichtbar, welche Vorstellungen eigentlich noch ungeklärt oder untereinander widersprüchlich sind.
Nennen Sie Randbedingungen, bevor sie zum Nachtrag werden
Die unangenehmsten Überraschungen im Projekt entstehen selten aus Features. Sie entstehen aus Randbedingungen, die zu spät offenliegen. Dazu gehören vorhandene Systeme, die angebunden werden müssen, Sicherheitsanforderungen, Hosting-Vorgaben, Rollenmodelle, Freigabewege, interne Freigabeketten, Dokumentationspflichten oder zeitliche Abhängigkeiten zu anderen Initiativen.
Wenn solche Punkte in der Anfrage fehlen, kalkulieren Anbieter zwangsläufig mit Lücken. Dann wirken Angebote zunächst attraktiv, werden aber später durch Nachträge, neue Annahmen oder zusätzliche Projektphasen ergänzt. Aus Unternehmenssicht fühlt sich das wie Unzuverlässigkeit an. In Wirklichkeit fehlte dem Projekt oft nur die Grundlage.
Sie müssen in der Anfrage nicht jede technische Einzelheit kennen. Sie sollten aber offen benennen, welche Rahmenbedingungen schon feststehen und welche noch entschieden werden müssen. Diese Ehrlichkeit verbessert die Qualität der Rückfragen und verhindert Scheingenauigkeit.
Schreiben Sie für Entscheidungen, nicht für Vollständigkeit
Ein starker Projektbrief muss nicht alles wissen. Er muss die richtigen Entscheidungen vorbereiten. Genau deshalb ist ein überladener Anforderungskatalog oft schwächer als ein kompakter, aber sauber strukturierter Brief.
Hilfreich ist, wenn Ihre Anfrage mindestens auf diese Fragen eine klare Antwort gibt:
- Welches Geschäftsproblem soll zuerst gelöst werden?
- Wer nutzt das System im ersten Release tatsächlich?
- Welcher Ablauf muss Ende zu Ende zuverlässig funktionieren?
- Welche Risiken oder Pflichtanforderungen dürfen nicht übersehen werden?
- Woran würden Sie erkennen, dass das Projekt nach dem Launch seinen Zweck erfüllt?
Mehr braucht es für ein gutes erstes Gespräch oft nicht. Was danach folgt, kann in Discovery, Angebotsverfeinerung und gemeinsamer Scope-Planung ausgearbeitet werden.
Vermeiden Sie technische Scheinsicherheit
Manche Unternehmen versuchen, fehlende Projektsicherheit durch sehr frühe technische Festlegungen zu kompensieren. Dann steht in der Anfrage bereits, welches Framework, welche Datenbank oder welche Hosting-Struktur verwendet werden soll, obwohl der eigentliche Produktkontext noch nicht sauber beschrieben ist.
Das kann sinnvoll sein, wenn echte Vorgaben existieren, etwa aus Compliance, bestehender Infrastruktur oder internen Standards. Problematisch wird es, wenn technische Entscheidungen nur deshalb vorab festgeschrieben werden, weil sie greifbarer wirken als Geschäftslogik. Dann wird die Lösungsfreiheit eingeschränkt, ohne dass dadurch mehr Klarheit entsteht.
Ein guter Partner kann mit technischen Vorgaben umgehen. Er kann aber nur dann sauber beraten, wenn klar ist, welche Vorgaben zwingend und welche eher Präferenzen sind. Wenn Sie diesen Unterschied kenntlich machen, verbessern Sie automatisch die Qualität der späteren Architekturgespräche.
Die Anfrage sollte auch den Auswahlprozess entlasten
Ein guter Brief wirkt nicht nur auf das Angebot selbst. Er verbessert auch Ihren Auswahlprozess. Wenn Sie mehrere Partner anfragen, können Sie Rückfragen, Annahmen und Angebotslogik viel schneller nebeneinanderlegen. Sie sehen besser, wer Ihr Problem verstanden hat, wer Risiken transparent macht und wer nur eine elegante Präsentation liefert.
Vor allem aber entstehen weniger Missverständnisse im Erstgespräch. Statt Zeit mit Grundsortierung zu verlieren, können Sie über Prioritäten, Betriebsmodell und Delivery sprechen. Genau dort wird Auswahl erst wertvoll.
Wer ohne diese Struktur in den Prozess geht, merkt oft erst nach mehreren Gesprächen, dass die Antworten nicht auf dieselbe Frage gegeben wurden. Dann beginnt die eigentliche Arbeit sehr spät.
Ein Brief ist kein Pflichtenheft, sondern ein Startpunkt mit Haltung
Viele Teams fürchten, eine Anfrage sei erst dann gut genug, wenn sie nahezu ein vollständiges Pflichtenheft ersetzt. Das ist selten notwendig und in frühen Phasen oft sogar kontraproduktiv. Was Sie brauchen, ist kein Scheinabschluss vor Projektbeginn, sondern ein belastbarer Startpunkt.
Ein guter Startpunkt zeigt Haltung. Er macht deutlich, wo Sie Klarheit haben und wo Sie Beratung erwarten. Er markiert Risiken nicht als Schwäche, sondern als Teil einer professionellen Vorbereitung. Er hilft Agenturen dabei, nicht nur Aufwand zu schätzen, sondern Verantwortung und Projektlogik zu verstehen.
Genau das macht später die Zusammenarbeit besser. Ein Partner kann nur dort gut beraten, wo die Ausgangslage ehrlich beschrieben ist.
Woran man erkennt, dass eine Anfrage noch nicht bereit ist
Es gibt einige typische Signale. Wenn in der Anfrage fast nur Features stehen, aber kaum Prozesslogik, fehlt meist die belastbare Grundlage. Wenn Erfolg nur in allgemeinen Formeln wie "modern", "benutzerfreundlich" oder "skalierbar" beschrieben wird, bleibt die Zieldefinition zu weich. Wenn interne Abhängigkeiten, Genehmigungen oder Zuständigkeiten ungeklärt sind, wird die Agentur später einen Teil dieser Klärungsarbeit übernehmen müssen, ob geplant oder ungeplant.
Auch unverbundene Widersprüche sind ein Hinweis. Zum Beispiel, wenn gleichzeitig ein schneller Start, hohe Individualisierung, strenge Governance und minimale Abstimmung versprochen werden. Solche Spannungen sind normal, sollten aber nicht unkommentiert bleiben. Je früher Sie sie benennen, desto besser wird die spätere Planung.
Wie Sie Ihre Anfrage ohne großen Overhead deutlich besser machen
Sie brauchen dafür kein monatelanges Vorprojekt. Meist reichen einige konzentrierte Arbeitsschritte. Sammeln Sie zuerst die wichtigsten Stakeholder-Perspektiven. Formulieren Sie dann das Kernproblem in ein bis zwei klaren Absätzen. Beschreiben Sie den zentralen Ablauf, markieren Sie Muss und später, nennen Sie relevante Randbedingungen und ergänzen Sie, woran Sie Erfolg messen möchten. Damit schaffen Sie eine Grundlage, mit der Anbieter wirklich arbeiten können.
Wenn Ihnen dafür intern die Struktur fehlt, ist das kein Zeichen, dass das Projekt noch nicht starten darf. Es ist nur ein Hinweis darauf, dass vor dem Angebot eine gute Sortierung nötig ist. Genau diese Sortierung spart später sehr viel Zeit und Friktion.
Wenn Sie Ihre Anfrage auf eine belastbare Grundlage stellen möchten, können Sie direkt unseren Projektbrief nutzen. Wenn Sie vorab typische Fragen zu Scope, Prozess und Zusammenarbeit klären möchten, ist auch die Seite mit häufigen Fragen unter FAQ ein guter Startpunkt.
