Um bom project brief coloca toda a gente na mesma página antes de o projeto começar — o que está a ser construído, porque é importante, quem está envolvido e como é que o sucesso será medido. Com Trupeer, pode poupar horas na escrita de project briefs começando com um modelo gratuito de project brief, personalizando-o com a sua identidade de marca e transformando o brief num resumo em vídeo curto que as partes interessadas podem ver em 3 minutos.

O que é um modelo de project brief e quando é escrito?

Um project brief é o documento curto escrito logo no início de um projeto, antes de existir um plano, que diz para que serve o projeto, porque é importante agora, a quem afeta, como é o sucesso e o que o limita.

É o documento que as pessoas assinam para autorizar o trabalho e que se torna o ponto de referência contra o qual toda a gente discute seis meses mais tarde. Foi deliberadamente mantido curto, normalmente uma ou duas páginas, porque é escrito no momento em que há menos informação.

Um modelo dá-lhe as secções. Contexto, objetivos, âmbito, entregáveis, cronograma, orçamento, partes interessadas, critérios de sucesso. Todas as versões que vai encontrar oferecem, aproximadamente, isso — e não há nada de errado com elas.

O problema dos briefs quase nunca são as secções. É o que se coloca dentro delas.

A maioria dos briefs indica uma solução, não um problema

Aqui está a queixa que todas as equipas de entrega, agências e grupos de engenharia fazem sobre os briefs, expressa da mesma forma em todas as indústrias: fomos briefados sobre a solução.

"Construir um portal do cliente." "Criar uma nova intranet." "Entregar uma aplicação móvel." "Redesenhar o fluxo de onboarding." Cada uma destas opções é algo a construir, apresentada como se fosse um requisito, quando na verdade é a resposta de alguém a uma pergunta que o brief nunca enuncia.

Isto acontece por uma razão perfeitamente razoável. Quem encomenda um projeto tem, normalmente, pensado nele durante semanas e chegou a uma conclusão. Escrever a conclusão parece clareza e escrever o problema parece vaguidão.

O custo é que as soluções mais baratas são eliminadas antes de alguém sequer as analisar. Assim que o brief diz portal, o projeto passa a ser um projeto de portal, e a opção que teria resolvido oitenta por cento do problema com cinco por cento do dinheiro nunca é avaliada, porque ninguém foi convidado a avaliar nada.

Um brief que enuncia um problema convida a respostas. Um brief que enuncia uma solução convida a estimativas.

Como personalizar este modelo no Trupeer

Passo 1: Abra a secção Templates

Vá à secção Templates no menu principal.

Passo 2: Selecione e abra um modelo

Clique em qualquer modelo com que queira trabalhar para o abrir.

Passo 3: Expanda a vista do modelo

Se necessário, expanda a vista do modelo para ver o layout completo e os detalhes com clareza.

Passo 4: Edite o modelo

Clique em Edit para começar a modificar o modelo selecionado.

No editor, pode:

• Adicionar novas secções

• Definir ou atualizar regras de formatação

• Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guarde o seu modelo personalizado

Depois de fazer todas as alterações necessárias, clique em Save para guardar o modelo atualizado como seu.

Passo 6: Pré-visualize e ajuste o modelo

Quando quiser ver como fica o seu modelo personalizado, abra a opção Preview.

A partir do ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o pretende.

Com um modelo de project brief pode:

• Poupar horas na escrita: Ignore a página em branco com uma estrutura de brief comprovada.

• Alinhar rapidamente as partes interessadas: Os briefs de uma página tornam as aprovações e o alinhamento mais rápidos.

• Manter-se fiel à marca: Aplique o seu logótipo, fontes e cores usando o brand kit da Trupeer — perfeito para briefs de agências e de clientes.

• Apresentar com impacto: Converta o brief num resumo em vídeo — ótimo para sales enablement e para apresentações às partes interessadas.

• Uniformizar entre projetos: Use o mesmo formato de brief para cada iniciativa.

• Aceder a equipas globais: Traduza briefs para 65+ idiomas com um único clique.

O teste das três respostas para qualquer project brief

