Status report de projeto: as seis partes, o farol e o que ele não pode esconder

Existe um relatório que quase todo projeto produz e quase nenhum lê até o fim. Ele chega por e-mail na sexta, tem um farol verde no topo, três parágrafos de texto e uma lista de próximos passos. Quem recebe olha o farol, conclui que está tudo bem e arquiva. Seis semanas depois o projeto atrasa, e a primeira pergunta é por que ninguém avisou. O status report avisou — só não de um jeito que pudesse ser lido.

A ferramenta que eu uso resolve isso por estrutura, não por boa vontade. Ela tem seis partes fixas, e duas delas existem justamente para impedir o relato confortável: a tabela de desvios, em que cada linha precisa citar a referência que a sustenta, e a justificativa do farol, que obriga quem pinta de verde a dizer por quê.

Este texto trata do documento do período, não do plano do projeto. Se o que você procura é como medir avanço contra linha de base, isso é assunto da curva S e do valor agregado. Aqui o assunto é o retrato: o que ele precisa mostrar, o que ele costuma esconder, e como ler o de outra pessoa.

Você vai ver as seis partes uma a uma, a regra do farol com os três critérios, por que desvio sem referência não é desvio, a diferença entre relatar avanço e relatar entrega, como escrever o relato de um período ruim, os erros que aparecem sempre, e um teste de dez minutos para saber se o seu relatório está sendo lido.

Sobre a procedência dos exemplos: as linhas de relato que aparecem no texto foram montadas para este artigo a partir do formato da ferramenta M13 do Kit Gestão de Projetos da Voitto. São ilustrativas — servem para mostrar o nível de detalhe que cada campo pede, não para relatar um projeto real.

O que é o status report

O status report é o retrato de um período de acompanhamento: o que avançou, o que desviou do planejado, e o que vem a seguir. Um relatório por período, sem exceção — período sem relato é período sem informação, e a lacuna sempre aparece depois, quando alguém tenta reconstruir a trajetória.

Ele não é um resumo do plano nem uma lista de tarefas concluídas. A diferença é de destinatário: o plano é escrito para quem executa, e o status report é escrito para quem decide sem acompanhar o dia a dia. Isso muda tudo — o que é óbvio para a equipe precisa estar dito, e o que é detalhe de execução não precisa estar.

A ferramenta pertence à fase de monitoramento, e o nome da fase é literal. Monitorar é comparar o que está acontecendo com o que foi combinado, e é por isso que o relatório sem referência à linha de base não monitora nada: ele descreve. Descrição é útil; monitoramento é o que permite agir a tempo.

Há uma pergunta que vale fazer antes de escrever a primeira linha: se este relatório fosse o único documento que o patrocinador lesse no mês, ele saberia decidir? A resposta honesta costuma ser não, e a razão quase nunca é falta de dado. É excesso de dado sem hierarquia, ou falta da comparação que transforma número em desvio.

As seis partes do relatório

A estrutura da ferramenta tem um cabeçalho de identificação e seis blocos. O cabeçalho traz projeto ou código, responsável pelo relato e data — e o período coberto, que é o campo mais esquecido e o que dá sentido a todos os outros.

A ordem não é arbitrária. Farol antes das realizações porque quem lê precisa da conclusão antes da evidência. Desvios antes de riscos porque desvio é o que já aconteceu e risco é o que pode acontecer, e confundir os dois é o erro mais comum do relato. Próximos passos por último porque só fazem sentido depois de saber de onde o projeto está partindo.

Repare que não há bloco de "observações gerais". A ausência é proposital. Campo livre no fim do relatório atrai justamente o que deveria estar nos blocos estruturados: o desvio que não se quer nomear, o risco que não se quer classificar, a justificativa que não cabe na frase curta do farol.

O farol: três cores, três critérios

O farol é a parte mais lida e a mais fraudada do relatório. Ele é lido porque é a única informação que cabe num olhar; é fraudado porque pintar de verde evita conversa difícil, e porque quase nenhuma organização define o critério das cores antes do primeiro relato.

