Progetto fallito: quando chiamarlo?

Il concetto di fallimento è in realtà una chiamata legata al business. Se un progetto commerciale costa più del denaro che porta, quel progetto sarebbe considerato un fallimento. Se un progetto open source non può costruire una comunità attorno al codice per aiutare a mantenerlo e prendersene cura, quel progetto open source ha avuto esito negativo.

Sono stato coinvolto in progetti dove abbiamo consegnato tutto in tempo e nel budget, ma il team di sviluppo aziendale non è riuscito a seguire il lavoro. Dal punto di vista del business, il progetto è fallito, anche se ciò che abbiamo consegnato è stato ben accolto e apprezzato.

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

• La mancata pianificazione in modo appropriato causerà eccessivo stress al tuo team e, in definitiva, porterà a un progetto fallito
• Un team stressato si rivaluterà con un elevato turnover e alla fine non sarai in grado di convincere le persone ad entrare a far parte dell'azienda.
• Le emergenze accadono, ma scopri cosa ha causato l'emergenza e cambia le tue pratiche per evitare che l'emergenza in futuro.

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

Failure is anything that can describe a goal not being met.

In breve, quando definisci il tuo obiettivo, definisci anche cosa è un errore in quel contesto.

Nella letteratura che hai citato, un fallimento è un progetto che è fuori budget e / o non ha rispettato la scadenza .

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

When you should cancel a project ? Quando sei sicuro che qualsiasi nuova seconda spesa su di essa fornirà un valore inferiore al suo costo.

Si chiama il dilemma dei costi irrecuperabili .

Se ti interessa l'argomento, ti consiglio Death March , da Edward Yourdon . Un libro davvero fantastico.

Ci sono molti modi in cui un progetto può "fallire". E alcuni dei quali ho lavorato sono stati errori:

1. Il software termoretraibile doveva essere riscritto per soddisfare le nuove regole statutarie / normative. I cattivi amministratori hanno scelto di evitare l'assunzione di nuove persone per aiutare con il carico di lavoro, e soprattutto con le competenze che ci mancavano. Il prodotto non aveva le nuove funzionalità richieste (doveva avere una archiviazione elettronica fatta in un certo modo) e doveva essere ritirato dal mercato. Mentre questo prodotto ha prodotto circa il 5% dei ricavi del nostro ufficio, è arrivata una modifica normativa simile che ha interessato il prodotto che ha prodotto il 60% dei nostri ricavi. Gli sviluppatori si sono incaricati di apprendere le competenze necessarie, ma i malintenzionati hanno scelto di aspettare fino a quando non fosse quasi troppo tardi per iniziare a implementare le modifiche richieste. Avevamo 3 anni di preavviso sul fatto che questi cambiamenti stavano arrivando mentre tentavamo di fare offerte sul lato server di questo cambiamento normativo - e la società ci ha giustamente impedito di presentare l'offerta. I nostri disadattati hanno scelto di farci aspettare fino a 8 mesi prima del passaggio prima che ci fosse concesso di lavorarci.

2. Il progetto aveva già superato il budget e era in ritardo quando sono stato portato a termine per aiutarlo. I manager di diversi livelli più alti hanno deciso che i costi irrecuperabili erano già troppo alti per realizzare il ROI richiesto per il progetto, quindi il progetto è stato annullato e tutti gli interessati 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 progetto interno ha impiegato così tanto tempo per completare che lo sponsor del progetto ha acquistato un software standard (in questo caso Microsoft Office) e ha scritto il proprio VBA per portare a termine il proprio lavoro. Il leader del team di sviluppo ha continuato a promettere la luna e ha rifiutato di ascoltare nelle riunioni manageriali che il progetto era già stato cancellato. 6 persone hanno lavorato per circa un anno completando un sistema che non sarebbe mai stato utilizzato.

