Ich lese ein Buch von Steve McConnell, das sich mit Software-Projektschätzungen befasst, und ich verstehe die folgende Aussage nicht (meine Übersetzung, ich habe das Buch auf Deutsch bekommen):
Eine effektive Organisation verschiebt ihre Verpflichtungen, bis die Arbeit zur Verengung des Kegels abgeschlossen ist. .. Angemessene Zusagen können in der Anfangsphase der mittleren Phase (ca. in 30 % des Projektfortschritts) gegeben werden.
Wie kann dies jemals in der Realität erreicht werden? Ich meine, im Unternehmen können wir erst mit der Arbeit an dem Projekt beginnen, wenn der Vertrag abgeschlossen ist. Der Vertrag wird mit Aufwandsschätzung und Preis unterschrieben, daher sind wir bereits dazu verpflichtet.
Wie ist das dann in der Praxis anwendbar?
Der Unsicherheitskegel hat einige Anwendungen, ist aber am nützlichsten, wenn er in Verbindung mit einigen anderen Praktiken verwendet wird. Beginnen wir also mit den Verwendungen unter den von Ihnen beschriebenen Umständen.
Kegel der Unsicherheit, wenn eine Verpflichtung eingegangen wird
Offensichtlich kann man eine bereits eingegangene Verpflichtung nicht aufschieben, das ist eine einfache Frage der Physik (Zeit). Die meisten Organisationen, mit denen ich zusammengearbeitet habe, arbeiten im Modell mit festem Umfang und Termin, die erfolgreich sind, zwei Dinge. Erstens polstern sie ihre Schätzungen stark auf. Sie versprechen immer das hintere Ende des Kegels der Unsicherheit. Zweitens behalten sie eine gewisse Kontrolle über den Aufwand, den sie aufbringen können, indem sie Teams und Personen zum Team hinzufügen. Es ist dieser zweite Teil, in dem der Kegel der Ungewissheit für sie hilfreich ist. Vielleicht haben Sie schon einmal das Sprichwort gehört: „Personen zu einem späten Projekt hinzuzufügen, macht es später“. Dies kommt von der Ramp-up-Zeit. Das Hinzufügen von Personen zu einem Team oder von Teams zu einem Projekt verlangsamt das Projekt für eine Weile, bevor es beschleunigt wird. Beim traditionellen Projektmanagement wissen Sie also normalerweise nicht, dass ein Projekt zu spät kommt, bis Sie re zu nah an der Frist, um diese Verlangsamung zu überwinden. Durch die effektive Nutzung von Burn-up-Diagrammen und einem Kegel der Unsicherheit können Sie viel früher erkennen, dass sich Ihr Projekt verspätet – vielleicht rechtzeitig, um effektiv Personen oder Teams hinzuzufügen.
Es ist auch erwähnenswert, dass ich noch nie eine erfolgreiche Organisation erlebt habe, die sich kalt an ein Projekt (und eine Schätzung) heranwagt. Sie investieren entweder ziemlich viel Architektur- und Designzeit (ich weiß nicht, ob es 30 % sind, aber es ist normalerweise beträchtlich), oder sie verkaufen eine sofort einsatzbereite Lösung, für die sie frühere Arbeit nutzen denselben Zweck. Mit anderen Worten, sie investieren Zeit und Geld, das sie später wieder hereinholen wollen.
Unsicherheitskegel ohne festen Umfang / festen Termin
Dies ist wahrscheinlich der häufigste Ansatz, den ich bei Unternehmen gesehen habe, die Auftragsarbeiten ausführen. Anstelle einer großen Verpflichtung gibt es eine Reihe kleiner Verpflichtungen, wie z. B. die Arbeit für 2 - 3 Sprints oder, wenn Sie Scrum nicht verwenden, vielleicht einen Monat am Stück. Ich habe mit einer Reihe von echten Unternehmen zusammengearbeitet, die dies tun. Geplant ist vielleicht ein 8-Monats-Projekt, aber es gibt regelmäßige Checkins und der Kunde kann sich jederzeit zurückziehen, weil die Teams brauchbare, funktionierende Software liefern, es geht also nie darum, Verluste zu reduzieren. Hier sieht der Cone of Uncertainty einen enormen Wert, da Sie Vorhersagen darüber treffen können, wann bestimmte Arbeiten erledigt sein könnten, und diese Vorhersagen auch verwenden können, um festzustellen, welche Arbeiten wichtiger sind.
Kegel der Unsicherheit ohne Verpflichtungen
Dieser Ansatz ist weitaus üblicher, wenn das Team, das die Arbeit erledigt, intern zur Organisation gehört, aber ich habe mit Gruppen gearbeitet, bei denen sie im Grunde für den Kunden angestellt sind und dieses Modell verwenden können. Bei diesem Ansatz haben die Teams einige Erfolgsmaßstäbe wie Betriebszeit, reduzierte manuelle Arbeit usw., die sie verwenden, um die Arbeit zu priorisieren. Sie arbeiten mit dem Kunden zusammen, um die Nadel bei diesen Maßnahmen zu bewegen. Dadurch wird das Projektmodell vollständig aufgegeben und Sie sehen daher nicht so viele Burn-up-Diagramme und Unsicherheitskegel in Gesprächen. Sie tauchen jedoch von Zeit zu Zeit auf, insbesondere bei langfristigen Bemühungen. Ich könnte zum Beispiel denken, dass ein Plattform-Upgrade all diese Maßnahmen stark ankurbeln wird, aber es wird ein paar Monate dauern. Drei Wochen in, Ich kann diesen Kegel der Unsicherheit nutzen, um zu sehen, ob diese drei Monate so verlaufen, wie ich dachte. Vielleicht dauert es viel länger, weil die neue Version der Plattform nur ein Durcheinander ist und es eine bessere Geschäftsentscheidung ist, sie auf den Tisch zu legen, während der Anbieter die Fehler beseitigt.
Abschließend Ihre Situation
Natürlich weiß ich nicht, wie Ihre Umstände sind, welche Art von Arbeit Sie ausüben oder wie Sie Ihre Verträge schreiben. Auf diese Weise haben andere Unternehmen dieses Modell genutzt, aber verschiedene Märkte in verschiedenen Ländern sind mehr oder weniger offen. Selbst wenn der Markt in eine bestimmte Richtung läuft, werden verschiedene Kunden in diesem Markt überall in ihrer Toleranz für Engagement sein. Wenn Unternehmen versuchen, auf diesen Ansatz umzusteigen, sehe ich den größten Erfolg, wenn sie einen Kunden finden, der offen ist, es auszuprobieren, anstatt es einem Kunden aufzuzwingen, und nach einem Team suchen, das sich freiwillig für diese Methode einsetzt, anstatt das Team dazu zu zwingen .
Ich spekuliere, dass "Engagement" in einem unbestimmten/mehrdeutigen Sinne verwendet wird.
Wir können Engagements nicht aufschieben – aber wir können die eingesetzten Ressourcen kontrollieren. Die meisten Organisationen haben einige Gateways, die Projekte passieren müssen, und diese Gateways hängen stark vom „Kegel der Unsicherheit“ ab. In meiner Organisation gibt es ein Gateway am Ende des Anforderungsprozesses und ein zweites Gateway am Ende des Designprozesses. Jede davon dient dazu, zu kontrollieren, wie viel Ungewissheit im Projekt verbleibt. Bis zum dritten Gateway stellen wir keine vollen Ressourcen bereit; Bis zu diesem Zeitpunkt haben wir nur vorläufige Zusagen gemacht. (Unsere Zahlen deuten darauf hin, dass 2/3 der Kosten nach diesem dritten Gateway anfallen).
Dies hat auch den Effekt eines „Aufschiebens der Arbeit“, bis der Unsicherheitskegel enger wird. Wir beginnen mit der Produktion erst, wenn wir die Entwicklung abgeschlossen haben.
In diesem Licht betrachtet ist die Aussage ... irgendwie offensichtlich ...
Unsere Projekte sind intern; Wir arbeiten nicht nach einem Vertrag, sondern nach einem internen Stakeholder/einer internen Verpflichtung. Abgesehen davon glaube ich, dass einige Organisationen ähnliche Dinge tun - z. B. Vertrag zur Fertigstellung des Designs, mit der Erwartung eines Entwicklungsvertrags, wenn der Designvertrag erfolgreich ist usw.
Bottom Line Up Front
Wie könnten wir die Verpflichtung zu Schätzungen im wirklichen Leben hinauszögern?
Wenn eine End-to-End-Schätzung im Voraus erforderlich ist , kann man nicht zögern. Wenn der Ansatz in eine iterative und kollaborative Arbeitsweise geändert werden kann, ist jede Iteration eine Verzögerung und besser einschätzbar.
Wie ist das dann in der Praxis anwendbar?
Es ist wichtig zu verstehen, dass man sich über die Zukunft umso weniger sicher sein kann, je weniger man weiß, insbesondere über komplexe Arbeit; Die Sicherheit steigt, je näher die Arbeit kommt. Seine Anwendung variiert je nach Ansatz.
Traditionelles Projektmanagement wurzelt in Herstellungsverfahren, die auf Fredrick Taylor und seinem Schüler Gantt basieren. Die Idee ist, dass durch das Arbeiten in Phasen, in denen eine Gruppe von Spezialisten Ergebnisse erstellt, die an die nächste Gruppe von Spezialisten weitergegeben werden, verschiedene Aspekte des Projekts (insbesondere Kosten, Umfang, Zeitplan) effektiver kontrolliert werden können. Es ist sehr erfolgreich in einfachen Bereichen und hatte Erfolg in komplizierten Bereichen. (Für Domänendefinitionen siehe Cynefin .)
Diese Ideen wurden auf die Softwareentwicklung falsch angewendet, was zum Aufkommen des Wasserfalls führte, da Royces Artikel Managing the Development of Large Software Systems falsch gelesen wurde . Viele der Probleme wurden dokumentiert, darunter Fred Brooks offenes retrospektives Buch The Mythical Man-Month , die Komplexität einer einzelnen Phase wird in Software Requirements: Are They Really A Problem von Bell & Thayer und im jährlichen CHAOS Report hervorgehoben .
In den 1990er Jahren wurden mehrere Ansätze entwickelt, um diese Probleme anzugehen: Scrum und eXtreme Prgramming sind zwei der bekanntesten. 17 Personen hinter diesen Ansätzen kamen 2001 zusammen, um zu diskutieren, was sie lernten und taten. Ihr Ergebnis war die Erstellung des Manifests für agile Softwareentwicklung . Die daraus resultierende Philosophie aus vier Werten und zwölf Prinzipien ist eine Zusammenfassung und allgemeine Richtlinie für den Erfolg.
Bei der Anwendung auf das traditionelle Fertigungsmodell erkennt der Kegel der Unsicherheit die Realität an: Alle anfänglichen Schätzungen sind sehr ungenau. Aus diesem Grund wird das Auffüllen von Schätzungen so häufig verwendet. Bereichsschätzungen wären ehrlicher und würden durch den Kegel unterstützt, werden aber nicht oft gesehen, da sie für die meisten Projektmanagementsysteme oder traditionellen Geschäftsverträge nicht konkret genug sind. Nach der Annahme wird Wert darauf gelegt, alles vollständig zu dokumentieren und zu entwerfen, um zu versuchen, die jetzt vertraglich vereinbarte Erwartung zu erfüllen oder die anfänglichen Schätzungen zu validieren. Wenn sich das Projekt dem Abgabetermin nähert, sind Projektionen normalerweise genauer, wie durch den Kegel beschrieben. Personal kann hinzugefügt werden, Änderungsprozesse für Anforderungen (Umfang) werden durchgesetzt und es kann ein Nachtrag für zusätzliche Zeit ausgehandelt werden.
Bei der Verwendung moderner Softwareproduktentwicklungsansätze kann jede Iteration als eigenes Projekt mit größerer Vorhersagbarkeit betrachtet werden. Eine Vision und kein starrer Plan, die tägliche Zusammenarbeit zwischen Kunde und Hersteller, die Erstellung kleiner Inkremente an qualitativ hochwertiger und benutzerfreundlicher Software und die kontinuierliche Neubewertung der Kundenbedürfnisse und der Effektivität der Lösung sind von grundlegender Bedeutung. Diese Praktiken führen dazu, dass Risiken reduziert werden und die Schätzung genauer und präziser wird, da der Unsicherheitskegel für jede kurze Iteration der Bemühungen schmal bleibt. Der Unsicherheitskegel wird dann zu einem Prognoseinstrument, sobald sich ein relativ konstantes Tempo etabliert hat. Je weiter man nach vorne schaut, desto ungenauer und präziser ist diese Schätzung.
Der gute Umgang mit probabilistischen Ergebnissen in jeder Organisation erfordert einen hohen Grad an Projektreife innerhalb dieser Organisation. Ich glaube, es ist sehr schwer, einen hohen Reifegrad zu erreichen und ihn dann zu halten, wenn man dort ist. Meiner Erfahrung nach und selbst in meinem Unternehmen, das sich intensiv auf PM konzentriert, habe ich nur wenige wirklich ausgereifte PM-Fähigkeiten in einem Unternehmen erlebt.
Dann sind normale menschliche Vorurteile im Spiel, die uns dazu bringen, Risiken in unserer Welt abzutun oder herunterzuspielen, in der wir sehr optimistisch in unsere Zukunft blicken und in der wir glauben, dass wir weitaus mehr Kontrolle über die unendliche Anzahl von Arbeitsvariablen haben, die sich auswirken Ergebnisse als wir wirklich tun. Selbst bei einer sehr ausgereiften PM-Organisation verschwinden diese Vorurteile also nie.
Schließlich haben wir bei einer Käufer-Verkäufer-Vereinbarung andere Geschäftsfaktoren im Spiel, die die Vereinbarung fester Verpflichtungen vorschreiben, obwohl dies nicht mit guten PM-Praktiken vereinbar ist. Schließlich kommen Terminverschiebungen und Projektüberschreitungen normalerweise den Einnahmen des Verkäufers zugute, es sei denn, Sie haben den richtigen Vertrag, um dies zu verhindern. Das bedeutet in der Regel Verpflichtungen, lange bevor ein Projekt beginnt.
Johannes v
Daniel