Three attempts produced no result because the project had no process and no owner, and that kind of fault is hard to see from the inside.
Over seven years, Elisa had tried three times to get the same project through. Every attempt ended the same way: there was next to nothing to show for it.
The project was to automate server patching in the server hosting services for business customers. A machine already applied the patches, and still the workload grew.
I came in as an outsider, after three attempts had already been made. My job was to find out why the project would not finish. The answer was not the one that had been looked for until then.
Three attempts, the same pattern
I do not know the course of the earlier attempts in detail, and I do not need to. What they had in common was that each had started with a purchase or an installation, and after that everyone waited for the thing to start working by itself.
The pattern is common: a project starts with a purchase, and a purchase is easy to record as progress. Buying a system or a device is not enough on its own, though. A process for how it is used still has to be built around it, and that part does not come in the box.
The project had no process that would say what happens next and who does it. It had no owner. It had no team whose job it was.
When nothing moved, people looked for the fault in what already existed.
Why nobody asked the right question
When something that has been bought or installed does not work, people see the fault from where they sit. One person sees a people or management problem, another a technical one, a third sees the cause somewhere else. Every reading makes sense where it is made. I do not know exactly what each earlier attempt fixed. More likely they failed earlier, at the point where everyone had their own idea of the cause and a shared one never formed. That is not an easy situation for an outsider either: when you hear three credible explanations, it is hard to judge which one is true. What the explanations had in common was that each pointed somewhere else. What was missing was outside everyone's view.
The automation had been bought and it ran the patches. Its results were still followed up by hand on every round. The machine did the execution and a person did the follow-up, and partly automated work was heavier than fully manual work, because the workload stayed and the responsibility blurred. The word “automated” meant different things to different people, and each of them was right from their own desk.
A technical question is a convenient question. It has an answer, you can hand it to someone as a task and tick it off as done. “Who owns this?” is more awkward. Asking it means someone says out loud that nobody has been responsible, and usually the person who would have to say it has a stake in the project. The question goes unasked, and the reason is not malice.
A missing structure also gives no error message. A broken component can be turned into a ticket. A missing process cannot, because it is nowhere. It shows only in the fact that nothing moves forward, and even that looks like a technical delay: waiting for the environment, waiting for a decision.
The structure also rewarded manual work. Manual follow-up showed up as work done. Removing it showed up nowhere. Management saw a report, not a view into the work: it knew the patches had been run, but not what was done around them. When visibility is missing, the picture of the situation is not wrong, just murky, and in the murk everyone sees the fault somewhere else. So it was here too, at first. In the end there was something to improve at every point in the chain, and that is not an accusation. That is what happens to a structure in which nobody sees the whole.
This is not a story about bad people. When the tool already exists, the natural question is why it does not work. The rarer question is what is missing around it. There was nothing wrong with the tool. No standard process had been built around it to bring faults into view. An outsider can ask that question, because they have no earlier attempt of their own to defend and none of the earlier attempts' assumptions behind them.
A diagnosis in a month and a half
I started by going through the situation. I interviewed the people who had been involved in the project and worked out what had gone wrong.
An interview reveals what documents do not, because a missing structure does not show in documents. A document tells you what exists, not what is missing. When you ask a person what they expected someone else to do, the gaps start to show.
The diagnosis took a month and a half. Its core was simple: a process and ownership were missing. The technology was not the problem.
Then I built what was missing. I wrote a process in which every step had a named role. Even the step where someone decides what to do when something fails got a role. On top of that I made the plans, the technical plans and the full documentation.
The structure was four decisions. The standard model is made once per platform, before the first customer, not customer by customer. The method has one owner and every customer account has one owner: a fault in the method belongs to the team, a fault in the customer's environment to the specialist. Every deviation from the standard model is logged with its cause, owner and date, so the same fault does not come back a third time. And the follow-up moved from the production team to the round-the-clock service desk: the night shift's task is written as lines in a runbook, and everything else waits for the morning as a ticket.
The most important single change was still the smallest. Before, a fault that blocked the automation stayed known only to the person who worked around it by hand, and on the next round they worked around it again. Now every fault that blocks the automation lands with two parties: the team that owns the method, and the customer in whose environment the fault is. When both see the same list, the environment gets fixed together, and the cycle ends. The automation did not need new technology. It needed the faults to become visible to the right people.
The pilot customer went live within two months, and in under three months there was a finished plan for bringing the remaining customer accounts under the same process. In this project too, I could have stretched it out for myself by more months. I said plainly that the rest should go to someone who is better at scheduling and task tracking, and more motivated to do it.
Ownership here means one thing: there is a person you can ask why the project has not moved, and whose job it is to get it moving. Ownership needs no title and no new organisation chart. It is enough that the name is written down and that the person knows they are in that role. A process means that when one step is done, it is known who does the next one.
A named role is a small thing and a decisive one. It means that when a step does not start, there is one name to ask. Without it, every step is everyone's responsibility, which is to say nobody's.
What I left behind was a structure: who owns what, which process runs it, and what has to exist before the work can be finished.
What happened
The project moved on to implementation. The first customer account went into production in October 2026, and responsibility for driving the project passed to a named project manager. The model holds without me, and that was the intention.
Reaching implementation is what none of the three earlier attempts managed. It is a result you can check.
Before that, the project had only ever been attempted. Now it had a process in which every step had a name and someone to do it.
If you have a project that has failed once or more, ask two things before the next attempt: who owns it, and what process drives it. If you have no answer, the next fix will most likely land in the wrong place too.
If this sounds familiar, send me a message. We start with the diagnosis.