Appunti Uni

09. Monitoring and Controlling Process Group

11 minuti

09. Monitoring and Controlling Process Group

Slide PDF

Indice

Obiettivo del Monitoring and Controlling

Definizione

Il Monitoring and Controlling Process Group raccoglie strumenti, template e processi usati per monitorare l’avanzamento del progetto, controllare gli scostamenti e intervenire quando il progetto si allontana da quanto pianificato.

In pratica: dopo aver pianificato il progetto, non basta attendere la fine per capire se tutto e andato bene. Bisogna osservare periodicamente cosa sta succedendo, confrontarlo con la baseline e decidere se servono azioni correttive.

I temi principali del modulo sono:

  • sistema di reporting;
  • strumenti visuali di reporting;
  • Scope Bank;
  • Issues Log;
  • Project Status Meetings;
  • Problem Escalation Strategy;
  • approvazione alla chiusura del progetto.

Come rispettare la schedula di progetto

Per mantenere il progetto entro i binari stabiliti in fase di pianificazione, le slide indicano alcune regole operative:

  • tenere daily team meetings;
  • completare i task il prima possibile;
  • riportare eventuali problemi il prima possibile;
  • non essere vittima delle creeps;
  • non provare a indovinare: nel dubbio bisogna fare domande;
  • applicare il principio “good enough is good enough”;
  • rispettare i requisiti, senza andare oltre i requisiti per evitare over-design;
  • essere aperti e onesti con i colleghi del team.

Punto critico

Il controllo non serve solo a produrre report: serve soprattutto a far emergere presto problemi, ritardi e scostamenti, quando e ancora possibile intervenire.

Sistema di Reporting

Definizione

Un Progress Reporting System e un sistema di supporto usato per produrre informazioni sullo stato di avanzamento del progetto.

In pratica: e il meccanismo con cui il project manager raccoglie dati, li organizza e li comunica al team o al senior management. Deve essere abbastanza completo da essere utile, ma non cosi pesante da diventare un lavoro aggiuntivo controproducente.

Caratteristiche di un Progress Reporting System

Un sistema di reporting efficace dovrebbe:

  • fornire informazioni tempestive, complete e accurate sullo stato di avanzamento;
  • non richiedere un overhead eccessivo in termini di effort;
  • essere intuitivo e facilmente accettabile dal team di progetto e dal senior management;
  • funzionare come early warning, cioe come allarme tempestivo quando ci sono problemi nel rispettare il piano.

Regola pratica

Il reporting e utile se rende visibile lo stato del progetto senza assorbire troppo tempo. Se il costo del reporting supera il valore dell’informazione prodotta, il sistema diventa controproducente.

Tipi di Project Status Report

Le slide distinguono cinque tipi di Project Status Report.

Current Period Reports

Coprono solo i periodi piu recenti del progetto. Evidenziano le attivita completate piu rilevanti e le eventuali variazioni rispetto al piano. Possono includere anche le ragioni degli scostamenti e le misure correttive corrispondenti.

Esempio: report settimanale che mostra cosa e stato completato nella settimana corrente, quali task sono in ritardo e quali azioni sono state avviate.

Cumulative Reports

Coprono l’intera storia del progetto. Sono efficaci per mostrare i trend dell’avanzamento, per esempio tracciando tutti gli scostamenti rispetto al pianificato e osservando se la situazione migliora o peggiora.

In pratica: non guardano solo l’ultima fotografia, ma l’evoluzione del progetto nel tempo.

Exception Reports

Sono rivolti al senior management e si concentrano sugli scostamenti rispetto al piano, sulle cause e sulle misure correttive da intraprendere. Sono molto sintetici e possono prevedere allegati con dettagli aggiuntivi.

Note

Un exception report non descrive tutto il progetto: porta all’attenzione del management solo cio che richiede decisioni o attenzione.

Stoplight Reports

Sono una variante applicabile a current period, cumulative ed exception reports. Usano un supporto visuale sintetico per comunicare rapidamente lo stato del progetto:

  • verde: tutto procede come pianificato;
  • giallo: ci sono stati scostamenti, ma la situazione e sotto controllo;
  • rosso: la situazione e fuori controllo.

Variance Reports

Si concentrano sugli scostamenti rispetto al pianificato. Per ogni attivita e periodo confrontano quanto previsto con lo stato di avanzamento effettivo. Le informazioni possono essere presentate con tabelle o grafici.

Informazioni da aggiornare

Per alimentare il sistema di reporting bisogna aggiornare periodicamente informazioni coerenti:

  • periodo da monitorare e momento esatto in cui aggiornare i dati;
  • lavoro effettivamente svolto nel periodo;
  • dati storici sull’eseguito nei periodi precedenti;
  • stime sulle attivita rimanenti;
  • date di inizio e fine delle attivita iniziate o terminate;
  • giorni gia impegnati e giorni previsti per completare ciascuna attivita;
  • risorse consumate e rimanenti;
  • percentuale di completamento.

