Wie kann ich zuverlässigere Schätzungen für Technologieaktualisierungsprojekte erstellen?

Nachdem ich einige Projekte durchgeführt habe, die die Technologie auffrischen, anstatt Funktionalität hinzuzufügen, sind mir einige wiederkehrende Themen aufgefallen:

  • Technologieaktualisierungsprojekte überschreiten mit größerer Wahrscheinlichkeit das Budget/den Zeitplan; Projekte, die inkrementelle neue Funktionen bieten, überschreiten mit geringerer Wahrscheinlichkeit Budget- und Zeitplanschätzungen.
  • Entwicklungsteams neigen eher dazu, Technologieaktualisierungsprojekte zu unterschätzen.
    • Neue Funktionen haben in der Regel klar definierte Anforderungen.
    • Alte Funktionalität ist immer eine Entdeckungsreise, insbesondere bei weit verbreiteten Produkten mit einer Geschichte von kundengesteuerten Korrekturen und Verbesserungen.
    • Ein großer Teil dieses verborgenen Erbes kommt erst zum Vorschein, nachdem das Team die Chance hat, ernsthafte Fortschritte beim Refactoring zu erzielen.

All dies macht eine frühzeitige Machbarkeitsbewertung und ROI-Analyse bei solchen Projekten zu einer Herausforderung.

Ich habe zwei Techniken ausprobiert, um dies zu beheben. Eine Technik besteht darin, den Schätzungen des Teams eine konstante Steuer hinzuzufügen, aber das kann grob und ungenau sein, da Refactoring-Projekte nicht gleich geboren werden. Eine andere besteht darin, Schätzungen und Planungsprognosen zu verschieben, bis das Team angemessene Anstrengungen unternommen hat, um die versteckten Kosten auszuräumen. Dies funktioniert jedoch nicht immer, da manchmal solch ein angemessener Aufwand an sich teuer ist und/oder das Geschäft eine frühzeitige Priorisierung erfordert.

Mich würde das kollektive Wissen von Leuten interessieren, die solche Projekte durchgeführt haben. Wie kann ich bei der Planung einer Technologieaktualisierung eine angemessene Vorhersehbarkeit erreichen?

Ihre Frage wurde leicht bearbeitet, hauptsächlich um die Listen generierende Meinungsumfrage zu entfernen. PMSE erfordert Fragen, die zumindest die Möglichkeit einer kanonischen Antwort zulassen, und keine Listen von Listen. Eine Frage sollte versuchen, ein Problem zu lösen, nicht eine Konstellation von Möglichkeiten erkunden.

Antworten (2)

Ich habe nicht genug Erfahrung, um diese Hypothese zu bestätigen oder zu widerlegen. Das heißt, wenn ich in der Position wäre, würde ich das minimal mögliche Refactoring-Projekt vorschlagen (ähnlich wie meine akademischen Kollegen früher die "am wenigsten veröffentlichbare Einheit" hatten). Fehler) eine Reihe von sogenannten latenten, unausgesprochenen kulturellen Anforderungen (eng verwandt mit „Stammeswissen“ und „Prozessressourcen der Organisation“).

Lassen Sie uns also ein Projekt starten, um die am wenigsten vorstellbare Technologieaktualisierung durchzuführen. Das setzt ein Team (und noch wichtiger in der Kommunikation) mit den Stakeholdern zusammen, die diese neuen Anforderungen plötzlich offenlegen. Wenn wir ein 1-monatiges Projekt beauftragen, um eine triviale Technologieaktualisierung durchzuführen. ("Jeder bekommt eine neue Maus"), die uns einen Parameter liefern sollte, mit dem wir die Genauigkeit größerer Technologieaktualisierungsprojekte verbessern können.

Ich glaube nicht, dass sich die Genauigkeit um eine Größenordnung verbessern wird. Ich denke, dies würde bestenfalls besser dazu beitragen, Interessenvertreter im Schrank aufzudecken (und / oder Zombie-Stakeholder - Sie kennen die - Sie können dies nicht ändern, weil Bob vor 10 Jahren in den Ruhestand getreten ist und vor 3 Jahren gestorben ist ... Bob hat es festgelegt Sie können diesen Arbeitsablauf also nur von seinem Schreibtisch aus erledigen und nicht an einem Freitag....)

Also im Wesentlichen eine Spitze, um das MVP für die Projektcharta zu entdecken?
Ich denke schon, aber ich habe versucht, die Verwendung von Wörtern zu vermeiden, für deren Verwendung ich nicht zertifiziert bin.
Dies ist definitiv im Stadion – Stammeswissen und Zombie-Stakeholder sind sehr gute Begriffe, die für dieses Problem einzigartig sind. Meine Erfahrung ist, dass wir normalerweise technische Fallstricke aufdecken, die Menschen im Laufe der Jahre gebaut und maskiert haben. Eine Spike-Aufgabe zu haben, ist eine Möglichkeit, damit umzugehen. Ich werde die Antwort akzeptieren, da sie nahe ist und die Frage eine Weile offen war.

Nach meinen Beobachtungen in dieser Branche im Laufe der Jahre bin ich nicht der Meinung, dass IT-Projekte unter etwas anderem leiden als jedes andere Projekt in anderen Bereichen. Was ich sehe, ist ein branchenspezifischer Druck, der auf IT-Projekte ausgeübt wird, die andere Domänen ausgearbeitet haben. Es besteht ein erheblicher Druck, den Projektpreis niedrig zu halten, nur um das Projekt auszuwählen. Dies beginnt lange bevor irgendeine Art von Angebotsanfrage für IT-Anbieter auf die Straße kommt, und dann beginnt der nächste Druck für einen niedrigen Ballpreis.

