--- title: "Softwareprojekt-Briefing für vergleichbare Angebote" description: "Was in ein Briefing für ein Softwareprojekt gehört, damit Angebote genau werden: Problem, Nutzer, Systeme, Daten, Budgetrahmen, Offenes und typische Fehler." canonical: https://sdk.enterprises/de/insights/writing-a-software-project-brief language: de --- # Softwareprojekt-Briefing für vergleichbare Angebote Aktualisiert: 2026-09-26 > Ein gutes Briefing für ein Softwareprojekt beschreibt das Problem, die Nutzer, die beteiligten Systeme und woran Erfolg zu erkennen ist, und lässt die Lösung für die Vorschläge der Partner offen. Schicken Sie jedem Partner dasselbe Briefing mit einem Budgetrahmen und einer klaren Liste dessen, was feststeht: Dann sind die Angebote, die Sie zurückbekommen, genau genug, um sie zu vergleichen. ## Ein Briefing soll Antworten vergleichbar machen Ein Projektbriefing hat eine Aufgabe: mehreren Partnern Ihr Problem so gut verständlich zu machen, dass sie einen Lösungsweg vorschlagen können, mit einer Schätzung, der Sie vertrauen können. Füllt jeder Partner die Lücken mit eigenen Annahmen, unterscheiden sich die Angebote im Umfang statt in der Qualität, und das günstigste ist oft das, das am wenigsten angenommen hat. Das Briefing sollte also beim Problem präzise und bei der Lösung zurückhaltend sein. Beschreiben Sie, was nach Abschluss des Projekts gelten muss, und lassen Sie die Partner erklären, wie sie dorthin kämen. Ihre Antworten auf diesen offenen Teil sind das Nützlichste, was Sie lesen werden. ## Beginnen Sie mit dem geschäftlichen Problem und damit, wie Sie Erfolg messen Beginnen Sie mit dem Grund für das Projekt: was heute nicht funktioniert, wen es betrifft und was es Sie kostet, alles so zu lassen. Die Aussage, dass Ihr Betriebsteam jede Bestellung aus E-Mails von Hand ins ERP abtippt, sagt einem Partner weit mehr als die Bitte um ein Portal zur Auftragsverwaltung. Sagen Sie dann, wie Sie den Erfolg beurteilen werden. Wählen Sie einige beobachtbare Ergebnisse, etwa die eingesparte Zeit pro Bestellung, Fehler, die nicht mehr bei Kunden ankommen, oder ein Datum, an dem ein altes System abgeschaltet werden kann. Diese Kriterien werden später zu den Abnahmekriterien der Meilensteine, formulieren Sie sie also so, dass jemand sie prüfen kann. ## Beschreiben Sie Nutzer, Systeme und Daten vor den Funktionen Integrations- und Datenarbeit wird leicht unterschätzt, wenn ein Partner sie nicht sehen kann. Bevor Sie Funktionen auflisten, beschreiben Sie, wer die Software nutzen wird, mit welchen Systemen sie zusammenarbeiten muss und welche Daten sie verarbeitet. Lücken in diesem Teil kommen später als Änderungswünsche zurück. - Nutzer: wer sie sind, ungefähr wie viele, wo und auf welchen Geräten sie arbeiten. - Bestehende Systeme: welche es sind, wem sie gehören und ob sie eine dokumentierte API bieten oder nur eine Datenbank und Dateiexporte. - Daten: welche personenbezogen, vertraulich oder reguliert sind, wo sie heute liegen und wie viel davon migriert werden muss. - Betrieb: wer die Software nach dem Launch betreibt und welche Regeln für Hosting oder Cloud in Ihrem Unternehmen bereits gelten. - Rahmenbedingungen: Sprachen, Anforderungen an Barrierefreiheit, Sicherheitsstandards und jede Frist, die sich nicht verschieben lässt, mit ihrem Grund. ## Nennen Sie einen Budgetrahmen und die Frist, die wirklich zählt Viele Auftraggeber halten das Budget zurück, um zu sehen, was die Partner vorschlagen. Das Ergebnis sind Angebote für unterschiedliche Projekte: Ein Partner plant das Minimum, ein anderer alles, was Sie erwähnt haben. Ein Rahmen, auch ein weiter, erlaubt jedem Partner, das beste Projekt vorzuschlagen, das hineinpasst, und Ihnen offen zu sagen, wenn es nicht passt. Machen Sie es mit der Zeit genauso. Sagen Sie, welches Datum feststeht und warum, etwa ein auslaufender Vertrag oder eine regulatorische Frist, und welche Termine nur Wünsche sind. Ein Partner kann nur um einen festen Termin herum planen, wenn er weiß, welcher es ist. ## Kennzeichnen Sie, was feststeht, und lassen Sie den Rest offen Kennzeichnen Sie jede Anforderung als fest, bevorzugt oder offen. Fest heißt, ein Angebot ist ohne sie nicht gültig, etwa Hosting in der EU oder die Anmeldung über Ihren bestehenden Identitätsanbieter. Bevorzugt heißt, Sie haben einen Grund, würden aber eine Alternative prüfen. Offen heißt, Sie wollen die Empfehlung des Partners. Lassen Sie die Technologie offen, es sei denn, Sie haben einen echten Grund, sie festzulegen, etwa ein internes Team, das den Code warten wird, oder eine Plattform, auf die Ihr Unternehmen standardisiert ist. Wenn Sie eine Wahl festlegen, sagen Sie, warum, damit die Partner ihr Angebot nicht darauf verwenden, dagegen zu argumentieren. Bitten Sie schließlich jeden Partner, in derselben Struktur zu antworten: sein Verständnis des Problems, das Vorgehen, Phasen und Meilensteine, Annahmen, Risiken, das Team und das Abrechnungsmodell. Erst eine gemeinsame Struktur macht die Angebote in der Praxis vergleichbar. ## Fehler, die Angebote unvergleichbar machen Viele unbrauchbare Angebote sind Antworten auf ein Briefing, das sie geradezu herausgefordert hat. Beseitigen Sie diese Muster, bevor Sie Ihres verschicken. - Eine Funktionsliste ohne Problembeschreibung, sodass jeder Partner Ihre Prioritäten errät. - Eine lange Spezifikation, die die Lösung festlegt, bevor jemand das Problem untersucht hat. - Kein Wort zu bestehenden Systemen oder zur Datenmigration, die dann als Änderungswünsche zurückkommen. - Zusätzliche Details, die nur einige Partner in Gesprächen erhalten, sodass ihre Angebote unterschiedliche Fragen beantworten. - Wörter wie einfach, Standard oder wie eine bekannte App, die für jeden Leser etwas anderes bedeuten. - Keine Frist für Rückfragen oder Antworten, die nur an den Partner gehen, der gefragt hat. ## Laden Sie zu Fragen ein und werten Sie sie als Teil der Bewertung Geben Sie den Partnern einen festen Zeitraum für Fragen, antworten Sie schriftlich und schicken Sie jede Antwort an alle. Die Fragen verraten schon für sich etwas: Ein Partner, der nach Ihren Daten, Ihren Nutzern und Ihren Abnahmekriterien fragt, denkt bereits an die Umsetzung. Ist das Problem noch zu unklar, um es gut zu beschreiben, sagen Sie das und bitten Sie um eine kurze, bezahlte Discovery-Phase statt eines vollständigen Angebots. Ein Festpreisangebot, das auf Vermutungen beruht, versteckt die Unbekannten in seinem Risikoaufschlag; eine Discovery-Phase ersetzt die Vermutungen durch Fakten. Wenn Sie möchten, dass Entwickler Ihr Briefing lesen oder darauf antworten, können Sie es über unser Formular „Projekt starten“ schicken. ## Das Wichtigste in Kürze - Beschreiben Sie das Problem, die Nutzer und woran Erfolg zu erkennen ist, und lassen Sie die Lösung offen. - Integrations- und Datenarbeit wird leicht unterschätzt, also listen Sie jedes beteiligte System und jeden Datenbestand auf. - Nennen Sie einen Budgetrahmen und sagen Sie, welche Frist feststeht und warum. - Kennzeichnen Sie jede Anforderung als fest, bevorzugt oder offen, und fordern Sie Angebote in einer gemeinsamen Struktur an. - Beantworten Sie Fragen schriftlich und teilen Sie jede Antwort mit jedem Partner. ## FAQ ### Wie lang sollte ein Briefing für ein Softwareprojekt sein? Lang genug, um Problem, Nutzer, Systeme, Daten, Rahmenbedingungen, Budgetrahmen und Zeitplan abzudecken, was bei den meisten Projekten auf wenige Seiten passt. Wird es deutlich länger, beschreibt es vermutlich die Lösung statt des Problems. ### Sollte man das Budget mit Softwarepartnern teilen? Ja, als Rahmen. Ohne ihn schlagen Partner Projekte sehr unterschiedlicher Größe vor, und Sie können sie nicht vergleichen. Ein Rahmen erlaubt jedem Partner zu zeigen, was er darin umsetzen würde, und Ihnen ehrlich zu sagen, wenn er nicht reicht. ### Sollte man auf ein Briefing hin einen Festpreis verlangen? Nur wenn das Briefing die Arbeit detailliert genug beschreibt, um sie zu schätzen. Sind zentrale Fragen noch offen, bitten Sie um eine Discovery-Phase zum Festpreis oder um eine Schätzspanne mit genannten Annahmen, und legen Sie den Preis für die Umsetzung fest, sobald die Unbekannten geklärt sind. ## Starten Sie bei Ihrem Bedarf - [Website-Erstellung](https://sdk.enterprises/de/website-development) ## Passende Leistungen - [Individualsoftware](https://sdk.enterprises/de/services/product-engineering) - [Technisches Audit und Beratung](https://sdk.enterprises/de/services/consulting) ## Weiterlesen - [Discovery-Phase im Softwareprojekt: Was sie liefern sollte](https://sdk.enterprises/de/insights/what-a-paid-discovery-phase-should-deliver) - [Festpreis oder Time & Material: das passende Vertragsmodell](https://sdk.enterprises/de/insights/fixed-price-or-time-and-materials)