Geben Sie dem Kunden hochrangige Schätzungen, ohne sich auf Zahlen festzulegen

Ich arbeite als Project Delivery Manager einer Softwareentwicklungsfirma. Oft kontaktieren mich langjährige und treue Kunden direkt vor der Projektinitiierung, um einen „Kostenvoranschlag“ für einige Arbeiten anzufordern, die an ihrem System durchgeführt werden sollen.

Oft kommen diese Anfragen mit Beschreibungen auf sehr hohem Niveau. Hervorzuheben ist, dass sie zu diesem Zeitpunkt noch nicht nach Angeboten fragen. Sie (die Person, oft mein Gegenüber im Unternehmen des Kunden oder sein Teammitglied) bitten mich praktisch, ihre Hausaufgaben zu machen, indem sie hochrangige Schätzungen für ihre Berichte oder Besprechungen erstellen.

Um ein vollständigeres Bild zu vermitteln, betreut mein Unternehmen den Kunden seit einiger Zeit. Länger als manche Manager und Ingenieure des Kunden dort arbeiten. Wir haben keinen Rahmenvertrag, der außervertragliche Anfragen wie diese abdeckt. Aus rein vertraglicher Grundlage sind wir daher nicht verpflichtet, solche Anfragen zu bearbeiten. Aber mein Firmeninhaber rät mir, solche Anfragen trotzdem zu berücksichtigen, weil es eine gute Beziehung zum Kunden fördert und uns zumindest einen Vorsprung verschafft, wenn oder falls das Projekt in eine offene Ausschreibung geht. Und ehrlich gesagt stimme ich ihr zu.

Das Problem dabei ist, dass ich Schätzungen in Zahlen wie Dollarkosten, Manntageanforderungen oder Zeitrahmen herausgebe. Die Zahl taucht oft in irgendeiner Budgetbesprechung oder einem Projektauftrag auf. Die Mitarbeiter gehen darauf basierend Verpflichtungen ein. Und wenn es an der Zeit ist, formelle Angebote einzureichen, wird mein Unternehmen oft gegen diese Zahlen gehalten. Oft ist der Umfang der Arbeit etwas gewachsen.

Meine Frage lautet: Wie kann ich den Kunden am besten vermitteln, dass der Kostenvoranschlag keineswegs verbindlich ist? Es ist eine "laufende Diskussion". Jegliche Zahlen, die sich daraus ergeben, seien es Dollarkosten oder Zeitrahmen, sind keine Verpflichtung von mir oder meiner Firma.

Antworten (6)

Leichte Frame-Herausforderung: Erwägen Sie, Ihre Schätzungen eher als das breite Ende eines Unsicherheitskegels als als diskrete Zahl anzugeben.

"Ich brauche eine [vage Sache], wie lange würde es dauern?"

„Okay, ich habe es mit meinem Team besprochen und wir denken, dass es zwischen 2 und 7 Wochen dauern wird.“

"Ich brauche eine genaue Schätzung."

"Dann brauchen wir genaue Angaben. Unsere Schätzung für die von Ihnen gemachten Angaben liegt bei 2 bis 7 Wochen."

"Okay, was ist mit [weniger vage Sache]?"

"Oh, das wären 3 bis 5 Wochen."

Wenn Sie Ihre Schätzungen als Spanne angeben, wird Ihre Unsicherheit in die Schätzung selbst eingebacken, sodass kein separater Schritt „aber wir verpflichten uns nicht vollständig zu dieser Schätzung“ erforderlich ist.

Der Unterschied zwischen Wochen und Personenwochen wird wichtig sein (und für die verstrichene Zeit, wenn die Uhr starten würde).
Wie lange es Ihrer Meinung nach dauern wird, mal zwei plus eins; Da ist deine Reichweite. Mein Favorit ist in The Road Warrior . Die meisten Leute denken wahrscheinlich an Scotty aus Star Trek, besonders in der TNG-Folge, in der er Geordi dafür beschimpft, dass er eine genaue Schätzung abgegeben hat.

Um die richtige Antwort von nvogel zu ergänzen .

Neben der Bereitstellung von Einzelleistungen müssen Sie die Standardfunktionen hinzufügen, die vergessen, übersehen, aber notwendig und sehr zeit- und ressourcenintensiv sind, daher wirken sie sich sowohl auf den Zeitplan als auch auf das Budget aus.

Funktionen wie Design, Funktionsspezifikation, Grafikdesign & Freigabe, Integration (Fehlerbehebung als Ergebnis der Integration - muss einen Namen erhalten, um die "Fehler" zu verbergen), QA (mit einigen Runden zur Fehlerbehebung), Beta-/Offline-Tests, Go-Live-Verfahren, um nur einige Beispiele zu nennen.

Sie können diese für selbstverständlich halten, aber wie Sie sagten, wird Ihr „Rohentwurf“ zu einem Arbeitsdokument, und deshalb möchten Sie eine falsche Preisgestaltung (und ein mögliches Scheitern der Wettbewerbsanalyse) auf der Grundlage eines Teilprojektplans verhindern.

