Usa questo modello
Un ottimo project brief allinea tutti sulla stessa lunghezza d'onda prima dell'avvio di un progetto: cosa si sta realizzando, perché è importante, chi è coinvolto e come verrà misurato il successo. Con Trupeer, puoi risparmiare ore nella stesura dei project brief partendo da un modello gratuito, personalizzandolo con la tua brand identity e trasformando il brief in un breve video riepilogativo che gli stakeholder possono guardare in 3 minuti.
Cos'è un modello di project brief e quando viene redatto?
Un project brief è il breve documento redatto all'inizio assoluto di un progetto, prima che esista il piano, che definisce a cosa serve il progetto, perché è importante adesso, chi coinvolge, cosa rappresenta il successo e quali sono i vincoli.
È il documento che le persone firmano per autorizzare il lavoro e diventa il punto di riferimento contestato da tutti sei mesi dopo. È volutamente breve, di solito una o due pagine, perché viene scritto nel momento in cui si hanno meno informazioni.
Un modello ti fornisce le sezioni. Contesto, obiettivi, ambito, deliverable, tempistiche, budget, stakeholder, criteri di successo. Ogni versione che troverai offre all'incirca questi elementi, e non c'è nulla di sbagliato in essi.
Il problema dei brief non sono quasi mai le sezioni. È ciò che contengono.
La maggior parte dei brief indica una soluzione, non un problema
Ecco la lamentela che ogni delivery team, agenzia e gruppo di ingegneria muove riguardo ai brief, espressa nello stesso modo in qualsiasi settore: ci è stata data una descrizione della soluzione, non del problema.
"Creare un portale clienti." "Creare una nuova intranet." "Realizzare un'app mobile." "Riprogettare il flusso di onboarding." Ciascuna di queste cose è un elemento da realizzare, presentato come se fosse un requisito, quando in realtà è la risposta di qualcuno a una domanda che il brief non menziona mai.
Ciò accade per un motivo comprensibile. Chiunque commissioni un progetto di solito ci ha pensato per settimane ed è giunto a una conclusione. Mettere per iscritto la conclusione dà una sensazione di chiarezza, mentre scrivere il problema sembra trasmettere vaghezza.
Il costo è che le soluzioni più economiche vengono eliminate prima ancora che qualcuno le prenda in esame. Una volta che il brief menziona un portale, il progetto diventa un progetto di portale, e l'opzione che avrebbe risolto l'ottanta percento del problema con il cinque percento della spesa non viene mai valutata, perché a nessuno è stato chiesto di valutare alcunché.
Un brief che espone un problema stimola risposte. Un brief che espone una soluzione stimola preventivi.
Come personalizzare questo modello in Trupeer
Passaggio 1: Apri la sezione Modelli
Vai alla sezione Modelli dalla navigazione principale.
Passaggio 2: Seleziona e apri un modello
Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.
Passaggio 3: Espandi la visualizzazione del modello
Se necessario, espandi la visualizzazione del modello per vedere chiaramente il layout completo e i dettagli.
Passaggio 4: Modifica il modello
Fai clic su Modifica per iniziare a personalizzare il modello selezionato.
All'interno dell'editor puoi:
Aggiungere nuove sezioni
Definire o aggiornare le regole di formattazione
Aggiungere un logo e regolarne la posizione e le impostazioni correlate
Passaggio 5: Salva il modello personalizzato
Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per archiviare il modello aggiornato tra i tuoi.
Passaggio 6: Visualizza in anteprima e perfeziona il modello
Quando desideri vedere l'aspetto del modello personalizzato, apri l'Anteprima.
Dalla schermata di anteprima puoi continuare ad apportare modifiche direttamente, se necessario, assicurandoti che il modello appaia esattamente come desideri.
Con un modello di project brief puoi:
Risparmiare ore di scrittura: Evita la pagina bianca grazie a una struttura di brief collaudata.
Allineare rapidamente gli stakeholder: I brief di una sola pagina rendono più veloci le approvazioni e l'allineamento.
Rimanere coerente con il brand: Applica il tuo logo, i caratteri e i colori utilizzando il brand kit di Trupeer, ideale per i brief di agenzie e clienti.
Presentare con impatto: Converti il brief in un video riepilogativo, ideale per il sales enablement e i pitch per gli stakeholder.
Standardizzare tra i progetti: Utilizza lo stesso formato di brief per ogni iniziativa.
Raggiungere team globali: Traduci i brief in oltre 65 lingue con un solo clic.
Il test delle tre risposte per qualsiasi project brief
Due minuti: è l'unico test per i brief che valga la pena eseguire.
Leggi il brief e indica tre soluzioni realmente diverse che potrebbero soddisfarlo.
Non tre varianti della stessa cosa. Tre approcci differenti: costruire qualcosa, modificare un processo, acquistare qualcosa, rimuovere un passaggio, comunicare in modo diverso, fare di meno.
Se riesci a indicarne tre, il brief descrive un problema e il progetto ha una vera decisione davanti a sé.
Se puoi indicarne solo una, il brief descrive una soluzione. Ciò non è automaticamente errato, poiché a volte la decisione è stata effettivamente presa per ottime ragioni, e in tal caso la cosa più onesta è dirlo chiaramente e chiamare il documento "specifica tecnica" anziché "brief". Ciò che non è onesto è presentare una conclusione già scontata come una domanda aperta, per poi sorprendersi che nessuno l'abbia messa in discussione.
Esegui questo test sul brief prima di farlo circolare, chiedendo a qualcuno che non sia stato coinvolto nella stesura. Chi lo ha scritto può sempre indicarne tre, perché sa cosa ha scartato. Nessun altro può farlo, perché il brief non contiene queste informazioni.
Come descrivere il problema anziché il deliverable
Quattro abitudini, e nessuna di esse richiede più tempo di quanto ne occorrerebbe per descrivere la soluzione.
Inizia con un'osservazione e un dato numerico. Non "i clienti trovano difficile controllare i propri ordini", ma "il mese scorso i clienti ci hanno contattato seimilasettecento volte per chiedere dove fosse il loro ordine". Il numero ha due funzioni: dimostra che il problema è reale e quantifica il valore di una soluzione.
Descrivi cosa succede attualmente. Come viene gestito attualmente il problema, in modo inefficiente, includendo le soluzioni di ripiego inventate dalle persone. La descrizione dello stato attuale è ciò che consente a qualcuno di proporre una soluzione più economica.
Separa i vincoli dai requisiti. Un budget è un vincolo. Una scadenza è un vincolo. "Deve integrarsi con il sistema di magazzino esistente" è un vincolo. "Deve avere un login" è un requisito mascherato da vincolo, che di solito deriva dall'idea mentale che qualcuno si è fatto della soluzione.
Definisci il successo come variazione del dato numerico, non come esistenza di un deliverable. Ridurre tali contatti della metà entro sei mesi è un criterio di successo. Lanciare un portale è un traguardo.
Nel caso in cui tu abbia realmente in mente una soluzione, inseriscila in una sezione chiaramente etichettata, presentandola come una delle possibili opzioni anziché come il brief stesso.
Modello gratuito di project brief: la struttura da copiare
Copia da qui. Una o due pagine, ed evita di dilungarti.
Intestazione. Nome del progetto, sponsor, autore, data, versione e la decisione richiesta.
Il problema. Un'osservazione con un numero, la frequenza con cui si verifica e quanto costa. Due o tre frasi.
Come viene gestito ora. Il processo attuale, inclusi i workaround, e perché non è adeguato.
Perché ora. Cosa è cambiato che rende opportuno intervenire in questo trimestre anziché il prossimo anno.
Chi è coinvolto. Le persone o i clienti interessati e all'incirca quanti sono.
Criteri di successo. Quale numero cambia, di quanto ed entro quando. Uno o due elementi, espressi come risultati concreti.
Vincoli. Budget, scadenze, sistemi non modificabili, obblighi normativi o contrattuali, indisponibilità di personale. Tutto ciò che è realmente fisso, e nulla che sia in realtà una preferenza.
Fuori ambito. Ciò che questo progetto non affronterà, specificato con sufficiente precisione da poter risultare oggetto di confronto.
Approcci candidati, se presenti. Soluzioni già prese in considerazione, chiaramente etichettate come opzioni anziché come il brief, indicando il motivo per cui ciascuna è nell'elenco.
Decisione richiesta e da parte di chi. Cosa viene richiesto e chi lo autorizza.
Copia fino a qui. Se il brief supera le due pagine, la causa principale è solitamente il contesto, che appartiene a un'appendice che nessuno leggerà, e va bene così.
Il retailer che ha creato un portale su cui non si è registrato nessuno
Ashfold Group è un retailer specializzato con circa novanta negozi e una considerevole attività online.
Il brief era di due pagine, ben scritto e approvato senza difficoltà. Indicava: realizzare un portale self-service per i clienti in cui poter accedere per visualizzare lo stato degli ordini, scaricare fatture e inviare richieste. Budget di trecentoquarantamila sterline. Nove mesi.
È stato consegnato nei tempi previsti e quasi nei limiti del budget, a trecentosettantunomila sterline.
Sei mesi dopo il lancio c'erano tremilacento account registrati a fronte di circa quarantaseimila clienti attivi, quindi meno del sette percento. Il volume di contatti verso il centro assistenza è rimasto invariato.
La revisione post-implementazione ha posto una semplice domanda: quale problema doveva risolvere questo progetto? Nessuno è stato in grado di indicarlo nel brief, perché il brief aveva descritto una soluzione.
Così qualcuno è andato a cercare il problema. Il centro assistenza gestiva circa undicimila contatti al mese. Un campione di cinquecento contatti ha mostrato che il sessantuno percento riguardava una qualche variante di "dov'è il mio ordine", ovvero circa seimilasettecento contatti al mese.
Di questi clienti, l'ottantaquattro percento aveva già ricevuto un'e-mail di spedizione contenente un link di tracciamento. O non l'avevano vista, oppure l'avevano riaperta dopo la scadenza del link fissata a quattordici giorni.
Il problema principale, quindi, non era l'assenza di un modo per verificare lo stato dell'ordine da parte dei clienti. Era che il metodo già a loro disposizione non funzionava.
Tre approcci più economici non erano mai stati valutati, perché il brief non ne aveva richiesto alcuno. Estendere la validità del link di tracciamento. Reinviare il link periodicamente fino alla consegna. Aggiungere lo stato dell'ordine all'area dell'account già esistente, stimato successivamente in circa diciottomila sterline.
Il portale era una soluzione legittima a un problema reale. Non era il problema più grande e richiedeva la registrazione, cosa che il novantatré percento dei clienti non ha mai fatto.
Il brief per il progetto successivo è stato scritto diversamente. I clienti ci contattano seimilasettecento volte al mese per chiedere dove si trovi il loro ordine. L'ottantaquattro percento di loro ha già ricevuto un link di tracciamento. Ridurre questi contatti della metà entro sei mesi. Vincoli: nessuna modifica all'integrazione con il corriere, centocinquantamila sterline e deve funzionare senza richiedere la registrazione ai clienti.
Tre team hanno proposto tre risposte realmente diverse. Quella scelta è costata sessantaduemila sterline e ha ridotto i contatti del cinquantotto percento entro cinque mesi.
La differenza tra i due brief è che al secondo si poteva rispondere in tre modi. Al primo si poteva rispondere in un solo modo, e quel modo era già stato scelto.
Gli elementi chiave di cui ogni project brief ha bisogno
Elemento | Cosa deve contenere | L'errore comune |
|---|---|---|
Problema | Un'osservazione con un numero e una frequenza | Una soluzione descritta come una necessità |
Stato attuale | Come viene gestito oggi, compresi i workaround | Omesso, per cui le soluzioni economiche rimangono invisibili |
Perché ora | Cosa è cambiato per rendere la questione urgente | Assente, quindi il progetto non ha argomenti di priorità |
Criteri di successo | Una variazione numerica di una certa entità entro una data | L'esistenza di un deliverable |
Vincoli | Solo elementi realmente fissi | Preferenze introdotte surrettiziamente come vincoli |
Fuori ambito | Definiti in modo specifico, compresi gli elementi richiesti dalle persone | Vuoto, o "fasi future" |
Decisione richiesta | Cosa viene autorizzato e da parte di chi | Implicito, quindi non viene deciso nulla |
Le due righe più importanti sono lo stato attuale e i vincoli, ed entrambe sono solitamente carenti. Lo stato attuale è ciò che permette di proporre una soluzione economica. I vincoli, onestamente distinti dalle preferenze, sono ciò che impedisce a un brief di trasformarsi accidentalmente in una specifica.
Come scrivere un project brief in cinque passaggi
Uno. Descrivi il problema con un dato numerico. Se non riesci a ottenere un numero, dedica un pomeriggio a cercarne uno. Un brief privo di dati quantitativi è solo una preferenza.
Due. Descrivi lo stato attuale, incluso il modo in cui le persone gestiscono temporaneamente il problema oggi.
Tre. Definisci il successo come una variazione di quel numero, associata a una data.
Quattro. Elenca i vincoli e mettine in discussione ognuno. Per ciascun elemento, chiediti chi lo ha stabilito e se potrebbe cambiare. All'incirca un terzo di solito può essere modificato, e ogni vincolo rimosso amplia la gamma delle risposte possibili.
Cinque. Esegui il test delle tre risposte con qualcuno che non ha partecipato alla stesura. Se fallisce, apri il brief ad altre possibilità oppure rinomina il documento in modo onesto.
Poi fallo circolare e aspettati che tra le risposte ottenute ce ne sia almeno una a cui non avevi pensato. Se nessuna ti sorprende, il brief era probabilmente una specifica.
I vincoli e come vengono mascherati da requisiti
È qui che la maggior parte dei brief si trasforma silenziosamente in specifiche tecniche, e ciò avviene senza che nessuno lo faccia intenzionalmente.
Un vincolo reale è un fattore che sfugge al controllo del progetto. Il budget è quello assegnato. La scadenza normativa è fissa. Il sistema di magazzino non verrà sostituito quest'anno. Il team è composto da quattro persone.
Una preferenza mascherata da vincolo sembra identica. Deve essere un'app mobile. Ha bisogno di una dashboard. Gli utenti dovrebbero avere un login. Ciascuno di questi elementi è l'immagine mentale che qualcuno ha della risposta e, una volta inserito nella sezione dei vincoli, viene trattato come immutabile da tutti i soggetti coinvolti a valle.
Il test consiste nel chiedersi, per ogni elemento, chi lo ha deciso e cosa succede se viene modificato. Un vincolo reale ha un referente esterno al progetto e comporta conseguenze in caso di violazione. Una preferenza non ha nessuna delle due cose e, solitamente, chi l'ha inserita la abbandonerà di buon grado se interrogato direttamente.
Affronta questa discussione prima di far circolare il brief. Richiede venti minuti ed è spesso il momento di maggior valore dell'intero progetto, poiché ogni vincolo rimosso aggiunge una potenziale soluzione.
Project brief, business case o piano di progetto?
Tre documenti all'inizio di un progetto, in sequenza, con ruoli differenti.
Il brief definisce il problema, i vincoli e i criteri di successo. Viene redatto per primo, è breve e autorizza l'analisi o l'esecuzione.
Il business case giustifica la spesa. Contiene le opzioni con i relativi costi e benefici, ed è ciò che viene approvato da una funzione finanziaria o da un comitato per gli investimenti. Un brief diventato lungo e ricco di numeri è solitamente un business case a cui è stato dato il nome sbagliato.
Il piano di progetto copre le modalità di consegna dell'approccio scelto: ambito, pianificazione, risorse, dipendenze e rischi. Il nostro modello di piano di progetto IT copre questo livello.
La sequenza è importante. Brief, poi le opzioni, poi il business case, infine il piano. Scrivere il piano prima del brief, cosa che accade più spesso di quanto si ammetta, significa che l'approccio è stato scelto prima che il problema venisse definito.
Una volta redatto il piano, il brief dovrebbe essere esplicitamente superato anziché rimanere archiviato come seconda fonte per l'ambito concordato. Due documenti che rivendicano autorevolezza rendono insanabili le dispute sull'ambito.
Varianti del project brief: creativo, design, software ed edile
La struttura resta valida per tutte le tipologie, ma cambia l'enfasi.
I brief creativi e di marketing richiedono il pubblico e il messaggio, e sono i più soggetti a focalizzarsi subito sulle soluzioni, perché il cliente arriva con un formato ben preciso in mente. Il problema qui è solitamente un comportamento che si desidera cambiare piuttosto che un elemento da realizzare.
I brief di design necessitano dell'utente, del contesto d'uso e dei vincoli del sistema esistente. Quasi tutti i brief di questa categoria traggono beneficio dal test delle tre risposte, poiché un brief di design che specifica un layout toglie spazio alla progettazione vera e propria.
I brief di progetti software hanno bisogno del problema e dell'attuale workaround più di ogni altra cosa, e dovrebbero tenersi del tutto alla larga dalle funzionalità. Una volta che le funzionalità entrano nell'ambito, stai scrivendo un documento dei requisiti, coperto dal nostro modello di PRD lean.
I brief per costruzioni e progettazione contengono vincoli che sono autenticamente tali: cantiere, pianificazione, normative, budget. In questo caso, la sezione dei vincoli rappresenta la sostanza piuttosto che un fattore di rischio.
I progetti incentrati sugli acquisti richiedono che il brief dichiari cosa viene acquistato in termini di risultato anziché come specifica tecnica, poiché la decisione sul livello di definizione delle specifiche avverrà in seguito ed è coperta dal nostro modello di piano di gestione degli approvvigionamenti.
Posso ottenere un modello di project brief in Word o Excel?
Word o Google Docs. Un brief è testo in prosa, occupa una o due pagine e viene commentato prima dell'approvazione. Non contiene nulla che richieda un foglio di calcolo.
Excel trova spazio solo se gestisci molti progetti e desideri un registro: progetto, sponsor, problema in una riga, criteri di successo, vincolo di budget, stato e data di approvazione. Tale registro è davvero utile per individuare il pattern che altrimenti nessuno noterebbe: quanti dei tuoi progetti hanno un criterio di successo espresso come deliverable anziché come valore numerico.
Il PDF serve per la versione approvata, esportata al momento della convalida finale. Poiché un brief è il punto di riferimento per le controversie successive, congelare la versione approvata con una data è più importante qui che per la maggior parte degli altri documenti.
PowerPoint è un contenitore poco adatto. Un brief presentato sotto forma di slide tende a tralasciare l'enunciazione del problema per mantenere la soluzione, per lo stesso motivo descritto in questa pagina.
Come mostrare il problema anziché descriverlo
La parte più difficile di un buon brief è rendere il problema tangibile per chi non lo vive in prima persona. Un numero aiuta. Un paragrafo raramente ci riesce.
Esiste un'alternativa economica che quasi nessuno utilizza: registrare il problema mentre si manifesta.
Due minuti di un operatore dell'assistenza che gestisce una chiamata su "dov'è il mio ordine", o di qualcuno che aggira un passaggio interrotto utilizzando tre schede del browser e un foglio di calcolo, comunicano più di una pagina di descrizione ed è molto difficile controbattere. Allegalo al brief.
L'IA di Trupeer rende tutto questo immediato, poiché una registrazione dello schermo diventa sia un video sia una guida scritta del processo attuale, esattamente ciò di cui ha bisogno la sezione dello stato attuale del brief. Fornisce inoltre al delivery team un riferimento a cui attingere nel momento in cui deve scegliere tra diversi approcci, evitando di affidarsi mesi dopo a quanto scritto sommariamente nel brief.
Registralo. Personalizzalo con il tuo brand. Traducilo. Usa Trupeer.
La stessa registrazione sarà utile successivamente come stato iniziale ("before") nel momento in cui valuterai se il progetto ha avuto successo. Il materiale viene archiviato nella tua knowledge base con un branding coerente, e le istruzioni di configurazione si trovano nella guida all'impostazione dei modelli di documento.
Domande frequenti
Esiste un modello gratuito di project brief in Word?
La struttura sopra riportata può essere incollata direttamente in Word o Google Docs. Non c'è alcun download protetto né moduli da compilare. Le due sezioni da scrivere per prime sono il problema con il relativo dato numerico e i vincoli, poiché tutto il resto scaturisce da essi e sono le due parti che la maggior parte dei modelli gestisce peggio.
Esiste un modello gratuito di project brief in Excel?
Excel è più indicato per un registro dei brief all'interno di un portfolio che per un brief individuale. Colonne per progetto, sponsor, il problema in una riga, il criterio di successo, il vincolo di budget, lo stato e la data di approvazione. Esaminare questo registro alla ricerca di criteri di successo formulati come deliverable è un modo rapido per individuare quali progetti non hanno un risultato misurabile.
Dove posso trovare un esempio di project brief in PDF?
Gli esempi pubblicati sono facili da trovare, anche presso enti del settore pubblico e organizzazioni sanitarie, e vale la pena leggerli per comprendere l'ordine delle sezioni. Leggili in modo critico, poiché gran parte dei brief pubblicati sono in realtà brief focalizzati sulla soluzione, e una lettura poco critica rinforza la cattiva abitudine discussa in questa pagina.
Quanto dovrebbe essere lungo un project brief?
Una o due pagine. I brief più lunghi contengono di solito dettagli di contesto che dovrebbero stare in un'appendice, oppure hanno assorbito il business case. Se il brief non può essere letto in cinque minuti da uno sponsor, verrà scorso rapidamente, e la prima parte a essere saltata sarà proprio l'enunciazione del problema.
Chi dovrebbe redigere il project brief?
Lo sponsor o la persona a cui fa capo il problema, con qualcuno del team di delivery che lo legge prima della diffusione. Questo secondo lettore è fondamentale per intercettare l'errore di proporre direttamente la soluzione, trattandosi della persona che altrimenti passerebbe nove mesi a realizzare la risposta sbagliata.
Qual è la differenza tra un project brief e un creative brief?
Riguarda principalmente l'ambito di applicazione piuttosto che la struttura. Un brief creativo aggiunge il target di riferimento, il messaggio, il tono di voce e il canale, e viene solitamente redatto da un cliente per un'agenzia. Entrambi soffrono allo stesso modo della tendenza a presentare la soluzione, e il test delle tre risposte si applica a entrambi senza alcuna variazione.
Quando deve essere approvato il project brief?
Prima che inizi qualsiasi pianificazione o stima, e in particolare prima che chiunque si sia impegnato verso un approccio. Un brief approvato dopo la scelta dell'approccio è solo una formalità e non sarà d'aiuto in caso di dispute successive sull'ambito, perché tutti ricorderanno l'approccio piuttosto che il documento.
Cosa succede al brief una volta che esiste il piano di progetto?
Dovrebbe essere esplicitamente sostituito e contrassegnato come tale, facendo diventare il piano l'unica fonte dell'ambito concordato. Lasciare il brief attivo come seconda fonte autoritativa rende le controversie sull'ambito impossibili da risolvere, poiché entrambe le parti possono citare un documento diverso. Conserva il brief come storico del problema che si intendeva risolvere, cosa che si rivelerà davvero utile in fase di chiusura.
