Modello di report di stato del progetto: formato settimanale, esempio — e come il report si compone da solo a partire dai recap (2026)

Un report di stato del progetto è una pagina breve, a formato fisso, che dice a chi non segue il lavoro quotidiano a che punto è il progetto: in linea o meno, cosa è cambiato dall'ultimo report, cosa potrebbe andare storto e cosa si chiede di decidere a chi legge. Viene scritto con una cadenza — settimanale per la maggior parte dei progetti — ed è ogni volta la stessa pagina, così chi legge confronta questa settimana con la scorsa invece di leggere da capo.

Questa guida parte dal mestiere — il formato, un modello da copiare, un esempio compilato, una versione settimanale più breve per il responsabile di team che riporta verso l'alto — e poi passa alla meccanica: quando basta un report e quando conviene ancora convocare una riunione di stato, dove si scrive il report negli strumenti che il tuo team già usa, e cosa succede tra le riunioni e la pagina. Perché la parte più difficile del report non è la scrittura. È la mezz'ora prima, quando chi guida il progetto ripercorre una settimana di chiamate e chat per capire che cosa è stato davvero concordato.

Che cos'è un report di stato del progetto — e che cosa non è

Intorno a un progetto girano quattro documenti, e il report è quello che si confonde più spesso con gli altri:

Il recap è per riunione; il report è per settimana, su tutte le riunioni. Uno stand-up porta i blocchi davanti a chi può rimuoverli; il report dice a chi è più lontano se quei blocchi mettono a rischio la data. Il registro delle decisioni conserva il perché; il report dice solo che una decisione è stata presa o è ancora necessaria. Se il report è difficile da scrivere, la causa è quasi sempre a monte: le riunioni della settimana non hanno lasciato traccia dei loro esiti, e chi guida il progetto li ricostruisce a memoria il venerdì pomeriggio.

Il formato settimanale: sei blocchi, una pagina

Un report che si legge ogni settimana deve stare in una schermata e mantenere sempre la stessa forma. Sei blocchi, in quest'ordine:

1. Intestazione. Progetto, periodo di riferimento, autore, data del prossimo report. Chi legge cerca prima di tutto il periodo: un report senza periodo è una pagina di affermazioni senza un "da quando".
2. Stato complessivo in una riga. Verde, giallo o rosso — oppure in linea, a rischio, fuori rotta — più una frase che spiega perché. Il colore è una sintesi dei blocchi che seguono, non una sensazione; se il blocco dei rischi dice che un fornitore ha accumulato due settimane di ritardo, la riga non può dire verde.
3. Avanzamento dall'ultimo report. Da tre a sei righe su ciò che è stato completato, ciascuna come risultato e non come attività. "Flusso di checkout in revisione con il cliente" è un fatto; "lavorato al checkout" no.
4. Prossimo periodo. Che cosa il team si impegna a completare prima del prossimo report, ciascuno con un responsabile. Questo blocco è il metro con cui si controllerà il blocco di avanzamento della settimana successiva.
5. Rischi, problemi e decisioni necessarie. Un rischio è qualcosa che potrebbe accadere; un problema è qualcosa che è già accaduto. Ogni riga: che cosa, effetto su data o budget, responsabile e che cosa si chiede a chi legge — compreso "niente, solo per informazione". Le decisioni necessarie hanno una riga propria, con la data entro cui il progetto ha bisogno della risposta.
6. Azioni aperte. Ogni azione ancora aperta, proveniente da qualsiasi riunione del periodo, con responsabile e scadenza, e un segno su quelle in ritardo. È il blocco che la maggior parte dei report omette, e quello che chi legge usa per giudicare se il colore del blocco 2 è onesto.

Tre cose da lasciare fuori: i dialoghi (chi ha detto cosa), i registri di attività (ore, chiamate effettuate) e tutto ciò su cui chi legge non potrebbe agire. Il report è per qualcuno che gli dedicherà quattro minuti. Ogni riga dovrebbe reggere alla domanda "che cosa farebbe di diverso chi legge sapendo questo?"

Modello di report di stato del progetto

Copialo in un documento, in un messaggio di canale o in un canvas. Le parentesi quadre sono segnaposto.

