4. Monitoraggio e controllo (Monitoring & Controlling)

Avviene in parallelo all'esecuzione: misura l'avanzamento, distingue il lavoro fatto dal valore prodotto, e corregge la rotta prima che gli scostamenti diventino irrecuperabili.

Obiettivi

• Confrontare l'andamento reale con la baseline di piano
• Distinguere quanto è stato fatto da quanto valore è stato prodotto
• Decidere se e quando intervenire per riallineare
• Gestire formalmente i change request
• Mantenere il controllo su scope, tempi, costi e qualità

La baseline: il riferimento contro cui misurare

Senza una baseline non c'è monitoraggio: c'è solo osservazione. La baseline è la versione approvata e congelata del piano contro cui si confronta tutto ciò che accade.

Lo standard PMBOK ne identifica tre, integrate nella Performance Measurement Baseline (PMB):

• Scope baseline — WBS approvata, deliverable previsti
• Schedule baseline — date di start/end per ogni attività e milestone (vedi Gantt)
• Cost baseline — distribuzione dei costi nel tempo (budget temporizzato)

⚠ Le baseline non si toccano durante l'esecuzione: si modificano solo attraverso un change request approvato. Se cambi la baseline ogni volta che vai in scostamento, smetti di scostarti — ma non hai più un riferimento.

Lavoro fatto ≠ valore prodotto

È la distinzione più importante e più trascurata del monitoraggio.

"Quanto è stato fatto" è quanto lavoro è stato consumato: ore registrate, task chiusi, righe di codice scritte, riunioni tenute. È un dato di input.

"Quanto valore è stato prodotto" è quanto deliverable utile è stato consegnato: feature funzionanti, parti dell'opera fisica completate, milestone superate. È un dato di output.

Le due cose non coincidono.

Esempio concreto

Settimana 4 di un progetto di 8. Pianificato: il 50% del lavoro dovrebbe essere completato.

• Stato lavori: 60 task chiusi su 100. Sembra che tu sia al 60%, sopra il piano.
• Stato valore: di quei 60 task, 20 erano rework su cose già fatte (zero valore nuovo), 10 erano riunioni di allineamento (zero valore), 30 hanno consegnato deliverable utili — ovvero 30% del valore totale.

Sei al 30% di valore prodotto, non al 60%. Il piano dice 50%. Sei in ritardo del 40% rispetto al previsto, ma il "dashboard task chiusi" raccontava l'opposto.

Perché succede

• Rework non tracciato — lavoro che ripaga un errore precedente, non crea valore nuovo
• Task di processo — standup, riunioni di allineamento, scrittura di status report
• Lavoro nascosto — spike, ricerca, debugging non pianificato
• Definition of Done debole — si chiudono task "fatti al 90%" che restano problemi aperti
• Scope creep silenzioso — nuovi task aggiunti senza change request

Earned Value Management (EVM)

Per leggere lo stato a un istante T senza confondere lavoro e valore, l'Earned Value Management confronta tre grandezze (in euro o in giornate-persona):

• PV — Planned Value — quanto valore avresti dovuto aver prodotto a T, secondo la baseline. È la "curva del piano".
• AC — Actual Cost — quanto hai effettivamente speso (o quante ore hai bruciato) per arrivare a T.
• EV — Earned Value — quanto valore hai realmente prodotto a T, valutato col costo originariamente pianificato.

Esempio

Progetto da 100k€, 8 settimane. Al termine della settimana 4:

Diagnosi: hai speso più del piano (AC > PV) e prodotto molto meno (EV < PV). Il classico progetto in difficoltà.

Calcolatore interattivo

Modifica i quattro input per simulare il tuo progetto. Gli indici si aggiornano in tempo reale, con codice colore: verde = in linea, giallo = scostamento serio (sotto 0.90), rosso = crisi (sotto 0.80).

Reset esempio

PVPlanned Value — pianificato a TACActual Cost — speso a TEVEarned Value — prodotto a TBACBudget At Completion — totale di piano

Indici di performance

SPI

0.60

Schedule · Crisi

CPI

0.55

Cost · Crisi

SV

−20k€

Schedule Variance · EV − PV

CV

−25k€

Cost Variance · EV − AC

Forecasting al termine

EAC

183,3k€

Estimate At Completion · BAC / CPI

ETC

128,3k€

Estimate To Complete · EAC − AC

VAC

−83,3k€

Variance At Completion · BAC − EAC

Indici di performance: SPI e CPI

I tre numeri sopra si riassumono in due indici:

• SPI (Schedule Performance Index) = EV / PV — efficienza temporale
• CPI (Cost Performance Index) = EV / AC — efficienza dei costi

Lettura:

Soglie indicative per l'allarme:

• SPI < 0.90 o CPI < 0.90 — scostamento serio, intervenire
• SPI < 0.80 o CPI < 0.80 — crisi, escalation allo sponsor

Nell'esempio sopra: SPI = 30/50 = 0.60, CPI = 30/55 = 0.55. Entrambi sotto 0.80 — situazione da gestire formalmente.

Variance: di quanto sei fuori

