Un ottimo brief di progetto mette tutti d'accordo prima dell'inizio del progetto stesso: cosa si sta realizzando, perché è importante, chi è coinvolto e come verrà misurato il successo. Con Trupeer, puoi risparmiare ore nella stesura dei brief di progetto partendo da un modello di brief di progetto gratuito, personalizzandolo con la tua brand identity e trasformando il brief in un breve video riassuntivo che gli stakeholder possono guardare in 3 minuti.

Cos'è un modello di brief di progetto e quando viene scritto?

Un brief di progetto è il breve documento scritto all'inizio di un progetto, prima che esista il piano, che indica a cosa serve il progetto, perché è importante ora, chi ne è influenzato, come appare il successo e quali sono i suoi vincoli.

È l'elemento che le persone firmano per autorizzare il lavoro e diventa il punto di riferimento che tutti contestano sei mesi dopo. È deliberatamente 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 queste sezioni, e non c'è nulla di male.

Il problema dei brief non sono quasi mai le sezioni. È ciò che ci viene inserito.

La maggior parte dei brief indica una soluzione, non un problema

Ecco la lamentela che ogni team di delivery, agenzia e gruppo di ingegneria fa riguardo ai brief, espressa allo stesso modo in ogni settore: siamo stati istruiti sulla soluzione.

"Costruire un portale clienti." "Creare una nuova intranet." "Fornire un'app mobile." "Riprogettare il flusso di onboarding." Ciascuno di questi è un elemento da costruire, che arriva come se fosse un requisito, quando in realtà è la risposta di qualcuno a una domanda che il brief non dichiara mai.

Questo accade per una ragione comprensibile. Chi commissiona un progetto di solito ci pensa da settimane ed è giunto a una conclusione. Scrivere la conclusione dà una sensazione di chiarezza, mentre scrivere il problema sembra dare un senso di vaghezza.

Il costo è che le soluzioni più economiche vengono eliminate prima ancora che qualcuno le esamini. Una volta che il brief dice "portale", il progetto diventa un progetto di portale, e l'opzione che avrebbe risolto l'ottanta percento del problema con il cinque percento del budget non viene mai valutata, perché a nessuno è stato chiesto di valutare nulla.

Un brief che enuncia un problema invita a trovare risposte. Un brief che enuncia una soluzione invita a fare preventivi.

Come personalizzare questo modello in Trupeer

Passo 1: Apri la sezione Modelli

Vai alla sezione Modelli dalla navigazione principale.

Passo 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passo 3: Espandi la visualizzazione del modello

Se necessario, espandi la visualizzazione del modello per vedere chiaramente il layout completo e i dettagli.

Passo 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare 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 relative impostazioni

Passo 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passo 6: Visualizza l'anteprima e perfeziona il modello

Quando vuoi vedere l'aspetto del tuo 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 brief di progetto puoi:

• Risparmiare ore di scrittura: Evita la pagina bianca grazie a una struttura di brief collaudata.

• Allineare gli stakeholder rapidamente: I brief di una sola pagina rendono più veloci le approvazioni e l'allineamento.

• Mantenere la coerenza del brand: Applica il tuo logo, font e colori usando il kit del brand di Trupeer, perfetto per i brief di agenzie e clienti.

• Presentare con impatto: Converti il brief in un video riassuntivo, ideale per il sales enablement e le presentazioni agli 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 brief di progetto

Due minuti, ed è l'unico test sul brief che valga la pena fare.

Leggi il brief e nomina tre cose sinceramente diverse che lo soddisfarebbero.

Non tre variazioni della stessa cosa. Tre approcci diversi: costruire qualcosa, cambiare un processo, acquistare qualcosa, rimuovere un passaggio, comunicare in modo diverso, fare meno.

Se riesci a nominarne tre, il brief descrive un problema e il progetto ha davanti a sé una vera decisione.

