Wir hatten für unseren Kunden von Grund auf eine maßgeschneiderte Lösung entwickelt. Kürzlich bat der Kunde um ein Angebot zur Integration mit einer Drittanbieter-Software.
Leider haben wir von ihrem Anbieter lediglich eine hastig geführte Demo dieser Software, einen Demo-API-Endpunkt und eine dürftige „Dokumentation“ mit Beispielen zum Aufrufen der API erhalten, ohne irgendeine Erklärung der zurückgegebenen Daten. Wir haben um mehr Dokumentation oder zumindest Demo-Zugriff auf diese Software gebeten, damit wir die API „reverse engineering“ können (ziemlich albern, nehme ich an), aber leider weigert sich der Anbieter, etwas davon zu geben, es sei denn, unser Kunde unterzeichnet einen Vertrag über ein Jahr mit ihnen.
Angesichts des massiven Mangels an Sichtbarkeit diesbezüglich zögere ich, irgendeine Art von Zitat zu liefern. Ich wurde jedoch unter Druck gesetzt, einen zu geben, also habe ich einen hohen Preis dafür angegeben, um die damit verbundenen Risiken abzudecken.
Natürlich ist der Kunde damit unzufrieden und behauptet, er könne es sich nicht leisten, dafür zu bezahlen. Außerdem scheint der Anbieter dem Kunden irgendwie gesagt zu haben , dass er die Integration zu einem viel niedrigeren Preis selbst durchführen kann, indem er unsere Software modifiziert.
Während der Code, den wir geschrieben haben, jetzt dem Kunden gehört und er damit machen kann, was er will, wie sage ich ihm, dass dies eine sehr schlechte Idee ist und höchstwahrscheinlich fehlschlagen wird? Außerdem bezahlt uns der Kunde immer noch für die Softwarewartung, daher möchten wir den Code in einem guten Zustand halten und natürlich möchten wir nicht für Probleme verantwortlich gemacht (oder behoben) werden, die sich aus den Änderungen des Anbieters ergeben könnten .
Vermutlich hat Ihr Kunde dem Dritten Ihren Code gezeigt und ist im Besitz aller Informationen, die er bei der Abgabe seines Gebots weniger riskieren muss als Sie.
Ihr Kunde hat jedoch das Risiko, dass er einfach ein niedriges Gebot abgibt, damit Ihr Kunde seine Hauptsoftware kauft und er die Integrationsarbeit möglicherweise nie abliefert.
Anstatt zu versuchen, dem Kunden Ihr Risiko zu erklären. Heben Sie ihr Risiko mit der Drittanbieteroption hervor, indem Sie sagen:
1- Jegliche Änderungen am Code bergen das Risiko, dass bestehende Funktionen beschädigt werden
2- Sie können das Produkt nicht weiter unterstützen, wenn Änderungen am Code vorgenommen werden. Wird der Drittanbieter diesen Support für das GESAMTE Produkt übernehmen?
3- Wenn der Drittanbieter nicht liefert oder Fehler gefunden werden, nachdem die Arbeit abgeschlossen ist und Ihr Kunde zu Ihnen zurückkommt, um die Probleme zu beheben. Die Kosten werden wahrscheinlich in der gleichen Höhe liegen, wie wenn Sie die Arbeit überhaupt erst erledigen würden.
4- Schlagen Sie vor, dass der Dritte einfach sein Standardprodukt verkaufen möchte und kein Interesse oder Anteil an der Integrationsarbeit hat. Wo Sie sich zu kontinuierlichem Support und Qualität verpflichten.
Sie betrachten den Anbieter als großes Risiko, das Sie in einer Festpreissituation absichern müssen. Ihr Zitat ist Ihre ehrliche Einschätzung und Sie wären dumm, es zu senken. Ich hoffe, Sie haben Ihrem Kunden Ihre Argumentation erklärt.
Ein Zeit- und Materialvertrag wäre für Sie beide besser. Sie gehen dieses Risiko nicht ein (insbesondere laufen Sie nicht Gefahr, vom unvernünftigen Lieferanten Ihres Kunden / Ihrem brüskierten Ex-Konkurrenten aufgehängt zu werden). Da der Kunde Ihre Risiken nicht tragen muss, bekommt er einen fairen Preis. Der Kunde scheint dem Anbieter mehr zu vertrauen als Ihnen und ist aufgrund seiner direkten Beziehung zu ihm wahrscheinlich besser in der Lage, seine Zusammenarbeit zu fördern. Ich glaube nicht, dass es schwer wäre, sie davon zu überzeugen, dass T&M hier der billigere Weg ist.
Während Supportverträge eine großartige Quelle für wiederkehrende Einnahmen sind, die hoffentlich wenig tatsächliche Arbeit erfordern. Auf die Unterstützung Ihres Codes nach der Änderung durch Dritte möchte ich nicht eingehen. Während die T&M-Route als der wahrscheinlich billigere Himmel präsentiert werden sollte, wenn sie es tun , verkaufen Sie dieses Durcheinander von (hoffentlich für den Kunden teuren) Software-Support zum Teufel, wenn sie es nicht tun .
Viele meiner Erfahrungen stammen aus der Architektur-/Bauwelt und ich denke, dass es ein Abrechnungsmodell gibt, das man sich ausleihen kann. Typischerweise wird die anfängliche „schematische Entwurfsphase“ vom Architekten auf Stunden-/Zeit- und Materialbasis in Rechnung gestellt und erst danach wird der Vertrag „Bauunterlagen“ unterzeichnet und der Preis festgelegt.
Es könnte sich lohnen, einen Zwei-Phasen-Ansatz zu versuchen: eine anfängliche Entwicklungsphase (nennen Sie es "Eignungsstudie", "Vorentwicklung" oder so ähnlich) mit Zeit- und Materialvertrag und einem am Ende festzulegenden normaleren Vertrag die Anfangsphase.
In der Anfangsphase müssen Sie Gespräche und Gespräche mit dem Kunden führen. Sie wollen die Zahlungsbereitschaft des Kunden nicht überfordern.
Viele Kunden können T&M nicht vertragen, sodass Sie gezwungen sind, ein Festpreisangebot zu machen – das ist ziemlich üblich.
Können Sie ein Festpreisangebot für einen Proof of Concept oder eine Minimum Viable Solution erstellen? Welche Drittanbieter-API, die in Ihre Lösung integriert ist, bietet den größten Nutzen bei dem geringsten Risiko?
Zitieren Sie die MVS/PoC-Arbeit mit einer gewissen Wahrscheinlichkeit und setzen Sie die Erwartung, dass der Rest der Arbeit zitiert werden kann, sobald der PoC abgeschlossen ist.
Nach Abschluss des Proof of Concept sollte ziemlich klar sein, was Ihre Fähigkeiten sind, was das Drittanbieterteam bewältigen kann, und der Kunde sollte eine gute Vorstellung davon haben, wer tatsächlich pünktlich und im Rahmen des Budgets liefern kann.
Wenn alles gut geht und das Drittanbieterteam großartig ist, sinken Ihr Risiko und Ihr Preis.
Wenn es nicht gut läuft, sollte Ihr Kunde die Ursache des Problems verstehen, und Ihr Preis wird sinnvoll sein.
Es ist entscheidend, dass Ihr Kunde weiß, dass die vollständige Lösung ein iterativer Prozess sein wird und Sie für mehr Geld zum Brunnen zurückkehren werden. Der Kunde sollte diesen Ansatz zu schätzen wissen, denn kleine Projekte gelingen viel häufiger als große Projekte: Gartner Survey
MCW
Barry A.