Dois minutos — e é o único teste de brief que vale a pena fazer.

Leia o brief e indique três coisas genuinamente diferentes que o satisfariam.

Não três variações da mesma coisa. Três abordagens diferentes: construir algo, mudar um processo, comprar algo, remover um passo, comunicar de forma diferente, fazer menos.

Se conseguir indicar três, o brief descreve um problema e o projeto tem uma decisão real pela frente.

Se só conseguir indicar uma, o brief descreve uma solução. Isso não está automaticamente errado, porque por vezes a decisão foi realmente tomada por boas razões — e, nesse caso, a atitude honesta é dizer isso e chamar ao documento uma especificação em vez de um brief. O que não é honesto é apresentar uma conclusão já tomada como uma pergunta em aberto e depois ficar surpreendido por ninguém a ter contestado.

Faça este teste ao brief antes de o distribuir, com alguém que não tenha estado envolvido na sua escrita. A pessoa que o escreveu consegue sempre indicar três, porque sabe o que rejeitou. Ninguém mais consegue, porque o brief não o contém.

Como escrever o problema em vez do entregável

Quatro hábitos, e nenhum deles demora mais do que escrever a solução.

Comece com uma observação e um número. Não "os clientes têm dificuldade em verificar as suas encomendas" mas "os clientes contactaram-nos seis mil e setecentas vezes no mês passado para saber onde está a sua encomenda". O número faz duas coisas: estabelece que o problema é real e dá dimensão ao valor que uma solução tem.

Diga o que acontece agora. Como é que o problema é tratado atualmente, mal, incluindo o workaround que as pessoas inventaram. A descrição do estado atual é o que permite a alguém propor uma resposta mais barata.

Separe as restrições dos requisitos. Um orçamento é uma restrição. Um prazo é uma restrição. Ter de integrar com o sistema de armazém existente é uma restrição. "É necessário ter login" é um requisito disfarçado de restrição e normalmente chega a partir da imagem mental da solução que alguém tem.

Defina o sucesso como uma mudança no número, e não como a existência de um entregável. Reduzir esses contactos para metade em seis meses é um critério de sucesso. Lançar um portal é um marco.

Quando tiver mesmo uma solução em mente, coloque-a numa secção claramente identificada a dizer isso, como um candidato e não como o brief.

Modelo gratuito de project brief: a estrutura para copiar

Copie daqui. Uma ou duas páginas, e resista à expansão.

Cabeçalho. Nome do projeto, patrocinador, autor, data, versão e a decisão que está a ser solicitada.

O problema. Uma observação com um número, com que frequência ocorre e quanto custa. Dois ou três parágrafos.

Como é tratado atualmente. O processo atual, incluindo o workaround, e por que não é suficientemente bom.

Por que agora. O que mudou e torna isto valioso fazer neste trimestre em vez do próximo ano.

Quem é afetado. As pessoas ou clientes envolvidos e, aproximadamente, quantos são.

Critérios de sucesso. Que número muda, em quanto e até quando. Um ou dois, expressos como resultados.

Restrições. Orçamento, prazo, sistemas que não podem mudar, obrigações regulamentares ou contratuais, pessoas indisponíveis. Tudo o que é realmente fixo e nada que seja, na prática, uma preferência.

Fora do âmbito. O que este projeto não vai abordar, nomeado com detalhe suficiente para ser controverso.

Abordagens candidatas, se existirem. Soluções já consideradas, claramente identificadas como candidatas e não como o brief, com a razão de cada uma estar na lista.

Decisão pretendida e por quem. O que está a pedir e quem o vai autorizar.

Copie até aqui. Se o brief passar de duas páginas, a causa habitual é o contexto, que pertence a um apêndice que ninguém vai ler — e isso está bem.

O retalhista que construiu um portal para o qual ninguém se registou

A Ashfold Group é um retalhista especializado com cerca de noventa lojas e um negócio online substancial.

O brief tinha duas páginas, estava bem escrito e foi aprovado sem dificuldade. Dizia: construir um portal de autoatendimento do cliente onde os clientes podem iniciar sessão para ver o estado das encomendas, descarregar faturas e levantar questões. Orçamento: trezentas e quarenta mil libras. Nove meses.

