Perché i grandi progetti IT tendono a fallire o hanno grandi costi / pianificazioni? [chiuso]

Ho sempre letto progetti di trasformazione o integrazione su larga scala che sono disastri totali o quasi totali. Anche se in qualche modo riescono ad avere successo, i costi e gli orari sono enormi. Qual è la vera ragione dietro i grandi progetti che sono più inclini al fallimento. Può essere agile essere utilizzato in questo tipo di progetti o l'approccio tradizionale è ancora il migliore.

Un esempio dall'Australia è il progetto del Queensland Payroll in cui hanno cambiato i criteri di successo dei test per consegnare il progetto.
Vedi alcuni altri progetti falliti in questa domanda SO ( su Wayback Machine )

Hai qualche esperienza personale da condividere?

Il motivo principale è un aumento della portata , che il libro "Il programmatore pragmatico" descrive come:

• gonfiori di funzionalità
• featurismo strisciante
• requisito creep

È un aspetto della sindrome della rana bollita.

L'idea dei vari metodi "agili" è quella di accelerare il feedback e - si spera - correggere l'evoluzione del progetto nel tempo.

Ma l'altro motivo è la gestione delle versioni : se non sei orientato a rilasciare il progetto (per quanto imperfetto possa essere), è probabile che fallirà (perché rilasciato troppo tardi, con troppe funzionalità errate e più difficile da correggere / aggiornare / l'aggiornamento).

Ciò non significa che devi avere una data di rilascio fissa, ma ciò significa che devi essere sempre in grado di costruire una versione in esecuzione del tuo programma, al fine di testarlo / valutarlo / rilasciarlo.

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

So che la cosa da fare "Realizzare" sarebbe quella di flettere l'ambito e mantenere fissa la data di lancio, ma ciò non funziona se si concordano funzionalità che non possono essere completate in tempo.

Ecco perché non sosteniamo specifiche o "funzionalità concordate". Questa è la radice del problema: dire che sai tutto su ciò di cui hai bisogno e su come verrà implementato anche prima che il primo pixel sia disegnato o che la riga di codice sia scritta .

Quando prevedi un futuro rigido su un regalo flessibile, sei nei guai. I futures rigidi sono tra le cose più pericolose. Non lasciano spazio a scoperte, emergenze ed errori che aprono nuove porte.

Di solito la complessità del progetto è sottovalutata .

Steve McConnell (di fama "Code Complete") ha un elenco degli errori classici .

Alcune pratiche di sviluppo inefficaci sono state scelte così spesso, da così tante persone, con risultati così prevedibili e negativi che meritano di essere chiamati "errori classici" ...

Questa sezione elenca tre dozzine di errori classici. Ho visto personalmente ciascuno di questi errori commessi almeno una volta e ne ho fatti molti da solo ...

Il comune denominatore in questo elenco è che non si otterrà necessariamente uno sviluppo rapido se si evita l'errore, ma si otterrà sicuramente uno sviluppo lento se non lo si evita ...

Per facilità di riferimento, l'elenco è stato diviso in base alle dimensioni della velocità di sviluppo di persone, processo, prodotto e tecnologia.

Persone

# 1: motivazione indebolita ...

# 2: personale debole ...

# 3: dipendenti con problemi incontrollati ...

# 4: Heroics ...

# 5: aggiunta di persone a un progetto in ritardo ...

# 6: uffici rumorosi e affollati ...

# 7: attrito tra sviluppatori e clienti ...

# 8: aspettative non realistiche ...

# 9: mancanza di un'efficace sponsorizzazione del progetto ...

# 10: mancanza di buy-in degli stakeholder ...

# 11: mancanza di input dell'utente ...

# 12: Politica posta sulla sostanza ...

# 13: pio desiderio ...

Processi

# 14: Programmi eccessivamente ottimisti ...

# 15: Gestione del rischio insufficiente ...

16: fallimento dell'appaltatore ...

17: Pianificazione insufficiente ...

# 18: Abbandono della pianificazione sotto pressione ...

# 19: tempo perso durante il front end fuzzy. Il "front end fuzzy" è il tempo prima dell'inizio del progetto, il tempo normalmente impiegato nel processo di approvazione e budget ...

# 20: Attività a monte modificate ... Conosciuto anche come "saltare in programmazione" ...

21: design inadeguato ...

# 22: garanzia di qualità modificata ...

# 23: Controlli di gestione insufficienti ...

# 24: convergenza prematura o troppo frequente. Poco prima che un prodotto sia programmato per essere rilasciato, c'è una spinta per preparare il prodotto al rilascio: migliorare le prestazioni del prodotto, stampare la documentazione finale, incorporare i ganci del sistema di aiuto finale, lucidare il programma di installazione, stub funzionalità che non sarà pronto in tempo, e così via ...

