Muitos projetos e pouca gente: quando contratar resolve

Contratar só resolve quando você tem muitos projetos, faz uma priorização de projetos honesta e ainda falta time. Antes disso, gente nova costuma ser absorvida pelo mesmo excesso de projetos que criou a falta de capacidade.

Você conhece o roteiro. O ciclo de planejamento começa, cada diretoria traz suas prioridades número um, tecnologia soma tudo e descobre que precisaria de muito mais gente do que tem. A negociação que vem depois é sempre a mesma: mais headcount, prazo mais longo ou cobrança por produtividade.

Quase ninguém pergunta o que deveria sair da lista.

Não é impressão. Numa pesquisa da Booz & Company com mais de 2.000 executivos, publicada na strategy+business, 64% disseram que suas empresas tinham prioridades conflitantes demais, e 49% afirmaram que não havia sequer uma lista de prioridades estratégicas.

Em muitas empresas grandes, a falta de capacidade não é falta de gente: é excesso de iniciativas que ninguém consegue justificar e ninguém tem autoridade, ou coragem, para parar. Por isso, antes de pedir mais gente, a pergunta é outra: quantos dos projetos que ocupam seu time seriam aprovados se chegassem hoje?

Um projeto verde pode estar queimando dinheiro

Imagine um projeto importante no status report: prazo verde, orçamento verde, escopo verde, 70% executado. A gestão parece impecável.

Agora faça outra pergunta: se esse projeto ainda não existisse, nós o aprovaríamos hoje?

O status report não responde isso. Para responder, é preciso olhar para outras coisas:

O problema original continua relevante?
A premissa que justificou o investimento continua válida?
O benefício esperado ainda compensa o dinheiro, o tempo e as pessoas que o projeto consome?
Surgiu uma alternativa melhor?
A prioridade do negócio mudou?

É perfeitamente possível ter um projeto bem executado que já não deveria estar sendo executado. O acompanhamento tradicional mede se estamos fazendo certo. Quase nunca mede se ainda estamos fazendo a coisa certa.

O PMI trata disso como gestão da realização de benefícios (Benefits Realization Management): a entrega não encerra a discussão sobre valor. O benefício precisa estar ligado à estratégia, ter um responsável e continuar sendo acompanhado depois da entrega. No Pulse of the Profession o PMI apontou que 83% das organizações não tinham maturidade nessa prática, e que 74% dos projetos atingiam metas e intenção de negócio quando os benefícios eram identificados antes do início.

Como o portfólio incha: a priorização de projetos ao contrário

O caminho de uma iniciativa deveria partir do resultado. Em muitas empresas, ele parte da ideia.

Como deveria ser	Como costuma acontecer
1. Resultado que o negócio precisa	1. Surge uma ideia
2. Driver que precisa mudar	2. Alguém importante patrocina
3. Processo afetado	3. Vira projeto
4. Capacidade necessária	4. Recebe orçamento
5. Iniciativa	5. Consome pessoas
6. Benefício esperado	6. Depois alguém tenta explicar qual estratégia ele atende
7. Resultado medido	7. O projeto termina sem medição de resultado

A coluna da direita é de onde vêm as dezenas de prioridades simultâneas, os projetos que nunca terminam e as equipes que parecem permanentemente sem capacidade. Cada item entrou por um motivo legítimo para alguém. Nenhum entrou com critério para sair.

Da meta de EBITDA à tecnologia: a ordem importa

“Aumentar EBITDA” é uma direção correta, mas ainda não diz o que fazer. É preciso descer a cadeia:

EBITDA → receita → retenção → reduzir cancelamentos → entender por que os clientes estão saindo.

Agora aparecem causas concretas: preço, atendimento, produto, canais digitais, percepção de valor. Suponha que os dados apontem problemas relevantes na jornada digital. A cadeia continua:

Reduzir cancelamentos → melhorar a experiência digital → corrigir os processos críticos da jornada → integração, dados, arquitetura, automação ou IA.

A tecnologia apareceu depois do problema. A conversa não começou com “precisamos de um projeto de IA”. Começou com “precisamos reduzir cancelamentos: o que está causando isso e onde a tecnologia gera resultado?”.

Para decidir investimento, IA poderia se chamar biscoito

Quando alguém diz “precisamos usar IA”, a primeira pergunta deveria ser: para produzir qual resultado?

Para a decisão de investimento, IA poderia se chamar automação, software, algoritmo ou biscoito. O nome da tecnologia não justifica o projeto. A sequência ruim é “temos IA, onde podemos usar?”. A sequência boa começa pelo resultado a melhorar, passa pelo problema, pelo processo e pela linha de base, e só então escolhe a intervenção. IA pode ou não fazer parte dela.

