Controllo

Aspetti generali

Il controllo riguarda il monitoraggio delle prestazioni rispetto alle baseline approvate, l’aggiornamento dei documenti di consegna e la esecuzione di azioni correttive quando necessario. Il controllo è necessario per tutta la durata del ciclo di vita, ma la spiegazione che segue è mirata principalmente alla funzione di controllo del processo di consegna.

Le finalità del controllo sono:

  • Rivedere le prestazioni rispetto alle baseline;
  • Valutare l’effetto delle prestazioni attuali sui piani futuri;
  • Intraprendere azioni quando necessario per realizzare i traguardi della pianificazione o concordarne la revisione.

Le tecniche di controllo rientrano in una delle tre categorie generali: cibernetico, go/no go ed ex-post.

Il controllo cibernetico fa parte della gestione quotidiana del lavoro; il controllo go/no go è applicato nei punti decisionali chiave del ciclo di vita; il controllo ex-post riguarda l’apprendimento dall’esperienza che consente il miglioramento continuo del project, programme e portfolio management.

Il controllo cibernetico si focalizza sul processo di consegna.

Il controllo go/no go si focalizza sulle revisioni fra una fase e l’altra del ciclo di vita e sul processo di gestione dei limiti.

Il controllo ex-post riguarda principalmente il processo di chiusura con un collegamento all’attività di revisione delle lezioni precedenti propria del processo di identificazione.

Il termine ‘cibernetico’ deriva dal Greco, ove significa ‘timoniere’ ed infatti un project, programme e portfolio manager usa il controllo cibernetico per ‘indirizzare’ il progetto, programma o portfolio giorno per giorno. Il lavoro del project, programme e portoflio manager è, in senso stretto, il primo controllo cibernetico mentre la relazione fra il project, programme e portoflio manager e lo sponsor è il controllo cibernetico di secondo livello.

L’elemento chiave del controllo cibernetico è il feedback. Un sistema viene monitorato, viene fornito un feedback e comparato ad una regola. Si eseguono quindi le azioni opportune per allineare il sistema alla regola. Nell’ambito della gestione dei progetti, programmi e portfolio la regola è rappresentata dai piani baseline; il monitoraggio fornisce il feedback riguardo alle prestazioni e il project, programme o portfolio manager appronta le azioni per conformarsi ai piani baseline.

Le tolleranze sono deviazioni accettabili rispetto alle baseline. Se la prestazione supera le tolleranze concordate, o si prevede che le superi, questa si considera come una questione da scalare allo sponsor. Lo sponsor ed il manager si accorderanno quindi in ordine alla appropriata azione correttiva da intraprendere. Se il risultato è un cambiamento importante del lavoro, allora si può concordare una nuova baseline rispetto alla quale saranno monitorate le prestazioni future.

Il controllo go/no viene utilizzato nei punti di decisione chiave posizionati lungo il ciclo di vita. Questi si trovano di solito alla fine di una fase, stadio o tranche del lavoro e comportano una revisione approfondita di ciò che è stato realizzato.

In questi punti decisionali, lo sponsor tiene conto delle informazioni disponibili e decide se proseguire con il lavoro rimanente. In casi estremi, un progetto, programma, o eventualmente addirittura un portfolio, può essere chiuso perché non appare ulteriormente giustificabile.

Il controllo ex-post è esclusivamente retrospettivo. Esso riguarda l’apprendimento dall’esperienza per mezzo, ad esempio, di revisioni post-progetto o post-programma.

A seconda della natura e della complessità di ciò che deve essere controllato sono utilizzati metodi specifici di controllo. Per esempio:

Un metodo comune per raffigurare le prestazioni relative ai tempi sono i rapporti RAG (Rosso, Giallo, Verde, in inglese Red, Amber, Green). La condizione verde significa che la prestazione ricade all’interno delle tolleranze e si prevede che vi rimanga. Quella gialla è all’interno delle tolleranze, ma si prevede che le superi. Il colore rosso indica infine che la prestazione ha già superato le tolleranze.

Tutte le sei componenti della consegna devono essere controllate. Alcune tecniche, come il controllo dei cambiamenti e il controllo di qualità, riguardano nello specifico un singolo elemento, cioè l’ambito. Altre, come la gestione dell’Earned Value (letteralmente valore realizzato), uniscono più elementi (vale a dire tempi e costi).

Nel contesto della creazione dei prodotti, il controllo dell’ambito è in effetti la stessa cosa del controllo della qualità. Questo ha la più diversa gamma di tecniche, che coprono l’ispezione, il collaudo e le misurazioni. Questo tipo di controllo verifica che i deliverable siano conformi alle specifiche, siano adatti allo scopo e soddisfino le aspettative degli stakeholder. Fra gli esempi di questo tipo di tecniche si possono annoverare: la frantumazione di campioni di calcestruzzo utilizzato per le fondamenta di un edificio, la revisione delle interfacce utente delle applicazioni informatiche, l’esecuzione di radiografie delle saldature dello scafo di una nave e l’osservazione dei risultati di script test durante lo sviluppo di una nuova componente software. L’ispezione spesso produce dati empirici, e strumenti come i diagrammi di dispersione, le carte di controllo, i diagrammi di flusso e i diagrammi di causa ed effetto aiutano tutti a controllare la qualità dei deliverable.

