Como este tema funciona na sua empresa
Gestão simples — Gantt em Excel, custo em planilha, bugs encontrados em anotações. Pouca formalidade; repasse informal ao gestor. Muitos "projetos" são realmente correções/manutenções, não projetos formais.
Gestão formal com ferramenta (Jira, Azure DevOps). Acompanha prazo (Gantt/burndown), custo (planilha), bugs. Relatório mensal de saúde. Separação entre ágil e waterfall.
PMO central, EVM em tempo real, dashboards integrados. Múltiplas métricas por tipo de projeto. Análise de portfolio (ROI, risco, estratégia). Alertas automáticos para desvios.
Indicadores de projetos de TI medem desempenho em três dimensões: prazo (projeto termina no dia?), custo (gasta o orçado?), qualidade (entrega sem bugs?). Balancear as três é desafio — otimizar uma frequentemente prejudica outra.
O tripé de projeto: prazo, custo, qualidade
Projeto tem três restrições. Escolha duas; a terceira sofre:
- Rápido + barato = qualidade baixa (bugs escapam).
- Rápido + qualidade = caro (precisa de mais gente).
- Barato + qualidade = lento (poucos recursos, qualidade levada a sério).
Gestor de projeto precisa negociar qual é a prioridade com stakeholder: é mais importante terminar no prazo ou não vazar qualidade? Essa conversa é crítica — sem ela, projeto falha em tudo.
Métricas de prazo: passou ou não passou?
Métricas básicas de prazo:
- Progresso de cronograma (Schedule Performance Index, SPI): quanto trabalho foi entregue vs. quanto deveria ter sido. SPI <1 significa atraso, >1 significa adiantado.
- Margem de atraso: quanto tempo o projeto ainda tem antes de passar do deadline. Calculado a partir de SPI — se SPI=0.8, projeto está 20% atrasado e vai terminar ~20% após data original.
- Variação de cronograma (Schedule Variance, SV): diferença entre trabalho entregue e trabalho planejado em dias/semanas.
Para Ágil: usar velocity (pontos entregues/sprint) e burndown (gráfico de progresso). Mesma lógica, formato diferente.
Métricas de custo: pagando mais que o orçado?
Métricas de custo:
- Cost Performance Index (CPI): valor entregue vs. valor gasto. CPI <1 significa gastando mais que o planejado (alarm!), >1 significa dentro do orçado.
- Variação de custo (CV): diferença em reais entre o que foi gasto e o que deveria ter sido gasto.
- Runrate vs. orçado: ritmo de gasto — se gastar R$ 10k/mês e orçado era R$ 8k/mês, você vai estourar no mês 6.
CPI <1 é RED FLAG — projeto está queimando dinheiro rápido. Agir logo: ajustar escopo (tirar requisito) ou aumentar produtividade (adicionar gente, melhorar processo).
Métricas de qualidade: bugs encontrados e escapados
Qualidade é subjetiva; métricas usam proxies:
- Bugs por módulo: quantidade de bugs encontrados no código. Divisão por módulo mostra qual parte é mais problemática.
- Cobertura de testes: % do código coberto por teste automatizado. Meta: 70%+. Baixa cobertura (<30%) significa risco alto — bugs vão escapar.
- Defects escapados em produção: bugs encontrados após release. Métrica mais importante — indica qualidade real que cliente vê.
Cuidado: reduzir bugs descobertos em QA não significa qualidade melhor — pode significar testes piores. Métrica que importa é defects em produção.
Earned Value Management (EVM): o framework rigoroso
EVM é framework que unifica prazo, custo e escopo. Conceitos:
- Planned Value (PV): valor que deveria ter sido entregue no cronograma até hoje.
- Earned Value (EV): valor do trabalho que foi realmente entregue até hoje.
- Actual Cost (AC): quanto foi realmente gasto até hoje.
A partir disso:
- SPI = EV / PV — se =1, está no prazo; <1 está atrasado.
- CPI = EV / AC — se =1, está no orçado; <1 está caro.
EVM é rigoroso e funciona para waterfall. Para ágil, adaptar: usar pontos ao invés de valor em reais, velocity ao invés de burndown.
Prazo: % completo vs. timeline. Custo: gasto real vs. orçado em planilha. Qualidade: "teve bugs?". Status: verde/amarelo/vermelho baseado em desvios simples.
EVM básico: SPI, CPI, variação. Burndown/velocity para ágil. Relatório mensal mostrando saúde (verde/amarelo/vermelho) e desvios. Qualidade: cobertura de testes, bugs encontrados.
EVM completo com projeção de término e custo final. Dashboard integrado com múltiplas fontes (ITSM, PMO, financeiro). Análise de risco e escalação automática. Métricas desdobradas por projeto, portfólio, programa.
Status de projeto: verde, amarelo, vermelho
Formato de reporte simples para executivos:
- Verde: prazo < 5% atraso, custo < 5% acima do orçado, qualidade dentro do esperado.
- Amarelo: prazo 5-15% atraso OU custo 5-15% acima OU qualidade abaixo. Acionar plano de remediação.
- Vermelho: prazo >15% atraso OU custo >15% acima OU qualidade crítica. Escalação imediata — pode virar cancelamento.
Cores devem refletir realidade — não pintar de verde um projeto que está em risco. Feedback honesto permite correção cedo.
Diferença entre métodos: Waterfall vs. Ágil
Waterfall (plano fixo) usa EVM clássico com Gantt. Ágil (plano adaptativo) usa velocity e burndown.
Na prática: Waterfall permite precisão de prazo/custo cedo. Ágil permite adaptação se prioridades mudam. Escolher método certo é parte do projeto.
Erro comum: aplicar métrica de waterfall em projeto ágil (ou vice versa). "Por que a velocity caiu?" é pergunta ágil válida. "Projeto está 2 sprints atrás" é termo waterfall em contexto ágil.
Comunicação de riscos: escalação clara
Quando projeto sai do alvo (amarelo/vermelho), comunicar logo. Escalação deve ser clara: "Este projeto está em risco de terminar 1 mês depois porque X. Estamos considerando Y como solução. Decidir até Z."
Não esconder problema esperando melhorar. Projetos que pioram raramente se corrigem sozinhos.
Sinais de que sua empresa precisa melhorar métricas de projeto
Se reconhece em 3+, métricas deve ser prioridade.
- Não consegue dizer se projeto está atrasado até perto do deadline
- Projetos frequentemente estouram orçado; ninguém viu vindo
- Qualidade cai constantemente — "sempre tem bugs em produção"
- Executivo pede "status do projeto X" e resposta é vaga
- Projeto termina e ninguém consegue dizer se foi bem-sucedido (prazo? custo? qualidade?)
- Acompanhamento é manual — planilha em alguém que ninguém atualiza
- Conflito entre TI e negócio sobre "quando vai terminar?" — falta de métrica para resolver
Caminhos para estruturar métricas de projeto
Implementação pode ser interna ou com consultoria.
Viável se PMO/gestor de projeto tem visão de métrica.
- Perfil necessário: gestor de projeto experiente ou analista com visão de EVM/ágil
- Tempo estimado: 2 a 4 meses para definir métricas, adaptar ferramentas, primeiro reporte
- Faz sentido quando: empresa já tem PMO, precisa apenas melhorar reporte
- Risco principal: sem referência externa, pode gerar muita métrica sem clareza sobre o que importa
Recomendado para implementação robusta ou estrutura PMO zero.
- Tipo de fornecedor: Consultoria de PMO ou transformação ágil
- Vantagem: experiência em métrica, integração com ferramenta, treinamento de PMO
- Faz sentido quando: empresa quer estrutura formal ou PMO não existe
- Resultado típico: em 2 a 3 meses, framework de métricas, ferramentas adaptadas, PMO treinado
Precisa estruturar métricas de projeto de TI?
Se métricas de projeto é desafio, o oHub conecta você gratuitamente a consultorias de PMO e transformação ágil. Em menos de 3 minutos, você descreve a situação e recebe propostas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Como medir desempenho de projeto de TI?
Medir em três dimensões: prazo (avanço vs. cronograma), custo (gasto vs. orçado), qualidade (bugs encontrados, testes). Status simples: verde (dentro), amarelo (risco), vermelho (alerta). Reporte mensal resumido para executivos.
Qual métrica saber se um projeto está atrasado?
Schedule Performance Index (SPI = trabalho entregue / trabalho planejado). Se SPI <1, está atrasado. Para ágil: velocity em relação ao planejado; burndown chart mostra visualmente. Métrica de "% completo" é imprecisa — pessoas sempre dizem "90% completo" por muito tempo.
Como acompanhar custo de projeto durante execução?
Cost Performance Index (CPI = valor entregue / valor gasto). CPI <1 significa caro — agir logo. Também acompanhar runrate (gasto/mês) vs. orçado — se ritmo é insustentável, projeto vai estourar. Reporte semanal em projeto crítico, mensal em normal.
Como medir qualidade de um projeto de TI?
Qualidade é subjetiva; usar proxies: cobertura de testes (70%+ é bom), bugs por módulo (identificar áreas problemáticas), defects em produção após release (métrica real de qualidade). Cuidado: reduzir bugs descobertos sem melhorar cobertura de testes significa testes piores, não qualidade melhor.
O que é Earned Value Management (EVM)?
EVM unifica prazo, custo e escopo. Conceitos: Planned Value (deveria entregar), Earned Value (realmente entregou), Actual Cost (realmente gastou). SPI = EV/PV (prazo), CPI = EV/AC (custo). Rigoroso e funciona bem para waterfall; adaptar para ágil usando pontos/velocity.
Como reportar saúde de projeto para executivos?
Formato simples: verde/amarelo/vermelho + 3 números (% prazo, % custo, % qualidade) + próximo passo. Exemplo: "VERDE: 95% prazo, 98% custo, qualidade OK. Entrega em 2 semanas." Não sobrecarregar com detalhes — executivo quer saber: em risco ou não?