Das ist eine Sache, die ich immer als gegeben hingenommen habe, den "Status quo" in meiner Branche (Softwareentwicklung), aber nie wirklich darüber nachgedacht habe. Und selbst jetzt, wo ich es tue, verstehe ich es immer noch nicht.
Ich spreche nicht davon, etwas zu schätzen, das Sie immer und immer wieder gemacht haben, aber Dinge, die Sie nie gebaut haben, für die Sie nicht die Erfahrung haben, die Spezifikationen sind unvollständig (wenn Sie überhaupt einen solchen Luxus haben), eine Schätzung abzugeben Aufwand für Powerpoint-Präsentationen während der Präsentation etc.
Ich meine, es widerlegt jede Logik, aber das passiert ständig. Wieso den?
Warum passiert das immer?
Ich werde nicht sagen, dass es nur um Kommunikation geht , aber ich denke, dass ein großer Teil des Problems, das Sie sehen, auf die Kommunikation zurückzuführen ist, die verbessert werden könnte.
Ich arbeite im selben Bereich und habe dieses Verhalten bei vielen Kunden in verschiedenen Branchen beobachtet. Es hat lange gedauert, bis ich verstanden habe, dass die Art und Weise, wie ich Kostenvoranschläge anfangs darlege, einen großen Einfluss darauf haben kann, wie der Kunde später mit diesen Kostenvoranschlägen umgeht. Und dann, im Laufe des Projekts, kann die Art und Weise, wie ich zusätzliche Informationen präsentiere, einen großen Einfluss darauf haben, wie stark der Kunde an den ursprünglichen Schätzungen verankert ist.
Eines der wichtigsten Dinge, die Sie beachten sollten, ist, dass Sie jedes Mal, wenn Sie Schätzungen abgeben, Erwartungen setzen. Je genauer Ihre Schätzungen klingen, desto wahrscheinlicher wird der Kunde sie als harte Frist behandeln. Wieso den? Der Kunde stellt Sie als Experten ein, und Sie haben ihm Ihre Expertenmeinung gegeben. Ein Experte wird doch sicher wissen, wovon er redet?
Überlegen Sie beispielsweise, wie Ihr Kunde reagieren würde, wenn Sie ihm sagen würden, dass das Projekt, das Sie für den 6. November veranschlagt haben, erst am 20. November abgeschlossen sein wird.
Denken Sie jetzt darüber nach, wie derselbe Kunde reagieren würde, wenn Sie ihm stattdessen ursprünglich gesagt hätten, dass Sie zwischen Oktober und November fertig sein würden, mit einer Wahrscheinlichkeit von 75 %, dass Sie in der ersten Novemberwoche fertig wären. Ihr Ausrutscher auf den 20. bedeutet, dass Sie Ihre Wahrscheinlichkeit von 75 % immer noch verfehlt haben, aber Sie sind immer noch in den Bereich gefallen, den Sie ursprünglich mit ihnen festgelegt hatten.
Die meisten (wenn auch definitiv nicht alle) Klienten werden auf den zweiten Fall viel akzeptabler reagieren als auf den ersten.
Der andere große Faktor besteht darin, sicherzustellen, dass im Verlauf des Projekts häufig und klar mit dem Kunden kommuniziert wird. Stellen Sie sicher, dass der Kunde sieht, wo das Projekt im Vergleich zum idealen Fortschritt steht. Stellen Sie sicher, dass Sie über alle Probleme sprechen, die den Zeitplan des Projekts im Vergleich zu den ursprünglichen Schätzungen beeinträchtigen könnten. Stellen Sie sicher, dass der Kunde Transparenz darüber hat, wie getroffene Entscheidungen dazu führen, dass zusätzlicher Umfang hinzugefügt, bestehender Umfang verschoben, ungeplante Arbeiten durchgeführt werden müssen oder Hindernisse, die den Fortschritt daran hindern, in der ursprünglich erwarteten Geschwindigkeit fortzufahren.
Verwenden Sie nicht einfach Text, um diese Informationen zu präsentieren. So etwas wie ein Burnup-Chart zu haben, kann den zunehmenden Umfang für den Kunden viel sichtbarer (und wirkungsvoller für sein Verständnis) machen, als einfach nur prozentuale vollständige Zahlen aufzulisten.
Es gibt einen Unterschied zwischen Schätzungen und Planungswerten, und ich finde, die meisten ignorieren oder verwechseln die beiden ... wahrscheinlich letzteres. Der Arbeitsaufwand ist probabilistisch und eine angemessene Schätzung sollte dies widerspiegeln und als Bereich möglicher Ergebnisse bereitgestellt werden. Zum Beispiel könnte eine Schätzung für den Bau einer Mauer sechs bis 15 Tage betragen, höchstwahrscheinlich neun. Wenn Sie diese Mauer 100 Mal gebaut und die Anzahl der Tage dokumentiert haben, sollten Ihre tatsächlichen Ergebnisse diese Verteilung widerspiegeln.
Ihr Planungswert ist eine Zahl innerhalb dieses Bereichs, die Ihr Ziel widerspiegelt, und sollte ein Wert sein, der das Maß an Risiko widerspiegelt, das Sie bereit sind einzugehen. In der Wandschätzung könnte mein Planungswert acht Tage betragen, was darauf hindeutet, dass meine Risikobereitschaft aggressiver ist als das, was ich am wahrscheinlichsten erreichen werde.
Sie müssen Planungswerte haben, und diese werden zu Fristen. Projekte können nicht unbefristet genehmigt werden. Niemand wird sein Geld mit der Erwartung aufs Spiel setzen, dass es so lange dauert, wie es dauert, und so viel kostet, wie es kostet. Würden Sie jemanden einstellen, der das sagt?
Es gibt Arten von Projekten, die extreme Innovationsereignisse oder Forschung in der Natur sind und die etwas anders angegangen werden, aber selbst dann haben Sie Grenzen gesetzt, wo Sie das Projekt beenden würden, wenn keine Fortschritte erzielt werden. Diese Grenzen sind in gewisser Weise Planungswerte oder Zielvorgaben.
Wenn der Kunde die Schätzung des Zeitplans anfordert, sieht er den PM als Experten an, der ihm sagen kann, was er den Stakeholdern mitteilen muss, mit denen der Kunde zusammenarbeitet. Daher ist es bei der Kommunikation der Zeitschätzungen wichtig, dass die Faktoren, die die Zeitschätzungen definieren, und die Kriterien für deren Erfüllung hervorgehoben werden sollten. Viele Male als Projektmanager, wenn Sie gefragt werden, wann Sie fertig sein können, geben die meisten von uns am Ende nur den Zeitplan und oft nur die Fristen an, ohne die Faktoren zu betonen, die es uns ermöglichen, den Zeitplan einzuhalten, und um wie viel Prozent es Abweichungen geben könnte. Auch wenn wir Variationen kommunizieren, kann man nicht einfach sagen, dass es sich um eine Variation von 50 % handelt, die anhand der Faktoren quantifiziert werden muss, auf die wir schließen.
Der Kunde akzeptiert den Zeitplan als Schätzung, wenn er unterstützt wird durch 1. Faktoren zum Erreichen des Zeitplans 2. Potenzielle Risiken für den Zeitplan 3. Unbekannte auf hohem Niveau, die zu Problemen führen könnten.
Warum werden Kostenvoranschläge wie Fristen behandelt?
Schätzungen sind im Kern Risikobewertungen. Sie werden oft als Näherungswerte für Terminrisiken, potenzielle Prozessbehinderungen und das Ausmaß des Chaos oder des Risikos des Unbekannten innerhalb des Projekts verwendet. Die psychologische Literatur ist voll von Beispielen dafür, wie schlecht Menschen Risiken einschätzen. Im Sicherheitsbereich schreibt Bruce Schneier oft über die Kluft zwischen wahrgenommenem Risiko und tatsächlichem Risiko.
Auch wenn dies den Anschein hat, als würde dies nur zu schlechten Schätzungen führen, wenn Sie darüber nachdenken, wie Menschen Schätzungen zur Messung von Zeitplanrisiken, Projektrisiken oder anderen Risiken verwenden , werden Sie schnell feststellen, dass Menschen emotional verdrahtet sind, um Schätzungen als Maßnahmen mit hoher Wahrscheinlichkeit zu behandeln Artikel. Dies unterscheidet sich nicht von der Art und Weise, wie die meisten Menschen probabilistische Wetterberichte behandeln.
Betrachten Sie den typischen Wetterbericht, der besagt:
Heute ist es morgens klar, mit 60-80% wechselnden Gewittern am Nachmittag.
Traurigkeit. Nun, kognitiv besteht eine Wahrscheinlichkeit ungleich Null, dass es den ganzen Tag regnen wird, eine Wahrscheinlichkeit ungleich Null, dass es überhaupt nicht regnen wird, und eine statistisch signifikante Wahrscheinlichkeit, dass es irgendwann nach dem Mittagessen und bevor ich von der Arbeit gehe, regnet. Das sind eine Menge Informationen, die die meisten von uns sicher nur als Kurzform für „Ich denke, ich nehme lieber einen Regenschirm mit zur Arbeit, nur für den Fall“ behandeln. Wir haben gerade eine Schätzung in ein festes Ziel für die Planung unseres Tages verwandelt.
Ich bin mir nicht sicher, wie ich das beweisen soll, außer anekdotisch, aber jeder frischgebackene MBA, für den ich persönlich jemals gearbeitet habe, wird am Altar von MS Excel verehrt. Business Schools lehren Rechnungswesen und Finanzanalyse, aber entweder lehren sie keine strengen Statistiken oder betonen sie nicht genug im Bereich der Geschäftsprozesse.
Ein Teil davon liegt in der Natur der Hochschulbildung (z. B. vermittelt sie oft Lehren, die von der vorherigen Geschäftsgeneration gelernt wurden), und ein Teil davon ist, dass die Hochschulbildung oft unter einem Elfenbeinturm-Syndrom leidet. Das ist nicht typisch für das Management; Fragen Sie jeden Informatik-Absolventen, ob ihn ein Informatik-Abschluss wirklich darauf vorbereitet hat, an einer großen, unternehmenskritischen E-Commerce-Anwendung zu arbeiten.
Genügend Seifenkistenmaterial. Hier ist ein praktischeres Beispiel. Wenn Sie ein Manager sind, lesen Sie Artikel wie diesen im Wall Street Journal:
Fang an und sei dir dem Ende bewusst. Es reicht nicht aus, einfach einen Kurs zu wählen; Sie müssen eine klare Vorstellung davon haben, wohin Sie dieser Kurs führen wird. Sie müssen entscheiden, was Sie tun werden und wohin es Sie führen wird. Kurz gesagt, Sie müssen eine Strategie haben.
Es sei dem Leser verziehen, Schätzungen mit Zielen zu verwechseln. In der Managementsprache dreht sich alles um Strategien, Ziele und (natürlich) Budgetierung. Eine Schätzung ist eine Wahrscheinlichkeit, keine Strategie, aber wenn Sie wirklich genau hinsehen, könnte es so aussehen. Ihr Kilometerstand kann variieren.
Projektmanager, Scrum Master oder andere Projektreferenten sind dafür verantwortlich sicherzustellen, dass die Beteiligten den Unterschied zwischen einem Kostenvoranschlag und einer vertraglichen Garantie verstehen. Dies ist nicht einfach und kann politisches Kapital verbrennen, wenn es keine Botschaft ist, die die Interessenvertreter hören wollen. Trotzdem gehört es zum Job .
Bei Scrum teilt sich der Scrum Master diese Verantwortung mit dem Product Owner. Der Scrum Master ist für den Prozess verantwortlich und stellt sicher, dass das Entwicklungsteam effektiv und transparent über seine Prozesse kommuniziert, einschließlich des Schätzungsprozesses. Der Product Owner ist jedoch die Person, die in erster Linie für das Management der Stakeholder-Erwartungen verantwortlich ist; Auch wenn diese Verantwortung nicht explizit ist, ist sie für die Kernaufgaben der Priorisierung von Product-Backlog-Einträgen und der Festlegung von Sprint-Zielen für jede Iteration unerlässlich.
Wenn keiner der Projektverantwortlichen oder -vollstrecker den Unterschied zwischen einem Kostenvoranschlag und einer Garantie kommunizieren kann, handelt es sich um einen Kommunikationsfehler . Überprüfen und passen Sie Ihren Kommunikationsprozess an, bis der Punkt effektiv gemacht ist, und akzeptieren Sie einfach, dass der Punkt wahrscheinlich immer wieder gemacht werden muss, insbesondere wenn etwas falsch eingeschätzt wird und es finanzielle oder zeitliche Konsequenzen gibt.
@ user12198 Die Realität ist, dass sie manchmal Fristen wollen, und in der Software haben wir eine Möglichkeit, die Zeit anstelle von Funktionen festzulegen. Aber das muss der Prozess sein, und er muss in das Dreieck eingebaut werden. Denken Sie daran, dass ein Team/Projekt zwei auswählen muss. Viele Softwareentwicklungspläne versuchen, alle zu beheben, oder sagen zumindest nicht ausdrücklich, dass einer vernachlässigt wird.
In Ihrem Fall klingt es so, als ob Sie die Anzahl der Funktionen (Umfang) auf die Wünsche des Kunden festlegen und Ressourcen festlegen möchten. Das Problem ist, dass Sie wahrscheinlich nicht gesagt haben, dass der Zeitplan variabel sein MUSS.
Eine Lösung, die ein Software-PM annehmen könnte, ist Timeboxing . Dies ermöglicht einen festen Zeitplan und Ressourcen, aber KEINEN festen Umfang. Ein Softwareplan müsste eine Art Priorisierungsschema wie MoSCoW verwenden . Wo der Kunde Funktionen quantifizieren muss und Sie auf diese Weise in einem Zeitfenster nur die wertvollsten Dinge erledigen, kann Ihr Ziel für ein Projekt nicht sein, alle Funktionen fertigzustellen, sondern rechtzeitig fertig zu werden.
Venture2099
Todd A. Jacobs
Venture2099
Venture2099
Marv Mills
David Arno
Venture2099
David Arno
Venture2099