Controlar o Cronograma — PMBOK 8: Guia Completo (2026)

Artigo atualizado em março/2026 para o PMBOK® Guide — Eighth Edition.

Monitorar e Controlar o Cronograma: O Processo que Detecta Desvios Antes que Virem Crises (PMBOK 8)

Anteriormente: Controlar o Cronograma (PMBOK 6)

Imagine este cenário: o cronograma foi construído com rigor — caminho crítico identificado, recursos nivelados, linha de base aprovada. Três semanas depois, ninguém atualizou o progresso das atividades. O Gantt mostra 15% de avanço, mas a realidade é 8%. Quando o patrocinador pede o status na reunião mensal, o gerente de projeto descobre o atraso ao vivo, diante de toda a diretoria. Não havia monitoramento. Não havia controle. O cronograma existia, mas estava morto.

Cadastre-se para navegar sem anúncios e participar do Project Together →

No PMBOK 8, o processo Monitorar e Controlar o Cronograma (código 2.3.2.3) é o Processo 18, terceiro e último do Domínio de Cronograma. Ele garante que o cronograma aprovado permaneça vivo, atualizado e útil como ferramenta de decisão — não como artefato decorativo.

Neste guia completo você vai encontrar:

• O que é o processo Monitorar e Controlar o Cronograma e onde ele se encaixa no PMBOK 8
• Por que usá-lo — e o que acontece quando você não usa
• 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
• Exemplos práticos — Projeto Horizonte e Projeto ProjectAdm
• Atalhos, templates e dicas
• 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

1. O que é o Processo Monitorar e Controlar o Cronograma

Monitorar e Controlar o Cronograma é o processo de acompanhar o status das atividades do projeto para atualizar o progresso do cronograma e gerenciar mudanças na linha de base do cronograma. É o processo que transforma dados de execução em informações de desempenho e previsões.

No PMBOK 8, este é o Processo 3 do Domínio de Cronograma (código 2.3.2.3). No PMBOK 6, era chamado Controlar o Cronograma — a adição de “Monitorar” no PMBOK 8 enfatiza que o processo não é apenas reativo (controlar desvios), mas também proativo (monitorar tendências antes que gerem desvios).

O processo produz saídas fundamentais:

• Informações de desempenho do trabalho — métricas calculadas como SV (variação de prazo), SPI (índice de desempenho de prazo), % concluída real vs. planejada
• Previsões do cronograma — estimativas atualizadas de quando o projeto ou fase será concluído, baseadas no desempenho real
• Solicitações de mudança — quando os desvios exigem ajustes na linha de base ou ações corretivas/preventivas
• Atualizações — do plano de gerenciamento, dos documentos do projeto e dos ativos de processos organizacionais

Monitorar vs. Controlar

Aspecto	Monitorar	Controlar
Natureza	Observar e medir	Agir e corrigir
Foco	Tendências e padrões	Desvios e exceções
Timing	Contínuo e proativo	Quando o limiar é ultrapassado
Resultado	Informações de desempenho	Ações corretivas/preventivas

2. Por que Usar o Processo Monitorar e Controlar o Cronograma

Um cronograma sem monitoramento é como um GPS que só mostra a rota mas nunca recalcula. É útil na partida, mas se torna irrelevante assim que você desvia do caminho.

Benefícios diretos

• Detecção precoce de desvios: Monitorar continuamente permite identificar tendências de atraso antes que se tornem crises irrecuperáveis.
• Previsões baseadas em dados: Em vez de “achismo”, as previsões de término são calculadas com base no desempenho real (SPI, velocity).
• Decisões fundamentadas: Quando o patrocinador pergunta “vamos atrasar?”, a resposta é baseada em métricas, não em percepção.
• Gestão proativa de mudanças: Desvios são tratados como solicitações formais de mudança, com análise de impacto e aprovação antes da implementação.
• Lições aprendidas em tempo real: O monitoramento gera dados de desempenho que podem ser usados para calibrar estimativas futuras.
• Proteção da linha de base: O controle formal evita que a linha de base seja alterada informalmente, preservando sua utilidade como referência.

O que acontece quando o processo é ignorado

