Warum scheitern große IT-Projekte oder haben große Kosten- / Terminüberschreitungen? [geschlossen]

34

Ich habe immer über große Transformations- oder Integrationsprojekte gelesen, die eine totale oder fast totale Katastrophe darstellen. Selbst wenn sie es irgendwie schaffen, Erfolg zu haben, sind die Kosten und der Zeitplan enorm. Was ist der wahre Grund dafür, dass große Projekte anfälliger für Misserfolge sind? Kann Agile in solchen Projekten eingesetzt werden oder ist der traditionelle Ansatz immer noch der beste.

Ein Beispiel aus Australien ist das Queensland Payroll-Projekt, bei dem die Kriterien für den Testerfolg geändert wurden, um das Projekt durchzuführen.
Weitere fehlgeschlagene Projekte in dieser SO-Frage anzeigen ( auf Wayback Machine )

Haben Sie persönliche Erfahrungen zu teilen?

Pratik
quelle
10
Eine merkwürdige Sache an diesem Problem ist, dass Entwickler und Manager in der Regel völlig unterschiedliche Antworten geben.
Mojuba
3
@mojuba Ich bin beide, und ich antwortete. Ich hoffe, dass dies nicht zur Diagnose einer multiplen Persönlichkeitsstörung führt.
Tim Post
1
Agil ist am besten, wenn der Kunde nicht weiß, was er will. Unternehmen sind im Allgemeinen nicht bereit, die enormen Beträge, die in Zeitungen fließen, für schlecht definierte Projekte auszugeben.
Tangurena
1
Dies ist nicht nur in der Software-Welt der Fall.
Job
1
Ein derart massives Projektversagen scheint häufiger in staatlichen Institutionen als in der Privatwirtschaft aufzutreten, oder es scheint zumindest häufiger in den Nachrichten zu sein.
Bratch

Antworten:

34

Der Hauptgrund ist eine Erweiterung des Umfangs , die das Buch "The Pragmatic Programmer" beschreibt als:

  • Feature Blähungen
  • schleichender featurismus
  • Anforderung kriechen

Es ist ein Aspekt des Boiled-Frog-Syndroms.

Die Idee der verschiedenen "agilen" Methoden ist es, das Feedback zu beschleunigen und - hoffentlich - die zeitliche Entwicklung des Projekts zu korrigieren.

Der andere Grund ist das Release-Management : Wenn Sie nicht darauf ausgerichtet sind, das Projekt zu veröffentlichen (so unvollkommen es auch sein mag), schlägt es wahrscheinlich fehl (weil es zu spät veröffentlicht wird, zu viele fehlerhafte Funktionen enthält und schwieriger zu reparieren ist / update / Aktualisierung).

Das bedeutet nicht, dass Sie einen festen Veröffentlichungstermin haben müssen, aber das bedeutet, dass Sie jederzeit in der Lage sein müssen, eine laufende Version Ihres Programms zu erstellen, um es zu testen, zu evaluieren und zu veröffentlichen.


Der Blog-Beitrag " Späte Projekte sind einen Tag zu spät " enthält viele weitere Beispiele:

Ich weiß, dass die Sache mit "Getting Real" darin besteht, den Umfang zu ändern und den Starttermin festzulegen, aber das funktioniert nicht, wenn eine vereinbarte Funktionalität vorliegt, die nicht rechtzeitig abgeschlossen werden kann.

Aus diesem Grund befürworten wir keine Spezifikationen oder „vereinbarten Funktionen“. Das ist die Wurzel des Problems: Sie wissen alles darüber, was Sie brauchen und wie es implementiert werden soll, noch bevor das erste Pixel gezeichnet oder eine Codezeile geschrieben wird .

Wenn Sie eine starre Zukunft für eine flexible Gegenwart vorhersagen, stecken Sie in Schwierigkeiten. Starre Futures gehören zu den gefährlichsten Dingen. Sie lassen keinen Raum für Entdeckungen, Entstehen und Fehler, die neue Türen öffnen.

VonC
quelle
1
Ich markiere dies als Antwort, obwohl es auch in anderen Beiträgen gute Punkte gibt. Ich stimme zu, dass der Fokus auf "Release Management" für große Projekte sehr wichtig ist.
Softveda
29

In der Regel wird die Komplexität des Projekts unterschätzt .