Strumenti di Reporting Visuale

Definizione

Gli strumenti di reporting visuale rappresentano graficamente lo stato del progetto, rendendo piu immediata la lettura di avanzamento, ritardi, scostamenti e trend.

In pratica: un grafico ben scelto permette di capire piu velocemente se il progetto e in linea con il piano, se sta peggiorando o se richiede interventi.

Gantt Chart e Stoplight Report

Il Gantt Chart Project Status Report mostra le attivita sulla linea temporale, permettendo di confrontare pianificazione e avanzamento.

Lo Stoplight Report sintetizza lo stato con tre condizioni:

  • progetto secondo piano;
  • progetto con problema, ma con un Get Well plan in atto;
  • progetto in fallimento, con intervento richiesto.

Esempio

Se un progetto ha uno scostamento ma esiste gia un piano di recupero credibile, lo stato puo essere giallo. Se invece lo scostamento non e controllato e richiede decisioni esterne, lo stato diventa rosso.

Milestone Trend Chart

Il Milestone Trend Chart e associato ai cumulative reports e mostra l’andamento delle milestone nel tempo.

In pratica: consente di osservare se le milestone tendono a spostarsi in avanti, restare stabili o anticipare. La sua utilita principale e rendere visibili i trend, non solo il singolo ritardo puntuale.

Earned Value Analysis

Definizione

L’Earned Value Analysis (EVA) e un approccio per misurare le performance del progetto confrontando il lavoro effettivamente svolto con il lavoro previsto dal piano.

L’Earned Value misura il valore del lavoro svolto usando metriche definite:

  • in termini economici, per esempio Euro o Dollari;
  • in termini di tempo/uomo, per esempio giorni/uomo o mesi/uomo.

Il lavoro effettivo viene confrontato con il lavoro pianificato per determinare scostamenti rispetto alla schedula e ai costi previsti.

Limite dell'Earned Value

Le metriche economiche o di tempo/uomo non sono ideali: mostrano l’evoluzione storica di costi ed effort, ma non spiegano le motivazioni degli scostamenti. Per questo, da sole non bastano per formulare previsioni affidabili sul futuro.

Curve di avanzamento

Le slide mostrano tre situazioni tipiche:

  • Standard S-Curve: curva di avanzamento con crescita progressiva, fase centrale piu intensa e stabilizzazione finale;
  • Aggressive Curve: andamento senza ramp-up e senza tempo di apprendimento;
  • Curve to Avoid: situazione in cui e passato il 70-80% del tempo, ma e stato completato circa il 30% del lavoro.

La curva da evitare segnala un rischio evidente: molto tempo e stato consumato, ma il progetto ha prodotto poco avanzamento misurabile.

Modi per misurare l’Earned Value percentuale

Le slide indicano quattro metodi:

  • 100-0;
  • 0-100;
  • 50-50;
  • proporzione dei task completati.

In pratica: i metodi stabiliscono quando attribuire valore al lavoro in corso. Per esempio, con la proporzione dei task completati, se 10 task sono completi su 14, il valore guadagnato e legato al rapporto 10/14.

PV, EV e AC

Nella misurazione dell’Earned Value compaiono tre grandezze:

  • PV (Planned Value): valore pianificato del lavoro;
  • EV (Earned Value): valore del lavoro effettivamente guadagnato/completato;
  • AC (Actual Cost): costo effettivo del lavoro svolto.

Il confronto tra queste grandezze permette di leggere:

  • Schedule Variance: scostamento rispetto alla schedula;
  • Cost Variance: scostamento rispetto ai costi.

Indici SPI e CPI

Definizione

Gli indici SPI e CPI sintetizzano le performance del progetto rispetto a schedula e costi.

Schedule Performance Index (SPI):

SPI = EV / PV

Misura come il progetto sta performando rispetto a quanto pianificato.

Cost Performance Index (CPI):

CPI = EV / AC

Misura come i costi del lavoro svolto evolvono rispetto ai costi stimati in fase di pianificazione.

Interpretazione indicata nelle slide:

  • valori < 1: oltre il budget o in ritardo rispetto alla schedula prevista;
  • valori > 1: sotto il budget o in anticipo rispetto alla schedula prevista.

Scope Bank

Definizione

La Scope Bank e un deposito di tempo usato per gestire richieste di modifica dello scope durante il progetto.

In pratica: si mette da parte una quota iniziale del tempo complessivo, per esempio 5-10%, da usare quando bisogna processare e integrare modifiche allo scope.

Le regole indicate nelle slide sono:

  • predisporre un deposito iniziale pari a una percentuale del tempo complessivo necessario;
  • decidere se usare tempo/uomo o durata;
  • prelevare dalla Scope Bank il tempo necessario per gestire una richiesta di modifica dello scope;
  • aggiungere tempo alla Scope Bank rimuovendo funzionalita o feature e depositando il tempo che sarebbe servito per svilupparle;
  • aggiungere alla Scope Bank eventuale tempo risparmiato nell’esecuzione di attivita;
  • far ridefinire continuamente al committente le priorita del contenuto della Scope Bank.