• Verde — no prazo e no custo. Não é "sem problema": é "os desvios existentes não ameaçam a data nem o orçamento acordados".
• Amarelo — desvio sob controle. Existe afastamento da linha de base, e existe resposta em curso com dono e prazo.
• Vermelho — desvio sem resposta. O afastamento existe e não há plano em curso capaz de recuperá-lo, ou a recuperação depende de decisão que ainda não foi tomada.

A distinção entre amarelo e vermelho é a que mais importa, e ela não é de tamanho. Um desvio grande com plano de recuperação em execução é amarelo; um desvio pequeno parado esperando decisão há três semanas é vermelho. A cor mede a existência de resposta, não a gravidade do problema — e é essa leitura que dá ao patrocinador a informação de que ele precisa: onde a decisão dele é necessária.

A justificativa do farol resolve o resto. Uma frase, obrigatória, inclusive no verde. Verde sem justificativa é o estado natural do relatório que ninguém lê; verde com justificativa obriga quem escreve a olhar o dado antes de escolher a cor. É uma trava barata e funciona.

E há a regra que a ferramenta escreve de forma direta: não escreva "projeto em dia" sem checar a curva S. A sensação de estar em dia vem do ritmo da equipe, que é alto justamente nas semanas em que se trabalha muito — e trabalhar muito não é o mesmo que avançar contra a linha de base. A curva é quem confirma ou desmente.

Desvio sem referência não é desvio

A tabela de desvios tem três colunas: o desvio, o efeito em prazo e custo, e a referência. A terceira é a que separa relatório de conversa. A regra é que toda linha cite onde o desvio está documentado — o controle de mudanças, a matriz de riscos ou o registro de problemas.

O motivo é que desvio sem referência não pode ser verificado nem acompanhado. Ele aparece num relato, some no seguinte e ninguém sabe se foi resolvido ou esquecido. Com referência, o desvio tem endereço: quem lê pode abrir o documento citado, ver o histórico e cobrar o encaminhamento.

A terceira linha do exemplo merece atenção porque ela mostra o caso limite: um item que ainda não produziu efeito. Ele não é desvio, é risco — e pertence ao bloco de riscos em destaque, não ao de desvios. Misturar os dois é o erro que faz a tabela de desvios crescer sem que o projeto tenha piorado, e o efeito colateral é que os desvios reais perdem visibilidade no meio.

Quando a mesma referência aparece em três relatos seguidos, o relatório está dizendo outra coisa: o encaminhamento não está andando. Essa leitura, que exige comparar relatórios em vez de ler um só, é a que mais rende — e é a que praticamente ninguém faz.

Relatar avanço não é relatar entrega

O bloco de realizações pede o que foi entregue no período, com data. A palavra entregue faz trabalho pesado ali. Ela exclui o que está em andamento, o que está quase pronto e o que foi iniciado — categorias que enchem relatórios e não informam nada, porque não são verificáveis.

A diferença fica clara quando se olha o que cada formulação permite concluir. "Iniciada a integração com o ERP" não permite concluir nada: não se sabe quanto falta nem quando termina. "Integração com o ERP homologada em 7 cenários de 7, em 18/03" permite concluir que aquela frente fechou. A primeira é atividade, a segunda é entrega.

Há um efeito perverso no relato por atividade que só aparece no terceiro ou quarto período: como atividade sempre existe, o relatório nunca fica vazio, e um projeto travado pode produzir quatro relatórios cheios seguidos. Relato por entrega, ao contrário, fica visivelmente vazio quando nada fechou — e é esse vazio que dispara a conversa certa, na semana certa.

• Não é entrega: "em andamento", "iniciado", "90% concluído", "aguardando retorno", "em validação".
• É entrega: artefato aceito, ambiente publicado, contrato assinado, teste concluído com resultado, treinamento realizado com lista de presença.
• Caso de fronteira: entrega parcial combinada previamente — vale, desde que a parte entregue tenha critério de aceite próprio.

Quando o período realmente não teve entrega, escreva isso. "Nenhuma entrega concluída no período" é uma frase difícil de mandar e é a informação mais valiosa que o relatório pode carregar. Ela costuma antecipar em semanas a conversa que, sem ela, só acontece quando a data final já está comprometida.

