Progetto fallito: quando chiamarlo?

Qualche mese fa la mia azienda si è trovata con le mani attorno a un'emergenza rovente di un progetto, e tutto il mio team di sei persone ha realizzato una "settimana di crisi" di cinque settimane. Nelle 48 ore prima di andare a vivere, ho lavorato 41 di loro, due da dietro a tutti. Nel mezzo di ciò, ho pubblicato quella che è stata la mia domanda di maggior successo fino ad oggi .

Durante tutto quel tempo non si è mai parlato di "fallimento". Era sempre "farlo, indipendentemente dal dolore".

Ora che la cosa è finita e noi come organizzazione abbiamo avuto del tempo per sederci e fare un bilancio di ciò che abbiamo appreso, mi è venuta una domanda. Non posso dire di aver mai preso parte a un progetto che direi "fallito". Molti erano in ritardo o sopra il budget, alcuni in modo disastroso, ma ho sempre finito per offrire QUALCOSA.

Eppure sento sempre parlare di "progetti IT falliti". Mi chiedo dell'esperienza delle persone con questo. Quali erano i parametri che definivano "fallimento"? Qual era il contesto? Nel nostro caso, siamo un negozio di software con clienti esterni. Un progetto interno a una grande azienda ha più spazio per "fallire"? Quando effettui quella chiamata? Cosa succede quando lo fai?

Non sono affatto convinto che fare ciò che abbiamo fatto sia una mossa aziendale intelligente. Non è stata la mia chiamata (sono solo una scimmia di codice) ma mi chiedo se sarebbe stato meglio tagliare le nostre perdite, dire che non stiamo consegnando e andare avanti. Non dico solo che a causa del pungere delle lunghe ore - la società ha perso la camicia sul progetto, in più i costi immateriali per la società in termini di morale e lealtà dei dipendenti erano grandi . Fattore che contro il colpo di PR di non riuscire a consegnare un progetto di alto profilo come questo era ... e non so quale sia la risposta giusta.

Il concetto di fallimento è in realtà una chiamata legata al mondo degli affari. Se un progetto commerciale costa più dei soldi che porta, quel progetto sarebbe considerato un fallimento. Se un progetto open source non può costruire una comunità attorno al codice per aiutarlo a mantenerlo e prendersene cura, quel progetto open source fallisce.

Sono stato coinvolto in progetti in cui abbiamo consegnato tutto in tempo e nel rispetto del budget, ma il team di sviluppo aziendale non è riuscito a seguire il lavoro. Dal punto di vista commerciale, il progetto ha fallito, sebbene ciò che abbiamo consegnato sia stato ben accolto e apprezzato.

In situazioni come la tua, l'azienda deve prendere alcune decisioni difficili. Se vogliono che il progetto abbia successo, devono imparare alcune lezioni:

• La mancata pianificazione in modo appropriato provocherà uno stress eccessivo per il team e alla fine porterà a un progetto fallito
• Una squadra stressata si vendicherà con un elevato turnover e alla fine non sarai in grado di ottenere brave persone a far parte dell'azienda.
• Le emergenze accadono, ma trova ciò che ha causato l'emergenza e cambia le tue pratiche per evitarla in futuro.

Qualsiasi azienda che non impara dai suoi errori ripeterà la storia abbastanza spesso. Lo prenderei come un segno che è tempo di trovare un'altra società.

Il fallimento è tutto ciò che può descrivere un obiettivo non raggiunto.

In breve, quando definisci il tuo obiettivo, definisci anche ciò che è un fallimento in quel contesto.

Nella letteratura menzionata, un fallimento è un progetto che ha superato il budget e / o non ha rispettato la scadenza .

Ciò non significa che il prodotto non verrà utilizzato. Ciò significa che è stato sviluppato con molto più dolore, denaro e tempo del previsto.

When you should cancel a project? Quando sei sicuro che ogni nuova seconda spesa su di essa fornirà meno valore del suo costo.

Si chiama dilemma del costo sommerso .

Se sei interessato all'argomento, ti consiglio Death March , di Edward Yourdon . Un libro davvero fantastico.

Esistono molti modi diversi in cui un progetto può "fallire". E parecchi su cui ho lavorato sono stati fallimenti:

