A few years ago, I joined the adventure of building a company around a SaaS document management solution. On paper, everything looked promising. The technology was solid. The platform was modern, scalable, and honestly quite advanced for its time. The teams were performing well:
- releases were delivered on time,
- scope commitments were respected,
- roadmaps were executed properly,
- and from a pure project delivery perspective, things looked under control.
But after three years, we made the difficult decision to stop not because the teams failed, not because the product was poorly built and not because execution was chaotic.
We stopped because the value proposition was not sufficiently aligned with what the market truly expected. We had built something technically impressive, but not something customers were ready to adopt at the scale we had envisioned.
That experience stayed with me for years because it forced me to rethink something fundamental:
A project can be a delivery success and still be a business failure.
And honestly, I believe many organizations are still struggling with that distinction. For decades, project management has been heavily focused on the famous “iron triangle”: on time, on budget and on scope.
Of course these things matter but in today’s world, they are no longer enough because projects are not created to deliver milestones. They are created to deliver value.
We Sometimes Confuse Delivery Excellence With Real Success
I have seen projects that were late, painful, politically difficult, and significantly over budget… yet created enormous long-term value for organizations and I have seen perfectly executed projects quietly disappear a few months after go-live because nobody really needed them.
The uncomfortable truth is that a project can respect every KPI and still fail. Why? Because success is not only about execution quality. It is also about relevance.
Does the project solve the right problem? Does it create meaningful impact? Does it still make sense as the environment changes?
Those questions are often harder than project planning itself.
The Obsession With Speed Is Creating New Problems
One thing I increasingly observe in organizations is the belief that moving faster means spending less time thinking.
We rush. We start before alignment exists. We reduce planning. We skip difficult conversations. We tell ourselves we will “figure it out later.”
Sometimes we even celebrate that behavior as agility but in reality, many of the delays and failures we later face are simply the cost of insufficient thinking at the beginning.
I am not advocating for heavy bureaucracy or endless documentation but I do believe that strong projects require moments where people slow down enough to:
- challenge assumptions,
- clarify objectives,
- understand dependencies,
- involve stakeholders properly,
- and ask uncomfortable questions early.
I used to say :
rework is always slower than thoughtful preparation.
Complexity Is Mostly About Humans
We often talk about complexity as if it were purely technical. In reality, the hardest part of complex projects is usually not the technology. It is the interfaces:
- between teams,
- between suppliers,
- between business and IT,
- between leadership layers,
- between conflicting priorities,
- and sometimes between different visions of success.
The larger the project becomes, the harder it is for one person (or even one team) to fully understand everything happening simultaneously and the longer projects last, the more the world around them changes:
- markets evolve,
- technology shifts,
- regulations move,
- priorities change,
- people leave,
- leadership rotates.
That is why adaptability matters so much. Not adapting during a long project is often more dangerous than changing direction.
The Most Dangerous Sentence in a Project
There is one sentence that always worries me when I hear it:
“But this project is unique.”
Of course every project has unique aspects but sometimes “uniqueness” becomes an excuse to ignore experience, benchmarks, or warning signs and that is where optimism bias starts becoming dangerous.
I have learned that some of the strongest warning signs in projects are often surprisingly simple:
- stakeholders are not truly involved,
- key roles remain unclear,
- difficult topics are avoided,
- reporting looks “too green,”
- or teams become convinced that normal rules no longer apply to them.
Projects rarely collapse overnight. Usually, the signals were there for months.
Great Leaders Do Not Carry Projects Alone
One of the hardest transitions for project leaders is understanding that leadership is no longer about personally solving every problem. Many leaders come from technical or specialist backgrounds. Their instinct is to jump in, fix issues, control details, and stay involved in everything. I understand that instinct very well but large-scale projects cannot rely on heroics.
The real role of leadership is to create an environment where the work can succeed without becoming dependent on one individual. That means:
- creating clarity,
- structuring governance,
- enabling collaboration,
- building trust,
- empowering teams,
- and making difficult decisions early enough.
The best project leaders I have seen are rarely the loudest people in the room. They are the ones quietly building systems that allow others to perform.
We Need To Normalize Reassessment
One thing organizations still struggle with is stopping, pausing, or reframing projects honestly. Too often, projects continue simply because:
- too much money was already invested,
- nobody wants to admit the situation changed,
- or governance systems unintentionally discourage transparency.
But persistence is not always leadership. Sometimes leadership means reassessing reality early enough to change direction before the damage becomes irreversible. I believe organizations need to become much better at continuously asking:
- Does this still create value?
- Are we solving the right problem?
- What changed since we started?
- Should we adapt?
- Or should we stop?
Those are difficult conversations but avoiding them is usually far more expensive.
Final Thought
Over the years, I have become convinced that project success is much more human, strategic, and dynamic than most dashboards suggest. Being on time, on budget and delivering scope matter but none of those things matter if the project ultimately fails to create meaningful value. Maybe the real question project leaders should ask themselves is not:
“Did we deliver the project correctly?”
But rather:
“Did we build something that truly deserved to exist?”