Outcome-Based Leadership in Project Management: Measuring What Really Matters
Image The ContextI once led a software development program with more than 100 developers and several project managers. The projects were strategically important for the company, and expectations from upper leadership were high.Officially, the organization was working with Scrum.
Image The ContextI once led a software development program with more than 100 developers and several project managers. The projects were strategically important for the company, and expectations from upper leadership were high.Officially, the organization was working with Scrum.
My mission was clear: get the program back on track and help the project managers reach a higher level of performance.
But one question quickly became apparent: What exactly does good project management performance mean?
The Problem: Measuring the Wrong ThingWhen asked how project manager performance was measured, top management struggled to provide a clear response. The answer usually came back to familiar project success metrics:
These metrics can be useful in managing project success (while usually falling short of adequately measuring project success). But they are not sufficient to evaluate project management performance.
A project can miss a deadline because of changing customer requirements, technical challenges, organizational dependencies, or decisions made far outside the project manager's area of influence. Conversely, a project can remain on schedule and within budget while communication is poor, risks are hidden, and stakeholders are constantly surprised by what happens next.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 04/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por que importa
Os projetos raramente fracassam no dia em que são declarados fracassados. Fracassam meses antes, numa reunião em que alguém viu o problema chegando e calculou que não lhe convinha dizer. Todo o resto — o cronograma que escorrega, o orçamento que estica — é a consequência visível desse silêncio.
Leio essas coisas procurando onde o risco estava antes de virar incidente. Quase sempre já estava escrito em algum registro que ninguém revisava, com um dono atribuído que nunca soube que era. O risco identificado e não gerenciado é pior que o não identificado: dá a falsa sensação de que há controle.
O que costuma dar errado
Onde costuma quebrar é na passagem para a operação. O projeto é declarado concluído quando é entregue, não quando a área que recebe consegue sustentá-lo. Três meses depois a equipe se dissolveu, ninguém documentou nada, e a operação convive com algo que não entende e não pode modificar.
O que observar
- O tamanho da primeira entrega útil: quanto mais longe estiver, mais se parece com uma aposta.
- Como foi estimado e quão perto estiveram as estimativas anteriores da mesma organização.
- Quem é o patrocinador e com que frequência real aparece — não no organograma, na agenda.
Como leio esta publicação
Eu usaria isto para revisar como se estima na organização. Se as estimativas históricas erraram sistematicamente pela metade e ninguém ajustou o método, não há projeto que dê certo: está se planejando com uma régua que mede curto e culpando a equipe por não chegar.
A notícia original está publicada em outro idioma; o trecho é citado como o veículo o entrega e o comentário é escrito em português.
Comentários
Ainda não há comentários. O primeiro pode ser o seu.
Está vivendo isso na sua equipe?
Abra o chat e me conte como estão lidando com isso. Tenho interesse em comparar notas.