1. Il software termoretraibile ha dovuto essere riscritto per soddisfare le nuove norme statutarie / regolamentari. I mismanager hanno scelto di evitare di assumere nuove persone per aiutare con il carico di lavoro, e in particolare con le competenze che tutti mancavano. Il prodotto non aveva le nuove funzionalità richieste (doveva avere un deposito elettronico fatto in un certo modo) e doveva essere ritirato dal mercato. Mentre questo prodotto ha prodotto circa il 5% dei ricavi del nostro ufficio, stava arrivando una simile modifica normativa che ha interessato il prodotto che ha prodotto il 60% dei nostri ricavi. Gli sviluppatori si sono presi la responsabilità di apprendere le competenze necessarie, ma i mismanager hanno scelto di aspettare che fosse quasi troppo tardi per iniziare a implementare le modifiche richieste. Abbiamo ricevuto 3 anni di preavviso che tali cambiamenti stavano arrivando mentre cercavamo di fare offerte sul lato server di questa modifica normativa - e l'azienda ci ha giustamente vietato di presentare l'offerta. I nostri mismanagers hanno scelto di farci aspettare fino a 8 mesi prima del passaggio prima che ci fosse permesso di lavorarci su.

2. Il progetto era già scaduto dal budget ed era scaduto quando sono stato incaricato di aiutarlo a completarlo. I manager di diversi livelli più alti hanno deciso che i costi sommersi erano già troppo elevati per rendere il ROI richiesto per il progetto, quindi il progetto è stato annullato e tutti i soggetti coinvolti sono stati licenziati. Lavorare lì per 1 settimana prima che il gruppo venisse licenziato (incluso me) è stato il periodo più breve in cui abbia mai lavorato in un posto.

3. Il completamento del progetto interno ha richiesto così tanto tempo che lo sponsor del progetto aveva acquistato un software standard (in questo caso Microsoft Office) e aveva scritto il proprio VBA per svolgere il proprio lavoro. Il leader del team di sviluppo ha continuato a promettere la luna e si è rifiutato di ascoltare nelle riunioni manageriali che il progetto era già stato annullato. 6 persone hanno lavorato per circa un anno completando un sistema che non sarebbe mai stato utilizzato.

L'unico progetto con cui sono stato coinvolto sia come programmatore, sia come parte del team PM è stato Ricochet, che è andato a vuoto con il fallimento di Metricom . C'erano letteralmente migliaia di appaltatori in tutto il paese che vi lavoravano. Quando il loro direttore finanziario si è dimesso, il progetto si è letteralmente interrotto. I mobili iniziarono a essere rimossi dagli uffici mentre la gente della liquidazione scendeva.

Per molti di noi, il termine applicabile era "disoccupazione", ma Lame Duck sarebbe stata una descrizione adeguata. Spesso, le persone chiave dovranno rimanere attive fino a quando non sarà completato un processo di autopsia / liquidazione, proprio come alcuni politici che restano in carica per alcuni mesi per finire il loro mandato prima dell'arrivo del loro successore.

Come indicato da Otávio Décio , non ho visto un progetto fallire fino all'abbandono dal boom del dot com.

Questo è un problema comune, menzionato anche in alcuni libri sulla gestione dei progetti. Nessun progetto mai "fallisce", anche se tutto ciò che offre è un'esperienza "che cosa da evitare la prossima volta".

IMO, un progetto è un fallimento se non farlo sarebbe stato più economico. Ad esempio, se il prodotto ha una durata prevista di 5 anni e fa risparmiare all'azienda 100K pa, allora è un fallimento se ci sono voluti più di 500K per realizzarlo. (Sto barando con i tassi di interesse qui per renderlo più semplice). Alcune persone sostengono che ogni progetto con un sovraccarico di costi e / o tempi è un fallimento, ma IMO questa definizione ha poco senso in quanto si concentra troppo su stime e pianificazione corrette.

Inoltre, non ho mai partecipato a progetti "falliti", ma molti progetti con costi e tempi eccessivi. Credo che il problema sia che nessuna delle parti - il cliente o l'appaltatore - vuole che qualsiasi progetto venga considerato un fallimento per tutti i bambini di ragioni, inclusa la responsabilità.

Quindi penso che quando senti "progetti IT falliti" in realtà questi sono "progetti che sono andati oltre i loro limiti, nel tempo o nel budget".

Dopotutto, quante persone o aziende che conosci verrebbero pulite e diranno "abbiamo fallito"?

