Draft for Tamir's review. Not published.
Put both sides on one record
Collect the logs, records and decisions from both sides for the same period, and align them on one timeline. For an outage, find the first failing event and the system that produced it. Then compare each side's written root cause against the timeline.
A long delay leaves a paper trail. The change log shows who changed requirements and when, and the decision log shows what waited on whom. When a supplier blames your staff or your data, test the claim under the conditions the contract specified, with the supplier present.
Read what the contract says
Check which contract carries the obligation, what it excludes, and what it says about acceptance, configuration and cooperation on incidents. Ask the vendor for the advice it says it gave, with dates and recipients. A data quality claim is testable when you measure the fields the work needs, rather than a general score.
Keep the fix apart from the dispute. Restore what worked before while responsibility is settled, and keep maintenance and support on their own track. Put the weekly cost of the problem in a number in front of both sides.
Depending on your seat
If you're the CEO, decide on the next three months rather than on the past year: what can ship or be fixed, with whom, by when. Act on the finding rather than on the louder side.
If you're on the board, the question moves to management. Ask what management did to select, contract and oversee the vendors, and what it changed after each failure. Vendor failures that recur under the same contracts are management's. When founders blame each other, get an independent read of what is built, what is left and where decisions waited.
What to check before you decide
- Collect both sides' logs and records for the same period and align them on one timeline.
- Find the first failing event in each incident, and the system or step that produced it.
- Ask for the requirement changes with dates and approvers, and the decisions that waited more than a month.
- Ask each side for its root cause in writing, and compare both against the timeline.
- Read the contracts for the obligation, its exclusions, acceptance, and the duty to cooperate on incidents.
- Test the vendor's claim under contract conditions, with the vendor present, and record the result.
- Put the weekly cost of the problem in a number in front of both sides.
Questions people ask
Our operator paid penalties for system failures and management blames vendors, how does the board judge whether management is in control?
Ask what management did to select, contract and oversee the vendors, and what it changed after each failure; vendor failures that recur under the same contracts are management's. Ask for a plan with measures the board can follow. It depends on whether the contracts give management the tools to hold vendors to account and on whether it used them.
Our startup's product is late and the CEO and CTO blame each other, how does the board find out what's really wrong?
Get an independent read of the engineering state: what is built, what is left, whether the plan is realistic for the team, and where decisions have waited. That separates engineering problems from leadership problems. Then act on the finding rather than on the louder founder. It depends on what the read shows and on how many months of runway remain.
Our new automated line runs far below the promised output and the supplier blames our staff, how do I find the truth?
Run a controlled test with the supplier's own engineers present, your best crew and the materials the contract specified, and measure output against the promise. The result settles who owns the gap. It depends on what the contract said about materials, staffing and acceptance, and on whether acceptance was ever formally done.
Our app is a year late and my CIO and the vendor blame each other, how do I find out who is right and what to do?
Get the change log and the decision log, because a year of delay leaves a paper trail that shows who changed what and who decided late. Then decide on the next three months rather than on the past year: what can ship, with whom, by when. It depends on whether the delay came from requirements changes, vendor delivery or decisions nobody made.
ERP go live is next month, plant manager says not ready, CIO says go, how do I decide?
Ask for evidence rather than opinions: has a full order been run through the new system end to end, with real products, by the people who will do it on day one? If yes, go with support on the floor; if no, the date is a guess. It depends on whether the readiness gap is training, data or missing functions, and on what the season allows.
Fraud losses went up after our new fraud system and the vendor blames configuration, how do I find out what went wrong?
Compare the fraud cases of the last months with the system's rules and alerts, because that shows whether the system saw the fraud and nobody acted, or never saw it at all. Then read the implementation record for who was supposed to configure what. It depends on whether the losses come from new fraud types or from fraud the old system caught and the new one does not.
We were fined for wrong data in our reports to the authority and the vendor says its data was correct, how do we stop this recurring?
Trace one report from the source systems to the authority's file and find where the numbers change; the error usually enters in a join, a mapping or a manual step nobody owns. Then assign an owner for the report's data path. It depends on how many systems feed the report and on whether the authority's definitions match your data.
Our EV charging platform keeps going down and the platform and charger vendors blame each other, how do I find out who is right?
Get the logs from both sides for the same minutes and have someone with no stake read them, because each vendor only shows the half that clears them. Then check which contract carries the availability obligation and what it excludes. It depends on whether the outages share a cause and on what each contract promises.
AML system implementation stalled, vendor blames our data quality, how do I know if that's true and what to do?
Measure the data against the specific fields the rules need rather than against a general quality score. Most rule sets can start on a subset of customers and products where the data is good enough. It depends on which fields the critical rules use and on how the regulator views a phased start.
How I can help with this decision
- Ask or talk (Free)
- I give my view on how to build the one record that ends the blame exchange, and which contract clause decides who owes what.
- Review (Pay if it was worth it)
- I write an independent assessment of what happened, each side's performance and the contract position. I recommend remedies, any change to vendor, scope or oversight, and the position to take with the vendor.
- Retain (When it makes sense)
- I stay close through the remedy period to review the fixes and the next results against what was agreed.