Amir Rezaei
quelle
2
+1: obwohl ich es vielleicht grob unterschätzt habe
Ken Henderson
@Confused Ich mag "falsch eingeschätzt" . Ich hätte nie gedacht, dass dieser Begriff so alt ist!
Mark C
Dann füge ich meiner Frage "Warum wird Komplexität unterschätzt?" Hinzu. Die Abschätzung von Umfang und Komplexität ist Teil von SDLC. Unterschätzen ist für mich also ein Symptom, keine Ursache.
Softveda
2
Es gibt viele Gründe zu unterschätzen. Ich möchte auf einige Punkte hinweisen: In einem komplexen Projekt kann eine sehr kleine Änderung sehr große Auswirkungen haben. Man könnte also sagen, dass dies keine kleine Veränderung war, sondern eine große. Es gibt jedoch die Meinung, dass etwas, das sehr einfach zu implementieren ist, keine große Sache sein sollte. Tatsächlich kann eine kleine Änderung der Geschäftslogik große Auswirkungen haben, da das Projekt komplex ist. Andere Ursachen: Budgetmangel, der zu weniger Zeit in „Analyse und Design“ führt. "Versuch und Irrtum" -Mentalität, anstatt mehr Zeit in "Analyse und Design" zu investieren. Mangel an Kompetenz.
Amir Rezaei
2
@Pratik, Komplexität wird oft unterschätzt, weil Programmierer (ich eingeschlossen) die Komplexität eines Projekts notorisch schlecht einschätzen. Dies liegt wahrscheinlich daran, dass Sie beim ersten Nachdenken über ein Projekt nur den allgemeinen Umriss sehen, aber nicht die Tausenden kleiner Details, die sich direkt unter der Oberfläche verbergen. Wenn ich zum Beispiel ein neues Webprojekt vorstelle, muss ich mich dem Instinkt widersetzen, zu denken: "Das ist einfach - ich werfe einfach eine Datenbank und etwas Front-End-Javascript-Code zusammen. Ich sollte in ungefähr einer Woche fertig sein." Aber so einfach ist das natürlich noch nie.
Charles Salvia
18

Steve McConnell (von "Code Complete") hat eine Liste der klassischen Fehler .

Einige ineffektive Entwicklungspraktiken wurden so oft von so vielen Menschen mit so vorhersehbaren, schlechten Ergebnissen ausgewählt, dass sie es verdienen, als "klassische Fehler" bezeichnet zu werden ...

In diesem Abschnitt werden drei Dutzend klassische Fehler aufgelistet. Ich habe persönlich gesehen, dass jeder dieser Fehler mindestens einmal gemacht wurde, und ich habe viele von ihnen selbst gemacht ...

Der gemeinsame Nenner in dieser Liste ist, dass Sie nicht unbedingt eine schnelle Entwicklung bekommen, wenn Sie den Fehler vermeiden, aber Sie werden definitiv eine langsame Entwicklung bekommen, wenn Sie es nicht vermeiden ...

Zur Vereinfachung der Bezugnahme wurde die Liste nach den Dimensionen der Entwicklungsgeschwindigkeit von Personen, Prozessen, Produkten und Technologien unterteilt.

Menschen

# 1: Untergrabene Motivation ...

# 2: Schwaches Personal ...

# 3: Unkontrollierte Problemmitarbeiter ...

# 4: Heroics ...

# 5: Hinzufügen von Personen zu einem späten Projekt ...

# 6: Laut, überfüllte Büros ...

# 7: Reibung zwischen Entwicklern und Kunden ...

# 8: Unrealistische Erwartungen ...

# 9: Mangelnde effektive Projektförderung ...

# 10: Fehlendes Stakeholder-Buy-in ...

# 11: Fehlende Benutzereingaben ...

# 12: Politik über Substanz gestellt ...

# 13: Wunschdenken ...

Verarbeiten

# 14: Zu optimistische Zeitpläne ...

# 15: Unzureichendes Risikomanagement ...

# 16: Auftragnehmerfehler ...

# 17: Unzureichende Planung ...

# 18: Planungsabbruch unter Druck ...

# 19: Zeitverschwendung während des Fuzzy-Frontends. Das "Fuzzy-Front-End" ist die Zeit vor dem Start des Projekts, die normalerweise für den Genehmigungs- und Budgetierungsprozess aufgewendet wird.

# 20: Shortchanged Upstream-Aktivitäten ... Auch bekannt als "Jumping in Coding" ...

# 21: Unangemessenes Design ...

# 22: Fehlende Qualitätssicherung ...

