Wie sollte ein Projektmanager mit einer Anfrage nach Vertragssoftware umgehen, um doppelt so viele Berichte zu erstellen, wie in den Projektanforderungen angegeben?

Einer der vier Werte von Agile ist „Kundenzusammenarbeit statt Vertragsverhandlung“.

Die erste Frage lautet: „Was ist das Beste für den Kunden?“. Sobald Sie das getan haben, fragen Sie: "Ist es durch den Vertrag abgedeckt?" und erst dann vertiefen Sie sich in das "bitten wir um mehr $".

Wenn ich mich speziell auf Ihr Problem konzentriere, wäre die erste Frage, die ich stellen würde, wer an der Überprüfung und Unterzeichnung des BRD beteiligt war? Oft habe ich festgestellt, dass der BRD nur eine Person vom Kunden hatte und diese Person vielleicht nicht wirklich die richtige Person war.

Wenn der Kunde für Ihr Unternehmen wichtig ist, würde ich vorschlagen, am agilen Wert festzuhalten und mit ihm zusammenzuarbeiten, um ihn glücklich zu machen.

Stellen Sie dann bei zukünftigen Projekten sicher, dass Sie im Voraus klare Definitionen von Erfolgs- und Akzeptanzkriterien erhalten. Stellen Sie außerdem sicher, dass die SOW so geschrieben ist, dass auf die endgültigen Anforderungen verwiesen wird, die an anderer Stelle dokumentiert sind.

Viel Glück

TL;DR

In dieser Phase besteht die Aufgabe des Projektmanagers darin, den Unternehmen einen Rahmen zu bieten, in dem sie den Umfang ansprechen, und das Budget und die Ressourcen abzuschätzen, die erforderlich sind, um diesen Umfang zu erreichen. Das ist es! In solchen Situationen liegen Schuldfragen (außer natürlich bei Ihnen) wirklich außerhalb des Verantwortungsbereichs eines Projektleiters.

Anstatt die Schuld zuzuweisen oder zu versuchen, die Last auf den Kunden abzuwälzen, sollten Sie:

1. Kommunizieren Sie effektiv mit Ihrer Organisation (und möglicherweise dem Kunden) über das Problem.
2. Identifizieren Sie eine oder mehrere mögliche Lösungen für das Problem.
3. Empfehlen Sie Ihrem Senior Management eine Lösung, die diese dann mit dem Kunden erarbeiten kann.

Jeder dieser Aktionspunkte wird nachstehend ausführlicher erörtert.

Kommunizieren Sie effektiv über Probleme

Akronyme können Kommunikationsprobleme verursachen, lösen sie aber selten. Der größte Teil Ihres Beitrags ist ein verwirrender Mischmasch aus Akronymen und macht einen schlechten Job, um über das eigentliche Problem zu kommunizieren. Also, lassen Sie uns das zuerst beheben. Ihre aussagekräftigen Fakten sind:

1. [D]ie Leistungsbeschreibung (SOW) besagt lediglich, dass die Software das „Reporting“ unterstützen wird.

2. [O]unser Business Requirements Document (BRD) beschreibt drei Berichte, die die Software erstellen muss.

3. [D]er Kunde bittet uns, sechs zusätzliche Berichte zu erstellen, und sagt, dass dies abgedeckt ist, weil die SOW sagt, dass die Software zur Erstellung von Berichten verwendet wird.

Zusammenfassend lässt sich sagen, dass die Leistungsbeschreibung, die den Umfang definiert, vage ist, das Dokument mit den Geschäftsanforderungen möglicherweise in Zusammenarbeit mit dem Kunden verfasst wurde oder nicht, und der Kunde verlangt, dass das Projekt sechs statt drei Berichte umfasst.

Analysieren Sie das Problem genau

Nachdem wir nun die eigentlichen Probleme identifiziert haben, sehen wir uns an, was das wirklich für Ihren Umfang und Ihren Prozess bedeutet.