Se riesci a nominarne solo una, il brief descrive una soluzione. Questo non è automaticamente sbagliato, perché a volte la decisione è stata presa sinceramente per ottime ragioni, e in tal caso la cosa onesta da fare è dirlo e chiamare il documento "specifica" piuttosto che brief. Ciò che non è onesto è presentare una conclusione scontata come una questione aperta e poi stupirsi che nessuno l'abbia messa in discussione.

Fai questo test sul brief prima che venga distribuito, con qualcuno che non è stato coinvolto nella sua stesura. Chi lo ha scritto può sempre nominarne tre, perché sa cosa ha scartato. Nessun altro può farlo, perché il brief non lo contiene.

Come scrivere il problema invece del deliverable

Quattro abitudini, e nessuna di esse richiede più tempo di quanto ne richiederebbe scrivere la soluzione.

Inizia con un'osservazione e un numero. Non "i clienti trovano difficile controllare i propri ordini" ma "i clienti ci hanno contattato seimilasettecento volte il mese scorso per chiedere dove fosse il loro ordine". Il numero fa due cose: stabilisce che il problema è reale e definisce quanto vale una soluzione.

Dichiara cosa succede ora. Come viene gestito attualmente il problema, in modo inefficiente, comprese le soluzioni alternative che le persone hanno inventato. La descrizione dello stato attuale è ciò che consente a qualcuno di proporre una risposta più economica.

Separa i vincoli dai requisiti. Un budget è un vincolo. Una scadenza è un vincolo. L'integrazione obbligatoria con il sistema di magazzino esistente è un vincolo. "Deve avere un login" è un requisito mascherato da vincolo, e di solito deriva dall'immagine mentale che qualcuno ha della soluzione.

Definisci il successo come una variazione del numero, non come l'esistenza di un deliverable. Ridurre della metà i contatti entro sei mesi è un criterio di successo. Lanciare un portale è una pietra miliare (milestone).

Laddove tu abbia sinceramente in mente una soluzione, inseriscila in una sezione chiaramente etichettata che lo indichi, come una delle opzioni candidate anziché come l'intero brief.

Modello di brief di progetto gratuito: la struttura da copiare

Copia da qui. Una o due pagine, e resisti alla tentazione di espanderlo.

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, comprese le soluzioni alternative, e perché non è sufficientemente valido.

Perché ora. Cosa è cambiato che rende questo progetto meritevole di essere realizzato in questo trimestre piuttosto che l'anno prossimo.

Chi è influenzato. Le persone o i clienti coinvolti, e all'incirca quanti.

Criteri di successo. Quale numero cambia, di quanto, entro quando. Uno o due, espressi come risultati (outcomes).

Vincoli. Budget, scadenze, sistemi che non possono essere modificati, obblighi normativi o contrattuali, persone non disponibili. Tutto ciò che è realmente fisso, e nulla che sia in realtà una preferenza.

Fuori ambito (Out of scope). Ciò che questo progetto non affronterà, nominato in modo sufficientemente specifico da essere controverso.

Approcci candidati, se presenti. Soluzioni già considerate, chiaramente etichettate come candidate piuttosto che come il brief stesso, con il motivo per cui ciascuna è presente nell'elenco.

Decisione richiesta e da parte di chi. Cosa stai chiedendo e chi lo sta autorizzando.

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à, il che va benissimo.

Il rivenditore che ha costruito un portale su cui nessuno si è registrato

Ashfold Group è un rivenditore specializzato con circa novanta negozi e un consistente business online.

Il brief era di due pagine, ben scritto e approvato senza difficoltà. Diceva: costruire un portale self-service per i clienti in cui i clienti possano accedere per visualizzare lo stato dell'ordine, scaricare fatture e porre domande. Budget trecentoquarantamila sterline. Nove mesi.

È stato consegnato in tempo e quasi in linea con il 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 al centro assistenza era invariato.

La revisione post-implementazione ha posto una domanda semplice: quale problema è stato costruito per risolvere. Nessuno ha saputo indicarlo nel brief, perché il brief aveva descritto una soluzione.

