Skip to content

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.

Holiday

Bas knows the organisation. Not the org chart. The real organisation. 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 organisations 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.

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