Le stesse informazioni in forma assoluta (in euro):

• SV (Schedule Variance) = EV − PV
• CV (Cost Variance) = EV − AC

Se negative, sei in scostamento sfavorevole. Nell'esempio: SV = 30 − 50 = −20k€, CV = 30 − 55 = −25k€.

KPI principali

Quattro famiglie di indicatori da monitorare in parallelo, per non guardare solo il dito (tempi/costi) e perdere la luna (qualità/percezione).

1 · Performance — SPI, CPI

Misurano l'efficienza con cui stai trasformando piano in valore. Definiti sopra, si calcolano dai dati EVM. Sintetici: un solo numero ciascuno per tempi e costi.

2 · Scostamento — SV, CV

Misurano in valore assoluto quanto sei fuori. Utili per dimensionare l'intervento — un CPI di 0.50 su un progetto da 10k vale 5k da recuperare, un CPI di 0.95 su 10M ne vale 500k.

3 · Qualità dei deliverable

EVM non misura la qualità. Un progetto può chiudere on-time e on-budget consegnando deliverable difettosi — fallisce comunque. KPI tipici:

• % deliverable accettati al primo round — quanti passano il sign-off senza rework. Soglia tipica: > 80%
• Difetti per deliverable (o per 1000 LOC nel software) — densità di bug per unità di output
• Tasso di rework — quante ore sul totale vanno in correzioni di lavoro già "chiuso". Soglia: > 15% = problema strutturale di qualità
• % deliverable in Definition of Done — il filtro più semplice e più efficace
• Severità dei difetti residui — non basta contarli, vanno pesati (blocker / major / minor)

4 · Soddisfazione degli stakeholder

Un progetto può essere on-time, on-budget, on-quality e fallire lo stesso, se gli stakeholder non riconoscono il valore o non si sentono ascoltati. KPI percettivi:

• Sponsor satisfaction — survey breve trimestrale (1-5 su comunicazione, allineamento, valore atteso)
• Stakeholder NPS interno — "Quanto raccomanderesti questo progetto come modo di lavorare?", scala da −100 a +100
• Engagement nelle review — % stakeholder che partecipano e danno feedback attivo
• Tempi di risposta dello sponsor — se aumentano, il progetto sta perdendo rilevanza in agenda
• Conflitti aperti — issue interpersonali o di scope contestati ancora non risolti

Vedi Success Criteria per definire questi KPI a inizio progetto, e Comunicazione per gestire le percezioni in modo non passivo.

Decidere se intervenire

Un singolo punto fuori baseline non è ancora un problema. Quello che conta è la tendenza.

Tre domande per ogni scostamento:

1. È un punto isolato o un trend? Una settimana sotto soglia è rumore; tre settimane sotto sono un segnale.
2. Lo scostamento è dentro la varianza tollerabile? Definisci una soglia (es. ±5% per CPI/SPI) prima dell'inizio del progetto, e intervieni solo oltre la soglia.
3. La causa è strutturale o congiunturale? Una persona in malattia è congiunturale. Una stima sistematicamente sbagliata è strutturale e richiede revisione del piano.

Vedi Root Cause Analysis per il "perché" dietro uno scostamento ricorrente, e Nemawashi per preparare un eventuale change request prima del Change Control Board.

Forecasting: dove finiremo

Con gli indici si può anche proiettare il futuro, assumendo che il pattern di efficienza attuale continui:

• BAC (Budget At Completion) — il budget totale pianificato
• EAC (Estimate At Completion) = BAC / CPI — stima del costo totale finale
• ETC (Estimate To Complete) = EAC − AC — quanto resta da spendere
• VAC (Variance At Completion) = BAC − EAC — sforamento (o risparmio) finale atteso

Nell'esempio: BAC = 100k, CPI = 0.55 → EAC = 100 / 0.55 = 182k€. Stai correndo verso uno sforamento dell'82% se non cambi nulla. È il numero che deve far suonare l'allarme.

Altre tecniche di controllo

• Status report periodici allo sponsor — vedi il template Status Report
• Change Control Board — valutazione formale delle modifiche di scope, tempi o costi
• Audit di qualità — verifiche a campione su deliverable, processi, documentazione
• Risk review — il Risk Register si rivede ad ogni status report, non solo all'inizio
• Burn-down / Burn-up chart — in contesti Agile, alternativa visuale e più semplice alle curve EVM

Regola d'oro: i problemi vanno scoperti presto e gestiti subito. Il costo di una correzione cresce esponenzialmente col tempo.

Collegamenti

• Esecuzione — fase parallela
• Definition of Done — la prima difesa contro il divario lavoro/valore
• Risk Register — da aggiornare continuamente in questa fase
• RBS — la tassonomia con cui scoprire i rischi prima di registrarli
• Nemawashi — usalo prima di portare un change request al Change Control Board
• Eisenhower Matrix — per decidere su quali scostamenti intervenire subito
• Comunicazione — principi di reporting e gestione stakeholder
• Status Report — template settimanale/bisettimanale
• Root Cause Analysis — per scostamenti significativi e ricorrenti