[Progetto] — report di stato per [periodo, es. 20–24 ottobre]
Autore: [nome] · Inviato: [data] · Prossimo report: [data]
Complessivo: [in linea / a rischio / fuori rotta] — [una frase che spiega perché]

Fatto dall'ultimo report
– [Risultato, come fatto] — [responsabile]
– [Risultato] — [responsabile]
– [Risultato] — [responsabile]

Prossimo periodo (entro [data del prossimo report])
– [Deliverable] — [responsabile]
– [Deliverable] — [responsabile]

Rischi e problemi
– [Rischio o problema] — effetto: [data / budget / ambito] — responsabile: [nome] — richiesta: [decisione necessaria entro la data / per informazione]

Decisioni necessarie
– [Domanda, con le opzioni sul tavolo] — necessaria entro [data] — da [nome]

Azioni aperte
– [Attività] — [responsabile] — scadenza [data] — [aperta / in ritardo dal giorno]
– [Attività] — [responsabile] — scadenza [data] — [aperta]

L'ordine è voluto. Uno sponsor che legge solo le prime tre righe ottiene il colore e il motivo; chi legge fino in fondo trova le azioni che spiegano il colore. Mantieni le intestazioni identiche da una settimana all'altra: il valore del formato sta nel confronto.

Esempio: un report di stato settimanale compilato

Un piccolo progetto software, team bilingue, un cliente che legge il report ogni lunedì:

Portale ordini v2 — report di stato per il 20–24 ottobre
Autore: Mateusz · Inviato: 24 ottobre · Prossimo report: 31 ottobre
Complessivo: a rischio — la sandbox del provider di pagamento è arrivata con quattro giorni di ritardo; la data di lancio regge solo se il test di integrazione passa entro il 29 ottobre.

Fatto dall'ultimo report
– Flusso di checkout in revisione con il cliente; due commenti aperti — Ana
– L'importazione dei prodotti dall'ERP gira ogni notte in staging — Priya
– Stringhe dell'interfaccia in spagnolo e rumeno complete; francese all'80% — Luca

Prossimo periodo (entro il 31 ottobre)
– Test di integrazione dei pagamenti sulla sandbox del provider — Priya
– Approvazione del checkout da parte del cliente — Ana
– Stringhe in francese complete, tutte e tre le lingue riviste — Luca

Rischi e problemi
– Ritardo della sandbox di pagamento (problema) — effetto: il lancio del 7 novembre regge solo se il test passa entro il 29 ottobre; altrimenti 14 novembre — responsabile: Priya — richiesta: per informazione, decisione sotto
– Tempi di revisione del cliente (rischio) — effetto: ogni giro richiede 3 giorni; un terzo giro sposta l'approvazione oltre la finestra del test — responsabile: Ana — richiesta: che il cliente raggruppi i commenti in un unico giro

Decisioni necessarie
– Se il test fallisce il 29 ottobre: lancio il 14 novembre con i pagamenti, oppure il 7 novembre con il solo pagamento su fattura e i pagamenti con carta aggiunti in seguito — necessaria entro il 30 ottobre — dal cliente

Azioni aperte
– Inviare al provider la allow-list degli IP — Priya — scadenza 21 ottobre — in ritardo dal 21 ottobre
– Confermare con il partner di hosting la finestra di go-live — Mateusz — scadenza 28 ottobre — aperta
– Rispondere ai due commenti sul checkout — Ana — scadenza 27 ottobre — aperta

Si noti che cosa l'esempio non dice: quante riunioni ci sono state, chi ha parlato, quante ore sono state spese. Chi legge capisce in una riga che la data è a rischio e in un blocco che cosa gli viene chiesto di decidere.

Modello di report settimanale per un responsabile di team

Il report settimanale di un responsabile di team al proprio manager è un cugino più breve del report di progetto. Chi legge è una sola persona, di solito con meno di due minuti, e le domande sono tre: il team rispetta gli impegni, che cosa è d'ostacolo, e che cosa ti serve da me. Quattro blocchi stanno in un messaggio di chat:

Team [nome] — settimana del [data]
Stato: [in linea / a rischio] — [una riga]
Consegnato: [due o tre risultati, ciascuno con un nome]
D'ostacolo: [uno o due blocchi, ciascuno con chi può rimuoverlo]
Che cosa serve da te: [una decisione o una risorsa, con una data] — oppure "niente questa settimana"

