A public broadcaster once asked its project office whether it should replace its project management tools. Microsoft Project Online on one side, Jira on the other, an open-source option on the table, and a business case to write. The work got done the way such work gets done: licences compared, migration effort estimated, risks listed, recommendation made.
The question that mattered more was not in the brief. Whichever tool the organisation picked, who would be accountable for the projects actually landing, and would that person be trusted enough to make the calls that landing them requires?
No comparison table answers that, and no tool compensates for the answer being unclear.
Methods are useful, and they are not the reason projects succeed
Few organisations fail for lack of a framework. Most have several at once: a stage-gate process inherited from a consultancy, agile ceremonies added a few years later, a project office producing dashboards, and a steering calendar fixed twelve months ahead. The Project Management Institute says much the same in its 2026 Pulse of the Profession report, whose title argues that best practices on their own are not enough, and which finds that 31% of complex projects do not deliver the full benefits they were meant to produce, more than twice the rate for projects in general.1
That is not a case for abandoning method. A clear stage structure stops a project starting without a sponsor. Working in short iterations exposes a bad assumption in weeks instead of quarters. Both help, and anyone who has worked without them knows what the absence costs. What a method cannot do is make people willing to use it honestly. A status report is only as truthful as the person filling it in believes it is safe to be.
What sits underneath
Patrick Lencioni puts the absence of trust at the bottom of his pyramid of team dysfunction. Above it come fear of conflict, lack of commitment, avoidance of accountability, and finally inattention to results.2 Read from the bottom up, that describes a great many troubled projects. People who do not trust each other avoid the difficult conversation about scope. With that conversation avoided, nobody really signs up to the plan. With nobody signed up, nobody holds anyone to account. And the result that nobody owns is the one that slips.
Amy Edmondson arrives at the same place from another direction. Her research shows that a team’s willingness to raise an error or a risk predicts performance better than the talent the team contains.3 Projects rarely derail because nobody noticed the problem. They derail because the person who noticed it decided that keeping quiet was the safer move.
Someone has to get up in the morning to land it
A project needs a person whose job is to see it through. Coordinating and reporting are part of the work, but they are not the point of the role, and a team can tell the difference within a fortnight. For that role to function, trust has to run in three directions at the same time.
The lead has to believe in the return. Someone who privately doubts the investment will pay off manages the calendar, protects the budget, and does not fight for the decisions that make the benefits real. This is not about enthusiasm; it is about holding a view of the business case that survives contact with a sceptical colleague. Can your project lead explain, without the slide deck, what the organisation gets back and when?
The hierarchy has to trust the lead, and trust here means delegated authority rather than encouragement. A lead who has to escalate every scope trade-off has responsibility without power, which produces delays while decisions queue upward and, soon after, a lead who quietly stops owning anything. How many decisions can your project lead take alone?
And the lead has to trust the teams. That means accepting estimates that are inconvenient, hearing bad news without hunting for someone to blame, and letting the people doing the work decide how to do it. The first piece of bad news on a project is a test. Whatever happens in that moment sets the tone for everything reported afterwards.
Owning the return, not just the plan
Most organisations stop one step short. The project lead is held accountable for scope, time and cost, while the return on investment stays with a sponsor who looks at the project once a month in a steering committee. People optimise what they are measured on, so the lead delivers the scope, meets the date, respects the budget, and leaves the benefits to someone else.
When the return belongs to the lead, the questions change. A feature that costs three weeks and moves nothing gets challenged instead of built. A deadline that would launch something nobody can use gets renegotiated while that is still cheap. The uncomfortable conversation happens early, which is the only time it is useful.
There is a fair objection. A project lead rarely controls the whole chain of value: adoption depends on operations, savings on decisions taken elsewhere, revenue on a commercial team. Holding someone to a result they cannot control alone is unfair and does not work. The workable version is ownership of the case: the lead is accountable for keeping the benefit logic honest, for saying out loud when it stops holding, and for proposing what to change. That mandate is defensible, and it is the one most project charters forget to write down.
As for the broadcaster, the tooling question deserved an answer and the business case was worth writing. What would have decided the outcome, whichever tool had won, was whether someone owned the result and had the room to go after it.
Four questions worth asking about your own projects
Who gets up in the morning with the job of landing this project, and do they know that is their job?
Do they believe the investment will pay off, and can they say why in their own words?
How many decisions can they make without escalating?
What happened the last time someone brought them bad news?
None of these appear in a methodology, and all four tell you more about how the project will end than the choice of framework.
Notes
- Project Management Institute, « Why Complex Projects Fail: Best Practices Are Not Enough, System Thinking Gives Your Team the Edge », press release on the Pulse of the Profession 2026 report, 12 May 2026: pmi.org. ↩
- Patrick Lencioni, The Five Dysfunctions of a Team, Jossey-Bass, 2002. ↩
- Amy C. Edmondson, « Psychological Safety and Learning Behavior in Work Teams », Administrative Science Quarterly, vol. 44, no. 2, 1999. ↩
About the author. Bernard Lecuivre is a Brussels-based project and programme lead, and an execution coach for executives through Coeos Transformation. He has run transformation and information-system programmes for fifteen years, including as Head of the Technology Project Management Office at RTBF, and for IBA, UCB, the European Commission and the Belgian Ministry of Defence. He holds Prince2 Practitioner, Agile Project Management and Professional Scrum Product Owner certifications, publishes cognitive-science-based teaching resources through Coeos Editions, and directs a youth rugby school in Brussels. He co-hosts the Almendra podcast on organisational transformation and impact measurement.
Work with Bernard Lecuivre: execution coaching for executives | LinkedIn