A project that won't finish? I find what's missing.
The project has a budget, a tool and people, and still it doesn't move. What holds it in place is rarely a technical fault: usually an owner, a process or a decision is missing, and nobody has made it. I find it, write it down, and build what is missing. I work alongside your own IT, not instead of it.
Book 15 min: tell me the situation, get a price →Do you recognize these situations?
A project that won't move
Two steps, the same person
Diagnosis first. It is scoped and fixed-price, and its result is yours. Only after that do we decide whether I build what is missing, or you do it yourselves.
Diagnosis: what holds the project in place
I interview the people involved and go through the situation, because a missing structure does not show up in documents. I name what is missing: an owner, a process, a decision, or a dependency nobody carries.
The result is a written structure. Who owns what, which process runs it, and what has to exist before the work can finish. Typically four to six weeks.
See an example →I build what is missing
A process with a named role for every step. An owner for everything that had none. And the ugly dependency nobody wanted to carry: the firewall opening, the access handover, the responsibility if the automation fails.
I prove the solution once. The first customer or unit into production, and a plan for bringing the rest under the same structure. You replicate the rest yourselves.
See an example →Diagnosis in practice
An example from an engagement where three earlier attempts had ended the same way:
The project that had failed three times
A large Finnish company had tried to deliver the same project three times. Each attempt ended the same way: next to nothing to show for it. I came in as an outsider, with three attempts already behind them, to find out why the project would not finish.
I don't know the earlier attempts in detail. What they had in common was that each began with a purchase or a setup, and then everyone waited for it to start working by itself. When nothing moved, the fault was looked for in what existed. What was missing was in nobody's field of view, and a missing process does not raise an error.
I interviewed the people involved, because a missing structure does not show up in documents. The diagnosis took a month and a half, and its core was simple: the project had no process and no owner. Technology was not the problem. I wrote the process with a named role for every step, including the step where you decide what happens when something fails. The project moved on to implementation.
Moving on to implementation is what the three earlier attempts never reached. That is a result you can check.
The part nobody wanted to carry
A structure does not come from drawing it. Usually a project has one dependency nobody wants to own, and that is where it stands still.
Ticket work that should never have existed
Access rights were granted one ticket at a time: a person read the request, interpreted it, made the change and closed the ticket. Several person-years of work, and the metric was ticket throughput time. That metric does not ask whether the ticket should exist at all.
I built a pipeline from the form to the end, so the request was structured from the start and the interpretation step was no longer needed. The technical part was teamwork. My part was what nobody wanted: the firewall openings from another department that was in no hurry, and the promise that if the automation failed, the responsibility was mine. Without that, the pipeline would never have started.
Several employees' worth of manual work disappeared. The project was not stuck on technology, but on nobody carrying the ugly part.
How it proceeds
First a call, then a price in writing, then the diagnosis. Building is a separate decision you make after the diagnosis.
A 15-minute call
You tell me what the project is and where it stands. I say straight whether I see something I can take hold of, or whether you need someone else.
A price in writing
I scope the diagnosis and give a fixed price before anything starts. It holds.
Diagnosis, four to six weeks
Interviews, a walk through the situation, and a written structure: who owns what, which process runs it, and what has to exist. We go through it together.
Build it, if you want
A single project I take all the way. If the same thing has to be repeated dozens of times, I build the structure, prove it once in production, and the repetition passes to your own person with the plan.
Why me?
I don't represent any vendor and I don't resell anything, so I have no earlier attempt to defend and no product to sell. An outsider can ask the question that is hard to ask from inside: who owns this?
My projects finish because I build a structure that carries without me. That is the point. If you want a 50-page explanation of why something is hard, don't call me.
Why me
Independent
No commissions, no reselling. I recommend what works, not what I get paid for.
Direct
I tell you straight what's wrong and who owns it. Also when that is uncomfortable.
A builder
I leave behind a process and owners, not slides. The structure carries without me.
Experienced
Projects from SMEs to large Finnish organizations, from hospitals to insurance. The same gap recurs regardless of size.
FAQ
Do you drive the project to the finish?
A single project, yes. I have driven a 220-workstation refresh in two weeks, an M365 rollout and a 60,000-document migration to the finish. When the same thing has to be repeated dozens of times, as in the example above, I build the structure and prove it once, and someone better suited than me runs the repetition. I say so out loud.
We have our own IT and a project office.
All the better. I work alongside, not instead: you have the people, I bring what is missing in between, meaning the owners, the process, and an outsider who is allowed to tell management what is hard to say from inside.
What if the project hasn't started yet?
Is there a project coming that must not fail? The same diagnosis before the start costs a fraction of what a restart costs. We look at who owns it, which process runs it, and what has to exist before the first step.
What does it cost?
The price is agreed in a 15-minute call once I know the scope, and you get it in writing before anything starts. The diagnosis is fixed-price. Building is priced separately, only after the diagnosis.
How large an organization?
From a 50-person company with one IT person to a large Finnish corporation. The example above is corporate scale. The problem is the same regardless of size: a missing owner and a missing process.
What do we end up with?
A written structure: who owns what, which process runs it, and what has to exist before the work can finish. If I build, also a proven pilot and a plan for the rest. No slides.
Let's talk.
Tell me where the project stands. I respond within 24 hours.