Software-Ausschreibung: So Werden Angebote Vergleichbar

Eine Software-Ausschreibung soll Anbieter vergleichbar machen. Die meisten erreichen das Gegenteil, weil sie eine Lösung so detailliert vorschreiben, dass die Antwort eingeengt wird, und zugleich genau die Angaben weglassen, die man zur Kalkulation bräuchte. Das Ergebnis sind fünf Angebote, die eine ganze Größenordnung auseinanderliegen, formal alle korrekt, und keines davon misst dasselbe.

Die übliche Diagnose lautet, die Anbieter wichen aus. Gelegentlich stimmt das. Weit häufiger hat das Dokument nach einer Zahl gefragt, die sich aus seinem Inhalt gar nicht ableiten ließ, und jeder Anbieter hat die Lücken mit anderen Annahmen gefüllt.

Der Test, ob Ihre Ausschreibung funktioniert: Könnten zwei verschiedene Anbieter sie lesen und im Wesentlichen zum selben Umfang kommen? Wenn dort „Benutzerverwaltung“ steht, ohne Hinweis darauf, wie viele Rollen es gibt, ob Berechtigungen je Datensatz abweichen oder ob eine Anbindung an ein vorhandenes Verzeichnis nötig ist, kalkuliert der eine eine Woche und der andere zwei Monate. Beide antworten ehrlich. Vergleichen können Sie die beiden nicht.

Warum eine Funktionsliste der falsche Ausgangspunkt ist

Eine Liste von Funktionen sagt dem Anbieter, was Sie entschieden haben, nicht was Sie brauchen. Das ist deshalb wichtig, weil die Entscheidung falsch sein kann und derjenige, der das bemerkt, innerhalb der von Ihnen vorgegebenen Struktur keine Möglichkeit hat, es auszusprechen.

Sie verbirgt außerdem genau die Angaben, die den Preis treiben. Der Aufwand in der Softwareentwicklung steckt in den unangenehmen Teilen: wie viele fremde Systeme angebunden werden, wie viele Bestandsdaten zu migrieren sind und in welchem Zustand sie sich befinden, wie viele unterschiedliche Nutzertypen mit abweichenden Rechten es gibt und welche regulatorischen Pflichten gelten. Eine Funktionsliste kann sehr lang sein und nichts davon enthalten.

Die Alternative ist nicht Unschärfe. Beschreiben Sie das Problem genau, nennen Sie die Randbedingungen, die wirklich feststehen, und lassen Sie das Angebot den Lösungsweg erklären. Sie bekommen unterschiedliche Antworten, und die Unterschiede sind dann aussagekräftig statt bloßes Rauschen.

Was in eine Software-Ausschreibung wirklich gehört

Das geschäftliche Problem und die Definition von Erfolg. Was heute passiert, was stattdessen passieren soll, und woran Sie erkennen werden, dass es funktioniert hat. Anbieter nutzen das, um den Umfang infrage zu stellen, und das ist das Wertvollste, was sie in dieser Phase tun können.

Mengen und Größenordnungen, mit Zahlen. Nutzer, Transaktionen, Datensätze, erwartetes Wachstum. Allein das beseitigt einen großen Teil der Streuung zwischen den Angeboten.

Systeme, an die angebunden werden muss, namentlich, mit dem Hinweis, ob es für jedes davon eine dokumentierte Schnittstelle gibt. Eine einzige Altanbindung ohne Dokumentation kann teurer werden als alles Übrige zusammen.

Daten, die Sie bereits haben. Wie viele, wo sie liegen und in welchem Zustand sie sind. Die Migration ist regelmäßig die am stärksten unterschätzte Position im ganzen Projekt.

Randbedingungen, die wirklich feststehen. Regulatorische Pflichten, ein vorgeschriebener Hosting-Standort, ein vorhandener Identitätsanbieter, ein unverrückbarer Termin. Sagen Sie dazu, was hart ist und was Wunsch, denn harte Vorgaben preisen Anbieter defensiv ein.

Was Sie ausdrücklich nicht wollen. Dinge klar auszuschließen ist eine der billigsten Möglichkeiten, die Streuung zwischen den Angeboten zu verringern.

Ihren Budgetrahmen. Ihn zurückzuhalten bringt keinen niedrigeren Preis. Es bringt Angebote, die auf ein Budget zugeschnitten sind, das niemand kennt, und die anschließend neu gemacht werden müssen. Eine Spanne erlaubt es Anbietern, Ihnen zu sagen, was darin machbar ist. Unser Leitfaden zu den Kosten individueller Softwareentwicklung beschreibt, was die einzelnen Bänder kaufen.

Die Fragen, die Anbieter unterscheiden

Stellen Sie weniger, aber bessere Fragen. Diese verraten mehr als eine Compliance-Matrix mit hundert Zeilen.

Was würden Sie zuerst bauen, und warum? Die Reihenfolge zeigt, ob das Problem verstanden wurde oder nur das Dokument.

Was ist daran das größte Risiko, und wie würden Sie es verringern? Ein Anbieter, der ein echtes Risiko benennt, ist vertrauenswürdiger als einer, der gar keines meldet.

Wer genau macht die Arbeit? Namen, Erfahrungsstufe und wie viel ihrer Zeit. Ein Angebot, geschrieben von Leuten, die es später nicht umsetzen, ist eine vertraute Enttäuschung.