# 23: Unzureichende Verwaltungskontrollen ...

# 24: Vorzeitige oder zu häufige Konvergenz. Kurz bevor die Veröffentlichung eines Produkts geplant ist, wird versucht, das Produkt für die Veröffentlichung vorzubereiten. Verbessern Sie die Leistung des Produkts, drucken Sie die endgültige Dokumentation aus, fügen Sie die endgültigen Hilfesystem-Hooks ein, polieren Sie das Installationsprogramm und stellen Sie Funktionen bereit, die nicht möglich sind pünktlich fertig und so weiter ...

# 25: Notwendige Aufgaben aus Schätzungen weglassen ...

# 26: Wir wollen später aufholen ...

# 27: Code-like-Hell-Programmierung. Einige Unternehmen sind der Meinung, dass eine schnelle, lockere Codierung im Handumdrehen ein Weg zu einer raschen Entwicklung ist ...

Produkt

# 28: Anforderungen Vergoldung. Einige Projekte haben von Anfang an mehr Anforderungen als sie benötigen ...

# 29: Feature schleichen ...

# 30: Entwicklervergoldung. Entwickler sind fasziniert von neuen Technologien und sind manchmal bestrebt, neue Funktionen auszuprobieren ... - unabhängig davon, ob dies in ihrem Produkt erforderlich ist oder nicht ...

# 31: Schieben Sie mich, ziehen Sie mich Verhandlung ...

# 32: Forschungsorientierte Entwicklung. Seymour Cray, der Konstrukteur der Cray-Supercomputer, sagt, er versuche nicht, in mehr als zwei Bereichen gleichzeitig technische Grenzen zu überschreiten, weil das Risiko eines Ausfalls zu hoch sei (Gilb 1988). Viele Softwareprojekte könnten eine Lektion von Cray lernen ...

Technologie

# 33: Silberkugel-Syndrom ...

# 34: Überschätzte Einsparungen durch neue Tools oder Methoden ... Ein besonderer Fall von überschätzten Einsparungen ergibt sich, wenn Projekte Code aus früheren Projekten wiederverwenden ...

# 35: Werkzeugwechsel mitten in einem Projekt ...

# 36: Keine automatisierte Quellcode-Kontrolle ...

Mücke
quelle
Übrigens, herzlichen Glückwunsch!
Mark C
14

Größeres Projekt = Mehr Komplexität
Mehr Komplexität = Mehr Unsicherheiten
Mehr Unsicherheiten = Schwieriger abzuschätzen Schwieriger abzuschätzen
= Schlechte Schätzungen
Schlechte Schätzungen = Kostenüberschreitungen

JohnFx
quelle
Aber warum sind "schlechte Schätzungen" immer zu niedrige Schätzungen?
Romanoza
Nach meiner Erfahrung zwei Dinge. Die Person, die um die Schätzung bittet, versucht zu verhandeln, und die Person, die sie gibt, beugt sich dem Druck. Zweitens erkennt die Person, die die Schätzung abgibt, nicht, wie viel Gleitzeit für das Wechseln und Kommunizieren von Aufgaben erforderlich ist. Sie arbeiten auch unter der falschen Annahme, dass es sich bei der gesamten Arbeit um Programmierung handelt, aber viel Zeit für die Projektmanagementkommunikation muss berücksichtigt werden.
JohnFx
12

Ich beschuldige das Bieterverfahren. Es belohnt die Gruppe, die das Geschäft auf dem Papier am billigsten / schnellsten aussehen lässt.

Die Leute, die Gebote abgeben, wollen ihre Zeit nicht verschwenden, wenn sie keine Gewinnchance haben, so dass ihre normalen Schätzungen auf Eis gelegt werden. Ich kenne Leute, die normale Schalter anstelle von POE-Schaltern angegeben haben, um 80 Dollar zu sparen. Das Projekt benötigte jedoch POE, da es über IP-Kameras verfügte. Diese $ 80 müssen ausgegeben werden, aber jetzt ist es außerhalb der Spezifikation.

Ich bin der festen Überzeugung, dass ein 2-Monats-Projekt im Wert von 2.000.000 USD noch 2 Monate im Wert von 2.000.000 USD dauern wird, unabhängig davon, wie viele Gebote Sie erhalten. Wenn Sie denken, dass es teuer ist, es richtig zu machen, warten Sie ab, wie teuer es ist, es falsch zu machen.

