Artigo atualizado em março/2026 para o PMBOK® Guide — Eighth Edition.
Cadastre-se para navegar sem anúncios e participar do Project Together →
Gerenciar Execução do Projeto: O Processo que Transforma Planos em Entregas Concretas (PMBOK 8)
Anteriormente: Orientar e Gerenciar o Trabalho do Projeto (PMBOK 6)
Imagine este cenário: o plano de gerenciamento está impecável — escopo detalhado, cronograma com marcos definidos, orçamento aprovado, riscos mapeados. A equipe recebe o plano na segunda-feira e começa a executar. Na quarta-feira, ninguém sabe exatamente quem está fazendo o quê. Na sexta, surgem três solicitações de mudança que ninguém esperava. No final do mês, as entregas estão atrasadas, os dados de desempenho não existem e os problemas se acumulam sem registro. O plano era perfeito — a execução, não.
No PMBOK 8, o processo Gerenciar Execução do Projeto é o Processo 4 do Domínio de Governança (código 2.1.6.4) — e é onde o projeto deixa de ser teoria e vira realidade. É o processo que consome a maior parte do orçamento, envolve a maior parte da equipe e produz as entregas que o cliente espera. Se a iniciação dá legitimidade e o planejamento dá direção, a execução é onde o valor é gerado.
Neste guia completo você vai encontrar:
- O que é o processo Gerenciar Execução do Projeto e onde ele se encaixa no PMBOK 8
- Por que usá-lo — e o que acontece quando a execução não é gerenciada
- ITTO completo — Entradas, Ferramentas/Técnicas e Saídas em tabela detalhada
- Passo a passo prático para aplicar o processo do zero
- Quando aplicar — cenários e gatilhos que indicam a necessidade de gestão ativa da execução
- Exemplos práticos — Projeto Horizonte (Horizonte Transportes) e Projeto ProjectAdm (Desenvolvimento de Software SaaS)
- Atalhos, templates e dicas para acelerar a gestão da execução
- 5 erros comuns — e como evitá-los
- Tailoring para contextos Preditivo, Ágil e Híbrido
- Interações com outros processos e domínios
- Checklist de aplicação rápida com 7 itens para usar hoje
1. O que é o Processo Gerenciar Execução do Projeto
Gerenciar Execução do Projeto é o processo de liderar e realizar o trabalho definido no plano de gerenciamento do projeto, implementar as mudanças aprovadas e produzir as entregas do projeto. É o processo central da execução — onde recursos são consumidos, atividades são realizadas e resultados tangíveis são gerados.
No PMBOK 8, este é o Processo 4 do Domínio de Governança (código 2.1.6.4). A mudança de nome do PMBOK 6 — de “Orientar e Gerenciar o Trabalho do Projeto” para “Gerenciar Execução do Projeto” — reflete uma visão mais direta: o foco não é apenas “orientar” o trabalho, mas efetivamente gerenciar toda a execução, desde a alocação de recursos até a coleta de dados de desempenho.
O processo produz múltiplas saídas fundamentais:
- Entregas — os produtos, serviços ou resultados tangíveis que o projeto deve produzir, conforme definido no escopo
- Dados de desempenho do trabalho — as observações e medições brutas coletadas durante a execução (percentual concluído, datas reais de início/término, custos reais, defeitos encontrados)
- Registro de Problemas (Issue Log) — o documento que registra todos os problemas, impedimentos e questões que surgem durante a execução e precisam ser resolvidos
- Solicitações de mudança — pedidos formais para alterar qualquer componente do projeto (escopo, cronograma, custos, qualidade)
- Atualizações — do plano de gerenciamento e dos documentos do projeto, refletindo a realidade da execução
Diferença entre planejar e executar
| Aspecto | Planejamento | Execução |
|---|---|---|
| Foco | Definir o que será feito, quando e por quem | Fazer o que foi planejado e registrar o que aconteceu |
| Consumo de recursos | Baixo (equipe de planejamento) | Alto (equipe completa, orçamento, fornecedores) |
| Resultado principal | Planos e linhas de base | Entregas concretas e dados de desempenho |
| Natureza | Intelectual — análise, previsão, decisão | Operacional — ação, produção, resolução |
| Problemas típicos | Premissas incorretas, estimativas otimistas | Impedimentos, conflitos, mudanças não previstas |
2. Por que Usar o Processo Gerenciar Execução do Projeto
A execução é onde 60-80% do orçamento do projeto é consumido. Gerenciar ativamente esse processo não é opcional — é a diferença entre entregar valor e desperdiçar recursos.
Benefícios diretos
- Entregas concretas: O processo garante que as atividades planejadas sejam efetivamente realizadas e que os produtos, serviços ou resultados sejam produzidos conforme o escopo definido.
- Visibilidade do progresso: Os dados de desempenho coletados durante a execução alimentam todos os processos de monitoramento. Sem dados, não há controle.
- Gestão proativa de problemas: O Registro de Problemas captura impedimentos em tempo real, permitindo resolução antes que se tornem crises.
- Implementação controlada de mudanças: Mudanças aprovadas são incorporadas à execução de forma estruturada, sem improvisos que comprometam a qualidade ou o cronograma.
- Rastreabilidade: Cada ação, decisão e resultado é documentado, permitindo auditoria e aprendizado.
- Coordenação da equipe: A gestão ativa da execução mantém todos alinhados — quem está fazendo o quê, até quando e com qual prioridade.
O que acontece quando o processo é ignorado
- Execução sem direção: A equipe trabalha com base em interpretações individuais do plano. Cada membro prioriza o que acha mais importante, gerando entregas fragmentadas e inconsistentes.
- Problemas invisíveis: Sem um registro formal de problemas, impedimentos se acumulam silenciosamente. Quando finalmente aparecem, já causaram atraso e retrabalho significativos.
- Mudanças informais: Solicitações de mudança são aceitas verbalmente, sem análise de impacto. O escopo cresce, o cronograma estoura e ninguém consegue rastrear quando e por que mudou.
- Dados inexistentes: Sem dados de desempenho, o gerente de projeto não sabe se o projeto está no prazo, no orçamento ou dentro da qualidade esperada. “Como está o projeto?” é respondido com “acho que está bem” — não com métricas.
- Desperdício de recursos: Equipe trabalhando em atividades erradas, fornecedores sem coordenação, retrabalho por falta de comunicação — tudo consequência de uma execução não gerenciada.
O princípio “Líder Responsável” do PMBOK 8 é especialmente relevante aqui: o gerente de projeto é o líder responsável por garantir que a execução ocorra conforme planejado — e por tomar decisões rápidas quando a realidade diverge do plano.
3. Entradas, Ferramentas e Técnicas, e Saídas (ITTO)
A tabela abaixo apresenta o ITTO completo do processo Gerenciar Execução do Projeto, conforme o PMBOK 8:
| Entradas | Ferramentas e Técnicas | Saídas |
|---|---|---|
|
|
Detalhamento das Entradas
Plano de gerenciamento do projeto: É a referência principal da execução. Inclui todas as linhas de base (escopo, cronograma, custos) e os planos auxiliares (qualidade, recursos, comunicações, riscos, aquisições). O plano diz o que fazer; a execução faz.
Documentos do projeto: O registro de riscos indica ações de resposta que devem ser implementadas durante a execução. O registro de lições aprendidas traz aprendizados de fases anteriores que podem melhorar a execução atual. O cronograma detalha quais atividades devem ser realizadas, em qual sequência e por quem. As atribuições da equipe definem responsabilidades individuais.
Solicitações de mudança aprovadas: Mudanças que passaram pelo processo de controle integrado de mudanças e foram aprovadas para implementação. A execução deve incorporar essas mudanças ao trabalho — elas não são opcionais após aprovação.
Fatores ambientais da empresa (FAE): Cultura organizacional, disponibilidade de infraestrutura, condições de mercado, regulamentações e a estrutura organizacional que afeta como a equipe trabalha.
Ativos de processos organizacionais (APO): Procedimentos operacionais, templates, ferramentas, diretrizes, base de conhecimento e lições aprendidas de projetos anteriores que apoiam a execução.
Detalhamento das Ferramentas e Técnicas
Opinião especializada: Consulta a profissionais com experiência técnica, de negócio ou de gestão relevante para resolver questões que surgem durante a execução. Pode incluir especialistas técnicos da equipe, consultores externos, gerentes funcionais e SMEs (Subject Matter Experts) de áreas específicas.
Sistema de Informações de Gerenciamento de Projetos (SIGP): Ferramenta ou conjunto de ferramentas que apoia a gestão da execução — controle de atividades, alocação de recursos, registro de horas, gestão de documentos, comunicação e coleta de dados de desempenho. Exemplos incluem MS Project, Jira, ProjectAdm, Monday.com, Asana e ClickUp. O SIGP é a infraestrutura tecnológica que suporta a execução.
Reuniões: Reuniões de acompanhamento (daily standups, reuniões semanais de status), reuniões de resolução de problemas, reuniões de coordenação com fornecedores e reuniões de tomada de decisão. Em projetos complexos, a estrutura de reuniões é o que mantém a equipe sincronizada.
Detalhamento das Saídas
Entregas: Os produtos, serviços ou resultados tangíveis produzidos pela execução do trabalho. Podem ser entregas parciais (módulos, componentes, documentos intermediários) ou entregas finais (produto completo, serviço em operação). As entregas passam pelo processo de validação de escopo antes de serem aceitas pelo cliente.
Dados de desempenho do trabalho: As medições brutas coletadas durante a execução — percentual de conclusão de atividades, datas reais de início e término, custos reais incorridos, horas de trabalho consumidas, defeitos encontrados, entregas concluídas versus planejadas. Esses dados são a matéria-prima para os relatórios de desempenho.
Registro de Problemas (Issue Log): Documento que registra todos os problemas, impedimentos e questões que surgem durante a execução. Para cada problema: descrição, data de identificação, responsável pela resolução, data-alvo para resolução, prioridade e status. O Issue Log é um documento vivo — atualizado continuamente durante toda a execução.
Solicitações de mudança: Pedidos formais para alterar qualquer aspecto do projeto — escopo, cronograma, custos, qualidade, recursos ou qualquer outro componente. As solicitações podem surgir de problemas identificados, oportunidades descobertas, mudanças no ambiente externo ou requisitos novos do cliente.
Atualizações: O plano de gerenciamento e os documentos do projeto são atualizados para refletir a realidade da execução — datas reais, custos reais, lições aprendidas, riscos materializados e premissas validadas ou refutadas.
4. Como Aplicar o Processo Passo a Passo
O passo a passo abaixo pode ser adaptado conforme a complexidade do projeto, mas a sequência lógica se aplica a qualquer contexto:
Passo 1 — Distribua o trabalho conforme o plano
Com o plano de gerenciamento aprovado e as linhas de base definidas, distribua as atividades para a equipe. Para cada membro:
- Confirme que ele entende o que deve ser feito (escopo da atividade)
- Confirme que ele tem os recursos necessários (ferramentas, acesso, informações)
- Confirme o prazo esperado (data de início e término)
- Confirme os critérios de aceitação (o que define “pronto”)
- Confirme a quem reportar o progresso (e com qual frequência)
Dica prática: Não basta enviar um e-mail com a lista de tarefas. Conduza uma reunião de kickoff da execução (ou sprint planning, em contexto ágil) para garantir que todos entendem suas responsabilidades e têm clareza sobre as prioridades.
Passo 2 — Implemente as mudanças aprovadas
Mudanças aprovadas pelo processo de controle integrado de mudanças devem ser incorporadas ao trabalho. Para cada mudança aprovada:
- Atualize o plano de gerenciamento (escopo, cronograma, custos) para refletir a mudança
- Comunique a mudança à equipe e aos stakeholders impactados
- Atribua as atividades adicionais ou modificadas aos responsáveis
- Atualize as linhas de base se a mudança foi aprovada com ajuste de baseline
Dica prática: Mantenha um log de mudanças implementadas, separado do log de mudanças solicitadas. Isso facilita a rastreabilidade: “Quando essa mudança foi implementada? Quem fez? Qual foi o impacto real?”
Passo 3 — Colete dados de desempenho continuamente
Durante toda a execução, colete dados de desempenho de forma estruturada:
- Progresso das atividades: Percentual de conclusão, datas reais de início/término
- Custos reais: Horas consumidas, despesas incorridas, pagamentos a fornecedores
- Qualidade: Defeitos encontrados, testes executados, entregas rejeitadas
- Riscos materializados: Riscos que se concretizaram e ações de resposta executadas
- Produtividade: Velocidade da equipe (em contextos ágeis), throughput, lead time
Use o SIGP para automatizar a coleta sempre que possível. Dados inseridos manualmente são propensos a atraso e inconsistência.
Passo 4 — Registre e gerencie problemas (Issue Log)
Quando um problema surgir durante a execução, registre-o imediatamente no Issue Log:
- Descrição: O que aconteceu ou está acontecendo
- Impacto: Como o problema afeta o projeto (prazo, custo, qualidade, escopo)
- Prioridade: Alta (bloqueia o trabalho), Média (impacta mas não bloqueia), Baixa (inconveniente)
- Responsável: Quem vai resolver
- Data-alvo: Quando deve ser resolvido
- Ação de resolução: O que será feito
- Status: Aberto, Em andamento, Resolvido, Escalado
Dica prática: Problemas não resolvidos se acumulam e se agravam. Revise o Issue Log em todas as reuniões de status. Escale problemas que não foram resolvidos dentro do prazo. Problemas escalados sem resolução por mais de 2 semanas devem ir ao patrocinador.
Passo 5 — Gerencie a equipe e resolva conflitos
A execução é onde os conflitos aparecem — prioridades concorrentes, sobrecarga de trabalho, diferenças técnicas, problemas interpessoais. O gerente de projeto deve:
- Monitorar a moral e a motivação da equipe
- Resolver conflitos antes que se tornem crônicos
- Remover impedimentos que bloqueiam o trabalho da equipe
- Reconhecer e celebrar conquistas (marcos atingidos, entregas concluídas)
- Realocar recursos quando necessário (balancear carga de trabalho)
Passo 6 — Coordene fornecedores e recursos externos
Se o projeto envolve fornecedores (conforme o Plano de Estratégia de Aquisições), gerencie a execução dos contratos:
- Monitore entregas de fornecedores contra os KPIs contratuais
- Realize reuniões de acompanhamento periódicas com cada fornecedor-chave
- Documente desvios de prazo, qualidade ou escopo
- Aplique penalidades ou incentivos conforme previsto no contrato
- Gerencie a interface entre equipe interna e fornecedores externos
Passo 7 — Gere solicitações de mudança quando necessário
Durante a execução, situações que exigem mudanças no plano surgirão inevitavelmente. Para cada situação:
- Documente a solicitação de mudança formalmente (o que, por que, impacto estimado)
- Encaminhe para o processo Avaliar e Implementar Mudanças (Processo 8)
- Não implemente mudanças sem aprovação formal — mesmo as “pequenas”
- Comunique à equipe o status de cada solicitação (aprovada, rejeitada, em análise)
5. Quando Aplicar o Processo
O processo Gerenciar Execução do Projeto é aplicado continuamente durante toda a fase de execução. Diferentemente de processos pontuais (como a iniciação), este processo é contínuo.
Cenários obrigatórios
- O planejamento foi concluído e as linhas de base estão aprovadas: A execução começa quando o “o que fazer” está definido e autorizado. Não execute sem plano.
- Mudanças foram aprovadas: Toda mudança aprovada deve ser implementada via este processo — não informalmente.
- O projeto tem equipe ativa trabalhando: Sempre que recursos estão consumindo orçamento e realizando atividades, a execução deve ser gerenciada.
Cenários recomendados
- Transição entre fases: Ao iniciar uma nova fase, a execução da fase anterior pode estar em paralelo com o planejamento da próxima. A gestão da execução garante que entregas da fase anterior sejam concluídas adequadamente.
- Picos de atividade: Períodos de alta intensidade (sprints finais, entregas críticas, deadlines de contrato) exigem gestão de execução mais ativa — reuniões mais frequentes, acompanhamento mais próximo.
- Múltiplas equipes ou fornecedores: Quando várias equipes trabalham em paralelo, a coordenação da execução é o que evita conflitos de dependência e retrabalho.
Gatilhos que indicam que a gestão da execução precisa de atenção
- A equipe não sabe quais são as prioridades da semana
- Problemas estão sendo resolvidos informalmente, sem registro
- Mudanças estão sendo implementadas sem aprovação formal
- Dados de desempenho não estão sendo coletados ou estão desatualizados
- Fornecedores não estão entregando conforme o contrato e ninguém está monitorando
- A equipe reporta impedimentos que persistem por dias sem resolução
- O gerente de projeto não consegue responder “qual o status atual do projeto?” com dados concretos
6. Exemplos Práticos por Setor
Exemplo 1 — Implantação do PMO: Projeto Horizonte
Contexto: A Horizonte Transportes (280 funcionários, transportadora de cargas com sede em Campinas-SP) estava na fase de execução do Projeto Horizonte: implantação do PMO usando ProjectAdm. Ana Silveira, PMP e gerente do projeto, liderava uma equipe de 8 pessoas (3 internas + 2 consultores externos + 3 do fornecedor ProjectAdm). Orçamento de R$ 320.000, prazo de 6 meses.
Como o processo foi aplicado:
- Distribuição do trabalho: Ana Silveira conduziu uma reunião de kickoff da execução com toda a equipe. Cada membro recebeu atribuições claras: Diego Carvalho (analista sênior) ficou responsável pela documentação dos processos do PMO; Carolina Mendes (consultora externa) pela configuração da plataforma ProjectAdm e definição do framework metodológico; e o treinador externo pela capacitação de 30 colaboradores em 3 turmas.
- SIGP: A própria plataforma ProjectAdm foi usada para gerenciar o projeto de sua implantação. Todas as atividades, atribuições, datas e documentos foram registrados na plataforma. Dados de desempenho eram coletados automaticamente (percentual de conclusão, horas registradas).
- Reuniões: Ana implementou reuniões diárias de 15 minutos (standup) com a equipe core e reuniões semanais de 1 hora com todos os envolvidos, incluindo Marcos Tanaka (gerente de operações, principal beneficiário do PMO). Roberto Campos (CEO/patrocinador) participava de uma reunião quinzenal de 30 minutos para acompanhamento executivo.
- Issue Log: Na semana 3 da execução, Diego Carvalho identificou um problema: o ERP TOTVS Protheus não tinha uma API documentada para a integração prevista com o ProjectAdm. O problema foi registrado com prioridade alta. Ana escalou para Marcos Tanaka, que acionou o fornecedor do ERP. A resolução levou 2 semanas — a integração foi reprogramada sem impactar o caminho crítico porque Ana havia incluído uma folga de 10 dias nessa atividade durante o planejamento.
- Solicitações de mudança: Na semana 6, Roberto Campos solicitou a inclusão de um dashboard executivo adicional que não estava no escopo original — um painel de indicadores de projetos visível para todo o comitê diretivo. Ana registrou a solicitação formalmente, estimou o impacto (+R$ 8.500 e +5 dias de trabalho de Carolina Mendes) e encaminhou para aprovação. Roberto aprovou com ajuste de orçamento, e a mudança foi incorporada à execução na semana seguinte.
Resultado: Ao final do mês 4 (de 6), Ana tinha dados de desempenho precisos: 68% do escopo concluído, 62% do orçamento consumido, 14 problemas registrados no Issue Log (11 resolvidos, 2 em andamento, 1 escalado), 3 solicitações de mudança (2 aprovadas, 1 rejeitada). Esses dados permitiram que Roberto Campos e Fernanda Lopes (gerente financeira) acompanhassem o projeto com confiança — sem a necessidade de “achismos”.
Exemplo 2 — Desenvolvimento de Software: Projeto ProjectAdm
Contexto: A equipe ProjectAdm estava na execução do desenvolvimento da plataforma SaaS. Eduardo Montes, GP do projeto, gerenciava uma equipe de 5 desenvolvedores internos + 1 agência de design UX/UI (contratada conforme o Plano de Estratégia de Aquisições). O desenvolvimento seguia uma abordagem híbrida: planejamento preditivo por release + sprints de 3 semanas para desenvolvimento.
Como o processo foi aplicado:
- Distribuição do trabalho: Eduardo usava sprint planning a cada 3 semanas para distribuir as atividades. O backlog priorizado era a referência. Cada sprint tinha um objetivo claro (ex.: Sprint 4 = “Módulo de cronograma com Gantt interativo”). As user stories eram atribuídas aos desenvolvedores com base em competência e disponibilidade.
- SIGP: A equipe usava a própria plataforma ProjectAdm (dogfooding — usando o próprio produto para gerenciá-lo). Jira era usado como ferramenta complementar para tracking de bugs. GitHub para código-fonte com CI/CD automatizado.
- Dados de desempenho: Velocidade da equipe medida em story points por sprint. Burndown chart atualizado diariamente. Defeitos categorizados por severidade (crítico, alto, médio, baixo) e por módulo. Lead time médio de uma user story: 4,2 dias.
- Issue Log: Na Sprint 3, a agência de design entregou as telas do módulo de dashboard com 5 dias de atraso, impactando o início do desenvolvimento front-end. Eduardo registrou o problema, conduziu uma reunião com a agência para entender a causa (briefing incompleto do lado da equipe ProjectAdm) e ajustou o processo: a partir da Sprint 4, o briefing de design seria entregue 1 semana antes do início da sprint, com review obrigatório do designer antes de começar.
- Solicitações de mudança: Durante a Sprint 5, dois clientes-piloto (que testavam a plataforma em beta) solicitaram funcionalidades não previstas: exportação de relatórios em PDF e integração com Google Calendar. Eduardo registrou ambas como solicitações de mudança, priorizou com base no valor de negócio (PDF = alto, Calendar = médio) e encaminhou para análise de impacto. A exportação PDF foi aprovada e incluída na Sprint 7; a integração com Calendar foi adiada para a Release 2.
Resultado: A gestão ativa da execução permitiu que Eduardo mantivesse a velocidade da equipe estável (média de 42 story points/sprint após a Sprint 3). O Issue Log acumulou 23 problemas ao longo de 8 sprints, com tempo médio de resolução de 3,1 dias. As solicitações de mudança foram gerenciadas sem “scope creep” — cada mudança aprovada veio com ajuste de escopo ou prazo documentado.
7. Atalhos, Templates e Dicas
Templates recomendados
- Template de Registro de Problemas (Issue Log): Planilha com colunas: ID, descrição, data de identificação, prioridade, responsável, data-alvo, ação de resolução, status, data de fechamento. Pode ser implementado em Excel, Google Sheets ou no SIGP.
- Template de Solicitação de Mudança: Formulário com: descrição da mudança, justificativa, impacto estimado (escopo, prazo, custo, qualidade), alternativas consideradas, recomendação do GP, aprovação do patrocinador/comitê.
- Template de Ata de Reunião de Status: Documento padrão com: data, participantes, progresso desde a última reunião, problemas/impedimentos, decisões tomadas, ações para a próxima semana.
- Dashboard de Execução: Painel visual com indicadores-chave: percentual de conclusão, orçamento consumido vs. planejado, problemas abertos, mudanças pendentes, riscos ativos e próximos marcos.
Ferramentas digitais
- ProjectAdm / MS Project / Monday.com: Para gerenciar atividades, atribuições e dados de desempenho
- Jira / Azure DevOps: Para equipes de desenvolvimento — tracking de user stories, bugs e sprints
- Slack / Microsoft Teams: Para comunicação rápida da equipe durante a execução
- Power BI / Google Data Studio: Para dashboards de desempenho automatizados
- Confluence / Notion: Para documentação da execução, atas de reunião e registros
Dicas avançadas
- Colete dados de desempenho em tempo real, não retroativamente: Dados coletados no final da semana são imprecisos. Configure o SIGP para que a equipe registre progresso e horas diariamente. A qualidade dos dados de desempenho determina a qualidade das decisões de gestão.
- Trate o Issue Log como um ativo estratégico: O Issue Log não é uma lista de reclamações — é um radar que mostra onde o projeto está enfrentando dificuldades. Analise padrões: se 60% dos problemas envolvem um fornecedor específico, o problema não é o Issue Log — é o fornecedor.
- Reuniões curtas e frequentes superam reuniões longas e esporádicas: Uma daily standup de 15 minutos resolve mais problemas do que uma reunião de 3 horas uma vez por mês. A frequência mantém a equipe alinhada e permite resolução rápida de impedimentos.
- Não aceite “está quase pronto” como status: “Quase pronto” pode significar 90% concluído ou 50% concluído com otimismo. Exija dados concretos: percentual objetivo, horas restantes estimadas, bloqueadores identificados. A síndrome dos 90% (onde os últimos 10% levam tanto tempo quanto os primeiros 90%) é real.
- Separe problemas de mudanças: Um problema é algo que deu errado e precisa ser corrigido. Uma mudança é algo que precisa ser diferente do planejado. Misturar os dois dificulta a análise e a priorização.
8. Erros Comuns e Como Evitá-los
Estes são os 5 erros mais frequentes na aplicação do processo Gerenciar Execução do Projeto — e como evitá-los:
Erro 1 — Executar sem dados de desempenho
Por que acontece: A equipe está focada em entregar e considera a coleta de dados como “burocracia”. O gerente de projeto não insiste na coleta por medo de ser visto como controlador. O resultado: ninguém sabe o status real do projeto até que seja tarde demais.
Como evitar: Torne a coleta de dados parte da rotina, não uma atividade extra. Configure o SIGP para que a atualização de status seja simples (5 minutos por dia por pessoa). Mostre à equipe como os dados são usados — para proteger o projeto, não para controlar pessoas. A transparência gera confiança.
Erro 2 — Não usar o Issue Log
Por que acontece: Problemas são resolvidos informalmente (“passei no corredor e resolvi com o João”) sem registro. O gerente de projeto não fica sabendo de impedimentos até que causem atraso visível.
Como evitar: Crie uma cultura de “registrar primeiro, resolver depois”. O Issue Log não é para culpar — é para rastrear e aprender. Revise o Issue Log em toda reunião de status. Celebre problemas resolvidos rapidamente — isso incentiva o registro.
Erro 3 — Aceitar mudanças sem processo formal
Por que acontece: O cliente ou o patrocinador pede uma “pequena mudança” e a equipe implementa imediatamente sem registrar. Pequenas mudanças se acumulam e, juntas, causam atrasos e estouros de orçamento significativos — o famoso “scope creep” por acumulação.
Como evitar: Estabeleça a regra: toda mudança, por menor que seja, passa pelo processo formal. Para mudanças pequenas, simplifique o processo (aprovação verbal do GP com registro no log de mudanças). Para mudanças médias e grandes, use o processo completo. O objetivo não é bloquear mudanças — é garantir que todas sejam conscientes e documentadas.
Erro 4 — Gerente de projeto como “chefe”, não como “líder”
Por que acontece: O gerente de projeto confunde gestão da execução com microgestão. Cobra status a cada hora, não delega decisões operacionais, não confia na equipe. O resultado: equipe desmotivada, dependente e sem autonomia.
Como evitar: O PMBOK 8 enfatiza o princípio da “Cultura Empoderada”. O gerente de projeto deve liderar, não controlar. Defina expectativas claras, delegue com confiança, dê autonomia para decisões operacionais e esteja disponível para remover impedimentos — não para dizer como cada tarefa deve ser feita.
Erro 5 — Não coordenar fornecedores com a mesma disciplina da equipe interna
Por que acontece: O gerente de projeto acompanha de perto a equipe interna mas “esquece” dos fornecedores — assumindo que o contrato garante a entrega. Fornecedores sem acompanhamento tendem a priorizar outros clientes e entregar o mínimo contratual, não o melhor resultado.
Como evitar: Trate fornecedores como parte da equipe do projeto. Inclua-os nas reuniões relevantes, monitore KPIs de desempenho, conduza reuniões de acompanhamento periódicas e aja rapidamente quando o desempenho estiver abaixo do esperado. O contrato define o mínimo; a gestão do relacionamento determina se você recebe o mínimo ou o máximo.
9. Tailoring: Preditivo, Ágil e Híbrido
O PMBOK 8 enfatiza que todo processo deve ser adaptado ao contexto do projeto. A gestão da execução é, talvez, o processo que mais varia entre abordagens.
Ambiente Preditivo (Waterfall)
- Distribuição do trabalho: Baseada no cronograma detalhado e na EAP. Atividades atribuídas por pacote de trabalho, com datas de início e término definidas.
- Dados de desempenho: Coletados por atividade — percentual de conclusão, datas reais, custos reais. Técnica de Valor Agregado (EVM) usada para análise quantitativa.
- Issue Log: Formal, com workflow de resolução e escalação definido.
- Reuniões: Semanais de status (1 hora), com ata formal e lista de ações.
- Mudanças: Processo formal com formulário de solicitação, análise de impacto e aprovação do CCB (Change Control Board).
Ambiente Ágil
- Distribuição do trabalho: Via sprint planning. A equipe puxa o trabalho do backlog priorizado — não recebe tarefas atribuídas pelo GP.
- Dados de desempenho: Velocidade (story points/sprint), burndown chart, lead time, cycle time, throughput. Métricas de fluxo, não de cronograma.
- Issue Log: Impedimentos registrados durante a daily standup e resolvidos pelo Scrum Master ou líder técnico. Mais ágil e menos formal.
- Reuniões: Daily standup (15 min), sprint review, sprint retrospective. Cadência curta e regular.
- Mudanças: Absorvidas naturalmente via repriorização do backlog. Não há “solicitação de mudança” formal — o Product Owner ajusta prioridades a cada sprint.
Ambiente Híbrido
- Distribuição do trabalho: Cronograma macro por fase (preditivo) + sprints dentro de cada fase (ágil). Trabalho atribuído por fase; dentro da fase, a equipe se auto-organiza.
- Dados de desempenho: EVM para fases e marcos; métricas ágeis para sprints. Dashboard integrado que mostra ambas as perspectivas.
- Issue Log: Formal para problemas que impactam fases ou gates; ágil para impedimentos de sprint.
- Reuniões: Standups diários + reunião semanal de status + gate reviews a cada fase.
- Mudanças: Mudanças de escopo de fase passam por processo formal; mudanças dentro da sprint são absorvidas via backlog.
Resumo comparativo do Tailoring
| Aspecto | Preditivo | Ágil | Híbrido |
|---|---|---|---|
| Distribuição | Por cronograma/EAP | Sprint planning + pull | Fase (preditivo) + sprint (ágil) |
| Dados de desempenho | EVM, % conclusão | Velocidade, burndown | EVM (macro) + ágil (sprint) |
| Issue Log | Formal com workflow | Impedimentos no daily | Formal (fase) + ágil (sprint) |
| Reuniões | Semanal formal | Daily + sprint events | Daily + semanal + gate reviews |
| Mudanças | Processo formal (CCB) | Repriorização do backlog | Formal (fase) + backlog (sprint) |
10. Interações com Outros Processos e Domínios
O processo Gerenciar Execução do Projeto é o coração operacional do PMBOK 8. Ele recebe insumos de praticamente todos os processos de planejamento e alimenta todos os processos de monitoramento.
Processos que alimentam a execução (dependências de entrada)
- Integrar e Alinhar os Planos do Projeto (Processo 2, Governança): O Plano de Gerenciamento é a referência principal da execução.
- Planejar Estratégia de Aquisições (Processo 3, Governança): Define como fornecedores serão gerenciados durante a execução.
- Avaliar e Implementar Mudanças (Processo 8, Governança): Fornece mudanças aprovadas para implementação.
- Todos os processos de planejamento (Escopo, Cronograma, Finanças, Recursos, Riscos, Stakeholders): Cada plano subsidiário alimenta a execução com diretrizes específicas.
Processos que dependem da execução (dependências de saída)
| Processo que recebe a saída | Domínio | O que recebe |
|---|---|---|
| Gerenciar Garantia da Qualidade (Processo 5) | Governança | Entregas para inspeção de qualidade |
| Gerenciar o Conhecimento (Processo 6) | Governança | Lições aprendidas e conhecimento gerado durante a execução |
| Monitorar e Controlar o Desempenho (Processo 7) | Governança | Dados de desempenho para análise e relatórios |
| Avaliar e Implementar Mudanças (Processo 8) | Governança | Solicitações de mudança para avaliação |
| Validar o Escopo (Escopo) | Escopo | Entregas concluídas para aceitação formal pelo cliente |
| Controlar o Cronograma (Cronograma) | Cronograma | Datas reais de início/término para comparação com a linha de base |
| Controlar os Custos (Finanças) | Finanças | Custos reais incorridos para análise de variação |
Interações com os Domínios do PMBOK 8
Governança: A execução é o processo central que conecta planejamento a monitoramento dentro do domínio de governança. Sem execução gerenciada, a governança perde seu propósito.
Escopo: A execução produz as entregas definidas no escopo. Desvios de escopo durante a execução são capturados como solicitações de mudança.
Cronograma: Dados de desempenho temporal (datas reais) alimentam o controle de cronograma. Atrasos na execução impactam diretamente o caminho crítico.
Finanças: A execução consome 60-80% do orçamento. Custos reais coletados durante a execução alimentam o controle financeiro.
Riscos: Riscos materializados durante a execução ativam respostas planejadas. Novos riscos identificados durante a execução alimentam o registro de riscos.
Recursos: A execução depende de recursos humanos, materiais e tecnológicos. Problemas de disponibilidade, competência ou produtividade impactam diretamente a execução.
Partes Interessadas: Stakeholders recebem entregas, participam de reuniões e fornecem feedback durante a execução. A satisfação dos stakeholders é diretamente influenciada pela qualidade da gestão da execução.
11. Checklist de Aplicação Rápida
Use estes 7 itens como referência rápida durante a execução do projeto:
- O trabalho está sendo distribuído e executado conforme o plano de gerenciamento (atividades, responsáveis, prazos)?
- Dados de desempenho estão sendo coletados continuamente (progresso, custos reais, qualidade)?
- O Issue Log está ativo e atualizado, com problemas registrados, priorizados e com responsável definido?
- Mudanças aprovadas estão sendo implementadas e documentadas — e mudanças não aprovadas não estão sendo aceitas informalmente?
- Reuniões de acompanhamento estão ocorrendo com frequência adequada (diária, semanal) e gerando ações concretas?
- Fornecedores externos estão sendo monitorados com a mesma disciplina da equipe interna?
- Solicitações de mudança estão sendo registradas formalmente e encaminhadas para avaliação — não implementadas diretamente?
Regra prática: Se menos de 5 destes itens estão sendo atendidos, a execução está fora de controle. O custo de corrigir agora é uma fração do custo de descobrir os problemas na entrega final.
12. Faça agora com IA: o Processo 27 do PMBOK 8 Together
O PMBOK 8 Together é o curso gratuito que executa este processo no seu projeto: você responde no seu quadro, roda o processo e ele escreve o documento — preenchido, no modelo pronto. É o Processo 27 de 40.
O que este processo lê do seu quadro
- a situação de conclusão dos cartões
- as datas e dependências dos pacotes de trabalho
- a lista Riscos e Premissas
- a lista Mudanças
O que ele entrega
- Dados de desempenho do trabalho
- Registro de Problemas
- Solicitação de mudança
Entregas o curso não gera: dependem de dados que o quadro não guarda (feriados, turnos, disponibilidade por pessoa). O processo diz quais são e por quê.
Como rodar
- Responda no seu quadro do projeto (ProjectAdm).
- Rode o processo 27 — ele devolve o prompt pronto, com os seus dados, na área de transferência.
- Cole na sua IA. Ela propõe; você decide.
- Cole a resposta na Caixa de entrada do quadro e rode o processo de novo — agora ele escreve o documento.
Baixar o pacote do curso — gratuito e sem instalar nada. Primeira vez? Veja a instalação padrão (5 minutos). As 40 aulas, com certificado, você recebe inscrevendo-se na página do curso.
Para se aprofundar em cada saída
Conclusão
O processo Gerenciar Execução do Projeto é onde o projeto gera valor — ou desperdiça recursos. A mudança de nome do PMBOK 6 para o PMBOK 8 reforça essa visão: não se trata apenas de “orientar o trabalho”, mas de gerenciar ativamente toda a execução, com dados, disciplina e liderança.
Os três pontos essenciais para levar para a prática:
- Dados de desempenho não são burocracia — são sobrevivência. Sem dados, o gerente de projeto navega no escuro. Com dados, ele antecipa problemas, justifica decisões e demonstra progresso. A coleta deve ser contínua, simples e integrada à rotina da equipe.
- O Issue Log é o radar do projeto. Problemas não registrados são problemas invisíveis — e problemas invisíveis se acumulam até explodirem. Criar uma cultura de registro imediato e resolução rápida é uma das ações de maior impacto que o gerente de projeto pode tomar.
- Toda mudança passa pelo processo formal — sem exceção. A erosão do escopo acontece uma “pequena mudança” por vez. Mesmo mudanças pequenas devem ser registradas e aprovadas. O objetivo não é impedir mudanças, mas garantir que todas sejam conscientes.
Próximo passo concreto: Abra o seu projeto atual. Os dados de desempenho estão atualizados? O Issue Log existe e está sendo usado? Mudanças informais estão acontecendo sem registro? Se a resposta for “sim” para a última pergunta, você identificou o gap mais urgente. Comece hoje: registre todas as mudanças pendentes e defina a regra com a equipe.
Veja todos os artigos do PMBOK 8 no Indice Completo
No livro
Gerenciar a Execução do Projeto é o Capítulo 28 de PMBOK 8 na Prática — os 40 processos do Guia PMBOK 8 numa ordem escolhida para você aprender aplicando, com 53 modelos — um por saída —, dois projetos acompanhados do início ao fim e um prompt de IA por capítulo.
CTA Final
Gostou do artigo?
(*) Newsletter com os próximos artigos da série PMBOK 8 e com templates e checklists prontos para aplicar.
Referências:
Cadastre-se para navegar sem anúncios e participar do Project Together →
Disclaimer:
Este artigo tem caráter informativo e educacional, com o objetivo de apresentar uma análise independente sobre o Guia PMBOK®. O conteúdo aqui publicado não reproduz nem substitui o material original do PMI e respeita integralmente seus direitos autorais. As marcas PMI e PMBOK® Guide são registradas pelo Project Management Institute. Para acesso ao conteúdo completo e oficial, adquira o guia pela Amazon ou baixe de forma gratuita em https://www.pmi.org/standards/pmbok se você é membro do PMI.
QUIZ
Quer testar o que aprendeu neste artigo?
Uma pergunta de múltipla escolha + uma reflexão prática. Ganhe pontos no Project Together!
💬 Reflexões da comunidade
Pretendo aplicar um acompanhamento mais próximo da execução do projeto, garantindo que as atividades sejam realizadas conforme o planejado e que problemas sejam tratados rapidamente. Isso ajudará a reduzir desvios, melhorar a colaboração da equipe e manter o foco nas entregas que geram valor.
— Rafael Ferreira Alves · 1 semana atrás
O controle das entregas nos projetos é importante.
— Dominick Ronaldo Doza Saboya · 1 mês atrás
Importante conteúdo para andamento do projeto.
— Giovani Jardim · 2 meses atrás
Gerenciar ativamente esse processo é a forma de alinhar o barco na direção certa, é assumir a responsabilidade de remover os impedimentos e orientar a equipe para entregar o seu melhor é ter certeza de que o projeto está entregando valor mensuravel para todos os envolvidos.
— [email protected] · 2 meses atrás
Pretendo aplicar o Passo 5: Gerencie a equipe e resolva conflitos, pois intervir rapidamente em desentendimentos e alinhar as expectativas do time mantém o clima colaborativo e evita quedas de produtividade.
— Adriana Lanes · 3 meses atrás
Como Associado da Amazon, a escritoriodeprojetos.com.br recebe por compras qualificadas. Os links para a Amazon nesta página são links de afiliado; o preço que você paga não muda.
