Back in 2018, we released the SAP Success report with the intention of understanding why some SAP programmes are so much more successful than other - and what those successful few do differently.
We created the report by interviewing over 100 people and asking them questions about 15 key areas - we call them success levers - of the SAP projects they’ve worked on.
The research revealed some fascinating results:
- Only 36% of respondents felt their project kept to the delivery plan
- Fewer than 30% felt their project was delivered on budget
- And, fewer than half felt the project achieved its business objectives.
But it isn’t all doom and gloom.
There were some significant outliers in the respondents to the survey, so we reached out to them in a bid to discover why their SAP success scores were so exceptional.
In this series of articles, we get some rare insights into the traits of an uber successful SAP programme.
Our SAP superstar unfortunately has to remain anonymous… so we’ll just call them Bob.
In this instalment we talk planning, executive sponsorship, project management and PMO.
Let’s take a look.
Connecting SAP to the business strategy
Resulting: Thanks for joining us here today Bob. You’ve seen the results of our SAP Success Report 2018 and one of the first things you mentioned is planning and that it has to be a realistic plan.
Bob: Yes, and it has to be a living plan as well, and a visible plan. If you’re just looking at a Microsoft project plan with too much detail in it you can’t see the wood for the trees. If you can put it up a level so you can see it on one page everyone can relate to it.
R: So one of the questions we asked was “was your SAP programme fully connected to the business strategy?”. 64% of executives strongly agreed, however overall 50% of people we asked felt the SAP programme wasn’t strongly connected to the business strategy. What’s your opinion on that?
B: So that’s kind of a bad place to start. They’ve started on this project and the executives - not everyone - just the executives said this is going to deliver what we want it to deliver.
R: And it’s my concern as well that if only 64% of executives agreed, 36% of execs didn’t think their programme was going to deliver business objectives.
How to ensure executive sponsorship of your SAP project
R: Our next finding is that 45% of respondents felt they didn’t have executive sponsorship on their SAP projects. 73% of execs felt they did buy into SAP projects. What’s going wrong?
B: So they’re spending however many million on these projects and they haven’t got main board approval and full sponsorship.
R: But on the successful projects you’ve worked on, can you give us some examples of the executives displaying confident sponsorship?
B: Well there was clear messaging. There was clear engagement with the executive, regular feedback to the executive, feedback both up and down, regular reporting to the executive on the main deliverables of the project.
R: And what about the other way around - the execs sponsoring down to the programme. What are some good examples of that?
B: Being around, giving input to the project, giving clear messages to the project, giving sound bites back into the project.
The exec isn’t going to come along every 5 minutes, but they can give support and give sound bites of support back to the project to let you know that you’re on track and that you’ve got their continued support; that the project is aligning to the business strategy and it is important.
It can possibly even be things like communicating that message from an executive point of view and making sure that message is communicated right across the business. So that could mean posters up on every wall in every location telling you what the business objectives are with the executive’s sponsorship and their name on it.
R: So was it omnipresent then, the support of the senior execs?
B: Yeah it was - just by having that name on the posters around the building showing their sponsorship. For example it could say “this is going to make a vital difference to our business - chief exec”.
Embedding your business case for SAP
R: So another finding here, a similar one: 60% of respondents said their business case was not embedded in their SAP programme and therefore wasn’t fully realised. How can you stop this?
B: Again it’s poster on the wall stuff: What are you doing? Why are you doing it? The poster will say “this is the business case” and you know that’s why you’re doing it.
R: By Poster, I assume you mean all channels of communication. It’s about visibility?
B: Yes. You’ve got to constantly remind people of the business case even when their head is down in the weeds.
SAP PMO and Project Management
R: These next few findings are around project management and PMO. 62% of people didn’t feel their programme was supported by strong project management. And, amazingly 62% of project managers themselves felt the same.
B: They feel like they’re not getting the support from above.
R: Yes, and you need people who have done it before as well
B: Yes, I think that’s probably key in your recruitment process. You’re asking “how many of these SAP programmes have you been through before?” “How many successful ones have you been through?”. You’ll also need some unsuccessful ones under your belt too so you can understand what success looks like.
R: That’s the key to learning isn’t it - you learn by getting things wrong. Did the project lead on your successful project reflect and demonstrate some of those abilities and skills?
B: Our project leads changed over time, but our final project lead was a very talented individual.
R: Was it a business side project lead or was it an external?
B: They were an external consultant.
R: And not the systems integrator?
B: Not the systems integrator. They were independent of the systems integrator.
In my mind, the overall project leaders shouldn’t be someone from the systems integrator.
If they’re from the systems integrator they’re compromised because they can’t be making demands on their own organisation.
You need someone who is independent, who can make demands on the systems integrator, who can make demands back on your business as well, and who can bring the whole thing together.
R: It can be easy just to think “we’ll get someone who’s managed an internal project before” but there are some nuances with SAP, so you need someone who’s not just done things like this before, but who’s really done this before.
B: Yeah and who has worked in your particular industry perhaps so they can relate to what you’re trying to achieve and your particular requirements.
R: So here’s a related finding: 57% of respondents felt their project was not supported by a strong PMO. So did you feel you had a strong PMO?
B: Yes we had a strong PMO. It kept a lot of the burden of financial reporting away from you.
They would track the spend so you wouldn’t be lost in tracking that. They’d also manage some of the regular project management reporting.
It meant you weren’t dying by analysis of reporting. You could focus on what needed to be done and to take the project forward. They would also bring regular reports to you.
Another aspect of their role was recognition.
They would help manage recognition programmes that we wanted. They would ensure that there were regular team get togethers and regular social events for the whole team. For example you would have a team meeting and then you would go out for dinner in the evening.
They helped to make sure everyone understood where we were as a project, guiding us when we all needed to work together to get part of the project back on track, and celebrating the success or sharing the pain that we were going through.
If one team or perhaps two or three teams might be working at weekends because of particular demands towards the go live, the PMO would help us step up to the mark and support them.
They helped to bring the team together.
R: The analogy we use is that your PMO is like a referee. You never notice a good referee, but you will notice a bad one. PMOs are the same. With a good PMO things just happen; a bad PMO will cause friction and hassle.
B: They just manage all your resources for you. Say you need contracts extended; its all done for you and you don’t have to be wasting your time on that.
SAP Systems Integrators and Third Party Vendors
R: Here’s the next finding, when posed the statement “SAP programmes delivered successfully with the support of a suitable systems integrator with a strong cultural fit to the business”, 60% of respondents felt they weren’t supported by the Systems Integrator, and only 18% of executives felt that the systems integrator supported the project with a strong cultural fit. That’s less that 1 in 5.
B: So perhaps the benefit I saw on my project was that we had a very able systems integrator who was already experienced with the client, so they weren’t bringing in any new systems.
R: I think cultural fit is important too. If there’s not a cultural fit things just don’t get done. You see so many systems integrators where there isn’t a fit and they just throw anchors out of the boat all the time. They’re there to get their outcome, but they lose sight of the client’s outcome.
The next finding is 57% of respondents felt that they hadn’t secured the right balance of third party vendors. Within that, 63% of procurement people felt that they got the mix wrong.
B: So is that saying they brought too many consultants in or too many of the systems integrator do you think?
R: Well, I doubt it’s too many in house people. It’s either going to be too many contractors or too many third party consultants.
There’s this cliff edge thing which is you’re spending 10 million pound on an SAP implementation, but 90% of your workforce and 90% of the knowledge base resides in externals.
You hit go live and you go through the obligatory 6 weeks of warranty cover that most people will commercially build into their RFP and then you hit a cliff edge where they…
B: They walk away.
R: Yeah and knowledge vanishes. It’s really hard to transfer knowledge from a busy incumbent team who are trying to implement a solution and get it over the line.
B: Yes there’s no time for that knowledge transfer and the systems integrator’s probably not that interested in passing on that information either.
Knowledge Transfer on SAP Projects
R: What has your experience of knowledge transfer been?
B: So in here it was the systems integrator who would continue to support us after go live.
A lot of the people who had been doing the technical build or the technical development of the changes were going to be there supporting it, although in a much reduced team.
R: What about the business knowledge though? For example you can have somebody who logs a ticket because something’s wrong, but it can be wrong because it’s broken or it can be wrong because somebody doesn’t know whether to cancel an invoice and re-bill it or to credit it.
That business knowledge doesn’t transfer to a third party because it’s business knowledge.
B: I think because of the experience on the project they had picked up a lot of that business knowledge.
There’s also a problem seen at so many different organisations where those skills are just being released away and being outsourced which can be a great mistake.
If you let that business knowledge go how do you ever get it back?
R: That’s the worst of the worst isn’t it? You do a BPO and outsource your finance processing, apps management and your IT.
You end up with the users working for IBM, the IT support people working for Infosys, and your outsourced business process people are dependent on your outsourced IT people to do anything.
And you end up just sat watching from the sidelines.
B: And, you can’t do anything about it when things go wrong. As a business you can be left crying out for support desperate with lack of knowledge.
SAP Project Architecture
R: The next finding relates to the statement “architecture team had sufficient depth of knowledge to define a solution that was suitable". Of the general respondents this was roughly 50/50, but interesting only 60% of architects felt they had sufficient knowledge to do the job.
B: Well I can understand that because it’s so complicated. But, if you haven’t got the knowledge are you the right person for doing it?
Those architects have got to really understand the solution - the devil’s in the detail, and the devil’s in the detail for the data as well.
They’ve got to understand the architecture of the data, all the underlying systems, and all the different interface systems. Those architects have got to understand all the different interfaces that are coming in and out and be able to process and manage all that data behind it as well - it’s mightily scary and complicated.
R: Another interesting one for architects is this: “the SAP programme was an opportunity to standardise best practice rather than rebuild existing processes.”
Around half didn’t and half did agree, but interestingly 70% of executives thought they had standardised, so you’ve got this disparity where executives think they’ve standardised but on the ground they’ve not.
B: And then forever on you’re maintaining those customisations that you built. So the closer you can get to that standard solution the less you’re maintaining year on year and you know it’s going to work.
SAP Adoption Across the Business
R: Next one: “a high degree of emphasis was placed on adoption of the SAP solution throughout the programme”. 45% of our respondents said there was insufficient emphasis on business adoption.
B: So that’s kind of worrying as well because that’s surely all part of your change programme, your communications and your training, making sure that your business is ready to adopt your solution.
R: What kind of adoption strategies did you see on the programme you were on?
B: So, very clear communication from the executive of what the overall business goals were, a global training plan to embed those business goals, clear communication about what exactly was changing and when, and refresher training before and after the event.
R: What kind of training methods were used?
B: We had a very able training leader.
They used gamification during a lot of this training and then made sure people had learnt it and were tested on it. The training was also rewritten into local languages.
R: Which is key on a global role. You can’t assume just because you speak english…
B: Exactly. All the training had to be translated into local languages so that people could buy into it and support it, and it had to be delivered by local people as well.
R: So did they use the kind of training where its CBT (computer based training) and you’re forced to go through it in a process and click drop-downs or was it a little bit more snack at your own pace and understand?
B: So a proper training programme was run, and some of it was CBT but other parts were knowledge tested through fun on the way through the process. The whole thing was supported by real people; it wasn’t just CBT, it was real investment in real training and properly done.
R: Its interesting, a word i’ve not heard in the last 8 years or 9 years that I heard really early on in my careers was floor-walkers.
I’ve heard super-users, but you used to have floor-walkers, and i think as business has become more global floor-walkers are probably not a thing because collaboration tools have got in the way.
B: But having someone to support you on go live, hand-held support, you can’t beat it. And it’s only a small investment.
Data Migration and Data Maintenance in SAP
R: The next finding: Fewer than half of respondents said attention was paid to data migration and ongoing data maintenance.
B: From what i’ve seen every project struggles with data at some stage.
R: This had one of the biggest disparities of all the questions we asked. 82% of executives felt sufficient attention had been paid to data, but only 36% of business managers thought the same.
B: Data is always the scary part.
R: The thing with data is it’s easy to think it’s boring master data, but actually master data itself makes its way into transactions, and transactions make business processes slick.
Those transactions then fall into your analytics, provide dashboards and supports, and you make decisions on them.
So just one little master data error can propagate. Can you tell us a bit about data management on the projects you worked on?
B: You’ve got to be absolutely OCD about data, and it pays you back when you do. The devil is in the detail when it comes to data. One character in a fine country code can throw you out. You think you’ve covered everything but just be one character throws the whole lot.
R: What about the business case? Can you tell us a bit more about embedding the business case from the start?
B: Yeah absolutely do that and make it simple as well - don’t make it over complicated. It should be boiled down to a few bullet points that can go onto a chart that’s easy to understand. It shouldn't be half a page of business case.
R: So without giving away the strategy of the project you were involved in whats a similar kind of business case?
B: ”This SAP Programme will simplify our processing by standardising a particular way of working”.
R: And did you turn that into a metric to be measured? Or was it more of a statement of direction?
B: It was more “this is what we’re going to do”. Then thats turned into the architecture, which is implemented into testing, then the build and then trained into people as to how it would work. Post go live it can be tested and assessed.
R: So its about getting the why in people’s minds as well as the what and the how?
B: Yeah, and keep it simple.
The most important factors to SAP success
R: Now, we’re going to take a look at the most important factors in determining SAP success and look at the difference between the top and the bottom respondents.
When it comes to savvy vendor management, the top half of respondents were 20% better on average, and the bottom half were 17% worse. Is it just about being clever about the way you contract and choose your SI?
B: And managing change as well on the way through. If you’re throwing a lot of change into your project you’ll find your costs are going up and that catches people by surprise.
R: Solution standardisation had a huge effect on success rates. The top half of performers on average performed 29% better when asked if they implemented a standardised solution.
B: The people who haven’t gone for a standardised solution and have customised their SAP are forever going to be maintaining a custom solution.
R: Yes, once you decide it you’re locked in. When you go heavily customised you’re done.
B: You’re stuck with that forever aren’t you and that’s your business expectations set as well.
R: After all if you think about it SAP is a big box of business processes that will run any business. SAP will run a bank, a utility company, a CPG company, so the only things that should be different from standard are the things that give you a competitive edge.
One of the hardest things to do is to get architects, executives and business managers to make really hard decisions and say “I know we’ve always done it like that, but if we do it this way it works out of the box, it costs less and it’s easier to use”.
So the project you worked on was that rationalisation and striving for standardisation, or were you looking for data standardisation?
B: Both.
It was making sure we used the same sort of templates across all the different parts of the company, and then when new parts of the company were being adopted or changed bringing them all into the fold and using exactly the same sort of data models.
We’d also cleanse the data at the same time. There was a lot of data standardisation as well as moving to standard processes in the organisation.
R: Finally the number one lever to success was this: high adoption focus. The top half of respondents were on average 43% better when it came to high adoption focus, and the bottom half of respondents were 25% worse.
B: So this again is managing the change, communicating it, and providing training on it.
Advice From The Best of The Best
R: So, thinking about the programme you worked on, what would you say made the difference and led you to having a successful project?
B: I would think good clear communication of what the business case was, and keeping an eye on that business case; making sure it flows all the way through every component of the project.
You also need clear project management with a clear structured plan on a page that everyone can see and buy into. You need clear architecture that aligns to the business plan, and you need to make sure the data is aligned to the business plan.
Finally, you need to manage the people. Do the good thing and motivate the people, look after the team and make sure you’re continually engaging the team and bringing them along with you.
R: I think the point around stress is a big one. Recognising that these projects are stressful and that you need to proactively manage stress within teams. After all people don’t come to work to make mistakes, they make mistakes because of stress.
B: If you manage that side of things by making sure people are enjoying what they’re doing, they’re not going to walk away from the project.
And if they’re enjoying it they’re communicating as well.
If people are under stress that’s the time when they shut down. If they’re feeling blamed they’re not sharing the information. If they’re having fun and sharing then they’ll come to meetings and the team will engage, so you’ve got to keep that team engagement going.
See how your SAP project matches up
Perhaps you’re working on an SAP project right now and you want to know how you match up to these best practices.
Well we can help.
