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.
Why it matters
Projects rarely fail on the day they are declared failed. They fail months earlier, in a meeting where somebody saw the problem coming and calculated it was not in their interest to say so. Everything else — the slipping schedule, the stretching budget — is the visible consequence of that silence.
I read these things looking for where the risk sat before it became an incident. It was almost always already written in some register nobody reviewed, with an assigned owner who never found out they were one. A risk identified and not managed is worse than one never identified: it creates the false sense that there is control.
What usually goes wrong
Where it usually breaks is the handover to operations. The project is declared finished when it is delivered, not when the receiving area can sustain it. Three months later the team has dissolved, nobody documented anything, and operations lives with something it does not understand and cannot change.
What to watch
- The size of the first useful delivery: the further out it is, the more it resembles a bet.
- How it was estimated and how close the same organisation's previous estimates turned out to be.
- Who the sponsor is and how often they actually show up — not on the org chart, in the calendar.
How I read this entry
I would use it to review how the organisation estimates. If historical estimates were systematically out by half and nobody adjusted the method, no project will land well: you are planning with a ruler that measures short and blaming the team for not reaching the mark.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
