SAL che funzionano: cosa chiedere a ogni stato avanzamento

Nella maggior parte dei progetti il SAL è una call in cui il fornitore dice “tutto ok, procediamo” e il committente annuisce. Poi, tre settimane prima della consegna, “tutto ok” diventa “ci servono altri due mesi”. Un SAL fatto bene esiste proprio per evitare quella sorpresa: serve a misurare, non a rassicurare.

Cadenza

Ogni due settimane è il compromesso giusto per la maggior parte dei progetti: abbastanza spesso da correggere la rotta, abbastanza raro da non diventare un peso. Su progetti brevi o critici, settimanale. Mensile è troppo: quando te ne accorgi, il ritardo è già strutturale.

Cosa deve produrre ogni SAL

1. Avanzamento rispetto al piano. Non “abbiamo lavorato sull’area pagamenti”, ma “dei 9 requisiti dell’area pagamenti, 5 sono completati e accettati, 2 in test, 2 non iniziati”.
2. Scostamenti. Dove siamo indietro (o avanti) rispetto alla data prevista, e perché. Uno scostamento dichiarato presto è gestibile; nascosto, diventa una crisi.
3. Rischi aggiornati. Il registro rischi va riletto ogni volta: cosa è cambiato, cosa è diventato più probabile, cosa possiamo fare adesso.
4. Decisioni richieste. Ogni SAL dovrebbe chiudersi con un elenco di scelte che spettano a te, con una data entro cui servono.
5. Budget speso rispetto al valore prodotto. Aver bruciato il 60% del budget non è un problema se hai il 60% dei deliverable accettati. Lo è se ne hai il 30%.
6. Demo. Software che funziona, non slide. Se non c’è niente da mostrare per due SAL di fila, è un segnale.

Il verbale

Una pagina, entro 24 ore, con tre sezioni: decisioni prese, azioni (chi fa cosa entro quando), punti aperti. Se una cosa non è nel verbale, al SAL successivo non è successa. Il verbale è lo strumento che trasforma le chiacchiere in impegni verificabili.

Metriche che non mentono

• Deliverable accettati / totali. La percentuale di avanzamento vera. Non “codice scritto”: accettato da te.
• Difetti aperti e trend. Se il numero di bug aperti cresce ogni settimana, la fine non è vicina anche se le funzioni “ci sono”.
• Velocità (quanto lavoro chiude il team per iterazione). Serve per proiettare la data di fine realistica, non quella di contratto.
• Burn-down del backlog. La linea deve scendere. Se è piatta, il lavoro entra alla stessa velocità con cui esce.

Errori ricorrenti

• Il SAL solo a parole. Nessun documento, nessun dato, nessuna demo: non è un SAL, è una telefonata.
• La sindrome del 90%. “Siamo al 90%” per cinque settimane. Il 90% dichiarato senza deliverable accettati di solito è 60%.
• Scope che cambia in silenzio. Se durante i SAL entrano funzioni nuove senza una richiesta di modifica formale, la data di consegna diventa carta straccia e nessuno se ne prende la responsabilità.
• Rischi copiati e incollati. Un registro rischi che non cambia mai è un registro che nessuno legge.

Agenda minima di un SAL

1. Demo di quanto completato dall’ultima volta (10–15 min).
2. Avanzamento per area rispetto al piano, con numeri.
3. Scostamenti e nuova proiezione della data di fine.
4. Rischi aggiornati e azioni di mitigazione.
5. Decisioni richieste al committente, con scadenza.
6. Riepilogo azioni e responsabili. Verbale entro il giorno dopo.

In sintesi

Un SAL utile ti fa uscire dalla riunione con tre cose: un numero di avanzamento di cui ti fidi, una data di fine realistica, una lista di decisioni da prendere. Se esci solo con la sensazione che “va tutto bene”, il SAL non ha fatto il suo lavoro.