Quindi qualcuno è andato a cercare il problema. Il centro assistenza gestiva circa undicimila contatti al mese. Un campione di cinquecento ha mostrato che il sessantuno percento era una qualche versione di "dov'è il mio ordine", che corrisponde a 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, o vi erano tornati dopo che il link era scaduto a quattordici giorni.

Il problema principale non era quindi che i clienti non avessero modo di verificare. Era che il modo in cui già disponevano non funzionava.

Tre approcci più economici non erano mai stati valutati, perché il brief non ne aveva invitato alcuno. Estendere la validità del link di tracciamento. Reinviare il link su base programmata fino alla consegna. Aggiungere lo stato dell'ordine all'area account già esistente, stimata successivamente a circa diciottomila sterline.

Il portale era una soluzione legittima a un problema reale. Ma 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 in modo diverso. I clienti ci contattano seimilasettecento volte al mese per chiedere dove si trova 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 dei clienti.

Tre team hanno proposto tre risposte sinceramente diverse. Quella scelta è costata sessantaduemila sterline e ha ridotto i contatti del cinquantotto percento in 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 brief di progetto ha bisogno

Le due righe che hanno il peso maggiore sono lo stato attuale e i vincoli, ed entrambe sono solitamente scarne. Lo stato attuale è ciò che permette a qualcuno di proporre la soluzione economica. I vincoli, onestamente separati dalle preferenze, sono ciò che impedisce a un brief di diventare accidentalmente una specifica.

Come scrivere un brief di progetto in cinque passaggi

Uno. Scrivi il problema con un numero. Se non riesci a ottenere un numero, passa un pomeriggio a cercarne uno. Un brief senza un numero è solo una preferenza.

Due. Descrivi lo stato attuale, incluso il modo in cui le persone vi pongono rimedio oggi.

Tre. Imposta il successo come una variazione di quel numero, con una data.

Quattro. Elenca i vincoli e metti in discussione ognuno di essi. Per ogni elemento, chiediti chi lo ha stabilito e se può essere modificato. Di solito circa un terzo può esserlo, e ognuno che cambia amplia la gamma delle risposte possibili.

Cinque. Fai il test delle tre risposte con qualcuno che non lo ha scritto. Se fallisce, apri il brief o rinomina onestamente il documento.

Poi distribuiscilo e aspettati che le risposte che riceverai includano almeno una a cui non avevi pensato. Se nessuna ti sorprende, il brief era probabilmente una specifica.

I vincoli e come vengono spacciati per requisiti

È qui che la maggior parte dei brief diventa silenziosamente una specifica, e accade senza che nessuno lo voglia.

Un vero vincolo è qualcosa al di fuori del controllo del progetto. Il budget è quello che è. La scadenza normativa è fissa. Il sistema di magazzino non verrà sostituito quest'anno. Il team è composto da quattro persone.

Una preferenza travestita da vincolo suona in modo identico. Deve essere un'app mobile. Ha bisogno di una dashboard. Gli utenti devono avere un login. Ciascuno di questi è l'immagine mentale che qualcuno ha della risposta e, una volta inserita nella sezione dei vincoli, viene trattata come inamovibile da chiunque venga dopo.

Il test consiste nel chiedere, per ogni elemento, chi ha deciso questo e cosa succede se cambia. Un vero vincolo ha un proprietario esterno al progetto e una conseguenza in caso di violazione. Una preferenza non ha né l'uno né l'altra e, di solito, la persona che l'ha scritta la abbandonerà volentieri se glielo si chiede direttamente.

Fai questa conversazione prima che il brief venga distribuito. Richiede venti minuti ed è spesso l'attività a più alto valore di tutto il progetto, perché ogni vincolo rimosso aggiunge una possibile risposta.

Brief di progetto, business case o piano di progetto?

Tre documenti all'inizio di un progetto, in sequenza, con compiti diversi.

