Why do projects run late?
One summer evening, an old friend and I came back to that question — not for the first time. He looked at projects from the perspective of a business owner; I looked at them as a project manager.
We laid out the facts, recalled situations, listed reasons.
Planning, priorities, communication, responsibilities, resources, decision-making — and sometimes, simply bad timing.
It seemed like almost every problem had a solution — from better agreements and replanning, all the way to introducing a new process. But then we added one more question: what if all of that had already been tried, and projects still got stuck?
You know, that evening we arrived at a fairly simple conclusion. The problem often isn't in the plan, or even in the people. It's in how the organization understands what a project actually is, why it's being carried out, and what each person's role in it is.
If the manager, the project manager, and the team member each understand the project differently, a good plan alone won't save it.
That's exactly when the idea came: why not use the experience I'd built up to help managers and project teams agree on:
- what a project actually is, and why it's needed;
- what needs to happen before a project starts;
- why different roles, documents, and tools are needed;
- how to use them not "for the process's sake," but so the agreed result is delivered on time and within the agreed budget.
Few people get to see a project from as many different sides as I have over my career.
I was a team member, carrying out planned work. I was a project manager, planning, coordinating, preparing documents and presentations. I was on the client's side, where what matters most is the business need and the result. And I've seen projects from the perspective of the person allocating resources to them and expecting a result in return.
When you put all these experiences together, you see very clearly the difference between what should work and what actually does.
The idea of sharing this experience was set aside back then, but not buried. It simply wasn't its time yet.
It kept maturing, because I kept noticing the same picture — whether I was working with vendors or with internal teams. At the start of a project, there's a lot of talk about how it will be managed.
Processes. Responsibilities. Stages. Risks. Documentation.
But quite often, behind these words there was no shared understanding of what exactly needed to be done, who had to do it, and — most importantly — why. That's when project management stopped being a tool for reaching a result, and became just another process to "get through."
In the summer of 2026, I decided there was nothing left to wait for.
I said goodbye to the comfortable life I'd spent years building while working at large companies, and turned this idea into my own new project.
A project whose purpose is to help companies manage their projects better. In practice, that means one simple tool — four questions we go through together on every project:
WHY are we doing this project, and what result do we need to get?
WHO is responsible for what, and who needs to be involved?
HOW will we plan the project, manage it, and make decisions?
WHEN do we need to reach the agreed result?
I believe good project management isn't about more documents. It's about people knowing what they're doing, why they're doing it, and how they'll reach the result together.
So today, I'm turning that experience into practice: training, consulting, and hands-on support for project teams — wherever theory alone isn't enough anymore.
I have the practice.
Now all that's left is to meet you.
Maybe the next project we save from running late will be yours.