L'unico progetto in cui sono stato coinvolto come programmatore o come parte del team PM è stato Ricochet, che è andato in rovina con la bancarotta di Metricom . C'erano letteralmente migliaia di appaltatori in tutto il paese che ci lavoravano. Quando il loro CFO si dimise, il progetto si fermò letteralmente. I mobili sono stati rimossi dagli uffici mentre i liquidatori scendevano.

Per molti di noi, il termine applicabile era "disoccupazione", ma Lame Duck sarebbe una descrizione adeguata. Spesso, le persone chiave dovranno rimanere attive fino al completamento di un processo di autopsia / liquidazione, proprio come alcuni politici che rimangono in carica per alcuni mesi per terminare il mandato prima che il loro successore entri.

Come indicato Otávio Décio , ho non si vede un progetto fallire fino al punto di abbandono dal boom delle dot com.

Questo è un problema comune, citato anche in alcuni libri sulla gestione dei progetti. Nessun progetto mai "fallisce", anche se tutto ciò che offre è un'esperienza "what-to-avoid-next-time".

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 salva la società 100K p.a., allora è un errore 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 di tempo è 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 nessun progetto "fallito", ma a un sacco di progetti con costi e superamenti di tempo. 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, 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".

Dopo tutto - quante persone o aziende che conosci verrebbero pulite e diranno "abbiamo fallito"?

Yet I hear about "failed IT projects" all the time.

What were the parameters that defined "failure"?

È un termine peggiorativo spesso usato quando il progetto cambia. A molte persone piace etichettare il cambiamento come "fallimento". Non so perché, ma in qualche modo è più potente o importante aver identificato un fallimento.

Alcuni progetti sono davvero persi e non viene creato nulla di valore. Ma quelli sono rari.

Anche un progetto che non ha mai prodotto software funzionante è un'esperienza di apprendimento in ciò che non fare. Ha creato valore. Ha creato un valore inatteso, quindi può essere etichettato in qualsiasi modo che le persone vogliono etichettarlo. "Failure" è buono come "Impara cosa non fare" in alcune cerchie.

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.

Does a project that's internal to a large corporation have more space to "fail"?

Forse. "fallimento" è un termine politico. Qualsiasi modifica alla pianificazione, al budget o all'ambito può essere etichettata come "modifica" o "fallimento". Possono anche essere etichettati come "imparato qualcosa di importante sull'incapacità del nostro team di scrivere un server web". O, ancora più positivamente, "ho imparato quali sono le competenze di cui abbiamo bisogno prima di provare di nuovo"

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

When do you make that call? What happens when you do?

Quando è opportuno che qualcuno faccia pressioni fuori dall'organizzazione perché non sei d'accordo con loro. Contrassegni il loro progetto come "fallimento" e li ricevi riassegnati in modo da poter avere persone diverse.

L'unico modo in cui un progetto può essere un errore 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 per quello che è successo.

Altrimenti, c'è sempre qualche valore.

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

Quindi la tua azienda che stava effettuando la fatturazione di questo lavoro, ha costretto a morte te e altre 5 persone per 5 settimane. Guadagnano ancora i loro profitti dal tuo duro lavoro. Spero che tu abbia qualcosa, perché la sicurezza del lavoro non è nulla in questi giorni e c'è molto lavoro. (Una 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 effettivamente pagarti per tutto quel lavoro e le 41 ore prima di andare a vivere, allora avrebbero avuto PERDONO denaro.

La tua gestione ha bisogno di sedersi e una spiegazione che se ciò dovesse accadere di nuovo devi essere pagato. Devono esprimere un giudizio migliore su quando staccare la spina.

Anch'io, come molti di coloro che hanno risposto qui, sono stato coinvolto in diversi progetti di grandi dimensioni che hanno funzionato nel tempo e nel budget, uno per più di mezzo decennio. Lo scenario peggiore (quello di mezzo decennio) ha comportato una follia gratuita di Mythical Man Month, oltre a un creep epico. Detto questo, non è mai stato abbandonato e ora stanno iniziando ad assumere alcuni clienti. Ma le aspettative iniziali (sostituzione pulita e ben progettata per un vecchio sistema obsoleto) e budget e tempistiche relativamente modesti sono state a lungo distrutte.

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