Due regole che lo rendono leggibile nei mesi. Primo, "Che cosa serve da te" non è mai vuoto per caso: scrivi "niente questa settimana" così il manager sa che il silenzio è voluto. Secondo, "Consegnato" elenca i nomi delle persone: un report settimanale è anche il luogo in cui chi guida il team rende visibile il lavoro a chi non lo vede ogni giorno. Se il team tiene già uno stand-up quotidiano con i blocchi nominati, "D'ostacolo" è una copia di quelli ancora in piedi il venerdì.

Il report settimanale sostituisce la riunione di stato settimanale per la maggior parte di ciò che la riunione portava, cioè l'informazione. Ciò che non può sostituire è trattato qui sotto.

Quando serve ancora una riunione di stato

Una riunione di stato è la forma dal vivo del report: ciascuno dice al responsabile o allo sponsor a che punto sono le cose, in una stanza, al costo del tempo di tutti. Una volta che esiste un report scritto, la riunione si giustifica solo quando la pagina non basta. Quattro casi:

• Una decisione con un compromesso. Il report può esporre le opzioni; non può negoziarle. Quando "Decisioni necessarie" contiene una voce la cui risposta dipende da ciò a cui due stakeholder sono disposti a rinunciare, trenta minuti con entrambi nella stessa stanza valgono più di due settimane di risposta a tutti.
• Una data si sposta. Un ritardo raramente viene accettato da una pagina. La conversazione su che cosa si sposta con essa — ambito, budget, l'avvio di un altro progetto — è una riunione, con il report come lettura preliminare.
• Un rischio ha superato la soglia. La settimana in cui un rischio diventa un problema, chi ne possiede le conseguenze deve sentirlo dal responsabile e fare domande, non leggerlo il lunedì.
• Un nuovo stakeholder. Chi non ha letto i sei report precedenti ha bisogno di una sessione per cogliere la forma del progetto; dopo, la pagina basta.

Una riunione di stato non serve a leggere il report ad alta voce. Se ogni punto all'ordine del giorno è "aggiornamento di X", annullala e invia la pagina; la guida sulla cadenza delle riunioni spiega quali riunioni ricorrenti si meritano il loro spazio. Quando la riunione si tiene, conducila a partire dal report: i blocchi dei rischi e delle decisioni sono l'ordine del giorno, e una riunione efficace si chiude con quei punti segnati come decisi, aperti o rinviati. Con stakeholder che parlano lingue diverse, per la riunione stessa ci sono tre opzioni: un interprete umano — la guida sull'interprete in Zoom mostra come impostarlo — i sottotitoli della piattaforma, oppure uno spazio che traduce per ogni partecipante; il report, scritto una volta sola, è un'altra questione.

Dove si scrive il report negli strumenti che già usi

Ogni grande piattaforma lascia qualcosa dopo una riunione da cui costruire un report di stato, e ognuna si ferma in un punto diverso. Solo comportamenti documentati, dalle pagine dei fornitori stessi, con il mese in cui ciascuna pagina è stata controllata:

Due cose valgono ovunque. Ciò che una riunione lascia è un documento per riunione, nell'unica lingua usata in sala; e se i prossimi passi della settimana scorsa siano stati fatti non è qualcosa che il documento sa — chi guida il progetto va a controllare prima di scrivere "fatto". Il lato dei sottotitoli in tempo reale delle piattaforme — ciò che Teams e Google Meet mostrano a schermo durante una chiamata — non cambia il documento che resta dopo. I notetaker sono la stessa categoria un passo più in là: quelli confrontati in alternative a Otter.ai scrivono un riepilogo per riunione, e un report che copre un mese di riunioni resta una pagina a parte.

Come il report si compone da solo a partire dai recap

