Perché i progetti IT di grandi dimensioni tendono a fallire o superano i costi elevati? [chiuso]

Il motivo principale è un aumento dello scope , che il libro "The Pragmatic Programmer" descrive come:

• feature bloats
• featurism strisciante
• requisito di scorrimento

It is an aspect of the boiled-frog syndrome.

L'idea del diverso metodo "agile" è di accelerare il feedback e - si spera - correggere l'evoluzione del progetto nel tempo.

Ma l'altro motivo è gestione del rilascio : se non sei orientato verso il rilascio del progetto (per quanto imperfetto possa essere), è probabile che fallirà (perché rilasciato troppo tardi, con troppe caratteristiche buggy e più difficile da correggere / aggiornare / aggiornare).

Questo non significa che devi avere una data di rilascio prefissata, ma ciò significa che devi essere in grado in ogni momento di creare una versione del tuo programma in esecuzione, per testarla / valutarla / rilasciarla.

Il post del blog " I progetti in ritardo sono in ritardo un giorno alla volta " contiene molti altri esempi:

I know the ‘Getting Real’ thing to do would be to Flex the scope and keep the launch date fixed, but that doesn’t work if there is agreed upon functionality that cannot be completed in time.

     

Questo è il motivo per cui non difendiamo le specifiche o "concordiamo sulla funzionalità". Questa è la radice del problema - affermando che sai tutto di ciò che ti serve e di come sarà implementato ancor prima che il primo pixel sia dipinto o linea di il codice è scritto.

     

Quando prevedi un futuro rigido su un regalo flessibile, sei nei guai. I futures rigidi sono tra le cose più pericolose. Non lasciano spazio alla scoperta, all'emergenza e agli errori che aprono nuove porte.

In genere la complessità del progetto è sottostimata .

Steve McConnell (di fama "Code Complete") ha una lista degli errori classici .

Some ineffective development practices have been chosen so often, by so many people, with such predictable, bad results that they deserve to be called "classic mistakes"...

This section enumerates three dozen classic mistakes. I have personally seen each of these mistakes made at least once, and I've made many of them myself...

The common denominator in this list is that you won't necessarily get rapid development if you avoid the mistake, but you will definitely get slow development if you don't avoid it...

For ease of reference, the list has been divided along the development-speed dimensions of people, process, product, and technology.

People

#1: Undermined motivation...

#2: Weak personnel...

#3: Uncontrolled problem employees...

#4: Heroics...

#5: Adding people to a late project...

#6: Noisy, crowded offices...

#7: Friction between developers and customers...

#8: Unrealistic expectations...

#9: Lack of effective project sponsorship...

#10: Lack of stakeholder buy-in...

#11: Lack of user input...

#12: Politics placed over substance...

#13: Wishful thinking...

Process

#14: Overly optimistic schedules...

#15: Insufficient risk management...

#16: Contractor failure...

#17: Insufficient planning...

#18: Abandonment of planning under pressure...

#19: Wasted time during the fuzzy front end. The "fuzzy front end" is the time before the project starts, the time normally spent in the approval and budgeting process...

#20: Shortchanged upstream activities... Also known as "jumping into coding"...

#21: Inadequate design...

#22: Shortchanged quality assurance...

#23: Insufficient management controls...

#24: Premature or too frequent convergence. Shortly before a product is scheduled to be released there is a push to prepare the product for release--improve the product's performance, print final documentation, incorporate final help-system hooks, polish the installation program, stub out functionality that's not going to be ready on time, and so on...

#25: Omitting necessary tasks from estimates...

#26: Planning to catch up later...

#27: Code-like-hell programming. Some organizations think that fast, loose, all-as-you-go coding is a route to rapid development...

Product

#28: Requirements gold-plating. Some projects have more requirements than they need right from the beginning...

#29: Feature creep...

#30: Developer gold-plating. Developers are fascinated by new technology and are sometimes anxious to try out new features... -- whether or not it's required in their product...

#31: Push me, pull me negotiation...

#32: Research-oriented development. Seymour Cray, the designer of the Cray supercomputers, says that he does not attempt to exceed engineering limits in more than two areas at a time because the risk of failure is too high (Gilb 1988). Many software projects could learn a lesson from Cray...

Technology

#33: Silver-bullet syndrome...

#34: Overestimated savings from new tools or methods... A special case of overestimated savings arises when projects reuse code from previous projects...

