Passo 1: Iniciar o projeto

Todo projeto começa com uma decisão: vale a pena investir tempo, dinheiro e energia nisso? O Passo 1 existe para responder essa pergunta com clareza — e, se a resposta for sim, deixar o projeto autorizado para seguir adiante. É aqui que você faz um levantamento inicial, olhando o projeto inteiro de cima, sem ainda mergulhar nos detalhes.

Para a sua carreira: aprender a iniciar bem um projeto — justificar, definir objetivos claros e alinhar as partes interessadas — é uma das competências mais valorizadas do mercado, vale para o projeto da empresa e vale para o seu projeto de vida ou de transição de carreira.

A ferramenta deste passo: 5W2H

Para organizar o levantamento inicial, usamos o 5W2H — um roteiro de perguntas simples e poderoso, que transforma uma ideia solta em um plano claro. Não é uma invenção nossa: o Guia PMBOK® 8ª edição diz que um termo de abertura, mesmo o mais enxuto, “responde a um subconjunto ou a todas estas perguntas: por quê, quem, o quê, onde, quando, como”.

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

Cada pergunta responde a uma parte essencial do projeto — e cada uma tem um cartão no seu quadro:

Nas próximas seções percorremos cada pergunta; ao responder o 5W2H você já está montando seu projeto.

O quadro é montado em duas etapas — e a segunda depende de você

Ao abrir o quadro, você vai notar que tudo a partir do bloco COMO nasce trancado 🔒 — os cartões 4.1 a 4.6 (o onde é parte do como), o 5 (QUANDO) e o 6 (QUANTO). Isso é de propósito.

O “Como?” do 5W2H é a abordagem de desenvolvimento — e é ela que define a forma do resto do seu quadro: muda como o seu trabalho é decomposto e mudam até os nomes das listas. Você vai conhecer os dois formatos daqui a pouco, na seção Como? — não precisa saber nada sobre eles ainda. A ordem do curso é a ordem certa de pensar, e ela tem duas metades:

• a abordagem se escolhe a partir das características da entrega, do projeto e da organização — ou seja, depois de você responder por quê, o quê e quem. Escolher antes seria chute;
• e o quando, o quanto e o onde se calculam a partir dela. “Quando fica pronto?” é uma pergunta diferente se a resposta é um marco (uma data com significado no projeto, como o fim de uma fase) ou o fim de um ciclo curto de entrega; “quanto custa?” é diferente se o custo é o do projeto inteiro ou o do time por Sprint. Perguntar antes é pedir um número sem saber o que ele significa.

Então funciona assim:

1. Etapa 1 (agora): você responde os cartões 1.1 a 3 (por quê · o quê · quem), lendo este artigo.
2. A decisão: quando chegar na seção “Como?”, você escolhe a abordagem.
3. Etapa 2: você roda o Passo 1 de novo — ele destranca o resto do termo (o COMO, o ONDE, o QUANDO e o QUANTO) e monta o resto do quadro na sua abordagem.

Why — Por quê? A justificativa e os objetivos

Esta é a primeira pergunta, e a mais importante: por que o projeto é necessário? Ela se divide em duas.

Qual é a sua justificativa?

Qual situação atual motivou o projeto? A justificativa quase sempre nasce de uma dor — algo que incomoda hoje e que o projeto vem transformar em algo melhor. Não busque a justificativa perfeita: este é um processo interativo, que você refina à medida que evolui.

Quais objetivos o projeto deve atender? Use OKR

Objetivos subjetivos geram dupla interpretação, conflito e retrabalho. Para dar clareza, use OKR (Objectives and Key Results): o Objetivo diz, de forma direcionadora, onde você quer chegar; os Resultados-chave dizem como você saberá que chegou — de 2 a 5 por objetivo, cada um com indicador e meta.

Quantos objetivos? Os que o projeto pedir — a maioria tem mais de um. Numere os Resultados-chave por objetivo (KR 1.1, KR 1.2, KR 2.1…): é por esse número que, no próximo tópico, cada entrega vai dizer a qual Resultado-chave ela serve. Assim nenhum Resultado-chave fica sem entrega que o alcance — e nenhuma entrega fica sem um porquê.

Teste a qualidade de cada Resultado-chave. Neste passo, um bom Resultado-chave é:

• Específico
• Mensurável (tem indicador e meta)
• Realista

Sempre que der, escreva a meta como “de X para Y” — do ponto de partida (o X: a situação de hoje, aquela mesma insatisfação que você descreveu na justificativa) até o alvo (o Y: aonde você quer chegar). Ela carrega mais informação que uma variação percentual: “reduzir o churn de 3,2% para 2,7%” diz mais do que “reduzir o churn em 15%”. Esse ponto de partida é recomendado, não obrigatório: quando é a primeira vez que você faz algo, não existe ponto de partida — aí escreva só o alvo (“chegar a Y”).

