Was Sie in ein Softwareentwicklungs-RFP aufnehmen sollten (und die 5 Klauseln, die Sie schützen)

Eine Softwareentwicklungsanfrage (RFP) ist das Dokument, das den Anbietern mitteilt, was Sie bauen müssen, warum und wie ihre Angebote beurteilt werden. Ein gutes Dokument enthält fünf Dinge: das Geschäftsproblem und die Ziele (keine Feature-Wunschliste), die bekannten Einschränkungen (Budgetrahmen, Fristen, bestehende Systeme, Compliance), einen klaren Rahmen mit den Inhalten und Inhalten, die Bewertungskriterien, nach denen Sie tatsächlich punkten werden, und die Vertragsbedingungen, die die Arbeit regeln. Der letzte Teil ist am wichtigsten und wird in den meisten RFPs ausgeblendet. Fünf Klauseln schützen Sie: IP-Eigentum, Akzeptanzkriterien, Übergabe und Dokumentation, Änderungskontrolle und Post-Launch-Support. Nehmen Sie diese in die Ausschreibung selbst auf, nicht in den Vertrag, den Sie aushandeln, nachdem Sie sich bereits entschieden haben, und Sie behalten Ihre Optionen offen, solange Sie sie noch haben.

Was beinhaltet ein gutes RFP für die Softwareentwicklung?

Der Aufbau ist einfach. Die Disziplin besteht darin, dass es um Ergebnisse und nicht um Lösungen geht.

Das Problem und das Ziel. Beschreiben Sie in einfachen Worten, was kaputt ist oder fehlt und wie Erfolg aussieht. Ein guter Anbieter schlägt den Bau vor; Du beschreibst das Ergebnis. Wenn Sie die Lösung im Detail spezifizieren, erfahren Sie nur, ob sie den Anweisungen folgen können.
Einschränkungen und Kontext. Budgetrahmen, Zeitplan, die Systeme, in die es integriert werden muss, die Daten, mit denen es in Berührung kommt, und etwaige regulatorische Verpflichtungen. Das Verschweigen des Budgets verschwendet die Zeit aller Beteiligten und führt zu unvergleichlichen Angeboten.
Umfang, explizit auf beiden Seiten. Listen Sie auf, was drin ist und, was genauso wichtig ist, was draußen. Die meisten Streitigkeiten beginnen in der Lücke zwischen dem, was die eine Seite als enthalten annahm, und dem, was die andere nicht tat.
Bewertungskriterien. Geben Sie an, wie Sie Vorschläge bewerten: relevante Erfahrung, technischer Ansatz, Team, Preis und die folgenden Bedingungen. Anbieter schreiben, was Sie messen.
Die Schutzklauseln. Die folgenden fünf. Sie in die Ausschreibung aufzunehmen und nicht in den späteren Vertrag, ist der größte Unterschied zwischen einem Käufer, der die Kontrolle behält, und einem Käufer, der dies nicht tut.

Dies ist auch das Dokument, in dem die Entscheidung Software erstellen oder kaufen bereits getroffen werden sollte. Ein RFP ist für einen Build. Wenn Sie immer noch Probleme von der Stange haben, klären Sie das zuerst.

Welche 5 Klauseln schützen Sie in einer Software-Ausschreibung?

Dies sind die Bedingungen, die darüber entscheiden, wer nach Abschluss des Projekts die Macht hat. Fordern Sie sie im Voraus an, während mehrere Anbieter die Arbeit noch haben möchten.

Klausel	Was es sichert	Was geht ohne schief
IP-Eigentum	Sie besitzen den Quellcode und die Assets sowie das Recht, diese zu ändern	Der Anbieter ist Eigentümer des Codes und Sie lizenzieren Ihr eigenes System von ihm zurück
Akzeptanzkriterien	Ein objektiver Test auf „erledigt“ vor der endgültigen Zahlung	Endloser Streit darüber, ob das Werk der Spezifikation entspricht
Übergabe und Dokumentation	Code, Anmeldeinformationen und Dokumente, die ein anderes Team übernehmen lassen	Sie sind eingesperrt, weil nur sie verstehen, wie es läuft
Änderungskontrolle	Ein vereinbarter Prozess und Tarif für Änderungen am Umfang	Überraschende Rechnungen oder Weigerung, Anpassungen vorzunehmen, wenn Sie erfahren
Support und Wartung	Definierte Reaktionszeiten und Kosten nach dem Start	Ein Live-System, bei dem niemand zur Reparatur verpflichtet ist

Warum gehört das Eigentum an geistigem Eigentum in die Ausschreibung und nicht in den Vertrag?