• Atrasos invisíveis: O cronograma mostra uma versão da realidade; a execução mostra outra. Ninguém percebe até ser tarde demais.
• Reação tardia: Sem monitoramento, os desvios são descobertos quando já são grandes demais para ações corretivas simples.
• Linha de base morta: Sem comparação sistemática entre planejado e real, a linha de base se torna um artefato histórico sem utilidade prática.
• Previsões subjetivas: “Acho que vamos terminar no prazo” substitui “Os dados mostram que terminaremos 2 semanas após o prazo”.
• Scope creep temporal: Atividades são adicionadas ao cronograma sem análise de impacto, consumindo folgas e comprometendo o caminho crítico.

O princípio “Líder Responsável” do PMBOK 8 se manifesta aqui: um líder responsável não espera que os problemas apareçam — ele monitora continuamente e age quando os sinais indicam desvio.

3. Entradas, Ferramentas e Técnicas, e Saídas (ITTO)

Entradas	Ferramentas e Técnicas	Saídas
Plano de gerenciamento do projeto Documentos do projeto (cronograma, dados do cronograma, calendários, registro de lições aprendidas) Dados de desempenho do trabalho Ativos de processos organizacionais (APO)	Análise de dados (análise de valor agregado, análise de tendências, análise de variação, análise what-if) Método do Caminho Crítico Sistema de informações de gerenciamento de projetos (SIGP) Otimização de recursos Antecipações e esperas Compressão de cronograma	Informações de desempenho do trabalho Previsões do cronograma Solicitações de mudança Atualizações (plano de gerenciamento, documentos do projeto, APO)

Detalhamento das Entradas

Plano de gerenciamento do projeto: Inclui o plano de gerenciamento do cronograma (limiares de controle, regras de medição, frequência de atualização), a linha de base do cronograma (referência para comparação) e a linha de base do escopo (para verificar se mudanças de escopo afetam o cronograma).

Documentos do projeto: O cronograma atualizado, os dados do cronograma (atividades, dependências, folgas), os calendários do projeto e o registro de lições aprendidas de períodos anteriores.

Dados de desempenho do trabalho: Informações brutas sobre o progresso — datas reais de início e término de atividades, % concluída, duração restante estimada. São os dados crus que serão processados por este processo.

Ativos de processos organizacionais (APO): Políticas de controle de mudanças, ferramentas de monitoramento, templates de relatórios de desempenho e bases de dados históricas para comparação.

Detalhamento das Ferramentas e Técnicas

Análise de valor agregado (EVA): Compara o valor planejado (PV) com o valor agregado (EV) para calcular a variação de prazo (SV = EV – PV) e o índice de desempenho de prazo (SPI = EV/PV). SPI > 1,0 indica adiantamento; SPI < 1,0 indica atraso.

Análise de tendências: Examina o desempenho ao longo do tempo para identificar padrões. Um SPI em queda constante indica que o projeto está desacelerando — mesmo que ainda esteja dentro do limiar de controle.

Análise de variação: Compara datas planejadas com datas reais para cada atividade ou marco. Identifica onde os desvios estão ocorrendo e quantifica o impacto.

Análise what-if: Simula cenários futuros com base no desempenho atual. “Se mantivermos esse ritmo, quando terminaremos?” “Se adicionarmos esse recurso, recuperamos o atraso?”

Método do Caminho Crítico: Recalculado periodicamente com as datas reais para verificar se o caminho crítico mudou (atividades que tinham folga podem ter se tornado críticas).

SIGP: Ferramentas automatizadas que coletam dados de progresso, calculam métricas de desempenho, geram relatórios e alertas automáticos quando limiares são ultrapassados.

Otimização de recursos: Quando o controle revela conflitos de recursos surgidos durante a execução, o nivelamento e a suavização são reaplicados.

Antecipações e esperas: Ajustadas durante o controle para compensar atrasos (reduzir lags, aumentar leads) sem alterar dependências fundamentais.

Compressão de cronograma: Crashing e fast-tracking aplicados como ação corretiva quando o cronograma está atrasado e a data final é inegociável.

4. Como Aplicar o Processo Passo a Passo

Passo 1 — Colete dados de desempenho

Na frequência definida no Plano de Gerenciamento do Cronograma, colete dados reais de progresso:

• Datas reais de início e término de atividades concluídas
• % concluída de atividades em andamento
• Duração restante estimada para atividades em andamento
• Atividades que deveriam ter iniciado mas não iniciaram
• Marcos atingidos vs. marcos planejados

Dica prática: Defina regras claras para medição de % concluída. A regra 0/100 (0% até concluir, 100% ao concluir) é a mais conservadora e precisa para atividades curtas. Para atividades longas, use 20/80 ou medição por entregáveis intermediários.