# 25: omettere le attività necessarie dalle stime ...

# 26: Pianificazione di recuperare più tardi ...

# 27: Programmazione simile al codice. Alcune organizzazioni pensano che la codifica veloce, libera e all-as-you-go sia una via per un rapido sviluppo ...

Prodotto

# 28: requisiti di doratura. Alcuni progetti hanno più requisiti di quelli necessari fin dall'inizio ...

# 29: Creep Feature ...

# 30: placcatura in oro per gli sviluppatori. Gli sviluppatori sono affascinati dalle nuove tecnologie e talvolta sono ansiosi di provare nuove funzionalità ... - se è richiesto o meno nel loro prodotto ...

# 31: spingimi, tirami trattativa ...

# 32: sviluppo orientato alla ricerca. Seymour Cray, il progettista dei supercomputer Cray, afferma di non tentare di superare i limiti ingegneristici in più di due aree alla volta perché il rischio di fallimento è troppo elevato (Gilb 1988). Molti progetti software potrebbero imparare una lezione da Cray ...

Tecnologia

# 33: Sindrome del proiettile d'argento ...

# 34: Risparmio sopravvalutato da nuovi strumenti o metodi ... Un caso speciale di risparmio sopravvalutato sorge quando i progetti riutilizzano il codice di progetti precedenti ...

# 35: Cambio di strumenti nel mezzo di un progetto ...

# 36: Mancanza di controllo automatizzato del codice sorgente ...

Progetto più ampio = Più complessità
Più complessità = Più incertezze
Altre incertezze = Più difficile da stimare
Più difficile da stimare = Stime
sbagliate Stime sbagliate = Superamenti

Incolpo il processo di offerta. Ricompensa il gruppo che può rendere l'affare più economico / 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 sospese. Conosco persone che hanno specificato switch normali anziché POE per risparmiare $ 80. Ma il progetto aveva bisogno di POE perché aveva telecamere IP. Che $ 80 devono essere spesi, ma ora è al di fuori delle specifiche.

Sono fermamente convinto che un progetto di $ 2,000,000 da 2 mesi richiederà ancora 2 $ $ 2,000,000 indipendentemente da quante offerte ricevi. Se pensi che farlo nel modo giusto sia costoso, aspetta e vedi quanto costa farlo nel modo sbagliato.

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 esempio quadratica a causa della crescente complessità, della durata del progetto più lunga (più tempo per le modifiche ai requisiti) ecc. La stima è duro, e più grande è il progetto, più diventa difficile stimare correttamente.

Un altro motivo sono le stime basate sull'ottimizzazione: per vincere l'offerta, vengono utilizzate le stime del caso migliore per calcolare il prezzo. Più grande è il progetto, meno probabile è uno scenario ottimale. Le regole di offerta rendono probabile che l'offerente più ottimista ottenga l'accettazione, quindi anche se 5 fornitori effettuano una stima realistica e il 6 ° è troppo ottimista, quello ottimista vince l'offerta e fallisce in seguito. 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" , ma restereste sorpresi da quante persone pensano che i problemi diminuiscano in profondità in relazione alla quantità di denaro che viene loro lanciata. La cattiva gestione dei progetti, che spesso si manifesta sotto forma di micro gestione, è la causa principale della maggior parte dei progetti di tank (secondo la mia esperienza). La micro gestione entra in gioco quando la "gestione" si rende conto che qualcosa sta andando fuori controllo e non hanno idea del perché.

Quando questa non è la causa, il risultato atteso del progetto probabilmente non era sostenibile all'inizio. Nella mia esperienza, se il lasso di tempo di un progetto è troppo breve, le persone avranno così paura di commettere errori che si traducono in un "doppio lavoro" da non riuscire a fare molto.

Questo è il motivo per cui 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 sarebbe in gestione a lungo, motivo per cui molti di noi (in definitiva) rispondono agli MBA anziché ai dottorandi.

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

Di tanto in tanto ti imbatti in qualcosa di ben pianificato, ben compreso, realistico e apparentemente semplice. Per qualunque motivo, a sei mesi dallo sviluppo, tutto si è invertito. Succede. Raramente, tuttavia, è che la causa alla base di un progetto diventa una botte di maiale glorificata.

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

Il più delle volte una combinazione di due o più dei seguenti:

• problema di collaborazione tra dipartimenti
• politica ... troppa politica ...
• squadra sbagliata
• programmazione non realistica
• cambiando 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", provano a fare un'enorme analisi (di nuovo un anno avanti) pensando che copriranno tutte le possibilità e, in seguito, trasformando 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 per le cattive notizie ("non possiamo avere ciò che vogliamo per ciò che possiamo permetterci") per farne la catena di comando. Meno probabilmente le cattive notizie possono farne parte della catena di comando, più è probabile che un piano fantasy venga accettato e poi tenuto in sospeso dopo che è noto che è insostenibile.