U / min mcotton
quelle
Ich kann den Satz "Ich habe eine feste Überzeugung ..." nicht verstehen - sollte der zweite Teil stattdessen "2 Monate und 2 Millionen Dollar ..." lauten?
Mark C
6

Ein möglicher Grund ist, dass Schätzungen auf kleineren Projekten basieren, wobei ein lineares Kostenwachstum mit der Projektgröße angenommen wird, während das Kostenwachstum z. B. aufgrund zunehmender Komplexität, längerer Projektdauer (mehr Zeit für Anforderungsänderungen) usw. quadratisch ist schwer, und je größer das Projekt, desto schwieriger wird es, richtig abzuschätzen.

Ein weiterer Grund sind optimistische voreingenommene Schätzungen: Um das Gebot zu gewinnen, werden Best-Case-Schätzungen verwendet, um den Preis zu berechnen. Je größer das Projekt ist, desto unwahrscheinlicher ist ein Best-Case-Szenario. Gebotsregeln machen es wahrscheinlich, dass der optimistischste Anbieter die Akzeptanz erhält. Selbst wenn fünf Anbieter eine realistische Schätzung vornehmen und der sechste zu optimistisch ist, gewinnt der optimistische Anbieter das Gebot und scheitert später. Das ist also eine Art negative Auswahl.

user281377
quelle
+1 für den Optimismus Bias. Ich kenne einige Projekte, die in verschiedenen Schwierigkeiten stecken, und alle haben diesen Fehler gemeinsam. Oft jedoch, weil sie mit einer vernünftigen Schätzung begannen, aber der Kunde sagte, "wir machen das nur für eine Million Dollar weniger", und das Management des Auftragnehmers entschied sich dafür, N-1 Million Dollar statt Null zu bekommen, obwohl sie keine hatten Grund zu der Annahme, sie könnten es liefern.
Tom Anderson
4

Die Kosten schließen aus Sicht des Managements einen Zeitplan nicht aus, der eine wichtige Unterscheidung darstellt. Wie wir wissen, "neun Frauen können in einem Monat kein Baby bekommen" , wundern Sie sich jedoch darüber, wie viele Menschen glauben, dass die Probleme im Verhältnis zum Geldbetrag, der auf sie geworfen wird, immer geringer werden. Schlechtes Projektmanagement, das sich häufig in Form von Mikromanagement manifestiert, ist nach meiner Erfahrung die häufigste Ursache für das Betanken von Projekten. Mikromanagement setzt ein, wenn „Management“ feststellt, dass etwas außer Kontrolle gerät und sie keine Ahnung haben, warum.

Wenn dies nicht der Grund ist, war das erwartete Ergebnis des Projekts wahrscheinlich nicht von Anfang an haltbar. Wenn der zeitliche Rahmen eines Projekts zu kurz ist, haben die Leute meiner Erfahrung nach solche Angst, Fehler zu machen, die zu „doppelter Arbeit“ führen, dass sie überhaupt nicht viel erledigen.

Aus diesem Grund sollte das Management mit erfahrenen Programmierern besetzt sein, die über eine lange Geschichte führender Teams verfügen, die erfolgreiche Projekte hervorgebracht haben. Solch eine Person könnte sagen "Auf keinen Fall könnten wir das verantwortungsbewusst tun", trotz der möglichen Einnahmen, und wäre nicht lange im Management, weshalb viele von uns (letztendlich) auf MBA's anstatt auf PHD's antworten.

Ich habe die Anzahl der Unternehmen verloren, für die ich gearbeitet habe und für die ein Nicht-Programmierer Programmierer eingestellt hat. Ich hatte einmal ein Interview, in dem der Personalchef nur über ein kürzlich stattgefundenes Sportereignis sprechen wollte (ich denke, es war ein Fußballspiel). Wenn sich die Person, die Sie betreuen, mehr von einem NFL-Trainer als von Knuth inspirieren lässt, geht das Projekt in den Tank.

Hin und wieder stößt man auf etwas, das gut geplant, gut verstanden, realistisch und scheinbar direkt war. Aus irgendeinem Grund kehrte sich nach sechs Monaten der Entwicklung alles um. Es passiert. Selten ist dies jedoch die Ursache dafür, dass ein Projekt zu einem verherrlichten Schweinefleischfaß wird.