Passo 2 — Atualize o modelo de cronograma

Insira os dados reais no modelo de cronograma (ferramenta oficial). O SIGP recalculará automaticamente:

• Datas projetadas de término para atividades em andamento
• Impacto em atividades sucessoras
• Caminho crítico atualizado (pode ter mudado)
• Folgas recalculadas
• Data projetada de término do projeto

Passo 3 — Calcule métricas de desempenho

Com os dados atualizados, calcule as métricas principais:

Métrica	Fórmula	Interpretação
SV (Schedule Variance)	EV – PV	SV > 0: adiantado; SV < 0: atrasado
SPI (Schedule Performance Index)	EV / PV	SPI > 1: adiantado; SPI < 1: atrasado
EAC(t) (Estimate at Completion – time)	Duração planejada / SPI	Previsão de duração total com base no SPI atual
Variação de marco	Data real – Data planejada	Positivo: atrasado; Negativo: adiantado

Passo 4 — Compare com os limiares de controle

Verifique se as métricas calculadas estão dentro dos limiares definidos no Plano de Gerenciamento do Cronograma:

• Se dentro dos limiares: registre e monitore a tendência
• Se no limiar de alerta: intensifique o monitoramento, prepare plano de contingência
• Se ultrapassou o limiar de ação: execute a ação corretiva prevista e/ou escale

Passo 5 — Identifique causas-raiz dos desvios

Para cada desvio significativo, investigue a causa-raiz:

• Estimativa original otimista demais?
• Recurso indisponível (férias, doença, realocação)?
• Dependência externa atrasada (fornecedor, aprovação)?
• Mudança de escopo não formalizada?
• Complexidade técnica subestimada?
• Retrabalho por qualidade insuficiente?

Passo 6 — Defina e execute ações corretivas ou preventivas

Com base na causa-raiz e na severidade do desvio:

• Ação corretiva: Corrigir o desvio atual (crashing, fast-tracking, realocar recursos, reduzir escopo)
• Ação preventiva: Evitar que desvios similares ocorram em atividades futuras (melhorar estimativas, adicionar buffers, antecipar dependências)
• Solicitação de mudança: Se o desvio exige alteração na linha de base, formalize via controle integrado de mudanças

Passo 7 — Gere e comunique relatórios de desempenho

Produza os relatórios definidos no Plano de Gerenciamento do Cronograma e distribua-os aos stakeholders apropriados. Inclua:

• Métricas de desempenho (SV, SPI, variação de marcos)
• Previsão atualizada de término (EAC temporal)
• Desvios significativos com causas-raiz e ações planejadas
• Mudanças no caminho crítico (se houver)
• Riscos temporais emergentes

5. Quando Aplicar o Processo

Cenários obrigatórios

• Durante toda a execução do projeto: Sempre. O monitoramento é contínuo e a frequência é definida no plano.
• Em gate reviews de fase: Antes de autorizar a próxima fase, o desempenho temporal da fase atual deve ser avaliado.
• Após qualquer mudança aprovada: Mudanças de escopo, recurso ou restrição exigem reavaliação do cronograma.

Cenários recomendados

• Quando o SPI apresenta tendência de queda: Mesmo dentro do limiar, uma tendência de queda indica problema futuro.
• Quando atividades do caminho crítico iniciam: Aumente a frequência de monitoramento para atividades críticas.
• Quando dependências externas se materializam: Fornecedores, aprovações regulatórias, entregas de terceiros.

Gatilhos que indicam que o controle é necessário

• Atividades que deveriam ter começado ainda não iniciaram
• Marcos foram atingidos com atraso
• A equipe reporta bloqueios ou dependências não resolvidas
• O patrocinador relata insatisfação com o progresso
• Novos riscos foram identificados que afetam o cronograma

6. Exemplos Práticos por Setor

Exemplo 1 — Implantação do PMO: Projeto Horizonte

Contexto: O Projeto Horizonte estava na semana 10 de 24. Ana Silveira tinha a linha de base aprovada e o Plano de Gerenciamento do Cronograma com limiares definidos. Era hora de aplicar o monitoramento e controle.

Como o processo foi aplicado:

