Angebote und Proposals richtig anfordern
Die Qualität einer Kostenschätzung hängt direkt von der Qualität des Briefings ab. Vage Anforderungen führen zu vagen Schätzungen – mit Sicherheitszuschlägen, die das Budget unnötig belasten. Dieser Artikel zeigt, wie Sie Anfragen so formulieren, dass Sie präzise, vergleichbare Angebote erhalten.
1. Warum Schätzungen oft ungenau sind
| Ursache | Auswirkung | Lösung |
|---|---|---|
| Unklare Anforderungen | Hoher Risikozuschlag (20–40 %) | Detailliertes Briefing |
| Fehlende Priorisierung | Entwickler schätzt Maximalumfang | Must-have vs. Nice-to-have trennen |
| Keine technischen Rahmenbedingungen | Falsche Annahmen → Fehlkalkulation | Bestehende Systeme dokumentieren |
| Zu wenig Kontext | Entwickler kennt Geschäftslogik nicht | Fachlichen Hintergrund erklären |
| Kein Zeitrahmen genannt | Entwickler kalkuliert konservativ | Gewünschten Zeitrahmen angeben |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
2. Das perfekte Briefing: 10 Pflichtinformationen
| Nr. | Information | Beispiel |
|---|---|---|
| 1 | Geschäftsziel | „Kunden sollen online Bestellungen aufgeben können" |
| 2 | Zielgruppe | „200 B2B-Kunden, Desktop und Tablet" |
| 3 | Feature-Liste mit Priorisierung | Must: Login, Bestellung; Nice: Empfehlungen |
| 4 | Bestehende Systeme und Integrationen | „ERP: SAP Business One, CRM: HubSpot" |
| 5 | Designvorgaben | „Corporate Design liegt vor" oder „Design wird benötigt" |
| 6 | Technische Vorgaben (falls vorhanden) | „Muss auf Azure laufen" oder „Keine Vorgaben" |
| 7 | Zeitrahmen | „Go-Live bis Q1 2026" |
| 8 | Budget-Rahmen (falls möglich) | „Budget liegt bei 80.000–120.000 €" |
| 9 | Entscheidungsprozess | „CTO entscheidet, 2 Wochen Feedbackschleife" |
| 10 | Wartung und Support | „Langfristiger Support gewünscht" |
3. Budget-Rahmen nennen – ja oder nein?
Pro Budget nennen:
- Entwickler kann realistisch beraten, was innerhalb des Budgets möglich ist
- Vermeidet Zeitverschwendung bei großer Diskrepanz
- Führt zu passgenauen Angeboten
Contra Budget nennen:
- Risiko, dass jedes Angebot das volle Budget ausschöpft
- Weniger Verhandlungsspielraum
Empfehlung: Nennen Sie eine Budget-Bandbreite statt einen Fixbetrag. „Unser Budget liegt zwischen 80.000 und 120.000 €" gibt Orientierung, ohne einen Festpreis vorzugeben.
4. Angebote systematisch anfordern
RFP-Struktur (Request for Proposal)
| Abschnitt | Inhalt |
|---|---|
| Unternehmensvorstellung | Wer Sie sind, was Sie tun |
| Projekthintergrund | Warum dieses Projekt, welches Problem wird gelöst |
| Anforderungen | Funktionale und nicht-funktionale Anforderungen |
| Technische Rahmenbedingungen | Bestehende Infrastruktur, Integrationen |
| Erwarteter Lieferumfang | Was genau soll geliefert werden |
| Zeitrahmen | Gewünschter Start und Go-Live |
| Bewertungskriterien | Wie Sie Angebote vergleichen werden |
| Geforderte Angebotsstruktur | Was das Angebot enthalten muss |
Diese Angaben im Angebot einfordern
Bitten Sie jeden Anbieter um folgende Informationen:
1. Aufwandsschätzung in Stunden oder Tagen (pro Phase/Feature)
2. Stundensatz/Tagessatz nach Rolle (zur Einordnung helfen marktübliche IT-Gehalts- und Stundensatz-Daten) [1]
3. Technologievorschlag mit Begründung
4. Teamzusammensetzung
5. Inkludierte und ausgeschlossene Leistungen
6. Zeitplan mit Meilensteinen
7. Annahmen und Voraussetzungen
8. Zahlungsbedingungen
9. Gewährleistung und Support-Optionen
10. Referenzprojekte
5. Angebote validieren
Plausibilitätscheck
| Prüfpunkt | Warnsignal |
|---|---|
| Aufwand pro Feature | Unter 1 Tag für komplexe Features |
| Gesamtaufwand | Weicht stark von anderen Angeboten ab (>30 %) |
| Fehlende Positionen | Testing, PM, Deployment nicht aufgeführt |
| Keine Annahmen dokumentiert | Risiko von Nachforderungen |
| Zeitplan unrealistisch | Kürzer als technisch sinnvoll |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
Vergleichstabelle
| Feature/Phase | Anbieter A (Tage) | Anbieter B (Tage) | Anbieter C (Tage) |
|---|---|---|---|
| Konzeption | |||
| Design | |||
| Frontend | |||
| Backend | |||
| Integrationen | |||
| Testing | |||
| PM | |||
| Gesamt | |||
| Preis |
Wenn ein Anbieter für dieselbe Leistung deutlich weniger Aufwand ansetzt, fehlt entweder etwas oder die Erfahrung ist vorhanden – klären Sie die Gründe.
Praxisbeispiel: Vom vagen zum präzisen Briefing
Vage Anfrage:
„Wir brauchen ein Kundenportal. Können Sie uns ein Angebot machen?"
Ergebnis: 3 Angebote zwischen 35.000 € und 180.000 €. Nicht vergleichbar.
Präzise Anfrage (mit Briefing):
„Wir suchen einen Entwicklungspartner für ein Kundenportal mit folgenden Anforderungen:
- Login für 500 B2B-Kunden (Active Directory)
- Dashboard mit Projektübersicht
- Dokumenten-Up/Download (max. 50 MB)
- Nachrichtenfunktion (kein Echtzeit-Chat)
- Rechnungsübersicht (Schnittstelle zu DATEV)
- Admin-Bereich für 10 interne Nutzer
- Budget: 80.000–120.000 €
- Go-Live: Q2 2026
- Design: Corporate Design wird als Figma-Dateien bereitgestellt"
Ergebnis: 3 Angebote zwischen 88.000 € und 115.000 €. Vergleichbar und realistisch.
Fazit und Einordnung
1. Zeit für ein gutes Briefing kann sich wirtschaftlich auszahlen: 1–2 Tage Vorarbeit können spätere Nachverhandlungen deutlich reduzieren.
2. Eine standardisierte Angebotsstruktur verbessert die Vergleichbarkeit: Einheitliche Formate machen Unterschiede sichtbarer.
3. Ein Budgetrahmen kann realistischere Angebote fördern: Er hilft Anbietern, ihre Annahmen passender einzugrenzen.
4. Die Trennung von Must-haves und Nice-to-haves erhöht die Steuerbarkeit: Entwickler können dadurch Prioritäten gezielter abbilden.
5. Angebote sollten aktiv validiert werden: Aufwandsunterschiede und fehlende Positionen verdienen vor einer Entscheidung vertiefte Prüfung.
Quellen
- StepStone – Gehälter IT-Softwareentwickler/in (2026-01-01)