Trotzdem muss ich zugeben, wenn Sie sich die Nachrichten ansehen, können Sie gelegentlich einen Motorradunfall oder ein Zugunglück sehen. Man hört nie etwas über die Millionen von Motorrädern oder Zügen, die jeden Tag pünktlich eintreffen, ohne dass es zu Zwischenfällen kommt. Das gleiche gilt für Projekte. Sicher, es ist interessant, eine öffentliche Autopsie von etwas zu sehen, das wirklich, wirklich schlecht gelaufen ist, aber man hört fast nie von Dingen, die wirklich, wirklich gut gelaufen sind. Ich denke, dass Tankprojekte immer noch die Ausnahme sind, nicht die Norm.

Tim Post
quelle
3

Meistens eine Kombination von zwei oder mehr der folgenden:

  • Kollaborationsproblem zwischen Abteilungen
  • Politik ... zu viel Politik ...
  • falsches Team
  • unrealistische Planung
  • Änderung des Geltungsbereichs ohne die entsprechende Methodik
  • fehlende Informationen

Schönes Buch zum Thema: Todesmarsch .

user2567
quelle
3

Die Leute neigen dazu zu denken, dass Softwareentwicklung ein prognostizierender Prozess ist, bei dem versucht wird, Dinge zu messen und zu schätzen, die ein Jahr im Voraus liegen. Das ist nicht möglich! Bausoftware ist keine Schraubenherstellung.

Dem gleichen "Trend" folgend, versuchen sie (erneut ein Jahr im Voraus) eine umfassende Analyse durchzuführen, in der Annahme, dass sie alle Möglichkeiten abdecken und später aus Programmierern reine Schreibkräfte machen. Wie kommt es, dass man denkt, dass das funktionieren könnte? Diese Art von Verhalten führt nur zu schlechten Schätzungen und viel Bürokratie.

Fernando
quelle
Ich stimme vollkommen zu. Es besteht immer eine große Unsicherheit hinsichtlich des Zeitplans und der Kosten großer Projekte. Es ist ein Teil der Softwareentwicklung, IMO. Selbst kleine Projekte sind nicht so einfach genau abzuschätzen.
ConnorsFan
3

Je größer das Projekt, desto wahrscheinlicher ist es, dass Sie für eine große Organisation arbeiten. Je größer die Organisation, desto mehr Managementebenen. Je mehr Führungsebenen vorhanden sind, desto schwieriger ist es für schlechte Nachrichten ("wir können nicht das haben, was wir wollen, für das, was wir uns leisten können"), die Befehlskette zu bilden. Je unwahrscheinlicher schlechte Nachrichten in der Befehlskette sind, desto wahrscheinlicher ist es, dass ein Fantasieplan akzeptiert und lange, nachdem bekannt ist, dass er nicht mehr tragbar ist, aufrechterhalten wird.

Wayne Conrad
quelle
2

Softwareprojekte jeder Größe "neigen zum Scheitern" oder "haben Kostenüberschreitungen". Sie müssen nicht über die Kostenüberschreitung im Geschäft um die Ecke hören, aber Sie tun hören über Dinge wie das FBI virtuellen Fallsystem oder das Gepäck Denver Airport Handling - System. Daher behaupte ich, dass nicht alle großen Systeme ausfallen und auch nicht alle großen Systeme Kosten- / Zeitplanüberschreitungen aufweisen.

Ich habe über große Anlagen kommen , die in auf Zeit kamen (der Zeitplan verschoben einmal und nur einmal während des Projektes) und auf spec (ich hatte keinen Zugang zu Haushaltsinformationen , wie wir nur 1 von vielen Lieferanten waren). Eines, das mich immer noch beeindruckt (und ich habe auf dieser Seite ein wenig darüber geschrieben), war ein großes integriertes Kundenmanagementsystem für einen großen Finanzkunden (in den ersten 100 der Fortune 500). Ich schätze, dass sie während der Telefonkonferenzen etwa 100.000 US-Dollar pro Tag (mehr als ein Jahr lang) auf die Gehälter der Menschen gesprengt haben.

Im Fall des Gepäckfördersystems gaben die Softwaremanager an, dass es bei Projekten dieser Größe und Komplexität 4 Jahre dauern wird, dieses System zu erstellen und zu debuggen. Die Verkaufsleiter und Geschäftsführer sagten: "Der Flughafen wird in 2 Jahren eröffnet. Wir haben dem Kunden mitgeteilt, dass es 2 Jahre dauern wird. Sie haben also 2 Jahre Zeit, dies zu tun." Der Test, ob Sie ein Programmierer oder ein Mismanager sind, ist eine einfache Antwort auf die folgende Frage: "War das Gepäckfördersystem zu spät oder pünktlich?"