1. Coleta de dados (semanal): Ana coletava o progresso toda sexta-feira: atividades concluídas, % de avanço das atividades em andamento e datas reais de início/término. Na semana 10, a atividade “Customização da plataforma ProjectAdm” (caminho crítico, duração planejada: 40 dias) estava com 45% concluída no dia 20 — deveria estar com 50%.
2. Cálculo de métricas: SPI do projeto = 0,91 (abaixo de 1,0 mas acima do limiar de 0,85). SPI da fase Plataforma = 0,87 — mais próximo do limiar. Variação do caminho crítico: 2 dias de atraso acumulado.
3. Análise de tendência: Ana plotou o SPI das últimas 4 semanas: 0,97 → 0,95 → 0,93 → 0,91. Tendência de queda constante. Se mantida, o SPI atingiria o limiar de 0,85 na semana 13.
4. Causa-raiz: Diego Carvalho (analista sênior) estava dedicando 30% do tempo a resolver problemas operacionais urgentes por pedido de Marcos Tanaka (gerente de operações). Isso não estava previsto no plano.
5. Ação corretiva: Ana reuniu-se com Roberto Campos (CEO) e obteve uma decisão formal: Diego seria 100% dedicado ao projeto até a conclusão da fase Plataforma. Marcos Tanaka designaria outro analista para as demandas operacionais.
6. Resultado: Na semana 12, o SPI havia se recuperado para 0,94. O atraso de 2 dias foi absorvido pela folga remanescente de 4 dias. A fase Plataforma foi concluída no prazo.

Exemplo 2 — Desenvolvimento de Software: Projeto ProjectAdm

Contexto: O Projeto ProjectAdm estava na Sprint 7 de 21 (mês 3,5 de 12). Eduardo Montes monitorava a velocidade da equipe e os marcos de release.

Como o processo foi aplicado:

1. Coleta de dados (por sprint): Eduardo revisava a velocity ao final de cada sprint. Velocidade planejada: 22 pontos/sprint. Velocidade real nas últimas 3 sprints: 20, 18, 17. Tendência de queda clara.
2. Projeção de release: Release 1 (MVP) precisava de 120 pontos no total. Já entregues: 94 pontos em 7 sprints. Faltavam 26 pontos em 2 sprints (até o mês 4). Com velocity de 17/sprint, entregariam apenas 34 pontos — suficiente, mas sem margem.
3. Análise de causa-raiz: Julia Chen (frontend) reportou que a integração com a biblioteca de gráficos estava tomando 40% mais tempo que o estimado. Os story points das tarefas de dashboard estavam subavaliados.
4. Ação preventiva para R2: Eduardo reestimou todas as tarefas de integração da Release 2 com fator de ajuste de 1,4x. O backlog da R2 passou de 160 para 195 pontos estimados, exigindo 11 sprints em vez de 8 — o que ultrapassava o prazo do mês 8.
5. Solicitação de mudança: Eduardo apresentou a Henry Douglas duas opções: (a) reduzir escopo da R2 em 35 pontos (eliminar integração com CRM, mover para R3) ou (b) adicionar um desenvolvedor frontend freelancer por 4 sprints (custo de R$ 18.000). Henry aprovou a opção (a), priorizando velocidade de entrega sobre escopo completo.
6. Atualização da linha de base: O roadmap de releases foi atualizado formalmente: R2 teria escopo reduzido e a integração com CRM migraria para R3. A nova linha de base foi aprovada em sprint review.

7. Atalhos, Templates e Dicas

Templates recomendados

• Template de Relatório de Desempenho do Cronograma: Documento com SV, SPI, variação de marcos, tendência, previsão de término e ações planejadas.
• Dashboard de Cronograma: Painel visual com semáforos por fase, burndown, caminho crítico e alertas de limiar.
• Template de Análise de Variação: Tabela com atividade, data planejada, data real, variação, causa-raiz e ação corretiva.

Dicas avançadas

• Monitore tendências, não apenas valores absolutos: Um SPI de 0,95 pode parecer aceitável, mas se vier caindo de 1,05 nas últimas 4 semanas, indica um problema em formação.
• Recalcule o caminho crítico periodicamente: O caminho crítico pode mudar durante a execução. Uma atividade que tinha folga pode se tornar crítica se outras atividades consumiram a folga.
• Use EVM temporal, não apenas financeiro: A análise de valor agregado para cronograma (SV, SPI) é tão importante quanto a financeira (CV, CPI). Monitore ambos.
• Automatize alertas: Configure o SIGP para enviar alertas quando limiares forem ultrapassados. Não dependa de revisão manual para detectar problemas.
• Documente lições aprendidas em tempo real: Quando uma ação corretiva funciona (ou falha), registre imediatamente. Não espere o final do projeto.