Eppure sento sempre parlare di "progetti IT falliti".

Quali erano i parametri che definivano "fallimento"?

È un termine peggiorativo spesso usato quando il progetto cambia. Molte persone amano etichettare il cambiamento come "fallimento". Non so perché, ma li rende in qualche modo più potenti o importanti per aver identificato un fallimento.

Alcuni progetti perdono davvero denaro e non si crea nulla di valore. Ma quelli sono rari.

Anche un progetto che non ha mai fornito software funzionante è un'esperienza di apprendimento su cosa non fare. Ha creato valore. Ha creato un valore imprevisto, quindi può essere etichettato in qualsiasi modo le persone vogliano etichettarlo. "Fallimento" è buono come "Imparato cosa non fare" in alcuni ambienti.

La vera domanda è "il valore era commisurato al costo"? E anche allora, il valore può essere così difficile da misurare che la risposta è interamente politica o soggettiva.

Un progetto interno a una grande azienda ha più spazio per "fallire"?

Forse. "fallimento" è un termine politico. Qualsiasi modifica a pianificazione, budget o ambito può essere etichettata come "modifica" o "errore". Possono anche essere etichettati come "imparato qualcosa di importante sull'incapacità del nostro team di scrivere un web server". O, ancora più positivamente, "imparato quali abilità abbiamo bisogno prima di riprovare."

I progetti esterni hanno spesso una maggiore supervisione da parte di addetti alle vendite e alla consegna, contabili e gestione dei progetti. I progetti interni hanno spesso una minore supervisione.

Quando effettui quella chiamata? Cosa succede quando lo fai?

Quando è opportuno che qualcuno venga espulso dall'organizzazione perché non sei d'accordo con loro. Si etichetta il loro progetto come "fallimento" e li si riassegna in modo da poter avere persone diverse.

L'unico modo in cui un progetto può essere un fallimento totale è la frode criminale - dove non sono state apprese lezioni, nulla può essere migliorato e i criminali sono stati licenziati e incarcerati, lasciando l'organizzazione all'oscuro di ciò che è accaduto.

Altrimenti, c'è sempre un certo valore.

La vera domanda è "il valore era commisurato al costo?"

Quindi la tua azienda che stava fatturando questo lavoro, ha ucciso te e altre 5 persone per 5 settimane. Continuano a trarre profitto dal tuo duro lavoro. Spero che tu abbia ottenuto qualcosa, perché la sicurezza del lavoro non è nulla in questi giorni e c'è molto lavoro. (Spina senza vergogna contattami se hai bisogno di lavoro e sei un programmatore competente, conosco diversi posti che hanno un disperato bisogno di aiuto).

Detto questo, se la tua azienda dovesse davvero pagarti per tutto quel lavoro e le 41 ore prima di andare a vivere, allora avrebbero perso i soldi.

Il tuo management ha bisogno di un sit down e una spiegazione che se ciò si verifica di nuovo devi essere pagato. Devono esprimere un giudizio migliore su quando staccare la spina.

Anch'io, come molti altri intervistati, sono stato coinvolto in numerosi progetti di grandi dimensioni che hanno funzionato nel tempo e nel budget, uno per oltre mezzo decennio. Lo scenario peggiore (quello della metà di un decennio) prevedeva una folle follia del Mese dell'uomo mitico gratuita, oltre a un epico insinuarsi nella portata. Detto questo, non è mai stato abbandonato e stanno iniziando ad assumere alcuni clienti ora. Ma le aspettative iniziali (sostituzione pulita e ben progettata per un vecchio sistema obsoleto) e un budget e una tempistica relativamente modesti sono ormai da tempo infranti.

Inoltre, a differenza della maggior parte delle persone qui, ho visto anche un progetto fallire completamente, fino all'abbandono . L'ultimo chiodo nella bara è arrivato all'inizio del 2010. Questo era lo scenario:

Piccola azienda (circa 30 persone) che realizza soluzioni ERP personalizzate per le medie imprese. Avevano alcune installazioni logistiche relativamente redditizie con compagnie minerarie australiane e alcuni equipaggiamenti per autotrasporti negli Stati Uniti. La piattaforma era un framework interno personalizzato costruito su J2EE. In realtà relativamente personalizzabile e ben fatto - le nuove semplici installazioni potrebbero essere costruite abbastanza rapidamente, ma non si sono ridimensionate troppo quando il livello di personalizzazione richiesto era molto complesso (come nel caso di alcuni dei loro più grandi clienti).