1. Ihr Unternehmen ist eindeutig für den vagen Umfang in der SOW verantwortlich. Ihr Vertragsprozess sollte festgelegt sein, aber in der Zwischenzeit übernimmt er die Verantwortung für die Definition des Umfangs der Berichterstattung auf dem Weg zu einem anderen Dokument oder Prozess innerhalb des Projekts. Dies kann Ihr Geschäftsanforderungsdokument sein oder auch nicht.
2. Wenn Sie von „unserem“ Geschäftsanforderungsdokument sprechen, ist es schrecklich unklar, wer eigentlich der BRD-Eigentümer ist. Wurden die Anforderungen vom Kunden geschrieben oder von ihm erfragt und dann von der Projektleitung in das Projekt eingebracht? Oder hat Ihr Projektteam dieses Dokument erstellt und vielleicht nicht alle Anforderungen vollständig erfasst? Dies ist sehr wichtig, da der Kunde im ersten Fall einen Umfang definiert hat, den er jetzt überschreitet, während Ihre Organisation im zweiten Fall eine vage SOW gefolgt von einem unvollständigen Satz von Anforderungen verwendet hat, um den Umfang zu definieren. Wenn Ihr Projektteam die Anforderungen nicht genau erfasst, wäre das wiederum die Schuld Ihres Unternehmens.
3. Die bloße Existenz der Frage setzt voraus, dass das Reporting-Produkt nicht einfach erweiterbar ist. Wenn dies der Fall wäre, wäre dies ein geringfügiges Problem, das kein erhebliches Budget erfordert oder zwei getrennten Managementteams Anlass zur Sorge gibt. Also gibt es entweder technische Schulden, das Fehlen einer robusten Implementierung oder es gibt Komplexitäten in Bezug auf diese Berichtspflicht, die vom Projekt nicht gut erfasst wurden.
4. Dies ist sowohl eine Frage des Projektumfangs (z. B. sind die zusätzlichen Berichte in der vereinbarten Arbeit enthalten?) als auch der Haftung (z. B. wer ist schuld an Missverständnissen, Scope Creep oder Budgetüberschreitungen). Dies ist eine Frage, die die Geschäftsleitung (und möglicherweise die Anwälte) auf beiden Seiten beantworten müssen, und nicht nur eine Frage des Projektmanagements. In dem Maße, in dem der Projektmanager entweder die vage SOW als Risiko hätte identifizieren oder darauf hinarbeiten sollen, dass die BRD korrekt und vollständig ist, gibt es sicherlich viele Schuldzuweisungen. Die eigentliche Frage ist jedoch , wer die zusätzlichen Projektkosten bezahlt?

Am Ende des Tages geht es bei den ersten drei Fragen um Schuldzuweisungen, die außerhalb eines Gerichtssaals nicht wirklich weiterhelfen, wenn es im Vertragsstreit so weit kommt. Was wirklich zählt, ist, wie Sie das Projekt und die Kundenbeziehung retten und enorme Kostenüberschreitungen vermeiden.

Der Pool möglicher Lösungen

Vergiss zuallererst, wie du dorthin gekommen bist, wo du bist. Korrigiere das ein andermal. Konzentrieren Sie sich stattdessen darauf, wie Sie mit dem Kunden zusammenarbeiten können, um eine zufriedenstellende Lösung zu finden, die Folgendes erfüllt:

1. die Erwartungen des Kunden an ein funktionierendes Produkt und
2. der Bedarf Ihres Unternehmens, zusätzliche Arbeiten zu finanzieren.

In keiner bestimmten Reihenfolge wird Ihr Projekt schließlich eine oder mehrere der folgenden Aufgaben ausführen:

• Rufen Sie "mea culpa" und erledigen Sie die restliche Arbeit ohne Aufpreis.
• Nutzen Sie die Erfahrung, um die Vertrags-, Budgetierungs-, Schätzungs- und Anforderungserfassungsprozesse in Zukunft zu verbessern.
• Sammeln Sie neue Berichtsanforderungen und fügen Sie sie dem Projekt hinzu, um zusätzliche Kosten zu minimieren und gleichzeitig den erwarteten Kundennutzen zu liefern.
• Arbeiten Sie mit dem Kunden zusammen, um eine gerechte Lösung zu finden.
  • Arbeiten Sie mit dem Kunden zusammen, um den Umfang neu zu definieren.
  • Arbeiten Sie mit dem Kunden zusammen, um das Budget neu zu verhandeln.