InterMIND è uno spazio di comunicazione in cui un progetto vive in un canale, quindi la materia prima del report ha una casa evidente. Ogni riunione del canale si chiude con un recap — un riepilogo, le decisioni, le action items con responsabili e date — scritto a partire dalla riunione stessa e consegnato per email, come messaggio nel canale e come link nell'evento del calendario. Ogni membro con accesso lo legge nella propria lingua: il resoconto è tradotto per ciascun lettore, non scritto una sola volta nella lingua che la sala ha usato per caso, e lo stesso vale per la chat del canale attorno ad esso, scritta da ogni membro nella propria lingua. Qualsiasi membro può modificare il recap, ogni modifica conserva autore e cronologia delle revisioni, e il canale conserva il recap di ogni sessione passata — così "fatto dall'ultimo report" diventa una scorsa dei recap della settimana invece di una ricostruzione.

Le action items portano con sé il proprio stato. Una voce risulta da fare, fatta o non fatta con un motivo, e in un'organizzazione con le pagine di stato del team attive, le voci aperte delle sessioni precedenti vengono valutate quando si scrive il recap successivo: una voce che qualcuno ha dichiarato conclusa è segnata come fatta, una voce discussa ma non conclusa è segnata come non fatta con il motivo espresso con le parole della riunione, una voce di cui nessuno ha parlato resta aperta. È il blocco "azioni aperte" del modello, tenuto dalle riunioni invece che da chi guida il progetto.

Le pagine di stato del team sono il luogo da cui viene il resto del report. Una pagina sugli ultimi 7, 28 o 90 giorni elenca le attività dell'organizzazione, i problemi, ciò che è importante e urgente, e il denaro in gioco, e ogni riga riporta la citazione letterale del recap su cui si basa; un'attività resta finché qualcuno non la chiude, e dopo quattro settimane senza movimento viene segnata come ferma. Chi guida il progetto scrive la riga dell'andamento e il colore — il giudizio — su una pagina che le riunioni hanno già compilato. La stessa pagina è leggibile tramite un assistente collegato: un responsabile che lavora in Claude, ChatGPT, Copilot o Gemini chiede le attività e i problemi aperti della settimana e ottiene le righe con le loro citazioni. Le pagine di stato del team sono una funzione in anteprima sui piani a pagamento: l'amministratore di un'organizzazione le attiva in Settings → Advanced dopo aver accettato i termini alpha (la pagina Funzionalità in anteprima descrive ciascuna di esse).

Dove il report deve arrivare in un sistema di riferimento, l'host aggiunge una copia del recap a qualsiasi indirizzo — la casella in entrata di un CRM o di un tracker di progetto — e ogni recap della riunione o del canale viene inviato anche lì dopo una conferma una tantum dell'indirizzo; la meccanica è in una copia di ogni recap di riunione nel tuo CRM, via email, e lo stesso recap arriva come webhook o come trigger Zapier per i team che lo pubblicano da soli in un tracker.

Uno stakeholder del cliente che deve vedere i recap viene invitato al canale per email ed entra con un account gratuito, leggendo nella propria lingua; i partecipanti esterni in un canale non costano nulla all'host. Un ospite di una singola riunione entra tramite link, senza account e senza costi — da telefono, nel browser — e sente la riunione dal vivo nella propria lingua. Per un ospite non resta alcun resoconto dopo: l'account è gratuito, ed è ciò che rende raggiungibile il resoconto. L'host mette a disposizione lo spazio e, con un piano a pagamento, paga solo per i membri attivi nei 28 giorni precedenti; i membri che restano inattivi mantengono l'accesso senza costi.

• Apri un recap completo — un resoconto reale, generato dallo stesso codice che scrive i tuoi.
• Prova la demo live — senza registrazione; parla e ascolta la sala tradotta per ciascun ascoltatore.

Il report come mestiere sopravvive a ogni strumento: qualcuno deve comunque dire se il progetto è in linea e perché. Ciò che non deve sopravvivere è la mezz'ora del venerdì — ripercorrere una settimana di chiamate, in una sola lingua, per capire che cosa è stato concordato e se qualcuno l'ha fatto.

FAQ

Che cos'è un report di stato del progetto?

Una pagina breve, a formato fisso, inviata con una cadenza — di solito settimanale — che dice a chi non segue il lavoro quotidiano a che punto è un progetto: uno stato complessivo in una riga con il motivo, che cosa è stato completato dall'ultimo report, che cosa è previsto prima del prossimo, i rischi e i problemi con il loro effetto su data o budget, le decisioni che si chiede a chi legge di prendere, e le azioni ancora aperte con responsabili e scadenze. È ogni volta la stessa pagina, così chi legge confronta le settimane invece di leggere da capo.