Azienda di piccole dimensioni (circa 30 persone) che realizza soluzioni ERP personalizzate per aziende di medie dimensioni. Avevano alcune installazioni logistiche relativamente redditizie con compagnie minerarie australiane e alcuni abiti per autotrasporti negli Stati Uniti. La piattaforma era una struttura interna personalizzata costruita su J2EE. In realtà relativamente personalizzabili e ben fatti - le nuove installazioni semplici potrebbero essere create abbastanza velocemente, ma non è stato scalato troppo bene quando il livello di personalizzazione richiesto era molto complesso (come nel caso di alcuni dei loro maggiori clienti).

Per farla breve: alcune delle loro installazioni più grandi e di maggior profilo hanno funzionato nel tempo e nel budget, e sembra che il mercato non lo apprezzasse, quindi non potevano ottenere altri clienti. L'azienda era fondamentalmente un pony un trucco, facendo poco più di questo sistema ERP, quindi una volta che il flusso di cassa da ciò si esaurì, cessarono l'attività e il sistema fu abbandonato (anche se il GFC avrebbe potuto averne una parte) .

(Ho lavorato lì solo per 9 mesi - nel 2004/2005.) Fondamentalmente sono stati ingaggiati e resi ridondanti man mano che il carico di lavoro veniva e veniva con nuove installazioni - invece di assumere appaltatori - il che è piuttosto rischioso. più a che fare con un modello di business traballante che con la tecnologia.)

Se il progetto è stato implementato in modo tale da soddisfare la richiesta originale, definirei il progetto con successo. Per me un fallimento sarebbe stato il roll out di un'applicazione che è stata poi universalmente respinta dagli utenti finali perché non soddisfaceva i loro bisogni. Oppure, peggio ancora, il progetto termina prima che un prodotto sia effettivamente distribuito agli utenti e il loro bisogno non è soddisfatto.

Generalmente, se un'azienda lavora per un cliente esterno, non è la sua decisione di ritirare un progetto in quanto potrebbero esserci problemi relativi al contratto (ad esempio violazione dei pagamenti del contratto) o un importante colpo di pubbliche relazioni, come hai notato. In alcuni casi, se vi è una violazione della penalità contrattuale, il costo della conclusione del contratto è parecchie volte inferiore a quello della violazione del contratto e la perdita di una somma di denaro simbolica è l'opzione preferita.

Nel lungo periodo, un'azienda può lavorare per migliorare la morale dei dipendenti per compensare un momento di crisi durante un progetto o sostituire i dipendenti che sono andati via perché sono stati spinti a fondo, ma a volte può essere impossibile recuperarli dai maggiori fallimenti del progetto (ad esempio, guarda le società di giochi che non sono riuscite a consegnare i prodotti in tempo e che sono falliti).

Quando il business case non resiste più.

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

In sostanza, si dice alla fine di ogni fase del progetto, o se un progetto non rientra in alcune tolleranze in certe aree (pianificazione, costi, qualità), dovrebbe esserci una revisione del business case. A quel punto, superi i costi totali anticipati e i benefici realizzabili in base a ciò che ora sai e se il progetto non si accumula più, viene ucciso.

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

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

I vantaggi sono più difficili, ma se hai una stima pessimista il più accuratamente possibile, allora se il business case non si accumula (normalmente misurato in quanto deve fare un x% di ritorno sui suoi costi in 3 anni dove X è probabile che sia 50% circa) puoi guardarlo più in dettaglio. Non dimenticare i costi di licenza e hardware (anche se stai utilizzando l'hardware esistente in quanto significa che non può essere utilizzato per nient'altro una volta che lo hai bloccato) e il supporto continuo.

Ma molto di questo non è roba da programmatore, è roba che il PM e l'azienda dovrebbero fare con l'input dell'intero team di progetto.