Sep 1, 2026 · 12 min read
Is This Project Failing Because of the Vendor, or Because of Us?
Four questions that tell you whose problem it is, the two numbers that decide what you do about it, and how to report any of it to a board you answer to.
You are six months into a project that was supposed to take four. The vendor says they are blocked waiting on you. Your team says the vendor is slow. Both sides are being polite about it and neither is moving.
You cannot referee this, because everything either side tells you sounds plausible and you have no way to check it. So the decision drifts, and drifting is expensive in a way that never appears on an invoice.
Four questions will tell you whose problem it is inside a week. Two numbers will tell you what to do about it. Do the questions first.
The short answer
It is almost always both, and your half is usually the larger half.
I find this nearly every time, and vendors are rarely as bad as they look from inside a struggling project. Your half is the only half you control, it is cheaper to fix, and fixing it is the only way to find out how bad the vendor actually is. While you are the bottleneck, their performance cannot be measured.
1. Who is waiting on whom?
Do this: take the last five things that slipped and write down what each one was waiting on. From the emails, not from memory, because memory hands you the loudest argument of the month rather than the pattern.
Why it decides things: this is the only measurement that separates the two stories, and it takes an afternoon. Almost everything else in this situation is opinion.
If three or more were waiting on you, on a decision, a file, an answer, a person who was on leave, you do not have a vendor problem yet. You may also have one. You cannot see it from here.
One warning. Those emails are usually in the inbox of whoever has been dealing with the vendor, so asking them to compile the evidence log feels like an audit of them. Say what it is for first, and do the reading yourself if you can.
2. Has what you are building changed since you signed?
Do this: put the original scope next to what is being built now and list the differences. Then, for each one, ask the vendor a question you can understand the answer to: did you flag this as a change at the time, or did you absorb it?
Why it decides things: do not try to price these yourself. You hired a vendor because you cannot, and their estimate of their own scope creep is not an independent number. The pattern is readable without any pricing. Changes they flagged and you approved are yours. Changes they absorbed silently are theirs, and a vendor who absorbs eleven of them and then presents the delay as a mystery has told you how they run projects.
Scope change is the most expensive cause and the most invisible, because it never arrives as a decision. It arrives as eleven reasonable requests over five months, each taking a minute to ask for and a week to build.
3. Can one person say yes?
Do this: name the person who can approve a decision on this project without asking anybody else.
Why it decides things: your decision cadence is a hard ceiling on delivery speed, and it is arithmetic rather than opinion. A group meeting monthly can make twelve decisions a year. A project like this needs thirty. The gap does not close because everybody is working hard.
If the honest answer is that nobody can, that is not avoidance and I would not treat it as one. In a nonprofit or an association it is usually a governance question, and the fix is a written delegation up to a stated figure, which the board has to pass. That is a three-week job and worth starting now whatever else you decide.
4. Are you being told things you do not understand, or things that do not add up?
Do this: take the same emails from question 1 and make one column. Month, and the reason given that month. Read it top to bottom.
Why it decides things: no single reason will look wrong, because each one was plausible when it arrived. The finding is in the sequence. A vendor who gave you four different accounts of the same delay has not lied at any point, and has still told you the thing you needed to know.
Things you do not understand are a translation failure. The vendor is probably competent and definitely talking to the wrong audience, which is fixable in one conversation and reasonable to ask for. Things that do not add up across the column are the only finding here that can end a contract on its own.
Reading the four together
| What you found | Whose problem | What it costs to fix |
|---|---|---|
| Mostly waiting on you | Yours | A fortnight of attention |
| Changes you approved | Yours | A conversation about money |
| Changes they absorbed silently | Theirs | A repriced plan, in writing |
| No single decision maker | Yours | A written delegation |
| Reasons that do not hold | Theirs | Possibly the contract |
Three of the five are usually yours. That is not letting vendors off. It is what the last five delays say when somebody finally writes them down.
The two numbers that decide more than the four questions do
This is the part most of these articles leave out, and it is the part your finance committee will actually ask about.
What you have already spent is gone. It is gone whether you continue or walk away, so it should carry no weight at all. Somebody will say we have spent this much and have nothing to show for it, and mean it as an argument for continuing, or for stopping, depending on who they are. It is neither. The only live question is what the remaining money buys.
What you have not paid yet is your leverage, and it is the only leverage you have. Three things to establish first, none of them technical, all answerable by your solicitor in a day.
- What is left to pay, and what is it tied to? If payments were tied to milestones that were not met, you are in a stronger position than you feel.
- Who owns the code and the data if this ends today? Get it in writing. It changes what walking away costs, and people are surprised in both directions.
- What does the termination clause require? Notice and handover obligations decide whether leaving takes a fortnight or a quarter.
A conversation where you know these answers goes differently from one where you do not, and vendors can tell which one they are in.
The distinction that matters more than late
Late is what everybody is arguing about and it is rarely the real risk.
A project that is late and building the right thing is a scheduling problem. Annoying, survivable, ends with working software. A project that is on time and building the wrong thing looks healthier in every status report and is much worse, because nobody escalates green dates. You find out at go-live, when the staff who have to use it tell you it does not match how they work.
So ask one more question alongside the four: when did somebody who will actually use this thing last see it? If the answer is longer than a month, that is your most serious problem, and it is not the one you were worried about.
The two cases where you should leave, and the one that catches neither
Switching vendors mid-project costs more than people expect and resets knowledge that was expensive to build. So I am cautious about this.
They cannot show you working software. Not a design, not a prototype, not a plan. If a project is six months in and there is nothing you can click, the plan is not late, it is fictional.
You have been given the same explanation twice. Everyone deserves a bad quarter. Nobody deserves two identical accounts of the same bad quarter, three months apart, with nothing having changed in between.
Both miss the fluent vendor. They ship something you can click, they never repeat a reason because they always have a fresh one, and they are pleasant throughout. That is why question 4 is a column rather than an impression. If every reason differs and the date has moved four times, the pattern is the finding, and it deserves the same weight as a repeated excuse.
What to do in the next two weeks
- The delay list, from the emails. An afternoon.
- The scope differences, and which ones they flagged at the time. Half a day.
- The reasons column. Same emails, one page.
- The three contract questions, put to your solicitor. A day of their time and cheaper than a week of yours.
- The thing in front of two people who will use it. Not a demo. Let them try to do their job with it and watch what happens.
- A working session rather than a status call. Bring the delay list and go through it without blame. Most vendors are visibly relieved when a client does this, because they have been carrying the list alone.
Then fix your half, renegotiate the scope, or leave. In that order of likelihood.
If you have to report this before you have fixed anything
Six weeks of fixing your side is the honest remedy, and boards do not always meet six weeks from now.
If yours meets sooner, do not walk in with “it turns out most of this is our fault.” That is true, and said plainly to people who hold you accountable it stops being a diagnosis and becomes a weapon, usually in the hands of whoever was already unhappy. The conversation then leaves the software entirely.
Say the same thing in the form it actually takes. We have identified a small number of constraints on our side. Here is what each one costs us in weeks. We are fixing them, and here is the date by which the vendor’s performance becomes measurable for the first time.
Then add the two things that turn a request for time into a test with a result.
What continuing to that date costs, and what you are holding back until you get there. A date with no money attached is not reassurance, it is a deferred ambush, and the next meeting will be worse because people will feel they were not told. Say what the next six weeks will spend and what remains unpaid at the end of it.
What happens if the date passes and nothing has changed. Terminate, withhold the balance, or escalate above the account manager. Name it in advance. A board hearing “give us until October” from somebody already four months late will hear a delay tactic unless the consequence is on the table with it.
Then ask for the date rather than a verdict. That is the part that matters most, because a finance committee cannot decide whether a system is salvageable and knows it, which is exactly why somebody in the room keeps reaching for walking away. It is the only decision available to them. Give them one they are competent to make.
And have the sunk cost sentence ready, because somebody will say we have spent this much and have nothing to show for it. The answer is that the money is gone whichever way the room votes tonight, and the only question on the table is what the remainder buys.
Bring your solicitor’s three answers with you as well. If you price the continuing option and not the leaving one, the people who want to leave will notice, and they will be right to. Walking away has a number too, and you look considerably more credible recommending one path when you can say what the other one costs.
The person nobody is asking
Somebody in your organisation has quietly become the translation layer on this project. They answer the vendor’s questions, chase the files, sit in every call, and explain your organisation to strangers over and over. Usually a programme manager or an operations lead, and usually it was never in their job description.
They know which of the four answers is true, and have known for months. They have probably not said it plainly, because it would sound like criticism of a decision somebody senior made, and because they are the one holding it together. Ask them on their own, and make it easy to be honest. “If this goes badly, what will we say the reason was?” That gets a better answer than any status report, and it costs nothing.
If it turns out they have been absorbing a job nobody assigned them, fix that whatever happens to the project. People burn out on unnamed work much faster than on hard work.
Most struggling projects can be saved, and most are saved by the client changing something rather than the vendor. If you are earlier than this and still choosing, I wrote separately about evaluating a proposal when you are not technical and about whether to build at all.
If you want somebody technical working for you rather than for the vendor, that is what a technology assessment is, and I can sit inside a project you have already committed to and hold the vendor to what they promised. The useful thing about that seat is not the technical knowledge. It is that I can say the uncomfortable half out loud, to your board if it helps, without it costing you anything politically.