Tech-agnostic consultancy, practical delivery

Turn operational noise into working systems.

I help SMEs, managers, and Product Owners choose, implement, and run practical workflows, tools, reporting, and delivery routines without forcing a specific platform.

Signals

The problem is rarely effort. It is usually system leakage.

Fix these before adding another meeting, dashboard, tool, or optimistic status update.

Signal 01

The team is busy, but control is unclear

People are moving tasks, attending meetings, and sending updates, but the next decision, current blocker, and real delivery confidence are hard to see.

Signal 02

The process lives in memory

Delivery depends on side conversations, follow-up messages, and someone manually reconstructing the latest version of reality.

Signal 03

The tools exist, but the system does not

CRMs, workspace suites, boards, dashboards, and documents may already be available, but ownership and workflow logic are still weak.

Explore further

Choose the next page based on what you need to prove.

Recognise the use case, inspect the resources, then check the recommendation evidence.

Operating loop

Design the work before selecting the software.

Tools, dashboards, and automations are useful only after the underlying operating model is clean enough to implement.

Phase 01

Map the real work

Start with the workflow people actually use, not the process diagram everyone politely ignores.

Phase 02

Expose the value leaks

Find where time, decisions, quality, data, and accountability leave the system.

Phase 03

Design the control layer

Define ownership, cadence, escalation rules, decision points, artefacts, tool logic, and reporting rules before changing the stack.

Phase 04

Ship, teach, adjust

Implement in short cycles, train the team on the live system, and tune the setup until it is usable.

Evidence examples

The goal is not prettier process. The goal is less drag.

These are examples of measurable operational drag this work is designed to reduce. The exact target depends on the workflow, baseline, and team capacity.

Example target: reduce recurring preparation work from several hours to a repeatable, lower-friction routine.

Example target: improve planned-vs-delivered reliability by making intake, commitments, and review cadence explicit.

Example target: reduce KPI and status-reporting effort by moving from manual assembly to dashboard-supported management routines.

Read the evidence layer
Kristóf is the kind of project management professional who doesn't just manage projects, he improves the systems, frameworks, and capabilities that enable organisations to deliver change more effectively.

Ferenc Havas

Head of Project Management Office (PMO), Profession.hu

He introduced an estimation methodology that not only helped developers give more accurate estimates, but also made planning significantly more predictable for the product side. That kind of cross-functional thinking is hard to find.

Eszter Somogyi-Vass

B2C Product Management Lead, Profession.hu (now Interior Designer at intereszti.design)

Fit check

This is not for every team. That is the point.

You need practical operating structure, not a motivational workshop.

You have a repeated delivery, reporting, workflow, or ownership problem.

People are compensating with meetings, manual admin, side messages, or spreadsheet workarounds.

You want a system the team can run after the first session ends.

FAQ

Questions worth answering before the call.

Is this project management training?+

Not in the traditional classroom sense. These are practical working sessions.

We use project management, agile delivery, business analysis, and communication principles, but the focus is your real project and the next useful steps.

Who is this best suited for?+

Managers, Product Owners, project leads, delivery leads, and small teams who want a clearer way to plan, communicate, make decisions, and keep delivery moving without adding unnecessary process.

Do we need to be using agile already?+

No. Agile experience is helpful, but not required.

The session is based on the way your team actually works today. The aim is to make the operating rhythm clearer, whether your environment is agile, hybrid, or mostly traditional project delivery.

What should I bring to a session?+

Bring the current project context: goals, timeline, known risks, stakeholders, team setup, open decisions, and any plan or roadmap you already use.

It does not need to be polished. In fact, unpolished is often more useful.

Will you tell us exactly what framework to use?+

Only if that is genuinely useful.

I do not start by forcing a framework onto the work. I start with what needs to succeed, then help shape the lightest practical structure around planning, ownership, communication, and follow-up.

What do we leave with?+

You leave with a clearer view of the delivery situation, practical improvement points, and a written next-step plan.

The output is designed to be usable immediately, not filed away in a folder called 'strategic alignment'.

Can this help before a project starts?+

Yes. That is often the best time.

A short preparation session before kickoff can clarify assumptions, risks, ownership, communication rhythm, and decision points before the team starts moving.

Can this help an active project?+

Yes, as long as the aim is to improve the operating rhythm and prepare the next steps.

The session is not about blame or drama. It is about making the work easier to lead from where it is now.

Start practical

Show me the messy workflow. I will show you where control is leaking.

Use the first conversation to decide whether the problem needs project preparation, delivery stabilisation, ongoing fractional project management, digital operations cleanup, tool selection, workflow implementation, or a deeper operating-model review.