SYNCHRO BOARD™
Per coloro che aspirano a prestazioni premium nella gestione di progetti complessi.
Synchro Board™ è una piattaforma collaborativa di nuova generazione, progettata per affrontare le cause sistemiche degli insuccessi nella gestione dei progetti.
ACCELERA IL PROCESSO DECISIONALE
Grazie a un linguaggio visivo, l’aggiornamento e il monitoraggio del progetto diventano semplici e rapidi, permettendo a tutti di sapere immediatamente se il progetto è aggiornato, nei tempi previsti e se gli ostacoli sono stati considerati.
FACILITA IL LAVORO DEL PROJECT MANAGER E DEI PARTECIPANTI
Niente più email o telefonate: tutte le informazioni sull’avanzamento delle attività e sulla disponibilità sono su Synchroboard, aggiornate in meno di un minuto.
FOCALIZZA L'ATTENZIONE DI TUTTI SULLE TASK ESSENZIALI
Solo le attività che richiedono una sincronizzazione inter-funzionale vengono gestite con Synchroboard, rendendo la gestione del progetto più chiara e focalizzata sugli elementi chiave. Le attività specifiche di ogni funzione sono gestite localmente tramite un Synchroboard dedicato.
RENDE AFFIDABILE LA DATA DI CONSEGNA DEL PROGETTO.
Le attività a rischio sono certificate conformi e gli errori vengono individuati il più vicino possibile alla causa che li ha generati.
FAVORISCE LA SINERGIA TRA I PARTECIPANTI
“Da soli si va veloci, ma insieme si va lontano.” Synchroboard favorisce la sincronizzazione delle parti coinvolte per raggiungere insieme le milestone, con attività completate e certificate conformi, privilegiando il ritmo del gruppo rispetto a quello delle singole attività.
SVILUPPA L'INTELLIGENZA COLLETTIVA
Crea un ambiente in cui le competenze individuali si combinano per raggiungere una performance collettiva superiore.
MODIFICA PROFONDAMENTE IL RAPPORTO DELLE PERSONE CON IL TIMING DEL PROGETTO.
Ciò che conta è il tempo rimanente per completare un’attività, non la percentuale di avanzamento, che riguarda solo il suo responsabile. Con Synchroboard, l’obiettivo è utilizzare il tempo strettamente necessario, evitando di consumare semplicemente quello assegnato.
RAFFORZA LA SINCRONIZZAZIONE DELLE PERSONE E DELLE ATTIVITA.
La data di inizio di un’attività è flessibile. L’importante è iniziare subito dopo la fine dell’attività precedente, indipendentemente da questa data, e rispettare i limiti della data di fine della propria attività.
FUNZIONALITA CHIAVE
SCALA DEL TEMPO PROGRESSIVA TRA IL MEDIO LUNGO TERMINE E IL CORTO TERMINE
Poiché le attività a medio e lungo termine richiedono meno precisione rispetto a quelle a breve termine, la scala temporale viene regolata, passando progressivamente da una rappresentazione molto compressa a una più dettagliata man mano che ci si avvicina alla data corrente.
TASKS RAGGRUPPATE PER FUNZIONI
A differenza dei diagrammi di Gantt tradizionali, in cui le attività sono organizzate in base alla loro successione, Synchroboard™ assegna a ogni funzione una “corsia” specifica all’interno del progetto. Questa corsia raggruppa tutte le attività da svolgere da quella funzione, semplificando la loro identificazione e il loro monitoraggio sia per il project manager che per i membri dei team coinvolti.
NUMEROSE POSSIBILITA DI FILTRARE I DATI
Nei progetti complessi, è fondamentale accedere rapidamente alle informazioni necessarie per migliorare la reattività e facilitare il processo decisionale. Synchroboard risponde a questa esigenza grazie a potenti filtri che consentono di organizzare i dati per funzione, attività o persona. Inoltre, la modalità ‘compressed’ offre una visione d’insieme del progetto a colpo d’occhio, con la possibilità di visualizzare tutti i dettagli passando il mouse sopra ogni attività.
VALUTAZIONE DELLA DURATA E DELLA PROGRESSIONE DELLE TASKS
Nei progetti complessi, le numerose interazioni tra attività e persone, insieme alla partecipazione simultanea di alcune persone a più progetti, rendono difficile stimare con precisione la durata e il tempo necessario per completare le attività. Synchroboard™ privilegia una valutazione basata sul “sentire” piuttosto che su calcoli matematici. Si concentra principalmente sull’utilizzo dell’emisfero destro del cervello, dedicato alla sintesi e alla creatività, piuttosto che sull’emisfero sinistro, più orientato ai calcoli aritmetici e spesso meno adatto a contesti complessi.
AGGIORNAMENTO DEL PROGETTO
Grazie alla funzionalità «drag-and-drop», tutti i membri del team possono aggiornare i dati in tempo reale, simultaneamente, anche se distribuiti su più sedi. Riunioni regolari vengono organizzate per analizzare gli scostamenti di sincronizzazione, sfruttarne i vantaggi quando possibile o limitarne gli effetti negativi. L’obiettivo principale è garantire e assicurare la data di consegna del progetto.
MESSA IN SICUREZZA DEI DATI E DEL SOURCE CODE
Sicurezza dei dati: La soluzione è installata su un Cloud che garantisce i massimi standard europei di sicurezza
Sicurezza del codice sorgente: Gli strumenti utilizzati ci permettono di misurare la sicurezza del codice sorgente, inoltre, un sistema di Secret Management, è stato implementatoproprio per garantire la massima sicurezza.
PERSONALIZZAZIONE
Synchroboard™ si integra facilmente con le applicazioni di gestione dei progetti già in uso, garantendo una compatibilità fluida. Inoltre, è possibile personalizzare l’interfaccia con il proprio brand chart per un’esperienza su misura.
Possibilità di aggiungere o rimuovere milestones o attività in qualsiasi momento del progetto.”
TESTIMONIANZE
Luca C.
Eravamo impegnati nell’applicazione delle metodologie lean ai processi di progettazione, con l’obiettivo di ridurre i tempi di lancio di un nuovo prodotto sul mercato. Pianificammo con le competenze disponibili, cercando di prevenire i ritardi con azioni correttive, ma nonostante gli sforzi, ci trovammo presto in ritardo.
Fu allora che introducemmo il concetto di Syncro Board. Inizialmente i progettisti erano scettici e il Project Manager temeva ulteriori ritardi, ma il risultato superò ogni aspettativa: in quattro settimane non solo recuperammo il ritardo, ma ci portammo in anticipo sui piani originali, chiudendo il progetto con quattro settimane di anticipo su un tempo stimato di 24 settimane, guadagnando così un ottimo 16,6% sul time to market.
All’epoca ero Direttore del Lean e Strategic Operations presso FAAC SpA. Oggi mi occupo di organizzazione aziendale e posso dire che l’approccio Syncro Board è diventato un compagno di viaggio indispensabile.
Didier P.
« Grazie alla sua scala temporale regolabile, Synchro board™ ci ha aiutato a concentrarci sulle date di fine delle attività sincronizzate, permettendoci di rispettare i nostri impegni in termini di tempi, qualità e costi. Utilizzando solo il tempo necessario per ogni attività e riducendo i tempi morti tra di esse, siamo riusciti persino a consegnare il nostro prodotto in anticipo. Questo ci ha anche permesso di ottenere un ordine aggiuntivo, inizialmente assegnato a un concorrente la cui pianificazione si è rivelata meno efficace. Non posso che raccomandarlo vivamente.»
Saverio G.
Ritengo che Synchroboard rappresenti uno utilissimo strumento per la gestione di qualunque progetto sufficientemente complesso da richiedere l'impegno, in fasi diverse di sviluppo, più enti/funzioni aziendali.. Syncroboard assicura, con il necessario grado di ‘periodicità', la condivisione simultanea di ogni tematica che abbia un qualche potenziale impatto trasversale alle diverse funzioni, riducendo i tempi di reazione. minimizzando i tempi morti, permettendo al tempo stesso di rafforzare lo spirito di squadra permettendo ad un gruppo di persone di diventare un Team coeso finalizzato ad un comune obiettivo.
Ritengo che questa metodologia di gestione/supervisione di progetti multifunzionali complessi rappresenti una pietra miliare per il miglioramento continuo delle performance aziendali
Progettista meccanico
“Avevo appena terminato una formazione in gestione dei progetti quando Synchro board™ è stato introdotto in azienda. Ho scoperto un’interpretazione innovativa dei concetti tradizionali di gestione dei progetti. Ne sono entusiasta.”
Michele D.
“Avevamo messo in discussione la nostra gestione dei progetti più volte senza mai ottenere risultati veramente migliori. SYNCHROBOARD ci ha conquistati per la sua capacità di semplificare la gestione di progetti complessi. Pensavamo che fosse necessaria un’applicazione sofisticata per gestire i nostri prodotti complessi, ma SYNCHROBOARD ci ha sorpreso proponendo di ‘suddividere il progetto in piccole parti’ e gestirle semplicemente con uno strumento molto basilare. È stata questa semplicità a sorprenderci e conquistarci.”
Marco T.
“Nonostante un time to market molto serrato, Synchro board™ ci ha permesso di avviare la produzione in tempo, con molti problemi in meno alla partenza rispetto al passato, rispettando al contempo i costi target e il budget del progetto. Siamo stati tutti sorpresi dalle sue potenzialità e dei risultati ottenuti.”
SCOPRI CHI SIAMO
La Nostra Mission
“Progettare per i clienti più esigenti, un ecosistema capace di affrontare con successo le cause profonde dei fallimenti nella gestione dei progetti, al fine di garantire in modo sistematico il raggiungimento degli obiettivi prefissati.”
Synchroboard Team
Il nostro percorso verso Synchro board™
Siamo, prima di tutto, consulenti che da oltre 25 anni affiancano PMI e grandi aziende in Europa e nel mondo per migliorare le loro performance operative e strategiche.
La gestione dei progetti, al centro di molti processi su cui interveniamo, è diventata una priorità.
Abbiamo quindi concentrato i nostri sforzi sul miglioramento delle prestazioni nella gestione dei progetti, identificando e risolvendo le cause sistemiche degli insuccessi.
Da questa visione è nato Synchroboard™, frutto di oltre 10 anni di sviluppo e miglioramenti costanti, realizzati in collaborazione con i nostri clienti.
E questo è solo l’inizio: ci sono ancora molte sfide e opportunità da cogliere.
Synchroboard™ continuerà a evolversi, con nuove versioni già in fase di preparazione.
Le nostre convinzioni per concepire Synchro board™
Per garantire un livello di performance premium. i principi fondamentali del lean devono costituire la base su cui si ispira la progettazione di Synchroboard™
I concetti derivati dalla metodologia agile hanno ampiamente dimostrato la loro efficacia nella gestione dei progetti.
Li abbiamo adattati affinché si integrino in modo armonioso con altri strumenti e metodologie.
Le buone pratiche, frutto di molteplici esperienze consolidate nel tempo, rappresentano insegnamenti preziosi.
Le abbiamo confrontate con Synchroboard™ per individuare e correggere eventuali lacune o discrepanze.
Infine, abbiamo messo in discussione le conoscenze e gli insegnamenti acquisiti nel campo della gestione dei progetti per affrontare e correggere le cause sistemiche di insuccesso in questo ambito.
Synchro board™ : La nostra soluzione per affrontare le cause ricorrenti dei fallimenti della gestione dei progetti.
Ciò che rende Synchroboard™ unico è l’integrazione di tre sfere essenziali:
- Le conoscenze tecniche e le convinzioni acquisite, basate su una solida esperienza.
- Le competenze pratiche e organizzative, sviluppate attraverso sperimentazioni concrete.
- L’intelligenza emotiva, che comprende la capacità di gestire le proprie emozioni e di interagire in modo efficace con gli altri.
Siamo convinti che l’interazione di queste tre sfere sia la chiave per raggiungere una performance superiore, rappresentando l’essenza dell’intelligenza collettiva.
È proprio questa intelligenza collettiva che consente di affrontare e risolvere molte delle cause sistemiche di insuccesso nella gestione dei progetti.
Ben più di una semplice applicazione di gestione dei progetti, Synchroboard™ è un vero e proprio meta-strumento.
È progettato per integrarsi al centro dei processi strategici, come lo sviluppo di nuovi prodotti, la personalizzazione su richiesta o qualsiasi contesto che richieda una gestione rigorosa del tempo e delle risorse.
ALCUNI RIFERIMENTI TRA I NOSTRI CLIENTI
RISORSE
12 leggi e pratiche per assicurarsi di avere successo nella gestione dei progetti
La gestione dei progetti è una disciplina complessa in cui ogni fase richiede una pianificazione accurata e un’esecuzione metodica.
Per massimizzare le possibilità di successo, è fondamentale integrare le leggi e le buone pratiche comunemente riconosciute.
Questi principi, sviluppati attraverso decenni di esperienza, consentono di anticipare gli ostacoli, gestire efficacemente le risorse e garantire risultati coerenti.
Adottando questi principi, i project manager riducono le incertezze e aumentano la capacità del team di affrontare gli imprevisti.
Il rispetto delle leggi e delle buone pratiche assicura una struttura solida e permette di trasformare un progetto complesso in un successo misurabile, ottimizzando al contempo il tempo e le risorse investiti.
Queste leggi sono state integrate nell’ecosistema synchroboard™. Te ne diamo la mostra personnale interpretazione qui sotto.
Certo, esistono altre leggi, aforismi, detti e massime che non necessitano di spiegazioni, tanto sono evidenti nella loro semplicità.
Vorrei citarne alcune:
- « MOONSHINE », attribuita al mio sensei Akao San:« Non perdere tempo a spiegare ai tuoi capi cosa vuoi fare e perché. Non conoscono il gemba. Fallo senza dire nulla e poi mostra ciò che hai realizzato. Sentirai i tuoi capi dire: “È esattamente quello che volevo che tu facessi.” »
- « La velocità conta poco, ciò che importa è andare nella giusta direzione. », una massima di Lord Baden Powell, fondatore dello scoutismo, che diceva anche, a proposito della leadership: « Se corri, loro camminano. Se cammini, loro si siedono. Se ti siedi, loro si sdraiano. »
Infine, alcune leggi attribuite ad AMA, un consulente senior che conosco da tempo:
- « Siamo sempre più esperti nel risolvere i problemi degli altri che nel risolvere i nostri, per i quali troviamo sempre mille giustificazioni. »
- Il suo corollario: « Siamo sempre meno tolleranti verso gli altri che verso noi stessi. »
- « La differenza tra spiegazione e giustificazione è la stessa che c’è tra chi migliora e chi resta fermo nello status quo. »
- « È una follia pensare di essere utili dedicando del tempo a fare con meno competenze ciò che un collega non ha fatto per mancanza di tempo. »
Legge di Murphy: Tutto ciò che può andare storto, andrà storto
Anche se spesso viene vista come una battuta umoristica o pessimistica, questa legge riflette una realtà importante in molti ambiti, soprattutto nella gestione dei progetti.
Per esperienza personale, ho elaborato una variante ancora più realistica:
“Tutto ciò che può andare storto, andrà storto e nel peggior momento possibile!”
Origine della legge di Murphy
La legge prende il nome da Edward A. Murphy Jr., un ingegnere aeronautico statunitense che lavorava negli anni ’40 a test di tolleranza umana alla gravità.
Durante un esperimento fallito a causa di un dispositivo installato in modo errato, Murphy avrebbe dichiarato: “Se qualcuno può commettere un errore, lo farà.”
Da allora, l’espressione è stata abbreviata nella sua forma attuale.
Esempi concreti della legge nella gestione dei progetti
- Ritardi nelle consegne: Se un fornitore può essere in ritardo, è molto probabile che lo sarà, e nel momento peggiore.
- Bug software: Una nuova versione, anche meticolosamente preparata, potrebbe causare malfunzionamenti inattesi proprio nel momento critico.
- Malintesi con gli stakeholder: Se una comunicazione può essere fraintesa, probabilmente lo sarà, e sempre nei momenti meno opportuni.
Come contrastare la legge di Murphy?
Un noto corollario a questa legge ci fornisce una pista per la soluzione: “Il diavolo si nasconde nei dettagli.”
Questa espressione, molto comune, sottolinea che sono spesso le piccole particolarità, trascurate o mal gestite, a generare problemi o complicazioni impreviste, lasciando così spazio alla legge di Murphy.
3 raccomandazioni per contrastare la legge di Murphy
- Cura della preparazione del progetto:
Effettuare un’analisi dei rischi, prendendo in considerazione qualità, costi, tempi e prestazioni della soluzione proposta.
- Suddivisione del prodotto:
Scomporre il prodotto da progettare o realizzare in elementi/moduli verificabili singolarmente, evitando di dover attendere le fasi finali, come l’esecuzione o l’installazione presso il cliente, per scoprire eventuali errori.
- Analisi delle cause radice:
Quando la legge di Murphy si manifesta, analizzare attentamente le cause principali del problema, trovare contromisure e correggere eventuali carenze nei processi o nei comportamenti.
Seguendo queste raccomandazioni, è possibile minimizzare l’impatto della legge di Murphy e migliorare significativamente la gestione dei progetti.
Legge di Parkinson: Un lavoro è sempre distribuito per occupare tutto il tempo disponibile.
La legge di Parkinson, formulata da Cyril Northcote Parkinson nel 1955, afferma che: “Il lavoro si espande fino a occupare tutto il tempo disponibile per completarlo.”
In altre parole, più tempo si ha a disposizione per svolgere un compito, più si tende a usarlo, spesso a scapito dell’efficienza.
Applicazione della legge di Parkinson nella gestione dei progetti
- Diluzione degli sforzi:
Nella gestione dei progetti, la legge di Parkinson spiega perché i team rallentano il loro ritmo quando viene concesso un tempo generoso.
Gli sforzi si adattano ai tempi disponibili, estendendo inutilmente la durata necessaria per completare attività semplici.
Esempio:
Se un’attività stimata in 3 giorni viene pianificata su una settimana, è probabile che richieda effettivamente una settimana, poiché il team modulerà i suoi sforzi in base al tempo a disposizione.
- Procrastinazione e inefficienza:
Quando i membri di un team sanno di avere molto tempo per completare un’attività, potrebbero ritardarne l’inizio o concentrarsi su aspetti non prioritari, riducendo così l’efficienza.
- Rischio di aggiunte non necessarie:
Con più tempo a disposizione, i team potrebbero includere funzionalità o dettagli superflui, non essenziali, che complicano inutilmente il progetto.
Conseguenze nella gestione dei progetti:
- Rischio di sforamento dei tempi: Anche con un calendario ben definito, le attività possono dilatarsi, impattando negativamente sulle scadenze del progetto.
- Costi aggiuntivi: Più tempo richiede un’attività, più risorse vengono mobilitate, aumentando le spese.
- Perdita di produttività: La diluizione del lavoro crea una percezione di inefficienza nel team.
Come contrastare la legge di Parkinson?
- Definire scadenze realistiche ma strette:
Dare il tempo giusto per completare un’attività spinge i team a concentrarsi e a lavorare in modo efficace.
- Utilizzare tappe intermedie:
Suddividere un progetto in fasi con scadenze chiare per mantenere un ritmo costante.
- Adottare approcci agili:
Cicli brevi e deliverable frequenti (come nella metodologia Agile) limitano la tendenza a diluire il lavoro su periodi lunghi.
- Promuovere la responsabilizzazione:
Introdurre un monitoraggio regolare e una comunicazione trasparente per assicurarsi che i team restino allineati sugli obiettivi.
- Cambiare il significato della durata di un’attività:
La durata dipende da vari fattori (focalizzazione, multitasking, esperienza, livello di performance atteso), ma ciò che conta è minimizzare il tempo consumato.
È improbabile che il tempo stimato corrisponda esattamente a quello necessario. Di conseguenza, ci sono due scenari possibili:
- L’attività viene completata prima della scadenza.
- L’attività viene completata dopo la scadenza.
Per questo motivo, Synchroboard™ ha eliminato il colore “verde” per indicare che un’attività è completata, perché non riflette questa realtà. Il tempo assegnato a un’attività non è un budget da consumare interamente: appartiene al progetto, non alla persona che lo esegue.
Conclusione
La gestione del tempo in un progetto non deve essere considerata come una semplice allocazione da consumare, ma come una risorsa preziosa da ottimizzare per raggiungere gli obiettivi globali.
Adottando un approccio realistico e flessibile, come quello proposto da Synchroboard™, è possibile ridurre le discrepanze nelle stime e guidare i team verso una gestione più efficace e focalizzata sulle priorità.
Questa visione sottolinea che ogni attività deve servire il progetto, non il contrario, per garantire un reale miglioramento delle prestazioni e dell’efficienza.
Legge di Hofstadter: tutto richiede sempre più tempo del previsto, anche tenendo conto della legge di Hofstadter.
“Ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della Legge di Hofstadter.”
Questa legge evidenzia una verità universale: i progetti, sia personali che professionali, richiedono spesso più tempo del previsto, anche quando si cerca di anticipare possibili ritardi.
Origine e Contesto
Douglas Hofstadter ha formulato questa legge nell’ambito della risoluzione di problemi complessi, come la creazione di intelligenze artificiali o algoritmi. Tuttavia, la sua applicazione si estende ben oltre, risultando rilevante in molti contesti dove la pianificazione è fondamentale.
Cause principali dietro la Legge di Hofstadter
- Sottostima sistematica delle attività:
Le persone tendono a essere troppo ottimiste riguardo alla propria capacità di completare i compiti, trascurando dettagli e imprevisti.
- Complessità dei progetti:
Anche i progetti apparentemente semplici possono nascondere dipendenze o problemi inattesi.
- Effetto di auto-riferimento:
La legge stessa sottolinea che cercare di compensare i ritardi regolando le previsioni non è sufficiente, poiché continueranno a emergere imprevisti.
Implicazioni nella gestione dei progetti
La Legge di Hofstadter ha conseguenze significative sulla pianificazione dei progetti, tra cui:
- Sforamento delle tempistiche: I ritardi diventano quasi inevitabili, anche con una pianificazione attenta.
- Effetto domino: Ritardi in attività critiche possono avere ripercussioni su tutto il progetto.
- Frustrazione delle parti interessate: La difficoltà nel rispettare le scadenze può compromettere la fiducia di clienti o stakeholder.
Come attenuare gli effetti della Legge di Hofstadter?
- Aggiunta di margini di sicurezza:
Non su ogni singola attività, ma su un gruppo di attività correlate che portano a un sottoprodotto del progetto.
Inserire buffer temporali per affrontare gli imprevisti, ispirandosi al concetto di “supermercato” del sistema di produzione just-in-time (JIT).
- Scomposizione delle attività:
Suddividere un progetto in piccoli passi per valutare meglio il tempo necessario per ciascuno. Questo aumenta la precisione nelle previsioni e nell’assegnazione delle risorse.
- Analisi dei rischi:
Identificare le attività critiche e le dipendenze che potrebbero causare ritardi e definire azioni per mitigare i rischi. Spesso questa fase è trascurata o monitorata in modo insufficiente.
- Flessibilità nella pianificazione:
Poiché le attività possono essere completate solo prima o dopo la data prevista, è necessaria una ripianificazione regolare delle attività successive. Questo garantisce una sincronizzazione precisa tra la data di fine di un’attività predecessore e la data di inizio di quella successiva. Questa esigenza ha ispirato il nome della nostra applicazione: Synchroboard™.
- Approcci iterativi:
Incrementare la frequenza delle revisioni e strutturare i progetti in modo da produrre risultati intermedi. Questo riduce l’impatto dei ritardi complessivi.
Conclusione
La Legge di Hofstadter ci ricorda che imprevisti e complessità sono elementi intrinseci di qualsiasi progetto. Piuttosto che cercare una pianificazione perfetta, è fondamentale adottare una gestione flessibile e proattiva, capace di rispondere meglio alle sfide impreviste e garantire risultati più prevedibili e sostenibili.
La legge 90-90: il primo 90% del progetto richiede il 90% del tempo e il restante 10% richiede anche il 90% del tempo.
La Legge 90-90, spesso citata in modo ironico nel campo dello sviluppo software e della gestione dei progetti, afferma:
“Il primo 90% di un progetto richiede il 90% del tempo previsto, e il restante 10% richiede anch’esso il 90% del tempo.”
Interpretazione e Ambito
Questa legge evidenzia un fenomeno ben noto nei progetti complessi: la sottostima degli sforzi richiesti nelle fasi finali del lavoro.
Dimostra come le attività finali, spesso percepite come secondarie o rapide, risultino invece molto più lunghe e complicate del previsto.
- Primo 90%: Di solito comprende le fasi iniziali, come la progettazione, lo sviluppo o l’esecuzione delle linee principali del progetto. Queste fasi sono spesso ben pianificate e rispettano in larga parte il cronoprogramma.
- Ultimo 10%: Riguarda gli aggiustamenti, le correzioni, i test, le validazioni e le rifiniture. Queste attività sono rallentate da imprevisti, cambiamenti dell’ultimo minuto o problemi non previsti.
Cause principali della Legge 90-90
- Sottostima delle rifiniture:
Dettagli come test, correzioni di bug e validazioni finali sono spesso sottovalutati in termini di tempo ed energia richiesti.
- Aumento della complessità:
Con il progredire del progetto, le interdipendenze e le difficoltà diventano più evidenti, rendendo gli ultimi aggiustamenti più complicati.
- Pressione crescente:
Gli ultimi 10% del progetto spesso coincidono con l’approssimarsi della scadenza, aumentando lo stress e la probabilità di errori.
Esempi di Applicazione
- Sviluppo software: Le fasi iniziali, come la scrittura del codice principale, avanzano rapidamente, ma i test finali, le correzioni dei bug e il rilascio richiedono molto più tempo del previsto.
- Edilizia: La struttura principale può essere completata nei tempi previsti, ma le rifiniture (verniciatura, impianti elettrici, decorazioni) spesso causano ritardi.
- Gestione dei progetti: Anche quando le tappe principali sono completate, gli aggiustamenti finali necessari a soddisfare tutte le parti interessate possono richiedere molto tempo.
Come contrastare la Legge 90-90?
- Pianificazione accurata:
Come per la Legge di Hofstadter, includere “supermercati” per ogni sottoprodotto del progetto e, alla fine, un “supermercato” per l’intero progetto. Questo tempo separa la fine dell’ultima attività dalla data effettiva di consegna. In Synchroboard, questo tempo viene chiamato “banca del tempo”, monitorata attraverso un indicatore specifico per garantire che non venga consumata più rapidamente di quanto avanza il progetto, simile al Burn-Down Chart della metodologia Agile.
- Anticipazione dei dettagli:
Prestare maggiore attenzione alla valutazione delle rifiniture e pianificare un tempo adeguato per test, correzioni e aggiustamenti.
- Iterazioni regolari:
Consegnare progressivamente parti del progetto per identificare e risolvere i problemi il prima possibile, evitando di accumularli verso la fine.
- Gestione proattiva dei rischi:
Identificare i punti critici che potrebbero ritardare le ultime fasi del progetto e predisporre azioni di mitigazione.
Conclusione
La Legge 90-90, pur essendo una rappresentazione umoristica, offre un promemoria realistico: nelle fasi finali di un progetto, i dettagli possono richiedere più tempo ed energia del previsto.
Un’efficace pianificazione e una corretta anticipazione degli imprevisti possono ridurre significativamente l’impatto di questo fenomeno, migliorando la gestione complessiva dei progetti.
Legge di Brooks: l’aggiunta di risorse umane a un progetto ritardato lo ritarderà ulteriormente.
La Legge di Brooks, formulata da Fred Brooks nel suo classico libro The Mythical Man-Month (1975), è un principio fondamentale nella gestione dei progetti, in particolare nello sviluppo software. Essa afferma:
“Aggiungere personale a un progetto in ritardo non fa altro che ritardarlo ulteriormente.”
Spiegazione
La Legge di Brooks evidenzia i limiti dell’aggiunta di risorse umane a un progetto in difficoltà.
Contrariamente alla convinzione comune che un lavoro possa sempre essere accelerato aggiungendo più persone, la realtà dimostra che ciò comporta spesso una perdita di produttività per diversi motivi:
- Tempo di integrazione:
I nuovi membri del team devono essere formati e aggiornati sullo stato del progetto, richiedendo tempo e risorse da parte dei membri già operativi.
- Aumento della complessità comunicativa:
Con l’aumento del numero di persone, gli sforzi di coordinamento crescono esponenzialmente, complicando la comunicazione e il processo decisionale.
- Attività indivisibili:
Alcuni aspetti di un progetto (come la progettazione o la risoluzione di problemi complessi) non possono essere suddivisi tra più persone.
Aggiungere risorse non apporta quindi alcun beneficio in questi casi.
Contesto e Applicazioni
- Sviluppo software:
Brooks osservò questa legge in progetti di grande scala, dove i ritardi peggioravano con l’aggiunta di sviluppatori a causa delle sfide legate alla coordinazione e all’integrazione.
- Gestione dei progetti in generale:
La legge si applica anche ad altri settori, dove l’inserimento di nuove risorse umane in un contesto disorganizzato o già in ritardo provoca ulteriore caos e inefficienza.
Esempio pratico
Immaginiamo un progetto in ritardo in cui 5 sviluppatori lavorano su un’applicazione complessa. Aggiungere 3 nuovi sviluppatori costringerà i primi 5 a:
- Formare i nuovi arrivati.
- Riorganizzare il lavoro e gestire le dipendenze.
Questo rallenterà il loro ritmo di lavoro, aggravando temporaneamente i ritardi invece di risolverli.
Come contrastare la Legge di Brooks?
- Pianificare meglio fin dall’inizio:
Anticipare le necessità di risorse umane e prevedere margini di sicurezza realistici.
È un principio fondamentale, eppure spesso questa valutazione viene trascurata o male eseguita.
- Modularizzare le attività:
Suddividere i progetti in sottosistemi indipendenti per consentire ai nuovi membri di contribuire senza interrompere l’intero flusso.
Questa modularità dovrebbe riflettere quella del prodotto oggetto del progetto, ormai un prerequisito per la competitività.
- Migliorare strumenti e processi:
Utilizzare strumenti di gestione che facilitino la collaborazione e riducano gli sforzi comunicativi.
In questo contesto, Synchroboard si distingue.
Il suo sistema visivo estremamente efficiente permette, in meno di un minuto, persino a una persona esterna al progetto di verificare se il progetto è gestito correttamente o meno.
- Rivedere la pianificazione:
In alcuni casi, è preferibile accettare un ritardo e riorganizzare il lavoro piuttosto che sovraccaricare il team.
Questo approccio è essenziale e parte integrante delle pratiche insegnate nell’ecosistema Synchroboard.
Conclusione
La Legge di Brooks ci ricorda che i progetti complessi non possono sempre essere accelerati semplicemente aumentando il personale.
Una pianificazione accurata, una struttura ben definita e processi efficaci sono fondamentali per evitare ritardi e inefficienze, garantendo così una gestione del progetto più fluida e produttiva.
Legge di Humphrey: gli utenti non sempre sanno cosa vogliono finché non se ne rendono conto.
La Legge di Humphrey, attribuita a Watts Humphrey, pioniere dell’ingegneria del software e creatore del Capability Maturity Model (CMM), afferma:
“Gli utenti non sanno cosa vogliono finché non lo vedono.”
Interpretazione
Questa legge evidenzia una sfida fondamentale nello sviluppo dei prodotti, in particolare nel settore software: i requisiti degli utenti sono spesso mal definiti o in continua evoluzione. Anche quando le esigenze iniziali sono espresse chiaramente, possono rivelarsi imprecise o inadatte a soddisfare i bisogni reali.
Cause principali della Legge di Humphrey
- Visione limitata degli utenti:
Senza una dimostrazione concreta, gli utenti possono avere difficoltà a immaginare come un prodotto o una soluzione risponderà alle loro necessità.
- Evoluzione delle aspettative:
Man mano che un progetto avanza, gli utenti acquisiscono una comprensione più chiara dei loro bisogni reali, spesso diversi da quelli iniziali.
- Complessità dei progetti:
I sistemi software, in particolare, sono spesso così complessi che le loro interazioni e funzionalità non possono essere completamente comprese prima dell’implementazione.
Implicazioni nella gestione dei progetti e nello sviluppo software
- Deriva dei requisiti:
I frequenti cambiamenti nelle esigenze degli utenti (noti anche come scope creep) possono causare ritardi, superamenti del budget e frustrazioni.
- Comunicazione insufficiente:
La legge sottolinea l’importanza di una comunicazione continua tra il team di sviluppo e gli utenti per ridurre i fraintendimenti.
- Necessità del prototipazione:
Giustifica l’uso di mockup, prototipi o versioni preliminari per consentire agli utenti di “vedere” e affinare le loro aspettative.
Approcci per gestire la Legge di Humphrey
- Metodologie Agile:
Approcci come Scrum o Kanban permettono di consegnare versioni incrementali del prodotto, raccogliendo feedback dagli utenti e adeguando rapidamente le funzionalità.
Tuttavia, questa strategia deve essere usata con attenzione: un approccio incrementale e iterativo non deve sostituire una vera esplorazione dei bisogni e delle loro priorità, cosa che il metodo Quality Function Deployment (QFD) fa in modo eccellente.
- Prototipazione rapida:
Creare mockup o prototipi funzionanti per permettere agli utenti di testare e affinare le loro aspettative sin dalle prime fasi del progetto.
- Workshop collaborativi:
Coinvolgere attivamente gli utenti durante le fasi di progettazione per ridurre la distanza tra i bisogni reali e quelli dichiarati.
- Test frequenti con gli utenti:
Organizzare sessioni di test con utenti reali durante tutto il progetto per convalidare le funzionalità in sviluppo.
Conclusione
La Legge di Humphrey ricorda con forza che i progetti devono essere flessibili e centrati sugli utenti.
Utilizzando metodologie appropriate e collaborando strettamente con le parti interessate, i team possono ridurre le incertezze e soddisfare i bisogni reali degli utenti, anche quando questi evolvono nel tempo.
Tuttavia, considerare l’evoluzione delle esigenze non deve in alcun modo prolungare la durata complessiva del progetto.
La legge della complessità: più un progetto è complesso, maggiori sono i potenziali punti di errore.
La Legge della Complessità, pur non essendo formalmente definita come una “legge” unica, si riferisce all’idea che la complessità di un sistema o di un progetto tenda a crescere nel tempo, spesso in modo esponenziale, man mano che vengono aggiunti nuovi elementi.
Una possibile formulazione di questa idea è:
“La complessità aumenta con la scala di un progetto o di un sistema, e ogni aggiunta rende la gestione e la comprensione più difficili.”
Origine e Contesto
Questa legge si basa su principi osservati in vari ambiti, tra cui:
- Gestione dei progetti: Ogni attività o dipendenza aggiunta aumenta la difficoltà di coordinazione.
- Sviluppo software: Ogni nuova riga di codice, funzionalità o correzione di bug può introdurre dipendenze e rischi imprevisti.
- Sistemi complessi in generale: Interazioni inattese emergono quando il sistema diventa più grande o sofisticato.
Principali Concetti Legati alla Legge della Complessità
- Crescita esponenziale della comunicazione:
Quando cresce la dimensione di un team o di un progetto, il numero di canali di comunicazione aumenta in modo esponenziale, secondo la formula , dove è il numero di membri. Ciò complica la coordinazione e aumenta il rischio di malintesi.
- “Debito tecnico”:
Nello sviluppo software, ogni modifica rapida o non pianificata può aggiungere complessità al sistema, richiedendo maggiori sforzi per la manutenzione o il miglioramento nel lungo periodo.
- Entropia organizzativa:
Nelle organizzazioni o nei progetti, l’introduzione di regole, processi o strumenti aggiuntivi può rendere il sistema più rigido, lento e difficile da gestire.
- Legge dei rendimenti decrescenti:
Aggiungendo elementi per risolvere un problema o migliorare un sistema, i benefici ottenuti diventano sempre meno significativi rispetto allo sforzo aggiuntivo richiesto.
Implicazioni della Legge della Complessità nella Gestione dei Progetti
- Difficoltà di coordinazione:
Più un progetto è grande e complesso, più diventa difficile allineare gli sforzi delle diverse parti interessate.
- Rischio maggiore di errori:
Con l’aumento delle interdipendenze, un errore minore può avere conseguenze sproporzionate sull’intero progetto.
- Aumento di tempi e costi:
La complessità aggiunge ulteriori livelli di lavoro (pianificazione, comunicazione, correzione), impattando negativamente sulle scadenze e sui budget.
Come Gestire la Complessità?
- Semplificazione proattiva:
- Suddividere progetti o sistemi in moduli indipendenti.
- Ridurre le dipendenze tra le attività.
- Prioritizzazione delle attività essenziali:
Concentrarsi sugli elementi ad alto valore aggiunto ed evitare aggiunte inutili che aumentano la complessità senza benefici chiari.
Questo punto è cruciale nei pannelli utilizzati nell’applicazione Synchroboard™, dove solo le attività che coinvolgono due o più parti interessate (generalmente settori o funzioni) vengono gestite. Le attività interne a ogni funzione sono gestite localmente per non disperdere l’attenzione del project manager e delle parti coinvolte sugli obiettivi chiave del progetto.
- Automazione e strumenti adeguati:
Utilizzare strumenti di gestione per semplificare i processi e migliorare la comunicazione.
- Metodologie Agile:
Adottare approcci flessibili come Scrum, che promuovono cicli brevi e frequenti aggiustamenti, riducendo i rischi legati all’accumulo di complessità.
- Documentazione rigorosa:
Mantenere una documentazione chiara e aggiornata per favorire una migliore comprensione e gestione di sistemi complessi.
Conclusione
La Legge della Complessità ricorda che qualsiasi sistema o progetto, se non viene attivamente semplificato, tende a diventare sempre più difficile da comprendere e gestire.
Integrando pratiche adeguate e mantenendo un equilibrio tra innovazione e stabilità, è possibile limitare gli effetti negativi della complessità crescente.
Legge di Maier: Se il problema non è ben definito, anche la soluzione sarà problematica.
La Legge di Maier, formulata dall’ingegnere e specialista di sistemi Robert Maier, è un principio spesso citato nell’ingegneria dei sistemi e nella gestione dei progetti. Essa afferma:
“Se il problema non è chiaramente definito, la migliore soluzione non può essere identificata.”
Interpretazione
La Legge di Maier sottolinea un aspetto fondamentale della risoluzione dei problemi: l’importanza cruciale di una comprensione chiara e precisa del problema prima di cercare soluzioni.
Un problema mal definito porta a soluzioni inefficaci o inadeguate, spesso costose in termini di tempo e risorse.
Cause Frequenti di Problemi Mal Definiti
- Mancanza di chiarezza negli obiettivi:
Le parti interessate non concordano su ciò che vogliono ottenere.
- Comprensione errata:
I bisogni degli utenti o dei clienti non sono ben compresi o espressi.
- Complessità o ambiguità del problema:
Gli aspetti critici del problema vengono oscurati da dettagli secondari o mal prioritizzati.
- Ipotesi implicite:
Le parti interessate o i team suppongono di conoscere il problema senza averlo analizzato esplicitamente.
Applicazione nella Gestione dei Progetti
- Importanza della definizione dei requisiti:
Un problema mal definito può portare a specifiche poco chiare, rendendo difficile misurare il successo o il fallimento del progetto.
- Impatto su tempi e budget:
I progetti spesso iniziano con un’idea vaga degli obiettivi, il che porta a costosi aggiustamenti in corso d’opera.
Sebbene si dica che non bisogna aspettare di avere tutto chiaro per iniziare, si rischia di cadere nell’eccesso opposto, dove il tempo per correggere supera quello necessario per chiarire meglio in partenza.
Come recita un altro adagio: “Affrettati lentamente.”
- Deriva dei requisiti (scope creep):
La mancanza di chiarezza iniziale favorisce l’aggiunta progressiva di nuove richieste, complicando la gestione di risorse e tempi.
A questo proposito, il processo di esplorazione dei bisogni della metodologia Quality Function Deployment (Blitz QFD) è estremamente efficace.
Come Applicare la Legge di Maier?
- Analisi approfondita del problema:
- Utilizzare l’approccio esplorativo come il Blitz QFD.
- Applicare strumenti come il diagramma di Ishikawa (diagramma causa-effetto) per identificare le cause profonde.
- Organizzare workshop collaborativi con le parti interessate per chiarire bisogni e aspettative.
- Definire obiettivi SMART:
Gli obiettivi devono essere:
- Specifici
- Misurabili
- Raggiungibili
- Rilevanti
- Definiti temporalmente
- Formalizzare i requisiti:
Documentare le specifiche in modo chiaro e dettagliato per evitare fraintendimenti.
- Prototipazione rapida:
Creare un prototipo o un mockup per validare la comprensione del problema da parte degli utenti e delle parti interessate.
- Comunicazione attiva:
Implementare un processo di feedback regolare per affinare la definizione del problema e garantire l’allineamento tra tutti gli attori.
In Synchroboard™, questo passaggio rientra nel concetto di “tripla chiave”, un punto di controllo (gate) in cui si verifica, tra le altre cose, che le specifiche siano corrette e che il cliente non le stia riconsiderando o modificando.
Esempio Pratico
Nello sviluppo di un software per la gestione dell’inventario, se il problema viene definito semplicemente come:
“Abbiamo bisogno di un sistema per gestire i nostri magazzini”,
potrebbe portare a soluzioni inadeguate.
Approfondendo, si scopre che il vero problema è:
“Abbiamo bisogno di ridurre gli errori umani nell’inserimento manuale e migliorare il monitoraggio dei prodotti in tempo reale.”
Questa definizione precisa guida la creazione di una soluzione adeguata.
Conclusione
La Legge di Maier ricorda che il tempo dedicato a definire chiaramente un problema è un investimento cruciale per garantire il successo di un progetto.
Un’analisi chiara e dettagliata dei bisogni, combinata con una comunicazione efficace, è la chiave per identificare soluzioni che rispondano realmente alle aspettative delle parti interessate e alle esigenze del contesto.
Legge di Peters: i team di progetto finiscono sempre per produrre ciò che è più facile da dimostrare, non necessariamente ciò che è più utile.
“Un team di progetto finisce sempre per fare ciò che è più facile da dimostrare, e non ciò che è più importante.”
Interpretazione
Questa legge evidenzia una tendenza comune nella gestione dei progetti:
i team tendono a dare priorità alle attività o ai risultati più visibili e misurabili, a scapito di quelli essenziali ma meno tangibili o difficili da quantificare.
Questo può portare a progetti in cui gli obiettivi strategici vengono trascurati a favore di deliverable secondari o simbolici.
Perché accade questa tendenza?
- Pressione per mostrare progressi visibili:
Stakeholder e management richiedono spesso prove concrete di avanzamento, spingendo i team a concentrarsi su attività dimostrabili.
- Facilità di esecuzione:
I membri del team preferiscono affrontare compiti semplici o tecnicamente accessibili, lasciando da parte elementi complessi o strategici.
- Scarsa definizione delle priorità:
In assenza di priorità chiare, i team possono focalizzarsi su attività che sembrano più gratificanti nel breve termine.
- Mancanza di visione strategica:
Quando gli obiettivi globali non sono ben compresi, i team si concentrano su ciò che è facile da quantificare.
Implicazioni nella Gestione dei Progetti
- Deviazione dagli obiettivi strategici:
Il progetto rischia di produrre deliverable conformi in apparenza, ma che non rispondono ai bisogni reali o critici.
- Perdita di tempo e risorse:
Gli sforzi si concentrano su attività secondarie invece di focalizzarsi sugli aspetti chiave.
- Frustrazione degli stakeholder:
Se i risultati finali non rispecchiano le aspettative strategiche, possono emergere conflitti o insoddisfazioni.
Come contrastare gli effetti della Legge di Peters?
- Definire chiaramente le priorità:
- Devono essere priorità di progetto, non individuali.
- Stabilire traguardi basati su criteri d’impatto, non solo di visibilità.
- Promuovere una visione a lungo termine:
- Formare i team a ragionare in termini di obiettivi globali e impatti.
- Sottolineare il valore strategico delle attività, anche se meno visibili.
- Monitorare gli indicatori chiave:
- Introdurre KPI (Key Performance Indicators) pertinenti che misurino i risultati importanti, non solo le fasi intermedie.
- Una dashboard di progetto deve includere indicatori di processo e indicatori di risultato, rispettando il principio: “Il processo seguito conduce ai risultati che ne derivano.”
- Coinvolgere gli stakeholder:
- Mantenere una comunicazione regolare per ricordare le priorità e allineare le aspettative.
- Incoraggiare una cultura del feedback:
- Organizzare revisioni periodiche per valutare se gli sforzi attuali contribuiscono davvero agli obiettivi globali.
Esempio Pratico
In un progetto di sviluppo software, il team potrebbe concentrarsi sulla progettazione di un’interfaccia utente accattivante (facile da mostrare durante le presentazioni) invece di ottimizzare il sistema backend, che è più complesso ma essenziale per le prestazioni complessive del prodotto.
Conclusione
La Legge di Peters è un prezioso promemoria per i project manager: non basta mostrare risultati visibili.
Gli sforzi devono essere allineati a ciò che è realmente importante per il successo globale del progetto.
Una gestione proattiva, una chiara definizione delle priorità e una visione strategica sono essenziali per contrastare questa tendenza naturale.
Legge di Kidder: Le cose che vengono misurate migliorano. Le cose che vengono ignorate si deteriorano.
La Legge di Kidder, attribuita a Tracy Kidder, scrittore e autore del libro The Soul of a New Machine (1981), afferma:
“Le persone che non hanno il tempo di fare bene le cose fin dall’inizio troveranno sempre il tempo per rifarle.”
Interpretazione
La Legge di Kidder sottolinea l’importanza di dedicare il tempo necessario a fare bene le cose fin dall’inizio, soprattutto in progetti complessi come lo sviluppo software, la gestione dei progetti o l’ingegneria.
Evidenzia un fenomeno comune: un approccio affrettato nelle fasi iniziali spesso porta a errori costosi, che richiedono correzioni successive, con conseguenti ritardi e sforamenti del budget.
Implicazioni nella Gestione dei Progetti
- Costo degli errori iniziali:
Un lavoro mal fatto all’inizio genera problemi che diventano sempre più costosi da correggere man mano che il progetto avanza.
Ad esempio, un errore di progettazione non rilevato potrebbe richiedere una riprogettazione completa in una fase avanzata.
- Perdita di tempo:
Sebbene si pensi di risparmiare tempo avanzando rapidamente, i ritorni indietro e le correzioni richiedono spesso molto più tempo rispetto a quanto si sarebbe impiegato facendo le cose bene fin dall’inizio.
- Impatto sulla qualità:
I prodotti o i deliverable sottoposti a numerose correzioni rischiano di essere di qualità inferiore, poiché gli aggiustamenti successivi possono introdurre incoerenze o compromessi.
Esempi Pratici
- Sviluppo software:
Se si salta la fase dei test iniziali per risparmiare tempo, i bug non rilevati potrebbero emergere in produzione, richiedendo correzioni urgenti e costose.
- Costruzioni:
Una stima errata dei materiali o una preparazione trascurata potrebbe causare ritardi significativi e costi aggiuntivi.
Come Evitare gli Effetti della Legge di Kidder
- Pianificazione accurata:
- Investire tempo nella pianificazione iniziale per identificare requisiti, rischi e tappe fondamentali.
- Stabilire step intermedi per evitare la fretta eccessiva.
- Definire standard di qualità:
- Creare criteri di qualità chiari per superare le varie fasi del progetto.
- Assicurarsi che ogni fase rispetti questi standard prima di procedere alla successiva.
- Adottare metodologie iterative:
- Utilizzare approcci come Agile, che consentono di sviluppare incrementi successivi integrando feedback regolari per evitare grandi ritorni indietro.
- Nell’ecosistema Synchroboard, questo avviene durante la fase di strutturazione del progetto, che deriva dal piano di mitigazione dei rischi.
- Investire nelle fasi critiche:
- Prestare particolare attenzione alle prime fasi del progetto (ricerca, progettazione, test iniziali) per costruire basi solide.
- Formare i team:
- Assicurarsi che tutti i membri del team comprendano l’importanza di fare bene le cose fin dall’inizio e dispongano delle competenze necessarie.
- Ricordare il detto: “Un lavoro mal fatto all’inizio costa da 7 a 13 volte di più in termini di tempo o risorse per correggerlo”, per modificare i comportamenti.
Conclusione
La Legge di Kidder ci ricorda che la fretta nelle fasi iniziali di un progetto può avere conseguenze costose.
Prendersi il tempo per pianificare, eseguire e validare accuratamente fin dall’inizio è un investimento che consente di risparmiare risorse, migliorare la qualità e garantire il successo complessivo del progetto.
Legge di Cohn: le decisioni più importanti sono spesso prese sulla base di informazioni incomplete.
La Legge di Cohn, formulata da Mike Cohn, esperto nello sviluppo Agile e autore di diversi libri sull’argomento, afferma:
“Più è difficile cambiare un aspetto di un sistema, più è importante definirlo correttamente fin dall’inizio.”
Interpretazione della Legge di Cohn
La Legge di Cohn evidenzia l’importanza di dare priorità agli aspetti critici di un progetto o di un sistema, specialmente quelli che saranno difficili, costosi o impossibili da modificare in futuro.
Sottolinea che alcune scelte, come le fondamenta di un’architettura software o i principi di base di un prodotto, richiedono particolare attenzione fin dalle prime fasi di progettazione.
Implicazioni nella Gestione dei Progetti
- Le decisioni strutturali hanno un impatto duraturo:
Le scelte iniziali di un progetto, come la tecnologia o la modularità, influenzano significativamente il percorso futuro.
Se queste decisioni sono sbagliate, le correzioni possono essere molto costose e complesse.
- Importanza dell’analisi iniziale:
Gli aspetti difficili da cambiare, come le dipendenze critiche, le norme di qualità o gli obiettivi strategici, devono essere analizzati attentamente prima di avviare il progetto.
- Flessibilità negli aspetti secondari:
Gli elementi facilmente modificabili, come l’interfaccia utente o funzionalità non critiche, possono essere decisi in un secondo momento o adattati a costi ridotti.
Esempi Pratici
Sviluppo software:
Se un sistema software viene progettato senza considerare la scalabilità (la capacità di gestire un aumento del carico), correggere questo errore quando il sistema è in produzione sarà estremamente costoso. La scalabilità, essendo difficile da modificare, deve essere pianificata fin dall’inizio.
Costruzioni:
Nella costruzione di un edificio, le fondamenta devono essere progettate con precisione perché sono quasi impossibili da modificare una volta realizzate, a differenza degli elementi decorativi o delle pareti interne.
Come Applicare la Legge di Cohn?
- Identificare gli elementi critici:
- Eseguire un’analisi approfondita per individuare gli aspetti che saranno costosi o complessi da modificare (es. architettura, infrastruttura, obiettivi strategici).
- Dare priorità alle decisioni fondamentali:
- Investire più tempo e risorse per definire chiaramente gli aspetti chiave all’inizio del progetto.
- Lasciare maggiore flessibilità agli elementi secondari o facilmente modificabili.
- Anticipare i cambiamenti possibili:
- Utilizzare modelli o architetture flessibili (es. modularità nello sviluppo software o nella progettazione) per ridurre al minimo gli impatti delle modifiche future.
- Validare le scelte critiche:
- Creare prototipi o effettuare validazioni preliminari per garantire che le scelte iniziali siano in linea con gli obiettivi.
Conclusione
La Legge di Cohn ricorda che non tutte le decisioni di un progetto hanno la stessa importanza o le stesse conseguenze.
Identificando e dando priorità alle scelte fondamentali, i team di progetto possono ridurre i rischi, evitare costi inutili e stabilire solide basi per il successo a lungo termine.
Legge di Weinberg: un team lavorerà entro il suo livello di tolleranza al fallimento
La Legge di Weinberg, formulata da Gerald Weinberg, esperto di gestione dei progetti e sviluppo software, afferma:
“Se gli sviluppatori hanno la sensazione che i loro dati saranno usati per punirli, falsificheranno i dati.”
Interpretazione della Legge
La Legge di Weinberg mette in evidenza un problema comune negli ambienti di lavoro in cui la performance delle squadre o dei singoli individui viene misurata in modo rigido e punitivo.
Quando i dipendenti percepiscono valutazioni o indicatori come una minaccia, possono manipolare dati o rapporti per evitare conseguenze negative, invece di segnalare onestamente difficoltà o problemi incontrati.
Implicazioni nella Gestione dei Progetti
- Metriche distorte:
Rapporti e indicatori di performance diventano poco affidabili, poiché i dipendenti cercano di “proteggersi” invece di riflettere la realtà.
- Perdita di trasparenza:
Una cultura punitiva incoraggia la dissimulazione dei problemi, ritardandone l’identificazione e la risoluzione.
- Impatto sulla collaborazione:
Un’atmosfera di sfiducia ostacola la comunicazione aperta tra i membri del team e può isolare gli individui.
- Fallimento dei progetti:
Quando le decisioni di gestione si basano su dati inesatti o falsificati, i progetti rischiano di deviare dagli obiettivi o di fallire.
Esempio Pratico
In un team di sviluppo prodotto, se un project manager insiste su scadenze rigide minacciando sanzioni in caso di ritardi, i membri del team potrebbero riportare progressi esagerati o incompleti, nascondendo problemi tecnici o bug.
Questi problemi, non rilevati in tempo, possono causare ritardi maggiori o portare a un prodotto di qualità inferiore.
Come Evitare gli Effetti della Legge di Weinberg?
- Creare le condizioni per sviluppare l’intelligenza emotiva anziché il management repressivo:
- Incoraggiare una comunicazione aperta in cui i membri del team si sentano sicuri di segnalare problemi o ritardi senza temere ritorsioni.
- Valorizzare gli apprendimenti derivati dagli errori invece di punirli. Si impara di più dagli errori che dai successi.
- Utilizzare le metriche come strumento di miglioramento:
- Presentare gli indicatori di performance come un mezzo per diagnosticare e migliorare i processi, non come un’arma per giudicare o sanzionare.
- Favorire la trasparenza:
- Coinvolgere i team nella definizione delle metriche di performance, assicurandosi che siano pertinenti e comprese da tutti.
- Fornire feedback costruttivi basati sui dati, senza accuse né critiche.
- Adottare pratiche agili:
- Organizzare retrospettive regolari per discutere apertamente le sfide incontrate e i modi per migliorare.
- Promuovere un approccio incrementale, in cui i problemi vengano identificati e risolti presto nel ciclo di sviluppo.
- Responsabilizzare senza minacce:
- Concentrarsi sulla responsabilità collettiva del team piuttosto che sulle performance individuali.
Conclusione
La Legge di Weinberg ricorda che un approccio punitivo nell’uso dei dati può compromettere la trasparenza e l’affidabilità delle informazioni cruciali per il successo di un progetto.
Promuovendo una cultura di fiducia, apprendimento e collaborazione, si incoraggiano comportamenti onesti e proattivi, essenziali per il successo dei progetti.
Questo approccio è al centro dell’ecosistema Synchroboard™, che favorisce lo sviluppo dell’intelligenza collettiva come la migliore forma di performance operativa.
Alcune statistiche sorprendenti sulla gestione dei progetti
La gestione dei progetti è una disciplina complessa in cui ogni fase richiede una pianificazione accurata e un’esecuzione metodica.
Per massimizzare le possibilità di successo, è fondamentale integrare le leggi e le buone pratiche comunemente riconosciute.
Questi principi, sviluppati attraverso decenni di esperienza, consentono di anticipare gli ostacoli, gestire efficacemente le risorse e garantire risultati coerenti.
Adottando questi principi, i project manager riducono le incertezze e aumentano la capacità del team di affrontare gli imprevisti.
Il rispetto delle leggi e delle buone pratiche assicura una struttura solida e permette di trasformare un progetto complesso in un successo misurabile, ottimizzando al contempo il tempo e le risorse investiti.
Queste leggi sono state integrate nell’ecosistema synchroboard™. Te ne diamo la mostra personnale interpretazione qui sotto.
Certo, esistono altre leggi, aforismi, detti e massime che non necessitano di spiegazioni, tanto sono evidenti nella loro semplicità.
Vorrei citarne alcune:
- « MOONSHINE », attribuita al mio sensei Akao San:« Non perdere tempo a spiegare ai tuoi capi cosa vuoi fare e perché. Non conoscono il gemba. Fallo senza dire nulla e poi mostra ciò che hai realizzato. Sentirai i tuoi capi dire: “È esattamente quello che volevo che tu facessi.” »
- « La velocità conta poco, ciò che importa è andare nella giusta direzione. », una massima di Lord Baden Powell, fondatore dello scoutismo, che diceva anche, a proposito della leadership: « Se corri, loro camminano. Se cammini, loro si siedono. Se ti siedi, loro si sdraiano. »
Infine, alcune leggi attribuite ad AMA, un consulente senior che conosco da tempo:
- « Siamo sempre più esperti nel risolvere i problemi degli altri che nel risolvere i nostri, per i quali troviamo sempre mille giustificazioni. »
- Il suo corollario: « Siamo sempre meno tolleranti verso gli altri che verso noi stessi. »
- « La differenza tra spiegazione e giustificazione è la stessa che c’è tra chi migliora e chi resta fermo nello status quo. »
- « È una follia pensare di essere utili dedicando del tempo a fare con meno competenze ciò che un collega non ha fatto per mancanza di tempo. »
Legge di Murphy: Tutto ciò che può andare storto, andrà storto
Anche se spesso viene vista come una battuta umoristica o pessimistica, questa legge riflette una realtà importante in molti ambiti, soprattutto nella gestione dei progetti.
Per esperienza personale, ho elaborato una variante ancora più realistica:
“Tutto ciò che può andare storto, andrà storto e nel peggior momento possibile!”
Origine della legge di Murphy
La legge prende il nome da Edward A. Murphy Jr., un ingegnere aeronautico statunitense che lavorava negli anni ’40 a test di tolleranza umana alla gravità.
Durante un esperimento fallito a causa di un dispositivo installato in modo errato, Murphy avrebbe dichiarato: “Se qualcuno può commettere un errore, lo farà.”
Da allora, l’espressione è stata abbreviata nella sua forma attuale.
Esempi concreti della legge nella gestione dei progetti
- Ritardi nelle consegne: Se un fornitore può essere in ritardo, è molto probabile che lo sarà, e nel momento peggiore.
- Bug software: Una nuova versione, anche meticolosamente preparata, potrebbe causare malfunzionamenti inattesi proprio nel momento critico.
- Malintesi con gli stakeholder: Se una comunicazione può essere fraintesa, probabilmente lo sarà, e sempre nei momenti meno opportuni.
Come contrastare la legge di Murphy?
Un noto corollario a questa legge ci fornisce una pista per la soluzione: “Il diavolo si nasconde nei dettagli.”
Questa espressione, molto comune, sottolinea che sono spesso le piccole particolarità, trascurate o mal gestite, a generare problemi o complicazioni impreviste, lasciando così spazio alla legge di Murphy.
3 raccomandazioni per contrastare la legge di Murphy
- Cura della preparazione del progetto:
Effettuare un’analisi dei rischi, prendendo in considerazione qualità, costi, tempi e prestazioni della soluzione proposta.
- Suddivisione del prodotto:
Scomporre il prodotto da progettare o realizzare in elementi/moduli verificabili singolarmente, evitando di dover attendere le fasi finali, come l’esecuzione o l’installazione presso il cliente, per scoprire eventuali errori.
- Analisi delle cause radice:
Quando la legge di Murphy si manifesta, analizzare attentamente le cause principali del problema, trovare contromisure e correggere eventuali carenze nei processi o nei comportamenti.
Seguendo queste raccomandazioni, è possibile minimizzare l’impatto della legge di Murphy e migliorare significativamente la gestione dei progetti.
Legge di Parkinson: Un lavoro è sempre distribuito per occupare tutto il tempo disponibile.
La legge di Parkinson, formulata da Cyril Northcote Parkinson nel 1955, afferma che: “Il lavoro si espande fino a occupare tutto il tempo disponibile per completarlo.”
In altre parole, più tempo si ha a disposizione per svolgere un compito, più si tende a usarlo, spesso a scapito dell’efficienza.
Applicazione della legge di Parkinson nella gestione dei progetti
- Diluzione degli sforzi:
Nella gestione dei progetti, la legge di Parkinson spiega perché i team rallentano il loro ritmo quando viene concesso un tempo generoso.
Gli sforzi si adattano ai tempi disponibili, estendendo inutilmente la durata necessaria per completare attività semplici.
Esempio:
Se un’attività stimata in 3 giorni viene pianificata su una settimana, è probabile che richieda effettivamente una settimana, poiché il team modulerà i suoi sforzi in base al tempo a disposizione.
- Procrastinazione e inefficienza:
Quando i membri di un team sanno di avere molto tempo per completare un’attività, potrebbero ritardarne l’inizio o concentrarsi su aspetti non prioritari, riducendo così l’efficienza.
- Rischio di aggiunte non necessarie:
Con più tempo a disposizione, i team potrebbero includere funzionalità o dettagli superflui, non essenziali, che complicano inutilmente il progetto.
Conseguenze nella gestione dei progetti:
- Rischio di sforamento dei tempi: Anche con un calendario ben definito, le attività possono dilatarsi, impattando negativamente sulle scadenze del progetto.
- Costi aggiuntivi: Più tempo richiede un’attività, più risorse vengono mobilitate, aumentando le spese.
- Perdita di produttività: La diluizione del lavoro crea una percezione di inefficienza nel team.
Come contrastare la legge di Parkinson?
- Definire scadenze realistiche ma strette:
Dare il tempo giusto per completare un’attività spinge i team a concentrarsi e a lavorare in modo efficace.
- Utilizzare tappe intermedie:
Suddividere un progetto in fasi con scadenze chiare per mantenere un ritmo costante.
- Adottare approcci agili:
Cicli brevi e deliverable frequenti (come nella metodologia Agile) limitano la tendenza a diluire il lavoro su periodi lunghi.
- Promuovere la responsabilizzazione:
Introdurre un monitoraggio regolare e una comunicazione trasparente per assicurarsi che i team restino allineati sugli obiettivi.
- Cambiare il significato della durata di un’attività:
La durata dipende da vari fattori (focalizzazione, multitasking, esperienza, livello di performance atteso), ma ciò che conta è minimizzare il tempo consumato.
È improbabile che il tempo stimato corrisponda esattamente a quello necessario. Di conseguenza, ci sono due scenari possibili:
- L’attività viene completata prima della scadenza.
- L’attività viene completata dopo la scadenza.
Per questo motivo, Synchroboard™ ha eliminato il colore “verde” per indicare che un’attività è completata, perché non riflette questa realtà. Il tempo assegnato a un’attività non è un budget da consumare interamente: appartiene al progetto, non alla persona che lo esegue.
Conclusione
La gestione del tempo in un progetto non deve essere considerata come una semplice allocazione da consumare, ma come una risorsa preziosa da ottimizzare per raggiungere gli obiettivi globali.
Adottando un approccio realistico e flessibile, come quello proposto da Synchroboard™, è possibile ridurre le discrepanze nelle stime e guidare i team verso una gestione più efficace e focalizzata sulle priorità.
Questa visione sottolinea che ogni attività deve servire il progetto, non il contrario, per garantire un reale miglioramento delle prestazioni e dell’efficienza.
Legge di Hofstadter: tutto richiede sempre più tempo del previsto, anche tenendo conto della legge di Hofstadter.
“Ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della Legge di Hofstadter.”
Questa legge evidenzia una verità universale: i progetti, sia personali che professionali, richiedono spesso più tempo del previsto, anche quando si cerca di anticipare possibili ritardi.
Origine e Contesto
Douglas Hofstadter ha formulato questa legge nell’ambito della risoluzione di problemi complessi, come la creazione di intelligenze artificiali o algoritmi. Tuttavia, la sua applicazione si estende ben oltre, risultando rilevante in molti contesti dove la pianificazione è fondamentale.
Cause principali dietro la Legge di Hofstadter
- Sottostima sistematica delle attività:
Le persone tendono a essere troppo ottimiste riguardo alla propria capacità di completare i compiti, trascurando dettagli e imprevisti.
- Complessità dei progetti:
Anche i progetti apparentemente semplici possono nascondere dipendenze o problemi inattesi.
- Effetto di auto-riferimento:
La legge stessa sottolinea che cercare di compensare i ritardi regolando le previsioni non è sufficiente, poiché continueranno a emergere imprevisti.
Implicazioni nella gestione dei progetti
La Legge di Hofstadter ha conseguenze significative sulla pianificazione dei progetti, tra cui:
- Sforamento delle tempistiche: I ritardi diventano quasi inevitabili, anche con una pianificazione attenta.
- Effetto domino: Ritardi in attività critiche possono avere ripercussioni su tutto il progetto.
- Frustrazione delle parti interessate: La difficoltà nel rispettare le scadenze può compromettere la fiducia di clienti o stakeholder.
Come attenuare gli effetti della Legge di Hofstadter?
- Aggiunta di margini di sicurezza:
Non su ogni singola attività, ma su un gruppo di attività correlate che portano a un sottoprodotto del progetto.
Inserire buffer temporali per affrontare gli imprevisti, ispirandosi al concetto di “supermercato” del sistema di produzione just-in-time (JIT).
- Scomposizione delle attività:
Suddividere un progetto in piccoli passi per valutare meglio il tempo necessario per ciascuno. Questo aumenta la precisione nelle previsioni e nell’assegnazione delle risorse.
- Analisi dei rischi:
Identificare le attività critiche e le dipendenze che potrebbero causare ritardi e definire azioni per mitigare i rischi. Spesso questa fase è trascurata o monitorata in modo insufficiente.
- Flessibilità nella pianificazione:
Poiché le attività possono essere completate solo prima o dopo la data prevista, è necessaria una ripianificazione regolare delle attività successive. Questo garantisce una sincronizzazione precisa tra la data di fine di un’attività predecessore e la data di inizio di quella successiva. Questa esigenza ha ispirato il nome della nostra applicazione: Synchroboard™.
- Approcci iterativi:
Incrementare la frequenza delle revisioni e strutturare i progetti in modo da produrre risultati intermedi. Questo riduce l’impatto dei ritardi complessivi.
Conclusione
La Legge di Hofstadter ci ricorda che imprevisti e complessità sono elementi intrinseci di qualsiasi progetto. Piuttosto che cercare una pianificazione perfetta, è fondamentale adottare una gestione flessibile e proattiva, capace di rispondere meglio alle sfide impreviste e garantire risultati più prevedibili e sostenibili.
La legge 90-90: il primo 90% del progetto richiede il 90% del tempo e il restante 10% richiede anche il 90% del tempo.
La Legge 90-90, spesso citata in modo ironico nel campo dello sviluppo software e della gestione dei progetti, afferma:
“Il primo 90% di un progetto richiede il 90% del tempo previsto, e il restante 10% richiede anch’esso il 90% del tempo.”
Interpretazione e Ambito
Questa legge evidenzia un fenomeno ben noto nei progetti complessi: la sottostima degli sforzi richiesti nelle fasi finali del lavoro.
Dimostra come le attività finali, spesso percepite come secondarie o rapide, risultino invece molto più lunghe e complicate del previsto.
- Primo 90%: Di solito comprende le fasi iniziali, come la progettazione, lo sviluppo o l’esecuzione delle linee principali del progetto. Queste fasi sono spesso ben pianificate e rispettano in larga parte il cronoprogramma.
- Ultimo 10%: Riguarda gli aggiustamenti, le correzioni, i test, le validazioni e le rifiniture. Queste attività sono rallentate da imprevisti, cambiamenti dell’ultimo minuto o problemi non previsti.
Cause principali della Legge 90-90
- Sottostima delle rifiniture:
Dettagli come test, correzioni di bug e validazioni finali sono spesso sottovalutati in termini di tempo ed energia richiesti.
- Aumento della complessità:
Con il progredire del progetto, le interdipendenze e le difficoltà diventano più evidenti, rendendo gli ultimi aggiustamenti più complicati.
- Pressione crescente:
Gli ultimi 10% del progetto spesso coincidono con l’approssimarsi della scadenza, aumentando lo stress e la probabilità di errori.
Esempi di Applicazione
- Sviluppo software: Le fasi iniziali, come la scrittura del codice principale, avanzano rapidamente, ma i test finali, le correzioni dei bug e il rilascio richiedono molto più tempo del previsto.
- Edilizia: La struttura principale può essere completata nei tempi previsti, ma le rifiniture (verniciatura, impianti elettrici, decorazioni) spesso causano ritardi.
- Gestione dei progetti: Anche quando le tappe principali sono completate, gli aggiustamenti finali necessari a soddisfare tutte le parti interessate possono richiedere molto tempo.
Come contrastare la Legge 90-90?
- Pianificazione accurata:
Come per la Legge di Hofstadter, includere “supermercati” per ogni sottoprodotto del progetto e, alla fine, un “supermercato” per l’intero progetto. Questo tempo separa la fine dell’ultima attività dalla data effettiva di consegna. In Synchroboard, questo tempo viene chiamato “banca del tempo”, monitorata attraverso un indicatore specifico per garantire che non venga consumata più rapidamente di quanto avanza il progetto, simile al Burn-Down Chart della metodologia Agile.
- Anticipazione dei dettagli:
Prestare maggiore attenzione alla valutazione delle rifiniture e pianificare un tempo adeguato per test, correzioni e aggiustamenti.
- Iterazioni regolari:
Consegnare progressivamente parti del progetto per identificare e risolvere i problemi il prima possibile, evitando di accumularli verso la fine.
- Gestione proattiva dei rischi:
Identificare i punti critici che potrebbero ritardare le ultime fasi del progetto e predisporre azioni di mitigazione.
Conclusione
La Legge 90-90, pur essendo una rappresentazione umoristica, offre un promemoria realistico: nelle fasi finali di un progetto, i dettagli possono richiedere più tempo ed energia del previsto.
Un’efficace pianificazione e una corretta anticipazione degli imprevisti possono ridurre significativamente l’impatto di questo fenomeno, migliorando la gestione complessiva dei progetti.
Legge di Brooks: l’aggiunta di risorse umane a un progetto ritardato lo ritarderà ulteriormente.
La Legge di Brooks, formulata da Fred Brooks nel suo classico libro The Mythical Man-Month (1975), è un principio fondamentale nella gestione dei progetti, in particolare nello sviluppo software. Essa afferma:
“Aggiungere personale a un progetto in ritardo non fa altro che ritardarlo ulteriormente.”
Spiegazione
La Legge di Brooks evidenzia i limiti dell’aggiunta di risorse umane a un progetto in difficoltà.
Contrariamente alla convinzione comune che un lavoro possa sempre essere accelerato aggiungendo più persone, la realtà dimostra che ciò comporta spesso una perdita di produttività per diversi motivi:
- Tempo di integrazione:
I nuovi membri del team devono essere formati e aggiornati sullo stato del progetto, richiedendo tempo e risorse da parte dei membri già operativi.
- Aumento della complessità comunicativa:
Con l’aumento del numero di persone, gli sforzi di coordinamento crescono esponenzialmente, complicando la comunicazione e il processo decisionale.
- Attività indivisibili:
Alcuni aspetti di un progetto (come la progettazione o la risoluzione di problemi complessi) non possono essere suddivisi tra più persone.
Aggiungere risorse non apporta quindi alcun beneficio in questi casi.
Contesto e Applicazioni
- Sviluppo software:
Brooks osservò questa legge in progetti di grande scala, dove i ritardi peggioravano con l’aggiunta di sviluppatori a causa delle sfide legate alla coordinazione e all’integrazione.
- Gestione dei progetti in generale:
La legge si applica anche ad altri settori, dove l’inserimento di nuove risorse umane in un contesto disorganizzato o già in ritardo provoca ulteriore caos e inefficienza.
Esempio pratico
Immaginiamo un progetto in ritardo in cui 5 sviluppatori lavorano su un’applicazione complessa. Aggiungere 3 nuovi sviluppatori costringerà i primi 5 a:
- Formare i nuovi arrivati.
- Riorganizzare il lavoro e gestire le dipendenze.
Questo rallenterà il loro ritmo di lavoro, aggravando temporaneamente i ritardi invece di risolverli.
Come contrastare la Legge di Brooks?
- Pianificare meglio fin dall’inizio:
Anticipare le necessità di risorse umane e prevedere margini di sicurezza realistici.
È un principio fondamentale, eppure spesso questa valutazione viene trascurata o male eseguita.
- Modularizzare le attività:
Suddividere i progetti in sottosistemi indipendenti per consentire ai nuovi membri di contribuire senza interrompere l’intero flusso.
Questa modularità dovrebbe riflettere quella del prodotto oggetto del progetto, ormai un prerequisito per la competitività.
- Migliorare strumenti e processi:
Utilizzare strumenti di gestione che facilitino la collaborazione e riducano gli sforzi comunicativi.
In questo contesto, Synchroboard si distingue.
Il suo sistema visivo estremamente efficiente permette, in meno di un minuto, persino a una persona esterna al progetto di verificare se il progetto è gestito correttamente o meno.
- Rivedere la pianificazione:
In alcuni casi, è preferibile accettare un ritardo e riorganizzare il lavoro piuttosto che sovraccaricare il team.
Questo approccio è essenziale e parte integrante delle pratiche insegnate nell’ecosistema Synchroboard.
Conclusione
La Legge di Brooks ci ricorda che i progetti complessi non possono sempre essere accelerati semplicemente aumentando il personale.
Una pianificazione accurata, una struttura ben definita e processi efficaci sono fondamentali per evitare ritardi e inefficienze, garantendo così una gestione del progetto più fluida e produttiva.
Legge di Humphrey: gli utenti non sempre sanno cosa vogliono finché non se ne rendono conto.
La Legge di Humphrey, attribuita a Watts Humphrey, pioniere dell’ingegneria del software e creatore del Capability Maturity Model (CMM), afferma:
“Gli utenti non sanno cosa vogliono finché non lo vedono.”
Interpretazione
Questa legge evidenzia una sfida fondamentale nello sviluppo dei prodotti, in particolare nel settore software: i requisiti degli utenti sono spesso mal definiti o in continua evoluzione. Anche quando le esigenze iniziali sono espresse chiaramente, possono rivelarsi imprecise o inadatte a soddisfare i bisogni reali.
Cause principali della Legge di Humphrey
- Visione limitata degli utenti:
Senza una dimostrazione concreta, gli utenti possono avere difficoltà a immaginare come un prodotto o una soluzione risponderà alle loro necessità.
- Evoluzione delle aspettative:
Man mano che un progetto avanza, gli utenti acquisiscono una comprensione più chiara dei loro bisogni reali, spesso diversi da quelli iniziali.
- Complessità dei progetti:
I sistemi software, in particolare, sono spesso così complessi che le loro interazioni e funzionalità non possono essere completamente comprese prima dell’implementazione.
Implicazioni nella gestione dei progetti e nello sviluppo software
- Deriva dei requisiti:
I frequenti cambiamenti nelle esigenze degli utenti (noti anche come scope creep) possono causare ritardi, superamenti del budget e frustrazioni.
- Comunicazione insufficiente:
La legge sottolinea l’importanza di una comunicazione continua tra il team di sviluppo e gli utenti per ridurre i fraintendimenti.
- Necessità del prototipazione:
Giustifica l’uso di mockup, prototipi o versioni preliminari per consentire agli utenti di “vedere” e affinare le loro aspettative.
Approcci per gestire la Legge di Humphrey
- Metodologie Agile:
Approcci come Scrum o Kanban permettono di consegnare versioni incrementali del prodotto, raccogliendo feedback dagli utenti e adeguando rapidamente le funzionalità.
Tuttavia, questa strategia deve essere usata con attenzione: un approccio incrementale e iterativo non deve sostituire una vera esplorazione dei bisogni e delle loro priorità, cosa che il metodo Quality Function Deployment (QFD) fa in modo eccellente.
- Prototipazione rapida:
Creare mockup o prototipi funzionanti per permettere agli utenti di testare e affinare le loro aspettative sin dalle prime fasi del progetto.
- Workshop collaborativi:
Coinvolgere attivamente gli utenti durante le fasi di progettazione per ridurre la distanza tra i bisogni reali e quelli dichiarati.
- Test frequenti con gli utenti:
Organizzare sessioni di test con utenti reali durante tutto il progetto per convalidare le funzionalità in sviluppo.
Conclusione
La Legge di Humphrey ricorda con forza che i progetti devono essere flessibili e centrati sugli utenti.
Utilizzando metodologie appropriate e collaborando strettamente con le parti interessate, i team possono ridurre le incertezze e soddisfare i bisogni reali degli utenti, anche quando questi evolvono nel tempo.
Tuttavia, considerare l’evoluzione delle esigenze non deve in alcun modo prolungare la durata complessiva del progetto.
La legge della complessità: più un progetto è complesso, maggiori sono i potenziali punti di errore.
La Legge della Complessità, pur non essendo formalmente definita come una “legge” unica, si riferisce all’idea che la complessità di un sistema o di un progetto tenda a crescere nel tempo, spesso in modo esponenziale, man mano che vengono aggiunti nuovi elementi.
Una possibile formulazione di questa idea è:
“La complessità aumenta con la scala di un progetto o di un sistema, e ogni aggiunta rende la gestione e la comprensione più difficili.”
Origine e Contesto
Questa legge si basa su principi osservati in vari ambiti, tra cui:
- Gestione dei progetti: Ogni attività o dipendenza aggiunta aumenta la difficoltà di coordinazione.
- Sviluppo software: Ogni nuova riga di codice, funzionalità o correzione di bug può introdurre dipendenze e rischi imprevisti.
- Sistemi complessi in generale: Interazioni inattese emergono quando il sistema diventa più grande o sofisticato.
Principali Concetti Legati alla Legge della Complessità
- Crescita esponenziale della comunicazione:
Quando cresce la dimensione di un team o di un progetto, il numero di canali di comunicazione aumenta in modo esponenziale, secondo la formula , dove è il numero di membri. Ciò complica la coordinazione e aumenta il rischio di malintesi.
- “Debito tecnico”:
Nello sviluppo software, ogni modifica rapida o non pianificata può aggiungere complessità al sistema, richiedendo maggiori sforzi per la manutenzione o il miglioramento nel lungo periodo.
- Entropia organizzativa:
Nelle organizzazioni o nei progetti, l’introduzione di regole, processi o strumenti aggiuntivi può rendere il sistema più rigido, lento e difficile da gestire.
- Legge dei rendimenti decrescenti:
Aggiungendo elementi per risolvere un problema o migliorare un sistema, i benefici ottenuti diventano sempre meno significativi rispetto allo sforzo aggiuntivo richiesto.
Implicazioni della Legge della Complessità nella Gestione dei Progetti
- Difficoltà di coordinazione:
Più un progetto è grande e complesso, più diventa difficile allineare gli sforzi delle diverse parti interessate.
- Rischio maggiore di errori:
Con l’aumento delle interdipendenze, un errore minore può avere conseguenze sproporzionate sull’intero progetto.
- Aumento di tempi e costi:
La complessità aggiunge ulteriori livelli di lavoro (pianificazione, comunicazione, correzione), impattando negativamente sulle scadenze e sui budget.
Come Gestire la Complessità?
- Semplificazione proattiva:
- Suddividere progetti o sistemi in moduli indipendenti.
- Ridurre le dipendenze tra le attività.
- Prioritizzazione delle attività essenziali:
Concentrarsi sugli elementi ad alto valore aggiunto ed evitare aggiunte inutili che aumentano la complessità senza benefici chiari.
Questo punto è cruciale nei pannelli utilizzati nell’applicazione Synchroboard™, dove solo le attività che coinvolgono due o più parti interessate (generalmente settori o funzioni) vengono gestite. Le attività interne a ogni funzione sono gestite localmente per non disperdere l’attenzione del project manager e delle parti coinvolte sugli obiettivi chiave del progetto.
- Automazione e strumenti adeguati:
Utilizzare strumenti di gestione per semplificare i processi e migliorare la comunicazione.
- Metodologie Agile:
Adottare approcci flessibili come Scrum, che promuovono cicli brevi e frequenti aggiustamenti, riducendo i rischi legati all’accumulo di complessità.
- Documentazione rigorosa:
Mantenere una documentazione chiara e aggiornata per favorire una migliore comprensione e gestione di sistemi complessi.
Conclusione
La Legge della Complessità ricorda che qualsiasi sistema o progetto, se non viene attivamente semplificato, tende a diventare sempre più difficile da comprendere e gestire.
Integrando pratiche adeguate e mantenendo un equilibrio tra innovazione e stabilità, è possibile limitare gli effetti negativi della complessità crescente.
Legge di Maier: Se il problema non è ben definito, anche la soluzione sarà problematica.
La Legge di Maier, formulata dall’ingegnere e specialista di sistemi Robert Maier, è un principio spesso citato nell’ingegneria dei sistemi e nella gestione dei progetti. Essa afferma:
“Se il problema non è chiaramente definito, la migliore soluzione non può essere identificata.”
Interpretazione
La Legge di Maier sottolinea un aspetto fondamentale della risoluzione dei problemi: l’importanza cruciale di una comprensione chiara e precisa del problema prima di cercare soluzioni.
Un problema mal definito porta a soluzioni inefficaci o inadeguate, spesso costose in termini di tempo e risorse.
Cause Frequenti di Problemi Mal Definiti
- Mancanza di chiarezza negli obiettivi:
Le parti interessate non concordano su ciò che vogliono ottenere.
- Comprensione errata:
I bisogni degli utenti o dei clienti non sono ben compresi o espressi.
- Complessità o ambiguità del problema:
Gli aspetti critici del problema vengono oscurati da dettagli secondari o mal prioritizzati.
- Ipotesi implicite:
Le parti interessate o i team suppongono di conoscere il problema senza averlo analizzato esplicitamente.
Applicazione nella Gestione dei Progetti
- Importanza della definizione dei requisiti:
Un problema mal definito può portare a specifiche poco chiare, rendendo difficile misurare il successo o il fallimento del progetto.
- Impatto su tempi e budget:
I progetti spesso iniziano con un’idea vaga degli obiettivi, il che porta a costosi aggiustamenti in corso d’opera.
Sebbene si dica che non bisogna aspettare di avere tutto chiaro per iniziare, si rischia di cadere nell’eccesso opposto, dove il tempo per correggere supera quello necessario per chiarire meglio in partenza.
Come recita un altro adagio: “Affrettati lentamente.”
- Deriva dei requisiti (scope creep):
La mancanza di chiarezza iniziale favorisce l’aggiunta progressiva di nuove richieste, complicando la gestione di risorse e tempi.
A questo proposito, il processo di esplorazione dei bisogni della metodologia Quality Function Deployment (Blitz QFD) è estremamente efficace.
Come Applicare la Legge di Maier?
- Analisi approfondita del problema:
- Utilizzare l’approccio esplorativo come il Blitz QFD.
- Applicare strumenti come il diagramma di Ishikawa (diagramma causa-effetto) per identificare le cause profonde.
- Organizzare workshop collaborativi con le parti interessate per chiarire bisogni e aspettative.
- Definire obiettivi SMART:
Gli obiettivi devono essere:
- Specifici
- Misurabili
- Raggiungibili
- Rilevanti
- Definiti temporalmente
- Formalizzare i requisiti:
Documentare le specifiche in modo chiaro e dettagliato per evitare fraintendimenti.
- Prototipazione rapida:
Creare un prototipo o un mockup per validare la comprensione del problema da parte degli utenti e delle parti interessate.
- Comunicazione attiva:
Implementare un processo di feedback regolare per affinare la definizione del problema e garantire l’allineamento tra tutti gli attori.
In Synchroboard™, questo passaggio rientra nel concetto di “tripla chiave”, un punto di controllo (gate) in cui si verifica, tra le altre cose, che le specifiche siano corrette e che il cliente non le stia riconsiderando o modificando.
Esempio Pratico
Nello sviluppo di un software per la gestione dell’inventario, se il problema viene definito semplicemente come:
“Abbiamo bisogno di un sistema per gestire i nostri magazzini”,
potrebbe portare a soluzioni inadeguate.
Approfondendo, si scopre che il vero problema è:
“Abbiamo bisogno di ridurre gli errori umani nell’inserimento manuale e migliorare il monitoraggio dei prodotti in tempo reale.”
Questa definizione precisa guida la creazione di una soluzione adeguata.
Conclusione
La Legge di Maier ricorda che il tempo dedicato a definire chiaramente un problema è un investimento cruciale per garantire il successo di un progetto.
Un’analisi chiara e dettagliata dei bisogni, combinata con una comunicazione efficace, è la chiave per identificare soluzioni che rispondano realmente alle aspettative delle parti interessate e alle esigenze del contesto.
Legge di Peters: i team di progetto finiscono sempre per produrre ciò che è più facile da dimostrare, non necessariamente ciò che è più utile.
“Un team di progetto finisce sempre per fare ciò che è più facile da dimostrare, e non ciò che è più importante.”
Interpretazione
Questa legge evidenzia una tendenza comune nella gestione dei progetti:
i team tendono a dare priorità alle attività o ai risultati più visibili e misurabili, a scapito di quelli essenziali ma meno tangibili o difficili da quantificare.
Questo può portare a progetti in cui gli obiettivi strategici vengono trascurati a favore di deliverable secondari o simbolici.
Perché accade questa tendenza?
- Pressione per mostrare progressi visibili:
Stakeholder e management richiedono spesso prove concrete di avanzamento, spingendo i team a concentrarsi su attività dimostrabili.
- Facilità di esecuzione:
I membri del team preferiscono affrontare compiti semplici o tecnicamente accessibili, lasciando da parte elementi complessi o strategici.
- Scarsa definizione delle priorità:
In assenza di priorità chiare, i team possono focalizzarsi su attività che sembrano più gratificanti nel breve termine.
- Mancanza di visione strategica:
Quando gli obiettivi globali non sono ben compresi, i team si concentrano su ciò che è facile da quantificare.
Implicazioni nella Gestione dei Progetti
- Deviazione dagli obiettivi strategici:
Il progetto rischia di produrre deliverable conformi in apparenza, ma che non rispondono ai bisogni reali o critici.
- Perdita di tempo e risorse:
Gli sforzi si concentrano su attività secondarie invece di focalizzarsi sugli aspetti chiave.
- Frustrazione degli stakeholder:
Se i risultati finali non rispecchiano le aspettative strategiche, possono emergere conflitti o insoddisfazioni.
Come contrastare gli effetti della Legge di Peters?
- Definire chiaramente le priorità:
- Devono essere priorità di progetto, non individuali.
- Stabilire traguardi basati su criteri d’impatto, non solo di visibilità.
- Promuovere una visione a lungo termine:
- Formare i team a ragionare in termini di obiettivi globali e impatti.
- Sottolineare il valore strategico delle attività, anche se meno visibili.
- Monitorare gli indicatori chiave:
- Introdurre KPI (Key Performance Indicators) pertinenti che misurino i risultati importanti, non solo le fasi intermedie.
- Una dashboard di progetto deve includere indicatori di processo e indicatori di risultato, rispettando il principio: “Il processo seguito conduce ai risultati che ne derivano.”
- Coinvolgere gli stakeholder:
- Mantenere una comunicazione regolare per ricordare le priorità e allineare le aspettative.
- Incoraggiare una cultura del feedback:
- Organizzare revisioni periodiche per valutare se gli sforzi attuali contribuiscono davvero agli obiettivi globali.
Esempio Pratico
In un progetto di sviluppo software, il team potrebbe concentrarsi sulla progettazione di un’interfaccia utente accattivante (facile da mostrare durante le presentazioni) invece di ottimizzare il sistema backend, che è più complesso ma essenziale per le prestazioni complessive del prodotto.
Conclusione
La Legge di Peters è un prezioso promemoria per i project manager: non basta mostrare risultati visibili.
Gli sforzi devono essere allineati a ciò che è realmente importante per il successo globale del progetto.
Una gestione proattiva, una chiara definizione delle priorità e una visione strategica sono essenziali per contrastare questa tendenza naturale.
Legge di Kidder: Le cose che vengono misurate migliorano. Le cose che vengono ignorate si deteriorano.
La Legge di Kidder, attribuita a Tracy Kidder, scrittore e autore del libro The Soul of a New Machine (1981), afferma:
“Le persone che non hanno il tempo di fare bene le cose fin dall’inizio troveranno sempre il tempo per rifarle.”
Interpretazione
La Legge di Kidder sottolinea l’importanza di dedicare il tempo necessario a fare bene le cose fin dall’inizio, soprattutto in progetti complessi come lo sviluppo software, la gestione dei progetti o l’ingegneria.
Evidenzia un fenomeno comune: un approccio affrettato nelle fasi iniziali spesso porta a errori costosi, che richiedono correzioni successive, con conseguenti ritardi e sforamenti del budget.
Implicazioni nella Gestione dei Progetti
- Costo degli errori iniziali:
Un lavoro mal fatto all’inizio genera problemi che diventano sempre più costosi da correggere man mano che il progetto avanza.
Ad esempio, un errore di progettazione non rilevato potrebbe richiedere una riprogettazione completa in una fase avanzata.
- Perdita di tempo:
Sebbene si pensi di risparmiare tempo avanzando rapidamente, i ritorni indietro e le correzioni richiedono spesso molto più tempo rispetto a quanto si sarebbe impiegato facendo le cose bene fin dall’inizio.
- Impatto sulla qualità:
I prodotti o i deliverable sottoposti a numerose correzioni rischiano di essere di qualità inferiore, poiché gli aggiustamenti successivi possono introdurre incoerenze o compromessi.
Esempi Pratici
- Sviluppo software:
Se si salta la fase dei test iniziali per risparmiare tempo, i bug non rilevati potrebbero emergere in produzione, richiedendo correzioni urgenti e costose.
- Costruzioni:
Una stima errata dei materiali o una preparazione trascurata potrebbe causare ritardi significativi e costi aggiuntivi.
Come Evitare gli Effetti della Legge di Kidder
- Pianificazione accurata:
- Investire tempo nella pianificazione iniziale per identificare requisiti, rischi e tappe fondamentali.
- Stabilire step intermedi per evitare la fretta eccessiva.
- Definire standard di qualità:
- Creare criteri di qualità chiari per superare le varie fasi del progetto.
- Assicurarsi che ogni fase rispetti questi standard prima di procedere alla successiva.
- Adottare metodologie iterative:
- Utilizzare approcci come Agile, che consentono di sviluppare incrementi successivi integrando feedback regolari per evitare grandi ritorni indietro.
- Nell’ecosistema Synchroboard, questo avviene durante la fase di strutturazione del progetto, che deriva dal piano di mitigazione dei rischi.
- Investire nelle fasi critiche:
- Prestare particolare attenzione alle prime fasi del progetto (ricerca, progettazione, test iniziali) per costruire basi solide.
- Formare i team:
- Assicurarsi che tutti i membri del team comprendano l’importanza di fare bene le cose fin dall’inizio e dispongano delle competenze necessarie.
- Ricordare il detto: “Un lavoro mal fatto all’inizio costa da 7 a 13 volte di più in termini di tempo o risorse per correggerlo”, per modificare i comportamenti.
Conclusione
La Legge di Kidder ci ricorda che la fretta nelle fasi iniziali di un progetto può avere conseguenze costose.
Prendersi il tempo per pianificare, eseguire e validare accuratamente fin dall’inizio è un investimento che consente di risparmiare risorse, migliorare la qualità e garantire il successo complessivo del progetto.
Legge di Cohn: le decisioni più importanti sono spesso prese sulla base di informazioni incomplete.
La Legge di Cohn, formulata da Mike Cohn, esperto nello sviluppo Agile e autore di diversi libri sull’argomento, afferma:
“Più è difficile cambiare un aspetto di un sistema, più è importante definirlo correttamente fin dall’inizio.”
Interpretazione della Legge di Cohn
La Legge di Cohn evidenzia l’importanza di dare priorità agli aspetti critici di un progetto o di un sistema, specialmente quelli che saranno difficili, costosi o impossibili da modificare in futuro.
Sottolinea che alcune scelte, come le fondamenta di un’architettura software o i principi di base di un prodotto, richiedono particolare attenzione fin dalle prime fasi di progettazione.
Implicazioni nella Gestione dei Progetti
- Le decisioni strutturali hanno un impatto duraturo:
Le scelte iniziali di un progetto, come la tecnologia o la modularità, influenzano significativamente il percorso futuro.
Se queste decisioni sono sbagliate, le correzioni possono essere molto costose e complesse.
- Importanza dell’analisi iniziale:
Gli aspetti difficili da cambiare, come le dipendenze critiche, le norme di qualità o gli obiettivi strategici, devono essere analizzati attentamente prima di avviare il progetto.
- Flessibilità negli aspetti secondari:
Gli elementi facilmente modificabili, come l’interfaccia utente o funzionalità non critiche, possono essere decisi in un secondo momento o adattati a costi ridotti.
Esempi Pratici
Sviluppo software:
Se un sistema software viene progettato senza considerare la scalabilità (la capacità di gestire un aumento del carico), correggere questo errore quando il sistema è in produzione sarà estremamente costoso. La scalabilità, essendo difficile da modificare, deve essere pianificata fin dall’inizio.
Costruzioni:
Nella costruzione di un edificio, le fondamenta devono essere progettate con precisione perché sono quasi impossibili da modificare una volta realizzate, a differenza degli elementi decorativi o delle pareti interne.
Come Applicare la Legge di Cohn?
- Identificare gli elementi critici:
- Eseguire un’analisi approfondita per individuare gli aspetti che saranno costosi o complessi da modificare (es. architettura, infrastruttura, obiettivi strategici).
- Dare priorità alle decisioni fondamentali:
- Investire più tempo e risorse per definire chiaramente gli aspetti chiave all’inizio del progetto.
- Lasciare maggiore flessibilità agli elementi secondari o facilmente modificabili.
- Anticipare i cambiamenti possibili:
- Utilizzare modelli o architetture flessibili (es. modularità nello sviluppo software o nella progettazione) per ridurre al minimo gli impatti delle modifiche future.
- Validare le scelte critiche:
- Creare prototipi o effettuare validazioni preliminari per garantire che le scelte iniziali siano in linea con gli obiettivi.
Conclusione
La Legge di Cohn ricorda che non tutte le decisioni di un progetto hanno la stessa importanza o le stesse conseguenze.
Identificando e dando priorità alle scelte fondamentali, i team di progetto possono ridurre i rischi, evitare costi inutili e stabilire solide basi per il successo a lungo termine.
Legge di Weinberg: un team lavorerà entro il suo livello di tolleranza al fallimento
La Legge di Weinberg, formulata da Gerald Weinberg, esperto di gestione dei progetti e sviluppo software, afferma:
“Se gli sviluppatori hanno la sensazione che i loro dati saranno usati per punirli, falsificheranno i dati.”
Interpretazione della Legge
La Legge di Weinberg mette in evidenza un problema comune negli ambienti di lavoro in cui la performance delle squadre o dei singoli individui viene misurata in modo rigido e punitivo.
Quando i dipendenti percepiscono valutazioni o indicatori come una minaccia, possono manipolare dati o rapporti per evitare conseguenze negative, invece di segnalare onestamente difficoltà o problemi incontrati.
Implicazioni nella Gestione dei Progetti
- Metriche distorte:
Rapporti e indicatori di performance diventano poco affidabili, poiché i dipendenti cercano di “proteggersi” invece di riflettere la realtà.
- Perdita di trasparenza:
Una cultura punitiva incoraggia la dissimulazione dei problemi, ritardandone l’identificazione e la risoluzione.
- Impatto sulla collaborazione:
Un’atmosfera di sfiducia ostacola la comunicazione aperta tra i membri del team e può isolare gli individui.
- Fallimento dei progetti:
Quando le decisioni di gestione si basano su dati inesatti o falsificati, i progetti rischiano di deviare dagli obiettivi o di fallire.
Esempio Pratico
In un team di sviluppo prodotto, se un project manager insiste su scadenze rigide minacciando sanzioni in caso di ritardi, i membri del team potrebbero riportare progressi esagerati o incompleti, nascondendo problemi tecnici o bug.
Questi problemi, non rilevati in tempo, possono causare ritardi maggiori o portare a un prodotto di qualità inferiore.
Come Evitare gli Effetti della Legge di Weinberg?
- Creare le condizioni per sviluppare l’intelligenza emotiva anziché il management repressivo:
- Incoraggiare una comunicazione aperta in cui i membri del team si sentano sicuri di segnalare problemi o ritardi senza temere ritorsioni.
- Valorizzare gli apprendimenti derivati dagli errori invece di punirli. Si impara di più dagli errori che dai successi.
- Utilizzare le metriche come strumento di miglioramento:
- Presentare gli indicatori di performance come un mezzo per diagnosticare e migliorare i processi, non come un’arma per giudicare o sanzionare.
- Favorire la trasparenza:
- Coinvolgere i team nella definizione delle metriche di performance, assicurandosi che siano pertinenti e comprese da tutti.
- Fornire feedback costruttivi basati sui dati, senza accuse né critiche.
- Adottare pratiche agili:
- Organizzare retrospettive regolari per discutere apertamente le sfide incontrate e i modi per migliorare.
- Promuovere un approccio incrementale, in cui i problemi vengano identificati e risolti presto nel ciclo di sviluppo.
- Responsabilizzare senza minacce:
- Concentrarsi sulla responsabilità collettiva del team piuttosto che sulle performance individuali.
Conclusione
La Legge di Weinberg ricorda che un approccio punitivo nell’uso dei dati può compromettere la trasparenza e l’affidabilità delle informazioni cruciali per il successo di un progetto.
Promuovendo una cultura di fiducia, apprendimento e collaborazione, si incoraggiano comportamenti onesti e proattivi, essenziali per il successo dei progetti.
Questo approccio è al centro dell’ecosistema Synchroboard™, che favorisce lo sviluppo dell’intelligenza collettiva come la migliore forma di performance operativa.
Perché si assegna sistematicamente più tempo del necessario ai compiti?
ABSTRACT:
L’assegnazione di tempo extra per gestire gli imprevisti, basata sulla legge di Parkinson, si rivela inefficace: non risolve le cause profonde, genera sprechi, allunga i tempi e compromette le opportunità.
Gli imprevisti non sono sempre imprevedibili, ma spesso derivano da una mancata rilevazione o gestione tempestiva.
Errori personali, modifiche in corso, mancanza di competenze e carenze di informazioni sono tra le cause più comuni.
Aggiungere tempo non garantisce il successo dei progetti.
Un approccio efficace richiede una gestione proattiva, con identificazione precoce dei rischi, reazione rapida e collaborazione del team.
Questo consente di ottimizzare i processi, ridurre le deviazioni e migliorare la resilienza, trasformando le incertezze in opportunità per raggiungere gli obiettivi.
Perché si assegna sistematicamente più tempo del necessario ai compiti?
«Un compito si espande sempre per occupare tutto il tempo disponibile. »
È l’insegnamento della legge di Parkinson nella gestione dei progetti.
Questa legge è facile da comprendere, così come le sue conseguenze.
Ma perché si assegna sistematicamente più tempo del necessario per completare un compito? E ciò aumenta davvero le probabilità di rispettare le scadenze?
Il tempo extra assegnato funge da riserva o cauzione per proteggersi da vari tipi di incognite.
Ha lo scopo di limitare:
- La paura 😨 e lo stress 😟 che l’incertezza genera nella nostra mente,
- L’impatto negativo 👀 del giudizio altrui (colleghi, superiori) sul nostro lavoro.
Il ragionamento è quindi semplice:
Più ci sono elementi sconosciuti, più bisogna proteggersi. 🔍
Gli elementi sconosciuti sono tutti imprevedibili? 🤔
Gli elementi imprevedibili sono quelli su cui non possiamo agire 🔒.
Tutti gli altri sono potenzialmente prevedibili, ma emergono perché non siamo riusciti a rilevarli in tempo. ⏱️
A quel punto, li chiamiamo imprevisti 🔄
Quali sono gli imprevisti più frequenti? 🤔
La lista è ampia. Nel contesto della gestione dei progetti, gli imprevisti più significativi e ricorrenti includono:
- Dover consumare più tempo a causa di:
- Errori personali ❌,
- Indicazioni errate 📋,
- Modifiche durante il progetto 🔄,
- Mancanza di competenze 🧠,
- Assegnazione di compiti extra non previsti ➕,
- Attese di informazioni 📩.
- Affrontare carenze di informazioni riguardo al compito da svolgere, in particolare:
- La sua durata effettiva ⏱️ (tempo di ciclo nominale),
- L’estensione del tempo necessario 🗓️ (lead time), cioè il tempo complessivo richiesto per completare l’attività.
Questo approccio aumenta la probabilità di completare il progetto nelle tempistiche previste? 🤔
Sebbene sia comune nella gestione dei progetti, i fatti parlano chiaro:
- 2 progetti su 3 non raggiungono tutti i loro obiettivi 🎯,
- 1 progetto su 2 ne raggiunge solo una parte 📉.
- Se funzionasse davvero, non avremmo bisogno di discuterne.
Possiamo quindi almeno affermare che aumentare il tempo delle attività: Non garantisce da solo il successo dei progetti 🛑.
In realtà, non lo farà mai 🚫
Perché questo approccio non permetterà di rispettare le scadenze? 🤔
Aggiungere tempo extra mira a compensare gli imprevisti, ma non affronta le loro cause profonde. Ci si limita a ridurne le conseguenze, lasciando il progetto vulnerabile al loro impatto perturbante.
Conseguenze dirette di questo approccio:
- Un effetto a cascata 🔄: se gli imprevisti consumano più tempo di quello assegnato, le attività successive vengono inevitabilmente ritardate.
- Un allungamento globale 🕒: il progetto richiede più tempo per essere completato.
Una domanda chiave: cosa accade al tempo extra se un’attività termina prima della data prevista?
La legge di Parkinson risponde chiaramente: Questo tempo “extra” non esiste realmente, poiché viene sistematicamente assorbito dall’allungamento delle attività per occupare tutto il tempo disponibile, anche in assenza di imprevisti.
Conclusione: Questo approccio crea un’illusione di sicurezza, ma:
- Non consente di anticipare efficacemente gli imprevisti,
- Allunga inutilmente i tempi,
- Non ottimizza il tempo disponibile.
Conseguenze dirette di questo approccio:
- Uno spreco di tempo 🕒 allocato inutilmente per attività che avrebbero potuto essere concluse prima.
- Un’opportunità mancata 🚀 di avviare le attività successive più velocemente.
- L’impossibilità di compensare i ritardi ⏳ con progressi realizzati altrove.
Non ci sono più dubbi:
«Aggiungere tempo in modo sistematico non garantisce il raggiungimento degli obiettivi di un progetto, in particolare il rispetto delle scadenze.» ❌
Un’alternativa si delinea:
«Cambiare il punto di vista con cui si concepisce e si affronta l’incertezza » potrebbe essere la chiave per gestire meglio gli imprevisti e aumentare le probabilità di successo.
Le 10 convinzioni fondamentali per massimizzare il successo nella gestione dei progetti 🚀
- «La paura non elimina il pericolo.» ⚠️
- Affrontare il pericolo consente di dominarlo, invece di cercare di evitarlo.
- «Un pericolo è un rischio non documentato.» 📋
- Documentare un rischio permette di classificarlo tra gli elementi conosciuti.
- Possono quindi essere stabilite azioni concrete per gestirlo, rendendolo quantificabile e controllabile.
- «Non tutti gli elementi sconosciuti sono imprevedibili. » 🔍
- Gli imprevisti rientrano nel nostro cerchio di influenza e azione.
- Gli imprevedibili, invece, appartengono al cerchio delle preoccupazioni e possono distrarci o paralizzare le nostre capacità.
- «I risultati dipendono dalla qualità del processo che li genera. » 🔧
- Identificare le aree di rischio fin dall’inizio e pianificarne la loro mitigazione.
- Certificare i lavori per limitare le sorprese.
- Ridurre i tempi morti tra le attività.
- Evitare deviazioni e correggere rapidamente le cause profonde.
- «Inizia quando vuoi, ma finisci prima della data prevista. » 🕒
- Questo incoraggia la libertà di intraprendere, rafforzando però la responsabilità sugli impegni.
- «Se un ritardo è inevitabile, informa rapidamente le persone interessate. » 📣
- La solidarietà di squadra richiede una comunicazione rapida e trasparente.
- Evitare rancori o regolamenti di conti, mettendo il progetto al centro delle priorità.
- «Il tempo appartiene al progetto, non agli individui.» ⏱️
- Considerare il tempo come una risorsa da ottimizzare, non come un budget da consumare.
- «La necessità di utilizzare il 100% del tempo assegnato è statisticamente improbabile.» 📊
- L’obiettivo dovrebbe essere quello di completare un compito consumando meno tempo del previsto.
- «La performance globale non si ottiene dalla somma delle performance individuali.» 🤝
- L’intelligenza collettiva è la leva principale della performance operativa.
- Un approccio manageriale chiaro rafforza l’impegno del team per raggiungere obiettivi comuni.
- «Aggiungere tempo extra non garantisce il successo del progetto.» 🚫
- È dimostrato che questa pratica è spesso controproducente.
In sintesi, per massimizzare il successo di un progetto garantendo il benessere delle persone coinvolte, è fondamentale:
- Identificare con precisione gli imprevisti 🔍 per affrontarli fin dalla loro comparsa, evitando comportamenti inappropriati o reazioni sproporzionate.
- Reagire rapidamente ⚡ agli imprevisti residui e alle deviazioni, per limitarne l’impatto prima che si amplifichino e danneggino gravemente il progetto.
- Incoraggiare l’interattività e la collaborazione 🤝, per sviluppare un’intelligenza collettiva capace di rispondere efficacemente alle sfide.
- Imparare dai fallimenti passati 📚 integrandoli nel processo di gestione, per evitare di ripetere gli stessi errori e rafforzare la resilienza del progetto.
Legge di Murphy: Tutto ciò che può andare storto, andrà storto
Anche se spesso viene vista come una battuta umoristica o pessimistica, questa legge riflette una realtà importante in molti ambiti, soprattutto nella gestione dei progetti.
Per esperienza personale, ho elaborato una variante ancora più realistica:
“Tutto ciò che può andare storto, andrà storto e nel peggior momento possibile!”
Origine della legge di Murphy
La legge prende il nome da Edward A. Murphy Jr., un ingegnere aeronautico statunitense che lavorava negli anni ’40 a test di tolleranza umana alla gravità.
Durante un esperimento fallito a causa di un dispositivo installato in modo errato, Murphy avrebbe dichiarato: “Se qualcuno può commettere un errore, lo farà.”
Da allora, l’espressione è stata abbreviata nella sua forma attuale.
Esempi concreti della legge nella gestione dei progetti
- Ritardi nelle consegne: Se un fornitore può essere in ritardo, è molto probabile che lo sarà, e nel momento peggiore.
- Bug software: Una nuova versione, anche meticolosamente preparata, potrebbe causare malfunzionamenti inattesi proprio nel momento critico.
- Malintesi con gli stakeholder: Se una comunicazione può essere fraintesa, probabilmente lo sarà, e sempre nei momenti meno opportuni.
Come contrastare la legge di Murphy?
Un noto corollario a questa legge ci fornisce una pista per la soluzione: “Il diavolo si nasconde nei dettagli.”
Questa espressione, molto comune, sottolinea che sono spesso le piccole particolarità, trascurate o mal gestite, a generare problemi o complicazioni impreviste, lasciando così spazio alla legge di Murphy.
3 raccomandazioni per contrastare la legge di Murphy
- Cura della preparazione del progetto:
Effettuare un’analisi dei rischi, prendendo in considerazione qualità, costi, tempi e prestazioni della soluzione proposta.
- Suddivisione del prodotto:
Scomporre il prodotto da progettare o realizzare in elementi/moduli verificabili singolarmente, evitando di dover attendere le fasi finali, come l’esecuzione o l’installazione presso il cliente, per scoprire eventuali errori.
- Analisi delle cause radice:
Quando la legge di Murphy si manifesta, analizzare attentamente le cause principali del problema, trovare contromisure e correggere eventuali carenze nei processi o nei comportamenti.
Seguendo queste raccomandazioni, è possibile minimizzare l’impatto della legge di Murphy e migliorare significativamente la gestione dei progetti.
Legge di Parkinson: Un lavoro è sempre distribuito per occupare tutto il tempo disponibile.
La legge di Parkinson, formulata da Cyril Northcote Parkinson nel 1955, afferma che: “Il lavoro si espande fino a occupare tutto il tempo disponibile per completarlo.”
In altre parole, più tempo si ha a disposizione per svolgere un compito, più si tende a usarlo, spesso a scapito dell’efficienza.
Applicazione della legge di Parkinson nella gestione dei progetti
- Diluzione degli sforzi:
Nella gestione dei progetti, la legge di Parkinson spiega perché i team rallentano il loro ritmo quando viene concesso un tempo generoso.
Gli sforzi si adattano ai tempi disponibili, estendendo inutilmente la durata necessaria per completare attività semplici.
Esempio:
Se un’attività stimata in 3 giorni viene pianificata su una settimana, è probabile che richieda effettivamente una settimana, poiché il team modulerà i suoi sforzi in base al tempo a disposizione.
- Procrastinazione e inefficienza:
Quando i membri di un team sanno di avere molto tempo per completare un’attività, potrebbero ritardarne l’inizio o concentrarsi su aspetti non prioritari, riducendo così l’efficienza.
- Rischio di aggiunte non necessarie:
Con più tempo a disposizione, i team potrebbero includere funzionalità o dettagli superflui, non essenziali, che complicano inutilmente il progetto.
Conseguenze nella gestione dei progetti:
- Rischio di sforamento dei tempi: Anche con un calendario ben definito, le attività possono dilatarsi, impattando negativamente sulle scadenze del progetto.
- Costi aggiuntivi: Più tempo richiede un’attività, più risorse vengono mobilitate, aumentando le spese.
- Perdita di produttività: La diluizione del lavoro crea una percezione di inefficienza nel team.
Come contrastare la legge di Parkinson?
- Definire scadenze realistiche ma strette:
Dare il tempo giusto per completare un’attività spinge i team a concentrarsi e a lavorare in modo efficace.
- Utilizzare tappe intermedie:
Suddividere un progetto in fasi con scadenze chiare per mantenere un ritmo costante.
- Adottare approcci agili:
Cicli brevi e deliverable frequenti (come nella metodologia Agile) limitano la tendenza a diluire il lavoro su periodi lunghi.
- Promuovere la responsabilizzazione:
Introdurre un monitoraggio regolare e una comunicazione trasparente per assicurarsi che i team restino allineati sugli obiettivi.
- Cambiare il significato della durata di un’attività:
La durata dipende da vari fattori (focalizzazione, multitasking, esperienza, livello di performance atteso), ma ciò che conta è minimizzare il tempo consumato.
È improbabile che il tempo stimato corrisponda esattamente a quello necessario. Di conseguenza, ci sono due scenari possibili:
- L’attività viene completata prima della scadenza.
- L’attività viene completata dopo la scadenza.
Per questo motivo, Synchroboard™ ha eliminato il colore “verde” per indicare che un’attività è completata, perché non riflette questa realtà. Il tempo assegnato a un’attività non è un budget da consumare interamente: appartiene al progetto, non alla persona che lo esegue.
Conclusione
La gestione del tempo in un progetto non deve essere considerata come una semplice allocazione da consumare, ma come una risorsa preziosa da ottimizzare per raggiungere gli obiettivi globali.
Adottando un approccio realistico e flessibile, come quello proposto da Synchroboard™, è possibile ridurre le discrepanze nelle stime e guidare i team verso una gestione più efficace e focalizzata sulle priorità.
Questa visione sottolinea che ogni attività deve servire il progetto, non il contrario, per garantire un reale miglioramento delle prestazioni e dell’efficienza.
Legge di Hofstadter: tutto richiede sempre più tempo del previsto, anche tenendo conto della legge di Hofstadter.
“Ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della Legge di Hofstadter.”
Questa legge evidenzia una verità universale: i progetti, sia personali che professionali, richiedono spesso più tempo del previsto, anche quando si cerca di anticipare possibili ritardi.
Origine e Contesto
Douglas Hofstadter ha formulato questa legge nell’ambito della risoluzione di problemi complessi, come la creazione di intelligenze artificiali o algoritmi. Tuttavia, la sua applicazione si estende ben oltre, risultando rilevante in molti contesti dove la pianificazione è fondamentale.
Cause principali dietro la Legge di Hofstadter
- Sottostima sistematica delle attività:
Le persone tendono a essere troppo ottimiste riguardo alla propria capacità di completare i compiti, trascurando dettagli e imprevisti.
- Complessità dei progetti:
Anche i progetti apparentemente semplici possono nascondere dipendenze o problemi inattesi.
- Effetto di auto-riferimento:
La legge stessa sottolinea che cercare di compensare i ritardi regolando le previsioni non è sufficiente, poiché continueranno a emergere imprevisti.
Implicazioni nella gestione dei progetti
La Legge di Hofstadter ha conseguenze significative sulla pianificazione dei progetti, tra cui:
- Sforamento delle tempistiche: I ritardi diventano quasi inevitabili, anche con una pianificazione attenta.
- Effetto domino: Ritardi in attività critiche possono avere ripercussioni su tutto il progetto.
- Frustrazione delle parti interessate: La difficoltà nel rispettare le scadenze può compromettere la fiducia di clienti o stakeholder.
Come attenuare gli effetti della Legge di Hofstadter?
- Aggiunta di margini di sicurezza:
Non su ogni singola attività, ma su un gruppo di attività correlate che portano a un sottoprodotto del progetto.
Inserire buffer temporali per affrontare gli imprevisti, ispirandosi al concetto di “supermercato” del sistema di produzione just-in-time (JIT).
- Scomposizione delle attività:
Suddividere un progetto in piccoli passi per valutare meglio il tempo necessario per ciascuno. Questo aumenta la precisione nelle previsioni e nell’assegnazione delle risorse.
- Analisi dei rischi:
Identificare le attività critiche e le dipendenze che potrebbero causare ritardi e definire azioni per mitigare i rischi. Spesso questa fase è trascurata o monitorata in modo insufficiente.
- Flessibilità nella pianificazione:
Poiché le attività possono essere completate solo prima o dopo la data prevista, è necessaria una ripianificazione regolare delle attività successive. Questo garantisce una sincronizzazione precisa tra la data di fine di un’attività predecessore e la data di inizio di quella successiva. Questa esigenza ha ispirato il nome della nostra applicazione: Synchroboard™.
- Approcci iterativi:
Incrementare la frequenza delle revisioni e strutturare i progetti in modo da produrre risultati intermedi. Questo riduce l’impatto dei ritardi complessivi.
Conclusione
La Legge di Hofstadter ci ricorda che imprevisti e complessità sono elementi intrinseci di qualsiasi progetto. Piuttosto che cercare una pianificazione perfetta, è fondamentale adottare una gestione flessibile e proattiva, capace di rispondere meglio alle sfide impreviste e garantire risultati più prevedibili e sostenibili.
La legge 90-90: il primo 90% del progetto richiede il 90% del tempo e il restante 10% richiede anche il 90% del tempo.
La Legge 90-90, spesso citata in modo ironico nel campo dello sviluppo software e della gestione dei progetti, afferma:
“Il primo 90% di un progetto richiede il 90% del tempo previsto, e il restante 10% richiede anch’esso il 90% del tempo.”
Interpretazione e Ambito
Questa legge evidenzia un fenomeno ben noto nei progetti complessi: la sottostima degli sforzi richiesti nelle fasi finali del lavoro.
Dimostra come le attività finali, spesso percepite come secondarie o rapide, risultino invece molto più lunghe e complicate del previsto.
- Primo 90%: Di solito comprende le fasi iniziali, come la progettazione, lo sviluppo o l’esecuzione delle linee principali del progetto. Queste fasi sono spesso ben pianificate e rispettano in larga parte il cronoprogramma.
- Ultimo 10%: Riguarda gli aggiustamenti, le correzioni, i test, le validazioni e le rifiniture. Queste attività sono rallentate da imprevisti, cambiamenti dell’ultimo minuto o problemi non previsti.
Cause principali della Legge 90-90
- Sottostima delle rifiniture:
Dettagli come test, correzioni di bug e validazioni finali sono spesso sottovalutati in termini di tempo ed energia richiesti.
- Aumento della complessità:
Con il progredire del progetto, le interdipendenze e le difficoltà diventano più evidenti, rendendo gli ultimi aggiustamenti più complicati.
- Pressione crescente:
Gli ultimi 10% del progetto spesso coincidono con l’approssimarsi della scadenza, aumentando lo stress e la probabilità di errori.
Esempi di Applicazione
- Sviluppo software: Le fasi iniziali, come la scrittura del codice principale, avanzano rapidamente, ma i test finali, le correzioni dei bug e il rilascio richiedono molto più tempo del previsto.
- Edilizia: La struttura principale può essere completata nei tempi previsti, ma le rifiniture (verniciatura, impianti elettrici, decorazioni) spesso causano ritardi.
- Gestione dei progetti: Anche quando le tappe principali sono completate, gli aggiustamenti finali necessari a soddisfare tutte le parti interessate possono richiedere molto tempo.
Come contrastare la Legge 90-90?
- Pianificazione accurata:
Come per la Legge di Hofstadter, includere “supermercati” per ogni sottoprodotto del progetto e, alla fine, un “supermercato” per l’intero progetto. Questo tempo separa la fine dell’ultima attività dalla data effettiva di consegna. In Synchroboard, questo tempo viene chiamato “banca del tempo”, monitorata attraverso un indicatore specifico per garantire che non venga consumata più rapidamente di quanto avanza il progetto, simile al Burn-Down Chart della metodologia Agile.
- Anticipazione dei dettagli:
Prestare maggiore attenzione alla valutazione delle rifiniture e pianificare un tempo adeguato per test, correzioni e aggiustamenti.
- Iterazioni regolari:
Consegnare progressivamente parti del progetto per identificare e risolvere i problemi il prima possibile, evitando di accumularli verso la fine.
- Gestione proattiva dei rischi:
Identificare i punti critici che potrebbero ritardare le ultime fasi del progetto e predisporre azioni di mitigazione.
Conclusione
La Legge 90-90, pur essendo una rappresentazione umoristica, offre un promemoria realistico: nelle fasi finali di un progetto, i dettagli possono richiedere più tempo ed energia del previsto.
Un’efficace pianificazione e una corretta anticipazione degli imprevisti possono ridurre significativamente l’impatto di questo fenomeno, migliorando la gestione complessiva dei progetti.
Legge di Brooks: l’aggiunta di risorse umane a un progetto ritardato lo ritarderà ulteriormente.
La Legge di Brooks, formulata da Fred Brooks nel suo classico libro The Mythical Man-Month (1975), è un principio fondamentale nella gestione dei progetti, in particolare nello sviluppo software. Essa afferma:
“Aggiungere personale a un progetto in ritardo non fa altro che ritardarlo ulteriormente.”
Spiegazione
La Legge di Brooks evidenzia i limiti dell’aggiunta di risorse umane a un progetto in difficoltà.
Contrariamente alla convinzione comune che un lavoro possa sempre essere accelerato aggiungendo più persone, la realtà dimostra che ciò comporta spesso una perdita di produttività per diversi motivi:
- Tempo di integrazione:
I nuovi membri del team devono essere formati e aggiornati sullo stato del progetto, richiedendo tempo e risorse da parte dei membri già operativi.
- Aumento della complessità comunicativa:
Con l’aumento del numero di persone, gli sforzi di coordinamento crescono esponenzialmente, complicando la comunicazione e il processo decisionale.
- Attività indivisibili:
Alcuni aspetti di un progetto (come la progettazione o la risoluzione di problemi complessi) non possono essere suddivisi tra più persone.
Aggiungere risorse non apporta quindi alcun beneficio in questi casi.
Contesto e Applicazioni
- Sviluppo software:
Brooks osservò questa legge in progetti di grande scala, dove i ritardi peggioravano con l’aggiunta di sviluppatori a causa delle sfide legate alla coordinazione e all’integrazione.
- Gestione dei progetti in generale:
La legge si applica anche ad altri settori, dove l’inserimento di nuove risorse umane in un contesto disorganizzato o già in ritardo provoca ulteriore caos e inefficienza.
Esempio pratico
Immaginiamo un progetto in ritardo in cui 5 sviluppatori lavorano su un’applicazione complessa. Aggiungere 3 nuovi sviluppatori costringerà i primi 5 a:
- Formare i nuovi arrivati.
- Riorganizzare il lavoro e gestire le dipendenze.
Questo rallenterà il loro ritmo di lavoro, aggravando temporaneamente i ritardi invece di risolverli.
Come contrastare la Legge di Brooks?
- Pianificare meglio fin dall’inizio:
Anticipare le necessità di risorse umane e prevedere margini di sicurezza realistici.
È un principio fondamentale, eppure spesso questa valutazione viene trascurata o male eseguita.
- Modularizzare le attività:
Suddividere i progetti in sottosistemi indipendenti per consentire ai nuovi membri di contribuire senza interrompere l’intero flusso.
Questa modularità dovrebbe riflettere quella del prodotto oggetto del progetto, ormai un prerequisito per la competitività.
- Migliorare strumenti e processi:
Utilizzare strumenti di gestione che facilitino la collaborazione e riducano gli sforzi comunicativi.
In questo contesto, Synchroboard si distingue.
Il suo sistema visivo estremamente efficiente permette, in meno di un minuto, persino a una persona esterna al progetto di verificare se il progetto è gestito correttamente o meno.
- Rivedere la pianificazione:
In alcuni casi, è preferibile accettare un ritardo e riorganizzare il lavoro piuttosto che sovraccaricare il team.
Questo approccio è essenziale e parte integrante delle pratiche insegnate nell’ecosistema Synchroboard.
Conclusione
La Legge di Brooks ci ricorda che i progetti complessi non possono sempre essere accelerati semplicemente aumentando il personale.
Una pianificazione accurata, una struttura ben definita e processi efficaci sono fondamentali per evitare ritardi e inefficienze, garantendo così una gestione del progetto più fluida e produttiva.
Legge di Humphrey: gli utenti non sempre sanno cosa vogliono finché non se ne rendono conto.
La Legge di Humphrey, attribuita a Watts Humphrey, pioniere dell’ingegneria del software e creatore del Capability Maturity Model (CMM), afferma:
“Gli utenti non sanno cosa vogliono finché non lo vedono.”
Interpretazione
Questa legge evidenzia una sfida fondamentale nello sviluppo dei prodotti, in particolare nel settore software: i requisiti degli utenti sono spesso mal definiti o in continua evoluzione. Anche quando le esigenze iniziali sono espresse chiaramente, possono rivelarsi imprecise o inadatte a soddisfare i bisogni reali.
Cause principali della Legge di Humphrey
- Visione limitata degli utenti:
Senza una dimostrazione concreta, gli utenti possono avere difficoltà a immaginare come un prodotto o una soluzione risponderà alle loro necessità.
- Evoluzione delle aspettative:
Man mano che un progetto avanza, gli utenti acquisiscono una comprensione più chiara dei loro bisogni reali, spesso diversi da quelli iniziali.
- Complessità dei progetti:
I sistemi software, in particolare, sono spesso così complessi che le loro interazioni e funzionalità non possono essere completamente comprese prima dell’implementazione.
Implicazioni nella gestione dei progetti e nello sviluppo software
- Deriva dei requisiti:
I frequenti cambiamenti nelle esigenze degli utenti (noti anche come scope creep) possono causare ritardi, superamenti del budget e frustrazioni.
- Comunicazione insufficiente:
La legge sottolinea l’importanza di una comunicazione continua tra il team di sviluppo e gli utenti per ridurre i fraintendimenti.
- Necessità del prototipazione:
Giustifica l’uso di mockup, prototipi o versioni preliminari per consentire agli utenti di “vedere” e affinare le loro aspettative.
Approcci per gestire la Legge di Humphrey
- Metodologie Agile:
Approcci come Scrum o Kanban permettono di consegnare versioni incrementali del prodotto, raccogliendo feedback dagli utenti e adeguando rapidamente le funzionalità.
Tuttavia, questa strategia deve essere usata con attenzione: un approccio incrementale e iterativo non deve sostituire una vera esplorazione dei bisogni e delle loro priorità, cosa che il metodo Quality Function Deployment (QFD) fa in modo eccellente.
- Prototipazione rapida:
Creare mockup o prototipi funzionanti per permettere agli utenti di testare e affinare le loro aspettative sin dalle prime fasi del progetto.
- Workshop collaborativi:
Coinvolgere attivamente gli utenti durante le fasi di progettazione per ridurre la distanza tra i bisogni reali e quelli dichiarati.
- Test frequenti con gli utenti:
Organizzare sessioni di test con utenti reali durante tutto il progetto per convalidare le funzionalità in sviluppo.
Conclusione
La Legge di Humphrey ricorda con forza che i progetti devono essere flessibili e centrati sugli utenti.
Utilizzando metodologie appropriate e collaborando strettamente con le parti interessate, i team possono ridurre le incertezze e soddisfare i bisogni reali degli utenti, anche quando questi evolvono nel tempo.
Tuttavia, considerare l’evoluzione delle esigenze non deve in alcun modo prolungare la durata complessiva del progetto.
La legge della complessità: più un progetto è complesso, maggiori sono i potenziali punti di errore.
La Legge della Complessità, pur non essendo formalmente definita come una “legge” unica, si riferisce all’idea che la complessità di un sistema o di un progetto tenda a crescere nel tempo, spesso in modo esponenziale, man mano che vengono aggiunti nuovi elementi.
Una possibile formulazione di questa idea è:
“La complessità aumenta con la scala di un progetto o di un sistema, e ogni aggiunta rende la gestione e la comprensione più difficili.”
Origine e Contesto
Questa legge si basa su principi osservati in vari ambiti, tra cui:
- Gestione dei progetti: Ogni attività o dipendenza aggiunta aumenta la difficoltà di coordinazione.
- Sviluppo software: Ogni nuova riga di codice, funzionalità o correzione di bug può introdurre dipendenze e rischi imprevisti.
- Sistemi complessi in generale: Interazioni inattese emergono quando il sistema diventa più grande o sofisticato.
Principali Concetti Legati alla Legge della Complessità
- Crescita esponenziale della comunicazione:
Quando cresce la dimensione di un team o di un progetto, il numero di canali di comunicazione aumenta in modo esponenziale, secondo la formula , dove è il numero di membri. Ciò complica la coordinazione e aumenta il rischio di malintesi.
- “Debito tecnico”:
Nello sviluppo software, ogni modifica rapida o non pianificata può aggiungere complessità al sistema, richiedendo maggiori sforzi per la manutenzione o il miglioramento nel lungo periodo.
- Entropia organizzativa:
Nelle organizzazioni o nei progetti, l’introduzione di regole, processi o strumenti aggiuntivi può rendere il sistema più rigido, lento e difficile da gestire.
- Legge dei rendimenti decrescenti:
Aggiungendo elementi per risolvere un problema o migliorare un sistema, i benefici ottenuti diventano sempre meno significativi rispetto allo sforzo aggiuntivo richiesto.
Implicazioni della Legge della Complessità nella Gestione dei Progetti
- Difficoltà di coordinazione:
Più un progetto è grande e complesso, più diventa difficile allineare gli sforzi delle diverse parti interessate.
- Rischio maggiore di errori:
Con l’aumento delle interdipendenze, un errore minore può avere conseguenze sproporzionate sull’intero progetto.
- Aumento di tempi e costi:
La complessità aggiunge ulteriori livelli di lavoro (pianificazione, comunicazione, correzione), impattando negativamente sulle scadenze e sui budget.
Come Gestire la Complessità?
- Semplificazione proattiva:
- Suddividere progetti o sistemi in moduli indipendenti.
- Ridurre le dipendenze tra le attività.
- Prioritizzazione delle attività essenziali:
Concentrarsi sugli elementi ad alto valore aggiunto ed evitare aggiunte inutili che aumentano la complessità senza benefici chiari.
Questo punto è cruciale nei pannelli utilizzati nell’applicazione Synchroboard™, dove solo le attività che coinvolgono due o più parti interessate (generalmente settori o funzioni) vengono gestite. Le attività interne a ogni funzione sono gestite localmente per non disperdere l’attenzione del project manager e delle parti coinvolte sugli obiettivi chiave del progetto.
- Automazione e strumenti adeguati:
Utilizzare strumenti di gestione per semplificare i processi e migliorare la comunicazione.
- Metodologie Agile:
Adottare approcci flessibili come Scrum, che promuovono cicli brevi e frequenti aggiustamenti, riducendo i rischi legati all’accumulo di complessità.
- Documentazione rigorosa:
Mantenere una documentazione chiara e aggiornata per favorire una migliore comprensione e gestione di sistemi complessi.
Conclusione
La Legge della Complessità ricorda che qualsiasi sistema o progetto, se non viene attivamente semplificato, tende a diventare sempre più difficile da comprendere e gestire.
Integrando pratiche adeguate e mantenendo un equilibrio tra innovazione e stabilità, è possibile limitare gli effetti negativi della complessità crescente.
Legge di Maier: Se il problema non è ben definito, anche la soluzione sarà problematica.
La Legge di Maier, formulata dall’ingegnere e specialista di sistemi Robert Maier, è un principio spesso citato nell’ingegneria dei sistemi e nella gestione dei progetti. Essa afferma:
“Se il problema non è chiaramente definito, la migliore soluzione non può essere identificata.”
Interpretazione
La Legge di Maier sottolinea un aspetto fondamentale della risoluzione dei problemi: l’importanza cruciale di una comprensione chiara e precisa del problema prima di cercare soluzioni.
Un problema mal definito porta a soluzioni inefficaci o inadeguate, spesso costose in termini di tempo e risorse.
Cause Frequenti di Problemi Mal Definiti
- Mancanza di chiarezza negli obiettivi:
Le parti interessate non concordano su ciò che vogliono ottenere.
- Comprensione errata:
I bisogni degli utenti o dei clienti non sono ben compresi o espressi.
- Complessità o ambiguità del problema:
Gli aspetti critici del problema vengono oscurati da dettagli secondari o mal prioritizzati.
- Ipotesi implicite:
Le parti interessate o i team suppongono di conoscere il problema senza averlo analizzato esplicitamente.
Applicazione nella Gestione dei Progetti
- Importanza della definizione dei requisiti:
Un problema mal definito può portare a specifiche poco chiare, rendendo difficile misurare il successo o il fallimento del progetto.
- Impatto su tempi e budget:
I progetti spesso iniziano con un’idea vaga degli obiettivi, il che porta a costosi aggiustamenti in corso d’opera.
Sebbene si dica che non bisogna aspettare di avere tutto chiaro per iniziare, si rischia di cadere nell’eccesso opposto, dove il tempo per correggere supera quello necessario per chiarire meglio in partenza.
Come recita un altro adagio: “Affrettati lentamente.”
- Deriva dei requisiti (scope creep):
La mancanza di chiarezza iniziale favorisce l’aggiunta progressiva di nuove richieste, complicando la gestione di risorse e tempi.
A questo proposito, il processo di esplorazione dei bisogni della metodologia Quality Function Deployment (Blitz QFD) è estremamente efficace.
Come Applicare la Legge di Maier?
- Analisi approfondita del problema:
- Utilizzare l’approccio esplorativo come il Blitz QFD.
- Applicare strumenti come il diagramma di Ishikawa (diagramma causa-effetto) per identificare le cause profonde.
- Organizzare workshop collaborativi con le parti interessate per chiarire bisogni e aspettative.
- Definire obiettivi SMART:
Gli obiettivi devono essere:
- Specifici
- Misurabili
- Raggiungibili
- Rilevanti
- Definiti temporalmente
- Formalizzare i requisiti:
Documentare le specifiche in modo chiaro e dettagliato per evitare fraintendimenti.
- Prototipazione rapida:
Creare un prototipo o un mockup per validare la comprensione del problema da parte degli utenti e delle parti interessate.
- Comunicazione attiva:
Implementare un processo di feedback regolare per affinare la definizione del problema e garantire l’allineamento tra tutti gli attori.
In Synchroboard™, questo passaggio rientra nel concetto di “tripla chiave”, un punto di controllo (gate) in cui si verifica, tra le altre cose, che le specifiche siano corrette e che il cliente non le stia riconsiderando o modificando.
Esempio Pratico
Nello sviluppo di un software per la gestione dell’inventario, se il problema viene definito semplicemente come:
“Abbiamo bisogno di un sistema per gestire i nostri magazzini”,
potrebbe portare a soluzioni inadeguate.
Approfondendo, si scopre che il vero problema è:
“Abbiamo bisogno di ridurre gli errori umani nell’inserimento manuale e migliorare il monitoraggio dei prodotti in tempo reale.”
Questa definizione precisa guida la creazione di una soluzione adeguata.
Conclusione
La Legge di Maier ricorda che il tempo dedicato a definire chiaramente un problema è un investimento cruciale per garantire il successo di un progetto.
Un’analisi chiara e dettagliata dei bisogni, combinata con una comunicazione efficace, è la chiave per identificare soluzioni che rispondano realmente alle aspettative delle parti interessate e alle esigenze del contesto.
Legge di Peters: i team di progetto finiscono sempre per produrre ciò che è più facile da dimostrare, non necessariamente ciò che è più utile.
“Un team di progetto finisce sempre per fare ciò che è più facile da dimostrare, e non ciò che è più importante.”
Interpretazione
Questa legge evidenzia una tendenza comune nella gestione dei progetti:
i team tendono a dare priorità alle attività o ai risultati più visibili e misurabili, a scapito di quelli essenziali ma meno tangibili o difficili da quantificare.
Questo può portare a progetti in cui gli obiettivi strategici vengono trascurati a favore di deliverable secondari o simbolici.
Perché accade questa tendenza?
- Pressione per mostrare progressi visibili:
Stakeholder e management richiedono spesso prove concrete di avanzamento, spingendo i team a concentrarsi su attività dimostrabili.
- Facilità di esecuzione:
I membri del team preferiscono affrontare compiti semplici o tecnicamente accessibili, lasciando da parte elementi complessi o strategici.
- Scarsa definizione delle priorità:
In assenza di priorità chiare, i team possono focalizzarsi su attività che sembrano più gratificanti nel breve termine.
- Mancanza di visione strategica:
Quando gli obiettivi globali non sono ben compresi, i team si concentrano su ciò che è facile da quantificare.
Implicazioni nella Gestione dei Progetti
- Deviazione dagli obiettivi strategici:
Il progetto rischia di produrre deliverable conformi in apparenza, ma che non rispondono ai bisogni reali o critici.
- Perdita di tempo e risorse:
Gli sforzi si concentrano su attività secondarie invece di focalizzarsi sugli aspetti chiave.
- Frustrazione degli stakeholder:
Se i risultati finali non rispecchiano le aspettative strategiche, possono emergere conflitti o insoddisfazioni.
Come contrastare gli effetti della Legge di Peters?
- Definire chiaramente le priorità:
- Devono essere priorità di progetto, non individuali.
- Stabilire traguardi basati su criteri d’impatto, non solo di visibilità.
- Promuovere una visione a lungo termine:
- Formare i team a ragionare in termini di obiettivi globali e impatti.
- Sottolineare il valore strategico delle attività, anche se meno visibili.
- Monitorare gli indicatori chiave:
- Introdurre KPI (Key Performance Indicators) pertinenti che misurino i risultati importanti, non solo le fasi intermedie.
- Una dashboard di progetto deve includere indicatori di processo e indicatori di risultato, rispettando il principio: “Il processo seguito conduce ai risultati che ne derivano.”
- Coinvolgere gli stakeholder:
- Mantenere una comunicazione regolare per ricordare le priorità e allineare le aspettative.
- Incoraggiare una cultura del feedback:
- Organizzare revisioni periodiche per valutare se gli sforzi attuali contribuiscono davvero agli obiettivi globali.
Esempio Pratico
In un progetto di sviluppo software, il team potrebbe concentrarsi sulla progettazione di un’interfaccia utente accattivante (facile da mostrare durante le presentazioni) invece di ottimizzare il sistema backend, che è più complesso ma essenziale per le prestazioni complessive del prodotto.
Conclusione
La Legge di Peters è un prezioso promemoria per i project manager: non basta mostrare risultati visibili.
Gli sforzi devono essere allineati a ciò che è realmente importante per il successo globale del progetto.
Una gestione proattiva, una chiara definizione delle priorità e una visione strategica sono essenziali per contrastare questa tendenza naturale.
Legge di Kidder: Le cose che vengono misurate migliorano. Le cose che vengono ignorate si deteriorano.
La Legge di Kidder, attribuita a Tracy Kidder, scrittore e autore del libro The Soul of a New Machine (1981), afferma:
“Le persone che non hanno il tempo di fare bene le cose fin dall’inizio troveranno sempre il tempo per rifarle.”
Interpretazione
La Legge di Kidder sottolinea l’importanza di dedicare il tempo necessario a fare bene le cose fin dall’inizio, soprattutto in progetti complessi come lo sviluppo software, la gestione dei progetti o l’ingegneria.
Evidenzia un fenomeno comune: un approccio affrettato nelle fasi iniziali spesso porta a errori costosi, che richiedono correzioni successive, con conseguenti ritardi e sforamenti del budget.
Implicazioni nella Gestione dei Progetti
- Costo degli errori iniziali:
Un lavoro mal fatto all’inizio genera problemi che diventano sempre più costosi da correggere man mano che il progetto avanza.
Ad esempio, un errore di progettazione non rilevato potrebbe richiedere una riprogettazione completa in una fase avanzata.
- Perdita di tempo:
Sebbene si pensi di risparmiare tempo avanzando rapidamente, i ritorni indietro e le correzioni richiedono spesso molto più tempo rispetto a quanto si sarebbe impiegato facendo le cose bene fin dall’inizio.
- Impatto sulla qualità:
I prodotti o i deliverable sottoposti a numerose correzioni rischiano di essere di qualità inferiore, poiché gli aggiustamenti successivi possono introdurre incoerenze o compromessi.
Esempi Pratici
- Sviluppo software:
Se si salta la fase dei test iniziali per risparmiare tempo, i bug non rilevati potrebbero emergere in produzione, richiedendo correzioni urgenti e costose.
- Costruzioni:
Una stima errata dei materiali o una preparazione trascurata potrebbe causare ritardi significativi e costi aggiuntivi.
Come Evitare gli Effetti della Legge di Kidder
- Pianificazione accurata:
- Investire tempo nella pianificazione iniziale per identificare requisiti, rischi e tappe fondamentali.
- Stabilire step intermedi per evitare la fretta eccessiva.
- Definire standard di qualità:
- Creare criteri di qualità chiari per superare le varie fasi del progetto.
- Assicurarsi che ogni fase rispetti questi standard prima di procedere alla successiva.
- Adottare metodologie iterative:
- Utilizzare approcci come Agile, che consentono di sviluppare incrementi successivi integrando feedback regolari per evitare grandi ritorni indietro.
- Nell’ecosistema Synchroboard, questo avviene durante la fase di strutturazione del progetto, che deriva dal piano di mitigazione dei rischi.
- Investire nelle fasi critiche:
- Prestare particolare attenzione alle prime fasi del progetto (ricerca, progettazione, test iniziali) per costruire basi solide.
- Formare i team:
- Assicurarsi che tutti i membri del team comprendano l’importanza di fare bene le cose fin dall’inizio e dispongano delle competenze necessarie.
- Ricordare il detto: “Un lavoro mal fatto all’inizio costa da 7 a 13 volte di più in termini di tempo o risorse per correggerlo”, per modificare i comportamenti.
Conclusione
La Legge di Kidder ci ricorda che la fretta nelle fasi iniziali di un progetto può avere conseguenze costose.
Prendersi il tempo per pianificare, eseguire e validare accuratamente fin dall’inizio è un investimento che consente di risparmiare risorse, migliorare la qualità e garantire il successo complessivo del progetto.
Legge di Cohn: le decisioni più importanti sono spesso prese sulla base di informazioni incomplete.
La Legge di Cohn, formulata da Mike Cohn, esperto nello sviluppo Agile e autore di diversi libri sull’argomento, afferma:
“Più è difficile cambiare un aspetto di un sistema, più è importante definirlo correttamente fin dall’inizio.”
Interpretazione della Legge di Cohn
La Legge di Cohn evidenzia l’importanza di dare priorità agli aspetti critici di un progetto o di un sistema, specialmente quelli che saranno difficili, costosi o impossibili da modificare in futuro.
Sottolinea che alcune scelte, come le fondamenta di un’architettura software o i principi di base di un prodotto, richiedono particolare attenzione fin dalle prime fasi di progettazione.
Implicazioni nella Gestione dei Progetti
- Le decisioni strutturali hanno un impatto duraturo:
Le scelte iniziali di un progetto, come la tecnologia o la modularità, influenzano significativamente il percorso futuro.
Se queste decisioni sono sbagliate, le correzioni possono essere molto costose e complesse.
- Importanza dell’analisi iniziale:
Gli aspetti difficili da cambiare, come le dipendenze critiche, le norme di qualità o gli obiettivi strategici, devono essere analizzati attentamente prima di avviare il progetto.
- Flessibilità negli aspetti secondari:
Gli elementi facilmente modificabili, come l’interfaccia utente o funzionalità non critiche, possono essere decisi in un secondo momento o adattati a costi ridotti.
Esempi Pratici
Sviluppo software:
Se un sistema software viene progettato senza considerare la scalabilità (la capacità di gestire un aumento del carico), correggere questo errore quando il sistema è in produzione sarà estremamente costoso. La scalabilità, essendo difficile da modificare, deve essere pianificata fin dall’inizio.
Costruzioni:
Nella costruzione di un edificio, le fondamenta devono essere progettate con precisione perché sono quasi impossibili da modificare una volta realizzate, a differenza degli elementi decorativi o delle pareti interne.
Come Applicare la Legge di Cohn?
- Identificare gli elementi critici:
- Eseguire un’analisi approfondita per individuare gli aspetti che saranno costosi o complessi da modificare (es. architettura, infrastruttura, obiettivi strategici).
- Dare priorità alle decisioni fondamentali:
- Investire più tempo e risorse per definire chiaramente gli aspetti chiave all’inizio del progetto.
- Lasciare maggiore flessibilità agli elementi secondari o facilmente modificabili.
- Anticipare i cambiamenti possibili:
- Utilizzare modelli o architetture flessibili (es. modularità nello sviluppo software o nella progettazione) per ridurre al minimo gli impatti delle modifiche future.
- Validare le scelte critiche:
- Creare prototipi o effettuare validazioni preliminari per garantire che le scelte iniziali siano in linea con gli obiettivi.
Conclusione
La Legge di Cohn ricorda che non tutte le decisioni di un progetto hanno la stessa importanza o le stesse conseguenze.
Identificando e dando priorità alle scelte fondamentali, i team di progetto possono ridurre i rischi, evitare costi inutili e stabilire solide basi per il successo a lungo termine.
Legge di Weinberg: un team lavorerà entro il suo livello di tolleranza al fallimento
La Legge di Weinberg, formulata da Gerald Weinberg, esperto di gestione dei progetti e sviluppo software, afferma:
“Se gli sviluppatori hanno la sensazione che i loro dati saranno usati per punirli, falsificheranno i dati.”
Interpretazione della Legge
La Legge di Weinberg mette in evidenza un problema comune negli ambienti di lavoro in cui la performance delle squadre o dei singoli individui viene misurata in modo rigido e punitivo.
Quando i dipendenti percepiscono valutazioni o indicatori come una minaccia, possono manipolare dati o rapporti per evitare conseguenze negative, invece di segnalare onestamente difficoltà o problemi incontrati.
Implicazioni nella Gestione dei Progetti
- Metriche distorte:
Rapporti e indicatori di performance diventano poco affidabili, poiché i dipendenti cercano di “proteggersi” invece di riflettere la realtà.
- Perdita di trasparenza:
Una cultura punitiva incoraggia la dissimulazione dei problemi, ritardandone l’identificazione e la risoluzione.
- Impatto sulla collaborazione:
Un’atmosfera di sfiducia ostacola la comunicazione aperta tra i membri del team e può isolare gli individui.
- Fallimento dei progetti:
Quando le decisioni di gestione si basano su dati inesatti o falsificati, i progetti rischiano di deviare dagli obiettivi o di fallire.
Esempio Pratico
In un team di sviluppo prodotto, se un project manager insiste su scadenze rigide minacciando sanzioni in caso di ritardi, i membri del team potrebbero riportare progressi esagerati o incompleti, nascondendo problemi tecnici o bug.
Questi problemi, non rilevati in tempo, possono causare ritardi maggiori o portare a un prodotto di qualità inferiore.
Come Evitare gli Effetti della Legge di Weinberg?
- Creare le condizioni per sviluppare l’intelligenza emotiva anziché il management repressivo:
- Incoraggiare una comunicazione aperta in cui i membri del team si sentano sicuri di segnalare problemi o ritardi senza temere ritorsioni.
- Valorizzare gli apprendimenti derivati dagli errori invece di punirli. Si impara di più dagli errori che dai successi.
- Utilizzare le metriche come strumento di miglioramento:
- Presentare gli indicatori di performance come un mezzo per diagnosticare e migliorare i processi, non come un’arma per giudicare o sanzionare.
- Favorire la trasparenza:
- Coinvolgere i team nella definizione delle metriche di performance, assicurandosi che siano pertinenti e comprese da tutti.
- Fornire feedback costruttivi basati sui dati, senza accuse né critiche.
- Adottare pratiche agili:
- Organizzare retrospettive regolari per discutere apertamente le sfide incontrate e i modi per migliorare.
- Promuovere un approccio incrementale, in cui i problemi vengano identificati e risolti presto nel ciclo di sviluppo.
- Responsabilizzare senza minacce:
- Concentrarsi sulla responsabilità collettiva del team piuttosto che sulle performance individuali.
Conclusione
La Legge di Weinberg ricorda che un approccio punitivo nell’uso dei dati può compromettere la trasparenza e l’affidabilità delle informazioni cruciali per il successo di un progetto.
Promuovendo una cultura di fiducia, apprendimento e collaborazione, si incoraggiano comportamenti onesti e proattivi, essenziali per il successo dei progetti.
Questo approccio è al centro dell’ecosistema Synchroboard™, che favorisce lo sviluppo dell’intelligenza collettiva come la migliore forma di performance operativa.
Perché le applicazioni di gestione dei progetti spesso non soddisfano le aspettative?
Statistica 1: Utilizzo dei software di gestione dei progetti
- Il 77% delle aziende possiede un software di gestione dei progetti, ma solo il 23% lo utilizza quotidianamente.
Commento:
Perché il 54% delle aziende non lo utilizza ogni giorno? La gestione dei progetti è presente in quasi tutti i settori. Questa situazione potrebbe essere spiegata da:
- Funzionalità non adeguate ai bisogni reali.
- Mancanza di chiarezza sui benefici apportati dai software.
Se l’utilità non è percepita, questi strumenti rischiano di cadere in disuso.
Statistica 2: Tasso di successo dei progetti
- 31% dei progetti rispettano tempi, budget e requisiti iniziali.
- 52% dei progetti terminano con sforamenti di costi, ritardi o modifiche agli obiettivi.
- 19% dei progetti vengono cancellati prima del completamento.
Commento:
Questi dati evidenziano problemi sistemici nella gestione dei progetti, come:
- Stime irrealistiche.
- Obiettivi poco definiti.
- Cambiamenti non gestiti correttamente.
Soluzione:
Ripensare le pratiche, migliorare la pianificazione, adottare una comunicazione efficace e strumenti realmente utili per affrontare queste sfide.
1. Ripensare la gestione dei progetti
Il 31% di progetti di successo dimostra che raggiungere gli obiettivi è possibile anche in contesti complessi.
Tuttavia, il fatto che quasi il 70% dei progetti affronti problemi o fallimenti parziali evidenzia la necessità di migliorare i processi e la maturità della gestione dei progetti.
L’ecosistema Synchroboard™ affronta queste sfide lavorando sulle cause sistemiche degli insuccessi.
Il dato allarmante del 19% di progetti annullati sottolinea un bisogno di rafforzare:
- Il processo di identificazione dei bisogni dei clienti.
- La costruzione della proposta di valore.
In questo contesto, l’uso di strumenti come il Blitz QFD, parte integrante di Synchroboard™, aiuta a esplorare e strutturare i bisogni in modo approfondito, allineando i progetti alle reali aspettative delle parti interessate.
2. Importanza della comunicazione e delle parti interessate
- Molti ritardi o cancellazioni derivano da una gestione inadeguata delle aspettative o da incomprensioni tra le parti coinvolte.
- Migliorare chiarezza e comprensione condivisa può portare benefici significativi
- Anticipare l’evoluzione delle esigenze
- Attraverso punti di controllo e certificazione rigorosi, come le “triple chiavi” di Synchroboard™, si assicura che:Le specifiche e le aspettative dei clienti siano validate in ogni fase.
- Gli eventuali cambiamenti siano integrati senza disagi per il progetto.
- Ridurre le frustrazioni legate a ritardi e aggiustamenti
- Anticipare l’evoluzione delle esigenze
3. Focus sulla riduzione degli sforamenti (52%)
L’elevato numero di progetti che superano i budget o i tempi evidenzia l’urgenza di migliorare alcuni aspetti fondamentali della gestione dei progetti
Soluzioni per affrontare i problemi legati a costi e ritardi:
- Migliorare le stime:
- Usare simulazioni basate su dati reali o scenari predefiniti.
- Analizzare dati storici per identificare deviazioni ricorrenti e affinare i modelli di previsione.
- Rafforzare il controllo durante il progetto:
- Implementare strumenti di gestione efficaci per monitorare i progressi in tempo reale.
- Utilizzare dashboard e strumenti collaborativi per visualizzare lo stato del progetto e rispondere rapidamente agli imprevisti.
- Adottare un nuovo approccio al tempo:
- Evitare che il tempo venga considerato un budget da consumare integralmente (legge di Parkinson).
- Gestire il tempo come un conto in banca, investendo ogni minuto risparmiato in altre attività.
- Utilizzare strumenti come i burn-down charts per ottimizzare l’uso del tempo rimanente.
- Integrare la qualità nei progetti
- I 5 strumenti dell’Auto-Qualità:
- Questi strumenti evitano la creazione o la trasmissione di difetti tra le fasi del progetto. In Synchroboard™, queste informazioni sono incluse nei kanban.
- Quality Gate/Triple Chiave:
- Un passaggio obbligatorio che certifica il lavoro svolto prima di passare alla fase successiva, garantendo conformità e stabilità delle specifiche.
- I 5 strumenti dell’Auto-Qualità:
- Impatti finanziari e organizzativi
- Le statistiche evidenziano impatti significativi:
- Perdite di risorse e opportunità mancate:
- Spreco di risorse umane e finanziarie.
- Opportunità commerciali perse, con impatti sulla crescita e competitività aziendale.
- Gestione ottimizzata con Synchroboard™:
- Riduzione significativa di costi e ritardi grazie a una sincronizzazione migliorata e gestione proattiva dei rischi.
- Rafforzamento della fiducia tra le parti interessate con comunicazione chiara e risultati prevedibili.
- Perdite di risorse e opportunità mancate:
Tool based-Project management: i limiti dei software di gestione dei progetti e la necessità di un’Intelligenza Collettiva
Le applicazioni di gestione dei progetti, sebbene progettate per facilitare la coordinazione, migliorare la produttività e centralizzare le informazioni, mostrano talvolta i loro limiti nella pratica.
- Circa il 60% dei progetti fallisce nel raggiungere gli obiettivi iniziali, anche con strumenti dedicati.
- Questo dato evidenzia un paradosso: nonostante le risorse impiegate, i risultati attesi non sempre vengono raggiunti.
- Ciò contraddice il principio di “Less Make More”, dove dovrebbero prevalere semplicità ed efficacia.
Problema di complessità
- Sebbene questi software offrano una vasta gamma di funzionalità, la loro complessità rappresenta spesso un ostacolo significativo per gli utenti.
- Secondo un recente sondaggio, il 40% degli utenti ammette di non sfruttare pienamente questi strumenti, a causa della mancanza di formazione adeguata o di interesse.
- Questa barriera impedisce a tali soluzioni di esprimere il loro pieno potenziale e limita il loro impatto sul successo dei progetti.
Conclusione
Per massimizzare l’efficacia dei software di gestione dei progetti, è fondamentale:
- Semplificare l’utilizzo, rendendo l’interfaccia e le funzionalità più intuitive.
- Fornire una formazione adeguata per supportare gli utenti nell’adozione degli strumenti.
- Garantire che l’implementazione dei software si basi su una chiara comprensione dei bisogni reali degli utenti e delle organizzazioni.
Hanno permesso i software di migliorare in modo significativo le cause sistemiche di insuccesso nella gestione dei progetti?
I software di gestione dei progetti sono spesso percepiti come soluzioni in grado di compensare i problemi di comunicazione e interazione all’interno dei team.
A volte si tende persino ad attribuire loro capacità quasi “intelligenti”, come se un’intelligenza artificiale potesse risolvere automaticamente questi disfunzionamenti.
Tuttavia, una valutazione condotta nel 2023 ha rivelato che oltre il 50% degli utenti ritiene che questi strumenti non si adattino alle specificità dei propri flussi di lavoro.
Molte aziende utilizzano contemporaneamente più applicazioni, il che porta a una dispersione delle informazioni invece che a una loro centralizzazione.
Questa frammentazione compromette l’efficacia complessiva, generando silos di dati e ostacolando la collaborazione.
L’Intelligenza Collettiva: La chiave per affrontare questa situazione
Per massimizzare l’efficacia degli strumenti di gestione dei progetti, è essenziale superare la semplice gestione delle attività per instaurare una vera Intelligenza Collettiva.
Questa approccio si basa su:
1.Sincronizzazione ottimale:
•Allineare i team, le attività e gli obiettivi per garantire che tutte le parti procedano nella stessa direzione.
•Assicurare una coordinazione fluida tra i diversi attori ed evitare sforzi dispersi o ridondanze.
2.Centralizzazione delle informazioni:
•Raccogliere tutti i dati rilevanti in un unico spazio, accessibile a tutti i membri del progetto.
•Eliminare i silos organizzativi e i duplicati per fornire una visione chiara e condivisa dello stato di avanzamento del progetto.
3.Adattabilità degli strumenti:
•Integrare soluzioni flessibili, in grado di adattarsi ai bisogni specifici e ai processi interni di ogni azienda.
•Consentire un livello di personalizzazione adeguato per riflettere le realtà operative e massimizzare l’efficienza dei team.
Synchroboard™ punta esattamente a questo obiettivo, collocando l’Intelligenza Collettiva al centro del suo ecosistema.
Creando le condizioni necessarie per una collaborazione fluida e una comunicazione arricchita, consente di raggiungere il massimo livello di performance organizzativa nella gestione dei progetti.
L’Intelligenza Collettiva non è solo un obiettivo finale, ma un motore per trasformare le sfide organizzative in opportunità di eccellenza.
Classifica delle cause sistemiche
Sebbene l’utilizzo di questi strumenti sia aumentato e offrano una vasta gamma di funzionalità per migliorare la comunicazione, la pianificazione e il monitoraggio, i tassi di successo dei progetti non hanno registrato progressi significativi.
Questo dato suggerisce che alcuni concetti o comportamenti fondamentali debbano essere riesaminati e adattati alle realtà organizzative.
Le cause degli insuccessi sono distribuiti equamente:
- 50% legati alla gestione dei progetti (es.: pianificazione, monitoraggio, gestione dei rischi).
- 50% legati all’organizzazione e al management aziendale (es.: cultura aziendale, leadership, allineamento strategico).
Questa distribuzione spiega perché i software di gestione dei progetti, per quanto avanzati, non siano stati sufficienti a migliorare significativamente i tassi di successo.
Gli strumenti non possono compensare disfunzioni organizzative o problemi strutturali nella gestione del lavoro in team.
Conclusione:
Per ottenere risultati significativamente migliorati, è essenziale affiancare l’utilizzo dei software a un’evoluzione delle pratiche manageriali e organizzative, integrando concetti come:
- L’intelligenza collettiva,
- Una migliore definizione degli obiettivi,
- Una comunicazione rafforzata tra i team.
Solo un approccio integrato tra tecnologia e trasformazione organizzativa può portare a un vero miglioramento.
Cause strettamente legate alla governance del progetto | Cause legate all’organizzazione e al management dell’azienda | |
Tasso eccessivo >35% | Modifica degli obiettivi del progetto: 37% | Modifica delle priorità dell’organizzazione: 39% |
Tasso molto elevato >20% et <30% | Comunicazione inadeguata o scarsa: 29% Opportunità e rischi indefiniti: 29% Supporto sponsor insufficiente: 26% Stima imprecisa del tempo di attività: 25% | Visione o obiettivo inadeguati: 29% Scarsa gestione del cambiamento: 28% Dipendenza dalle risorse: 26% Project manager inesperto: 22% |
Tasso elevato <20% | Procrastinazione dei membri del team: 13% | Previsione inadeguata delle risorse: 18% Dipendenza dall’attività: 12% |
Convinzioni su cui ci siamo basati per affrontare le cause sistemiche dei fallimenti nella gestione dei progetti
Abstract:
Nella gestione dei progetti, l’imprevisto è spesso percepito come un ostacolo inaspettato che disturba anche i piani più accurati. Tuttavia, l’imprevisto non deve essere confuso con l’imprevedibile. Mentre l’imprevedibile sfugge a qualsiasi anticipazione, l’imprevisto trova le sue radici nell’ignoto: ipotesi non verificate, informazioni mancanti o processi mal gestiti. Questo articolo esplora come gli imprevisti nascano dalle zone d’incertezza e propone strategie concrete per anticiparli e ridurne l’impatto. Tra queste, la precisione nella gestione dei dettagli, la certificazione delle fasi e una reazione rapida agli scostamenti permettono di trasformare l’imprevisto in un’opportunità di apprendimento. Adottando un approccio proattivo e deterministico, i team possono ridurre l’ignoto e rafforzare la propria capacità di raggiungere gli obiettivi, anche di fronte agli imprevisti.
È nell’ignoto che si nasconde l’imprevisto 🚀🔍
Nella gestione dei progetti, l’imprevisto è spesso visto come un elemento di disturbo inaspettato 😬, una delle cause frequenti di fallimento nel raggiungimento degli obiettivi.
Quante volte abbiamo sentito dire: «Senza quell’imprevisto, tutto sarebbe andato bene…»?
Ma poniamoci la vera domanda: si trattava di un imprevisto o di un imprevedibile? 🤔
Per sua natura, l’imprevedibile sfugge a qualsiasi anticipazione. L’imprevisto, invece, deriva spesso da una mancanza di rigore: un’ipotesi non verificata, un’analisi insufficiente o un processo mal eseguito.
L’imprevisto nasce dall’ignoto 🌫️, quel vasto e complesso spazio che include tutto ciò che ignoriamo o trascuriamo.
Un’informazione mancante, un lavoro non certificato o una cattiva sincronizzazione tra i team rappresentano altrettante zone di incertezza 🌪️ che si trasformano rapidamente in imprevisti destabilizzanti.
Più un progetto è complesso, più gli ignoti sono numerosi, e più gli imprevisti si manifestano.
Come limitare queste situazioni?
Rifiutiamo il fatalismo 🚫. L’ignoto non deve mai giustificare un fallimento. Nulla è inevitabile: ogni imprevisto rappresenta un’opportunità di analisi e miglioramento.
Adottiamo un approccio deterministico. Siamo convinti che i risultati derivino dai processi implementati 🔄.
Migliorando la capacità di gestire gli imprevisti, rendiamo i progetti più prevedibili e i loro risultati più affidabili.
Per riuscirci, dobbiamo padroneggiare i dettagli 🧐:
•Identificare le zone a rischio,
•Certificare i lavori ✔️, e
•Sincronizzare i team e le attività 🤝.
Adottiamo una gestione reattiva di fronte agli scostamenti 🚨:
•Riconosciamoli,
•Analizziamone le cause profonde, e
•Correggiamoli per evitare che si ripetano.
Ogni imprevisto è una lezione per ridurre l’ignoto nei progetti futuri 📘.
Se impariamo a esplorare l’ignoto con rigore e a trattare gli imprevisti come opportunità, rafforzeremo la nostra resilienza e aumenteremo le possibilità di successo.
E se l’imprevisto diventasse il nostro alleato? 💪🚀
Imprevisti, Imprevedibili, Inevitabili e altri Sconosciuti: Vincere contro uno dei maggiori perturbatori della gestione dei progetti
Convinzioni | Impatto sulla gestione di progetto | Impatto sull’organizzazione e il management dell’azienda |
Un progetto inizia solo perché è stato valutato come sufficientemente contributivo agli obiettivi strategici dell’azienda. | Evita che il progetto venga annullato o posticipato. | Obbliga l’azienda a valutare il contributo di ogni progetto all’interno del portafoglio. |
Un progetto inizia solo dopo aver esplorato i bisogni del mercato. | Permette di avere maggiore certezza sugli obiettivi attesi. | Obbliga l’azienda a implementare un vero processo di esplorazione del proprio mercato. |
Non si può creare un diagramma di Gantt senza prima aver definito un piano di mitigazione dei rischi che integri le dimensioni QCDP (Qualità, Costo, Tempi, Prestazioni). | Consente di scoprire bisogni latenti non espressi. | Obbliga l’azienda a minimizzare i rischi economici e di immagine verso il proprio mercato. |
Non si gestisce un progetto complesso con strumenti complessi. La complessità va suddivisa per essere gestita più facilmente con strumenti semplici. | Evita l’aggiunta di attività una volta che il progetto è stato avviato. | Porta a rimettere in discussione le scelte fatte per gli strumenti utilizzati. |
Solo le attività che coinvolgono almeno due parti devono essere monitorate regolarmente. | Il project manager e i membri del team si concentrano maggiormente sul percorso critico e sulle attività più delicate. | Obbliga i manager di funzione a gestire localmente le attività specifiche al loro ambito professionale. |
Il tempo rimanente per completare un’attività conta più del tempo consumato e del progresso della stessa. | Focalizza l’attenzione sul tempo rimanente a disposizione. | Forma le persone per affrontare questo profondo cambiamento di paradigma. |
La durata assegnata a un’attività non è un budget da consumare interamente. | Evita considerazioni sullo stato di avanzamento in percentuale (legge 90-90). | Richiede di tener conto di questo cambiamento nell’elaborazione di un Gantt standardizzato. |
È statisticamente improbabile che un’attività utilizzi esattamente il 100% del tempo assegnato: o si consuma di più o di meno. | Si utilizza solo il tempo necessario per completare l’attività e certificarla conforme. | Richiede di modificare la procedura per l’elaborazione del Gantt di progetto. |
Un’attività è considerata completata solo se è stata certificata conforme. | Obbliga i team a dichiarare come intendono certificare l’attività. Questo può richiedere un tempo inizialmente non previsto se non si è considerato l’impatto che la non conformità può avere sugli obiettivi del progetto. | Formare i team alle metodologie derivate dalla gestione della qualità nella lean production: •I 5 strumenti dell’auto-qualità. •La matrice dell’auto-qualità. •Il concetto “non accettare, non creare, non trasmettere” una non conformità. |
Un progetto complesso deve essere suddiviso in modo che una certificazione funzionale possa essere effettuata senza attendere la fase finale con il prodotto completamente definito, per individuare il prima possibile eventuali non conformità. | Evita una delle principali cause di fallimento, ovvero la correzione di errori scoperti all’ultimo minuto. | Integrare nei Gantt standard i tempi e i costi della certificazione (prototipazione, laboratori esterni, ecc.). |
Solo quando tutte le attività di tutte le parti coinvolte sono completate e certificate conformi è possibile passare alla fase (gate) successiva. | Focalizza maggiormente l’attenzione sulla qualità dei deliverable per ridurre la scoperta di errori nelle fasi successive del progetto. | Includere questa necessità nello standard di gestione dei progetti. |
Fare bene al primo colpo è il modo migliore per gestire il tempo e ottimizzare i costi. | Modifica il comportamento delle persone. | Con Synchroboard, questa attività è denominata “tripla chiave”. |
Qualsiasi sia la natura dei problemi, devono essere affrontati per essere risolti, non elusi. | Rompe il paradigma secondo cui “non c’è tempo per fare bene le cose” perché si devono correggere molti errori (legge di Hofstadter). | Integrare il concetto di intelligenza collettiva nei team. |
Non si struttura un progetto con l’intenzione di sacrificare uno degli elementi del triangolo d’oro (qualità, costi, tempi). | La risoluzione dei problemi relazionali crea un clima di fiducia, favorendo l’emergere dell’intelligenza collettiva. | Formare i team sull’intelligenza emotiva. |
Il software non deve funzionare in modalità “pilota automatico”. Sono sempre le persone a mantenere il controllo e la comprensione di ciò che accade. | In modo controintuitivo, questo concetto facilita la comprensione del progetto, ovvero il punto in cui ciascun membro del team è arrivato in relazione ai progressi degli altri. | La risoluzione dei problemi organizzativi migliora le prestazioni delle squadre. |
L’intelligenza collettiva rappresenta la forma più elevata di performance operativa. | Maggiore efficienza nel progetto. | La risoluzione dei problemi tecnici è facilitata dall’implementazione di un processo di arbitraggio. |
⚠️ Nessun post disponibile.
PARTNERSHIP
Condividere punti di vista su sfide comuni stimola la creatività e porta spesso a soluzioni semplici ed efficaci. Di fronte alle difficoltà legate alla sopravvivenza e all’evoluzione, le aziende, spesso sotto pressione per la mancanza di tempo, tendono a scegliere soluzioni standardizzate, guidate dall’abitudine piuttosto che da un’analisi realmente adeguata ai propri bisogni.
Crediamo che i partner abbiano un ruolo essenziale nel ribaltare questa tendenza. Il loro contributo va oltre la semplice promozione delle nostre soluzioni: arricchiscono il nostro approccio condividendo le loro esigenze e i loro suggerimenti.
Questa collaborazione è pensata per creare un valore reciproco, vantaggioso per Synchroboard, i partner e i clienti. Per questo, abbiamo sviluppato diversi programmi adatti ai diversi livelli di competenza tecnica e di coinvolgimento dei partner. Questi programmi spaziano dal collegamento con potenziali clienti qualificati fino alla gestione completa dell’implementazione.
Offriamo inoltre un programma di formazione con certificazione, pensato per i partner che desiderano rafforzare le loro competenze e massimizzare il loro impatto.
Profili di partnership
Referral
- Realizza la promozione.
- Stabilisce il contatto con il prospect.
- Non partecipa al processo di vendita.
Reseller
- Realizza la promozione e la vendita con il nostro supporto.
- E' assistito tecnicamente su richiesta.
Integrator
- Realizza la promozione, la vendita e l'erogazione in autonomia.
- Eroga solo servizi standard.
Business Developper
- Realizza l'erogazione e il supporto presso clienti identificati.
- Partecipa allo sviluppo di nuove soluzioni.
FAQ
Sicurezza dei dati
Quale è il livello di sicurezza per il cloud selezionato?
SB: Abbiamo scelto Google Cloud Platform (GCP) per la sua grande sicurezza sia come cybersecurity che come salvaguardia. GCP garantisce i massimi standard europei in termini di sicurezza:
- ISO27001 per la protezione e sicurezza dei dati, ISO27017 per la sicurezza cloud
- ISO27018 per la sicurezza dei dati in Cloud
Interfaccia con app esistenti
Quali dati sono da importare in Synchro board™?
SB: gli elementi da riportare nella app sono quelli solitamente utilizzati per definire il gantt:
- data inizio progetto
- Milestones
- tasks
- ente
- assignee
- le date di inizio e fine di ogni task
- la durata
- i colori pre definiti
dopodiché, Synchroboard™ li elabora per definire gli elementi visivi utili per l’ecosistema dove evolve.
I dati elaborati dentro a Synchro board possono essere esportati nella app originaria?
La app iniziale serve all’ellaborazione del gantt del progetto. Dopodiché, non c’è più nessun valore aggiunto ritornare verso la app originaria. Pertanto, questa funzione non è prevista.
Codice source
Cosa succede se l’azienda proprietaria e/o la software house falliscono?
SB: Il source code è messo in sicurezza in Github ed è accessibile per tutti i clienti registrati in caso di fallimento della struttura esterna.
GitHub è una piattaforma di sviluppo collaborativa basata su Git, un sistema di controllo di versione distribuito. Permette a sviluppatori e team di gestire, collaborare e condividere il codice sorgente per progetti software. GitHub è una delle piattaforme più popolari per progetti open-source e commerciali, offrendo strumenti potenti per il controllo delle versioni, la gestione dei progetti e la collaborazione.
Assistenza tecnica
Come viene organizzato il supporto tecnico?
SB: Il supporto tecnico include tutte le richieste di rapida risoluzione, tutti i bug di sistema ed eventuali errori non riconducibili al cliente
Per i clienti che vogliono il massimo dell’assistenza con un canone aggiuntivo garantiamo anche il supporto tecnico tramite telefono.
L’abbonamento prevede un intervento in 24h dall’apertura del ticket.
Quanto costa l’aggiornamento della app?
l’aggiornamento è integrato nel prezzo della licenza pertanto, non costa nulla in più
Utilizzo dell'app
quante persone possono interagire in concommitanza sulla piattaforma?
SB: la piattaforma è prevista con una funzionalità di “collaborative editing” in tempo reale. Pertanto, non vi sono limiti di persone
Personalizzazione
è possibile avere una personalizzazione totale della app, con il brand e il chart code aziendale?
SB: Come è stato progettato Synchro board™, è possibile fare una customization molto facilmente
è possibile adattare la struttura della app alle esignze di gestione di progetto che abbiamo definito?
SB: attraverso un menù, è possibile parametrare la struttura del board (time line variabile) come i colori degli enti o degli attendee. Gli altri componenti come i cartellini non sono parametrabili se non tramite una modifica del code
Aggiunto di tasks e milestones
Di quale flessibilità Synchro board™ dispone dopo avec fatto l’import del gantt se il progetto subisce delle modifiche?
SB: Synchro board permette l’aggiunta di ulteriori milestones o task.
Gestione della qualità
Cosa c’entra la qualità con la gestione dei progetti?
SB: La mancata qualità influisce sulla prevedibilità della data di consegna nonché sul costo del progetto, del prodotto e in futuro, dell’avviamento in produzione.
Per tutti questi motivi, la qualità fa parte integrante dell’ecosistema Synchro board™ come lo è nel modello di Toyota Production System e Toyota Product Development System ai quali si riferisce Synchro board™