Um exemplo de como sair do subjetivo: em vez de “o projeto deve satisfazer os clientes”, escreva “nível de satisfação geral do cliente maior que 80%, medido por pesquisa respondida ao fim do projeto”.

What — O quê? Produtos e requisitos

Para atingir cada objetivo, defina as entregas (produtos, serviços ou resultados) necessárias e, para cada entrega, seus requisitos. Requisito é uma condição a ser atendida para satisfazer uma necessidade — pode ser obrigatório ou desejado.

Uma boa entrega é um resultado (um substantivo), não uma atividade: “Política de compras publicada”, não “escrever a política”.

Vale distinguir alguns parentes próximos do requisito, porque são conceitos que voltam o projeto todo:

Who — Quem? As partes interessadas

Conhecer as expectativas de quem cerca o projeto é decisivo. Quando houver conflito de interesses, seu papel é equilibrá-los para minimizar resistências e atrasos. Organize as partes interessadas em três grupos:

• Clientes — quem vai usufruir dos produtos e resultados. O projeto existe para atendê-los.
• Equipe — quem produz alguma entrega (seja funcionário ou não).
• Demais partes interessadas — pessoas, organizações e fatores externos que podem impactar o projeto.

Dê atenção especial às partes interessadas mais críticas: quem tem poder sobre recursos, escopo (veto), orçamento (aprova aumento/redução) e pessoas — em especial o patrocinador, quem autoriza e banca o projeto. Se você não sabe quem é o patrocinador, você ainda não tem um projeto autorizado.

Um cuidado especial ao montar a equipe

Ao listar a equipe, force a memória e procure lembrar de todas as pessoas que vão executar alguma atividade no projeto — não só o núcleo principal, mas também quem participa por pouco tempo, quem entra de outra área ou de um fornecedor. Nomeie cada uma pela pessoa ou função real que entrega (“Ana — edição de vídeo”), e não por um grupo vago (“time de marketing”): é a essas pessoas que as tarefas do projeto serão atribuídas mais adiante.

Não se cobre lembrar de todos agora. A equipe cresce com o projeto: sempre que você se lembrar de mais alguém, ou que surgir uma nova necessidade, volte a este cartão e acrescente o novo membro — isso é natural e esperado.

E, sempre que possível, cada membro da equipe deve ter um usuário no ProjectAdm (ou na ferramenta que você usar para gerir as tarefas). É esse usuário que permite à pessoa receber as notificações das suas tarefas e marcá-las como concluídas conforme as realiza. Sem um usuário associado, ninguém é avisado do que precisa fazer — e o projeto perde o controle mais básico: saber quem faz o quê.

O Passo 1 faz essa ligação por você. Quando ele encontra um membro da equipe que já é usuário do seu projeto no ProjectAdm, ele liga os dois: a partir daí, as tarefas dessa pessoa são atribuídas à conta dela (Passos 4 e 7), e os e-mails que o Passo 7 prepara vão para o endereço daquela conta — mantido pela própria pessoa, nunca digitado por você. Quando o casamento não é óbvio, ele pergunta em vez de adivinhar: mandar a lista de tarefas de alguém para a pessoa errada é pior do que não mandar. E não ser usuário do ProjectAdm está tudo bem — você informa o e-mail, e o curso o registra no cartão daquela pessoa.

How — Como? A abordagem de desenvolvimento

Chegamos à decisão que muda todo o resto — e é por isso que ela vem depois de você já saber por quê, o quê e quem, e antes de dizer quando, quanto e onde.

O “Como?” do 5W2H começa pela abordagem de desenvolvimento: “o meio usado para criar e evoluir um produto, serviço ou resultado durante o ciclo de vida do projeto” (Guia PMBOK® 8ª edição). Ela não é o gosto do gerente nem a moda do mercado: é uma decisão tomada a partir dos fatores do projeto que você tem na mão. E ela vive num espectro:

• Preditiva — o escopo é conhecido e estável o bastante para planejar antes de executar. Define-se o escopo e decompõe-se ele numa EAP — a Estrutura Analítica do Projeto, que quebra a entrega em pedaços cada vez menores até chegar a pacotes de trabalho que dá para estimar e atribuir a alguém. Com a EAP na mão estima-se prazo e custo e aprova-se uma linha de base (baseline): a foto do escopo, do prazo e do custo aprovados, contra a qual toda mudança futura vai ser comparada. Mudar depois é caro: por isso se planeja antes.
• Ágil — os requisitos ainda não estão claros e o feedback frequente vale mais do que a previsibilidade. Estabelece-se uma Visão do Produto, os requisitos conhecidos viram um Product Backlog — a lista única do que falta fazer, sempre em ordem de prioridade, de onde o time puxa o próximo trabalho — e entrega-se em Sprints: ciclos curtos de duração fixa (uma a quatro semanas) em que o time constrói um Incremento, ou seja, um pedaço do produto pronto para usar de verdade, não uma etapa interna. Faz, mostra, aprende, reprioriza. Não confunda a Visão do Produto com a Meta do Produto: a visão é o horizonte — para onde o produto aponta, sem prazo; a Meta do Produto é o estado concreto que, atingido, permite encerrar este projeto, e ela nasce no Passo 2, junto com o backlog. (O Guia PMBOK® chama essa família de adaptativa — o Scrum é o método mais usado dela.)

