Dove finisce la “gestione del cambiamento” e inizia il “fallimento del progetto”?

Question

Di recente sono entrato in un mini-argomentazione con il mio capo in merito al "fallimento del progetto". Dopo tre anni, il nostro progetto per migrare una base di codice su una nuova piattaforma (un progetto in cui mi sono impegnato per 1,5 anni, ma il mio lead del team è stato in corso solo per pochi mesi) è andato in vita.Lui, insieme al senior management sia della mia azienda che del cliente (sono uno di quegli orribili consulenti di cui si sente tanto parlare.Il mio impegno è un "Application Outsourcing") ha dichiarato il progetto un successo.Non ero d'accordo, affermando che le vecchie presentazioni che avevo trovato mostravano che, rispetto al programma originale, il ritardo nell'implementazione era meglio misurato in mesi e potenzialmente poteva essere misurato in anni.Ho spiegato ciò che so sul fallimento dei progetti e gli studi e le statistiche alla base dei tassi di fallimento.Ha risposto che era tutto accademico e che nessun progetto da lui guidato era fallito, grazie alle meraviglie della gestione del cambiamento/rischio: ciò che sembra ridursi a spiegare i ritardi e rivalutare il programma sulla base di nuovi dati.

Forse una consulenza come questa è diversa da altri progetti, ma sembra che questo sia solo un fallimento racchiuso in un nome più carino per evitare lo stigma di non essere riusciti a consegnare in tempo, nel rispetto del budget o con la piena funzionalità.Il fatto che mi abbia spiegato che la mia azienda ha regalato ore di lavoro gratuitamente per portare a termine il progetto entro il budget massimo la dice lunga.

Quindi ti chiedo questo:

• Cos'è la gestione del cambiamento e come si applica a un progetto?
• Dove finisce la "gestione del cambiamento" e inizia il "fallimento del progetto"?

---

@shog9:
Non stavo parlando di un gioco di colpe con i consulenti, soprattutto perché in questo caso io rappresentare i consulenti.Stavo cercando opinioni su quando un progetto dovrebbe essere considerato "fallito" indipendentemente dalla funzionalità necessaria era finalmente implementato.
Sto cercando la differenza tra "in realtà è un po' più complesso di quanto pensassimo, e ci vorrà un'altra settimana" che mi aspetterei sia in qualche modo tipico, e "fallimento del progetto", comunque tu voglia definire il fallimento.C'è anche una differenza?Questo lieve slittamento del programma costituisce un "fallimento statistico del progetto"?

Answer 1

Penso che, la maggior parte delle volte, noi sviluppatori dimentichiamo che tutto ciò che facciamo è, dopo tutto, una questione di affari.

Da questo punto di vista un progetto non è un fallimento finché il cliente è disposto a pagare per realizzarlo.Tutto dipende dal cliente, alcuni clienti hanno più pazienza e comprendono meglio i rischi dello sviluppo del software, altri semplicemente non pagheranno se c'è un ritardo sostanziale.

Comunque, riguardo alla tua domanda.Ogni volta che sviluppi un progetto ci sono dei rischi, forse pianifichi la fine del progetto in una certa data ma ci vorranno circa sei mesi in più del previsto.In tal caso devi bilanciare ciò che hai già speso e ciò che hai da guadagnare rispetto ai rischi che stai correndo.In realtà esiste un'intera scienza chiamata "processo decisionale" che lo studia a livello di software, quindi il tuo capo non ha affatto torto.

Diamo un'occhiata ad alcune domande: il cliente è disposto ad aspettare il progetto?È disposto ad assumersi certi sovraccosti?Anche se così non fosse, vale la pena completare il progetto assumendosi i costi aggiuntivi invece di buttare via tutto il lavoro già svolto?L'azienda può farsi carico di ciò che ha già perso?

La vera risposta al tuo problema si trova dietro queste domande.Non è possibile stabilire un punto e dire, qui, che se il progetto non è completato entro questo momento, allora è un fallimento.Per quanto riguarda la tua situazione specifica, chi lo sa?Il tuo capo probabilmente ha più informazioni delle tue, quindi il tuo compito è dirgli come sta andando il progetto, quanto ci vorrà e quanto costerà (in termini di ore/uomo se lo desideri)

Answer 2

