My first ERP programme nearly sank. I was on the client side, fairly junior, and watching something go wrong that nobody seemed willing to name. We got it back. It took months we did not have and money nobody had planned for.
What I remember most is not the recovery. It is how long it took anyone to say the word "trouble" out loud. The people closest to the build knew. They were also the people being paid to build it.
That is the problem this article is about.
Search for advice on picking an SAP consultancy and you will find plenty. Check the certifications. Ask about industry experience. Meet the team. Call the references. All fine, as far as it goes. Notice who wrote it, though. Almost all of it comes from systems integrators and SAP partners.
It is a bit like asking the estate agent whether now is a good time to buy.
So here is the question nobody in that pile asks. If the firm building your programme is also the firm reporting on it, where does the bad news come from?
The National Audit Office has been circling this for years. Its 2021 review of digital change in government found twenty-five years of underperformance, and traced most of it back to decisions made before anyone picked a technology. Its work on shared services says it plainer. No strong technical lead. Nobody single-handedly on the hook for delivery.
Horváth asked two hundred S/4HANA executives the same thing in 2025 and got the same answer. Scope crept. Programme management was weak. Data migration was underestimated. Three-quarters said nobody thought hard about staffing before the work began. Horváth sell transformation services, so weigh it accordingly. What makes it worth reading is that the causes came from the people who lived through it.
Look at that list again. Scope. Governance. Staffing. Decisions.
Every one of them is on your side of the table.
Ask this first. The answer tells you how much to trust everything else they say.
Independence is not a feeling. It is a structure. Either a firm makes money from which software you buy, who builds it and how long it takes, or it does not. Most firms with a stake will tell you their interests match yours. Usually they do. The trouble is the one day they do not, and you will not get a warning.
We sorted this out elsewhere decades ago. Sarbanes-Oxley made it illegal for your auditor to also build your financial systems. The Financial Reporting Council stops auditors here taking any part in management decisions. Nobody treats those rules as an insult to auditors. They exist because structure beats good intentions.
Listen for the firm that sells you the conflict as a benefit. "We implement too, so we understand delivery from the inside." True. Also the point.
Name them.
If you cannot name a person, your supplier is doing the job. A steering committee is not a name. Committees meet monthly. Programmes go wrong on a Tuesday.
This one is about you. Ask it anyway and watch what they do with it.
Most SAP programmes do not fail because the SI could not build it. They fail because the client could not keep up. Decisions stack up. Workshops slip because your best people are doing the day job. Data cleansing never starts. And the delivery partner waits, politely, on the clock.
A good advisor will tell you where you are thin, even when it costs them the warm glow of the first meeting. If someone tells you your team is fine before they have met your team, that is not an assessment. That is a pitch.
It will grow. That part is not in doubt.
The question is who holds the whistle. If the delivery partner runs change control, every change they approve adds to their invoice. I am not accusing anybody of anything. I am pointing out that you have given the referee's whistle to one of the teams and asked them to be fair.
Data is where programmes stop.
Horváth's executives put migration near the top of the list of things they got wrong, which will shock nobody who has done one. Ownership belongs with the business that made the mess in the first place. Not the delivery partner. Not a workstream reporting to the delivery partner. You need somebody on your side who can look at the quality numbers a fortnight before cutover and say no.
You will see some terrifying statistics about data migration failure. I went looking for the source of a few of them and could not find one, so I am not going to repeat them here. The people who have actually done it say it was harder than they planned. That will do.
Six months on, the delivery partner has packed up and gone. Who is still answerable for the numbers in the business case?
Most programmes quietly decide that success means the system is running. Your board approved something else. They approved a return.
The SI guides do ask this one, and fair play to them.
Get names. Get their availability in writing. Ask what happens if they get moved to a bigger client in month four. A firm with two thousand consultants might have three who really know your sector, and their tier status will not tell you whether you are getting them.
Follow the line. That is the whole test.
Assurance only works if the people doing it can hand you bad news without it costing them money. The Institute of Internal Auditors says plainly that a function should not assure work it was recently responsible for. The Infrastructure and Projects Authority runs independent reviews of major government programmes for exactly this reason.
Construction worked this out years ago. The owner's representative acts for the client, reports to the client, and takes nothing from the contractor. You would not let the main contractor act as your own representative on a building site. In SAP we do it every week and call it partnership.
You should finish this more capable than you started. Ask how. Ask what stays behind when they go.
If nobody has an answer, nobody planned one.
Ask all nine of everyone. Including the firms calling themselves independent. Including us.
Two of these are awkward for Limelight to answer, which is rather the point. If a firm sails through all nine, they are answering the questions they rehearsed, not the ones you asked. Slow them down and ask a follow-up.
Questions three and nine are the ones almost nobody asks. In my experience they tell you more about the next three years than anything on a certification list.
I have seen what this costs when it goes wrong. I once sat opposite a CFO who broke down in front of me, worried about his job and what the programme was doing to his home life. He was not a weak man. He had simply been left carrying something nobody else would pick up.
That is what these nine questions are really for.
You can see where we did this successfully here - Case Studies