Note

La Scope Bank rende esplicito che le modifiche allo scope hanno un costo. Se entra qualcosa di nuovo, bisogna consumare tempo disponibile o rimuovere qualcos’altro.

Issues Log

Definizione

L’Issues Log e un documento dinamico che contiene tutti i problemi emersi durante il progetto, in particolare quelli non ancora risolti.

La risoluzione dei problemi riportati nell’Issues Log e importante per la continuazione e il successo del progetto. Inoltre, l’Issues Log diventa una preziosa fonte di dati storici.

Le informazioni che puo contenere sono:

  • ID Number;
  • Date logged;
  • descrizione del problema;
  • descrizione dell’impatto sul progetto se il problema non viene risolto;
  • proprietario del problema, cioe problem owner;
  • azione da intraprendere per risolvere il problema;
  • stato;
  • esito.

Esempio

Un task critico non puo partire per mancanza di una risorsa. L’Issues Log registra il problema, l’impatto sul progetto, il responsabile della risoluzione e l’azione prevista.

Project Status Meetings

Definizione

I Project Status Meetings sono riunioni periodiche usate per raccogliere dal team le informazioni necessarie a monitorare e controllare lo stato di avanzamento.

Devono essere effettuati con cadenza periodica, per esempio giornaliera o settimanale. Le slide evidenziano quattro domande guida:

  • chi dovrebbe partecipare?
  • quando si devono tenere?
  • qual e il loro scopo?
  • qual e il loro format?

Daily Status Meeting

Il 15-Minute Daily Status Meeting ha queste caratteristiche:

  • partecipa l’intero team oppure solo i task manager responsabili dei task in lavorazione;
  • solitamente e una riunione in piedi;
  • puo essere utile un facilitatore, anche scelto tra i partecipanti;
  • deve essere riportato sinteticamente lo stato di ciascun task;
  • include aggiornamento della Scope Bank;
  • include aggiornamento dell’Issues Log.

Per ciascun task si riporta se e:

  • in schedula;
  • in anticipo rispetto alla schedula, specificando di quanto;
  • in ritardo rispetto alla schedula, specificando di quanto e se serve aiuto.

Regola pratica

Il daily status meeting deve essere breve e orientato all’informazione utile. Non e il luogo ideale per risolvere problemi complessi: quelli possono richiedere un meeting dedicato.

Problem Management Meeting

Il Problem Management Meeting serve a trattare problemi specifici e coinvolge solo i membri del team interessati.

Le attivita previste sono:

  • concordare la definizione del problema;
  • concordare chi e il proprietario del problema;
  • fare brainstorming per la soluzione;
  • assegnare una priorita alle soluzioni individuate;
  • aggiornare l’Issues Log;
  • pianificare il prossimo meeting, se necessario.

Problem Escalation Strategy

Definizione

La Problem Escalation Strategy definisce come far salire un problema ai livelli decisionali appropriati quando non puo essere gestito efficacemente al livello corrente.

Le slide collegano la strategia di escalation a tre dimensioni di controllo:

  • scope and quality;
  • resource availability;
  • time and cost.

Nella definizione della strategia di risoluzione dei problemi si individuano tre livelli.

Project Manager-Based Strategies

Il project manager puo:

  • non richiedere nessuna azione se il problema si risolvera da solo;
  • esaminare le relazioni di dipendenza;
  • riassegnare le risorse.

Resource Manager-Based Strategies

Il livello resource manager-based riguarda la negoziazione di risorse aggiuntive.

Client-Based Strategies

Il cliente puo essere coinvolto per:

  • negoziare un approccio basato su rilasci multipli;
  • richiedere un’estensione della schedula;
  • richiedere una modifica di scope.

Gerarchia di escalation

L’escalation procede da interventi meno invasivi a interventi piu impattanti: usare slack, comprimere la schedula, riassegnare risorse, negoziare risorse aggiuntive, poi arrivare a rilasci multipli, estensione della schedula o modifica dello scope.

Approvazione alla Chiusura

Definizione

L’approvazione alla chiusura e il passaggio in cui, soddisfatti i criteri di accettazione della soluzione, il progetto puo entrare nella fase di closing.

Le slide formulano il principio in modo diretto: quando tutti i criteri previsti per l’accettazione della soluzione sono stati soddisfatti, il committente non puo che essere contento e il progetto puo entrare nella fase di chiusura.

In pratica: il monitoring and controlling accompagna il progetto fino al punto in cui e possibile dimostrare che i criteri di accettazione sono stati rispettati.

Prossimi Argomenti

Continueremo con:

Vista grafico

Link entranti