8. Erros Comuns e Como Evitá-los

Erro 1 — Atualizar o cronograma sem analisar o desempenho

Por que acontece: A equipe atualiza as datas no cronograma quando há atraso, mas não calcula métricas de desempenho (SV, SPI) nem analisa tendências. O cronograma parece atualizado, mas ninguém sabe se o projeto está dentro dos limiares.

Como evitar: Atualizar o cronograma e analisar o desempenho são duas etapas distintas e sequenciais. Primeiro atualize os dados; depois calcule as métricas; depois compare com os limiares; depois decida se precisa agir.

Erro 2 — Mudar a linha de base sem aprovação formal

Por que acontece: O GP ajusta a linha de base informalmente para que os relatórios mostrem que o projeto está “no prazo”. Resultado: a linha de base perde sua utilidade como referência de desempenho e o controle se torna uma ficção.

Como evitar: Qualquer mudança na linha de base deve passar pelo controle integrado de mudanças. Se o projeto está atrasado, o relatório deve mostrar que está atrasado — não esconder o desvio ajustando a referência.

Erro 3 — Monitorar com frequência insuficiente

Por que acontece: A equipe monitora mensalmente um projeto de 3 meses. Resultado: os desvios são detectados quando já consumiram toda a folga disponível.

Como evitar: A frequência de monitoramento deve ser proporcional ao risco e à duração do projeto. Projetos de 3 meses: semanal. Projetos ágeis: por sprint (ou diário para burndown). Atividades no caminho crítico: frequência dobrada.

Erro 4 — Focar em % concluída sem verificar entregas

Por que acontece: A equipe reporta “80% concluída” sem nenhuma entrega intermediária verificável. O fenômeno dos “90% eternos” — a atividade fica em 90% por semanas.

Como evitar: Use regras objetivas de medição: 0/100 (só conta quando termina), 50/50 (50% ao iniciar, 50% ao concluir) ou medição por entregas intermediárias. Evite estimativas subjetivas de % concluída.

Erro 5 — Não escalar quando o limiar é ultrapassado

Por que acontece: O GP detecta que o SPI ultrapassou o limiar mas não escala para o patrocinador, esperando “resolver sozinho”. Resultado: o desvio cresce até se tornar irrecuperável sem intervenção executiva.

Como evitar: Os limiares e regras de escalação existem para serem seguidos. Escalar não é sinal de incompetência — é sinal de governança saudável. Documente a escalação e a decisão do patrocinador.

9. Tailoring: Preditivo, Ágil e Híbrido

Ambiente Preditivo (Waterfall)

• Monitoramento: Comparação semanal entre linha de base e progresso real. Análise de valor agregado (SV, SPI, EAC temporal).
• Controle: Ações corretivas formais (crashing, fast-tracking, replanejamento). Mudanças na linha de base via controle integrado.
• Relatórios: Gantt com progresso, tabela de variação de marcos, curva S temporal.

Ambiente Ágil

• Monitoramento: Burndown diário, velocity por sprint, release burnup.
• Controle: Ajuste de escopo do sprint (sprint backlog é negociável), repriorização de backlog, ajuste de capacidade.
• Relatórios: Burndown chart, velocity trend, release forecast.

Ambiente Híbrido

• Monitoramento: Marcos via EVA (preditivo) + velocity via burndown (ágil).
• Controle: Marcos protegidos (mudanças formais) + escopo de sprint flexível.
• Relatórios: Dashboard consolidado com marcos (semáforo) + burndown por sprint.

Resumo comparativo do Tailoring

Aspecto	Preditivo	Ágil	Híbrido
Frequência	Semanal	Diário (burndown) + sprint	Marcos: quinzenal / Sprints: diário
Métrica principal	SPI + variação de marcos	Velocity + burndown	Ambas por camada
Ação corretiva típica	Crashing / fast-tracking	Redução de escopo do sprint	Crashing (marcos) + scope trim (sprints)
Mudança de linha de base	Formal (comitê de mudanças)	Velocity recalibrada	Marcos: formal / Sprints: flexível

10. Interações com Outros Processos e Domínios

Processos que alimentam este processo