I progetti software di tutte le dimensioni "tendono a fallire" o "hanno sovraccarichi di costi". Non si sente circa il superamento dei costi presso l'azienda dietro l'angolo, ma si fanno sentire di cose come il sistema Caso virtuale FBI, o il sistema di gestione dei bagagli Denver Airport. Quindi farò valere che non tutti i sistemi di grandi dimensioni falliscono, né tutti i sistemi di grandi dimensioni hanno sovraccarichi di costi / pianificazione.

Mi sono imbattuto in grandi sistemi che sono arrivati ​​in tempo (il programma si è spostato una e una sola volta durante il progetto) e su specifiche (non avevo accesso alle informazioni di bilancio in quanto eravamo solo 1 di molti fornitori). Uno che mi colpisce ancora (e ne ho scritto un po 'su questo sito) è stato un grande sistema integrato di gestione dei clienti per un grande cliente finanziario (nei primi 100 della fortuna 500). Stimo che hanno soffiato circa $ 100k / giorno (per più di un anno) sugli stipendi delle persone durante le teleconferenze.

Nel caso del sistema di gestione dei bagagli, i gestori del software hanno dichiarato "sulla base di progetti di queste dimensioni e complessità, ci vorranno 4 anni per costruire e eseguire il debug di questo sistema". I direttori delle vendite e dei dirigenti hanno dichiarato "l'aeroporto si aprirà 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 mismanager è una semplice risposta alla seguente domanda: "il sistema di gestione dei bagagli era in ritardo o in orario?"

Se il cliente sa esattamente cosa vuole (e pochissimi lo fanno), sarà molto lontano nel percorso per tenere sotto controllo costi e tempi (e queste sono le persone che tendono a fare offshoring abbastanza bene). Se il tuo progetto deve soddisfare ogni singola possibile caratteristica che i tuoi clienti possono eventualmente immaginare e ogni singolo dipartimento ha il diritto di veto su quando i loro mattoncini d'oro da compagnia vengono aggiunti al progetto, allora sei condannato a respingere il fallimento dall'inizio (come quello dell'FBI Progetto VCF).

Percezione della realtà

Ecco la migliore descrizione di questo problema che abbia mai trovato. Altalena dell'albero da businessballs.com

Mi è stato subito introdotto il concetto di "Perception of Reality" nella mia carriera di programmatore. Per questo sono veramente grato. Credo che questo sia il motivo principale per cui un progetto fallisce, non solo per i progetti IT .

Una ragione per i fallimenti è che un grande progetto è di solito un progetto di alto profilo, importante per il business. Quando progetti e compiti sono di alto profilo, incoraggia le persone a mentire.

Il tuo capo vuole che tu stimi il tuo stato di completamento nella parte alta. Vuole stimare sovraccarichi e ritardi nella parte bassa. Quando si verifica un problema, non vuole sentire che aggiungerà tre settimane all'attività; vuole sentire che puoi farcela tra un paio d'ore stasera.

E così via e così via.

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

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

Ho avuto la possibilità di lanciare il progetto quando hanno cambiato le tecnologie in uno in cui non ero abile. Ho parlato con qualcuno molto più tardi. Il progetto ha finito per essere annullato quando era quasi a metà ... a 12 mesi e 35 milioni di dollari.

Grandi progetti di alto profilo scoraggiano la gente a dire "questo è un errore". Gli errori non sono tollerati.

Elaborando un po 'la risposta di VonC:

Questi grandi progetti tendono ad avere una mentalità "tutto o niente". Il progetto, come definito, deve essere rilasciato in una volta sola - spesso perché è un passaggio da un sistema esistente.

Ciò significa che i problemi di scorrimento delle caratteristiche / requisiti sono più difficili da affrontare, quindi quando il progetto si concretizza spesso viene visto come non soddisfare più i requisiti. Ciò può essere aggravato se il sistema esistente è stato aggiornato o la tecnologia è passata nel frattempo.

Qual è la soluzione a questo?

Non so davvero perché nessuno vuole avere due sistemi in esecuzione in parallelo con un insieme mutevole di funzioni divise tra i due.

La complessità di un grande progetto può essere selvaggiamente esacerbata da pressioni politiche esterne. Un dipartimento può avere un'idea molto chiara e focalizzata di ciò che vogliono nel nuovo sistema, ma poi i dipartimenti associati entrano in contatto con dozzine di richieste sulla falsariga di "Bene, finché lo fai, perché non lo fai? fai questo piccolo compito secondario anche per noi? " Potresti iniziare dicendo "No, questo è fuori portata", ma poi iniziano i combattimenti politici tra i disordini 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 è stata in grado di cercare targhe parziali attraverso il sistema dei veicoli a motore, una caratteristica che sembra assurdamente semplice. Ho chiesto a un amico cosa diavolo fosse così difficile aggiungere questa funzione, e mi hanno detto che ogni volta che proponevano di passare a un database moderno, ogni altro dipartimento dello stato che aveva qualche interazione con il sistema automobilistico voleva ottenere la loro parte di anche il sistema risolto. Il risultato è stato il completo gird-lock nella modernizzazione IT. Alla fine lo stato ha messo insieme abbastanza capitali per compiere uno sforzo di ammodernamento a livello di sistema, che poi si è indebolito perché era così orribilmente complesso.

Un fattore che è stato toccato ma non ancora affrontato:

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 esclusi da qualcuno che ha fatto una stima sbagliata.

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

Michael Krigsman su ZDNet ha un blog dedicato a " Fallimenti dei progetti IT ", che potrebbe essere di interesse qui.

Un altro punto è che con progetti lunghi che durano anni, ci saranno generalmente aggiornamenti da prendere in considerazione o soluzioni alternative, ad esempio un progetto ora potrebbe essere realizzato nel cloud rispetto al sito per qualcosa che inizia a venire sempre più, che nel considerare questi non erano scontati quando è stato avviato il progetto. Ad esempio, mentre si potrebbe iniziare mentre qualcosa è a 6.0, prima che la prima fase sia terminata ci potrebbe essere un 6,3 o 6,4 e la domanda su quando aggiornare viene chiesto. Cambiamenti nel campo di applicazione e funzionalità desiderate, sia perché i requisiti non sono stati raccolti correttamente o qualcuno ha cambiato idea, sono un altro paio di punti che sono già stati coperti un bel po '.

Può essere agile essere utilizzato in questo tipo di progetti o l'approccio tradizionale è ancora il migliore.

Il motivo per cui i processi agili ben applicati non sembrano soffrire di questo problema tanto è per una semplice ragione. Non è possibile avviare un grande progetto 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 per le prossime due settimane. Quando la tua visione è così breve, devi scendere a compromessi. Non puoi mai iniziare con un piano per creare "L'ultima parola nei widget", per qualsiasi tipo di widget che stai progettando. Al massimo, puoi iniziare con "Un widget che può capovolgere", poiché si tratta della maggior parte del lavoro che puoi svolgere in una o due iterazioni.

La cosa positiva di questo è che dopo alcune iterazioni, hai già un prodotto completo e funzionante che qualcuno può trovare utile, in particolare quel cliente che ha un disperato bisogno di un widget che può capovolgere e zort.

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

• Mancata spedizione agli utenti effettivi

I grandi progetti hanno una brutta tendenza a entrare in modalità "infrastruttura" per anni, dimenticando di costruire funzionalità per gli utenti finali e di spedirle. Al momento della spedizione, è molto costoso cambiare, e di solito i più grandi cambiamenti concettuali finiscono per essere richiesti dopo il primo vero beta test.

• Mancata stima accurata dei costi

Se i progetti sembrano superare il loro ritorno sugli investimenti, vengono annullati.

• Mancato controllo della qualità

Con abbastanza difetti è possibile che lo slancio in avanti scenda a zero o al di sotto. Senza alcun progresso, è difficile discutere della continuazione dell'esistenza.

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

Cose che ho visto nello sviluppo Web:

• Troppi cuochi: il maggiore rivenditore B&M in cui l'enfasi si è improvvisamente spostata sul web. Improvvisamente 20 capi dipartimento stanno raccordando ogni iniziativa per impressionare il nuovo capo formaggio. Una volta ho dovuto implementare nuove icone perché al legale non piaceva l'aspetto di quelle vecchie.

• Attenzione eccessiva al confronto delle specifiche rispetto al raggiungimento degli obiettivi - "Le icone di IE6 sono leggermente sbiadite rispetto a quelle di IE7. Per favore lascia cadere quel lavoro critico per la data di lancio che stai facendo e occupati del 0,05% della nostra base di clienti per fare cose orribili che richiederanno giorni per implementare e rallentare ancora di più l'esperienza di IE ".

• Bad Tools scelti da non sviluppatori che non potevano nemmeno preoccuparsi di chiedere consigli ai loro sviluppatori interni.

• Dev cattivi scelti dagli strumenti - "Perché pagare 20 sviluppatori Java competenti con uno stipendio decente quando possiamo esternalizzare 200 ragazzi letterati a malapena in codice che sanno troppo poco per usare il controllo delle versioni?" poiché contemporaneamente e con persone di diversi paesi, lavorano sui back-end principalmente per 3 app di grandi dimensioni.

• Bad / Broken Architecture - Strati su strati di codice in preda al panico, fai-da-fare-ieri, da persone licenziate o che ora sono manager.