Im föderalen Bereich hier in den USA gibt es einen Drang, alles zu einem festen Festpreis zu bekommen, auch für Projekte, bei denen der föderale Kunde nicht einmal wirklich weiß, was er will und während des Projekts "entdeckt" wird. Kein anderer Branchenanbieter würde jemals einen solchen Vertrag abschließen, aber IT-Anbieter tun dies ständig. Kann sich irgendjemand einen Bauunternehmer vorstellen, der sich für einen Bauvertrag zum Festpreis anmeldet, um ein „Haus irgendwo hier drüben“ zu bauen?

Unterschätzung tritt in allen Projekten auf, weil es sich um eine menschliche Voreingenommenheit handelt, die als Optimismusvoreingenommenheit bezeichnet wird. Aber die anderen Schätzmethoden helfen, dies zu kontrollieren, z. B. die Verwendung historischer Daten, Parametrik, Delphi-Technik usw. Bevor Sie diese bewährten Methoden verwenden, muss dieser Druck zur Preisillusion jedoch gelöst werden.

Danke für die Antwort, aber meine Frage bezog sich nicht auf IT-Projekte im Allgemeinen, sondern speziell auf Technologieersatz/Refaktorisierung.
Meine Antwort würde sich nicht ändern, egal wie spezifisch Sie innerhalb der IT werden möchten. Ich denke der Druck ist der gleiche. Aber es gibt auch keine spezifische Antwort auf eine Frage wie diese. Dies sind nur meine Beobachtungen in diesem Bereich.
sich verpflichten, ein Haus mit einer unbestimmten Anzahl von Schlafzimmern zu bauen, das für ein unbestimmtes Klima geeignet ist, sich an unbestimmte Vorschriften hält und einen unbekannten Geschmack anspricht. Das ist die Bundesregierung, die „Bring mir einen Stein“ in „Bau mir etwas und ich sage dir, dass es mir nicht gefällt, wenn du fertig bist. Oh, und es muss der Unternehmensarchitektur entsprechen, die wir ablehnen erlauben, geschrieben zu werden, und muss agil sein."
Das ist urkomisch und zu genau!
Genau - ich suchte nach Erfahrungen von Leuten, die Refactoring-Projekte durchführen. Laut meinem Beitrag sind nicht alle Arten von IT-Projekten gleich, und ich würde eine andere Schätztechnik für das Refactoring eines Kernelmoduls anwenden als für den Aufbau eines Portals für Regierungsdienste. Jedenfalls habe ich auf dem Weg einen Einblick in Bundesprojekte bekommen - werde im Auge behalten, falls und wenn welche in meine Richtung gehen.
David, ich stimme Ihrem Beitrag im Allgemeinen zu und möchte positiv abstimmen, aber während dies das Problem erklärt , wird keine Lösung empfohlen. Welche Kontrollen würden Sie speziell vorschlagen, um in einem Technologie-Ersatzprojekt auf Bestätigungsverzerrung oder fehlende Spezifikationen zu kontrollieren?
@CodeGnome, wenn ich diese Frage beantworten könnte, wäre ich jetzt wohlhabend und im Ruhestand. In meiner Firma haben wir Kontrollen, die dabei helfen sollen, aber die Angebotsteams lernen, wie sie um sie herum navigieren, und diese Kontrollen stehen auch unter dem Druck, nicht das zu tun, wofür sie vorgesehen sind; stattdessen den Anschein erwecken, das zu tun, was es tun soll. Ich kenne die Lösung nicht.
@DavidEspina Es ist dieser letzte Satz: "Aber die anderen Schätzmethoden helfen, das zu kontrollieren. Es würde auch in der IT funktionieren, wenn wir sie tatsächlich verwenden würden." Für mich implizierte das, dass Sie dachten, es gäbe eine konkrete Lösung. Vielleicht wenn du es bearbeitet hast? Ich stimme zu, dass es derzeit keine bekannte Lösung gibt; nur Minderungen, von denen agile Praktiken (unter anderem) einige Optionen bieten.
Die Lösung sind nicht die Schätztechniken – Delphi-Methode, 3-Punkte, historische Daten usw. – denn das ist nicht das Problem, das die IT plagt. Das Problem ist eher der Druck, eine Preisillusion zu erzeugen. Die Lösung muss um diesen Druck herum liegen, dem wir ausgesetzt sind. Ich hoffe das ergibt Sinn.
Können Sie die Antwort aktualisieren, um die in diesen Kommentaren besprochenen Probleme zu beheben. Ich denke, „der Druck der Preisillusion“ ist zu wertvoll, um ihn zu verlieren.
@DavidEspina du liegst sicherlich nicht falsch, aber ich verstehe nicht, wie dies die Frage beantwortet. Bearbeiten Sie möglicherweise einige Ihrer Kommentare in der Antwort.
Ich denke, das ist ein komplexes Thema im IT-Bereich. Durch meine begrenzten Beobachtungen habe ich die Hypothese aufgestellt, dass es der Druck ist, die Dinge in der IT billig aussehen zu lassen, als Grundursache für diese unrealistischen Preispunkte, die wir tendenziell verwenden. Ich kann die Hypothese zu diesem Zeitpunkt weder testen, noch kann ich eine Lösung dafür entwickeln. Ich denke, dies ist eines dieser Probleme, die noch einer Lösung bedürfen, bei denen eine Antwort auf diese Frage noch nicht wirklich gegeben werden kann. Zumindest sehe ich das so. Ich kann dieser Antwort nicht weiter nachgehen.
Wie kann ich zuverlässigere Schätzungen für Technologieaktualisierungsprojekte erstellen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v