• Desenvolver o Cronograma (Cronograma): Fornece a linha de base e o modelo de cronograma
• Orientar e Gerenciar o Trabalho (Governança): Gera os dados de desempenho do trabalho
• Realizar o Controle Integrado de Mudanças (Governança): Aprova mudanças na linha de base

Processos que dependem deste processo

Processo	Domínio	O que recebe
Monitorar e Controlar as Finanças	Finanças	Informações de desempenho temporal para análise integrada custo-prazo
Monitorar Riscos	Riscos	Desvios de cronograma que podem ativar riscos identificados
Gerenciar as Comunicações	Partes Interessadas	Relatórios de desempenho para distribuição aos stakeholders
Realizar o Controle Integrado de Mudanças	Governança	Solicitações de mudança na linha de base do cronograma

Interações com os Domínios

Governança: As solicitações de mudança no cronograma alimentam o controle integrado de mudanças. As informações de desempenho alimentam os relatórios de status do projeto.

Finanças: O desempenho temporal e o desempenho financeiro são interdependentes. Atrasos geralmente geram custos adicionais. A análise de valor agregado integra ambas as dimensões.

Riscos: Desvios de cronograma podem ativar riscos identificados ou revelar riscos novos. Reservas de tempo consumidas devem ser comunicadas ao processo de monitoramento de riscos.

Recursos: Ações corretivas no cronograma (crashing) exigem recursos adicionais. A disponibilidade de recursos pode ser a causa dos desvios.

Partes Interessadas: Stakeholders precisam ser informados sobre desvios significativos e previsões atualizadas. A frequência e o formato da comunicação devem seguir o plano de comunicações.

11. Checklist de Aplicação Rápida

1. Os dados de desempenho do trabalho estão sendo coletados na frequência definida no plano, com regras claras de medição de progresso?
2. O modelo de cronograma está atualizado com datas reais e o caminho crítico foi recalculado?
3. As métricas de desempenho (SV, SPI) estão sendo calculadas e comparadas com os limiares de controle?
4. Tendências de desempenho estão sendo analisadas (não apenas valores pontuais) para detectar problemas em formação?
5. Desvios significativos foram investigados quanto à causa-raiz e ações corretivas/preventivas foram definidas?
6. Previsões de término baseadas em dados (não em otimismo) estão sendo comunicadas aos stakeholders?
7. Solicitações de mudança na linha de base estão sendo formalizadas via controle integrado de mudanças?

Regra prática: Se menos de 5 destes itens estão sendo atendidos, o cronograma está desgovernado. Um cronograma sem monitoramento ativo é um artefato histórico — útil para a auditoria pós-mortem, inútil para a gestão.

12. Faça agora com IA: o Processo 33 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 33 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 Mudanças

O que ele entrega

• Informações sobre o desempenho do trabalho
• Previsões do Cronograma
• Solicitação de mudança

Como rodar

1. Responda no seu quadro do projeto (ProjectAdm).
2. Rode o processo 33 — ele devolve o prompt pronto, com os seus dados, na área de transferência.
3. Cole na sua IA. Ela propõe; você decide.
4. 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

• Informações sobre o desempenho do trabalho
• Previsões do Cronograma
• Solicitação de mudança

Conclusão

O processo Monitorar e Controlar o Cronograma é o que mantém o cronograma vivo. Sem ele, a linha de base aprovada é um retrato congelado de uma realidade que mudou no dia seguinte.

Os três pontos essenciais:

• Monitorar é proativo; controlar é reativo. O PMBOK 8 enfatiza ambos. Detectar tendências antes que virem desvios é mais eficiente do que corrigir crises depois que acontecem.
• Métricas sem ação são decoração. Calcular SPI e não agir quando ele cai abaixo do limiar é o mesmo que não calcular. O valor das métricas está nas decisões que elas informam.
• A linha de base é sagrada. Mudar informalmente a linha de base para “melhorar os números” é fraude gerencial. Se o projeto está atrasado, o relatório deve dizer que está atrasado — e propor ações para recuperar.

Próximo passo concreto: Verifique o SPI do seu projeto atual. Se não sabe o SPI, você não está monitorando. Se sabe mas não está comparando com um limiar, você não está controlando. Se está comparando mas não está agindo, você está apenas observando.

Veja todos os artigos do PMBOK 8 no Indice Completo

---

🇺🇸 Read this article in English

CTA Final

Gostou do artigo?

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

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.

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.