Mattias Ejbe, welcome to Ready, Set, Goal. For those who don’t know you, who are you?
Thanks for having me. I’m Mattias Ejbe a civil engineer with around 30 years of experience leading infrastructure and IT projects. I work as a project manager, I’m IPMA certified, and I also host a podcast in Sweden about project management. That’s me in short.
Why are you so passionate about project management?
Because I love solving hard problems. In line organisations, you often improve existing processes, but in project management you work with new challenges. If something were easy, it would already be handled in the line organisation. When it’s difficult, you need to bring people together and solve it. That’s what I love.
Why is project management such a critical capability in organisations? What problems does it solve?
Organisations rarely fail because of bad ideas. They fail because of poor execution. Project management is the discipline that turns strategy into delivered value. It helps solve the chaos many companies quietly live with: missed deadlines, unclear responsibilities, wasted money, and teams that are not aligned.
How would you explain project management to a 12-year-old?
Imagine that you and your friends decide to build a treehouse. Someone has to figure out what wood you need, who will hammer, who will climb, and when it all needs to be done. Someone also needs to check that it’s safe and that everyone is still working toward the same goal. That person is the project manager. Project management is simply how you turn a good idea into something real, together.
So the goal is the treehouse, it needs to be delivered on time, and someone needs to know who does what and by when. That’s basically project management?
Yes, exactly. And you also need agreement on the timeline. One person may think it needs to be done before summer, another before the rain starts. You need to discuss that and make it clear, maybe even document it.
If management says something has to be finished in two hours, but people don’t agree, who makes the final decision?
If management are the project sponsors, they make the final decision. But if they say, “This must be done in two hours,” then the answer is: fine, but what part of the scope do you want to remove? It always comes back to time, cost, and scope. If they want more scope, they need to give more time or more money. If they want less time, they need to reduce the scope.
From your experience, what separates successful projects from failed ones?
One word: clarity. I’ve reviewed failed projects, and many of them had goals on paper, but not shared goals. Different people understood the goals differently. Some projects even had multiple sponsors with different agendas. Successful projects have a clear purpose, clear scope, and clear roles. Failed projects often collapse because of assumptions that were never discussed or documented.
This is music to my ears. How should companies think about goal-setting in projects?
It’s not really different from goal-setting in the line organisation. Again, it’s about clarity. The line organisation should define the effect goals, what they want to achieve. Then the project sets the project goals: how it will deliver something that helps achieve those effect goals. Everything needs to connect.
I work with a customer using OKRs in a specific project. In your world, is that basically the same thing, just with different words?
Yes, I think it’s mostly different wording. In project management, especially in standards, you often talk about effect goals and project goals. But it’s very similar. The important thing is knowing whether you are talking about the bigger outcome you want to create or the specific delivery that contributes to it. It’s the same logic, just named differently.
How much should you measure in a project?
You should always measure, because measurement is how you learn. You set goals, you try to achieve them, and then you evaluate what happened. Why did you succeed? Why didn’t you? That learning helps you improve the next project. So goals should be written and documented in a measurable way. They can still be ambitious, but they need to be measurable.
If a company works with OKRs and also has many projects, how can OKRs and project management coexist?
I think they fit together beautifully. OKRs give the business direction. They define the “why” and the “what.” Projects are the vehicles that deliver the “how” and the “when.” A key result like reducing churn by 15 percent is only an ambition until you either handle it in the line organisation or launch a project to achieve it. That’s where project management comes in.
In OKR, we often work with three objectives, three key results under each one, and then three initiatives. How many projects can a company run at the same time?
I’ve seen organisations try to run a hundred projects at once with only a couple of sponsors overseeing them. That does not work. The more projects you have, the more structure you need, like a PMO. But in general, fewer is better. It is better to run fewer projects over shorter periods, let them deliver, and then start new ones.
So fewer is better?
Yes. Fewer is better.
Where do projects fit in the OKR structure? Objective, key result or initiative?
You’re more of the OKR expert than I am, but from my side the most important thing is to avoid double reporting. I really dislike situations where we report the same thing in OKR meetings and then again in project steering meetings. That creates bureaucracy instead of alignment. So I don’t think the exact placement is the main issue. The important thing is not to track the same work in multiple places and not to turn OKRs into a task list.
In large organisations, OKRs may live in spreadsheets or slides, while project work lives in Jira or another tool. How do we avoid bureaucracy and double counting?
By reporting in one place as much as possible. If a team already reports in the project structure, they should not have to do the same reporting again somewhere else. Maybe the OKRs only need to be updated every quarter, while the day-to-day follow-up happens inside the project. We do this to achieve results, not to create more reporting. Follow-up matters, but too much follow-up in too many places becomes a burden.
This is really interesting. It should support the business, not create more admin. Any final advice for the listeners Mattias?
Make the portfolio visible. Put it on a wall, in Teams, or wherever people can see what is ongoing and what is not. Be ready to close projects that are not working. Many organisations have zombie projects that no one really owns anymore, but they keep consuming money. Sometimes you need to say: this was not the right idea, let’s stop it and use the remaining resources elsewhere. A PMO can be very helpful for this. And again: clarity matters. From my perspective, OKRs sit above the projects. Projects are simply one way of delivering on the OKRs.
This feels like the start of a much bigger conversation. Maybe next time we can bring in questions from customers and listeners and go deeper into OKRs and project management together?
I’d love that. I also have a lot to learn from your side of this, because I receive goals and then run projects, but I’m very interested in how those goals were chosen in the first place, how the OKRs were set, and how they were aligned across the organisation. That’s often where the real challenge begins.
More questions already. But yes, let’s do that next time. We’ll gather input from the listeners and record a second episode.
Thanks a lot for having me here.