Was passiert, wenn sich der Umfang ändert? Er wird sich ändern. Die Antwort zeigt Ihnen, wie die Zusammenarbeit unter Druck funktioniert, und das zählt mehr als der Tagessatz.

Was brauchen Sie von uns? Projekte scheitern mindestens ebenso oft an der Verfügbarkeit auf Kundenseite wie an der Fähigkeit des Anbieters, und wer das ausspricht, beschreibt die Wirklichkeit, statt zu verkaufen.

Was gehört uns am Ende? Quellcode, Infrastruktur, Konten, Daten. Halten Sie das schriftlich fest, bevor Sie auswählen, nicht danach.

Die Antworten lesen

Das billigste Angebot spiegelt meist die engste Auslegung des Umfangs wider, nicht die höchste Effizienz, und die Lücke taucht als Änderungsantrag wieder auf, sobald die Arbeit begonnen hat.

Schauen Sie darauf, wo ein Anbieter seine Mühe investiert hat. Ein Angebot, das den Großteil seiner Länge auf die Schnittstellen und die Datenmigration verwendet, hat verstanden, wo die Schwierigkeit liegt. Eines, das sie auf Methodik und Teamfotos verwendet, hat sich mit dem Problem nicht befasst.

Werten Sie ungefragte Einwände als gutes Zeichen. Ein Anbieter, der sagt, ein Teil Ihres Umfangs sei überflüssig, oder eine genannte Vorgabe koste mehr, als sie wert ist, macht genau die Arbeit, die Sie eigentlich wollen. Anbieter, die allem zustimmen, sind leichter zu lesen und schlechter in der Zusammenarbeit.

Und prüfen Sie, ob jedes Angebot dieselbe Frage beantwortet. Wo zwei um den Faktor drei auseinanderliegen, hat eines etwas angenommen, das im Dokument nicht stand, und herauszufinden welches ist nützlicher als jede Bewertungsmatrix.

Wann Sie besser keine durchführen

Wenn die Arbeit klein ist oder explorativ, oder wenn Sie noch nicht wissen, was Sie brauchen, ist eine Ausschreibung das falsche Instrument. Sie kostet beide Seiten Wochen und erzeugt einen falschen Eindruck von Genauigkeit.

Dafür ist ein bezahltes Discovery-Projekt in der Regel besser: ein kurzes Stück Arbeit, das eine Spezifikation hervorbringt, mit der Sie dann an den Markt gehen können, oder das zeigt, dass sich die Sache nicht lohnt. Beide Ergebnisse sind besser als ein Wettbewerb um einen Umfang, den niemand definieren konnte. Die Disziplin beim Zuschnitt aus unserem Leitfaden zur MVP-Softwareentwicklung gilt hier unmittelbar.

Mecanik antwortet auf Ausschreibungen und hilft Organisationen auch dabei, sie zu schreiben, als Teil unserer Arbeit in der Softwareentwicklung. Die Dokumente, die gute Angebote hervorbringen, sind durchweg die kürzeren mit echten Zahlen darin.

Häufig gestellte Fragen

Was gehört in eine Software-Ausschreibung? Das geschäftliche Problem und die Definition von Erfolg, Mengen und Größenordnungen mit echten Zahlen, namentlich genannte Systeme für die Anbindung samt Angabe, ob es dokumentierte Schnittstellen gibt, der Zustand der zu migrierenden Daten, welche Randbedingungen wirklich feststehen, was ausdrücklich nicht dazugehört, und ein Budgetrahmen.

Soll ich mein Budget in die Ausschreibung schreiben? Ja. Es zurückzuhalten bringt keinen niedrigeren Preis, sondern Angebote, die auf ein Budget zugeschnitten sind, das niemand kennt, und die anschließend neu gemacht werden müssen. Eine genannte Spanne erlaubt es Anbietern, Ihnen zu sagen, was darin realistisch machbar ist, und macht die Antworten vergleichbar.

Warum liegen Angebote für dieselbe Software so weit auseinander? Meist weil das Dokument Lücken gelassen hat und jeder Anbieter sie mit anderen Annahmen gefüllt hat. Eine Zeile wie „Benutzerverwaltung“ ohne Angabe zur Zahl der Rollen, zu Rechten je Datensatz oder zur Verzeichnisanbindung lässt sich ehrlich mit einer Woche oder mit zwei Monaten kalkulieren. Die Streuung ist eine Eigenschaft der Ausschreibung, nicht der Anbieter.

Welche Fragen zeigen einen guten Softwareanbieter? Was er zuerst bauen würde und warum, was er für das größte Risiko hält und wie er es verringern würde, wer genau die Arbeit macht und mit wie viel seiner Zeit, wie mit Änderungen am Umfang umgegangen wird, was er von Ihnen braucht, und was Ihnen am Ende gehört.

Wann sollte ich keine Ausschreibung machen? Wenn die Arbeit klein oder explorativ ist oder Sie noch nicht definieren können, was Sie brauchen. Ein Wettbewerb um einen undefinierten Umfang kostet beide Seiten Wochen und erzeugt Scheingenauigkeit. Ein bezahltes Discovery-Projekt, das eine Spezifikation hervorbringt oder zeigt, dass das Vorhaben sich nicht lohnt, ist das bessere Instrument.