• Sic die auftraggebenden Auftraggeber aufeinander, um eine für beide Seiten (un)zufriedenstellende Lösung auszuhandeln.
• Anwalt, und vor Gericht gehen, wer Recht hatte.

Es kann einige Variationen eines Themas geben, die ich nicht behandelt habe, aber im Allgemeinen sind dies Ihre Möglichkeiten. Einige sind definitiv schmackhafter als andere, aber es ist wirklich Sache der Geschäftsleitung, die Optionen auszuwählen, nicht der Projektmanager.

Empfehlungen

Ich persönlich würde, wann immer möglich, den kooperativen Ansatz empfehlen. Ihr Ziel sollte es sein, so viel Wert wie möglich zu liefern, ohne übermäßige Kosten zu verursachen, während das Ziel des Kunden darin bestehen sollte, funktionierende Software zu erhalten, die seinen Anforderungen entspricht, ohne kostenlose Arbeit zu erwarten oder eine Beziehung zu beeinträchtigen, auf die er sich möglicherweise für die langfristige Unterstützung des Software, für deren Entwicklung sie Ihr Unternehmen bezahlen.

In einer perfekten Welt wäre dieses Problem nie aufgetreten. Da dies der Fall ist, möchten Sie die Kunst des Kompromisses erforschen , damit beide Parteien zufrieden davongehen können, wenn sie nicht glücklich sind.

In einem agilen Shop würde ich es einfach als iterative Erweiterung der bereits geleisteten Arbeit behandeln. In einem Wasserfallladen würde ich:

1. Sammeln Sie die Anforderungen.
2. Lassen Sie sich vom Kunden und Ihrem Entwicklungsteam den neuen Umfang genehmigen, um sicherzustellen, dass alle auf derselben Seite sind.
3. Schätzen Sie den Aufwand und die Kosten, die mit dem neuen Bereich verbunden sind.
4. Lassen Sie die Führungskräfte beider Unternehmen ihr 400:1-Gehalt verdienen, indem Sie aushandeln, wer für den zusätzlichen Umfang bezahlen wird.

In dieser Phase besteht die Aufgabe des Projektmanagers darin, den Unternehmen einen Rahmen zu bieten, in dem sie den Umfang ansprechen, und das Budget und die Ressourcen abzuschätzen, die erforderlich sind, um diesen Umfang zu erreichen. Das ist es! In solchen Situationen liegen Schuldfragen (außer natürlich bei Ihnen) wirklich außerhalb des Verantwortungsbereichs eines Projektleiters.

Die SOW ist vertraglich. Die BRD ist ein Arbeitsprodukt. Die SOW wird wahrscheinlich obsiegen, falls dies jemals zu Streitigkeiten führen sollte. Allerdings ist die BRD nicht ohne Gewicht. Wenn die Erstellung der zusätzlichen Berichte mühsam ist und Sie aus Kostengründen beeinträchtigt, dann bringen Sie den Kunden an einen Tisch und besprechen Sie mehr Geld. Ein vernünftiger Kunde wird verhandeln. Ein unvernünftiger Kunde wird dies nicht tun. Aber dann haben Sie die Lektion für Ihren nächsten Auftritt gelernt, um mehr Kontingenz für solche Dinge zu Ihrem Preis zu schaffen.

Meiner Erfahrung nach wird sich das Dokument durchsetzen, das von beiden Seiten unterzeichnet wird .

• Wenn der BRD bei 3 Berichten sehr deutlich war , der Kunde sich dessen aber nicht bewusst war , ist es Sache des Projekts, diesen Fehler aufzufangen – und den BRD so schnell wie möglich auf weitere Lücken zu überprüfen
• Hatte der Auftraggeber die BRD gekannt und abgesegnet, geht es um eine Neuplanung
• Wenn es kein formelles unterzeichnetes Dokument gibt , müssen Sie sich darauf einigen, wie es angegangen werden soll (viele Alternativen werden von CodeGnome ausführlich erwähnt) - ein Dokument abzuzeichnen, da es scheint, dass die Zusammenarbeit (wie die, die wir in Agile Umgebungen) ist in dieser Umgebung nicht stark.