Etwas, das bei ausgelagerten Softwareprojekten ziemlich häufig vorkommt, ist, dass der Anbieter die Komplexität oder Lernkurve im Zusammenhang mit einer vereinbarten Leistungsbeschreibung unterschätzt und die Kosten in der Mitte des Projekts erhöhen möchte, wenn er feststellt, dass er unterschätzt hat.
Meine Frage ist: Gibt es einen fairen Weg, um zu entscheiden, wann der Verkäufer den unvorhergesehenen Aufwand "essen" und wann der Kunde tatsächlich mehr bezahlen sollte?
Vertragsstreitigkeiten sind eine Möglichkeit, das finanzielle Risiko für das Unternehmen zu managen, nicht das Zeitplanrisiko. Aus rein praktischen Gründen können Sie das Terminrisiko nicht wirklich durch vertragliche Mittel abschieben, egal was der Vertrag auch besagt.
Kurzfristig basieren Ihre unmittelbaren Optionen auf einer Geschäftsanalyse der Bedürfnisse und Alternativen Ihres Unternehmens. Denken Sie auch daran, dass die gewählte Option eher auf politischen Entscheidungen der Geschäftsleitung beruht als auf irgendetwas anderem.
Identifizieren Sie die Optionen und die damit verbundenen Kosten und legen Sie sie dem Management zur Entscheidung vor. Konzentrieren Sie sich dann darauf, Ihre Prozesse für die Zukunft zu fixieren.
Gibt es einen fairen Weg, um zu entscheiden, wann der Anbieter den unvorhergesehenen Aufwand „fressen“ und wann der Kunde tatsächlich mehr bezahlen sollte?
Während einige Antworten dies legalistisch ansprechen oder die Vorteile des agilen Prinzips der Kundenzusammenarbeit gegenüber Vertragsverhandlungen diskutieren, stellen Sie im Grunde einfach die falsche Frage.
Die pragmatische Frage bei einem solchen Streit sollte lauten: Brauche ich das Ergebnis mehr als die ursprüngliche Vereinbarung oder Zahlungsbedingungen? Am Ende des Tages können beide Seiten zwar Schuld zuweisen, Verantwortung übernehmen oder einen Anwalt beauftragen, aber keines dieser Dinge führt tatsächlich zur Arbeit. Selbst wenn Sie bereit sind, Ihre Beziehung zum Anbieter aufzugeben, stehen Sie dann vor schwierigen Entscheidungen darüber, wer die Arbeit erledigen wird, wie schnell sie sie tatsächlich liefern kann oder ob Sie überhaupt das gewünschte Endergebnis erzielen können .
Hier gilt oft das Gesetz von Brooks , weil Ihr Projekt wahrscheinlich schon in Verzug ist. An diesem Punkt Verträge anzufechten, Anbieter zu wechseln oder nach alternativen Lösungen zu suchen, kann Ihr Projekt noch später machen. Ob dies aus geschäftlicher Sicht akzeptabel ist oder nicht , ist letztendlich eher eine strategische oder Risikomanagemententscheidung als eine rein vertragliche.
Sie können den Schaden an dieser Stelle nicht wirklich rückgängig machen, da alle Ihre Optionen entweder mehr kosten, den Umfang oder die Qualität verringern oder Ihre Produktlieferung verzögern. Vielleicht alle oben genannten. Sie können jedoch den Prozessfehler analysieren und darauf abzielen, es beim nächsten Mal besser zu machen.
In den meisten Fällen ist das Problem nicht wirklich vertraglich. Das eigentliche Problem ist, dass das Unternehmen erst zu spät von einem Problem erfuhr. Agile Prozesse gehen dies durch kontinuierliche Zusammenarbeit, Transparenz und enge Inspektions- und Anpassungszyklen an.
Es ist im Allgemeinen viel besser, ausfallsichere Projektkontrollen zu implementieren, damit Sie das Projekt entweder anpassen oder vorzeitig beenden können, bevor übermäßige versunkene Kosten entstehen oder Sie vor dem Dilemma stehen, ob Sie versunkene Kosten verfolgen sollen oder nicht. Welcher Prozess- oder Kontrollfehler auch immer dazu geführt hat, dass das Projekt diesen Punkt ohne viele Vorwarnungen erreicht hat, dass Ihr Budget oder Ihre Zieldaten gefährdet sind, ist fehlerhaft und sollte angepasst werden.
Selbst wenn das Unternehmen die Arbeit an seinem Softwareprojekt „ausgelagert“ hat, ist am Ende des Tages immer noch jemand im Unternehmen für die Durchführung dieses Projekts verantwortlich. Pragmatisch gesprochen, wenn diese Person das Projekt kaputt macht, behält sie beide Hälften.
Wenn Sie den Preis wirklich festlegen möchten und das Vertrauen zwischen Ihnen und dem Anbieter noch gering ist, müssen Sie Ihren Umfang und seinen Preis zusammen mit Ihrem Anbieter so detailliert wie möglich dokumentieren . In einem solchen Fall ist es viel einfacher zu beurteilen, ob am Ende alles Gekaufte geliefert wird oder nicht.
Ein guter Ansatz ist also eine kurze Ausarbeitungsphase (auch bekannt als Sprint Zero ), in der Ihr Anbieter (oder Ihr Unternehmen) Anforderungen spezifizieren und auch die wichtigsten technischen Risiken mindern kann (die Ergebnisse der Minderung sollten Ihnen auch in Form eines Prototyps oder eines Prototyps geliefert werden). Analysedokumentation). Für ein 100.000-Dollar-Projekt sind 10.000 bis 20.000 Dollar Ausarbeitung ziemlich genug (insgesamt 100.000 Dollar).
Außerdem sollten Sie während der Phase bereit sein, jeden Tag sehr viel mit dem Team zusammenzuarbeiten (weil es kurz ist) – Anforderungen zu klären und bei der Lösung von Risiken zu helfen (z. B. Kompromisse bei technischen Lösungen und Scope-Optionen zu finden).
Und während des Projekts sollten Sie oft nach Demos fragen (mindestens alle 2 Wochen), wo Sie überprüfen sollten, was die Jungs liefern. Schauen Sie nicht nur schnell auf ihren Bildschirm, sondern gehen Sie auch zu dem Server, auf dem es installiert ist, und überprüfen Sie gründlich, ob alles in Ordnung ist und der Fortschritt gut ist. Und den Rest des Umfangs verfeinern – aber versuchen, keine neuen Funktionen im Umfang hinzuzufügen (was immer passiert), sondern wirklich minimal lebensfähige Produktfunktionen zu finden.
Die Nachteile des Elaboration-Phase- Ansatzes sind folgende:
Es ist also keine Wunderwaffe. Aber immer noch ein nützliches Instrument, um erste Vereinbarungen in schriftlicher Form zu erhalten. Außerdem ermöglicht es dem Anbieter, sich ein wenig zu entspannen und eine genauere Schätzung zu erstellen – dh Verantwortung zu übernehmen und sich darauf einzulassen.
Wenn das erste Projekt erfolgreich ist und der Anbieter Ihr Vertrauen gewinnt, kann der Discovery für seine zukünftigen Phasen sogar noch billiger sein, oder Sie können zum T&M-Modell wechseln, um die Bürokratie und Ihre eigenen Kosten für das Projekt zu senken.
Zur Risikominderung siehe auch „The Rational Unified Process Made Easy“ – großartiges Buch über das Gleichgewicht zwischen Wasserfall- und agilen Ansätzen.
Dies ist natürlich eher Verhandlungssache – es sollte eine konstruktive Kommunikation über Kosten und Umfang geben – versuchen Sie, die Standpunkte des Anbieters zu verstehen, stellen Sie sicher, dass er Ihre versteht, versuchen Sie, von ihm zu lernen, versuchen Sie nicht, alles während des Projekts umzusetzen - Seien Sie bereit für große Einschnitte in der Funktionalität. Und am Ende soll alles gut werden!
Ihrer Frage entnehme ich, dass es sich bei der Vertragsart in diesem Zusammenhang um ein festes Festpreismodell handelt. Wenn dies der Fall ist, ist der Verkäufer unabhängig von den finanziellen Verlusten, die der Verkäufer erleidet, für die Erfüllung des vertraglich vereinbarten Umfangs verpflichtet, es sei denn, die ausdrücklichen Stop-Loss-Kriterien im Vertrag wurden erfüllt. Wenn die Stop-Loss-Sprache schlecht geschrieben war oder fehlt, gibt es keinen Auslöser, den ein Verkäufer verwenden kann, um den Käufer zurück an den Tisch zu bringen.
Die Realität ist jedoch, dass, wenn der Verkäufer in einer ernsthaften Verlustsituation ist, die Arbeit oder ihre Qualität in Gefahr ist und niemand wirklich gewinnt. Es liegt im besten Interesse des Käufers, sich wieder mit dem Verkäufer zusammenzusetzen und einen vernünftigeren Deal auszuarbeiten, um das Projekt am Laufen zu halten, damit alle gewinnen. Hier besteht das Risiko, dass der Käufer das Vertrauen verliert und die Arbeit aus wichtigem Grund einstellt, möglicherweise auf Schadenersatz klagt und den Ruf des Verkäufers in der Branche ruiniert.
Die beste Lösung ist also, bei der Schätzung von Arbeiten, die ziemlich unbekannt oder mit hohen Risiken oder einem FoAK (First of a Kind) sind, eine andere Art von Vertragsmodell zu verwenden, wie z. B. Time and Materials oder Cost Plus Fee.
Dies geschieht normalerweise, wenn das Dokument zum Projektumfang nicht gut vorbereitet ist. Als Softwareentwickler versäumen wir es manchmal, wichtige Funktionalitäten zu integrieren, und sie tauchen als unvorhergesehen auf. Und es ist sehr notwendig, an Subroutinen/Funktionen zu arbeiten, die den gegebenen Softwarespezifikationen zugrunde liegen.
Fragen Sie den Anbieter:
Schließlich zahlen Sie nur dann mehr, wenn es für Sie sinnvoll ist.
Sie sollten nicht zahlen, wenn bei der Bereitstellung zuvor dokumentierter Funktionen ein Fehler oder eine Verzögerung auftritt.