Vermeiden Sie Überschreitungen von 50 % und mehr: Ausschreibungsunterlagen für die Softwareentwicklung
Vermeiden Sie Überschreitungen von 50 % und mehr: Ausschreibungsunterlagen für die Softwareentwicklung Eine Ausschreibung für die Softwareentwicklung erhält das beste Angebot eines Anbieters, wenn sie das angestrebte Geschäftsergebnis, einen realistischen Budgetrahmen und einen phasenweisen Lieferplan mit einem MVP als erstem Schritt nennt.
Eine Ausschreibung für die Softwareentwicklung erhält das beste Angebot eines Anbieters, wenn sie das angestrebte Geschäftsergebnis, einen realistischen Budgetrahmen und einen phasenweisen Lieferplan mit einem MVP als erstem Schritt nennt. Sie sollte von jedem Anbieter verlangen, seinen technischen Ansatz, die Qualifikationen des Teams, die Liefermeilensteine und die Sicherheitszusagen schriftlich darzulegen. Bewerten Sie die Antworten anhand eines gewichteten Bewertungsrasters, das die technische Eignung und Sicherheit höher gewichtet als den niedrigsten genannten Preis, und orientieren Sie sich dabei an den Empfehlungen von Experten zu Kriterien für die Auswahl von Softwareanbietern.
Die wichtigsten Erkenntnisse
Eine gut strukturierte Ausschreibung für die Softwareentwicklung nennt klar Geschäftsergebnisse, Umfang und Anforderungen, um detaillierte, realistische Angebote zu erhalten, die mit den Projektzielen und Sicherheitsstandards übereinstimmen.
| Punkt | Details |
|---|---|
| Klare Problembeschreibung | Definieren Sie das Geschäftsergebnis und messbare Erfolgskennzahlen, damit Anbieter relevante Lösungen liefern können. |
| Eindeutiger Umfang und Abnahmekriterien | Legen Sie den Umfang, den ausgeschlossenen Umfang, die Annahmen und die Abnahmekriterien mit konkreten Leistungsbenchmarks fest. |
| Technische und sicherheitsbezogene Bewertung | Verwenden Sie ein gewichtetes Bewertungsraster, das technische Eignung, Sicherheit und nachgewiesene Erfahrung stärker gewichtet als den Preis allein. |
| Phasenweiser Lieferplan | Skizzieren Sie einen phasenweisen Ansatz, der mit einem MVP beginnt, um die Fähigkeiten des Anbieters vor einer vollständigen Beauftragung zu prüfen. |
| Ridiculous Engineering-Ansatz | Nutzen Sie die Dienstleistungen von Ridiculous Engineering für die fachkundige Erstellung von Ausschreibungsunterlagen, die Bewertung von Angeboten oder Unterstützung bei der Projektdurchführung. |
Inhaltsverzeichnis
- Was in eine Ausschreibung für die Softwareentwicklung gehört
- Eine praxisnahe Struktur und Vorlage für eine Ausschreibung, die Sie noch heute versenden können
- Wie Sie Angebote bewerten, ohne zu raten
- Sicherheits- und Anforderungen an die Lieferkette integrieren
- Zeitplan, Kostenerwartungen und zu vermeidende Fehler
- Rechtliche und vertragliche Überlegungen
- Wie Ridiculous Engineering helfen kann
- Quellen
- FAQ
Was in eine Ausschreibung für die Softwareentwicklung gehört
Eine klare Problembeschreibung bildet das Rückgrat des Dokuments. Formulieren Sie das Geschäftsergebnis, das Sie erreichen möchten, und verknüpfen Sie es mit einer messbaren Erfolgskennzahl – etwa der Verkürzung der manuellen Bearbeitungszeit, der Verringerung der Anzahl von Supporttickets oder dem Erreichen einer bestimmten Konversionsrate. Anbieter verfassen präzisere Angebote, wenn sie wissen, wie „fertig“ in geschäftlichen und nicht nur in funktionalen Begriffen aussieht.
Als Nächstes folgt der Umfang. Unklarheiten an dieser Stelle führen zu mehr Budgetstreitigkeiten als alles andere in diesem Dokument. Legen Sie genau fest, was zum Umfang gehört, was ausdrücklich ausgeschlossen ist und welche Annahmen Sie zu Daten, Integrationen und bestehenden Systemen treffen. Verknüpfen Sie jede größere Funktion mit Abnahmekriterien, damit niemand sechs Monate später darüber streitet, was „fertig“ bedeutet.
Funktionale Anforderungen lassen sich am besten als kurze User Stories statt als dichte Funktionslisten formulieren. Einige Beispiele:
- Als Betriebsleiter kann ich die Lagerbestände in Echtzeit an allen Lagerstandorten einsehen.
- Als Kunde kann ich mein Passwort zurücksetzen, ohne den Support kontaktieren zu müssen.
- Als Administrator kann ich nach Datumsbereich und Abteilung gefilterte Nutzungsberichte exportieren.
Nichtfunktionale Anforderungen verdienen dieselbe Spezifität. Vage Formulierungen wie „das System sollte schnell sein“ geben Anbietern keine Grundlage für ein Angebot. Diese Zahlen werden später zu Ihren Abnahmetests, also legen Sie sie jetzt richtig fest.
Schließlich ist die vertragliche Ebene ebenso wichtig wie die technische. Regeln Sie das Eigentum am geistigen Eigentum (Sie wollen den Code, nicht nur eine Nutzungslizenz), Supportzeiten, Service-Level-Vereinbarungen, Fristen für die Behebung von Mängeln und einen definierten Prozess zur Änderungskontrolle bei Anpassungen des Projektumfangs während des Projekts. Wenn Sie diesen Abschnitt auslassen, werden aus „schnellen Lösungen“ schnell Abrechnungsstreitigkeiten.
Eine praxisnahe Struktur und Vorlage für eine Ausschreibung, die Sie noch heute versenden können
Halten Sie das Kerndokument schlank und verschieben Sie ergänzende Materialien in Anhänge. Ein Anbieter, der zehn Angebote prüft, wird die ersten drei Seiten aufmerksam lesen und den Rest überfliegen. Stellen Sie daher die wichtigsten Inhalte an den Anfang.
- Zusammenfassung für die Geschäftsleitung: ein Absatz zum Geschäftsproblem und zum gewünschten Ergebnis.
- Ziele: die messbaren Ziele, die das Projekt erreichen muss.
- Umfang: im Umfang enthalten, nicht im Umfang enthalten und Annahmen.
- Anforderungen: funktionale und nichtfunktionale Anforderungen, wie oben beschrieben.
- Liefergegenstände: was und wann übergeben wird.
- Abnahmekriterien: wie Sie jeden Liefergegenstand überprüfen werden.
- Preisvorlage: ein einheitliches Format, das jeder Anbieter auf dieselbe Weise ausfüllt.
- Bewertungskriterien: anhand welcher Kriterien die Anbieter bewertet werden.
- Zeitplan: Fristen für Antworten, Zeitfenster für Fragen und Antworten sowie der voraussichtliche Projektstart.
- Rechtliche Bestimmungen: geistiges Eigentum, Vertraulichkeit, Haftung und Kündigungsklauseln.
Architekturdiagramme, anonymisierte Beispieldaten, API-Spezifikationen und Benutzerprofile gehören in die Anhänge, nicht in den Hauptteil. So bleibt die Ausschreibung im Kern übersichtlich und bietet seriösen Anbietern dennoch die technische Tiefe, die sie für eine genaue Aufwandsschätzung benötigen.
Ein Beispiel für einen Abschnitt zu Abnahmekriterien: „Das Reporting-Dashboard muss gefilterte Ergebnisse für Datensätze mit bis zu 50.000 Datensätzen innerhalb von 2 Sekunden laden und ohne Datenverlust als CSV exportieren.“ Das ist spezifisch genug, um getestet zu werden, schreibt jedoch nicht die Implementierung vor.
Bitten Sie für die Preisgestaltung jeden Anbieter, dieselbe Tabelle auszufüllen: Position, Beschreibung, geschätzte Stunden, Stunden- oder Festpreis und Gesamtsumme. Eine einheitliche Formatierung ist die einzige Möglichkeit, Angebote direkt miteinander zu vergleichen, statt zu raten, welche Leistungen wo enthalten sind.
Die meisten gut durchgeführten Ausschreibungen bleiben bei weniger als 15 Seiten Kerninhalt zuzüglich Anhängen, bei typischen Antwortfristen von einigen Wochen. Kürzere Fristen begünstigen Anbieter, die ihre Schätzungen zur Risikovermeidung aufblähen, während längere Fristen selten bessere Antworten hervorbringen, sondern lediglich spätere.
So bewerten Sie Angebote, ohne zu raten
Eine gewichtete Bewertungsmatrix macht aus der Angebotsbewertung eine nachvollziehbare Entscheidung statt einer Bauchentscheidung. Beachten Sie, dass die Kosten weit unten und nicht oben stehen. Das ist beabsichtigt. Best Practices im Beschaffungswesen warnen davor, den günstigsten Anbieter auszuwählen bei komplexen Softwareprojekten, da sich zu niedrige Preise später häufig in verpassten Fristen oder technischen Sicherheitsschulden zeigen.
Bauen Sie Ihre Bewertungsmatrix um Zeilen auf, die von den Anbietern konkrete Angaben verlangen:
- Passung der Architektur: Entspricht der vorgeschlagene Technologie-Stack Ihren Anforderungen an Skalierung und Integration?
- Nachweise für vergleichbare Projekte: Haben sie etwas Vergleichbares entwickelt, und können sie dies belegen?
- Realismus des Bereitstellungsplans: Werden die Meilensteine durch eine glaubwürdige Aufschlüsselung untermauert oder lediglich durch ein Gantt-Diagramm mit gerundeten Zahlen?
- Vorgehen bei Qualitätssicherung und Tests: Wie sieht ihr Ansatz für Testabdeckung aus, nicht nur ihre Toolauswahl?
- Reifegrad von DevOps und CI/CD: Wie liefern sie Code aus und wie häufig?
- Sicherheitskontrollen und SBOM-Bereitschaft: Können sie eine SBOM erstellen, und tun sie das bereits?
- Referenzen und finanzielle Stabilität: Wird dieser Anbieter in 18 Monaten noch am Markt sein?
Sobald die Bewertungen vorliegen, führen Sie mit Ihren zwei oder drei besten Finalisten einen kurzen Discovery-Workshop oder eine klärende Fragerunde durch. Hier lernen Sie am meisten. Anbieter, die präzise Fragen zu Ihrem Datenmodell stellen oder einen unrealistischen Zeitplan infrage stellen, sind meist diejenigen, die Ihnen auch mitten im Projekt die Wahrheit sagen – und nicht nur beim Kick-off. Anbieter, die allem zustimmen, ohne auch nur eine einzige klärende Frage zu stellen, sollten Sie aus den falschen Gründen noch einmal genauer prüfen.
Bitten Sie jeden Finalisten um Architekturdiagramme und einen Meilenstein-basierten Implementierungszeitplan und bewerten Sie anschließend die Realisierbarkeit statt der Vollständigkeit. Ein Angebot, das in einem Bereich Unsicherheit einräumt und erklärt, wie diese reduziert werden soll, ist meist überzeugender als eines, das auf dem Papier Perfektion verspricht. Unser eigener 12-Punkte-Leitfaden zur Auswahl eines Unternehmens für individuelle Softwareentwicklung geht noch ausführlicher darauf ein, falls Sie eine zweite Orientierungshilfe wünschen.
Sicherheits- und Lieferkettenanforderungen verankern
Sicherheit gehört als bewertete Anforderung in die RFP und nicht als nachträglicher Zusatz in die rechtlichen Bestimmungen. Verweisen Sie auf das NIST Secure Software Development Framework, auch bekannt als SSDF oder NIST SP 800-218, und bitten Sie Anbieter, ihre Praktiken an den Kategorien Prepare, Protect, Produce und Respond auszurichten und dies zu bestätigen, anstatt eine bestimmte Toolchain zu verlangen. Ergebnisorientierte Anforderungen sind langlebiger als Tool-Listen, da sich die Tools alle paar Jahre ändern, die Ergebnisse jedoch nicht.
Verlangen Sie eine Software-Stückliste, eine dokumentierte Richtlinie zur Meldung und Behebung von Sicherheitslücken, Nachweise über Sicherheitskontrollen in der CI/CD-Pipeline sowie einen festgelegten Behebungszeitplan für nach dem Go-live entdeckte Sicherheitslücken. CISA’s Software Acquisition Guide empfiehlt, Lieferanten mithilfe von Beschaffungsklauseln für Sicherheitsergebnisse verantwortlich zu machen. Diese Klauseln jetzt in Ihre RFP aufzunehmen, ist deutlich günstiger, als sie nach einem Sicherheitsvorfall auszuhandeln. Dieselben Empfehlungen legen nahe, Entscheidungen zur Risikoakzeptanz zu dokumentieren und bei einer vollständigen Nichterfüllung einer Kontrolle durch einen Anbieter von einer Führungskraft genehmigen zu lassen. So gibt es eine klar benannte verantwortliche Person für diesen Zielkonflikt – statt sechs Monate später nur ratlos mit den Schultern zu zucken.
Profi-Tipp: Bitten Sie Anbieter um eine Beispiel-SBOM aus einem früheren Projekt und nicht nur um das Versprechen, eine solche erstellen zu können. Wenn sie noch nie eine erstellt haben, ist auch das eine nützliche Information.
Bewerten Sie Sicherheit in einer eigenen Zeile des Bewertungsrasters und verlangen Sie Nachweise: Beispielrichtlinien, eine Beschreibung eines früheren Vorfalls und seiner Bearbeitung oder – sofern vorhanden – eine Sicherheitsbewertung durch Dritte.
Zeitplan, Kostenerwartungen und zu vermeidende Fehler
Ein realistischer RFP-Zeitplan umfasst sechs Phasen: Vorbereitung, Anbieter-Fragerunde, Zeitraum für die Angebotsabgabe, Bewertung, Verhandlung und Kick-off. Die meisten Organisationen unterschätzen die Phasen Bewertung und Verhandlung, die zusammen oft genauso lange dauern wie der Zeitraum für die Angebotsabgabe.
Die Veröffentlichung einer Budgetspanne zu Beginn spart allen Beteiligten Zeit. Anbieter, die nicht innerhalb Ihrer Spanne liefern können, scheiden aus eigenem Antrieb aus, bevor sie ein 20-seitiges Angebot verfassen, und Sie vermeiden das unangenehme Gespräch, in dem sich ein vielversprechendes Angebot als dreimal so teuer wie Ihr Budget herausstellt. Jedes dritte IT-Projekt überschreitet das Budget um 50 % oder mehr – genau die Art von Überschreitung, die eine klarere Abgrenzung des Leistungsumfangs und die Veröffentlichung einer Budgetspanne verhindern sollen.
Häufige Fehler, die Sie vermeiden sollten:
- Mehrdeutige Abnahmekriterien, die offenlassen, wann etwas als „fertig“ gilt.
- Team-Lebensläufe auszulassen, sodass Sie die Unternehmensbroschüre statt der tatsächlichen Personen bewerten, die Ihren Code schreiben werden.
- Sicherheit wie eine Checkliste statt wie eine bewertete Anforderung zu behandeln.
- Liefermeilensteine wegzulassen und damit Ihr einziges Frühwarnsystem zu entfernen.
- Implementierungsdetails zu stark vorzugeben und dadurch versehentlich eine schlechtere technische Lösung zu diktieren.
Legen Sie ein erstes MVP oder eine Phase 1 rund um ein messbares Ergebnis fest. Das ist der günstigste Weg, die tatsächliche Umsetzungskompetenz eines Anbieters zu prüfen, bevor Sie etwas Längerfristiges unterzeichnen.
Rechtliche und vertragliche Aspekte
Der Abschnitt mit den rechtlichen Bestimmungen einer RFP legt Erwartungen fest, deren spätere Neuverhandlung weitaus teurer ist, als sie von Anfang an richtig zu formulieren. Beim Eigentum an geistigem Eigentum sollte unmissverständlich festgehalten werden, dass Ihnen der im Rahmen des Vertrags erstellte Code, die Designs und die Dokumentation gehören – nicht lediglich eine Nutzungslizenz. Klauseln zu Vertraulichkeit und Datenverarbeitung sind wichtiger denn je, wenn ein Anbieter auf Kundendaten oder proprietäre Geschäftslogik zugreift.
Die Bestimmungen zu Haftung und Schadloshaltung sollten dem tatsächlichen Risikoprofil des Projekts entsprechen. Ein Anbieter, der ein internes Berichtstool entwickelt, trägt ein anderes Risiko als ein Anbieter, der die Zahlungsabwicklung übernimmt; Ihre Vertragsformulierung sollte dies entsprechend abbilden. Kündigungsklauseln müssen klar festlegen, was mit Code, Dokumentation und Zugangsdaten geschieht, wenn eine der Parteien das Projekt vorzeitig beendet, denn eine unklare Ausstiegsklausel macht aus einer schlechten Anbieterwahl schnell einen Rechtsstreit.
Service-Level-Agreements gehören in den Vertrag und nicht nur in die RFP – mit konkreten Reaktionszeiten für verschiedene Schweregrade von Fehlern und einem definierten Prozess für Änderungen des Leistungsumfangs nach Beginn der Arbeiten. Die Forschung des GAO zur agilen Beschaffung weist darauf hin, dass Programme auf Basis iterativer Business Cases und kontinuierlicher Bewertung Risiken besser steuern als feste Verträge, bei denen alles auf einmal vereinbart wird. Das sollten Sie bei der Strukturierung von Zahlungsmeilensteinen und der Änderungssteuerung berücksichtigen. Unser Leitfaden zur öffentlichen Beschaffung enthält beispielhafte Vertragsformulierungen, falls Sie eine Ausgangsvorlage statt einer leeren Seite wünschen.
Wie Ridiculous Engineering helfen kann
Eine starke RFP zu verfassen, ist ein Projekt. Sie umzusetzen, ist ein anderes – und genau darauf kommt es an. Ridiculous Engineering bietet Teams Unterstützung beim Erstellen von RFPs und bei der unabhängigen Bewertung von Angeboten oder kann von Anfang an als Umsetzungspartner mit Senior Engineers und Sicherheitsexpertise fungieren. Ganz gleich, ob Sie eine zweite Einschätzung bei der Anbieterbewertung oder ein Team für die Umsetzung benötigen: Beginnen Sie mit Individueller Softwareentwicklung oder nehmen Sie über Softwareberatung und Unterstützung bei der Umsetzung Kontakt auf, um Ihre aktuelle Situation zu besprechen.
Quellen
- Secure Software Development Framework | CSRC
- Software Acquisition Guide: Für staatliche Unternehmenskunden | CISA
- Beschaffung von Verteidigungssoftware: Änderungen an Anforderungen, Aufsicht und benötigten Tools für Waffenprogramme | U.S. GAO
FAQ
Was ist der Unterschied zwischen RFP und RFQ?
Eine RFP (Request for Proposal, Aufforderung zur Angebotsabgabe) fordert Anbieter auf, einen technischen Ansatz und eine Lösung für ein Geschäftsproblem vorzuschlagen, während eine RFQ (Request for Quote, Preisanfrage) Anbieter auffordert, eine Lösung zu bepreisen, die Sie bereits vollständig spezifiziert haben. Verwenden Sie eine RFP, wenn Anbieter ein Problem kreativ lösen sollen, und eine RFQ, wenn die Anforderungen feststehen und der Preis ausschlaggebend ist.
Was sind die 7 Schritte einer RFP?
Die Definitionen variieren, aber eine gängige Variante umfasst folgende Schritte: Ziele definieren, Anforderungen und Umfang ausarbeiten, die RFP veröffentlichen, Fragen und Antworten mit den Anbietern durchführen, Angebote sammeln, Antworten bewerten und Punkte vergeben sowie anschließend verhandeln und einen Anbieter auswählen. Einige Organisationen ergänzen nach der Vertragsunterzeichnung einen formellen Projektauftakt als achten Schritt.
Wie viel kostet eine RFP?
Darauf gibt es keine pauschale Antwort, da die Kosten von der intern für die Ausarbeitung und Bewertung aufgewendeten Zeit abhängen und nicht von einer an irgendjemanden gezahlten Gebühr. Organisationen, die zu Beginn auf eine klare Eingrenzung des Umfangs verzichten, zahlen häufig indirekt durch Überschreitungen seitens der Anbieter. Deshalb sind eine veröffentlichte Budgetspanne und ein phasenweiser MVP-Ansatz so wichtig.
Welche häufigen Fehler bei RFPs sollten vermieden werden?
Zu den häufigsten Fehlern gehören vage Abnahmekriterien, das Überspringen der Qualifikationsprüfung des Anbieter-Teams, die Behandlung von Sicherheit als nachträglichen Aspekt statt als bewertete Kategorie sowie das vollständige Weglassen von Liefermeilensteinen. Eine weitere häufige Falle ist die übermäßige Spezifizierung von Implementierungsdetails, da Anbieter dadurch auf eine technisch schlechtere Lösung festgelegt werden können, als sie sie andernfalls vorgeschlagen hätten.