Projetos fracassam em três lugares: na escolha, na execução e na sustentação. Só o primeiro não deixa rastro, e por isso é o menos corrigido.
O padrão se repete: um projeto entrega tudo o que prometeu, no prazo, dentro do orçamento, com a documentação completa, e ninguém consegue apontar o que mudou na operação depois dele. O relatório final é impecável. O problema que motivou a abertura continua lá. Nesse caso, o projeto não foi mal conduzido; foi bem conduzido rumo a um lugar que não valia a viagem.
Por isso a distinção que a maioria dos textos deixa para o fim vem aqui no começo. Projeto não é o que você faz — é o que você faz uma vez. Tem começo, fim e um resultado que não existia antes. Se a atividade se repete indefinidamente e o “fim” é apenas o próximo ciclo, isso é rotina, e rotina tratada como projeto gera a burocracia sem gerar a entrega. O inverso também custa caro: mudança relevante tratada como rotina nunca ganha dono, prazo nem recurso.
As quatro fases, e o que se decide em cada uma
| Fase | Decisão da fase | Sinal de que ela foi pulada |
|---|---|---|
| Iniciação | Este projeto deve existir? | Ninguém sabe dizer que número deveria mudar |
| Planejamento | Qual o caminho e o que pode dar errado? | Cronograma sem premissa escrita |
| Execução e controle | Estamos no caminho, ou mudou alguma coisa? | Reunião de status que só reporta percentual concluído |
| Encerramento | Funcionou? O que aprendemos? | Projeto que “termina” quando a equipe é realocada |
Iniciação: a fase que decide o resultado
A pergunta desta fase não é “como fazer”, é “vale fazer”. E ela tem uma versão operacional que resolve quase tudo: qual indicador deveria mudar, em quanto, e até quando?
Se a resposta não sai em uma frase, o projeto ainda não está definido — está apenas desejado. “Melhorar o atendimento” não é objetivo de projeto; “reduzir o tempo de primeira resposta de quatro horas para uma, até dezembro” é. A diferença não é de redação: a primeira formulação não permite saber, no fim, se funcionou.
Formalizar isso é o papel do documento de abertura, com escopo, patrocinador, prazo e critério de sucesso — o que está tratado em project charter. E quando existem vários projetos candidatos e recursos para poucos, o critério de escolha entre eles é assunto próprio, com um caso concreto em seleção de projetos de melhoria.
Planejamento: caminho e premissas
Planejar não é preencher cronograma. É decidir a sequência do trabalho, quem responde por cada parte e — a parte que quase sempre falta — escrever o que está sendo assumido como verdadeiro.
Toda estimativa repousa sobre premissas: o fornecedor entrega no prazo combinado, a equipe fica disponível, o sistema aguenta o volume. Premissa não escrita não pode ser monitorada, e quando ela quebra o projeto atrasa sem que ninguém saiba por quê. Premissa escrita vira item de acompanhamento e o atraso vira informação.
A representação visual da sequência e das dependências é o gráfico de barras que leva o nome de quem o criou, e está em Henry Gantt.
Execução e controle: a diferença entre andar e progredir
A reunião de status mais comum reporta percentual concluído. É a métrica menos informativa que existe, porque um projeto pode estar 80% concluído e 0% útil — todas as tarefas cumpridas e nenhuma mudança no indicador que motivou a abertura.
Controle útil acompanha três coisas ao mesmo tempo: o que foi entregue, o que aconteceu com as premissas, e o que aconteceu com o indicador-alvo. A terceira é a que quase nunca aparece, e é a única que responde se o projeto está funcionando. Quando o método iterativo faz mais sentido que o plano longo — escopo incerto, aprendizado a cada ciclo —, o caminho está em metodologia Scrum.
Há um ponto onde a maior parte dos projetos de melhoria se perde, e ele é específico: mudar várias coisas ao mesmo tempo. Quando cinco alterações entram juntas e o indicador melhora, não se sabe qual delas funcionou — e no ciclo seguinte a organização carrega as cinco, incluindo as que não fizeram nada. Testar uma mudança por vez, com previsão registrada antes, é a lógica do PDSA, e ela cabe dentro de qualquer método de gestão de projetos.
Uma ressalva importante: testar uma de cada vez vale quando não há como isolar efeitos de outro jeito. Quando os fatores são conhecidos e é possível planejar as combinações, o experimento fatorial responde por vários ao mesmo tempo, em menos rodadas, e ainda revela interações entre eles — algo que a variação sequencial não alcança.
Encerramento: verificar se ficou
Encerrar é verificar se o resultado prometido aconteceu e garantir que ele fique. As duas partes costumam falhar.
A verificação falha porque compara um ponto antes com um ponto depois. Um indicador que caiu no mês seguinte pode ter caído por sazonalidade, por variação normal do processo ou por sorte. A verificação que sustenta uma afirmação de melhoria olha o comportamento ao longo do tempo, antes e depois, com a faixa de variação visível — é o que faz a carta de controle, e é a diferença entre mudança e melhoria.
A permanência falha por outro motivo. O projeto muda o processo, escreve o procedimento novo, treina a equipe — e seis meses depois o processo voltou ao que era. Implementar não é o mesmo que documentar: o que sustenta a mudança é o processo padronizado, o indicador acompanhado por alguém com nome, e a rotina que o mantém. Sem isso, o encerramento entrega uma pasta, não um resultado. É o que a padronização protege.
Metodologia é escolha, não identidade
Boa parte da discussão sobre método em gestão de projetos gasta energia numa disputa que não existe na prática. Plano detalhado funciona quando o escopo é conhecido e o custo de errar é alto — obra, implantação de sistema, mudança regulatória. Ciclo curto funciona quando o escopo é incerto e o aprendizado a cada rodada muda o próximo passo.
A escolha é do projeto, não da empresa. Organizações que adotam um método como identidade acabam forçando escopo conhecido para dentro de ciclos curtos, ou tratando descoberta como se fosse cronograma — e nos dois casos o método vira ritual, cumprido porque é o método, não porque resolve.
Há um caso em que o roteiro já vem definido. Quando o projeto é de melhoria de um processo que já existe e o problema é entender por que ele entrega o que entrega, o roteiro é o DMAIC, que organiza as mesmas fases em torno da pergunta causal — definir, medir, analisar, melhorar e controlar. Esta página trata da condução genérica, que vale também para projetos que não são de melhoria: uma implantação, uma expansão, um lançamento. Em formações como o Green Belt, o roteiro estruturado existe justamente para não virar ritual: cada etapa tem uma pergunta a responder, e a etapa termina quando a pergunta foi respondida, não quando o campo foi preenchido.
Quando o projeto entrega tudo e não muda nada
Um exemplo torna o problema concreto. Uma fábrica de autopeças — situação-tipo, montada para ilustrar — abriu um projeto para reduzir o retrabalho, que rodava em 4,1%, com meta de 2%. O projeto entregou dezoito ações, treinou noventa pessoas, encerrou no prazo e dentro do orçamento.
O retrabalho terminou em 3,9%. Nos dois anos anteriores, o mesmo indicador havia oscilado entre 3,4% e 4,6% sem intervenção nenhuma — ou seja, 3,9% está dentro da faixa em que o processo já vivia. O projeto não piorou nada e não melhorou nada: produziu um número que qualquer mês teria produzido sozinho.
Nenhum critério foi violado, porque nenhum tinha sido declarado. A meta de 2% aparecia na apresentação de abertura e em lugar nenhum do encerramento, e a comparação que foi ao relatório final foi 4,1% contra 3,9% — dois pontos, sem a série que mostraria a faixa.
Esse é o projeto que passa em toda auditoria de processo, porque a auditoria verifica se as etapas foram cumpridas. E é o que reaparece no ano seguinte com outro nome, porque o problema continua vivo. A defesa contra ele custa uma frase escrita na iniciação — qual número, quanto, até quando — e a disposição de olhar esse número no encerramento, mesmo quando ele não coopera.
Conteúdo revisado pelo Master Black Belt Marcelo Petenate, estatístico, formado pela Unicamp, mestre pela USP e especialista em Lean Six Sigma e melhoria contínua. Revisão com foco no critério de encerramento e no limite do percentual concluído como métrica de acompanhamento.
O White Belt gratuito da EDTI apresenta as três questões fundamentais que estruturam qualquer projeto de melhoria.
Perguntas frequentes
Qual a diferença entre projeto e processo?
Projeto tem começo, fim e entrega algo que não existia. Processo se repete e entrega a mesma coisa continuamente. A confusão custa caro nos dois sentidos: rotina tratada como projeto vira burocracia sem entrega, e mudança relevante tratada como rotina nunca ganha dono nem prazo.
Quais são as fases de um projeto?
São quatro. A iniciação decide se o projeto deve existir e qual indicador deveria mudar. O planejamento define o caminho e registra as premissas. A execução e controle acompanham entregas, premissas e o indicador-alvo. O encerramento verifica se funcionou e garante que a mudança fique. Os nomes variam entre metodologias, mas as decisões não, e pular a primeira é o erro mais caro porque só aparece no fim.
O que faz um gerente de projetos?
Responde pelo resultado, não pela execução das tarefas. Na prática, o trabalho central é decidir o que entra e o que sai do escopo, monitorar as premissas que sustentam o plano e manter visível o indicador que o projeto deveria mudar. Quem só acompanha percentual concluído está fazendo relatório, não gestão.
Qual metodologia de gestão de projetos é melhor?
Depende do projeto. Plano detalhado se sai melhor com escopo conhecido e custo alto de errar; ciclo curto se sai melhor com escopo incerto. Para melhoria de processo existente, o roteiro específico é o DMAIC. Adotar uma metodologia como identidade da empresa força projetos para dentro do formato errado, e o método vira ritual.
Como saber se um projeto deu certo?
Comparando o indicador-alvo ao longo do tempo, antes e depois, e não em dois pontos isolados. Um ponto depois melhor que um ponto antes pode ser variação normal do processo — como no caso do retrabalho que terminou em 3,9% dentro de uma faixa histórica de 3,4% a 4,6%. Sem a série, a conclusão sobre sucesso é uma opinião com número ao lado.
Por que projetos bem-sucedidos não geram mudança duradoura?
Porque documentar a mudança não é o mesmo que implementá-la. Sem processo padronizado, indicador com responsável e rotina de acompanhamento, a operação volta ao comportamento anterior em poucos meses, e a pasta do projeto permanece perfeitamente organizada.
O que são premissas de um projeto e por que registrá-las?
São as condições assumidas como verdadeiras para o plano funcionar: prazos de terceiros, disponibilidade de equipe, capacidade de sistema. Registradas, viram itens de acompanhamento e o desvio vira informação antecipada. Não registradas, o projeto atrasa e ninguém consegue explicar a causa.
Vale a pena ter um PMO?
Vale quando existem projetos suficientes para que a escolha entre eles seja um problema real, e o PMO serve para priorizar e padronizar. Deixa de valer quando ele passa a produzir relatórios sobre projetos em vez de melhorar a seleção deles — e essa transição costuma acontecer sem que ninguém decida.