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

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?

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.

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

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 ...

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

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.

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.

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.

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 .

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.

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.

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).

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.

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.

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.

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.

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?

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.

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.

• 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.

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

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.