A few tips & trick to avoid failing with SAP Program/Projects – Part 1

Publish date:

Most project managers are well familiar with Cobb’s Paradox. Martin Cobb was serving as CIO for the Secretariat of the Treasury Board of Canada in 1995 when he phrased the question “If we know why project’s fail and we know how to prevent their failure, why do they still fail?” I believe the Cobb’s paradox […]

Most project managers are well familiar with Cobb’s Paradox. Martin Cobb was serving as CIO for the Secretariat of the Treasury Board of Canada in 1995 when he phrased the question “If we know why project’s fail and we know how to prevent their failure, why do they still fail?” I believe the Cobb’s paradox is still valid in the IT-business in general and for SAP-projects in particular.
We still read about ERP-projects with severe overruns, missed deadlines and with quality issues after go live. According to a research provided by Gartner1) in the beginning of 2015 as many as 41% of all SAP implementations were late according to their original time schedule and 31% were over budget and 21% didn’t deliver all the business benefits that were stated in the business case. The input to this study comes from the yearly Gartner Magic quadrant survey so I believe the providers have selected the some of their best clients so the result could be even worse.
In this Blog, I will introduce 10 SAP project best practices gathered from my own experiences acting as project manager and in other advisory roles in larger SAP programs over the last 20 years. This week I start with the first 5 best practices.

Best Practice #1 – Make sure the project and program is lead by people with experience from running successful ERP-projects/programs

It is no doubt that an ERP-project is one of the most complex IT-projects to run, where current core business processes and IT-processes not only are to be replaced but also to be extended to the next level of user experience, business process excellence and information transparency. Very often the IT-system to be replaced is a completely custom built application that has been enhanced for 30 years or in some cases even more.
Far too many experiences are learned the hard way with project and program managers without any previous experience in running a multimillion ERP-project. Normal businesses don’t focus in running ERP-projects; they are in the business because they normally are good at something else. An ERP-project is one of the most challenging tasks with a very transparent end result.  In order to master this kind of challenges you need to make sure that the operational management is staffed with people with several years in managing ERP-programs. I would not even consider a very skilled general project manager without specific experience from running an ERP-program to qualify.

Best Practice #2 – Don’t start from scratch – start with already pre-configured solutions

Your implementation project does not need to start from scratch. A lot of the business processes are well established industry standard processes where you don’t need to design the processes but rather should accept the best practice processes already provided from pre-configured solutions like the SAP Business all in One solutions (the Capgemini intellectual property MFGPath) or from the SAP Rapid deployment solutions. When doing so, you can free up time to be spent on designing processes that really makes a difference. The initial configuration of SAP S/4HANA is based on already pre-configured solutions providing ready-to run business processes with sample data that will mark the starting point for an implementation.

Best Practice #3 – The Project Preparation phase is there to set the foundation for a successful project, so make sure you use the time carefully!

A SAP project is like an oil tanker. It takes time to get it up to speed and it’s hard to turn it around as soon as it is up to speed. That’s why the project needs to get started quickly, but even more important is to get the most basics right from the beginning. Many of the well established SI’s of today have their own start-up kit (like the Rapid Start from Capgemini) that brings in standards, accelerators, templates, follow-up routines right from the beginning. All these kind of standards and guidelines are documented in the Program Governance Plan (PGP). Just make sure that the PGP becomes the operational steering document and not a document just there to provide a “tick” in a check-box in order to get through a toll gate.
Standards bring often minds into thoughts around bureaucracy, but the fact is that without standards and structure the overhead tends to be even heavier.

Best Practice #4 – Make sure you get stakeholder and end-user involvement early and use CRPs

Implementing SAP or other ERP-systems brings the benefit that it can be used with very limited amount of effort to demonstrate the future way of working very early in the project.
The S/4HANA as well as the Capgemini pre-configured solutions comes with ready-to run business processes with sample data that already of the box can be used for conference room pilots and as a starting point for an implementation. Use these opportunities and tools to demonstrate the solution from day 1. Review, refine and anchor the solution based on what you see is what you get. It all boils down to communication and understanding and an approach with high involvement of end-and key-users very early pays off in the end with higher quality, less risk for late unwanted surprises and a more anchored solution.  A change of a process, at the time of testing can be very costly and can result in a postponed go live, cost overruns and misery so the conference room pilot approach is a powerful way to avoid it.

Best Practice #5 – The ERP-platform is not a development platform

This best practice could also have been phrased “keep to standard”. Most SAP-projects have a statement like “stick to SAP standard” as a guiding principle, but a study of 1400 SAP systems by West Trax2) in 2013 tells us something else. The study found that up to 45% of the applications on a SAP system are custom code and that more than 40% of that custom code is unused and that 30% of that custom code can be replaced by SAP standard functionality. It also concluded that at least 70% of SAP standard functions are unused. The consequences of this are of course obvious, high lifecycle TCO, limited support from SAP and less flexibility when it comes to future upgrades and new functionality. 
There are different ways to mitigate the risk of this, but I believe that a down to earth change management approach that clearly explains the rationale behind using standard functionality supported by top business management, clearly defined change control processes and a well defined global template are three components that will help.

Next week I will post part 2 in this series, so stay tuned.

  1. Source Gartner 2015
  2. Value Creation Through Optimization of Your SAP Implementation?” West Trax, 11 November 2013.


Related Posts


How to liberate your legacy applications to unleash powerful, agile next-gen apps

Erik Haahr
Date icon March 1, 2021

Discarding the burden of an existing traditional applications landscape will bring clearer...

Business Case

Digital transformation – Understand the why. Shape the how.

Valery Smague
Date icon December 17, 2020

CxOs always focus on bringing their business to the next level. This is a relevant business...


Redundant dyads and SAP S/4HANA

David Lowson
Date icon November 17, 2020

The significant advancement of computers and computing techniques over the years has enabled...