Como escrever o relato de um período ruim

Todo projeto tem períodos ruins, e a qualidade do gerente aparece justamente neles. A tentação é diluir: espalhar a má notícia em texto longo, começar pelas realizações, deixar o farol em amarelo quando ele é vermelho. Isso compra uma semana e cobra caro depois, porque a perda de credibilidade é permanente.

1. Ponha a cor certa no topo. Vermelho com justificativa de uma linha é mais fácil de defender do que amarelo que precisa ser explicado depois que alguém percebeu.
2. Nomeie a causa, não a categoria. "Atraso da equipe" não é causa: é resumo. "Dois analistas realocados para outro projeto em 11/03" é causa, e aponta para quem pode resolver.
3. Quantifique o efeito, mesmo aproximado. "Impacto significativo" não permite decisão. "+12 dias no caminho crítico" permite.
4. Diga o que você já está fazendo e o que depende de decisão de terceiro. Essa separação é o conteúdo útil do relato ruim: ela transforma má notícia em pedido claro.
5. Não prometa recuperação sem plano. Recuperação prometida e não cumprida no relato seguinte custa mais que o atraso original.

A quarta linha é a que muda a conversa. Um relatório vermelho que diz apenas "estamos atrasados" convida à cobrança. Um que diz "estamos atrasados em 12 dias; a recuperação de 8 deles depende da confirmação da janela de infraestrutura, que está com a diretoria desde 04/03" convida à ação. O conteúdo é o mesmo; a utilidade não.

Vale registrar as decisões que saem dessa conversa. O relato ruim costuma produzir escolhas rápidas — cortar escopo, adiar entrega, contratar apoio — e são exatamente as decisões que ninguém lembra três meses depois. O registro de decisões existe para isso, e o gancho natural é a reunião de leitura do relatório.

Riscos em destaque não é a matriz de riscos

O bloco de riscos do status report tem uma função estreita: mostrar o que mudou de patamar desde o último relato. Ele não é um resumo da matriz de riscos, e transformá-lo nisso é o caminho mais rápido para que ninguém o leia.

A matriz tem dezenas de linhas e é revisada em ciclo próprio. O relatório do período precisa de três, no máximo quatro: os riscos que subiram de probabilidade, os que se aproximaram no tempo e os que se materializaram — estes últimos migram para a tabela de desvios e saem do bloco de riscos.

O critério de seleção é a mudança, não a gravidade. Um risco alto que está alto desde o começo do projeto e não mudou não pertence ao relato do período: ele já está na matriz e já é conhecido. Repeti-lo em todos os relatórios treina o leitor a pular o bloco inteiro, e aí o risco novo, que importava, some junto.

Há uma pergunta que ajuda na hora de selecionar: o que eu sei hoje sobre risco que eu não sabia no relato anterior? Se a resposta for nada, o bloco pode dizer isso em uma linha. Bloco honestamente vazio é melhor que bloco preenchido por obrigação.

O período coberto é o campo que dá sentido aos outros

De todos os campos do cabeçalho, o período coberto é o mais ignorado e o que mais custa quando falta. Sem ele, as datas das realizações viram pontos soltos: não dá para saber se três entregas em duas semanas é ritmo alto ou baixo, nem se o intervalo desde o último relato foi de sete ou de vinte e um dias.

O problema aparece com força quando o relato atrasa. Um relatório semanal emitido com dez dias de intervalo cobre um período maior que o normal, e quem lê, sem saber disso, compara a produção de dez dias com a de sete e conclui que o projeto acelerou. O campo de período é o que impede essa leitura errada, e ele custa uma linha.

Há uma regra prática que resolve a maior parte dos casos: períodos não podem ter buraco nem sobreposição. Se o relato anterior cobriu até 07/03, este começa em 08/03. Quando um período é pulado, o relatório seguinte declara a lacuna em vez de esticar a janela silenciosamente — esticar a janela apaga a informação de que houve um período sem acompanhamento.