Foi entregue a tempo e perto do orçamento, a trezentas e setenta e uma mil.

Seis meses após o lançamento, havia três mil e cem contas registadas face a cerca de quarenta e seis mil clientes ativos, ou seja, menos de sete por cento. O volume de contactos para o centro de atendimento manteve-se inalterado.

A revisão pós-implementação colocou uma pergunta simples: que problema é que isto foi construído para resolver? Ninguém conseguiu apontar isso no brief, porque o brief tinha descrito uma solução.

Então alguém foi e encontrou o problema. O centro de atendimento tratava cerca de onze mil contactos por mês. Uma amostra de quinhentos mostrou que sessenta e um por cento eram uma versão de "onde está a minha encomenda", o que corresponde a cerca de seis mil e setecentos contactos por mês.

Desses clientes, oitenta e quatro por cento já tinham recebido um email de expedição com uma ligação de tracking. Ou não tinham visto isso, ou voltaram a consultar depois de a ligação expirar ao fim de catorze dias.

O problema dominante, portanto, não era que os clientes não tinham forma de verificar. Era que a forma que já tinham não funcionava.

Três abordagens mais baratas nunca tinham sido avaliadas, porque o brief não convidava nenhuma. Estender a validade da ligação de tracking. Reenviar a ligação num calendário até à entrega. Adicionar o estado da encomenda à área da conta que já existia, estimado depois em cerca de dezoito mil libras.

O portal era uma solução legítima para um problema real. Não era o maior problema e exigia registo, algo que noventa e três por cento dos clientes nunca fizeram.

O brief para o projeto de acompanhamento foi escrito de forma diferente. Os clientes contactam-nos seis mil e setecentas vezes por mês para saber onde está a sua encomenda. Oitenta e quatro por cento deles já tinham recebido uma ligação de tracking. Reduzir esses contactos para metade em seis meses. Restrições: sem alteração à integração com o transportador, cento e cinquenta mil libras, e tem de funcionar sem exigir que os clientes se registem.

Três equipas propuseram três respostas genuinamente diferentes. A escolhida custou sessenta e dois mil libras e reduziu esses contactos em cinquenta e oito por cento em cinco meses.

A diferença entre os dois briefs é que o segundo podia ser respondido de três formas. O primeiro podia ser respondido de uma forma — e essa forma já tinha sido escolhida.

Os elementos-chave que todo o project brief precisa

As duas linhas que pesam mais são o estado atual e as restrições — e ambas são normalmente pouco desenvolvidas. O estado atual é o que permite a alguém propor a resposta barata. As restrições, separadas honestamente das preferências, são o que impede que um brief se torne uma especificação por acidente.

Como escrever um project brief em cinco passos

Um. Escreva o problema com um número. Se não conseguir obter um número, passe uma tarde a consegui-lo. Um brief sem número é uma preferência.

Dois. Descreva o estado atual, incluindo como as pessoas contornam isso hoje.

Três. Defina o sucesso como uma mudança nesse número, com uma data.

Quatro. Liste as restrições e desafie cada uma. Para cada item, pergunte quem definiu isto e se poderia mudar. Aproximadamente um terço costuma poder, e cada restrição que muda alarga o intervalo de respostas possíveis.

Cinco. Faça o teste das três respostas com alguém que não o tenha escrito. Se falhar, ou abra o brief, ou identifique o documento de forma honesta.

Depois, distribua-o e espere que as respostas que receber incluam pelo menos uma que não tinha pensado. Se nenhuma o surpreender, o brief era provavelmente uma especificação.

Restrições — e como são introduzidas como requisitos

É aqui que a maioria dos briefs se transforma silenciosamente em especificações, e isso acontece sem que ninguém tenha intenção.

Uma restrição genuína é algo fora do controlo do projeto. O orçamento é o que é. O prazo regulamentar está fixo. O sistema de armazém não está a ser substituído este ano. A equipa tem quatro pessoas.