Wenn der Kunde genau weiß, was er will (und nur sehr wenige), ist er auf dem Weg, Kosten und Zeit unter Kontrolle zu halten, sehr weit (und das sind die Leute, die Offshoring recht gut machen). Wenn Ihr Projekt jede einzelne Funktion erfüllen muss, die Ihre Kunden sich nur erträumen können, und jede einzelne Abteilung ein Vetorecht hat, wenn ihre Lieblingsgoldbricks zum Projekt hinzugefügt werden, dann sind Sie von Anfang an zum Scheitern verurteilt (wie das FBI) VCF-Projekt).

Tangurena
quelle
2

Wahrnehmung der Realität

Hier ist die beste Beschreibung dieses Problems, die ich je gefunden habe. Baumschaukel Von businessballs.com

Das Konzept der "Wahrnehmung der Realität" wurde mir schon früh in meiner Programmkarriere vorgestellt. Dafür bin ich sehr dankbar. Ich glaube, dass dies der Hauptgrund ist, warum ein Projekt scheitert, nicht nur IT- Projekte.

Michael Riley - AKA Gunny
quelle
2

Ein Grund für Misserfolge ist, dass ein großes Projekt in der Regel ein hochkarätiges, für das Geschäft wichtiges Projekt ist. Wenn Projekte und Aufgaben im Vordergrund stehen, ermutigt es die Menschen, zu lügen.

Ihr Chef möchte, dass Sie Ihren Abschlussstatus hoch einschätzen. Er möchte Überschreitungen und Verzögerungen auf der niedrigen Seite schätzen. Wenn Sie auf ein Problem stoßen, möchte er nicht hören, dass es die Aufgabe um drei Wochen verlängert. er möchte hören, dass du es heute Nacht in ein paar Stunden schaffen kannst.

Und so weiter und so fort.

Ich war vor einigen Jahren bei einem Projekt für einen Kunden. Ich wurde nach Abschluss des Angebots und des Projektplans hinzugezogen. Es bestand ständiger Druck, schneller, schneller und lächerlich Entscheidungen zur Kostenreduzierung zu treffen. keine Schreibtische, Computer, nichts.

Schließlich stellte ich fest, dass das Projekt bei 7 Monaten und 16 Millionen Dollar geboten wurde. Ich schätze auf der Rückseite eines Umschlags, dass es 24 Monate und 50 bis 100 Millionen sein sollte. Ich habe ein Treffen mit meinem Vorgesetzten und seinem Vorgesetzten vereinbart und meinen Fall vorgestellt und festgestellt, dass wir NICHT annähernd pünktlich oder budgetgerecht liefern können. Sie haben alle Probleme heruntergespielt. Am Ende der Sitzung rief der CIO an und teilte diesen beiden Managern im Wesentlichen mit, was ich gesagt hatte, mit Ausnahme des Fehlers im ursprünglichen Angebot.

Ich hatte die Chance, das Projekt abzubrechen, als sie die Technologie auf eine ungeübte umstellten. Ich habe viel später mit jemandem gesprochen. Das Projekt wurde abgebrochen, als es ungefähr zur Hälfte fertig war ... mit 12 Monaten und 35 Millionen Dollar.

Hochkarätige Großprojekte halten die Leute davon ab, zu sagen, "das ist ein Fehler". Fehler werden nicht toleriert.

Ron Ruble
quelle
1

Erläutern Sie kurz die Antwort von VonC:

Diese großen Projekte tendieren dazu, eine "Alles oder Nichts" -Mentalität zu haben. Das definierte Projekt muss auf einmal freigegeben werden - oft als Umstellung auf ein bestehendes System.

Dies bedeutet, dass es schwieriger ist, auf die Probleme mit dem Kriechen von Features / Anforderungen zu reagieren. Wenn das Projekt zum Abschluss kommt, wird es häufig als nicht mehr den Anforderungen entsprechend angesehen. Dies kann sich verschlimmern, wenn das bestehende System aktualisiert wurde oder die Technologie in der Zwischenzeit weiterentwickelt wurde.

Was ist die Lösung dafür?

Ich weiß es nicht genau, da niemand zwei Systeme parallel laufen lassen möchte, wobei sich die Funktionsvielfalt zwischen beiden aufteilt.

ChrisF
quelle
1

