Dal brief allo Statement of Work

Tra gli epitaffi del PM Butcher, il serial killer dei project manager del libro, ce n’è uno che dice: «Ogni requisito ignorato è un progetto saltato». È una battuta macabra, ma è anche la cosa più vera che si possa dire sull’inizio di un progetto. La maggior parte dei problemi che esplodono a metà strada era già scritta, o non scritta, nei primi documenti.

Quei documenti sono tre, e spesso vengono confusi. Hanno autori diversi, momenti diversi e scopi diversi.

Documento	Chi lo scrive	A che cosa serve
Requisiti	Si raccolgono insieme, cliente e fornitore	Capire esigenze e aspettative: che cosa deve fare il prodotto o il servizio
Brief	Il cliente	Descrivere il problema, il contesto, il pubblico, gli obiettivi e i vincoli
Statement of Work	Il fornitore, approvato dal cliente	Fissare che cosa si consegna, come, con quali tempi, costi, ruoli e responsabilità

Il brief: che cosa deve contenere

Un buon brief è preciso, sintetico e coerente. Non racconta tutto: dice quello che serve e rimanda il resto agli allegati. Queste sono le voci che non dovrebbero mai mancare.

• Intestazione: oggetto, natura (gara o assegnazione diretta), data, referente, scadenza per le proposte.
• Contesto: l’azienda, il prodotto o servizio, il momento. In breve: brand book e schede prodotto vanno in allegato.
• Obiettivi: quelli generali e quelli misurabili, con i valori di partenza. «Aumentare le visite del 10%» non significa niente se nessuno sa quante sono oggi.
• Pubblico: dati, abitudini, motivazioni. Le buyer personas, se ci sono, valgono più di qualsiasi tabella demografica.
• Competitor e mercato: chi c’è, che cosa fa, che cosa funziona nel settore.
• Linee guida creative: tono, stile, riferimenti. Un trucco che funziona sempre: «tre siti che ci piacciono, tre che non ci piacciono, e perché».
• Deliverable: che cosa ci si aspetta di ricevere, in un elenco o in un paragrafo, ma senza ambiguità.
• Budget: è sempre il punto più delicato. Chi lo scrive teme che una cifra dichiarata venga spesa tutta; chi lo riceve non sa come dimensionare la proposta senza. Una forbice («tra 30 e 50 mila») o un tetto, insieme al rapporto qualità-prezzo tra i criteri di valutazione, risolvono quasi sempre il problema.
• Tempi: due calendari, non uno. Quello della selezione (domande, Q&A, consegna delle proposte, decisione, kick-off) e quello del progetto (consegne, revisioni, lancio).
• Esclusioni: ciò che non è compreso. Il classico «media escluso» evita settimane di equivoci.
• Criteri di valutazione: come verranno giudicate le proposte. Si trovano raramente fuori dalle gare pubbliche, ed è un peccato: aiutano tutti a lavorare meglio.

Gli errori più comuni

Troppo vago o troppo dettagliato. Un brief vago genera proposte che non c’entrano; uno troppo dettagliato toglie spazio alla soluzione. L’equilibrio sta nel descrivere bene il problema e lasciare aperta la risposta.

Informazioni nascoste o non aggiornate. Una storia vera: un brief per il rifacimento di un sito, senza dire al fornitore che era in corso un rebranding completo. L’identità del marchio è cambiata mentre il sito veniva costruito, e tutto è stato rivisto in corsa, all’ultimo minuto. La spiegazione: «Era una cosa riservata». Per le cose riservate esiste l’accordo di riservatezza (NDA); il silenzio, invece, costa a tutti.

Niente spazio per le domande. Per quanto un brief sia chiaro, chi lo riceve avrà domande. Prevedere sessioni di Q&A è il minimo; quando non si tratta di una gara, lavorare insieme sul concept è ancora meglio.

Tempi impossibili. Brief inviati a fine luglio o il 23 dicembre, il venerdì per il lunedì. Assegnazioni che arrivano in ritardo senza che si spostino la partenza e la consegna. Sono errori che minano il progetto prima ancora che cominci.

Saper ricevere un brief

Leggere bene un brief è importante; riceverlo bene lo è altrettanto, e ci si pensa meno.

• Ascolta quello che il cliente dice, e quello che non dice. I silenzi e le esitazioni spesso indicano dove sono i problemi.
• Chiedi subito, o annota per dopo. Se la presentazione è per più fornitori e le domande arrivano in un secondo momento, scrivi i dubbi mentre li hai.
• Pretendi un brief scritto. Se il cliente non lo produce, scrivilo tu sulla base di quello che hai sentito e mandaglielo per conferma. È il gesto più utile che un PM possa fare all’inizio di un progetto.
• Prepara una scheda per il team. Sempre la stessa struttura: cliente, persone presenti, attività precedenti, criticità note, obiettivi, pubblico, deliverable, cose da fare e da non fare, budget, scadenza interna e scadenza del cliente, data e modalità della presentazione. Con il tempo, il team la leggerà in un minuto.

Andare oltre il brief

A volte un brief non convince: la soluzione richiesta sembra sbagliata, o si pensa di poter fare di meglio. Proporre un’alternativa può essere la mossa vincente, o il modo più rapido per perdere un cliente. Prima di farlo, vale la pena chiedersi:

1. Ho capito davvero che cosa vuole ottenere il cliente, e quale problema vuole risolvere?
2. I miei dubbi sono oggettivi, o mi mancano delle informazioni?
3. Quali esigenze non emergono dal brief, ma secondo me ci sono?
4. Sono così convinto da giocarmi tutto, compreso il progetto?

Per rispondere aiutano due cose: una sessione con il team, quasi come se ci si ridesse il brief da soli, e una conversazione con il cliente. Si crede spesso che durante una gara fare domande sia un segno di debolezza. Non è così: mantenere un canale aperto è parte del lavoro di chi segue il cliente, in allineamento costante con il PM.

Quando si decide di andare oltre, l’alternativa va presentata accanto alla soluzione richiesta, non al suo posto: «Nel brief si chiede X; crediamo che Y possa funzionare meglio, per queste ragioni». Con dati, esempi concreti e la disponibilità a lavorarci insieme.

Lo Statement of Work

Lo Statement of Work (SoW) è il documento che chiude la fase delle intenzioni e apre quella degli impegni. È, a tutti gli effetti, la base del contratto. Deve dire:

• perché si fa il progetto e con quali obiettivi;
• che cosa è incluso e, con la stessa chiarezza, che cosa è escluso;
• le ipotesi su cui si regge (le assumptions): se cambiano, cambia il progetto;
• come verrà fatto: approccio, fasi, attività, metodologia;
• che cosa verrà consegnato e con quali criteri di accettazione;
• tempi e costi;
• chi fa che cosa e chi approva (la governance).

Un SoW ben scritto non serve a difendersi dal cliente: serve a evitare che ci sia bisogno di difendersi. È la base su cui si stima, si pianifica e si gestiscono le modifiche quando arrivano. E arrivano sempre.

Nei progetti più strutturati, accanto al SoW ci sono altri due documenti. Il Project Charter sancisce ufficialmente l’avvio del progetto e ne dà una visione sintetica: perché, chi, che cosa, quando. Il Project Plan viene dopo, e guida l’esecuzione con attività, risorse, costi, rischi e comunicazione. Il primo dice che il progetto esiste, il secondo come lo porteremo a termine.