Martins 2010 Destaca Os Custos Estimados Como Um Processo

Entendendo custos estimados como processo na prática

Quando eu comecei a trabalhar com planejamento de projetos, sempre vi a parte de estimativas como algo que se fazia uma vez e pronto. Aí entrou o Martins em 2010 destacando os custos estimados como um processo, e isso mudou completamente a forma como eu encaro a coisa. Não é mágica, é só entender que estimar custo não é um evento isolado. É uma sequência de etapas que se repetem, se refinam e se ajustam conforme o projeto avança.

O que o martins 2010 destaca os custos estimados como um processo realmente propõe

A ideia central é simples, mas muita gente pega mal. Estimar custo não acontece num único momento. Começa quando o projeto ainda é vago e vai ganhando precisão conforme mais informações aparecem. Cada fase do projeto tem seu próprio nível de estimativa, e o Martins coloca isso como um fluxo contínuo, não como um documento que se entrega e arquivar. Na prática, isso significa que você trabalha com três tipos de estimativa ao longo do tempo: a estimativa grosseira, que usa parâmetros históricos e fator de experiência; a estimativa analítica, que quebra o trabalho em componentes menores e soma os custos unitários; e a estimativa paramétrica, que aplica modelos estatísticos baseados em variáveis mensuráveis do projeto. Nada disso é novo. O que o Martins traz de útil é a noção de que essas técnicas se complementam ao longo do tempo, não competem.

Como aplicar esse conceito no dia a dia

O primeiro passo é abandonar a ideia de que existe uma estimativa certa. O que existe é uma estimativa adequada ao momento do projeto. Quando eu comecei a aplicar esse raciocínio, meu processo ficou assim: nas primeiras semanas, eu fazia uma estimativa de ordem de grandeza baseada em projetos semelhantes que eu já tinha visto. Não era bonito, mas servia para dar uma noção de viabilidade sem perder tempo. Depois, conforme o escopo ia sendo definido, eu quebrava os trabalhos em EAPs menores e aplicava estimativa analítica nos componentes que já estavam claros. As partes que ainda eram incertas eu mantinha como contingência. O ponto que ninguém conta é que a maior dificuldade não é escolher a técnica. É convencer as pessoas certas a aceitar que a estimativa vai mudar. Eu já entrei em reuniões onde o gerente financeiro Questionou três vezes a mesma estimativa porque ela tinha crescido 18 por cento entre a versão inicial e a versão final. A resposta que eu dava era simples: o projeto não era o mesmo. O escopo tinha ganhado detalhe. A estimativa tinha ganhado precisão. Crescimento não é erro. É aprendizado.

Um problema real que eu tive e como resolvi

Uma vez, eu estava trabalhando num projeto de infraestrutura onde o Martins em 2010 destaca os custos estimados como um processo foi justamente o que eu usei como base. O problema veio quando o cliente aprovou o orçamento na fase inicial, mas dois meses depois pediu uma alteração significativa no escopo. A estimativa que eu tinha feito na fase analítica já estava consolidada e aprovada. Quando a mudança chegou, eu não tinha margem para absorver sem refazer quase tudo. A solução que eu encontrei foi documentar cada premissa da estimativa em um registro separado. Cada item tinha uma explicação do que estava incluído, do que estava excluído e qual nível de confiança eu tinha naquela linha. Quando a mudança aconteceu, eu consegui mostrar exatamente quais itens seriam afetados e por quê, em vez de simplesmente apresentar um novo número total. Isso reduziu o atrito nas negociações e ainda serviu como referência para projetos futuros parecidos.

O que começar bem faz diferença

A parte mais subestimada desse processo todo é a coleta de dados históricos. Se você não tem registros limpos dos custos reais dos projetos anteriores, qualquer estimativa que você fizer vai depender demais da intuição. Eu gasto cerca de uma semana no início de cada projeto novo apenas organizando dados dos últimos três anos de projetos similares. Esse tempo retorna multiplicado quando chega a hora de justificar uma variação ou revisar uma estimativa. Outro ponto que as pessoas esquecem é a revisão periódica. A estimativa não deve ser um documento estático. Eu faço revisões a cada marco importante do projeto, verificando se as premissas continuam válidas e se os dados reais estão alinhados com o que eu previ. Quando os desvios começam a aparecer consistentemente, eu ajusto os fatores de correção para as próximas estimativas. Isso transforma o processo em algo que melhora com o tempo, em vez de repetir os mesmos erros.

Limitações que você precisa saber antes de confiar cegamente

Nenhum modelo de estimativa funciona bem quando os dados de entrada são ruins. Se o escopo é claramente mal definido ou se as informações históricas são escassas ou desatualizadas, a estimativa vai dar falsa sensação de precisão. Eu já vi gente presenting números com duas casas decimais como se fossem exatos, quando na realidade o intervalo de confiança era de mais ou menos trinta por cento. Isso é pior do que apresentar uma faixa ampla e honesta desde o início. Outro problema comum é a dependência excessiva de ferramentas automatizadas. Planilhas e softwares ajudam, mas eles não substituem o julgamento técnico. Um algoritmo não sabe que um fornecedor específico teve problemas de entrega no último trimestre, ou que uma determinada tecnologia ainda está passando por instabilidade no mercado. Essas informações costumam estar com quem executou o trabalho, não no banco de dados. Se o seu cenário é de alto grau de incerteza e baixo volume de dados históricos, vale considerar métodos qualitativos complementares, como o Della technique ou análise de cenários, antes de depender exclusivamente de modelos paramétricos. Eles exigem mais conversa e menos cálculo, mas em contextos ambíguos muitas vezes entregam resultados mais confiáveis.