Denn das Kräfteverhältnis verschiebt sich, sobald Sie sich für einen Anbieter entscheiden. Bevor Sie unterschreiben, haben Sie mehrere Interessenten und einen sauberen Vergleich. Nach der Unterzeichnung haben Sie einen Lieferanten und ein halb fertiges System, das Sie nicht einfach verschieben können. Eine Klausel, deren Einigung in der ersten Woche nichts kostet, kann im sechsten Monat eine Neuverhandlung oder einen Neuaufbau kosten.

Der Besitz von geistigem Eigentum ist das deutlichste Beispiel. Erklären Sie deutlich, dass der gesamte Quellcode, alle Designressourcen und zugehörigen Materialien bei Bezahlung Ihr Eigentum werden und keine Restlizenz erforderlich ist, um sie auszuführen oder zu ändern. Seriöse Firmen akzeptieren dies problemlos. Ein Anbieter, der sich weigert, weil er Ihren Code behalten möchte, erzählt Ihnen etwas Nützliches, bevor Sie etwas ausgegeben haben.

Akzeptanz ist die zweite Klausel, deren Überspringen die Leute bereuen. Definieren Sie, was „abgeschlossen“ als einen im Voraus vereinbarten Test bedeutet, bei dem das System entweder besteht oder nicht. Ohne sie werden die letzten zehn Prozent eines Projekts zu einer Verhandlung und nicht zu einer Lieferung, und Ihre Abschlusszahlung ist der einzige verbleibende Hebel, um den Abschluss zu erzwingen.

Wie behalten Sie durch Übergabe, Änderungskontrolle und Support die Kontrolle?

Diese drei entscheiden darüber, ob Sie ein System besitzen oder lediglich Zugang an die Leute vermieten, die es gebaut haben.

Mit der Übergabe wird Eigentum Wirklichkeit. Der Vertrag sollte funktionierenden Quellcode in einem von Ihnen kontrollierten Repository, Bereitstellungsanweisungen, Umgebungskonfiguration, Anmeldeinformationen und Dokumentation erfordern, die gut genug ist, damit ein kompetentes Team, das das Projekt noch nie gesehen hat, es ausführen und erweitern kann. Fordern Sie es als Ergebnis mit einem eigenen Akzeptanzschritt an, nicht als Gefälligkeit am Ende. Wenn die Übergabe vage ist, sind Sie unabhängig von der IP-Klausel eingesperrt, da in der Praxis niemand anderes das System berühren kann.

Änderungskontrolle schützt beide Seiten. Ihre Anforderungen werden sich während des Baus ändern; das ist normal. Was Sie wollen, ist eine vereinbarte Vorgehensweise: wie eine Änderung beantragt wird, wie der Preis dafür ist und zu welchem Preis. Das Ziel besteht nicht darin, Veränderungen zu verhindern, sondern darin, die Überraschung zu beseitigen, sodass eine neue Anforderung zu einem kleinen, vorhersehbaren Gespräch und nicht zu einem Streit wird.

Unter Support und Wartung versteht man die Klausel für den Tag nach der Markteinführung, also an dem Tag, an dem die Software tatsächlich ihren Lebenszyklus beginnt. Definieren Sie, was passiert, wenn etwas kaputt geht: Reaktionszeiten, wer dafür verantwortlich ist, was es kostet und wie lange. Ein Live-System ohne Wartungspflicht ist eine Belastung, die auf ihren ersten Vorfall wartet. Hier zeigt sich auch der Unterschied zwischen Kaufberatung und Ergebniskauf. Ein Partner, der verantwortlich bleibt, sobald das System in Produktion ist, ist eine andere Sache als einer, der bei der Übergabe verschwindet.

Der praktische Imbiss

Behandeln Sie die Ausschreibung als den Ort, an dem Sie die Bedingungen festlegen, und nicht nur als den Ort, an dem Sie die Arbeit beschreiben. Die Vereinbarung der fünf Klauseln (IP-Eigentum, Akzeptanz, Übergabe, Änderungskontrolle, Support) kostet fast nichts, solange die Anbieter noch im Wettbewerb stehen, und eine Menge hinzuzufügen, sobald man sich für eine entschieden hat. Schreiben Sie sie frühzeitig ein, bewerten Sie Vorschläge, und Sie behalten die Kontrolle über das System, für dessen Aufbau Sie bezahlen. Wenn Sie ein zweites Paar Augen auf einen Brief haben möchten, bevor er rausgeht, sagen Sie uns, was Sie bauen; das ist ohnehin die Art von Abgrenzung, mit der unsere Arbeit im Bereich kundenspezifische Software beginnt.