#35: Switching tools in the middle of a project...

#36: Lack of automated source-code control...

Progetto più grande = Più complessità
Più complessità = più incertezze Altre incertezze = più difficile da stimare
Più difficile da stimare = stime errate
Stime errate = superamento dei costi

Do la colpa al processo di offerta. Premia il gruppo che può rendere l'affare più economico / più veloce sulla carta.

Le persone che mettono insieme le offerte non vogliono perdere tempo se non hanno possibilità di vincere, quindi le loro normali stime vengono messe in attesa. Conosco persone che hanno specificato interruttori normali anziché switch POE per risparmiare $ 80. Ma il progetto aveva bisogno di POE perché aveva telecamere IP. Quel $ 80 deve essere speso, ma ora è al di fuori delle specifiche.

Ho la ferma convinzione che un progetto da 2 mesi di $ 2,000,000 richiederà ancora 2 mesi $ 2,000,000 indipendentemente dal numero di offerte ricevute. Se pensi che farlo bene è costoso, aspetta e vedi quanto è costoso farlo male.

Una possibile ragione è che le stime si basano su progetti più piccoli, ipotizzando una crescita lineare dei costi con le dimensioni del progetto, quando in realtà la crescita dei costi è ad es. quadratico a causa della crescente complessità, della durata del progetto più lunga (più tempo per le modifiche dei requisiti) ecc. La stima è difficile, e quanto più grande è il progetto, tanto più difficile è la stima corretta.

Un altro motivo sono stime distorte ottimizm: per vincere l'offerta, le stime migliori vengono utilizzate per calcolare il prezzo. Più grande è il progetto, meno probabile è uno scenario migliore. Le regole di offerta rendono probabile che l'offerente più ottimista ottenga l'accettazione, quindi anche se 5 venditori fanno una stima realistica e il sesto è troppo ottimista, l'ottimista vince l'offerta e fallisce più tardi. Quindi questa è una specie di selezione negativa.

Il costo non preclude il programma agli occhi del "management", che è una distinzione importante da fare. Come sappiamo, "nove donne non possono fare un bambino in un mese" , tuttavia rimarrai sorpreso dal fatto che molte persone pensino che i problemi si riducano in profondità in relazione alla quantità di denaro che è lanciato contro di loro. Una cattiva gestione del progetto, che spesso si manifesta sotto forma di micro gestione, è la causa principale della maggior parte dei progetti di tanking (nella mia esperienza). La gestione micro inizia quando il "management" si rende conto che qualcosa sta andando fuori controllo e non ha alcuna conoscenza del perché.

Quando questa non è la causa, probabilmente il risultato previsto del progetto non era sostenibile. Secondo la mia esperienza, se il periodo di tempo di un progetto è troppo breve, le persone saranno talmente timide di commettere errori che si traducono in "doppio lavoro" da non ottenere gran parte di ciò che viene fatto.

Ecco perché la gestione dovrebbe essere popolata da programmatori esperti che hanno una storia di team leader che hanno prodotto progetti di successo. Una persona del genere potrebbe dire "In nessun modo potremmo farlo in modo responsabile", nonostante le possibili entrate, e non saremmo in gestione a lungo, motivo per cui molti di noi (in definitiva) rispondono agli MBA anziché ai PHD.

Ho perso il conto del numero di aziende per le quali ho lavorato in cui un non programmatore era incaricato di assumere programmatori. Una volta ho avuto un'intervista in cui il gestore delle assunzioni non voleva fare altro che discutere di un recente evento sportivo (penso fosse una partita di calcio). Se la persona che hai in carica attira più ispirazione da un allenatore della NFL rispetto a Knuth, il progetto sarà completato.

Una volta ogni tanto ti imbatti in qualcosa che era ben pianificato, ben compreso, realistico e apparentemente semplice. Per qualsiasi motivo, sei mesi in sviluppo, tutto si è invertito. Succede. Raramente, tuttavia, è la causa alla base di un progetto che diventa un barile di maiale glorificato.

Tuttavia, devo ammettere che ... se guardi la notizia, potresti vedere occasionalmente un incidente motociclistico o un incidente ferroviario. Non si sente mai parlare di milioni di motocicli o treni che arrivano puntualmente ogni giorno senza incidenti. Lo stesso vale per i progetti. Certo, è interessante vedere un'autopsia pubblica di qualcosa che è andata davvero male, ma non si sente quasi mai parlare di cose che sono andate davvero bene. Penso che i progetti affondati siano ancora l'eccezione, non la norma.

