Artigo atualizado em março/2026 para o PMBOK® Guide — Eighth Edition.
Cadastre-se para navegar sem anúncios e participar do Project Together →
Estimar Recursos: Como Determinar o Tipo e a Quantidade de Recursos que Cada Atividade Exige (PMBOK 8)
Anteriormente: Estimar os Recursos das Atividades (PMBOK 6)
Imagine este cenário: o cronograma diz que a atividade “migrar banco de dados” leva 5 dias. Mas ninguém especificou se são 5 dias com 1 DBA sênior ou 5 dias com 2 DBAs juniores. A equipe assume que terá um DBA sênior disponível. Quando a atividade começa, o único DBA sênior está alocado em outro projeto, e os dois juniores disponíveis não têm experiência com a tecnologia legada. A atividade que deveria levar 5 dias se arrasta por 18. Esse cenário é o resultado previsível de estimar durações sem estimar recursos.
No PMBOK 8, o processo Estimar Recursos é o Processo 31 (código 2.6.2.2) do Domínio de Recursos. Ele determina os tipos e as quantidades de materiais, pessoas, equipamentos e suprimentos necessários para executar cada atividade do projeto. É o processo que transforma o cronograma de “lista de atividades” em “lista de atividades com os recursos que as viabilizam”.
Neste guia completo você vai encontrar:
- O que é o processo Estimar Recursos 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 (Horizonte Transportes) e Projeto ProjectAdm (SaaS)
- Atalhos, templates e dicas para acelerar a estimativa
- 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 Estimar Recursos
Estimar Recursos é o processo de determinar os recursos da equipe e os recursos físicos — tipos, quantidades e características — necessários para executar o trabalho do projeto. Ele conecta o “o que fazer” (escopo) com o “com o quê fazer” (recursos), viabilizando estimativas de custo e cronograma realistas.
No PMBOK 8, este é o Processo 31 (código 2.6.2.2), o segundo do Domínio de Recursos. No PMBOK 6, era chamado “Estimar os Recursos das Atividades” — o PMBOK 8 simplificou o nome, mas a essência permanece: cada atividade precisa de recursos definidos para ser executada.
O processo produz três saídas:
- Requisitos de Recursos (Resource Requirements) — a documentação detalhada dos tipos e quantidades de recursos necessários para cada atividade ou pacote de trabalho
- Estrutura Analítica dos Recursos (EAR / Resource Breakdown Structure) — uma representação hierárquica dos recursos por categoria e tipo, similar à EAP mas para recursos
- Atualizações de documentos do projeto — ajustes na lista de atividades, no registro de premissas e no calendário de recursos com base nas estimativas
Diferença entre Estimar Recursos e Estimar Durações
Estes dois processos são interdependentes, mas distintos:
| Aspecto | Estimar Recursos | Estimar Durações |
|---|---|---|
| Pergunta que responde | “O que é necessário para executar esta atividade?” | “Quanto tempo esta atividade levará?” |
| Resultado | Tipos, quantidades e características de recursos | Períodos de trabalho necessários |
| Domínio | Recursos | Cronograma |
| Relação causal | Define os recursos que influenciam a duração | Usa a estimativa de recursos como entrada |
A estimativa de duração depende da estimativa de recursos: uma atividade com 2 desenvolvedores seniores pode levar 5 dias; a mesma atividade com 1 desenvolvedor júnior pode levar 15 dias. Estimar durações sem antes estimar recursos é como calcular o tempo de viagem sem saber se você vai de avião ou de bicicleta.
2. Por que Usar o Processo Estimar Recursos
A estimativa de recursos é o elo entre o planejamento de escopo e as estimativas de custo e prazo. Sem ela, cronogramas e orçamentos são construídos sobre suposições.
Benefícios diretos
- Estimativas de custo realistas: O custo do projeto é, em grande parte, o custo dos recursos. Sem saber quantas pessoas, que equipamentos e quais materiais são necessários, as estimativas de custo são ficção.
- Cronograma viável: A duração de uma atividade depende dos recursos alocados. A estimativa de recursos permite calcular durações realistas e identificar restrições de calendário.
- Base para aquisição: Para adquirir recursos (Processo 32), é preciso saber primeiro o que adquirir. A estimativa de recursos gera os requisitos que orientam a aquisição.
- Identificação de gargalos: Ao estimar recursos por atividade, padrões emergem: o mesmo DBA sênior é necessário em 12 atividades diferentes no mesmo período. Esse gargalo só é visível com estimativa detalhada.
- Otimização do uso de recursos: Com requisitos documentados, é possível nivelar recursos (resource leveling), agrupar atividades que usam o mesmo recurso e minimizar ociosidade.
- Documentação para lições aprendidas: Comparar recursos estimados com recursos reais gera dados para melhorar estimativas futuras.
O que acontece quando o processo é ignorado
- Cronograma irreal: Atividades são estimadas com durações genéricas, sem considerar a produtividade real dos recursos disponíveis. O cronograma “parece” viável mas não sobrevive ao primeiro contato com a realidade.
- Orçamento subestimado: Sem saber quantos recursos são necessários, o orçamento é baseado em “achismo”. Quando os custos reais aparecem, o orçamento estoura.
- Conflitos de alocação invisíveis: O mesmo recurso é alocado em múltiplas atividades simultâneas sem que ninguém perceba até a execução.
- Aquisições tardias: Sem requisitos de recursos documentados, a aquisição começa tarde demais, gerando atrasos por falta de pessoal ou materiais.
- Qualidade comprometida: Atividades que exigem especialistas são executadas por generalistas porque ninguém especificou o nível de competência necessário.
3. Entradas, Ferramentas e Técnicas, e Saídas (ITTO)
A tabela abaixo apresenta o ITTO completo do processo Estimar Recursos, conforme o PMBOK 8:
| Entradas | Ferramentas e Técnicas | Saídas |
|---|---|---|
|
|
|
Detalhamento das Entradas
Plano de Gerenciamento do Projeto: O plano de recursos fornece o framework de categorias e papéis. A linha de base do escopo (EAP + dicionário) define os pacotes de trabalho que precisam de recursos.
Documentos do projeto: A lista de atividades identifica o que precisa de recursos. Os atributos das atividades detalham requisitos específicos (ex: “requer certificação AWS”). O calendário de recursos mostra quando os recursos existentes estão disponíveis. O registro de riscos alerta sobre riscos que podem afetar a disponibilidade.
Fatores ambientais da empresa (EEFs): Localização e disponibilidade de recursos na organização e no mercado, custos de mercado para recursos especializados, condições do mercado de trabalho e cultura organizacional sobre compartilhamento de recursos.
Ativos de processos organizacionais (OPAs): Políticas de contratação e aquisição, dados históricos de projetos similares (quantos recursos usaram, que tipos), banco de dados de competências interno, métricas de produtividade organizacional.
Detalhamento das Ferramentas e Técnicas
Opinião especializada: Consulta a pessoas com experiência em estimar recursos para atividades similares. Gerentes funcionais, líderes técnicos e consultores externos podem fornecer estimativas baseadas em experiência direta.
Estimativa análoga: Usa dados de projetos anteriores similares como base. Se o projeto anterior precisou de 3 desenvolvedores para uma funcionalidade equivalente, usa-se esse dado como referência. É rápida e barata, mas menos precisa — funciona melhor quando os projetos são genuinamente comparáveis.
Estimativa paramétrica: Usa relações estatísticas entre dados históricos e variáveis do projeto. Exemplo: “cada tela de interface exige 16 horas-homem de desenvolvimento” — multiplicado pelo número de telas, gera a estimativa total. É mais precisa que a análoga quando os parâmetros são confiáveis.
Estimativa bottom-up: Decompõe cada atividade em componentes menores e estima os recursos para cada componente, depois agrega. É a técnica mais precisa, mas também a mais demorada. Ideal para atividades complexas ou de alto risco onde a precisão justifica o investimento.
Análise de dados (análise de alternativas): Compara diferentes opções de recursos para a mesma atividade. Exemplo: contratar um especialista externo por R$ 800/hora por 2 dias vs. treinar um funcionário interno por 2 semanas. A análise considera custo, prazo, qualidade e risco de cada alternativa.
Sistema de Informação de Gerenciamento de Projetos (SIGP): Ferramentas de software que auxiliam na estimativa, alocação e nivelamento de recursos. Inclui módulos de resource planning em ferramentas como MS Project, Primavera, Jira e similares.
Reuniões: Sessões de estimativa com a equipe do projeto e especialistas. Técnicas como Planning Poker (em contextos ágeis) podem ser adaptadas para estimar recursos além de esforço.
Detalhamento das Saídas
Requisitos de Recursos: Documentação detalhada dos tipos e quantidades de recursos por atividade ou pacote de trabalho. Exemplo: “Atividade 3.2.1 — Migrar banco de dados: 1 DBA sênior (experiência em Oracle + PostgreSQL), 1 servidor de staging (16GB RAM, 500GB SSD), licença de ferramenta de migração (AWS DMS). Duração estimada: 5 dias.”
Estrutura Analítica dos Recursos (EAR): Representação hierárquica dos recursos organizados por categoria. Exemplo: Nível 1 — Pessoas, Equipamentos, Materiais. Nível 2 — Pessoas > Desenvolvimento, QA, Gestão. Nível 3 — Desenvolvimento > Frontend, Backend, DBA. A EAR facilita a consolidação e o controle de recursos por categoria.
Atualizações de documentos do projeto: A lista de atividades pode ser atualizada com informações de recursos. O registro de premissas pode incluir novas premissas sobre disponibilidade. O calendário de recursos é ajustado com base nas estimativas.
4. Como Aplicar o Processo Passo a Passo
Passo 1 — Revise a EAP e a lista de atividades
Para cada pacote de trabalho ou atividade, pergunte: “Que tipo de recurso é necessário para executar isso?” Classifique em categorias: pessoas (por competência), equipamentos, materiais, infraestrutura, licenças.
Passo 2 — Escolha a técnica de estimativa adequada
Para cada atividade, selecione a técnica mais apropriada:
- Atividades bem conhecidas e repetitivas: Estimativa análoga ou paramétrica
- Atividades complexas ou de alto risco: Estimativa bottom-up
- Atividades com múltiplas alternativas: Análise de alternativas primeiro, depois estimativa detalhada da alternativa escolhida
- Atividades sem referência histórica: Opinião especializada + estimativa bottom-up
Passo 3 — Estime recursos por atividade
Para cada atividade, documente:
- Tipo de recurso (papel/competência para pessoas; especificação para físicos)
- Quantidade necessária
- Período de necessidade (quando e por quanto tempo)
- Nível de competência ou especificação técnica mínima
- Premissas da estimativa
Passo 4 — Monte a Estrutura Analítica dos Recursos (EAR)
Organize todos os recursos estimados em uma hierarquia por categoria. Isso permite visualizar a demanda total por tipo de recurso e identificar concentrações ou gargalos.
Passo 5 — Identifique conflitos e gargalos
Com os requisitos consolidados, analise: algum recurso está super-alocado (demandado por mais atividades do que sua disponibilidade permite)? Alguma competência é necessária mas não existe na organização? Algum material tem lead time que conflita com o cronograma?
Passo 6 — Valide com especialistas e gerentes funcionais
Apresente as estimativas para líderes técnicos e gerentes funcionais. Eles podem identificar premissas irrealistas, sugerir alternativas e confirmar disponibilidade.
Passo 7 — Documente e integre
Formalize os requisitos de recursos, a EAR e as premissas. Integre com o cronograma (para alimentar as estimativas de duração) e com o orçamento (para alimentar as estimativas de custo).
5. Quando Aplicar o Processo
Cenários obrigatórios
- Durante o planejamento inicial: As estimativas de recursos são entrada obrigatória para estimativas de duração e custo. Sem elas, cronograma e orçamento são ficção.
- Antes da aquisição de recursos: Para adquirir recursos (Processo 32), é preciso saber o que adquirir — e isso vem deste processo.
- Quando novas atividades são adicionadas: Mudanças de escopo geram novas atividades que precisam de estimativas de recursos.
Cenários recomendados
- Re-estimativa após mudanças significativas: Se a tecnologia, a abordagem ou a equipe mudam substancialmente, as estimativas de recursos devem ser refeitas.
- Planejamento em ondas (rolling wave): Atividades do futuro próximo são estimadas em detalhe; atividades distantes são estimadas em alto nível e refinadas conforme se aproximam.
- Análise de viabilidade: Antes de comprometer-se com um escopo, estimar recursos ajuda a avaliar se o projeto é viável com os recursos disponíveis.
Gatilhos
- O cronograma está sendo montado sem informações sobre recursos por atividade
- As estimativas de custo estão genéricas (“vai custar mais ou menos R$ 200.000”)
- Atividades críticas não têm recursos específicos designados
- A equipe não sabe se tem capacidade para executar o escopo planejado
- Recursos físicos não têm especificações definidas
6. Exemplos Práticos por Setor
Exemplo 1 — Implantação do PMO: Projeto Horizonte
Contexto: Ana Silveira (GP) precisa estimar os recursos para as 47 atividades do Projeto Horizonte na Horizonte Transportes. O plano de recursos já define os papéis; agora é preciso quantificar para cada atividade.
Como o processo foi aplicado:
- Técnica escolhida: Ana usou uma combinação de estimativa análoga (baseada em implantações de PMO realizadas por Carolina Mendes em projetos anteriores) e bottom-up (para atividades específicas da Horizonte Transportes, como treinamento de 40 colaboradores e customização do ProjectAdm para o setor de transportes). Carolina forneceu dados de 3 implantações anteriores em empresas de porte similar.
- Estimativa por atividade: Para a atividade “Mapear processos atuais de gerenciamento de projetos”, Ana estimou: 1 consultora sênior (Carolina Mendes, 3 dias), 1 analista do PMO (Diego Carvalho, 5 dias), sala de reunião com projetor (5 meios-períodos), flipchart e post-its (material). Para “Customizar dashboards do ProjectAdm”, estimou: 1 consultora (Carolina, 8 dias), 1 analista de TI (2 dias), licença admin do ProjectAdm (já adquirida), ambiente de homologação (servidor de staging).
- EAR construída: A EAR do Projeto Horizonte tinha 3 níveis: Nível 1 — Pessoas, Equipamentos, Materiais, Serviços. Nível 2 — Pessoas > Equipe Interna, Consultoria Externa. Nível 3 — Equipe Interna > Analistas PMO (3), TI (2), RH (1 part-time). A EAR revelou que Carolina Mendes era necessária em 23 das 47 atividades — um gargalo que levou Ana a replanejar o sequenciamento para não sobrecarregar a consultora.
- Validação: Ana apresentou as estimativas para Roberto Campos (CEO) e Marcos Tanaka (Operações). Marcos alertou que os analistas de TI tinham manutenção programada do sistema de rastreamento de frotas no mês 3 — uma restrição que não estava no calendário de recursos e que foi incorporada imediatamente.
Resultado: As estimativas de recursos permitiram que Ana calculasse durações realistas e identificasse que o mês 3 era um gargalo (TI indisponível + pico de atividades de Carolina). A solução foi antecipar atividades que dependiam de TI para o mês 2 e redistribuir atividades de consultoria entre os meses 2 e 4. Sem a estimativa detalhada de recursos, o conflito só seria descoberto durante a execução.
Exemplo 2 — Desenvolvimento de Software: Projeto ProjectAdm
Contexto: Eduardo Montes (GP) precisa estimar recursos para os 12 épicos do backlog do Projeto ProjectAdm. A equipe é enxuta (5 pessoas) e trabalha em sprints de 2 semanas.
Como o processo foi aplicado:
- Técnica escolhida: Eduardo usou estimativa paramétrica com base na velocidade histórica da equipe. Nos 3 primeiros sprints (rodados como piloto), a equipe entregava em média 34 story points por sprint. Eduardo usou esse parâmetro para estimar recursos por épico: cada story point requeria, em média, 4 horas de desenvolvimento (backend ou frontend) + 1 hora de QA + 0,5 hora de design.
- Estimativa por épico: O épico “Módulo de Gestão de Riscos” (estimado em 89 story points) exigia: Marcus Webb (backend, 178 horas), Julia Chen (frontend, 178 horas), Bruno Silva (design, 44,5 horas), Henry Douglas (revisão técnica, 22 horas). Total: 422,5 horas. Ao cruzar com a capacidade do sprint (Marcus e Julia a 60%, 48h cada por sprint), Eduardo calculou que o épico demandaria 4 sprints (8 semanas).
- EAR do projeto: Nível 1 — Pessoas, Infraestrutura, Licenças. Nível 2 — Pessoas > Desenvolvimento (backend, frontend), Design, QA, Gestão. Infraestrutura > Cloud (AWS EC2, RDS, S3), CI/CD (GitHub Actions). Licenças > Figma, GitHub Pro, domínios.
- Gargalos identificados: Marcus Webb era necessário em 10 dos 12 épicos (backend era a competência mais demandada). Bruno Silva tinha férias no mês 6, exatamente quando o épico de “Dashboard Executivo” (muito intensivo em design) estava planejado. Eduardo reorganizou o roadmap para antecipar entregas de design.
Resultado: A estimativa paramétrica permitiu prever com precisão de 87% as necessidades de recursos ao longo dos 12 meses. No mês 5, quando Eduardo precisou justificar ao board a contratação de um terceiro desenvolvedor, apresentou a EAR e os requisitos de recursos por épico — a aprovação saiu em 3 dias com dados concretos, sem “achismo”.
7. Atalhos, Templates e Dicas
Templates recomendados
- Template de Requisitos de Recursos: Planilha com colunas: ID da atividade, descrição, tipo de recurso, quantidade, competência/especificação mínima, período de necessidade, premissas, alternativas.
- Template de Estrutura Analítica dos Recursos (EAR): Diagrama hierárquico ou planilha com decomposição por categoria > tipo > recurso específico.
- Template de Análise de Alternativas: Tabela comparativa com alternativas de recurso para cada atividade, incluindo custo, prazo, qualidade e risco de cada opção.
Dicas avançadas
- Estime recursos ANTES de estimar durações: A sequência lógica é: escopo > recursos > durações > custos. Inverter essa ordem gera estimativas circulares.
- Use dados históricos sempre que possível: A melhor estimativa vem de dados reais de projetos anteriores, não de “opinião” isolada. Se a organização não tem dados históricos, comece a coletá-los agora.
- Documente as premissas de cada estimativa: “Estimei 3 dias porque assumi um DBA sênior com experiência em Oracle.” Se a premissa muda (DBA júnior, sem experiência), a estimativa precisa ser refeita.
- Considere a curva de aprendizado: Um recurso novo em uma tecnologia ou ferramenta não terá a mesma produtividade de um recurso experiente. Inclua tempo de ramp-up nas estimativas.
- Revise as estimativas com a equipe: Estimativas feitas unilateralmente pelo GP tendem a ser otimistas. Envolva quem vai executar na estimativa — eles conhecem os detalhes que impactam os recursos necessários.
8. Erros Comuns e Como Evitá-los
Erro 1 — Estimar durações sem estimar recursos
Por que acontece: A pressão por um cronograma rápido leva a equipe a estimar durações diretamente, sem primeiro definir que recursos executarão cada atividade.
Como evitar: Estabeleça como regra que nenhuma estimativa de duração é válida sem a estimativa de recursos correspondente. A pergunta “quanto tempo leva?” só pode ser respondida após “quem vai fazer e com o quê?”.
Erro 2 — Assumir recursos genéricos
Por que acontece: A estimativa diz “1 desenvolvedor, 5 dias” sem especificar nível de experiência, tecnologia ou competências. Um “desenvolvedor” pode ser um júnior ou um arquiteto — a diferença de produtividade pode ser de 3x a 5x.
Como evitar: Sempre qualifique o recurso: nível de senioridade, competências específicas, certificações necessárias. “1 desenvolvedor backend sênior com experiência em API REST e PostgreSQL” é uma estimativa; “1 desenvolvedor” é um chute.
Erro 3 — Não considerar disponibilidade real
Por que acontece: A estimativa assume que o recurso estará 100% disponível, quando na realidade está compartilhado entre projetos, tem reuniões, treinamentos e atividades funcionais.
Como evitar: Use fatores de produtividade realistas. Uma pessoa “alocada” 100% ao projeto tipicamente tem 60-70% de tempo produtivo para atividades do projeto. Confirme alocações reais com gerentes funcionais.
Erro 4 — Esquecer recursos físicos nas estimativas
Por que acontece: O foco recai sobre pessoas, e recursos físicos (servidores, licenças, materiais, salas, equipamentos) são esquecidos até que sua ausência atrasa uma atividade.
Como evitar: Para cada atividade, pergunte: “Além de pessoas, que equipamentos, materiais, licenças ou infraestrutura são necessários?” Inclua recursos físicos na EAR e nos requisitos de recursos.
Erro 5 — Não revisitar estimativas quando premissas mudam
Por que acontece: As estimativas são feitas uma vez e nunca mais revisadas, mesmo quando a tecnologia, a equipe ou o escopo mudam significativamente.
Como evitar: Vincule cada estimativa às suas premissas. Quando uma premissa muda, as estimativas associadas devem ser revistas. Em planejamento em ondas, re-estime as atividades do próximo horizonte a cada ciclo.
9. Tailoring: Preditivo, Ágil e Híbrido
Ambiente Preditivo (Waterfall)
- Estimativas detalhadas por atividade, com requisitos documentados para cada recurso
- EAR formal com 3+ níveis de decomposição
- Estimativas aprovadas antes de iniciar a execução
- Re-estimativa formal a cada mudança de escopo aprovada
Ambiente Ágil
- Estimativas focadas em capacidade da equipe (velocity) mais do que em recursos por atividade
- Equipes cross-funcionais estimam coletivamente (Planning Poker)
- Recursos estimados por sprint/iteração, refinados continuamente
- EAR simplificada ou implícita na composição do time
Ambiente Híbrido
- Estimativas detalhadas para pacotes de trabalho de fases preditivas
- Capacity planning por sprint para fases ágeis
- EAR formal para o projeto como um todo + estimativas iterativas por sprint
| Aspecto | Preditivo | Ágil | Híbrido |
|---|---|---|---|
| Granularidade | Por atividade | Por sprint/equipe | Por fase + por sprint |
| Técnica principal | Bottom-up + paramétrica | Velocity + Planning Poker | Bottom-up (fases) + velocity (sprints) |
| EAR | Formal, detalhada | Implícita na equipe | Formal para projeto + implícita por sprint |
| Revisão | Por mudança de escopo | A cada sprint | Por fase + a cada sprint |
10. Interações com Outros Processos e Domínios
Processos que alimentam a estimativa de recursos
| Processo | Domínio | O que fornece |
|---|---|---|
| Planejar o Gerenciamento dos Recursos (Processo 30) | Recursos | Framework de papéis, categorias de recursos, políticas de alocação |
| Definir Escopo / Criar EAP | Escopo | Pacotes de trabalho e atividades que precisam de recursos |
| Identificar Riscos | Riscos | Riscos que podem afetar disponibilidade ou tipo de recurso necessário |
Processos que dependem da estimativa de recursos
| Processo | Domínio | O que recebe |
|---|---|---|
| Estimar Durações das Atividades | Cronograma | Tipos e quantidades de recursos para calcular durações realistas |
| Estimar Custos | Finanças | Requisitos de recursos para calcular custos por atividade |
| Adquirir Recursos (Processo 32) | Recursos | Requisitos de recursos — o que precisa ser adquirido |
| Desenvolver o Cronograma | Cronograma | EAR e requisitos para nivelamento de recursos |
Interações com os Domínios
Escopo: A EAP define o trabalho; a estimativa de recursos define o que é necessário para executar cada pacote de trabalho.
Cronograma: As estimativas de recursos são entrada direta para estimativas de duração e para o nivelamento de recursos no desenvolvimento do cronograma.
Finanças: O custo do projeto é, em grande parte, o custo dos recursos estimados. Sem estimativas de recursos, as estimativas de custo são genéricas.
Riscos: Estimativas de recursos podem revelar riscos (recurso escasso, competência inexistente na organização, lead time longo para materiais).
11. Checklist de Aplicação Rápida
- Todas as atividades (ou pacotes de trabalho) têm estimativas de recursos associadas — tipo, quantidade e período?
- Os recursos humanos estão qualificados por competência/senioridade (não genéricos como “1 desenvolvedor”)?
- Os recursos físicos (equipamentos, licenças, materiais, infraestrutura) foram estimados junto com os humanos?
- A Estrutura Analítica dos Recursos (EAR) foi construída, mostrando a demanda consolidada por categoria?
- As premissas de cada estimativa estão documentadas (produtividade, disponibilidade, competência assumida)?
- Gargalos de recursos foram identificados (mesmo recurso demandado por múltiplas atividades simultâneas)?
- As estimativas foram validadas com especialistas e/ou gerentes funcionais responsáveis pelos recursos?
Regra prática: Se menos de 5 destes itens foram atendidos, a estimativa de recursos não está completa. Cronogramas e orçamentos baseados em estimativas incompletas de recursos são ficção — e ficção não sobrevive ao primeiro sprint.
12. Faça agora com IA: o Processo 8 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 8 de 40.
O que este processo lê do seu quadro
- as datas e dependências dos pacotes de trabalho
- os itens da lista Orçamento
- o cartão da equipe
O que ele entrega
- Base das estimativas
- Estrutura analítica dos recursos
- Requisitos de recursos
Como rodar
- Responda no seu quadro do projeto (ProjectAdm).
- Rode o processo 8 — 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 Estimar Recursos é o elo que conecta o escopo do projeto às estimativas de prazo e custo. Sem ele, cronogramas e orçamentos são construídos sobre suposições — e suposições não sobrevivem ao contato com a realidade.
Os três pontos essenciais para levar para a prática:
- Estime recursos ANTES de estimar durações. A duração de uma atividade depende de quem vai executá-la e com quais ferramentas. Inverter essa ordem gera cronogramas fictícios que desmoronam na execução.
- Qualifique os recursos — nunca use genéricos. “1 DBA sênior com experiência em Oracle e PostgreSQL” é uma estimativa; “1 pessoa de banco de dados” é um chute. A precisão da estimativa determina a precisão do cronograma e do orçamento.
- A EAR é seu radar de gargalos. Ao consolidar todos os recursos em uma estrutura hierárquica, os gargalos ficam visíveis: o mesmo especialista necessário em 20 atividades, o mesmo equipamento disputado por 3 equipes. Identificar gargalos durante o planejamento é 10x mais barato do que descobri-los durante a execução.
Próximo passo concreto: Abra o seu projeto atual. Cada atividade do cronograma tem recursos estimados com tipo, quantidade e competência? Se não, comece pelas atividades do caminho crítico — essas são as que mais impactam o prazo se os recursos forem insuficientes.
Veja todos os artigos do PMBOK 8 no Indice Completo
🇺🇸 Read this article in English
No livro
Estimar Recursos é o Capítulo 9 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 considerar melhor as habilidades, experiências e limitações individuais de cada pessoa ao planejar os recursos do projeto, evitando tratar a equipe apenas como capacidade disponível. Isso permitirá distribuir as atividades de forma mais adequada e definir estimativas mais realistas.
— Rafael Ferreira Alves · 2 semanas atrás
A aplicação da Estrutura Analítica dos Recursos (EAR) combinada com o mapeamento rigoroso de equipamentos e competências técnicas é a frente de maior valor para a rotina de construção pesada aliada a treinamentos e cultura de segurança. Na execução de obras pesadas, é comum que o planejamento trate máquinas, ferramentas de medição e equipes como unidades genéricas, gerando gargalos críticos no canteiro — como frentes paradas por falta de equipamentos calibrados, disputas simultâneas por instrumentos de ensaio ou treinamentos obrigatórios atropelados pela pressa da produção. Operacionalizar essa visão traz ganhos diretos para a operação: Controle preventivo de gargalos de equipamentos críticos: Utilizar a EAR para mapear claramente a demanda por recursos físicos essenciais (como decibelímetros, luxímetros, medidores de vibração ou EPIs especiais de ancoragem) e verificar a disponibilidade e calibração frente ao cronograma de frentes de trabalho. Isso evita que equipes fiquem ociosas ou executem serviços sem a devida conformidade metrológica. Garantia de qualificação técnica nas frentes de risco: Detalhar os requisitos de competência para cada atividade de alta criticidade (espaços confinados, trabalho a quente ou em altura) assegurando que os profissionais alocados possuam as certificações e treinamentos específicos exigidos pelas Normas Regulamentadoras, blindando o canteiro contra desvios legais e operacionais.
— ROBSON PEIXOTO · 4 semanas atrás
Pretendo considerar melhor as características de cada pessoa na hora de distribuir as atividades, levando em conta experiência, habilidade e limitações, e não apenas a quantidade de pessoas disponíveis.
— caio mosl · 1 mês atrás
Entender melhor como aplicar a questão dos recursos e custos no projeto.
— NICOLE CORREA AIRES DE OLIVEIRA · 1 mês atrás
Usefull
— Dominick Ronaldo Doza Saboya · 2 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.