Os números confirmam que adoção não é resultado. O BCG reportou em 2025 que 60% das empresas pesquisadas obtinham pouco ou nenhum valor material com IA, com ganhos mínimos de receita e custo. Em 2024, a mesma consultoria mostrou que as empresas que lideram em IA colocam 10% dos recursos em algoritmos, 20% em tecnologia e dados e 70% em pessoas e processos. Valor vem de mudar o trabalho, não de ligar a ferramenta.

O teste de cinco perguntas antes de aprovar qualquer iniciativa

Não é preciso outro framework. Antes de um projeto entrar no portfólio, cinco respostas precisam estar claras:

Qual resultado do negócio queremos alterar? Não “modernizar”, “inovar” ou “usar IA”. Qual resultado.
Qual é a linha de base? Sem saber onde estamos, não há como provar melhoria.
Qual benefício esperamos? Receita, custo, risco, produtividade, experiência, disponibilidade ou outra variável mensurável, com valor estimado.
Quem responde pelo benefício? O gerente do projeto responde pela entrega. Alguém do negócio precisa responder pelo resultado.
Quando vamos verificar se funcionou, e o que nos faria parar? Projeto entregue não é benefício realizado. E projeto sem critério de parada só para quando acaba o dinheiro ou a paciência.

Sem essas respostas, ainda não existe um projeto. Existe uma ideia. Ideias podem ser ótimas, só não deveriam disputar orçamento e pessoas como se já fossem prioridade estratégica.

Como liberar capacidade no portfólio que já existe

O teste protege a porta de entrada. Mas a capacidade que falta hoje está presa no que já entrou. É ali que está a resposta para quem precisa de gente agora.

Liste tudo o que consome pessoas, não só o que está no escritório de projetos. Demandas recorrentes, projetos pequenos de área e pilotos que viraram operação entram na conta.
Aplique a cada item a pergunta “aprovaríamos hoje?” e as cinco perguntas acima.
Classifique em três grupos: continua (passa no teste), reformula (falta resposta, e o dono do benefício tem prazo curto para completá-la) e para (não passa, ou ninguém assume o benefício).
Leve ao comitê a decisão de parar com o ganho explícito: quantas pessoas e quanto orçamento voltam para as iniciativas que passaram no teste.
Para o que continua, registre o critério de parada e a data da próxima verificação de benefício.

Parar um projeto em andamento custa caro politicamente, porque alguém importante o patrocinou e o investimento já feito pesa na decisão. Por isso a decisão não pode ser da TI. A TI mostra o custo em capacidade; o dono do resultado decide se o benefício ainda vale esse custo.

Governança madura não existe para colocar mais etapas entre a ideia e a execução. Existe também para ajudar a empresa a dizer não.

Quando contratar resolve de fato

Depois do filtro, a conta muda de natureza. Se o que sobrou de projetos ativos ainda demanda recursos, aí sim falta gente, e o pedido de contratação passa a ter uma base que o CFO consegue avaliar.

Contratar tende a resolver quando:

o portfólio já passou pelo teste e o que sobrou, com resultado, linha de base e dono, ainda excede a capacidade;
o gargalo está em trabalho recorrente que cresce com o negócio (mais usuários, mais sistemas, mais volume de operação), e não num pico de projetos;
falta uma competência específica que trava várias iniciativas aprovadas ao mesmo tempo;
o benefício que as iniciativas atrasadas deixam de gerar é maior que o custo da contratação.

Contratar tende a só aumentar o problema quando:

ninguém consegue dizer o que sairia da lista, e a nova capacidade será ocupada pelo mesmo fluxo sem filtro;
o pico é temporário, e uma contratação permanente vira custo fixo para um problema passageiro;
o projeto já está atrasado e a expectativa é que gente nova recupere o prazo. Fred Brooks descreveu isso em 1975, em The Mythical Man-Month: colocar mais gente num projeto de software atrasado o atrasa ainda mais, porque quem chega precisa ser integrado e treinado por quem já está lá.

A diferença aparece no próprio pedido. “Estamos sobrecarregados” é percepção. “Estas iniciativas passaram no teste, geram este benefício e não cabem na capacidade atual” é um caso de investimento.

Na prática: o pedido de mais gente vem junto com a lista do que sai. Se a área não consegue apontar nada que deixaria de fazer, o pedido ainda não está pronto para ser aprovado.

Talvez sua empresa não precise de tantos projetos

Quando uma organização reclama o tempo todo de falta de capacidade, há duas possibilidades: falta capacidade de fato, ou há iniciativas demais disputando recursos limitados. Contratar resolve a primeira. A segunda exige decisões mais difíceis: priorizar, interromper, consolidar e dizer não.

Por isso uma boa governança não deveria ser medida pela quantidade de projetos que acompanha, e sim por quantos deles consegue justificar.

Quantos projetos do seu portfólio você conseguiria ligar, em menos de dois minutos, a um resultado de negócio, uma linha de base, um benefício esperado e alguém responsável por realizá-lo?