A meno che gli obiettivi non siano stati chiaramente dichiarati all'inizio del progetto, non ci sono linee chiare tra "successo" e "fallimento". Spesso, un progetto avrebbe un variabile grado di successo/fallimento.

Per alcuni, inserire semplicemente alcuni concetti nel codice sarebbe un successo, mentre altri potrebbero misurare il successo come recuperare tutti gli investimenti e realizzare profitti.Due modalità di fallimento ben note sono lo slittamento della pianificazione e il deterioramento della qualità, ma nel mondo reale le persone non sembrano preoccuparsene molto.

Un modo semplice per aggirare il programma è lasciare che i manager facciano richieste quando vogliono (le funzionalità si insinuano) e lasciare che i programmatori codifichino ciò che ritengono giusto (codifica da cowboy).Processo di gestione del cambiamento come pianificazione dello sprint di mischia e gioco di pianificazione di XP sono alcuni degli esempi.Questi sono alcuni dei tentativi del management e degli sviluppatori di consegnare prodotti affidabili in tempo.Se una delle parti non è interessata all'affidabilità e alla puntualità, la gestione del cambiamento non sarebbe utile.

Answer 3

Suppongo che il successo del progetto dipenda da chi è il cliente.Se i clienti fossero i direttori dell’azienda e fossero contenti, allora il progetto ha avuto successo nonostante i fallimenti lungo il percorso.

Answer 4

Andy Rutledge ha scritto un articolo piuttosto interessante sul successo.Anche se il titolo lo è Discussioni pre-offerta, definisce l'articolo avere un progetto di successo, che per Andy comporta:

1. Potremo io o il mio team portare il nostro miglior lavoro al risultato finale?
2. Il cliente è preparato a impegnarsi adeguatamente nel progetto?
3. Il cliente è pronto per iniziare questo progetto?
4. Il cliente è disposto a investire fiducia nelle mie idee o in quelle del mio team?
5. Sono o il mio team è pronto a soddisfare o superare i requisiti del progetto?

Questo articolo è stato segnalato da Obie Fernandez, consulente di successo, nel suo Fai il trambusto convegno sulla consulenza.

Answer 5

Cos'è la gestione del cambiamento e come si applica a un progetto?

La gestione del cambiamento riguarda l'approvazione e la comunicazione delle modifiche a un progetto prima che avvengano.Se qualcuno nel tuo progetto (utente, sponsor, membro del team...chiunque) voglia aggiungere una funzionalità, la modifica deve essere documentata e analizzata per gli effetti.Qualsiasi modifica risultante all'ambito, al budget e al programma deve quindi essere approvata prima che la modifica venga intrapresa.Questi cambiamenti sono generalmente approvati dal tuo sponsor, dal tuo comitato direttivo o dal tuo cliente.

Una volta che le modifiche sono state approvate e accettate, questo sarà il tuo nuovo piano.Non importa quale fosse il budget o il programma originale.

La gestione del cambiamento nei progetti si basa sul principio "Nessuna sorpresa".Le persone giuste (il comitato di controllo delle modifiche) devono approvare eventuali modifiche all'ambito, alla pianificazione e al budget prima che vengano attuate.

Una cosa da ricordare è che potrebbero esserci alcuni vincoli e tolleranze espliciti o impliciti per il cambiamento.Potrebbe essere necessario consegnare il progetto entro una certa data per soddisfare i requisiti normativi governativi.Oppure la tua organizzazione potrebbe avere una soglia secondo cui una volta che il budget di un progetto supera del 30% il budget originale, deve passare al livello "C" altrimenti il ​​progetto viene interrotto.Indagare e dichiarare esplicitamente queste soglie e tolleranze in anticipo è un buon modo per avere progetti di maggior successo.

Dove finisce la "gestione del cambiamento" e inizia il "fallimento del progetto"?

Se un progetto rispetta l'ambito, la pianificazione e il budget approvati, avrà successo.

Tuttavia può ancora essere visto come un fallimento.Le revisioni post-implementazione sono un ottimo strumento per qualificarlo con i tuoi stakeholder (non solo con il tuo capo).Sarebbe utile esaminare anche la realizzazione dei benefici per vedere fuori dalla scatola nera del progetto e l'impatto sull'azienda nel suo insieme.