Hängen Sie jeden Kostenvoranschlag an eine detaillierte Leistung und nicht an einen benannten Arbeitsumfang an, so gibt es weniger Raum für Zweifel an dem, was geschätzt wurde. Verwenden Sie die relative Schätzung (Punkte) auf Artikelebene und aggregieren Sie dann die Punktwerte und wandeln Sie sie nach Bedarf in absolute Zeit und Kosten um. Die besten Schätzungen werden in der Regel vom Entwicklungsteam und nicht von einem Delivery Manager erstellt und verwaltet.

Ihr Problem erfordert zwei Dinge, die zu 100 % IHREM Unternehmen gehören, und zwar nur diese beiden Dinge: 1) Sie müssen eine juristische Sprache einfügen, die Ihre Schätzung begleitet, dass dies eine allgemeine, grobe Schätzung der Größenordnung ist, basierend auf was zu diesem Zeitpunkt bekannt war, die sich ändern kann, wenn die Anforderungen bekannter und fester werden; und 2) IHR Unternehmen muss standhaft bleiben und zurückschlagen, wenn Sie Druck verspüren, sich an dieses ROM zu halten. Nummer 2 ist kritisch, weil Nummer 1 ohne sie bedeutungslos ist.

Schauen Sie sich einfach andere Branchen wie das Baugewerbe an. Wenn Sie sich mit groben, hochrangigen Wünschen an einen Bauunternehmer gewandt haben, um Ihnen ein Haus zu bauen, und dann versuchen, ihn an diesem Wert festzuhalten - wenn er ihn überhaupt bietet -, werden sie lachen, wenn sie von Ihnen weggehen.

Für diejenigen von uns, die in der SW- oder anderen Wissensarbeit tätig sind, scheinen wir Schwierigkeiten zu haben, genau das zu tun. Aber es ist eigentlich kein weiteres Eingreifen erforderlich, außer „Nein!“ zu sagen. Verkäufer von Software und anderen Wissensarbeiten haben einen gleichberechtigten Platz am Tisch.

Die Kommunikation sollte möglichst klar sein, will man Fehlinterpretationen vermeiden, das ist nicht unhöflich, sondern einfach professionell. Was ist mit einer prominenten Note

This is a rough estimate based on incomplete requirements.
It is intended to support your decision process, but it's not binding
and should not be used in budget or schedule planning.

in Ihrer Antwort-E-Mail? CC Ihren Chef, damit es eine klare Spur gibt, dass Sie sich nicht auf einen endgültigen Zeit- oder Budgetbereich festgelegt haben.

Das ist richtig, was du gesagt hast. Allerdings hatte ich vor langer Zeit einen Chef, der nahm, was ich schrieb, entfernte, was ihm nicht gefiel, fügte Dinge hinzu, änderte Inhalte und lieferte es dann weiter. Dann musste ich erklären, warum ich mich nicht auf das Monster einlasse, das der Boss erschaffen hat. Was lustiger ist, ist, dass Chefs der oberen Ebene die gleichen Dinge taten, was also das "endgültige Ziel" erreichte, war ziemlich unabhängig von den Informationen, die ich zur Verfügung stellte.

Eine Möglichkeit, auf die Frage zu antworten, besteht darin, sich auf Risiken zu konzentrieren, die der späteren Arbeit innewohnen. Insgesamt würde ich für ein sehr riskantes Projekt überhaupt keine Schätzung abgeben, sondern eine Vorstudie vorschlagen.

Typische zu bewertende Risikofaktoren, die in der Antwort hervorgehoben werden könnten, könnten sein. Jede der Aussagen könnte mit einer Zahl versehen werden, z. B. zwischen 1 und 5, wobei 5 ein hohes Risiko bedeuten würde – eine zu hohe Summe -> eine Vorstudie nahe legen.

  • Wir verstehen die Anforderungen
  • Es gibt keine wichtigen Aspekte der Anforderungen außerhalb unserer Kontrolle, die wir handhaben müssen, z. B.: gesetzliche Anforderungen, Geschäftslogik, Übersetzung in andere Sprachen, ...
  • Wir erwarten nicht, dass sich die Anforderungen während des Projekts ändern (Feature Creep kann sehr teuer werden)
  • Wir glauben, dass es tatsächlich möglich ist, nach den Anforderungen zu bauen (der Kunde verlangt nicht das Unerreichbare)
  • Wir glauben, dass wir über ausreichende Kenntnisse und Lösungen zu Faktoren wie Produktionsumgebung, Leistung, Sicherheit, ...
  • Wir haben alle erforderlichen technologischen Kenntnisse im eigenen Haus oder sind leicht verfügbar, z. B. in der Verwendung einer Computersprache oder eines Frameworks
  • Wir haben die erforderlichen Kapazitäten (Programmierer, Tester, Testsysteme, ...) zum richtigen Zeitpunkt verfügbar, um die Lösung gemäß dem Zeitplan des Käufers zu erstellen
  • Wir erwarten, dass das Personal des Käufers bei Bedarf verfügbar ist (Anforderungsverantwortliche, Entscheidungsträger, Abnahmetestpersonal, ...)
  • Die Bereitstellung am Standort des Benutzers ist weder zeitaufwändig noch kostspielig
  • fügen Sie nach Ihrer Erfahrung hinzu