Skip to content
Nearly every guide to choosing an SAP consultancy is written by firms who want the job. They tell you how to size up the implementer. Not one of them asks who is watching the implementer for you. These nine questions fix that.

 

The Backstory

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. But 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 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 looking at 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. A lack of a strong technical lead, or nobody single-handedly responsible 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 consider that accordingly. What makes it worth reading is that the causes came from the people who lived through it. Importantly, a lot of those are client side obligations - something it is almost impossible to contract out.

These nice questions are important and you should ask them of everyone. Including the firms calling themselves independent. Including us.

 

1. Are you independent of the systems integrator and of SAP?

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 and who builds it, or it does not. Most firms will tell you their interests match yours. Usually they do. The trouble is that one day they might not. Typically you will not get a warning.

We resolved this 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.

2. Who is accountable for the client side?

Name them. If you cannot name a person, your supplier is doing the job. A steering committee is not a name. Committees meet monthly to make key decisions. You need a named individual. Programmes go wrong on a Tuesday - not in neat timeframes.

3. Are we ready to hold everyone to account?

This one is about the client/supplier relationship and how things will be managed.

Most SAP programmes do not fail because a delivery partner 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. The delivery partner meanwhile, waits - politely and on the clock.

A good advisor will tell you where you are thin, and the impact it is having. If someone tells you your team is fine before they have met your team, that is not an assessment. That is a pitch.

4. Who protects when scope grows?

Firstly - scope will grow. That part is not in doubt - and in a lot of cases, rightly so (assuming the benefits of doing so make sense).

The question is who holds the line. If the delivery partner runs change control, every change they approve adds to their invoice. I am not accusing anybody of anything but you would not give a referees whistle to one of the teams and then expect a football match to be fair.

The scope, and its control, needs to be firmly owned by the client side team.

5. Who owns the data?

Data is where programmes tend to be impacted the most.

Horváth's executives put migration near the top of the list of things that go wrong. That should not shock anyone given how challenging the workstream can be. However, ownership belongs with the business, not the delivery partner. You need somebody on your side of the fence who can look at the quality numbers a fortnight before cutover and say 'this is not going to work'.

6. Who owns the benefits after go-live?

Six months on, the delivery partner has packed up and gone. Who is still answerable for the numbers in the business case? Most programmes decide that success means the system is running. Your board approved something else. They approved a return on the investment - and someone needs to ensure that is realised in your business.

7. Will the people who pitched actually deliver?

This is an all too familiar theme in large bids. Ensure you get the names of your team in writing. Ask what happens if they get moved to a bigger client in month four. A firm with two thousand consultants might only have two or three who really know your sector, and you need to understand if you are getting them consistently on your programme.

8. Who does assurance report to?

Follow the reporting line. 

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 resolved this 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.

Assurance needs to be independent. 

9. What happens when everyone leaves?

This is an increasingly important topic. As a general theme, you should finish your programme more capable than you started. Ask how that will be realised and what stays behind when they go. Generally speaking, if nobody has an answer, nobody planned one. You should insist on a capability uplift as part of your journey.

 

How to use these questions...

You should ask all nine questions to everyone you are considering working with. Including the firms calling themselves independent. Including us.

If a firm sails through all nine, they are answering the questions they rehearsed, potentially not the ones you asked. Slow them down and ask a follow-up. Be sure to understand the detail.

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 good at his job - but was simply 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

 

This, and other critical aspects, are covered in our guide - Start Right. It covers how to de-risk an ERP investment before implementation begins, including the readiness work most organisations skip. You can download a free copy via the following form.

Neil How

About the author

Neil How

Neil ran his first SAP transformation programme in his early twenties. He spent the next 21 years working both client side and for various consultancies running numerous SAP programmes. After successfully completing over 15 full lifecycles he took a senior leadership/board position and his work moved onto creating the same success for others.

More about Neil

© 2026 Limelight Consulting