1. Come accade solitamente
Il progetto parte con un perimetro chiaro. O almeno, così sembra.
Poi arrivano le richieste:
“Possiamo aggiungere solo una piccola cosa?”
“Già che ci siamo, sistemiamo anche questo?”
“È un tweak veloce, vero?”
Ogni modifica è ragionevole presa singolarmente. Il problema nasce quando si accumulano.
Nel giro di qualche settimana:
- il lavoro è aumentato
- le tempistiche si allungano
- il cliente ha una percezione diversa del perimetro iniziale
E soprattutto, nessuno ricorda più quando una richiesta è diventata parte del progetto.
Aneddoto classico: progetto web, 5 pagine previste. Alla consegna diventano 11. Il cliente è convinto che fosse sempre stato così. Il team ha in mente una sequenza di call, messaggi vocali e commenti su file condivisi. Nessuno ha una ricostruzione ordinata.
Ci sono anche dinamiche più sottili:
- richieste fatte in call e mai scritte
- modifiche approvate con un “ok” in chat senza contesto
- task aggiunti direttamente su strumenti operativi senza passare da una conferma formale
Il risultato è sempre lo stesso: una zona grigia dove tutto sembra incluso.
2. Cosa devi dimostrare
Qui il punto è molto concreto: quando una modifica è stata richiesta, in che forma e rispetto a quale perimetro iniziale.
Devi poter dimostrare:
- l’esistenza della richiesta di modifica
- il contenuto preciso della richiesta
- il momento in cui è stata fatta
- il contesto (call, e-mail, chat, tool)
- la differenza rispetto allo scope originale
- eventuali conferme o approvazioni
In una discussione, la domanda diventa:
“Questa attività era prevista all’inizio o è stata aggiunta dopo?”
3. Cosa raccogliere
Qui serve raccogliere le tracce delle modifiche mentre accadono, non a posteriori.
Materiali utili:
- e-mail con richieste di modifica
- screenshot di chat (Slack, Teams, WhatsApp, ecc.)
- esportazioni di conversazioni rilevanti
- registrazioni o note di call
- commenti su documenti condivisi (Google Docs, Figma, ecc.)
- task aggiunti su strumenti di project management
- versioni aggiornate di documenti o deliverable
- riepiloghi inviati dopo meeting
- eventuali mini-preventivi o approvazioni scritte
Un dettaglio pratico:
anche un semplice screenshot di un messaggio tipo “aggiungiamo anche questo punto” con data e ora visibili può fare molta chiarezza dopo.
4. Come procedere
Qui la chiave è trasformare le modifiche in qualcosa di tracciabile e ordinato.
Quando arriva una richiesta:
- evita di lasciarla solo in forma orale
- riportala subito in forma scritta (anche con un breve riepilogo)
- collega la richiesta a un contesto preciso
Subito dopo:
- salva o esporta la conversazione rilevante
- fai uno screenshot se la richiesta è in chat
- crea un piccolo “blocco informativo” (richiesta + contesto)
Poi fai un passaggio fondamentale:
- chiarisci se la modifica rientra nello scope o è un’aggiunta
- se serve, invia un breve messaggio di allineamento (“questa attività è extra rispetto a…”)
Per organizzare tutto:
- crea una cartella dedicata alle modifiche di progetto
- raccogli i materiali per data o per tema
- mantieni una sequenza logica delle richieste
A questo punto:
- crea pacchetti coerenti (richiesta + eventuale risposta + versione aggiornata del deliverable)
- attesta questi materiali nello stato in cui esistono
Se le modifiche continuano:
- ripeti il processo senza sovrascrivere
- conserva ogni passaggio come parte della storia del progetto
Nel tempo, ottieni una timeline chiara:
richiesta → chiarimento → approvazione → implementazione
5. Errori da evitare
Gli errori più comuni sono quelli che sembrano innocui mentre lavori.
- accettare modifiche solo a voce senza traccia scritta
- rispondere “ok” in chat senza contestualizzare
- aggiornare i deliverable senza conservare la versione precedente
- non distinguere mai tra scope iniziale e aggiunte
- lasciare le richieste disperse tra strumenti diversi
C’è anche un errore di atteggiamento:
considerare ogni modifica come “parte del flusso normale” senza mai fermarsi a registrarla.
Accorgimenti utili oltre all’attestazione:
- inviare sempre un breve recap dopo call con modifiche
- usare etichette chiare tipo “nuova richiesta” o “estensione”
- mantenere coerenza nei nomi dei file e nelle versioni
Quando la documentazione è ordinata, le discussioni si accorciano molto. L’attestazione gratuita aggiunge un riferimento temporale preciso a ogni passaggio raccolto.
6. Dopo la documentazione
Se nasce un disallineamento:
- ricostruisci la sequenza delle modifiche
- condividi i passaggi in ordine cronologico
- evidenzia cosa è stato aggiunto nel tempo
Questo approccio aiuta a spostare la conversazione su fatti concreti.
Se serve:
- coinvolgi il referente di progetto lato cliente
- prepara un riepilogo chiaro delle variazioni
- valuta un aggiornamento formale di tempi e costi
Nei casi più complessi:
- puoi usare la documentazione raccolta per supportare un confronto più strutturato
- avere una timeline chiara rende ogni verifica più veloce
Alla fine, il vantaggio reale è semplice:
riesci a distinguere con precisione tra lavoro previsto e lavoro cresciuto strada facendo, senza dover ricostruire tutto a memoria.