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 qué importa
Los proyectos rara vez fracasan el día que se declaran fracasados. Fracasan meses antes, en una reunión donde alguien vio venir el problema y calculó que no le convenía decirlo. Todo lo demás —el cronograma que se corre, el presupuesto que se estira— es la consecuencia visible de ese silencio.
Leo estas cosas buscando dónde estaba el riesgo antes de convertirse en incidente. Casi siempre ya estaba escrito en algún registro que nadie revisaba, con un dueño asignado que nunca se enteró de que lo era. El riesgo identificado y no gestionado es peor que el no identificado: da la falsa sensación de que hay control.
Lo que suele salir mal
Donde suele romperse es en el traspaso a operación. El proyecto se declara terminado cuando se entrega, no cuando el área que lo recibe puede sostenerlo. Tres meses después el equipo se disolvió, nadie documentó nada y la operación convive con algo que no entiende y no puede modificar.
Qué mirar
- El tamaño de la primera entrega útil: mientras más lejos esté, más se parece a una apuesta.
- Cómo se estimó y qué tan cerca estuvieron las estimaciones anteriores de la misma organización.
- Quién es el patrocinador y con qué frecuencia real aparece — no en el organigrama, en la agenda.
Cómo leo esta entrada
Yo lo usaría para revisar cómo se estima en la organización. Si las estimaciones históricas se pasaron sistemáticamente por la mitad y nadie ajustó el método, no hay proyecto que salga bien: se está planificando con un metro que mide corto y culpando al equipo por no llegar.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
Comentarios
Todavía no hay comentarios. El primero puede ser el tuyo.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