Die Komplexität von Großprojekten kann durch externen politischen Druck erheblich verschärft werden. Eine Abteilung hat vielleicht eine sehr klare, fokussierte Vorstellung davon, was sie im neuen System wollen, aber die zugeordneten Abteilungen melden sich mit Dutzenden von Anfragen wie "Nun, solange Sie das tun, warum nicht?" An erledigen Sie diese kleine Nebenaufgabe auch für uns? " Sie könnten mit "Nein, das ist nicht in Reichweite" beginnen, aber dann beginnen die politischen Kämpfe zwischen den Deaprtments und das Budget für das Projekt ist bedroht, es sei denn, jeder bekommt sein Stück vom Kuchen.

Unsere örtliche Polizei konnte jahrelang nicht nach Teilschildern im Fahrzeugsystem suchen, was absurd einfach erscheint. Ich habe einen Freund gefragt, warum es so schwierig ist, diese Funktion hinzuzufügen, und er hat gesagt, dass jedes Mal, wenn er vorschlägt, auf eine moderne Datenbank umzusteigen, jede andere Abteilung des Staates, die mit dem Kraftfahrzeugsystem in Wechselwirkung steht, einen Teil davon haben möchte Das System wurde ebenfalls repariert. Das Ergebnis war eine vollständige Umrüstung der IT-Modernisierung. Schließlich stellte der Staat genügend Kapital zusammen, um systemweite Modernisierungsbemühungen durchzuführen, die dann aufgrund der schrecklichen Komplexität ins Stocken gerieten.

Charles E. Grant
quelle
1

Ein Faktor, der angesprochen, aber noch nicht angesprochen wurde:

Fast alle dramatischen Misserfolge sind Verträge, die ausgeschrieben wurden. Was passiert mit einem kompetenten Unternehmen in einer solchen Situation? Sie machen eine realistische Schätzung und werden daher mit ziemlicher Sicherheit von jemandem unterboten, der eine schlechte Schätzung vorgenommen hat.

Wenn die Firma nicht richtig einschätzen kann, ist es überraschend, dass sie auch kein System richtig bauen kann?

Loren Pechtel
quelle
Sie sind möglicherweise in der Lage, richtig zu schätzen, würden aber lieber das Gebot erhalten und dann Kosten- und Zeitüberschreitungen anstreben, als das Gebot zu verlieren. Dies gilt natürlich für unehrliche Verkäufer.
David Thornley
Eine übliche Strategie ist es, mit einem hochqualifizierten Team auf eigene Kosten zu arbeiten. Sobald der Auftrag gewonnen ist, kann Geld für die Änderungskontrolle und -wartung (letztere ist in der Regel weitaus höher als das ursprüngliche Projekt) und durch die Ersetzung von weniger teurem Personal verdient werden.
Michael Grazebrook
0

Michael Krigsman bei ZDNet hat einen Blog über " IT Project Failures ", der hier von Interesse sein könnte.

Ein weiterer Punkt ist, dass bei langen Projekten, die sich über Jahre erstrecken, in der Regel entweder Upgrades in Betracht gezogen werden müssen oder alternative Lösungen, z Dies war nicht selbstverständlich, als das Projekt gestartet wurde. Zum Beispiel, während man anfangen könnte, während etwas bei 6.0 ist, könnte es zu dem Zeitpunkt, zu dem die erste Phase abgeschlossen ist, einen 6.3 oder 6.4 Ausgang geben und die Frage, wann ein Upgrade durchgeführt werden soll, wird gestellt. Änderungen im Umfang und der gewünschten Funktionalität, entweder weil die Anforderungen nicht korrekt erfasst wurden oder jemand seine Meinung geändert hat, sind weitere Punkte, die bereits ausführlich behandelt wurden.

JB King
quelle
0

Kann Agile in solchen Projekten eingesetzt werden oder ist der traditionelle Ansatz immer noch der beste.

Der Grund, warum gut angewandte agile Prozesse nicht so sehr unter diesem Problem zu leiden scheinen, ist ein einfacher. Sie können ein großes Projekt nicht agil starten. Sie können den einen oder anderen auswählen.