Vale também separar a data do relato da data de fechamento do período. São coisas diferentes e a distância entre elas é informação: relatório escrito três dias depois do fim do período é normal, escrito duas semanas depois é sinal de que o rito perdeu prioridade, e isso costuma anteceder o abandono do documento.

Próximos passos: o campo que vira lista de desejos

O último bloco pede o que será feito até o próximo período, e é o mais fácil de escrever mal. A degeneração típica é previsível: ele começa como compromisso e vira lista de intenções, com verbos no infinitivo e sem data — "avançar na homologação", "alinhar com o fornecedor", "revisar o cronograma".

O teste para saber se o campo está funcionando é ler o relatório do período anterior antes de escrever o atual. Cada item dos próximos passos de lá deveria aparecer aqui, ou nas realizações, ou nos desvios. Item que simplesmente sumiu entre um relatório e outro é a evidência mais clara de que ninguém está lendo o documento — inclusive quem o escreve.

• Compromisso: "Homologação dos 4 cenários restantes concluída até 28/03, responsável Marina."
• Intenção: "Avançar na homologação."
• Compromisso: "Janela de infraestrutura confirmada pela diretoria até 22/03, ou o risco R-05 vira desvio."
• Intenção: "Alinhar com a infraestrutura."

A segunda linha de compromisso do exemplo tem uma propriedade útil: ela declara antecipadamente o que acontece se o passo não for cumprido. Isso muda a natureza do relatório seguinte, porque o desvio já estava previsto e nomeado. Poucos gerentes escrevem assim, e é o que separa o relatório que informa do relatório que antecipa.

Um limite útil: entre três e cinco itens. Lista de doze próximos passos não é plano, é inventário de tudo que está aberto — e o leitor, sem hierarquia, ignora o bloco inteiro. Se há doze frentes ativas, escolha as que mudam o farol e deixe o resto no plano do projeto, que é onde elas moram.

Quem escreve, quem lê e o que muda entre os dois

Há um desencontro estrutural no status report que nenhuma boa vontade resolve: quem escreve conhece o projeto por dentro e quem lê decide por fora. Tudo que é óbvio para o primeiro é invisível para o segundo, e tudo que é detalhe para o primeiro ocupa espaço caro na atenção do segundo.

O sintoma mais comum é o vocabulário. Siglas internas, nomes de módulos, apelidos de frente de trabalho — todos economizam tempo de quem escreve e custam compreensão de quem lê. A regra prática é dura e funciona: nenhuma sigla sem expansão na primeira aparição de cada relatório, mesmo que ela já tenha aparecido nos doze anteriores.

O segundo sintoma é a omissão do óbvio. O gerente sabe que a frente de integração é a mais crítica do projeto e não repete isso; o patrocinador, que lê seis relatórios de seis projetos diferentes, não tem esse mapa na cabeça. Uma frase de contexto por relatório — qual é a frente crítica agora — custa pouco e muda a leitura de tudo abaixo.

A terceira linha da tabela merece um comentário. Quando o projeto já recuperou atraso antes, quem escreve carrega esse histórico e tende a relativizar o desvio atual. O leitor não carrega nada disso. Dar o número absoluto primeiro e o acumulado depois resolve, e de quebra dá ao patrocinador a informação de que o projeto tem capacidade de recuperação demonstrada — que é um argumento forte e quase nunca usado.

O status report em portfólio: quando são seis projetos, não um

Tudo muda quando quem lê recebe seis relatórios no mesmo dia. O tempo de atenção por documento cai para menos de um minuto, e o farol deixa de ser um resumo do projeto para virar um critério de triagem: o leitor procura o vermelho e o amarelo, e os verdes recebem uma olhada de dois segundos.

Isso tem uma consequência que quem escreve raramente considera: num contexto de portfólio, o relatório compete por atenção com outros cinco. Relatório longo perde para relatório curto, e relatório sem conclusão perde para relatório com conclusão — independentemente da qualidade do projeto por trás.