Che cosa dovrebbe includere un report di stato settimanale?

Sei blocchi: un'intestazione con il periodo di riferimento; una riga di stato complessivo con il motivo; l'avanzamento dall'ultimo report come risultati, non attività; gli impegni per il prossimo periodo con i responsabili; rischi, problemi e decisioni necessarie, ciascuno con il proprio effetto e una richiesta; e ogni azione aperta con responsabile e scadenza, con quelle in ritardo segnalate. Lascia fuori dialoghi, ore e tutto ciò su cui chi legge non può agire.

Come si scrive un report di stato del progetto?

Parti dal report precedente: il suo blocco "prossimo periodo" è la lista di controllo di questa settimana, e le sue azioni aperte sono o concluse o ancora aperte. Poi scorri i recap delle riunioni della settimana per vedere che cosa è stato deciso e che cosa è stato aggiunto. Scrivi per ultima la riga di stato, dopo il blocco dei rischi, così che il colore corrisponda ai fatti. Invialo lo stesso giorno ogni settimana, alla stessa lista, e mantieni le intestazioni identiche da un report all'altro.

Qual è la differenza tra un report di stato e una riunione di stato?

Un report di stato si scrive e si legge in modo asincrono; una riunione di stato è la stessa informazione data dal vivo, al costo del tempo di tutti i presenti. Una volta che esiste un report, una riunione si giustifica quando la pagina non basta: una decisione con un compromesso tra stakeholder, una data che si sposta, un rischio appena diventato problema, o un nuovo stakeholder che ha bisogno una volta sola di cogliere la forma del progetto. Una riunione il cui ordine del giorno è "aggiornamento di ciascuno" è un report letto ad alta voce.

Un modello di report settimanale per un responsabile di team è diverso da un report di stato del progetto?

È più breve e rivolto a una sola persona. Il report settimanale di un responsabile di team al proprio manager risponde a tre domande in quattro blocchi — stato in una riga, che cosa il team ha consegnato con i nomi, che cosa è d'ostacolo e chi può rimuoverlo, e che cosa serve dal manager entro quando — e sta in un messaggio di chat. Un report di stato del progetto è più lungo, copre un periodo e un insieme di stakeholder, e riporta rischi, decisioni e azioni aperte di ogni riunione del progetto.

Ogni quanto va inviato un report di stato del progetto?

Ogni settimana per la maggior parte dei progetti: abbastanza spesso perché un ritardo venga colto entro una settimana, abbastanza di rado perché ogni report abbia qualcosa di nuovo. Quello quindicinale si adatta a progetti lunghi e regolari con poche decisioni; il report quotidiano appartiene a una settimana di lancio o a un incidente, ed è un documento diverso e più breve. Qualunque sia la cadenza, il giorno e la lista dei destinatari non dovrebbero cambiare: un report che arriva ogni settimana in un giorno diverso non viene letto come una serie.

Il cliente dovrebbe ricevere il report di stato?

Sì, se il cliente paga il progetto e una decisione del report spetta a lui — il blocco "decisioni necessarie" è scritto per lui. Scrivi, quando possibile, un solo report per tutti, invece di una versione per il cliente e una interna; un report in due versioni si disallinea, e quello interno diventa quello vero. Ciò che resta fuori da un report condiviso è il dettaglio interno del team — prestazioni individuali, stime in corso di negoziazione — che appartiene agli appunti personali di chi guida il progetto.

Fonti: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap in Microsoft Teams; Zoom — Using Meeting Summary with AI Companion; Google Meet — "Take notes for me" in Google Meet; Google Workspace Updates — "Take notes for me" suggests next steps; Slack — Meeting agenda template (canvas). Le pagine Microsoft sugli appunti, Google Meet sugli appunti e Slack sono state controllate a ottobre 2026; l'annuncio Google sui prossimi passi a settembre 2026; le pagine Microsoft sul recap e Zoom sul riepilogo della riunione ad agosto 2026. I fornitori cambiano nel tempo piani, funzionalità ed elenchi delle lingue; consulta le loro pagine per lo stato attuale.