Monitor & Control in PM²: mantenere il progetto sotto controllo, non soltanto aggiornato
Tredicesimo articolo della serie “Imparare PM² attraverso un progetto”
Un progetto non è sotto controllo perché il Project Manager invia uno status report ogni venerdì. È sotto controllo quando il team confronta sistematicamente ciò che accade con ciò che era stato approvato, capisce gli scostamenti e decide azioni proporzionate.
In PM², Monitor & Control è un insieme di attività trasversali: accompagna il progetto dall’avvio alla chiusura. Non è quindi una fase successiva a Executing né un momento amministrativo.
L’idea essenziale
La logica è sempre la stessa:
- si definisce una baseline: piano, requisiti, costi, calendario, qualità e criteri di accettazione approvati;
- si misura la situazione reale;
- si valuta lo scostamento, i rischi e l’impatto;
- si agisce, si registra la decisione e si comunica agli interessati.
Senza baseline non si può parlare seriamente di “ritardo” o “fuori budget”: esiste solo una percezione.
Monitorare e controllare non sono sinonimi
| Attività | Domanda a cui risponde | Esempio |
|---|---|---|
| Monitorare | Dove siamo rispetto al piano? | Il rilascio beta è al 60%, mentre il piano prevedeva l’80%. |
| Controllare | Cosa facciamo per riportare il progetto entro limiti accettabili? | Riassegnare capacità, ripianificare una dipendenza o sottoporre un cambiamento al livello decisionale competente. |
Monitorare produce evidenza; controllare trasforma quell’evidenza in una decisione o in un’azione. Un report senza follow-up è monitoraggio incompleto, non controllo.
Cosa comprende Monitor & Control in PM²
PM² raggruppa le attività di gestione che mantengono il progetto governabile:
| Area | Cosa si verifica o si gestisce |
|---|---|
| Prestazioni | stato complessivo, previsioni, scostamenti e reportistica |
| Tempi e costi | avanzamento rispetto a schedule e budget; azioni correttive |
| Stakeholder | aspettative, coinvolgimento, comunicazione e resistenze |
| Requisiti e cambiamenti | tracciabilità, valutazione dell’impatto, approvazione e Change Log |
| Rischi | probabilità, impatto, risposta e aggiornamento del Risk Log |
| Issue e decisioni | problemi già avvenuti, owner, scadenze, escalation e Decision Log |
| Qualità e accettazione | conformità dei deliverable e criteri di accettazione |
| Transizione, business implementation e outsourcing | preparazione all’uso operativo, adozione e fornitori |
Non significa applicare tutte le pratiche con la stessa intensità. Il PM le adatta alla complessità e al rischio del progetto, senza perdere tracciabilità sulle decisioni importanti.
Il ciclo pratico di controllo
flowchart TD
A[Baseline approvata] --> B[Raccogli dati reali]
B --> C[Valuta scostamento e impatto]
C --> D{Entro tolleranza?}
D -- Sì --> E[Registra e comunica]
D -- No --> F[Correggi o proponi cambiamento]
F --> G[Decisione e aggiornamento controllato]
G --> E
Le tolleranze rendono il flusso sostenibile: il PM gestisce ciò che rientra nella propria delega; quando uno scostamento supera i limiti concordati, lo porta al ruolo o organo con l’autorità necessaria. Non si confonde l’escalation con lo scarico di responsabilità: il PM prepara analisi, opzioni e raccomandazione.
Change, risk e issue: la distinzione da ricordare
| Termine | Che cos’è | Esempio in Annotatio |
|---|---|---|
| Risk | Evento incerto che, se accade, può influire sul progetto. | Il provider delle notifiche push potrebbe cambiare policy prima del go-live. |
| Issue | Problema già avvenuto o presente. | Le notifiche Android non arrivano più su alcuni dispositivi. |
| Change | Richiesta di modificare un elemento già approvato del progetto. | Il cliente chiede che le prenotazioni ricorrenti entrino nel rilascio attuale, benché non fossero nello scope. |
La sequenza mentale corretta è: un rischio può materializzarsi e diventare un’issue; una change request può nascere per risolvere un’issue, ma non è automaticamente approvata.
Gestire un cambiamento: non basta dire sì
Una richiesta di cambiamento utile deve essere registrata e valutata prima della decisione. La valutazione considera almeno impatto su:
- scope e requisiti;
- tempi e dipendenze;
- effort e costi;
- qualità, sicurezza e rischi;
- benefici attesi e priorità.
Solo dopo l’approvazione il piano e le baseline pertinenti vengono aggiornati in modo controllato. Se ogni richiesta urgente entra direttamente nello sviluppo, non è agilità: è perdita di governo.
Il caso Annotatio: il report che porta a una decisione
Il piano per Prenotazioni Smart prevede il rilascio a fine giugno, con notifiche push, lista d’attesa e dashboard per il gestore. A metà giugno il PM rileva:
- la lista d’attesa è pronta;
- le notifiche push hanno un difetto su Android;
- il gestore chiede anche l’esportazione CSV delle presenze, non prevista nello scope;
- il test con due palestre evidenzia formazione insufficiente per i collaboratori.
La gestione corretta non è un unico “semaforo rosso”. È distinguere e trattare:
| Evidenza | Tipo | Azione |
|---|---|---|
| Difetto push Android | Issue | Owner tecnico, analisi della causa, scadenza e verifica della correzione. |
| Esportazione CSV | Change request | Stima dell’impatto; decisione su inclusione, rinvio o sostituzione di altra funzionalità. |
| Formazione insufficiente | Rischio per adozione/benefici, con evidenza emersa dal test | Aggiornare piano di business implementation e predisporre micro-formazione prima del go-live. |
Il PM aggiorna report e log; il PO/BM decide sulle priorità e sull’accettabilità dell’impatto business; lo SP valuta capacità e fattibilità della soluzione. Così lo stato del progetto diventa una base per decidere, non un bollettino.
Da non confondere
| Affermazione | Perché è errata |
|---|---|
| “Monitor & Control avviene dopo Executing.” | È trasversale: si applica durante l’intero ciclo di vita. |
| “Un issue è un rischio molto grave.” | No. Un issue è già reale; un rischio è incerto. Gravità e probabilità sono dimensioni diverse. |
| “Ogni richiesta del cliente è una change approvata.” | È una richiesta da analizzare e decidere secondo la governance. |
| “Il Change Log è solo burocrazia.” | Conserva motivazione, impatto, decisione e tracciabilità delle modifiche. |
Tre domande per fissarlo
- Quale baseline stai usando per dichiarare che un progetto è in ritardo?
- Quando uno scostamento deve essere gestito dal PM e quando richiede escalation?
- La richiesta ricevuta è un rischio, un’issue o una change request? Perché?
Flashcard
D: Che cosa fa Monitor & Control in PM²?
R: Confronta la situazione reale con le baseline, gestisce scostamenti, rischi, issue e cambiamenti, e supporta decisioni tempestive.
D: Qual è la differenza essenziale tra risk e issue?
R: Il risk è incerto e futuro; l’issue è presente o già avvenuto.
D: Cosa deve avvenire prima di incorporare una change nel piano?
R: Registrazione, analisi dell’impatto, decisione dell’autorità competente e aggiornamento controllato delle baseline.
Domanda in stile esame
Un fornitore comunica che una componente potrebbe non essere disponibile in tempo. Il PM registra l’informazione come issue e cambia subito la data di rilascio.
Qual è la correzione migliore?
Risposta: la possibile indisponibilità è innanzitutto un risk, perché non si è ancora verificata. Il PM deve valutarne probabilità, impatto e risposta; un cambiamento della baseline di rilascio richiede poi l’analisi e l’approvazione previste dalla governance.
Fonte
I concetti e le attività citati derivano dal capitolo Monitor & Control della PM² Methodology Guide 3.1 della Commissione europea.
Nel prossimo articolo entreremo nel Project Work Plan: come trasformare scope, deliverable, attività, stime e dipendenze in un piano realmente utilizzabile.