La maggior parte delle volte una combinazione di due o più dei seguenti elementi:

• problema di collaborazione tra reparti
• politica ... troppa politica ...
• squadra sbagliata
• programmazione non realistica
• modifica dell'ambito senza la metodologia appropriata
• informazioni mancanti

Bel libro sull'argomento: Death March .

Le persone tendono a pensare che lo sviluppo del software sia un processo predittivo, cercando di misurare e stimare le cose con un anno di anticipo. Non è possibile! Il software di costruzione non è la produzione di bulloni.

Seguendo la stessa "tendenza", cercano di fare un'enorme analisi (sempre un anno prima) pensando che copriranno tutte le possibilità e, successivamente, trasformeranno il programmatore in semplici dattilografi. Come mai uno pensa che questo potrebbe funzionare? Questo tipo di comportamento porta solo a stime sbagliate e molta burocrazia.

Più grande è il progetto, più è probabile che tu stia lavorando per una grande organizzazione. Più grande è l'organizzazione, più livelli di gestione. Più livelli di gestione, più difficile è la cattiva notizia ("non possiamo avere quello che vogliamo per quello che possiamo permetterci") per farne la catena di comando. Le cattive notizie meno probabili possono far salire la catena di comando, più è probabile che un piano fantasy venga accettato e poi mantenuto a lungo dopo che è noto essere insostenibile.

I progetti software di tutte le dimensioni "tendono a fallire" o "hanno un costo eccessivo". Non si sente il costo del superamento del business dietro l'angolo, ma si fa si sente parlare di cose come il sistema FBI Virtual Case o il sistema di gestione bagagli di Denver Airport. Quindi farò l'affermazione che non tutti i sistemi di grandi dimensioni falliscono, né tutti i sistemi di grandi dimensioni hanno sovraccarichi di costo / programma.