Uma preferência vestida de restrição parece idêntica. Tem de ser uma aplicação móvel. Precisa de um dashboard. Os utilizadores devem ter login. Cada uma destas opções é a imagem mental de alguém sobre a resposta e, assim que entra na secção de restrições, é tratada como imutável por toda a gente a jusante.

O teste é perguntar, para cada item, quem decidiu isto e o que acontece se mudar. Uma restrição real tem um responsável fora do projeto e uma consequência se for violada. Uma preferência não tem nenhum, e normalmente a pessoa que a escreveu vai simplesmente deixá-la cair se lhe perguntarem diretamente.

Faça essa conversa antes de o brief ser distribuído. Leva vinte minutos e é frequentemente o valor mais alto desses vinte minutos em todo o projeto, porque cada restrição removida adiciona uma resposta possível.

Project brief, business case ou plano de projeto?

Três documentos no início de um projeto, em sequência, com funções diferentes.

O brief define o problema, as restrições e os critérios de sucesso. É escrito primeiro, é curto e autoriza a investigação ou a entrega.

O business case justifica o investimento. Contém opções com custos e benefícios e é o que uma função de finanças ou um conselho de investimento aprova. Um brief que ficou longo e cheio de números é, normalmente, um business case com o nome errado.

O plano de projeto descreve como é que a abordagem escolhida será entregue: âmbito, calendário, recursos, dependências e risco. O nosso modelo de plano de projeto de TI cobre essa camada.

A sequência importa. Brief, depois opções, depois business case, depois plano. Escrever o plano antes do brief — algo que acontece com mais frequência do que qualquer pessoa admite — significa que a abordagem foi escolhida antes de o problema ser enunciado.

Assim que o plano existir, o brief deve ser explicitamente substituído, em vez de ficar guardado como uma segunda fonte de âmbito acordado. Dois documentos a reivindicar autoridade é como as disputas de âmbito se tornam irresolúveis.

Variantes de project brief: criativo, design, software e construção

A estrutura mantém-se entre tipos e o foco muda.

Briefs criativos e de marketing precisam do público e da mensagem, e são os mais suscetíveis a solution-briefing, porque o cliente chega com um formato em mente. O problema aqui é, normalmente, um comportamento que quer mudar e não uma coisa que quer criar.

Briefs de design precisam do utilizador, do contexto de utilização e das restrições do sistema existente. Quase todos os briefs nesta categoria beneficiam do teste das três respostas, porque um brief de design que especifica um layout remove o design.

Briefs de projetos de software precisam do problema e do workaround atual mais do que qualquer outra coisa, e devem manter-se totalmente afastados de funcionalidades. Assim que as funcionalidades entram no âmbito, está a escrever um documento de requisitos, o que o nosso modelo de lean PRD cobre.

Briefs de construção e de design incluem restrições que, de facto, são restrições: local, planeamento, regulamentação, orçamento. Aqui, a secção de restrições é o conteúdo, e não o risco.

Projetos com forte componente de procurement precisam que o brief diga o que está a ser comprado como resultado e não como especificação, uma vez que a decisão sobre a maturidade da especificação vem mais tarde e o nosso modelo de plano de gestão de procurement cobre isso.

Posso obter um modelo de project brief em Word ou Excel?

Word ou Google Docs. Um brief é texto corrido; são uma ou duas páginas e é comentado antes de ser aprovado. Não há nada nele que queira uma folha de cálculo.

O Excel só faz sentido se estiver a gerir muitos projetos e quiser um registo: projeto, patrocinador, problema numa linha, critério de sucesso, restrição de orçamento, estado e data de aprovação. Esse registo é, de facto, útil para detetar o padrão que, de outra forma, ninguém vê — e é assim que muitos dos seus projetos têm um critério de sucesso expresso como entregável em vez de como número.

PDF para a versão aprovada, exportado no momento do sign-off. Como um brief é o ponto de referência para disputas futuras, congelar a versão aprovada com uma data é mais importante aqui do que na maioria dos documentos.

PowerPoint é um recipiente fraco. Um brief apresentado como slides tende a perder a formulação do problema e a manter a solução, pela mesma razão descrita ao longo desta página.