Il brief dichiara il problema, i vincoli e i criteri di successo. Viene scritto per primo, è breve e autorizza l'indagine o la consegna.

Il business case giustifica la spesa. Contiene opzioni con costi e benefici, ed è ciò che una funzione finanziaria o un comitato di investimento approva. Un brief che è diventato lungo e pieno di numeri è di solito un business case con il nome sbagliato.

Il piano di progetto copre il modo in cui verrà realizzato l'approccio scelto: ambito, programma, risorse, dipendenze e rischi. Il nostro modello di piano di progetto IT copre questo livello.

La sequenza è importante. Prima il brief, poi le opzioni, poi il business case e 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 venisse enunciato il problema.

Una volta che il piano esiste, il brief dovrebbe essere esplicitamente sostituito piuttosto che lasciato in archivio come seconda fonte di ambito concordato. Due documenti che rivendicano autorità sono il modo in cui le controversie sull'ambito diventano irrisolvibili.

Varianti del brief di progetto: creativo, design, software e costruzione

La struttura regge per tutti i tipi, ma l'enfasi cambia.

I brief creativi e di marketing hanno bisogno del pubblico e del messaggio, e sono i più inclini alla stesura di soluzioni, perché il cliente arriva con un formato in mente. Il problema qui è solitamente un comportamento che si desidera cambiare piuttosto che un oggetto che si desidera realizzare.

I brief di design hanno bisogno dell'utente, del contesto d'uso e dei vincoli del sistema esistente. Quasi tutti i brief di questa categoria beneficiano del test delle tre risposte, perché un brief di design che specifica un layout ha eliminato il design stesso.

I brief di progetti software hanno bisogno del problema e della soluzione alternativa attuale più di ogni altra cosa, e dovrebbero tenersi del tutto alla larga dalle funzionalità. Una volta che le funzionalità sono nell'ambito, stai scrivendo un documento di requisiti, che il nostro modello di PRD snello copre.

I brief di costruzione e progettazione portano vincoli che sono realmente vincoli: sito, pianificazione, regolamentazione, budget. Qui la sezione dei vincoli rappresenta la sostanza piuttosto che il rischio.

I progetti ad alto tasso di approvvigionamento hanno bisogno del brief per indicare ciò che viene acquistato come risultato piuttosto che come specifica, poiché la decisione sulla maturità della specifica arriva in seguito e il nostro modello di piano di gestione degli approvvigionamenti la copre.

Posso ottenere un modello di brief di progetto in Word o Excel?

Word o Google Docs. Un brief è testo, è di una o due pagine e riceve commenti prima dell'approvazione. Non c'è nulla in esso che richieda un foglio di calcolo.

Excel merita un posto solo se gestisci molti progetti e desideri un registro: progetto, sponsor, problema in una riga, criterio di successo, vincolo di budget, stato e data di approvazione. Quel registro è davvero utile per individuare lo schema che altrimenti nessuno vede, ovvero quanti dei tuoi progetti hanno un criterio di successo espresso come deliverable piuttosto che come numero.

PDF per la versione approvata, esportata al momento della firma. Poiché un brief è il punto di riferimento per future controversie, congelare la versione approvata con una data è più importante qui che per la maggior parte dei documenti.

PowerPoint è un contenitore inadatto. Un brief presentato come diapositive tende a perdere la dichiarazione del problema e a mantenere la soluzione, per lo stesso motivo descritto in questa pagina.

Come mostrare il problema invece di descriverlo

La parte più difficile di un buon brief è far sembrare reale un problema a persone che non lo vivono. Un numero aiuta. Un paragrafo raramente ci riesce.

C'è un'alternativa economica che quasi nessuno usa: registrare il problema mentre si verifica.

Due minuti di un operatore del servizio clienti che gestisce una chiamata "dov'è il mio ordine", o di qualcuno che rimedia a un passaggio interrotto con tre schede del browser e un foglio di calcolo, comunicano più di una pagina di descrizione ed è molto difficile controbattere. Allegalo al brief.