Mi sono imbattuto in grandi sistemi arrivati in tempo (la pianificazione si è spostata una volta e solo una volta durante il progetto) e su specifiche (non ho avuto accesso alle informazioni di budget perché eravamo solo 1 di molti fornitori). Uno che mi impressiona ancora (e ne ho scritto un po 'su questo sito) è stato un grande sistema integrato di gestione dei clienti per un grande cliente finanziario (nella prima 100 della fortuna 500). Stimo che abbiano fatto saltare circa $ 100.000 al giorno (per più di un anno) sui salari delle persone durante le conference call.

Nel caso del sistema di gestione dei bagagli, i responsabili del software hanno affermato che "sulla base di progetti di queste dimensioni e complessità, ci vorranno 4 anni per costruire ed eseguire il debug di questo sistema". I direttori delle vendite e dei dirigenti hanno detto che "l'aeroporto si apre in 2 anni, abbiamo detto al cliente che ci vorranno 2 anni, quindi hai 2 anni per farlo". Il test per vedere se sei un programmatore o un manager sbagliato è una semplice risposta alla seguente domanda: "il sistema di smistamento bagagli è in ritardo o in orario?"

Se il cliente sa esattamente quello che vuole (e pochi lo fanno), sarà molto lontano lungo il percorso per tenere sotto controllo i costi e il tempo (e questi sono quelli che tendono a fare abbastanza bene offshoring). Se il tuo progetto deve soddisfare ogni singola funzione possibile che i tuoi clienti possano immaginare, e ogni singolo dipartimento ha il potere di veto su quando i loro mattoni d'oro vengono aggiunti al progetto, allora sei destinato a fallire fin dall'inizio (come l'FBI Progetto VCF).

Percezione della realtà

Ecco la migliore descrizione di questo problema che abbia mai trovato. Tree Swing da businessballs.com

Sono stato introdotto al concetto di "Percezione della realtà" all'inizio della mia carriera di programmatore. Per questo sono davvero grato. Credo che questo sia il motivo principale per cui un progetto fallisce, non solo per i progetti IT .

Un motivo per i fallimenti è che un grande progetto è solitamente un progetto aziendale di alto profilo, importante per il business. Quando progetti e attività sono di alto profilo, incoraggia le persone a mentire.

Il tuo capo vuole che tu valuti il tuo stato di completamento sul lato alto. Vuole stimare eccedenze e ritardi sul lato basso. Quando incontri un problema, non vuole sentire che aggiungerà tre settimane al compito; vuole sentire che puoi farcela entro un paio d'ore stasera.

E così via e così via.

Ero su un progetto diversi anni fa, per un cliente. Sono stato portato dopo che l'offerta e il piano del progetto sono stati completati. C'era una pressione costante per andare più veloce, più veloce e ridicole decisioni di taglio dei costi, pesante sovraccarico del personale, nessuna risorsa per loro; niente banchi, computer, niente.

Infine, ho scoperto che il progetto era stato offerto a 7 mesi e 16 milioni di dollari. Ho stimato sul retro di una busta che dovrebbe essere di 24 mesi e da 50 a 100 milioni. Ho organizzato un incontro con il mio manager e il suo manager, e ho presentato il mio caso, e come NON stavamo arrivando da nessuna parte vicino a consegnare in tempo o budget; hanno minimizzato tutti i problemi. Alla fine dell'incontro, il CIO ha chiamato e detto a entrambi i dirigenti essenzialmente ciò che ho detto, ad eccezione del difetto nell'offerta originale.

Ho avuto la possibilità di chiudere il progetto quando hanno cambiato tecnologia a uno di cui non ero abile. Ho parlato con qualcuno molto più tardi. Il progetto è stato cancellato quando era quasi a metà ... a 12 mesi e 35 milioni di dollari.

Grandi progetti di alto profilo scoraggiano le persone dicendo "questo è un errore". Gli errori non sono tollerati.

Elaborazione un po 'sulla risposta di VonC:

Questi grandi progetti tendono ad avere una mentalità "tutto o niente". Il progetto come definito deve essere rilasciato in un colpo solo - spesso come se fosse un passaggio da un sistema esistente.

Questo significa che i problemi di scorrimento delle funzionalità / dei requisiti sono più difficili da affrontare, quindi quando il progetto viene a buon fine è spesso visto come non più necessario soddisfare i requisiti. Questo può essere esacerbato se il sistema esistente è stato aggiornato o la tecnologia si è spostata nel frattempo.

Qual è la soluzione a questo?

In realtà non so come nessuno voglia avere due sistemi in esecuzione in parallelo con un set di funzioni che si divide tra i due.

La complessità del grande progetto può essere selvaggiamente esacerbata da pressioni politiche esterne. Un dipartimento può avere un'idea molto chiara e focalizzata di ciò che vuole nel nuovo sistema, ma poi i dipartimenti associati saltano dentro con dozzine di richieste sulla falsariga di "Bene, finché lo fai, perché non lo fai? fare questo piccolo compito secondario anche per noi? " Potresti iniziare col dire "No, è fuori dal campo di applicazione". Ma poi inizia la lotta politica tra le parti, e il budget per il progetto è minacciato a meno che tutti non ottengano il loro pezzo di torta.

Per anni, la nostra polizia locale non è riuscita a cercare le piastre parziali attraverso il sistema di veicoli a motore, una caratteristica che sembra assurdamente semplice. Ho chiesto ad un amico che cosa fosse così difficile aggiungere questa funzione, e hanno detto che ogni volta che proponevano di passare a un database moderno, ogni altro dipartimento dello stato che avesse avuto qualche interazione con il sistema automobilistico voleva ottenere la loro parte di anche il sistema è stato riparato. Il risultato è stato un completo gird-lock nella modernizzazione dell'IT. Alla fine lo stato ha messo insieme abbastanza capitali per fare uno sforzo di ammodernamento sistematico, che poi è fallito perché era così terribilmente complesso.

Un fattore che è stato toccato ma non ancora trattato:

Quasi tutti i drammatici fallimenti sono contratti che sono stati offerti. Cosa succede a un'azienda competente in una situazione del genere? Fanno una stima realistica e quindi sono quasi certamente sottovalutati da qualcuno che ha fatto una stima sbagliata.

Se la società non è in grado di stimare correttamente, è sorprendente che non possano costruire correttamente un sistema?

Michael Krigsman su ZDNet ha un blog dedicato a " IT Project Failures ", che potrebbe interessare qui.

Un altro punto è che con progetti lunghi che durano anni, generalmente ci saranno aggiornamenti da considerare o soluzioni alternative, ad es. un progetto potrebbe ora essere fatto nel cloud contro il sito per qualcosa che sta iniziando a emergere sempre di più, che nel considerare questi non era un dato quando il progetto è stato avviato. Ad esempio, mentre si potrebbe iniziare mentre qualcosa è a 6.0, nel momento in cui viene eseguita la prima fase potrebbe esserci un 6.3 o 6.4 e la domanda su quando eseguire l'aggiornamento viene richiesta. Le modifiche al campo di applicazione e alle funzionalità desiderate, sia perché i requisiti non sono stati raccolti correttamente, sia che qualcuno ha cambiato idea, sono un altro paio di punti che sono già stati trattati un bel po '.

Can agile be used in these sort of projects or traditional approach is still the best.

Il motivo per cui i processi agili applicati bene non sembrano soffrire di questo problema tanto per un semplice motivo. Non è possibile avviare un progetto di grandi dimensioni in modo agile. Puoi scegliere l'uno o l'altro.

Con un processo agile, non stai mai guardando oltre una o due iterazioni nel futuro del progetto. non esiste un "piano" per i prossimi 2 anni, solo le prossime due settimane. Quando la tua opinione è così breve, devi fare alcuni compromessi. Non puoi mai iniziare con un piano per creare "L'ultima parola nei widget", per qualunque tipo di widget tu stia progettando. Al massimo, puoi iniziare con "Un widget che può tremare", perché questo è il lavoro che puoi svolgere in una o due iterazioni.

Il bello di tutto ciò è che dopo alcune iterazioni hai già un prodotto funzionante e completo che qualcuno può trovare utile, specialmente un cliente che ha un disperato bisogno di un widget che possa frob e zort .

Essenzialmente, i progetti di grandi dimensioni possono fallire perché mirano a risolvere tutti i problemi di tutti i potenziali clienti. Un progetto agile non ha mai questo obiettivo, ma indirizza in ogni versione solo un problema critico che potrebbe avere un singolo cliente. Dopo un po 'di tempo, tuttavia, un progetto agile potrebbe risolvere molti problemi critici per molti clienti.

• Mancato recapito agli utenti effettivi

I grandi progetti hanno una brutta tendenza ad entrare in modalità "infrastruttura" per anni, e dimenticano di costruire funzionalità reali per l'utente finale e di spedirle. Nel momento in cui viene spedito, è molto costoso cambiare e di solito i maggiori cambiamenti concettuali vengono chiesti dopo la prima vera beta testing.

• Errore nella stima accurata del costo

Se i progetti sembrano supereranno il loro ritorno sull'investimento, verranno cancellati.

• Mancato controllo della qualità

Con abbastanza difetti è possibile che lo slancio in avanti scenda a zero o sotto. Senza alcun progresso, è difficile sostenere la continuità dell'esistenza.

Hanno dimenticato la legge di Hofstadter: ci vuole sempre più tempo del previsto, anche se si tiene conto della legge di Hofstadter.

Cose che ho visto nello sviluppo Web:

• Troppi cuochi: rivenditore principale di B & M dove l'enfasi si è improvvisamente spostata sul web. All'improvviso 20 capi di dipartimento stanno prendendo in giro ogni iniziativa per impressionare il nuovo formaggio di testa. Una volta ho dovuto implementare nuove icone perché non mi piaceva l'aspetto delle vecchie.

• Focalizzazione eccessiva sull'abbinamento delle specifiche rispetto al raggiungimento degli obiettivi - "Le icone di IE6 sono leggermente sbiadite rispetto a quelle di IE7. Per favore lascia perdere il lavoro critico in fase di lancio e occupati di .05% della nostra base clienti cose orribili che impiegheranno giorni per implementare e rallentare ancora di più l'esperienza di IE. "

• Strumenti danneggiati scelti da non-sviluppatori che non si sono nemmeno preoccupati di chiedere consigli ai propri sviluppatori interni.

• I cattivi sviluppatori scelgono gli strumenti - "Perché pagare 20 sviluppatori Java competenti per un salario decente quando possiamo esternalizzare 200 persone a conoscenza del codice a malapena che sanno troppo poco per usare il controllo di versione?" mentre lavorano simultaneamente e con persone in paesi diversi, lavorano principalmente sui back-end per 3 app di grandi dimensioni.

• Architettura danneggiata / interrotta - Livelli su strati di codice preso dal panico, "fatto da ieri", da persone che sono state licenziate o che sono ora responsabili.