Per farla breve: alcune delle loro installazioni più grandi e di alto profilo sono andate avanti nel tempo e nel budget, e sembra che il mercato non l'abbia apprezzato, quindi non hanno potuto ottenere altri clienti. La società era sostanzialmente un pony, facendo poco più di questo sistema ERP, quindi una volta esaurito il flusso di cassa da quello inaridito, hanno cessato l'attività e il sistema è stato abbandonato (anche il GFC avrebbe potuto avere un ruolo in esso) .

(Ho lavorato lì solo per 9 mesi - nel 2004/2005. Fondamentalmente hanno assunto e reso ridondanti man mano che il carico di lavoro andava e veniva con nuove installazioni - invece di assumere appaltatori - il che è piuttosto complicato. Con il senno di poi, il fallimento era probabilmente più da fare con un modello di business traballante che con la tecnologia.)

Se il progetto fosse stato distribuito in modo tale da soddisfare la richiesta originale, avrei definito il progetto riuscito. Per me un fallimento sarebbe il lancio di un'applicazione che è stata poi universalmente respinta dagli utenti finali perché non soddisfaceva le loro esigenze. O, peggio ancora, il progetto viene interrotto prima che un prodotto venga effettivamente distribuito agli utenti e le loro esigenze non siano soddisfatte.

Generalmente se un'azienda lavora per un cliente esterno, non è la sua decisione di avviare un progetto in quanto potrebbero esserci problemi contrattuali (ad esempio violazione dei pagamenti del contratto) o un grande successo di PR, come hai notato. In alcuni casi, se si verifica una violazione della penalità del contratto, l'opzione preferita è il costo di conclusione del contratto più volte di quello della violazione del contratto e la perdita di una somma di denaro simbolica.

A lungo termine, un'azienda può lavorare per migliorare la morale dei dipendenti per compensare un periodo di crisi durante un progetto o sostituire i dipendenti che se ne sono andati perché sono stati spinti duramente, ma a volte può essere impossibile per loro recuperare dai principali fallimenti del progetto ( vale a dire guardare le società di giochi che non sono riuscite a consegnare i prodotti in tempo che sono falliti).

Quando il caso aziendale non regge più.

Questa è la misura che Prince2 (la metodologia di Project Management) usa e ha molto senso per me.

Sostanzialmente dice alla fine di ogni fase del progetto, o se un progetto non rientra in determinate tolleranze in determinate aree (programma, costi, qualità), dovrebbe esserci una revisione del caso aziendale. A quel punto si superano i costi totali previsti e i benefici realizzabili in base a ciò che ora si conosce e se il progetto non si accumula più, viene ucciso.

Il problema con questo per molti progetti che ho visto è che non espongono in anticipo ciò che stanno cercando di ottenere in dettaglio, il che rende molto difficile valutare (a) se è ancora realistico, o (b ) se ne valgono la pena i costi che dovrai spendere per arrivarci. In queste situazioni la cosa migliore che puoi fare è produrre un caso aziendale nel momento in cui diventi sospettoso per permetterti di capire se i tuoi sospetti sono corretti.

Mettere insieme un business case non deve essere un'impresa importante, lo faranno un paio di lati di A4. I costi sono relativamente facili (come misura approssimativa un programmatore costa: (stipendio annuo * 2) / 250 al giorno per l'Europa, probabilmente un po 'meno per gli Stati Uniti poiché i benefici sono inferiori e il numero medio di giorni lavorativi più alti che sono gli input qui ).

I vantaggi sono più difficili ma se si stima pessimisticamente nel modo più accurato possibile, quindi se il business case non si accumula (normalmente misurato in quanto deve fare un ritorno x% sui suoi costi in 3 anni in cui X è probabile che sia del 50% o quindi) puoi guardarlo in modo più dettagliato. Non dimenticare i costi di licenza e hardware (anche se stai utilizzando hardware esistente in quanto significa che non può essere utilizzato per nient'altro una volta che lo hai catturato) e supporto continuo.

Ma molto di questo non è roba da programmatore, è roba che il PM e il business dovrebbero fare con il contributo di tutto il team di progetto.