Existe também a abordagem híbrida, que combina as duas — mas ela não é um terceiro caminho que se escolhe no começo: ela nasce na prática, quando você conduz uma abordagem e toma emprestado o que funciona da outra.

Como escolher — os 5 eixos que decidem

O Guia não manda escolher no feeling: a seção 4.3 lista as variáveis a considerar, em três categorias (a entrega, o projeto e a organização). São muitas — e várias dizem a mesma coisa com nomes diferentes. Destiladas, sobram cinco eixos, e é neles que a decisão realmente muda:

A regra de bolso do próprio Guia resume tudo: requisitos claros e estáveis desde o início → preditiva; requisitos incertos e feedback frequente valioso → ágil.

O resto do “Como”: restrições, premissas e riscos

Com a abordagem escolhida, o bloco COMO se completa — e repare que estes três conceitos mudam de forma conforme a sua escolha:

• 4.2 Restrições — os limites impostos de fora (prazo, orçamento, norma, contrato). Restrição não se negocia dentro do projeto: se contorna ou se aceita. No ágil, a restrição típica é a data: ela é fixa, e é o escopo que flutua para caber.
• 4.3 Premissas — o que você assume como verdade sem ter certeza (“o fornecedor entrega em 30 dias”). Toda premissa que cai vira um risco. No ágil, a premissa vira hipótese — e a Sprint 1 existe para testá-la.
• 4.4 Riscos iniciais — os riscos de alto nível que você já enxerga na largada, escritos como causa → evento → impacto. “Atraso” não é risco: é o impacto. No ágil, o risco não mora num documento paralelo: ele entra no backlog — a incerteza de conhecimento vira um spike — um item do backlog cujo resultado não é entrega, e sim resposta: uma investigação de tempo limitado, feita para descobrir algo que ninguém sabe ainda. Você aprofunda no Passo 3.
• 4.5 Escopo inicial — a primeira decomposição das suas entregas: a EAP (decomposição em pacotes de trabalho, numerada por níveis — o pacote tem custo, duração e critério de aceitação) ou o Product Backlog inicial (itens de valor em ordem de prioridade, escritos como histórias de usuário: como [usuário], quero [necessidade], para [benefício]). Aqui é visão inicial — você abre no Passo 2.

E o “onde”? Ele é parte do “como”

Onde o trabalho acontece e até onde ele vai: qual área, unidade, sistema, região, público — presencial ou remoto. E, principalmente: o que fica de fora.

O onde vem aqui, no fim do “Como?”, por um motivo: ele depende da maneira de conduzir o projeto. Um time que entrega em incrementos curtos e senta com o usuário real trabalha em um “onde” diferente de um que entrega tudo no fim. Por isso ele é parte do como — e não uma pergunta solta lá atrás.

É também a menos decisiva das sete perguntas. Se você ainda não sabe onde, deixe o cartão em branco e decida no momento certo — é uma resposta legítima, e melhor do que inventar um limite que você vai ter de desdizer depois. O que vale mesmo aqui é o que fica de fora: custa uma linha agora e economiza semanas de discussão adiante.

When e How much — Quando e Quanto (visão preliminar)

Na Iniciação você faz apenas uma estimativa preliminar de prazos e custos — o suficiente para decidir pela viabilidade. Coloque marcos só nas entregas mais fáceis de estimar, em prazo relativo se preferir (“Semana 4”, “Mês 2”), e não se preocupe com o resto: o detalhamento vem no Passo 4 — Cronograma e orçamento.

No custo, dê a ordem de grandeza com a base do cálculo e a margem: “R$ 20 a 30 mil — 2 pessoas × 3 meses; margem -25%/+50%”. Dizer “ainda não sei, e esta é a base do meu chute” é honesto. Fingir precisão é o que quebra a confiança lá na frente.

Fatores críticos de sucesso

• Definir com clareza o objetivo e a abrangência do projeto;
• Identificar as partes interessadas e definir estratégias para ganhar suporte ou reduzir obstáculos;
• Identificar a data de início e as principais dependências;
• Reconhecer, no ambiente externo, oportunidades e ameaças;
• Avaliar as premissas e os riscos envolvidos;
• Decidir, ao final, pela viabilidade e pela continuidade do projeto.

