Retainer vs. Project Business: What Actually Pays Off

I'm against project-based consulting in the classical sense. That's a strong statement, I know. But I think it's right.

The classic model looks like this: You have a problem, you write an RFP, my quote is 50,000 euros for six months. We sign a contract with exact scope. I deliver something. Project ends. Invoice paid. Goodbye.

The problem with this model is fundamental. It optimizes for the wrong things.

The Problem with Projects

When I work as a consultant against the clock – when the project ends in six months – then I optimize for one thing: fulfilling the scope. Not for the best solution. For the solution that fits the scope.

That leads to weird decisions. A solution that works today but creates problems tomorrow? Not my problem anymore. A feature you don't really need but is in the scope? Gets built. A feature you actually need but isn't in the scope? Doesn't get built.

For you it's even worse: After the project, you're alone. The consultant is gone. Your knowledge about the system sits in documentation. Which is either incomplete or incomprehensible. If something breaks, you need to find someone new. They don't know the system. It takes weeks to understand it.

That's inefficient and expensive.

Even worse: When I jump between projects, I forget your problems. I work three months for you, three months for someone else. Then I'm back with you. But the specific requirements of your company? Gone from my head.

The Bigger Point: Knowledge Loss

Projects lead to massive knowledge loss. That's a giant problem.

The system runs. It works. But only the person who built it really understands why it works that way. What decisions were made? What alternatives were rejected? Why?

That's documented somewhere. Maybe. Or maybe not.

A year later: Your team needs a change. They write a new project spec. A new consultant comes. They have to understand the entire system first. That costs time. That costs money. That leads to worse decisions because the new consultant doesn't understand why the system was built that way.

This happens repeatedly. With every new project. Every time you lose knowledge.

That's the economics of consulting: The more new projects, the better for the consulting firm. The more fragmented your knowledge, the more new projects you need.

That's a perverse incentive structure.

The Retainer Model: A Different Way

My model is different. I work with you on a retainer basis. That means: 8, 16, 24, or 40 hours per month. It's regular. It's predictable.

What's the difference?

First: I'm continuously involved. I don't forget your problems. I understand the evolution of your company. When your requirements change, I adapt the solution – not because a new project demands it, but because it makes sense.

Second: I optimize for the right outcome. Not for scope, but for your success. If a feature is garbage, we say so. If another is critical, we build it – even if it wasn't planned.

Third: Knowledge stays. I'm in your systems. I know the architecture. If something breaks, I'm there. Not in a week. Immediately.

Fourth: Your procurement department is on vacation. Not to be mean, but: Every new project means an RFP. Write the spec. Get three quotes. Compare. Negotiate. Sign contracts. That costs you time and money. With a retainer? Sign once. Then it runs.

For Me: Predictability

For me, this model has advantages too. I like predictability. With retainer clients, I know my income. I plan over months. I invest in the client. I read into their industry. I build real expertise.

That's the opposite of: Project after project, constantly changing requirements, always context-switching.

Retainer clients are more attractive to me. That's why I'm better for them. I can concentrate. I can think long-term.

This Isn't a Support Contract

This is important: A retainer isn't a "maintenance contract" with me as a support hotline.

It's a real partnership. We sit together and think: How can your system get better? What optimizations make sense? What technical debt do we pay down? Where do we still have problems?

That's active co-design. Not reactive repair.

A good example: An energy company with an old balancing group management system. The system works. But it's slow. The user interface is cryptic. Three months of retainer with me: I analyze the system, identify the real problems, clean it up. Not because it's a separate project, but because it's part of my monthly work.

That's better for you. Better systems. Better decisions. Less overhead.

The Uncomfortable Truth

Big consulting firms love project business. The more projects, the more revenue. The more fragmented your knowledge, the more new projects you need.

That's rational for them. For you? Not so much.

I believe in retainers because it's the right structure for real improvement. Not for maximizing consulting revenue.

That doesn't mean: Never do projects. Sometimes you need a big project. That's okay. But it should be the exception. The rule should be: Continuous improvement. Regular reviews. A partner who knows your systems.

---

You're looking for someone who supports you long-term, not jumping from project to project? Let me show you a retainer model that makes sense for both of us.

Let's talk →