I controlli si possono altresì classificare come basati sugli eventi o basati sul tempo. I controlli go/no-go ed ex post sono basati sugli eventi, i quali a loro volta si basano sul ciclo di vita (la conclusione di una fase, stadio o tranche) o sul feedback (quando sono superate le tolleranze).

I controlli basati sul tempo riguardano più tipicamente il controllo cibernetico e comprendono i rapporti settimanali o mensili, le revisioni periodiche o le riunioni sullo stato di avanzamento ad intervalli regolari. È responsabilità del project, programme o portfolio manager raccogliere i dati sullo stato di avanzamento e preparare i rapporti, evidenziando le aree che richiedono attenzione. In alcuni casi questo lavoro sarà curato da una funzione di supporto, lasciando libero il manager di concentrarsi sul processo decisionale e sulla implementazione delle azioni correttive.

Nessun lavoro andrà avanti rigorosamente secondo il piano. Un buon piano conterrà voci riguardanti riserve di contingency e di gestione per ammortizzare gli effetti delle questioni. Alcune di queste riserve saranno sotto il controllo del project, programme e portfolio manager mentre altre sotto quello dello sponsor.

 

Progetti, programmi e portfolio

Il modo in cui i dati sullo stato di avanzamento sono raccolti e riportati dipenderà dalle tecniche di pianificazione usate per lo sviluppo della baseline.

In un progetto piccolo, la baseline dei tempi può essere stata preparata e presentata come un semplice diagramma di Gantt, nel qual caso l’avanzamento del calendario di progetto può essere mostrato come un grafico di slittamento.

Quando i progetti diventano più complessi e le tempistiche sono basate su diagrammi reticolari, questi modelli possono essere usati per tecniche di controllo quali la gestione dell’earned value (EVM) o la catena critica.

Più il metodo di registrazione e di analisi dello stato di avanzamento è sofisticato, più accurate saranno le previsioni relative alle prestazioni future. Per esempio, se un semplice grafico di slittamento basato sull’analisi del percorso critico potrebbe non prevedere un futuro sforamento delle tolleranze, una previsione basata sulla gestione dell’earned value mostrerà quello sforamento. Questo è il motivo per cui l’analisi del percorso critico suppone che i tassi di avanzamento futuri saranno conformi al piano originale mentre l’EVM suppone che i tassi di avanzamento futuri saranno in linea con quelli storici.

Mentre i sistemi di controllo dei progetti tradizionali tendono a focalizzarsi in primo luogo su tempi e costi, i progetti agili si focalizzano sull’ambito. Nell’ambiente agile i prodotti sono realizzati in ‘sprint’ brevi di durata predeterminata (timebox) e tecniche di controllo come la kanban appaiono più appropriate per il controllo del flusso del lavoro. Sopra un certo numero di sprint, i grafici burn down (burn down chart) rappresentano spesso un modo di illustrare lo stato di avanzamento migliore dei diagrammi di Gantt.

Nei programmi e nei portfolio ci saranno molteplici livelli di controllo cibernetico. Un project manager di un progetto raccoglierà ad intervalli regolari il feedback sullo stato di avanzamento e adotterà quando necessario le azioni correttive. Se il progetto fa parte di un programma, il programme manager può assumere il ruolo di sponsor del progetto e fornire il secondo livello di controllo.

Nel caso in cui il programma faccia parte di un portfolio allora ci sarà una relazione del tutto analoga che introduce un terzo livello di controllo.

Questo non vuol dire che ci sono tre persone a controllare il progetto su base giornaliera. Ciascun livello di controllo ha a che fare con un diverso grado di dettaglio ed ha una differente ampiezza di controllo. All’interno dei progetti più grandi o dei programmi o portfolio, il sistema di controllo (esposto se possibile in un piano di gestione del controllo) deve spiegare, per ciascun livello, come:

  • saranno fissate le tolleranze;
  • saranno raccolti e riportati i dati sullo stato di avanzamento;
  • saranno monitorate le interdipendenze fra piani diversi;
  • saranno consolidate verso l’alto le informazioni sullo stato di avanzamento;
  • saranno comunicate verso il basso le decisioni.

Quando il lavoro diviene più complesso è di vitale importanza focalizzarsi sugli indicatori chiave di prestazione (key performance indicators – KPI) piuttosto che monitorare tutto nei minimi dettagli. Quando la complessità aumenta e i manager hanno bisogno di informazioni tempestive ed accurate per prendere decisioni ben fatte sarà indispensabile il ruolo di un PSO (ufficio di supporto al progetto, programma o portfolio).

 


Grazie a E-quality Italia e a Project Management Europa per la traduzione

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
26th September 2014Reference to control techniques for agile projects added
Torna in cima