Will you tell us to fire our vendor?

Only if that's genuinely the answer, and it often isn't. Most failing projects have a structural cause rather than an incompetent supplier, and replacing the supplier inside the same structure reproduces the failure.

Can we buy just the assessment?

Yes, and plenty do. Fixed price, one to three weeks, written independently. You can act on it with us, with your existing vendor, or with someone else entirely.

Will our vendor cooperate?

Usually, once it's clear the assessment isn't a prelude to blame. We ask for access and conversation, not a defence. Vendors are generally as stuck as you are and often relieved.

What if the answer is to stop?

Then we say so, in writing, with the reasoning. Sunk cost is the most expensive argument in this category and someone independent has to be willing to name it.

AliveCommerce / Capabilities / Recover a failing project

Recover a failing project

Past deadline, past budget, and every status update sounds like the last one. The hardest part isn't the technical problem. It's that everyone involved now has a position to defend, which makes an honest picture of where things stand almost impossible to get from the inside.

Does this sound like you?

Tick what applies. The count changes what we'd recommend, and sometimes the recommendation is to do nothing yet.

What's actually causing it.

Almost never carelessness. Usually the predictable result of a decision that made sense at the time.

Scope was agreed before it was understood

Both sides signed something neither fully understood, in good faith. Discovery then finds the real requirements, and the commercial structure has no room for them.

The commercial model punished honesty

Under a fixed scope, raising a problem costs the vendor money and costs you time. So problems surface late, when they're expensive, rather than early when they're cheap.

Nobody owned the whole picture

Your side owned requirements, theirs owned delivery, and the space between — integration, data, change, adoption — belonged to nobody until it became the reason for the delay.

What we do about it.

In this order, because doing them out of order is how these projects fail.

Establish where things actually stand

Independently, in writing, with no interest in the answer. What's built, what works, what's salvageable, and what the remaining options genuinely cost.

Say whether to continue

Sometimes the recommendation is to stop, or to keep the current vendor with a different structure. We're not trying to inherit the project — we're trying to give you a decision you can defend.

Stabilise before adding

Nothing new gets built until what exists is understood and working. Adding to an unstable base is how recoveries become second failures.

Change the structure, not just the team

If the commercial model caused the failure, replacing the vendor inside the same model reproduces it. Usually the fix is how the work is bought, not who does it.

Assessment

1 to 3 weeks

Independent, written, fixed price

Common outcome

Keep the vendor

With a different structure and clearer ownership

Most common trigger

A third missed date

Or a board asking a direct question

Which way in.

Same team either way. The difference is whether this has an ending.

A defined project

AliveCommerce

Assessment first, recovery second, as separate decisions. You can buy the assessment and take it elsewhere — that happens and it's fine.

Project recovery

Continuous ownership

Champion1

When the recovery is really a support problem. We take over products whose vendor has gone dark or whose developer has left, and keep them running.

Product recovery

What it looks like in practice.

Construction · 95 staff · 6 weeks

A two-year implementation with no end in sight

The assessment recommended keeping the vendor and changing the contract. Both sides agreed within a fortnight, which surprised everyone including us.

6 wks

to a signed reset

Straight answers.

Related.

These tend to travel together.

Replace a legacy system“It still works. Nobody left knows how.”Take software off my plate“Nobody owns the stack. Everyone owns a piece of it.”Connect systems that don't talk“An export, an import, and a spreadsheet in between.”

Tell us what's breaking.

We'll tell you which part of this we'd put on it, roughly what it costs, and whether it's worth doing at all — including when the honest answer is that you don't need us.

Start the Conversation

Knowledge and process

Applications and data

Customer and web

Browse by symptom instead

The structure

Continuous ownership

Before you commit

Start with one problem

Priority sectors

Also

Or by situation

Not sure you fit?

Reading

Most read

Proof

Nobody owns the application layer