7 fattori per fallimento garantito

Non apprezzare i dipendenti, sottovalutare la complessità o fare affidamento sui miti. Se questi e altri fattori vengono presi in considerazione, il tuo progetto fallirà sicuramente.

Lo sai che? Per settimane e mesi, il project manager riferisce sul suo progetto. Ovviamente non dovrebbero mancare le classiche spie di stato. E questo è costantemente sul verde: tutto ok. Ma un giorno il semaforo diventa improvvisamente rosso! Di conseguenza, inizia un processo di elaborazione molto spiacevole per i responsabili. Il più delle volte la prima domanda riguarda il colpevole, la seconda le cause, e poi ci si dedica solo alle possibili soluzioni.

Di seguito sono riportati 7 fattori tipici che quasi garantiscono il fallimento.

Fattore 1: ignorare il fattore umano

In molti anni come sviluppatore, project manager, coach e crisis manager, ho scoperto che le tensioni interpersonali sono il più grande ostacolo all'implementazione di progetti IT. Al contrario, la chimica tra i dipendenti è corretta e c'è un clima aperto e tollerante ai guasti, si possono trovare soluzioni per tutte le difficoltà, anche in situazioni critiche.

È nella natura dell'uomo evitare i conflitti. E quindi è naturale se le persone (ad esempio il project manager) ignorano completamente o distolgono lo sguardo troppo a lungo. Ma i conflitti di solito non si dissolvono da soli. La ricerca è richiesta, come moderazione e almeno la prospettiva sul cambiamento o sulla soluzione.

A volte sono le piccole cose che hanno un grande impatto, come un nuovo lavoro per un dipendente. Tuttavia, spesso sono necessarie spese maggiori, come la riorganizzazione dei team, per riportare la pace nel progetto. Tuttavia, l'alternativa peggiore è ignorare il fattore umano.

Fattore 2: Pensa troppo in grande o fai troppo in piccolo

Alcune aziende rilevano un progetto. Sottovalutano la complessità, i rischi e l'immenso sforzo personale e materiale. La mia organizzazione è in grado, indipendentemente dai costi, di gestire un progetto con 100 dipendenti? Abbiamo abbastanza posti di lavoro, sale riunioni, capacità di rete, server di sviluppo, ecc.?

L'azienda è in grado di soddisfare i requisiti di un grande team di sviluppo agile per un percorso di sviluppo e test che includa integrazione/consegna continue? Prevedendo tali domande, il business case avrebbe dovuto essere calcolato realisticamente. Ho visto più volte che solo poco prima dell'inizio di un gigantesco progetto è diventato chiaro che il sistema risultante non era effettivamente necessario perché non si adattava al modello di business dell'azienda. Sfortunatamente, nessuno l'aveva notato prima.

Un altro modello riconoscibile: un protagonista vuole assolutamente realizzare un SW, ad esempio per motivi di prestigio o per utilizzare dipendenti, e calcola i costi come trascurabili. Se il successivo project manager non è abbastanza forte da presentare la discrepanza nel contesto degli organi decisionali, ciò crea un elevato potenziale di crisi.

Fattore 3: affidarsi a stime e pianificazione al 100%

Un mito diffuso è l'attendibilità delle stime e della pianificazione. Il concept del progetto è definito dalla sua unicità. Forse c'erano già progetti simili, ma in linea di principio un'azienda sta entrando in un nuovo territorio con ogni progetto. Ciò significa che le stime possono essere valide solo in base alle esperienze dei creatori e alle loro capacità di adattamento rispetto al progetto in corso.

Tuttavia, i piani non possono mai includere eventi spontanei, cambiamenti in termini di requisiti, tecnologie o l'ingresso di rischi non previsti. In definitiva, le stime e i piani basati su di esse non sono altro che una scommessa sul futuro! Accettare questo fatto è un primo passo avanti. Disciplina, coraggio e sistema aiutano a prevenire o alleviare possibili crisi.

Fattore 4: Il magico triangolo PM costantemente ignorato

Studi informatica, primo semestre, prima lezione project management: “Il magico triangolo PM“ . La persona interessata ai compiti di gestione viene introdotta molto presto alle leggi di questo triangolo. Questi dicono che il cambiamento di uno dei tre parametri porta inevitabilmente alle conseguenze di almeno uno degli altri parametri.

