LKPU Blog - LKPU Consulting Consulting Insights and Publications

In our blog, we write about the topics that genuinely matter in our projects. About things that do not quite fit together, questions without easy answers, and problems that are often ignored for a little too long.

We take a closer look, challenge familiar assumptions, and share what we learn along the way. We write from practical experience and with the ambition to call things what they are. Not every observation is comfortable – but that is often exactly where its value lies. For people and teams who want to truly understand how things connect and make well-founded decisions.

The org chart looks excellent.
Every box is aligned. Everyone has a manager.
There is just one problem.
Work rarely respects boxes.
An org chart answers one important question:

Who reports to whom?

It does not tell you who actually performs the work.
It does not show which skills are required.
It does not reveal capacity bottlenecks, duplicated responsibilities or critical dependencies.
And it certainly does not explain why that one urgent task always ends up with Bas.

Org charts create a reassuring sense of order because they visualise hierarchy. But organisations are not trees. They are networks of work, responsibility, skills, capacity and dependencies.

Two departments may sit far apart on the organisational chart while depending on each other every day.
Two people may have identical job titles while performing entirely different work.
And a position may appear perfectly staffed even though the person occupying it does not have the skills the work requires.
The org chart is therefore not wrong.
It is simply incomplete.
A more useful view connects three questions:

What needs to be done?
Processes and tasks.

Who should do it?
Structures, roles and positions.

Who can actually do it?
People, skills and capacity.

Connect those three perspectives and you begin to see the real organisation.
Until then, you mostly know who reports to whom.
Useful.
But not quite enough.

Author: Anna-Lena Appel

If your organisation only works because Bas knows who to call, you don’t have an operating model.

Bas knows the organization. Not the org chart. The real organization. He knows who can make decisions, who actually fixes problems and who is best left off the email chain. Useful. Until Bas isn’t there. Most organizations have a Bas. Bas does not just know his job. He knows the shortcuts, exceptions and unofficial responsibilities. When a process gets stuck, Bas knows who to call. When two departments cannot agree, Bas knows someone who knows someone. And when a task officially belongs to Team A but has quietly been handled by Team B for the past three years, Bas knows that too.
Convenient.
And slightly worrying.
Because what looks like experience and collaboration may actually mean that a significant part of the organisation exists only in people’s heads. The org chart tells you who reports to whom. Process documentation tells you how things are supposed to work. Job descriptions tell you what people are theoretically responsible for. Bas knows what really happens. Then Bas goes on holiday.
“Who normally does this?”
“I thought Finance owned it.”
“No, Operations does that.”
“Ask Bas.”
A robust operating model should not depend on individual employees compensating for gaps in the organisation. It should make visible what work needs to be done, which roles and positions are responsible, which skills are required and whether enough capacity actually exists. That does not mean eliminating informal collaboration. Good organisations need people who connect the dots. But those people should improve the system, not replace it.
The interesting question is therefore not:
“Who knows how this works?”
It is:
“Would it still work if that person disappeared tomorrow?” If the answer is no, you have just learned something important about your organisation. FIRM GROUND® focuses precisely on these connections: processes, structures, tasks, skills and people are viewed as one connected organisational model. Bas can stay. He just shouldn’t have to know everything.

Author: Michael Nolte

Congratulations. Your process works. As long as Bas isn’t on holiday.

The process looked excellent. Twelve boxes. Six arrows. Three approvals. Even a legend. There was probably a file called Version_4.2_final_FINAL. Then Bas took two weeks off. It turned out that step six only works because Bas manually corrects a spreadsheet every Thursday. Step eight depends on somebody remembering that Client A is treated differently. And the approval in step ten belongs to a role whose owner changed four months ago. The documented process was correct. Reality had simply failed to read the documentation. This happens when processes are designed in isolation. A process is not just a sequence of activities. Every activity requires responsibility, skills, capacity, information and often technology. Remove one of those elements and the process diagram may still look perfect. The process just stops working.
So the better question is not:
“Is the process documented?”
It is:
“Is the process organisationally supported?”

Who performs each task?
Is accountability clear?
Are the required skills available?
Is there enough capacity?
What happens during absence, growth or organisational change?
A robust process survives holidays.
A fragile one has Bas.
And a spreadsheet.

Author: Jan Koppetsch

Banking is becoming invisible. The organisation behind it cannot.

Banking is increasingly disappearing from view. Payments, financing and authentication are becoming part of journeys customers barely want to think about. Behind the scenes, however, things are becoming more complex. Product, Payments, Fraud, Risk, Operations, Technology and external providers all need to work together seamlessly. That creates an interesting challenge: the more invisible banking becomes, the clearer end-to-end ownership needs to be. Who decides when something goes wrong? Who owns the journey? And who sets priorities when customer experience, risk and regulation compete?

Banking can become invisible. Responsibility cannot.

Author: Abtin Maghrour

Banks do not have a strategy problem. They have an execution window.

AI, Instant Payments, Open Banking, new platforms, new regulation: banks generally know which topics matter. The harder question is how quickly they can turn decisions into reality. Because strategy eventually meets legacy systems, limited budgets, provider dependencies, regulatory programmes and scarce specialist capacity. Competitive advantage may therefore depend less on having the right idea first — and more on executing a good decision quickly and well. The more relevant board-level question may be:

Which of today’s right decisions can we actually implement fast enough?

Author: Jan Koppetsch

“Project status: on track.” That is not necessarily good news.

Critical projects rarely fail overnight. Decisions get postponed. Deadlines move. New requirements enter the scope. Risks travel from one steering committee to the next. And yet the status report often remains green or amber for surprisingly long. The problem is simple: activity is not the same as progress. A proper project rescue starts with a realistic view of the situation. What is genuinely finished? Which decisions are missing? Which assumptions are no longer valid? Where is scope still growing?

A project does not need to be red to already be in trouble.

Author: Johannes Rotter

You do not rescue a project by making the plan look better.

When a project comes under pressure, the first reaction is often to replan. More detail. New milestones. More reporting. But a better schedule does not resolve unclear decisions, growing scope or missing ownership. Project rescue starts with different questions:

What do we really need to deliver?
What cannot be delivered at the same time?
Who decides?
What needs to leave the scope?
What needs to happen now?

A good rescue plan may initially look worse than the old one because it exposes risks and corrects unrealistic assumptions.

A project is not rescued when the plan turns green again. It is rescued when the plan becomes deliverable again.

Author: Jan Koppetsch

What clients really buy in critical projects: clarity.

Consulting is often described through frameworks, methodologies and workshops. In critical situations, clients frequently need something simpler:

Clarity. What is the real problem? What options do we have? Which decision needs to be made now? And who takes ownership afterwards? Good consulting is therefore not about making complexity look impressive. It is about reducing complexity until action becomes possible.

What do we know?
What do we not know?
What matters now?
What can wait?

Explaining complexity is easy. Making it decision-ready is the real work.

Author: Jan Koppetsch

More fraud prevention does not automatically make payments safer.

Fraud prevention is supposed to prevent fraud. Sounds straightforward. In practice, a system can become so restrictive that legitimate customers are constantly blocked as well. Risk may decrease, but false positives, abandoned purchases and complaints increase. The better question is therefore not:

How many transactions do we stop? But: How well do we distinguish legitimate transactions from fraudulent ones?

That requires Fraud, Payments, Risk, Operations and Technology to work together.

Good fraud prevention does not stop as much as possible. It makes the right decision as often as possible.

Author: Abtin Maghrour