Artigo atualizado em março/2026 para o PMBOK® Guide — Eighth Edition.
Cadastre-se para navegar sem anúncios e participar do Project Together →
Iniciar Projeto ou Fase: O Processo que Define se o Projeto Nasce Forte ou Já Nasce Condenado (PMBOK 8)
Anteriormente: Desenvolver o Termo de Abertura do Projeto (PMBOK 6)
Imagine este cenário: a diretoria aprovou o projeto na sexta-feira, e na segunda a equipe já está executando. Ninguém sabe exatamente quem é o gerente de projeto. Os objetivos foram discutidos em uma reunião informal, mas nunca documentados. As premissas existem apenas na cabeça do patrocinador. Três meses depois, o projeto está com escopo descontrolado, orçamento estourado e uma equipe que não sabe por que está fazendo o que faz. Esse cenário não é exceção — é o resultado previsível de pular a iniciação formal.
No PMBOK 8, o processo Iniciar Projeto ou Fase é o Processo 1 do Domínio de Governança — e existe por uma razão simples: sem autorização formal, sem alinhamento de expectativas e sem documentação das premissas, o projeto não tem fundação. É como construir um edifício sem fundação: pode até parecer que está avançando, mas o colapso é questão de tempo.
Neste guia completo você vai encontrar:
- O que é o processo Iniciar Projeto ou Fase 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 que indicam que é hora de iniciar formalmente
- Exemplos práticos — Projeto Horizonte (Horizonte Transportes) e Projeto ProjectAdm (Desenvolvimento de Software SaaS)
- Atalhos, templates e dicas para acelerar a iniciaçã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 Iniciar Projeto ou Fase
Iniciar Projeto ou Fase é o processo que autoriza formalmente o início de um projeto ou de uma fase dentro de um projeto já existente. Ele define premissas, expectativas, restrições e, fundamentalmente, identifica e nomeia o gerente do projeto com autoridade reconhecida para alocar recursos e tomar decisões.
No PMBOK 8, este é o Processo 1 do Domínio de Governança — o primeiro de 9 processos que compõem a estrutura de governança de projetos. Isso não é coincidência: a governança começa pela autorização formal. Sem ela, tudo o que vem depois — planejamento, execução, monitoramento — opera sem legitimidade.
O processo produz duas saídas fundamentais:
- Termo de Abertura do Projeto (Project Charter) — o documento que formaliza a existência do projeto, seus objetivos, restrições, marco de alto nível e a autoridade do gerente de projeto
- Registro das Premissas (Assumption Log) — o documento que captura todas as suposições, condições e limitações aceitas como verdadeiras no momento da iniciação, mas que precisam ser validadas ao longo do projeto
Uma novidade do PMBOK 8 para este processo é a inclusão do Canvas do Projeto (Project Canvas) como ferramenta e técnica. O Canvas permite que a equipe visualize, em uma única página, os elementos essenciais do projeto — propósito, valor, stakeholders, riscos, premissas e entregas — facilitando o alinhamento rápido entre todos os envolvidos.
Diferença entre iniciar um projeto e iniciar uma fase
O processo se aplica a ambos os cenários, mas com diferenças de escopo:
| Aspecto | Iniciar Projeto | Iniciar Fase |
|---|---|---|
| Autorização | Autoriza o projeto inteiro | Autoriza a continuidade para a próxima fase |
| Documento principal | Termo de Abertura completo | Termo de Abertura da fase ou atualização do Termo original |
| Nível de detalhe | Alto nível — visão geral do projeto | Mais detalhado — foco nos objetivos e entregas da fase |
| Premissas | Premissas iniciais do projeto | Premissas atualizadas com base nas fases anteriores |
| Decisor | Patrocinador ou comitê de governança | Gate review ou sponsor da fase |
2. Por que Usar o Processo Iniciar Projeto ou Fase
A iniciação formal não é burocracia — é a fundação sobre a qual todo o projeto será construído. Quando bem executada, ela gera benefícios concretos e mensuráveis:
Benefícios diretos
- Legitimidade formal: O projeto existe oficialmente perante a organização. Recursos podem ser alocados, contratos podem ser assinados, decisões têm amparo documental.
- Alinhamento de expectativas: Patrocinador, gerente de projeto e stakeholders-chave partem de uma mesma base documentada — objetivos, restrições, premissas e critérios de sucesso.
- Definição clara de autoridade: O gerente de projeto é nomeado formalmente, com escopo de autoridade definido. Não há ambiguidade sobre quem decide o quê.
- Rastreabilidade desde o dia zero: Premissas são documentadas, decisões iniciais são registradas, e o projeto nasce com um histórico que pode ser auditado.
- Base para o planejamento: Sem o Termo de Abertura, o planejamento não tem referência. É como tentar criar um plano de viagem sem saber o destino.
- Controle de gate para fases: Ao aplicar a iniciação por fase, a organização cria pontos de decisão formais — continuar, ajustar ou cancelar — antes de comprometer mais recursos.
O que acontece quando o processo é ignorado
As consequências de pular ou subestimar a iniciação são previsíveis e documentadas:
- Escopo descontrolado: Sem objetivos documentados, qualquer demanda parece legítima. O scope creep começa no dia 1.
- Conflitos de autoridade: Sem nomeação formal do gerente de projeto, múltiplas pessoas tentam tomar decisões, gerando conflitos e paralisia.
- Premissas invisíveis: Todos assumem coisas diferentes — prazos, orçamentos, disponibilidade de recursos — mas ninguém documentou. Quando a realidade diverge, não há referência para ajustar.
- Retrabalho no planejamento: A equipe planeja com base em suposições não validadas. Quando o patrocinador finalmente revisa, descobre que o plano inteiro está desalinhado com a expectativa original.
- Cancelamento tardio: Projetos que não deveriam ter sido iniciados consomem recursos por meses antes de alguém perceber que não havia viabilidade desde o início.
O princípio “Foque no Valor” do PMBOK 8 reforça essa necessidade: se o projeto não demonstra valor desde a iniciação, ele não deveria consumir recursos. A iniciação formal é o primeiro filtro de valor.
3. Entradas, Ferramentas e Técnicas, e Saídas (ITTO)
A tabela abaixo apresenta o ITTO completo do processo Iniciar Projeto ou Fase, conforme o PMBOK 8:
| Entradas | Ferramentas e Técnicas | Saídas |
|---|---|---|
|
|
|
Detalhamento das Entradas
Documentos de negócio: Incluem o Business Case (justificativa financeira e estratégica do projeto), o Plano de Gerenciamento de Benefícios (como os benefícios serão medidos e realizados) e o estudo de viabilidade. São a base para determinar se o projeto deve existir.
Acordos: Contratos com clientes, memorandos de entendimento, cartas de intenção ou acordos internos entre departamentos. Quando o projeto nasce de uma demanda contratual, o acordo é a entrada mais importante.
Fatores ambientais da empresa (EEFs): Condições externas e internas que influenciam o projeto — cultura organizacional, estrutura de governança existente, condições de mercado, regulamentações, infraestrutura disponível.
Ativos de processos organizacionais (OPAs): Templates existentes, lições aprendidas de projetos anteriores, políticas internas, repositórios de conhecimento, padrões de documentação.
Detalhamento das Ferramentas e Técnicas
Opinião especializada: Consulta a especialistas que possuem conhecimento técnico, de negócio ou de gestão relevante para a definição do projeto. Pode incluir consultores externos, gerentes seniores, especialistas técnicos ou profissionais com experiência em projetos similares.
Coleta de dados: Técnicas como brainstorming (geração de ideias para objetivos e premissas), entrevistas (com patrocinador e stakeholders-chave) e benchmarking (comparação com projetos similares já realizados).
Habilidades interpessoais e de equipe: Incluem gestão de conflitos (alinhar expectativas divergentes entre stakeholders), facilitação (conduzir reuniões produtivas de iniciação) e gestão de reuniões (estruturar o kickoff de forma eficiente).
Reuniões: Reuniões de alinhamento com o patrocinador, kickoff meetings, sessões de definição de premissas e restrições, e gate reviews para aprovação de fases.
Matriz de responsabilidades: Ferramenta que define quem é Responsável, quem Aprova, quem é Consultado e quem é Informado (RACI) para as principais atividades e decisões do projeto. No contexto da iniciação, define a estrutura de governança inicial.
Canvas do projeto: Uma das novidades do PMBOK 8. É uma ferramenta visual que permite mapear, em uma única página, os elementos essenciais do projeto: propósito, justificativa, stakeholders, entregas, premissas, restrições, riscos e critérios de sucesso. Funciona como um “mapa mental estruturado” que facilita o alinhamento rápido entre todos os participantes da iniciação.
Detalhamento das Saídas
Termo de Abertura do Projeto (Project Charter): O documento que autoriza formalmente o projeto ou fase. Deve conter, no mínimo: propósito/justificativa, objetivos mensuráveis, requisitos de alto nível, premissas e restrições, riscos iniciais, cronograma de marcos, orçamento resumido, critérios de sucesso, nome e autoridade do gerente de projeto, e nome e autoridade do patrocinador.
Registro das Premissas (Assumption Log): Documento que lista todas as suposições feitas durante a iniciação — condições assumidas como verdadeiras, mas que ainda não foram confirmadas. Cada premissa deve ser acompanhada da sua origem, impacto potencial caso não se confirme e responsável por validá-la. O registro é um documento vivo: deve ser revisado e atualizado ao longo de todo o projeto.
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 — Reúna e analise os documentos de negócio
Antes de qualquer reunião, colete e revise o Business Case, o estudo de viabilidade, o Plano de Benefícios e qualquer acordo contratual existente. Pergunte-se:
- A justificativa do projeto é clara e quantificável?
- Os benefícios esperados estão definidos com métricas?
- Existe viabilidade técnica e financeira documentada?
- Os acordos contratuais impõem restrições que afetam o escopo ou o prazo?
Dica prática: Se o Business Case não existir ou for genérico demais, solicite ao patrocinador antes de avançar. Iniciar um projeto sem justificativa clara é plantar a semente do fracasso.
Passo 2 — Identifique e consulte os stakeholders-chave
Mapeie quem são as pessoas que influenciam ou são influenciadas pelo projeto. Nesta fase inicial, foque nos stakeholders de alto impacto:
- Patrocinador (sponsor)
- Cliente ou representante do cliente
- Diretores de áreas impactadas
- Especialistas técnicos relevantes
- Representantes de compliance ou regulatório (quando aplicável)
Conduza entrevistas individuais ou uma reunião de alinhamento para capturar expectativas, restrições e premissas de cada stakeholder-chave.
Passo 3 — Preencha o Canvas do Projeto
Utilize o Canvas do Projeto como ferramenta de facilitação em uma sessão colaborativa. Em uma reunião de 60 a 90 minutos, preencha os blocos:
- Propósito: Por que este projeto existe?
- Objetivo SMART: O que será alcançado, com qual métrica, até quando?
- Benefícios: Que valor será gerado para a organização e para os stakeholders?
- Produto/Entrega principal: O que será produzido?
- Stakeholders-chave: Quem está envolvido e com qual papel?
- Premissas: O que estamos assumindo como verdade?
- Restrições: Quais são os limites inegociáveis (prazo, orçamento, regulamentação)?
- Riscos iniciais: O que pode dar errado?
- Marcos de alto nível: Quais são as datas ou eventos críticos?
O Canvas funciona como um rascunho visual que depois será formalizado no Termo de Abertura. Sua vantagem é a velocidade de alinhamento — todos veem a mesma página, literalmente.
Passo 4 — Estruture a Matriz de Responsabilidades inicial
Defina, no mínimo, as seguintes responsabilidades:
| Papel | Quem | Responsabilidade principal |
|---|---|---|
| Patrocinador | [Nome] | Aprovar o Termo de Abertura, resolver impedimentos de alto nível, garantir financiamento |
| Gerente de Projeto | [Nome] | Liderar o planejamento e a execução, reportar status, gerenciar stakeholders |
| Cliente / Product Owner | [Nome] | Definir requisitos, validar entregas, priorizar backlog (em contextos ágeis) |
| Comitê de Governança | [Membros] | Aprovar mudanças significativas, conduzir gate reviews |
Esta matriz será expandida durante o planejamento, mas sua versão inicial é essencial para que todos saibam quem é quem desde o primeiro dia.
Passo 5 — Documente as premissas no Registro de Premissas
Para cada premissa identificada no Canvas e nas reuniões, registre:
- Descrição da premissa: O que está sendo assumido
- Origem: Quem forneceu essa premissa
- Impacto se não se confirmar: O que acontece se a premissa for falsa
- Responsável pela validação: Quem vai confirmar se é verdade
- Data prevista para validação: Quando será verificada
- Status: Aberta, confirmada, refutada
Exemplo: “Premissa: A equipe de TI terá 3 desenvolvedores seniores disponíveis em tempo integral a partir de maio. Origem: Diretor de TI. Impacto se falsa: Atraso de 4 a 6 semanas na entrega do MVP. Responsável: RH + Diretor de TI. Validação: até 15 de abril.”
Passo 6 — Redija o Termo de Abertura do Projeto
Com base no Canvas preenchido, nas entrevistas e na análise dos documentos de negócio, redija o Termo de Abertura formal. A estrutura recomendada inclui:
- Título do projeto e identificador único
- Propósito e justificativa do projeto (extraído do Business Case)
- Objetivos mensuráveis (SMART)
- Requisitos de alto nível
- Descrição de alto nível do projeto e suas entregas principais
- Premissas e restrições
- Riscos iniciais de alto nível
- Cronograma de marcos
- Orçamento resumido
- Critérios de sucesso do projeto
- Gerente de projeto designado — nome e nível de autoridade
- Patrocinador — nome e autoridade
- Aprovação formal (assinatura ou equivalente)
Dica prática: O Termo de Abertura não deve ter mais de 3 a 5 páginas. Se for mais longo, você provavelmente está detalhando o que deveria estar no Plano de Gerenciamento do Projeto (próximo processo).
Passo 7 — Obtenha a aprovação formal
Submeta o Termo de Abertura ao patrocinador (ou ao comitê de governança, dependendo da estrutura organizacional) para aprovação formal. A aprovação deve ser:
- Documentada: Assinatura física, digital ou registro em sistema de gestão
- Comunicada: Todos os stakeholders-chave devem ser informados de que o projeto foi formalmente autorizado
- Arquivada: O Termo aprovado deve ser armazenado no repositório do projeto como documento base
Após a aprovação, o projeto tem legitimidade para alocar recursos, iniciar o planejamento detalhado e executar as atividades previstas.
5. Quando Aplicar o Processo
O processo Iniciar Projeto ou Fase deve ser executado nos seguintes cenários:
Cenários obrigatórios
- Início de um novo projeto: Sempre. Sem exceção. Mesmo projetos pequenos precisam de uma versão simplificada da iniciação formal.
- Início de uma nova fase em projetos multi-fases: Cada fase deve ser formalmente autorizada antes de iniciar, permitindo que a organização decida se deve continuar, ajustar ou cancelar.
- Após aprovação do Business Case: Quando o estudo de viabilidade é concluído e a decisão de investir é tomada, a iniciação formaliza essa decisão.
Cenários recomendados
- Mudança estratégica significativa durante o projeto: Quando o direcionamento do projeto muda radicalmente (novo patrocinador, mudança de objetivo, fusão organizacional), pode ser necessário “re-iniciar” formalmente o projeto com um novo Termo de Abertura.
- Retomada de projeto paralisado: Se um projeto ficou parado por meses e as condições mudaram, é prudente executar novamente a iniciação para revalidar premissas, restrições e justificativa.
- Transição de gerente de projeto: Quando um novo gerente assume um projeto em andamento, uma mini-iniciação ajuda a realinhar expectativas e documentar a transferência de autoridade.
Gatilhos que indicam que a iniciação é necessária
- A equipe está trabalhando sem saber quem tem autoridade para tomar decisões
- Stakeholders têm expectativas divergentes sobre os objetivos do projeto
- Não existe documento formal que justifique a existência do projeto
- Recursos estão sendo alocados sem aprovação documentada
- Premissas críticas não foram validadas nem registradas
- Uma fase foi concluída e a organização precisa decidir se avança para a próxima
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) recebeu o mandato para executar o Projeto Horizonte: implantação do Escritório de Projetos (PMO) usando ProjectAdm como plataforma de gestão, com metodologia, treinamento e marketing. O cliente perdia leads por ter um site lento e desatualizado — a meta era aumentar a conversão em 40% em 6 meses. Orçamento de R$ 360.000, duração de 4 meses.
Como o processo foi aplicado:
- Documentos de negócio: O diretor da agência apresentou um Business Case com benchmark competitivo, análise de taxa de rejeição do site atual (78%) e projeção de ROI para o cliente. O objetivo principal foi formalizado como “Aumentar a taxa de conversão de visitantes em leads qualificados de 2,1% para 3,0% até o mês 6 pós-lançamento”.
- Canvas do Projeto: Em uma sessão de 75 minutos com o PM, o gerente de contas, o designer sênior e o representante do cliente (CMO da consultoria), o Canvas mapeou o propósito (“Lançar um site de alta performance integrado ao HubSpot CRM até semana 16”), as entregas (novo site, fluxos de automação, integração CRM, treinamento da equipe do cliente), as premissas (acesso ao CRM existente será fornecido na semana 1, conteúdo aprovado pelo cliente em até 3 dias por sprint) e os riscos (atraso na aprovação de conteúdo, mudança de escopo nas integrações).
- Termo de Abertura: Documento de 3 páginas com objetivos SMART, orçamento aprovado por fase (discovery, design, desenvolvimento, integração/testes), nomeação formal do PM e autoridade para decidir soluções técnicas sem aprovação por escrito para itens abaixo de R$ 5.000.
- Registro de Premissas: 9 premissas documentadas, incluindo: “O cliente fornecerá briefing de conteúdo das 8 páginas principais até o início do Sprint 2”, “As credenciais de acesso ao HubSpot serão entregues na semana 1” e “Aprovações de design ocorrerão dentro da sprint, sem acumular revisões”.
Resultado: Quando o cliente solicitou a inclusão de um chatbot na semana 6 (fora do escopo original), o PM consultou o Termo de Abertura e o Registro de Premissas para avaliar o impacto: +R$ 28.000 e +2 semanas. A solicitação foi formalizada como mudança de escopo, aprovada pelo patrocinador e incorporada ao projeto com ajuste documentado — sem retrabalho nem conflito sobre “quem disse o quê”.
Exemplo 2 — Desenvolvimento de Software: Projeto ProjectAdm
Contexto: A equipe ProjectAdm (5 profissionais, startup SaaS de gestão de projetos) iniciou o Projeto ProjectAdm: desenvolvimento de uma plataforma SaaS de gerenciamento de projetos para pequenas e médias empresas, com templates PMBOK 8 integrados. O projeto envolvia integração com 3 sistemas legados (ERP, CRM e banco de dados contábil) e conformidade com requisitos regulatórios do Banco Central (BACEN). Orçamento de R$ 1.100.000, duração de 8 meses.
Como o processo foi aplicado:
- Documentos de negócio: O product owner elaborou um Business Case com análise de mercado (12 clientes corporativos em pipeline aguardando a plataforma), custo de oportunidade e projeção de ARR de R$ 4,2 milhões após o lançamento. O Comitê Executivo aprovou o projeto com restrição explícita: conformidade com a Circular BACEN 3.909 era inegociável, mesmo que implicasse ajuste de prazo.
- Sessão de iniciação com stakeholders: Workshop de 4 horas com PM, tech lead, product owner, representante jurídico/compliance, CTO e dois clientes-piloto. A sessão revelou uma premissa crítica não documentada: os clientes assumiam que os relatórios seriam gerados em tempo real (latência <5 segundos), enquanto a equipe de desenvolvimento havia estimado o projeto com latência de até 30 segundos. O conflito foi resolvido durante a iniciação — não durante a execução.
- Canvas do Projeto: Propósito definido como “Entregar plataforma de relatórios financeiros com latência <5 segundos, integrada aos 3 sistemas legados e certificada pelo BACEN, até o mês 8”. Riscos de alto impacto identificados: incompatibilidade de APIs dos sistemas legados, atraso na homologação regulatória e rotatividade da equipe de QA.
- Termo de Abertura: Documento de 6 páginas com abordagem híbrida formalizada (planejamento preditivo por fase + sprints de 3 semanas), marcos regulatórios obrigatórios como milestones inegociáveis, budget de contingência de 15% aprovado explicitamente pelo patrocinador e nomeação do PM com autoridade para contratar recursos adicionais de QA sem aprovação do comitê, até o limite de R$ 80.000.
Resultado: A iniciação formal permitiu que todos os 9 membros da equipe e os clientes-piloto partissem do mesmo entendimento dos objetivos, restrições regulatórias e premissas técnicas. Quando a integração com o ERP legado revelou incompatibilidade de formato de dados na semana 5, o Registro de Premissas já documentava esse risco — e o plano de contingência (uso de middleware de transformação) foi ativado em 48 horas, sem impacto no cronograma geral.
7. Atalhos, Templates e Dicas
Templates recomendados
- Template de Termo de Abertura do Projeto: Use um modelo com seções pré-definidas (propósito, objetivos, premissas, restrições, riscos, cronograma de marcos, orçamento, aprovação). Preencha em no máximo 3-5 páginas.
- Template de Canvas do Projeto: Uma página com blocos visuais para propósito, stakeholders, entregas, premissas, restrições e riscos. Ideal para sessões colaborativas com post-its ou em ferramentas como Miro, Mural ou Canva.
- Template de Registro de Premissas: Planilha com colunas: ID, descrição, origem, impacto, responsável, data de validação, status. Pode ser feito no Excel, Google Sheets ou no próprio sistema de gestão de projetos.
- Template de Matriz RACI: Tabela com atividades nas linhas e papéis nas colunas. Preencha com R (Responsável), A (Aprovador), C (Consultado) e I (Informado).
Ferramentas digitais
- Miro / Mural: Para sessões de Canvas do Projeto colaborativas (presenciais ou remotas)
- MS Project / ProjectLibre: Para documentar o cronograma de marcos do Termo de Abertura
- Confluence / Notion: Para redigir e compartilhar o Termo de Abertura com controle de versão
- ClickUp / Monday.com / Jira: Para registrar premissas como itens rastreáveis com responsável e data
- Google Workspace / Microsoft 365: Para o Registro de Premissas em planilha colaborativa
Dicas avançadas
- Faça a iniciação proporcional ao projeto: Um projeto de R$ 50 milhões com 200 pessoas precisa de um Termo de Abertura robusto. Uma melhoria de processo com 3 pessoas e 2 meses de duração precisa de uma versão simplificada. Tailoring começa aqui.
- Use o Canvas antes do Termo de Abertura: O Canvas é o rascunho visual; o Termo de Abertura é a formalização. Preencher o Canvas primeiro torna a redação do Termo de Abertura mais rápida e mais alinhada.
- Não confunda Termo de Abertura com Plano de Projeto: O Termo autoriza. O Plano detalha. Se seu Termo de Abertura tem cronograma detalhado, EAP e alocação de recursos, ele virou um Plano. Mantenha o foco em alto nível.
- Registre premissas como riscos potenciais: Toda premissa não validada é um risco disfarçado. Ao preencher o Registro de Premissas, pergunte: “E se isso não for verdade?” A resposta pode gerar um risco que precisa de tratamento.
- Marque a data de revisão das premissas: Premissas não são eternas. Defina quando cada premissa será revisada e por quem. Premissas esquecidas se tornam surpresas caras.
8. Erros Comuns e Como Evitá-los
Estes são os 5 erros mais frequentes na aplicação do processo Iniciar Projeto ou Fase — e como evitá-los:
Erro 1 — Iniciar o projeto sem Termo de Abertura formal
Por que acontece: A pressão por velocidade e a cultura de informalidade fazem com que a equipe comece a trabalhar antes de qualquer formalização. “O patrocinador já aprovou verbalmente” é a frase mais perigosa do gerenciamento de projetos.
Como evitar: Estabeleça como regra organizacional que nenhum recurso será alocado e nenhuma atividade será iniciada sem um Termo de Abertura aprovado. Para projetos urgentes, use uma versão simplificada (1 página) que pode ser expandida depois — mas nunca zero páginas. A ausência de um Termo de Abertura é o equivalente a dirigir sem habilitação: pode até funcionar por um tempo, mas quando der problema, não há amparo.
Erro 2 — Termo de Abertura genérico, sem objetivos mensuráveis
Por que acontece: O Business Case é vago, e a equipe reproduz essa vagueza no Termo de Abertura. Objetivos como “melhorar a eficiência” ou “modernizar os processos” são inúteis porque não podem ser medidos nem validados.
Como evitar: Aplique critérios SMART a todo objetivo do Termo de Abertura. Em vez de “melhorar a eficiência operacional”, escreva “reduzir o tempo médio de processamento de pedidos de 48 horas para 12 horas até dezembro de 2027”. Se não for possível quantificar, o objetivo não está maduro o suficiente para entrar no Termo de Abertura — volte ao Business Case e refine.
Erro 3 — Não identificar o gerente de projeto no Termo de Abertura
Por que acontece: A organização define o projeto primeiro e “depois vê quem vai gerenciar”. A definição tardia do gerente de projeto causa problemas de propriedade: ninguém se sente responsável pelo sucesso do projeto até que o GP seja formalmente nomeado.
Como evitar: Inclua a nomeação do gerente de projeto como item obrigatório do Termo de Abertura. Idealmente, o GP deve participar da elaboração do Termo — ele precisa entender o contexto, as premissas e as expectativas antes de assumir. Se o GP for nomeado depois, conduza uma sessão de handover formal com o patrocinador.
Erro 4 — Tratar premissas como fatos confirmados
Por que acontece: A equipe registra premissas no início e nunca mais as revisa. “A equipe estará disponível em maio” é registrada como premissa, mas ninguém verifica em abril. Quando maio chega e a equipe não está disponível, o projeto sofre um atraso que poderia ter sido antecipado.
Como evitar: Para cada premissa, defina um responsável por validá-la e uma data de validação. Inclua a revisão de premissas na pauta das reuniões de status. Trate premissas como hipóteses que precisam ser testadas — não como verdades definitivas. O Registro de Premissas é um documento vivo, não um arquivo morto.
Erro 5 — Preencher o Canvas do Projeto sozinho, sem os stakeholders
Por que acontece: O gerente de projeto preenche o Canvas “para ganhar tempo” e depois apresenta para aprovação. O problema é que o Canvas perde seu maior valor — o alinhamento coletivo. Quando os stakeholders não participam do preenchimento, eles não se sentem donos das premissas e decisões registradas.
Como evitar: O Canvas do Projeto é uma ferramenta de facilitação, não um formulário a ser preenchido individualmente. Conduza uma sessão presencial ou virtual com os stakeholders-chave. Mesmo que leve 90 minutos, essa sessão economiza semanas de desalinhamento futuro. Se for impossível reunir todos, conduza sessões menores com grupos diferentes e consolide.
9. Tailoring: Preditivo, Ágil e Híbrido
O PMBOK 8 enfatiza que todo processo deve ser adaptado ao contexto do projeto. A iniciação formal não é exceção — mas o que muda não é a necessidade de fazer, e sim como fazer.
Ambiente Preditivo (Waterfall)
No contexto preditivo, a iniciação é o processo mais formal e estruturado:
- Termo de Abertura: Documento completo (3-5 páginas), aprovado formalmente pelo patrocinador ou comitê de governança. Inclui cronograma de marcos, orçamento resumido e critérios de sucesso detalhados.
- Registro de Premissas: Documento formal com todas as premissas catalogadas, priorizadas por impacto e com plano de validação.
- Aprovação: Gate review formal antes de avançar para o planejamento. Sem aprovação, o projeto não avança.
- Canvas do Projeto: Usado como ferramenta de alinhamento na reunião de kickoff, complementando (não substituindo) o Termo de Abertura formal.
- Iniciação por fase: Cada fase tem sua própria iniciação, com gate review ao final da fase anterior e autorização formal para a próxima.
Quando usar esta abordagem: Projetos com escopo bem definido, requisitos estáveis, alta necessidade de documentação (regulamentação, compliance, contratos) e ciclo de vida longo.
Ambiente Ágil
No contexto ágil, a iniciação é mais leve e iterativa, mas continua existindo:
- Termo de Abertura: Versão enxuta (1-2 páginas) focada em visão do produto, objetivos de negócio, stakeholders-chave e limites de investimento. Em Scrum, pode ser complementado pelo Product Vision e pelo Product Goal.
- Registro de Premissas: Registrado no backlog como itens de investigação (spikes) ou no definition of ready. Premissas são validadas iterativamente a cada sprint.
- Canvas do Projeto: Ferramenta central. Em ambientes ágeis, o Canvas pode substituir parte do Termo de Abertura formal, especialmente em projetos internos com menor exigência de documentação.
- Aprovação: Menos formal, mas ainda necessária. O Product Owner e o patrocinador validam a visão e os limites antes de iniciar a Sprint 0 ou a fase de Discovery.
- Iniciação contínua: Em projetos ágeis de longa duração, a “re-iniciação” pode acontecer a cada release ou a cada mudança significativa de direcionamento (pivot).
Quando usar esta abordagem: Projetos com requisitos emergentes, alta incerteza, necessidade de feedback rápido e ciclos curtos de entrega.
Ambiente Híbrido
O contexto híbrido combina elementos dos dois modelos:
- Termo de Abertura: Documento formal (2-3 páginas) que define o framework geral do projeto, mas permite que detalhes sejam refinados iterativamente. Define as “guard rails” — limites que não podem ser ultrapassados.
- Registro de Premissas: Formal para premissas de alto nível (orçamento, prazo, regulamentação), iterativo para premissas técnicas e de escopo (validadas sprint a sprint).
- Canvas do Projeto: Usado na sessão de kickoff para alinhar stakeholders, com atualização periódica ao final de cada fase ou release.
- Dupla aprovação: Gate review formal para mudanças de fase (preditivo) + validação iterativa do Product Owner para mudanças de escopo dentro da fase (ágil).
- Iniciação por “onda”: Fases iniciais (análise, design) podem ter iniciação preditiva; fases de desenvolvimento podem ter iniciação ágil com discovery e sprint planning.
Quando usar esta abordagem: Projetos que combinam escopo parcialmente definido com áreas de alta incerteza, organizações em transição para agilidade, ou projetos com múltiplas equipes usando abordagens diferentes.
Resumo comparativo do Tailoring
| Aspecto | Preditivo | Ágil | Híbrido |
|---|---|---|---|
| Termo de Abertura | Completo (3-5 pgs) | Enxuto (1-2 pgs) | Moderado (2-3 pgs) |
| Canvas do Projeto | Complementar | Central | Complementar + atualizado |
| Premissas | Catalogadas formalmente | Validadas por sprint | Formal (alto nível) + iterativo (detalhe) |
| Aprovação | Gate review formal | Validação do PO + sponsor | Gate review + validação iterativa |
| Frequência | Uma vez por fase | Contínua / por release | Por fase + por onda de planejamento |
10. Interações com Outros Processos e Domínios
O processo Iniciar Projeto ou Fase é o ponto de partida de toda a cadeia de processos do PMBOK 8. Praticamente todos os demais processos dependem, direta ou indiretamente, das saídas da iniciação.
Processos que alimentam a iniciação (dependências de entrada)
A iniciação é o primeiro processo formal do projeto, então suas entradas vêm primariamente de fora do projeto:
- Processos organizacionais pré-projeto: Seleção de portfólio, análise de viabilidade, aprovação de Business Case
- Encerramento de fase anterior: Se for uma iniciação de fase, as saídas do processo “Encerrar Projeto ou Fase” da fase anterior alimentam esta iniciação
Processos que dependem da iniciação (dependências de saída)
| Processo que recebe a saída | Domínio | O que recebe |
|---|---|---|
| Integrar e Alinhar os Planos do Projeto (Processo 2) | Governança | Termo de Abertura como base para o Plano de Gerenciamento do Projeto |
| Planejar o Gerenciamento do Escopo | Escopo | Termo de Abertura com requisitos de alto nível e objetivos |
| Planejar o Gerenciamento do Cronograma | Cronograma | Cronograma de marcos e restrições de prazo do Termo de Abertura |
| Planejar o Gerenciamento dos Custos | Finanças | Orçamento resumido e restrições financeiras do Termo de Abertura |
| Identificar Riscos | Riscos | Riscos iniciais do Termo de Abertura + Registro das Premissas |
| Planejar o Gerenciamento dos Recursos | Recursos | Nomeação do GP, Matriz RACI inicial, restrições de recursos |
| Identificar Partes Interessadas | Partes Interessadas | Stakeholders-chave identificados na iniciação |
Interações com os Domínios do PMBOK 8
Governança: A iniciação é o processo fundacional do domínio de governança. Define a estrutura de autoridade, a matriz de responsabilidades e o framework de decisão que sustentarão todos os demais processos de governança — desde a integração dos planos até o encerramento formal.
Escopo: O Termo de Abertura fornece os requisitos de alto nível e os objetivos que servirão de base para o planejamento detalhado do escopo. Sem uma iniciação bem feita, o escopo começa com uma fundação instável.
Cronograma: Os marcos de alto nível e as restrições de prazo definidas na iniciação direcionam todo o planejamento temporal do projeto. Alterações nas premissas de prazo impactam diretamente o cronograma.
Finanças: O orçamento resumido e as restrições financeiras do Termo de Abertura definem o envelope financeiro dentro do qual o projeto deve operar. A iniciação também formaliza a origem dos recursos financeiros.
Riscos: Os riscos iniciais identificados na iniciação alimentam o processo de identificação de riscos. Mais importante: o Registro de Premissas é uma fonte primária de riscos, já que toda premissa não confirmada é um risco potencial.
Recursos: A nomeação do gerente de projeto e a Matriz RACI inicial definem a estrutura de recursos humanos do projeto. A autoridade do GP para alocar recursos é estabelecida na iniciação.
Partes Interessadas: Os stakeholders identificados durante a iniciação são o ponto de partida para o gerenciamento de partes interessadas. O Termo de Abertura documenta quem são os stakeholders de alto impacto e qual sua relação com o projeto.
11. Checklist de Aplicação Rápida
Use estes 7 itens como referência rápida antes de considerar a iniciação concluída:
- O Business Case (ou justificativa equivalente) foi analisado e existe uma razão documentada para o projeto existir?
- O Termo de Abertura do Projeto foi redigido com objetivos mensuráveis (SMART), premissas, restrições e riscos iniciais — e aprovado formalmente pelo patrocinador?
- O gerente de projeto foi nomeado com autoridade clara e documentada para alocar recursos e tomar decisões dentro dos limites definidos?
- As premissas foram registradas no Registro de Premissas com responsável por validação e data prevista para verificação?
- Os stakeholders-chave foram identificados e consultados durante a iniciação — e suas expectativas foram documentadas?
- A Matriz de Responsabilidades (RACI) inicial foi definida, com papéis claros para patrocinador, gerente de projeto, cliente e comitê de governança?
- O Canvas do Projeto foi preenchido colaborativamente com os stakeholders-chave, garantindo alinhamento visual sobre propósito, valor, entregas, premissas e riscos?
Regra prática: Se menos de 5 destes itens foram atendidos, a iniciação não está completa. Investir tempo agora para completá-los evita semanas de retrabalho, desalinhamento e conflitos durante a execução.
12. Faça agora com IA: o Processo 1 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 1 de 40.
O que este processo lê do seu quadro
- a lista Riscos e Premissas
- as respostas do 5W2H (o Termo de Abertura)
O que ele entrega
- Registro das premissas
- Termo de abertura do projeto
Como rodar
- Responda no seu quadro do projeto (ProjectAdm).
- Rode o processo 1 — 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 Iniciar Projeto ou Fase é, por design, o primeiro processo do PMBOK 8 — e essa posição reflete sua importância: sem uma iniciação bem feita, todo o restante do projeto opera sobre uma base frágil.
Os três pontos essenciais para levar para a prática:
- A iniciação formal não é burocracia — é proteção. O Termo de Abertura protege o gerente de projeto, alinha expectativas e documenta as condições sob as quais o projeto foi aprovado. Sem ele, decisões são arbitrárias, responsabilidades são ambíguas e premissas são invisíveis.
- O Canvas do Projeto é a grande novidade do PMBOK 8 para este processo. Ele permite alinhamento visual e rápido entre todos os stakeholders em uma única sessão. Use-o como rascunho colaborativo antes de redigir o Termo de Abertura formal — a qualidade do Termo e o nível de alinhamento serão significativamente superiores.
- Premissas documentadas são riscos gerenciáveis; premissas ignoradas são surpresas caras. O Registro de Premissas não é um formalismo — é um radar que antecipa problemas. Trate cada premissa como uma hipótese que precisa ser testada, e não como um fato consumado.
Próximo passo concreto: Abra o seu projeto atual. O Termo de Abertura existe e está aprovado? Se sim, verifique: os objetivos são SMART? O gerente de projeto está nomeado com autoridade clara? As premissas estão documentadas com responsável e data de validação? Se a resposta for “não” para qualquer uma dessas perguntas, você identificou sua primeira ação de melhoria. Faça agora — antes que a falta de iniciação formal se transforme em um problema real.
Quer aplicar o processo Iniciar Projeto ou Fase nos seus projetos? Comece pelo Checklist de Aplicação Rápida (Seção 11) e avalie quantos dos 7 itens seu projeto atual atende. Se faltar mais de 2, você tem um gap de iniciação que precisa ser resolvido antes de avançar para o planejamento.
Veja todos os artigos do PMBOK 8 no Indice Completo
🇺🇸 Read this article in English
No livro
Iniciar Projeto ou Fase é o Capítulo 2 de PMBOK 8 na Prática — os 40 processos do Guia PMBOK 8 numa ordem escolhida para você aprender aplicando, com 63 modelos, 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 principalmente a importância de uma iniciação bem estruturada, com objetivos claros e alinhamento entre todos os envolvidos. Acredito que definir desde o início o propósito, as responsabilidades e os resultados esperados ajuda a evitar falhas de comunicação, retrabalho e desperdício de recursos, tanto nos projetos quanto nas atividades do dia a dia.
— THAMIRES RIBEIRO · 1 dia atrás
Pretendo seguir com a estrutura completa, conforme orientação do projeto.
— Jaqueline Lima · 3 dias atrás
A aplicação direta desse processo no meu dia a dia como técnico em segurança do trabalho está na formalização e no alinhamento inicial ao implementar novas diretrizes, programas (como PGR/PCMSO) ou mudanças em processos operacionais. Muitas vezes, uma nova norma, um procedimento de segurança ou a implantação de uma ferramenta de controle é lançada sem um alinhamento prévio claro com os setores envolvidos (produção, manutenção, diretoria). O resultado prático disso é o que o artigo aponta: cada área interpreta a exigência de um jeito, o chão de fábrica vê a medida como burocracia desnecessária e o projeto nasce fragmentado. Utilizar os conceitos de iniciação formal e engajamento inicial de partes interessadas permite: Definir claramente o propósito e os limites: Deixar evidente para a operação e para a liderança o porquê daquela ação de segurança e quais são os resultados esperados, evitando resistência logo na largada. Mapear os atores certos desde o início: Garantir que os encarregados, a CIPA e a gestão participem da concepção da medida, garantindo que o plano faça sentido prático para quem está na ponta. Garantir autoridade e patrocínio: Ter o respaldo formal da gerência para exigir o cumprimento das diretrizes de segurança, blindando o técnico contra a percepção de que a segurança é "opcional" ou responsabilidade exclusiva de um único setor.
— ROBSON PEIXOTO · 1 semana atrás
Pretendo seguir a estrutura conforme orientação do artigo. Excelente material.
— Williams Barros · 2 semanas atrás
Vou definir claramente as metas do projeto.
— Jorge Luiz de Freitas Vilela · 3 semanas atrás

Continue no livro
PMBOK 8 na Prática
Os 40 processos do Guia PMBOK 8 aplicados num projeto real, com o artefato pronto em cada passo.
Ver o livro — R$ 31,99 →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.

Uma Iniciação bem estruturada permite identificar riscos, oportunidades e restrições desde o início, facilitando a tomada de decisões e reduzindo a probabilidade de falhas durante a execução, por este e varios outros motivos que é importante com que todos os projetos respeitem essa fase pois, também assegura que os recursos sejam alocados de forma adequada e que o projeto esteja alinhado às estratégias e prioridades da organização.
Excelente abordagem
Será que existe diferença nos termos de abertura olhando os modelos de gestão de projectos?
Qual é a abordagem de desenvolvimento você usa?
No framework Scrum, por exemplo, o Termo de abertura nem é citado.
Na verdade o pensamento é todos modelos exigem termo de abertura mas se o caso não é esse então vou aprofundar onconhecimento