A padronização entre projetos, que parece burocracia, é o que torna a triagem possível. Quando os seis relatórios têm o farol no mesmo lugar, com os mesmos três critérios, o leitor compara. Quando cada gerente usa o próprio formato e o próprio termômetro, a comparação é impossível e a decisão volta a depender de quem fala mais alto na reunião.

• Mesmo critério de cor entre todos os projetos, definido pelo escritório de projetos e não por cada gerente.
• Mesmo período de corte, para que os relatórios cheguem juntos e sejam comparáveis no tempo.
• Mesma ordem de blocos, porque a leitura em série depende de saber onde olhar sem procurar.
• Limite de tamanho: uma página. O que não cabe pertence aos documentos referenciados.

O limite de uma página costuma gerar resistência e é o item que mais melhora a qualidade do relato. Espaço escasso obriga hierarquia, e hierarquia é exatamente o que o leitor de portfólio precisa e o que o relatório longo não entrega. O detalhe não se perde: ele fica nos documentos citados na coluna de referência, acessíveis a quem quiser descer um nível.

Vale um alerta sobre consolidação automática. Ferramentas que somam o farol de seis projetos num indicador único de portfólio destroem a informação: três verdes e um vermelho não dão um amarelo de portfólio, dão um projeto que precisa de decisão e três que não precisam. A agregação serve para contagem, nunca para substituir a leitura.

Erros comuns no status report

• Farol sem critério definido. Cada relator pinta pelo próprio termômetro, e a cor deixa de ser comparável entre períodos e entre projetos.
• Verde por hábito. Quando o verde é o estado padrão, o amarelo passa a soar como alarme grave e ninguém o usa — restam duas cores, e o farol perde metade da resolução.
• Relato por atividade. Projeto travado produz relatórios cheios, e o vazio que deveria disparar a conversa nunca aparece.
• Desvio sem referência. Some no relato seguinte sem que ninguém saiba se foi resolvido.
• Misturar risco com desvio. Incha a tabela de desvios e esconde os desvios reais no meio.
• Período coberto em branco. Sem a janela, as datas das realizações não dizem se o ritmo caiu ou subiu.
• Campo livre de observações. Atrai justamente o que deveria estar estruturado nos outros blocos.
• Relatório escrito para a equipe. Usa vocabulário interno e omite o óbvio, que é exatamente o que o patrocinador não sabe.

Há ainda um erro de calendário que vale nomear: emitir o relatório sempre depois da reunião de acompanhamento. Quando isso acontece, o documento vira ata e perde a função de preparar a leitura. O relatório publicado antes da reunião muda a natureza do encontro — em vez de informar, ele passa a decidir, porque todo mundo chega tendo lido a mesma coisa.

Um teste de dez minutos para saber se o seu relatório é lido

Relatório não lido é indistinguível de relatório lido, do ponto de vista de quem escreve — nos dois casos ninguém responde. Há um jeito barato de descobrir em qual dos dois você está, e ele não exige perguntar a ninguém.

1. Pegue os três últimos relatórios e some quantos desvios distintos apareceram. Se o número for zero ou um em um projeto de porte, o relatório está sendo escrito para não gerar pergunta.
2. Verifique se algum desvio mudou de referência ao longo dos três — de risco para problema, de problema para mudança. Movimento entre documentos é sinal de que o relato está acoplado ao resto.
3. Conte quantas vezes o farol mudou de cor. Farol que nunca muda não está medindo nada.
4. Procure, nos três, uma frase que tenha custado desconforto para escrever. Se não houver nenhuma, o relatório está otimizado para conforto, e conforto é o oposto da função dele.

O teste tem uma vantagem sobre perguntar diretamente ao patrocinador: ele mede o documento, não a educação de quem responde. Quase ninguém diz que não lê o relatório recebido; quase todo mundo o trata como recebido e arquivado. O padrão dos três últimos relatos conta a verdade.

E se o resultado for ruim, a correção raramente é de formato. Relatório que ninguém lê costuma ser relatório sem conclusão: ele apresenta informação e deixa a interpretação para o leitor. O farol com justificativa existe exatamente para forçar a conclusão, e é o primeiro campo a consertar.