Your project has not moved in months. Someone has to go in and find out why.
A stranded migration. A build that keeps stretching. A supplier who no longer gives clear answers. I step in, find out what is really happening — with the code, with the people and with the contract — and tell you what can be done. Even if the answer is to stop.
First call, 30 minutes, no cost. If the problem is not the one you think it is, I would rather tell you before invoicing you for anything.
What a stalled project looks like from the inside
There is almost never a day when the project stops. It slows to a halt. These are the signs usually on the table when someone calls me.
- The delivery date has moved more than twice, and the last time nobody even asked why.
- Progress meetings have turned into justification meetings.
- The supplier answers in technical language when you ask about deadlines, and in commercial language when you ask about technical problems.
- There are tickets open from six months ago that nobody closes and nobody deletes, because closing them would mean admitting they will not be done.
- Every new feature breaks something else, and fixing what is broken now takes longer than building what is new.
- The budget is at 80% and the project, by feel, is at half.
- The internal team and the supplier only speak through the project manager, and each has their own version of why this is going badly.
- You have already thought about changing supplier, but a reasonable doubt holds you back: what if the new one arrives, looks at this and says the same thing.
If you recognised four or more, you do not have an execution problem. You have an information problem: nobody on the inside can give you a neutral account of what is happening, because they are all part of it.
And if the project is moving but what you do not control is who is doing it, before changing it is worth knowing what broke: technical vendor management.
The problem is not always technical. It is almost never entirely technical.
When a project stalls, the first instinct is to look for a technical culprit: the code is bad, the platform cannot cope, the developer is not good enough. Sometimes that is true. But in most of the stalled projects I have seen, the technical part was the symptom, not the cause.
Technical blockage
The platform has a real limitation, there is technical debt in the way, or an architecture decision made three years ago means every change costs three times as much. It is the only one fixed by writing code. It is also the rarest in its pure form.
Operational blockage
Work arrives from five different places, nobody decides what comes first, and the technical team prioritises by order of arrival or order of insistence. The code is fine. The process is not. This is not fixed with more developers: it is fixed by putting someone in charge of deciding.
Decision blockage
There is a pending decision nobody wants to make, usually because it is expensive, uncomfortable or political. While it goes unmade, the team keeps working on things that do not depend on it, so the project looks like it is moving. It is not: it is warming up the waiting room.
All three look the same from outside: a project that does not arrive. They are treated in completely different ways. And that is why the first job is never to fix anything, but to find out which of the three you have.
What I do when I step in
There is no template. There is an order, and it starts by listening to everyone before touching anything.
I listen to all three versions
Business, technical team and supplier. Separately. Each has a coherent version of why the project is going badly, and none of the three is complete. The real picture lives in the contradictions between them.
I look at the real state, not the reported one
The repository, the commit history, the tickets, the environments, the deployments, the integrations. Not to judge the code, but to know whether what is said in the progress meeting matches what actually happened.
I read the contract and the estimates
What was committed, with what scope, and what has been added along the way without renegotiating anything. A huge share of stalled projects are stalled right here, and nobody has looked.
I separate the three blockages
What is technical, what is operational and what is a decision that has been waiting for months. Named explicitly: which decision, who has to make it, and what gets unblocked when they do.
I tell you what I would do
Not a list of options. A recommendation, with what it costs, how long it takes and what is lost by doing it. And what happens if nothing is done.
I stay until it moves
If you want. I can hand over the analysis and leave, or stay to coordinate execution with your team and your suppliers. We decide that after the analysis, not before.
What you take away
Short documents you can put in front of a board without translating them.
- A situation report
- What is happening, in business language, with the evidence behind it. Including the part you will not enjoy reading.
- The three blockages, separated
- Which part of the jam is technical, which part is operational and which decisions are still pending. With owners.
- A prioritised action plan
- What gets done first, what gets done later and what does not get done. With the approximate cost and the risk of each line.
- An explicit recommendation
- Continue, reorder, cut scope, renegotiate, change supplier or stop. One of the six. Argued.
And if I stay: coordination of the execution, technical liaison with the suppliers, and a periodic progress report you can read in five minutes.
When it makes sense to call me
- When the project has not moved in months and the explanations no longer convince you.
- When you suspect the supplier, but have no way to contrast what they tell you.
- When you are about to change agency and want to know what you take with you and what you leave behind.
- When the budget is draining and you need to decide whether to keep investing or cut.
- When the internal and external teams blame each other and there is nobody neutral in the room.
- When the migration is half done and going back is no longer free.
- When you yourself doubt whether the problem is yours: how it was asked for, how it was decided, how it was governed.
When I am not the right person
- If what you need is hands
- If you know exactly what has to be built, who will build it and in what order, and all you lack is development capacity, hire developers or an agency. I would be expensive for that.
- If you have already decided and just want someone to sign off
- If the decision is made and what you need is an external report to back it, I am not your option. I might look at the same thing and reach a different conclusion.
- If the problem is product or market
- If the project is not moving because nobody is clear who it is for or what it should do, that is not technical leadership. It is a different conversation, and there are better people than me to have it.
- If nobody inside wants this looked at
- A rescue needs access: to the code, to the people and to the contracts. If that door is closed by internal politics, the work cannot be done properly, and I would rather not start it.
- If the urgency is today for tomorrow
- Really understanding a situation takes days, not hours. If you need an answer this afternoon, the responsible answer is that I cannot give you one.
A rescue does not always end in a rescue
Nobody hires this to be told to stop. But sometimes that is the conclusion, and saying it is part of the job. These are the six possible endings, and I have seen all of them.
Unblock
There was a concrete obstacle — a decision, a dependency, a person — and it is removed. The project starts moving almost on its own.
Reorder
The work was fine, the order was not. It gets replanned and what would have taken six more months ships in two, with fewer things in it.
Cut scope
The project is viable, but not the project that was signed. What does not add value gets cut and what does gets delivered.
Renegotiate
The problem is in the contract: open scope, estimates that no longer hold, badly placed incentives. You sit down with the supplier and rebuild it.
Change supplier
Sometimes, yes. But with a handover plan, knowing what is recovered and what is lost, and not in the heat of a bad meeting.
Stop
The project no longer makes sense, or finishing it will cost more than the value it will return. Stopping in time is the decision that saves the most money and the one least often taken, because nobody wants to be the one to propose it. I can be the one who proposes it.
What will not happen is that I tell you everything is fine so I can keep invoicing, or that I tell you everything is broken so I can sell you a rebuild.
How the scope gets defined
On the first call I do not close a price or a timeline. I have not seen the project, and estimating without having seen it would not be serious: what a rescue, a due diligence or external technical leadership costs depends on the real state of the system, on what access exists, on how many suppliers are involved, on what documentation there is, and on how urgent it is.
- 01
A first call to understand the situation
Thirty minutes, no cost. You tell me what is going on, I ask questions, and I come out knowing whether I can help and what kind of work fits.
- 02
If it fits, an initial review of the context
I take a first look at whatever exists: documentation, access, contracts, who is involved. This is where the real size of the problem becomes visible.
- 03
Definition of the scope
What is in, what is out, what dependencies exist and what can be left aside without the work losing its point.
- 04
A written proposal
With scope, price, timeline and deliverables. No open ranges: a proposal you can compare and defend.
- 05
We start only if we both approve it
If the proposal does not convince you, no harm done and you have paid nothing. If it does not convince me, I say so first.
I would rather look careful than look fast. A quote given in thirty minutes, without having looked at anything, gets broken by week three.
Tell me what is stuck.
You explain the situation, I tell you what I see from the outside and what I would do if it were my project. If that conversation shows you do not need me, I say so right there and you will have lost nothing but half an hour.
You tell me what is happening and since when.
I tell you whether this smells like a technical, operational or decision blockage.
If it fits, we define an initial scope and a closed proposal reaches you before anything starts.
What people ask me before we start
How is this different from a technical audit?
A technical audit looks at the state of the system and tells you about it. A rescue looks at the state of the system, the organisation and the contract, and then stays to move things. The audit answers «what state is this in». The rescue answers «what do we do now». And if what you are about to do is buy or invest, the question is a different one: the technical due diligence.
Are you going to tell my supplier they are doing it wrong?
I do not come in to assign blame, I come in to find out what is happening. In many cases the supplier is doing exactly what was asked of them, and the problem is what was asked. When there really is a supplier problem, I say so with evidence and in private, to you first.
Do I need to give you access to the code?
Yes, read access at least. Also to the tickets and the people. Without that I can give you an opinion, but not a diagnosis, and I do not want to charge you for an opinion.
How long does it take?
I do not know before looking, and be wary of anyone who tells you in half an hour. It depends on the size of the project, on how many people have to be heard and on what documentation exists. On the first call I understand the situation; if I see I can help, I tell you what information I need to prepare a proposal with a closed scope and timeline.
And if you tell me to stop the project?
Then you will have paid for an analysis in order to stop paying for a project. It is usually the best ratio between what it costs and what it saves of everything I do.
Do you work with my team or replace it?
I work with it. I am not here to take anyone's job, and if the analysis shows there are too many or too few people, that is a recommendation to you, not an offer from me.
Can you rescue a project on a platform you do not know?
The three types of blockage are the same in any stack, and two of the three are not technical. If the blockage turns out to be purely technical and in a technology I do not master, I will say so and find someone who does. Where I have covered the most ground is eCommerce: Magento, Shopify and BigCommerce.