Mit einem agilen Prozess schauen Sie nie wirklich nach ein oder zwei Iterationen in die Zukunft des Projekts. Es gibt keinen Plan für die nächsten zwei Jahre, nur für die nächsten zwei Wochen. Wenn Ihre Sicht so kurz ist, müssen Sie ein paar Kompromisse eingehen. Sie können niemals mit einem Plan beginnen, "Das letzte Wort in Widgets" für jede Art von Widget zu erstellen, die Sie entwerfen. Sie können höchstens mit "Ein Widget, das frobgen kann" beginnen, da dies die meiste Arbeit darstellt, die Sie in ein oder zwei Iterationen erledigen können.

Das Gute daran ist, dass Sie nach ein paar Iterationen bereits ein vollständiges, funktionsfähiges Produkt haben, das jemand nützlich finden kann, insbesondere derjenige Kunde, der dringend ein Widget benötigt, das frobgen und verwenden kann zortieren kann.

Grundsätzlich können große Projekte scheitern, weil sie darauf abzielen, alle Probleme aller potenziellen Kunden zu lösen. Ein agiles Projekt hat niemals dieses Ziel, sondern behandelt in jeder Version nur ein kritisches Problem, das ein einzelner Kunde haben könnte. Nach einer Weile könnte ein agiles Projekt jedoch eine Menge kritischer Probleme für eine Menge Kunden lösen.

SingleNegationElimination
quelle
Das ist nicht wahr. Viele agile Projekte sind umfangreich. In meinem Scrum-Training haben sie darauf hingewiesen, dass es ratsam ist, in den frühen Sprints architektonische Geschichten und wegwerfbare Prototypen zu haben. Sie sind auch nicht auf Software beschränkt - mein Trainer hatte ein Projekt zum Bau eines Hubschraubers und der dazugehörigen Waffensysteme durchgeführt.
Michael Grazebrook
0
  • Fehler beim Versenden an tatsächliche Benutzer

Große Projekte tendieren unangenehm dazu, jahrelang in den "Infrastruktur" -Modus zu wechseln, und vergessen, echte Endbenutzerfunktionen zu erstellen und auszuliefern. Zum Zeitpunkt der Auslieferung ist die Änderung sehr teuer, und in der Regel werden die größten konzeptionellen Änderungen nach dem ersten echten Betatest gefragt.

  • Fehler bei der genauen Schätzung der Kosten

Wenn Projekte so aussehen, als würden sie über ihre Kapitalrendite hinauswachsen, werden sie storniert.

  • Fehler bei der Qualitätskontrolle

Bei genügend Defekten ist es möglich, dass der Vorwärtsimpuls auf Null oder darunter fällt. Ohne Fortschritte ist es schwierig, für den Fortbestand zu argumentieren.

Joeri Sebrechts
quelle
0

Sie haben das Hofstädter-Gesetz vergessen: Es dauert immer länger als erwartet, auch wenn Sie das Hofstädter-Gesetz berücksichtigen.

Brian Carlton
quelle
0

Dinge, die ich in der Webentwicklung gesehen habe:

  • Zu viele Köche - Major B & M Retailer, bei denen der Schwerpunkt plötzlich auf das Internet verlagert wurde. Plötzlich verfolgen 20 Abteilungsleiter jede Initiative, um den neuen Kopfkäse zu beeindrucken. Ich musste einmal neue Icons implementieren, weil legal das Aussehen der alten nicht mochte.

  • Übermäßiger Fokus auf die Übereinstimmung der Spezifikationen über die Erreichung der Ziele - "Die Symbole von IE6 sind im Vergleich zu denen von IE7 etwas verblasst. Bitte lassen Sie die für das Startdatum wichtige Arbeit, die Sie ausführen, fallen und kümmern Sie sich um 0,05% unserer Kunden, um schreckliche Dinge zu erledigen, die Tage dauern werden die IE-Erfahrung noch mehr zu implementieren und zu verlangsamen. "

  • Bad Tools wurden von Nicht-Entwicklern ausgewählt, die nicht einmal die Mühe hatten, ihre internen Entwickler um Rat zu fragen.

  • Von Tools ausgewählte böse Entwickler - "Warum 20 kompetente Java-Entwickler ein anständiges Gehalt zahlen, wenn wir 200 Leute mit Barcode-Kenntnissen auslagern können, die zu wenig wissen, um die Versionskontrolle zu verwenden?" Da sie gleichzeitig und mit Menschen in verschiedenen Ländern arbeiten, arbeiten sie an den Backends hauptsächlich für 3 große Apps.

  • Schlechte / kaputte Architektur - Schichtenweise in Panik geratener Code, der von Personen erstellt wurde, die entlassen wurden oder jetzt Manager sind.

Erik Reppen
quelle