Como mostrar o problema em vez de o descrever

A parte mais difícil de um bom brief é fazer com que um problema pareça real para pessoas que não o vivenciam. Um número ajuda. Um parágrafo raramente ajuda.

Existe uma alternativa barata que quase ninguém usa: registar o problema a acontecer.

Dois minutos de um agente de serviço a tratar uma chamada "onde está a minha encomenda" ou de alguém a contornar um passo avariado com três separadores do browser e uma folha de cálculo comunicam mais do que uma página de descrição e é muito difícil de contestar. Anexe-o ao brief.

O Trupeer AI torna isso simples, porque uma gravação de ecrã passa a ser tanto um vídeo como um guia escrito do processo atual — exatamente o que a secção de estado atual do brief precisa. Também dá à equipa de entrega algo para consultar quando estiver a decidir entre abordagens, em vez de depender da redação do brief meses mais tarde.

Registe. Dê marca. Traduza. Trupeer.

A mesma gravação é útil depois como estado anterior quando mede se o projeto funcionou. O material vive na sua knowledge base com branding consistente, e as instruções de configuração estão no guia de configuração do modelo de documento.

Perguntas Frequentes

Existe um modelo gratuito de project brief em Word?

A estrutura acima é colada diretamente no Word ou no Google Docs. Não há download condicionado nem formulário. As duas secções que deve escrever primeiro são o problema com o seu número e as restrições, porque tudo o resto decorre delas e são as duas secções em que os modelos lidam melhor com o que é mais fraco.

Existe um modelo gratuito de project brief em Excel?

O Excel é adequado para um registo de briefs ao longo de um portefólio, em vez de um brief individual. Colunas para projeto, patrocinador, problema numa linha, critério de sucesso, restrição de orçamento, estado e data de aprovação. Ver esse registo à procura de critérios de sucesso expressos como entregáveis é uma forma rápida de identificar quais os projetos que não têm um resultado mensurável.

Onde posso encontrar um exemplo de project brief em PDF?

Os exemplos publicados são fáceis de encontrar, incluindo de entidades do setor público e organizações de saúde, e valem a pena ser lidos pela ordem das secções. Leia-os de forma crítica, uma vez que uma grande parte dos briefs publicados são briefs de solução e lê-los sem criticidade reforça o hábito de que esta página trata.

Quanto tempo deve ter um project brief?

Uma ou duas páginas. Os briefs mais longos costumam incluir contexto que pertence a um apêndice, ou absorveram o business case. Se o brief não puder ser lido em cinco minutos por um patrocinador, será lido à pressa, e a secção lida à pressa primeiro é a formulação do problema.

Quem deve escrever o project brief?

O patrocinador ou a pessoa que é responsável pelo problema, com alguém da entrega a lê-lo antes de ser distribuído. Esse segundo leitor é o que deteta solution-briefing, porque é a pessoa que, de outra forma, passaria nove meses a construir a resposta errada.

Qual é a diferença entre um project brief e um creative brief?

Sobretudo é uma questão de domínio, não de estrutura. Um creative brief acrescenta público, mensagem, tom e canal, e é normalmente escrito por um cliente para uma agência. Ambos sofrem de solution-briefing da mesma forma e o teste das três respostas aplica-se a ambos sem modificação.

Quando deve o project brief ser aprovado?

Antes de começar qualquer planeamento ou estimativa e, especificamente, antes de alguém se comprometer com uma abordagem. Um brief aprovado depois de a abordagem ser escolhida é uma formalidade e não ajuda quando o âmbito é contestado mais tarde, porque toda a gente se vai lembrar da abordagem em vez do documento.

O que acontece ao brief depois de existir o plano do projeto?

Deve ser explicitamente substituído e marcado como tal, passando o plano a ser a única fonte de âmbito acordado. Deixar o brief ativo como uma segunda autoridade é o que torna as disputas de âmbito irresolúveis, porque ambas as partes podem citar um documento. Mantenha o brief como registo do problema que estava a ser resolvido, o que é genuinamente útil no encerramento.