Tuttavia, queste leggi sono fin troppo felici di essere ignorate nella pratica. Come già accennato nel contesto della stima e della pianificazione, un progetto è in qualche modo unico e la probabilità di influenze non pianificate è eccezionalmente alta. Ecco perché prima o poi è necessario per quasi tutti i progetti che i responsabili reagiscano a queste influenze. Tuttavia, se tutti i parametri sono fissi, cioè il cliente continua a pretendere il rispetto di tempi, budget e contenuti, il fallimento è solo una questione di tempo.

Fattore 5: Documentazione di tutto

Libero dopo Franz Beckenbauer: "Lo chiamiamo un classico!" Sebbene sempre più aziende si affidino a procedure agili (principalmente scrum), si trovano ancora organizzazioni e progetti che danno maggiore importanza alla documentazione estesa rispetto al software da creare. Questo è un rischio elevato, specialmente nei grandi progetti. Spesso ha funzionato per mesi o addirittura anni una caccia di consulenti ed esperti di dipartimento su migliaia di pagine, che verranno successivamente tradotte da un altro team in SW.

Più ampia è la documentazione, più lunghi sono i tempi di realizzazione e meno è probabile che il SW corrisponda alle effettive esigenze degli utenti. Le reazioni ai cambiamenti del mercato non sono possibili o sono possibili solo con grandi sforzi e concessioni temporali. Un documento offre una base sulla quale il prodotto può essere rimosso. Sfortunatamente, ciò che è scritto non è necessariamente chiaro e il risultato è pensato in modo diverso da come inizialmente pensato. Quante volte ho sentito la frase del personale del dipartimento e degli utenti finali: "Oh, l'avevo immaginato in modo molto diverso!" .

Fattore 6: solo nessuna organizzazione equilibrata del progetto

Un team di 20 sviluppatori e 1 contatto tecnico? Non c'è bisogno di conoscenze specialistiche per riconoscere che questo costrutto fallirà prima o poi. All'inizio di un progetto, che sia a cascata o agile, può ancora funzionare perché gli sviluppatori sono impegnati con i framework o con la configurazione degli ambienti. Ma molto presto i dipendenti faranno domande: hanno bisogno di un supporto professionale intensivo.

Un singolo esperto in materia non può mai resistere a questa pressione temporale ed emotiva e richiede supporto, sia in termini di personale che attraverso il processo di attuazione. Tuttavia, è una pessima idea contrastare il collo di bottiglia del personale limitando la comunicazione.

Anche un'idea popolare e molto in primo piano sulla scala dei tipici errori di gestione: un dipendente raccoglie le domande degli sviluppatori, le discute con il referente tecnico e restituisce le risposte. In questo modo crei un collo di bottiglia per eccellenza, inneschi un tasso di errore estremamente elevato e ritardi notevolmente lo sviluppo.

Fattore 7: Riscalda lentamente la rana

Conosci questa storia? Se metti una rana in una casseruola con acqua e la riscaldi continuamente fino a cottura, la rana non tenta di scappare. Se lo getti direttamente nell'acqua calda, salta fuori immediatamente.

Una delle mie conoscenze più importanti di me negli ultimi anni è che i dipendenti dei progetti IT scadono con l'aumentare della durata della crescente cecità. I processi una volta stabiliti vengono forse messi in discussione in retrospettive, ma raramente sono davvero drastici. La capacità delle persone di reagire ai cambiamenti scompare in modo proporzionale alla durata di un progetto.

Pertanto, l'illuminazione sporadica (Health Checks) è consigliata da (enormi) progetti da parte di un consulente esterno, precedentemente non coinvolto, al fine di scoprire le perdite, percorsi potenzialmente non mirati. Al più tardi dopo aver riconosciuto una crisi conclamata, è quasi impossibile creare il turnaround con il solo personale esistente.

Quindi può essere possibile

I tipici errori di gestione descritti sono solo una piccola selezione della mia lista personale di modelli di comportamento, che impediscono o addirittura impediscono il completamento con successo dei progetti di sviluppo SW. Da lontano potrebbe sorgere l'impressione che sia facile riconoscere i problemi e correggerli nelle prime fasi dei progetti. Ma condizioni quadro apparentemente inamovibili e la citata cecità rendono spesso difficile prendere le giuste decisioni. Le statistiche del Gruppo Standish detto all'inizio lo dimostrano anno dopo anno.

Se un progetto è in difficoltà, è fortemente raccomandato che un gestore di crisi esterno possa analizzare e agire in modo obiettivo, libero da sensibilità e senza la zavorra della storia del progetto. La sola partecipazione di un esperto che ascolti le persone nel progetto può già provocare effetti positivi. La selezione di misure adeguate riesce anche alla trasformazione e infine al turnaround.