Trupeer AI rende tutto questo semplice, poiché una registrazione dello schermo diventa sia un video che una guida scritta del processo attuale, che è esattamente ciò di cui ha bisogno la sezione dello stato attuale del brief. Offre inoltre al team di sviluppo qualcosa a cui fare riferimento quando deve scegliere tra diversi approcci, anziché affidarsi alla formulazione del brief mesi dopo.

Registralo. Personalizzalo con il tuo brand. Traducilo. Usa Trupeer.

La stessa registrazione è utile in seguito come stato precedente ("prima") quando misuri se il progetto ha funzionato. Il materiale risiede nella tua base di conoscenza con un branding coerente, e le istruzioni di configurazione sono nella guida alla configurazione del modello di documento.

Domande frequenti

Esiste un modello di brief di progetto gratuito in Word?

La struttura sopra descritta si incolla direttamente in Word o Google Docs. Non c'è nessun download protetto e nessun modulo. Le due sezioni da scrivere per prime sono il problema con il suo numero e i vincoli, poiché tutto il resto ne consegue e sono le due sezioni che la maggior parte dei modelli gestisce peggio.

Esiste un modello di brief di progetto gratuito in Excel?

Excel è più adatto per un registro di brief su un intero portfolio piuttosto che per un singolo brief. Colonne per progetto, sponsor, il problema in una riga, il criterio di successo, il vincolo di budget, lo stato e la data di approvazione. Scorrere quel registro alla ricerca di criteri di successo espressi come deliverable è un modo rapido per scoprire quali progetti non hanno un risultato misurabile.

Dove posso trovare un esempio di brief di progetto in PDF?

Gli esempi pubblicati sono facili da trovare, anche da parte di enti pubblici e organizzazioni sanitarie, e vale la pena leggerli per l'ordine delle sezioni. Leggili con occhio critico, poiché una grande percentuale di brief pubblicati sono brief di soluzioni e leggerli acriticamente rafforza l'abitudine di cui tratta questa pagina.

Quanto dovrebbe essere lungo un brief di progetto?

Una o due pagine. I brief più lunghi di solito contengono un contesto che appartiene a un'appendice, oppure hanno assorbito il business case. Se il brief non può essere letto in cinque minuti da uno sponsor, verrà letto superficialmente, e la sezione saltata per prima sarà la dichiarazione del problema.

Chi dovrebbe scrivere il brief di progetto?

Lo sponsor o la persona a cui appartiene il problema, con qualcuno del team di sviluppo che lo legga prima che venga distribuito. Quel secondo lettore è colui che intercetta la stesura di soluzioni, perché altrimenti sarà la persona che passerà nove mesi a costruire la risposta sbagliata.

Qual è la differenza tra un brief di progetto e un brief creativo?

Principalmente l'ambito piuttosto che la struttura. Un brief creativo aggiunge pubblico, messaggio, tono e canale, e di solito viene scritto da un cliente per un'agenzia. Entrambi soffrono allo stesso modo della stesura di soluzioni, e il test delle tre risposte si applica a entrambi senza modifiche.

Quando dovrebbe essere approvato il brief di progetto?

Prima che inizi qualsiasi pianificazione o stima, e in particolare prima che chiunque si sia impegnato in un approccio. Un brief approvato dopo che l'approccio è stato scelto è una formalità e non aiuterà quando l'ambito verrà contestato in seguito, perché tutti si ricorderanno dell'approccio piuttosto che del documento.

Cosa succede al brief una volta che esiste il piano di progetto?

Dovrebbe essere esplicitamente sostituito e contrassegnato come tale, con il piano che diventa l'unica fonte dell'ambito concordato. Lasciare il brief attivo come seconda autorità è ciò che rende irrisolvibili le controversie sull'ambito, poiché entrambe le parti possono citare un documento. Conserva il brief come record di quale problema si stava risolvendo, il che è davvero utile al momento della chiusura.