🎯 Sua vez de participar — Iniciar o projeto

Objetivo: autorizar o início do projeto e registrar, de forma enxuta, por que ele existe, o que entrega, quem participa, como será conduzido (e onde), quando e quanto custa.

O seu roteiro (é o mesmo deste artigo):

1. Abra o quadro — menu do curso → Passo 1 — Iniciar o projeto. Ele pergunta o nome do projeto e cria a lista INPUTS com as 7 perguntas.
2. Responda os cartões 1.1 a 3 — lendo cada seção deste artigo. Escreva você; use os prompts 1 a 3 para acelerar.
3. Escolha a abordagem — menu → Passo 1 · COMO (5 perguntas). O script recomenda; você decide.
4. Rode o Passo 1 de novo — ele destranca o resto do termo e monta o resto do seu quadro na sua abordagem.
5. Complete os cartões 4.2 a 4.6, 5 e 6 — restrições, premissas, riscos iniciais, escopo inicial, o onde e, por fim, o quando e o quanto (prompts 5 e 6).

🎁 Sua entrega: o Termo de Abertura completo, montado nos cartões do seu quadro — e o quadro pronto para o Passo 2.
⏱️ Tempo sugerido: cerca de 2 horas para o levantamento inicial — cuidado para não entrar no detalhe agora.
🛠️ Ferramentas: ProjectAdm + 5W2H + OKR + a sua IA.

💬 Lembre-se: este é um processo interativo. À medida que você evolui, vai querer atualizar seções anteriores — isso é saudável e mostra que você está se aprofundando. Pode voltar e reescrever qualquer cartão: rodar o Passo 1 de novo nunca apaga o que você escreveu. O importante é começar e não parar, seguindo passo a passo até o Passo 10.

Autorizado o projeto, o próximo passo é detalhar o que está — e o que não está — dentro dele. Vamos ao Passo 2: Revisar o escopo.

🎁 O seu artefato — o Termo de Abertura em Word, gerado do seu quadro

Ao concluir o Passo 1, o Project Together lê o seu quadro e gera para você o Termo de Abertura do Projeto (arquivo Word .docx, no modelo 5W2H do curso), salvo na pasta _saida/documentos/. Você não copia nada: o quadro é a fonte, o documento é o resultado — pronto para compartilhar com o patrocinador e as partes interessadas.

Como conferir:

1. Abra a pasta _saida/documentos/ (dentro da pasta do curso) e abra o arquivo Termo de Abertura – (nome do seu projeto).docx no Word.
2. Confira se cada seção — Por quê (justificativa e OKR), O quê (entregas), Quem, Como (abordagem, restrições, premissas), Quando e Quanto — reflete o que você escreveu nos cartões. O cabeçalho traz o nome do seu projeto.
3. Quer atualizar? Ajuste os cartões no quadro e gere de novo pela tecla D no menu do curso (Gerar os meus documentos) — o documento é sempre um retrato fiel do quadro.

🧭 Como usar os 10 passos — uma ordem para aprender, um repertório para usar

Você aprende os passos em sequência (1 → 10) porque é assim que se entende a lógica de um projeto pela primeira vez. Mas um projeto real não anda em linha reta.

O Passo 1 (Iniciar) vem sempre primeiro — não dá para monitorar, mudar ou executar o que ainda não foi autorizado. Depois dele, você roda os passos na ordem que o projeto pedir, em sequência ou em paralelo. E vários você repete muitas vezes:

• Passo 8 (Monitorar e Status Report) — rode sempre que precisar comunicar o andamento às partes interessadas ou checar a saúde do projeto. Não é um evento no fim: é contínuo.
• Passo 9 (Controlar mudanças) — rode sempre que chegar um pedido de mudança, a qualquer momento.
• Passos 6 e 7 (Engajar e Executar) — acontecem ao longo de todo o projeto.

É por isso que os 10 passos entram no cronograma do seu projeto: são tarefas recorrentes do responsável, não uma lista que se percorre uma única vez. O Guia PMBOK® 8ª edição diz que os domínios de desempenho — os grupos de atividades que o Guia usa para organizar o trabalho de um projeto — correm simultaneamente ao longo de todo o ciclo de vida do projeto — eles se sobrepõem e se interconectam, em vez de acontecerem em silos —, de modo que monitorar e controlar mudanças ocorrem do início ao fim, não numa etapa isolada.

💡 Dica: a qualquer momento, rode Verificar o meu projeto (tecla P no menu do curso). Ele lê o seu quadro e diz por onde você anda nos 10 passos, se o seu plano ainda alcança o que você prometeu e o que fazer a seguir.

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.