My Bono Fides
As a very Senior SAP Project Manager, I have successfully led many greenfield SAP implementations. I have also led many project recoveries, carve-outs, upgrades, migrations, and probably most importantly, many SAP Project Reviews, both Project Management Reviews and Solution Reviews.
I’ve also worked as a Senior SAP Industry Principal. This was both a quota carrying sales role, as well as a delivery role. One of the key roles of the Industry Principal is to put together the software license package proposal. While this may seem simple, it meant you had to know what software packages were available – from among all the different core, industry and partner solutions, have a very good idea of what they could do, and then be able to price them out. While I was very knowledgeable about my core industries, I relied heavily upon my network within and without SAP, to put together the right solutions.
How does one become a SAP Industry Solution Principal? SAP provided training on it.
Think of it as a level above Solution Architect, such as the IS Retail Solution Architect Training. As I was already a certified SAP project manager, Industry Principal was an Add-On, with a bunch of training involved - a common theme in the SAP world.
I’ve also led many projects in the i2 Technologies Supply Chain Management space, all of which went live right on time. As well, I’ve led various Oracle Custom Development (Oracle CDM) projects, using a now retired CASE (Computer Aided System Engineering) tool called Oracle Designer 2000. This was before they had acquired all the various packaged solutions they now offer.
And long before I started being the project manager on complex, enterprise level IT projects, I ran even more complex projects as a USAF officer, all of which incorporated complex, state-of-the-art Information Technology to achieve complex aircraft maintenance (re: logistics) project requirements.
I don’t want this to be my resume, but you should know that I am a SAP Certified Project Manager, a PMP (Project Management Professional Certification from the Project Management Institute), a Certified Scrum Master, hold the SAFe certification and have an MBA, which was really the basis for much of what I’ve been able to bring to every project. In short, I have a lot of project management experience.
All of my projects have been successful, but I have had to work to ‘rescue’ many ‘others’. Maybe you would like me to take a look at your project.
Common Causes I’ve Observed of SAP Project Failures
No Business Case - Success not Defined
The most common cause of SAP Project Failure is not having a business case – bar none. It’s very hard, if not impossible, to judge whether or not a project is a success or failure, if there is no business case.
The very first deliverable of the SAP ASAP project plan is the Business Case. You would be shocked to know that I almost never have a business plan available when I am starting a greenfield SAP project – or really, any flavor of SAP project.
The SAP Customer Engagement Lifecycle or CEL, regardless of which version of the SAP implementation methodology is being used, whether ASAP (local or global) or Activate, includes performing extensive work prior to the signing of any SOW (Statement of Work) that includes developing a business case. This process takes time and money, requires deep SAP expertise, Industry Expertise, and ideally, a great deal of interaction with the client during the business case development process.
SAP itself, recognizing how critical this process was and is to selling their software, has what amounts to an internal management consulting arm, which, while it gets renamed sometimes, consist of an army of MBAs, SAP partners and Value Engineers. Sometimes, clients pay for this effort, while other times, it is ‘free’.
Why This is Critical
SAP projects, even simple ones, will encounter ‘bumps along the way’. The SAP project manager will need that business case when speaking with the project sponsor. The SAP project manager and the SAP project sponsor, will both do better when explaining the current situation to the executive steering committee when the business case is front and center.
Post Go-Live Business Case Monitoring
The business case isn’t just a deliverable of the methodology. It’s also required after you go-live. And here’s where I see major failure. The SAP implementation methodology always includes a post go-live support function, which is typically referred to as Hyper-Care. For the most part, this phase is given short shrift, focused on making sure the system works as designed, resetting passwords and potentially preparing for the next phase.
What’s usually missing (because this is hard), is monitoring whether or not the goals of the business case are being achieved. Since most of the benefits of an SAP implementation don’t start to accrue until after you’re live, this means somebody has to be assigned to monitor and track whether or not the expected business benefits are being achieved.
This implies there’s a role for ‘somebody’ to be tracking the KPIs. If this is left to an internal person (the typical approach), it’s not their primary job. It instead needs to be a joint effort between the implementation project manager and the client. In short, it’s the project after the project. And it cost money.
Within the SAP CEL, there is an actual phase that initially was called the CBI or Continuous Business Improvement phase – I happen to be an SAP CBI Certified Consultant. In a nutshell, it was a framework for planning each subsequent phase of your SAP system lifecycle. I’ve yet to see an RFP come in that either asked for a business case nor a follow-up phase similar to what SAP envisions.
This is, in my expert opinion, just the normal procurement process trying to force software providers and implementation partners into a ‘how low will you go’ features and functions bake-off. Dumbest approach I’ve ever seen. And I am a SAP MM Consultant!
I’ve only rarely seen RFPs where the client left the door open to propose different solutions or even to develop the business case. Those were usually larger clients with a somewhat more structured approach to acquiring large, complex systems.
SAP ASAP Methodology Training
Whether using SAP ASAP (in any of its flavors) or SAP Activate (in any of its flavors), or some partner defined methodology variant (this is common with the large SIs), there is, as part of the methodology, SAP implementation methodology training required for both the client implementation team and among the client leadership team. This last part is where it gets to be problematic.
Senior Leaders are Busy
While the core client SAP implementation team is supposed to be trained up on the SAP implementation methodology, at the same level as the SAP implementation consultants, this is not practicable or feasible for the senior management team.
Executive Bite-Sized Training
What is supposed to happen is that they are given the executive version of the training. If they want the full she-bang, (I have had this happen), great, it should be included in the implementation plan. However, most of the time, they will need short, intense workshops, such that they understand what is expected of them, and what questions they should be asking of the Project Manager as the project progresses.
Not a Class You Can Skip
Unfortunately, I’ve seen a few SAP projects where no training was offered or delivered. I’ve also seen instances where the training was offered, but there were no-shows or worse, someone was delegated to attend. SAP isn’t the kind of system you just let the IT guy handle. Nor is it the type of system where you want people who you can afford to let go, go. You need the very best of your team – or you will get sub-par solutions.
Training Plan Not Defined
The SAP Implementation Methodology also includes the creation and delivery of training, as per the training plan. The development of the training plan is where the breakdown typically happens. Within the SAP world, there exist Training Consultants, who should be engaged during the development of the SOW. This cost money. SAP has these type of consultants. I have not run across them on smaller implementors. Not even sure if the major SIs have them. Since SAP training is ever changing, you need this role to be filled.
Multiple Levels of Training Required
SAP is a large software system, incorporating at least 16 core modules, many industry specific solutions, a whole range of partner solutions and a development environment (ABAP and other technologies) as well. Every SAP project will need to have training for the core client SAP implementation team members, which is generally the same as the training most SAP consultants receive when they start, i.e., SAP MM Academy, or any of the other modules.
But there is also a requirement for SAP implementation Methodology training, delivered in various formats to all the various members of the team, all the way up to the CEO. As a matter of fact, when I first started out, SAP insisted that all of consultants get SAP ASAP Certified.
I am not sure whether that is still the case. It should be. It is very obvious to me that many SAP consultants, while capable, do not actually know the implementation methodology as designed by SAP, who, after all, get paid to figure this stuff out. Now that the SAP Solution Manager is being retired, there will once again be a need to retrain the existing SAP Consulting population. If I were a customer, I would dig into this subject very deeply.
Then there is a requirement for custom End-User Training, usually (but not always), developed by the implementation team, and delivered to the End-Users.
Training is Expensive and Often Short-Changed
As one might imagine, all of this training is very expensive. Just to orient you, a typical SAP Academy probably will cost around 10 to 12 K when you include travel and Per Diem. End-User training also usually involves (or should) the use of a 3rd party training tool, which has its own training requirement. Like all cost, training is often targeted as a cost to be reduced. This ALWAYS results in low end-user acceptance. There are no exceptions.
Trained and Experienced Resources are More Valuable
Sadly, many clients don’t want to invest too much money in training (if any at all) due to the danger of the newly minted SAP expert jumping ship. As part of the methodology, again, this is usually skipped, you must plan and make adjustments to compensation plans to protect your investment – this process is also part of the methodology.
Successful Testing Depends on Successful Training
If you read about many SAP project failures, you’ll nearly always find the blame laid at the feet of the project manager, and that there wasn’t enough testing.
While the project manager rightly gets the blame (that’s what they’re there for, after all), most of the time, their options were limited by previous choices. To wit, if there was inadequate investment in SAP implementation team member training, and end-user training, then these ill-trained team members will not be able to design and execute robust testing.
SAP Best Practices – Necessary but Not Sufficient
You see, one of the reasons, I, as an SAP project manager, relied so heavily on SAP Solution Manager, was the SAP Best Practices and the included test scenarios. The SAP Best Practices, which, when used right by SAP experts, allows you to quickly set the scope of a project, and get a working, baseline SAP system up and running.
SAP Best Practices also include a library of Best Practice Test Scenarios. These provide a comprehensive set of test scenarios that can be transported into the test environment, and if needed, extended to cover client specific requirements using the eCATT tool or 3rd party testing applications.
Now, if you have ever actually performed software testing, you’ll know that one of the toughest challenges is coming up with the test scenarios in the first place. It takes a lot of business process knowledge and software knowledge to do this successfully. Most people fail at it and get frustrated. Without that SAP Best Practice Test Scenario Library, I, as a project manager, don’t have much faith that everything that should have been tested, was tested.
This is especially true of business process scenarios that cross various modules. As a SAP Industry Principal, when I would recommend software license bundles that ‘grouped’ many modules together to enable an end-to-end process, I knew testing these scenarios was going to require very advanced consulting knowledge, not generally available in the market.
The SAP Best Practice test scenario library also allows you to rerun your tests, much more rapidly and most of all, consistently. I have personally been a tester on various solutions (Linear Asset Management being one of them, long ago), and while it was generally easy enough to test it to see if it worked the way the developer said it should work, it was a lot more challenging (and more important) to break it.
Now you might begin to understand why generally, testing is not done enough, why it’s hard to make a change and retest it, and why, oddly enough, almost no one agrees on what enough testing is.
I can say, that when you read an SAP project Post-Mortem, and they say they couldn’t ship products when they went live – that it obviously wasn’t tested enough.
But the SAP Methodology has clearly defined testing levels, provides a vast library of test scenarios that go with every level of testing and why you’ll almost never see enough detail in an RFP response to decide whether there’s enough budget on the table to perform proper testing.
So, test, then test some more if you want to avoid being one of those SAP Failures.
Change Management
This is another huge area where projects go south. It’s very common for SAP partners to make the ‘assumption’ (and you know what this means) that ‘change management’ can be delegated to the client. This never works. Unless a client’s business is change management, they have zero expertise in what is a very complex undertaking – change management.
SAP Organization Change Management
For greenfield SAP implementations, as an SAP project manager, what I have seen work best is when there is a dedicated change management team, often a third party, who is in charge of the change management program. However, they key to success is that the SAP project manager remains responsible for change management, while the change management team reports to the PM.
Change Takes Time – Sometimes Way More Than Budgeted For.
Communication Plan – a Close Cousin of Successful Change Management
The development and successful delivery of an SAP project communication plan is a key part of project success. It is, of course, part of the SAP implementation methodology. I’ve seen very elaborate communication plans, and I’ve (sadly) seen ‘lip service’ communication plans. These were done for compliance purposes only, and as could be expected, didn’t succeed.
How do you know whether they succeeded or not? On those projects where someone was assigned the responsibility and given the authority and budget, you’ll usually find copies (even in this day and age) of the monthly project newsletters pinned to the walls. Especially when someone has been given public recognition in the newsletter. In fact, if you were to go talk to someone who received this recognition 20 years after go-live, they will have a copy of it. Ask me how I know😎
When I’ve been called upon to perform project reviews, I usually ask members of the SAP implementation team a few key questions:
- What’s the name of the project manager?
- When’s the last time they spoke with their project manager?
- Can they tell me the top 2 or 3 goals of the project?
A sure sign that the project has already failed is when no one can tell me the name of the project manager, have never interacted with the project manager and have no idea why the company is even doing the project. It’s also a good indicator of a poorly executed change management program.
No Publicly Available Project Plan
As a project manager, I, of course, live and breathe the project plan, which so far, I’ve always used MS Project to produce. With the near constant changes in this product on the part of Microsoft, I realize this has become harder to do, but nevertheless, it still my ‘Gold Standard’.
Your project plan is your instrument panel. It’s also critical that every member of the team be able to see it, and that it be kept up-to-date. I like to make weekly updates.
However, the methodology says you need an end-to-end project plan out-of-the-gate, which gets progressively elaborated as you finish each phase and start the next. It’s shocking how often you walk into a project and there’s no project plan whatsoever – because they didn’t want to spend the money on the software. Or they just declared they would do it with Excel.
Here’s a secret – Everybody on the team needs a MS Project license. I would go so far as to say a great investment in project success is to hire a Microsoft Certified MS Project Consultant who also knows sharepoint and to set it all up for you (this will make your life as a project manager so much easier).
Protip: MS Project has an integration with SAP Solution Manager. Learn to use it.
Ideal Project Management Environment
On one of my past projects, a very long time ago, that’s exactly what we did – had someone come in and set up this ideal project environment. When it was all done, everybody was in my resource sheet, received their daily task(s) from the plan, via outlook, and was able to report task status via outlook, directly to the plan. This was one of the few times where I could concentrate on actually managing the project, versus chasing status.
Project Status Reporting
One of the key reasons for having the project plan, visible to everyone, is for status reporting. A template I use has you report against the WBS elements on the plan. That means you, the project manager, prepares a status report that says what was accomplished against the plan this week, and what is planned to be accomplished against the plan next week. It is imperative that this is done at the level of the WBS. It’s simple in design and highly effective, when consistently used. It’s only possible to use if you have a detailed project plan.
ProTip: Pay close attention to activities that were accomplished which were not on the plan and to planned activities that are not on the project plan. You need to know why anyone is doing anything that is not on the plan. Afterall, you have a budget to run, and this is a sure way for it to bleed out all over the floor.
If you have globally dispersed teams, such as you often find with the SIs, this quickly reveals the weakness in the entire project delivery setup. You will find that you have a project administrator with no accountability for project success, providing you updates from his team, usually in India, China or the Philippines. You’ll quickly find out you have different people working on your project from one week to the next, and their idea of progress varies greatly.
Costs drive this behavior. But the impact on project timelines and ultimately, achieving the promised benefits of the business case, all take a hit. There are many tasks (primarily development) that can be successfully outsourced. But ideally, the project manager would rather have everybody in one spot. That’s not just my opinion; that’s an industrial engineering fact.
Pursuing Software Development versus Standard SAP Software
My job as an SAP Industry Principal, was to figure out what software was needed to meet the often highly complex requirements of a client’s RFP (Request for Proposal).
Herein is the source of a conflict that can lead to disaster. You see, as I mentioned previously, SAP has about 16 core modules (Grouped into Finance, Logistics and Human Resources), and somewhere in the neighborhood of 31 industry solutions. But beyond that, there are many solutions available from SAP that are not on the public price list (for a variety of reasons), such as Airline Route Profitability (I think that one is now available).
These solutions are often not available because the business unit within SAP doesn’t want to take on the responsibility of maintaining the product. There are many business reasons for this, including that it doesn’t make commercial sense.
Then there are often numerous partner solutions available. If one is aware of the capabilities buried within these partner solutions, and industry solutions, you just might be able to put together a software proposal that fully meets the requirements of an RFP – thus avoiding or greatly minimizing development cost and associated risks.
But, of course, this means the software license will be more expensive. SAP also routinely acquires entire solutions by buying other companies, remember BusinessObjects? Sometimes, these acquisitions bring unique or better capabilities to the SAP offering. Sometimes, not so much.
Now imagine you’re an IT department with an army of ABAP coders available. Without exception – coders are going to code. While they might be able to develop a solution – it won’t be supportable by SAP without a special additional support package.
If you're looking to get to a 'clean core', this won't get you there.
Such systems eventually become poorly documented, orphaned systems. See the various AS400 systems out there or HP3000 systems running COBOL.
This approach also introduces huge risk to a project. It is not often that I see a project that has been scoped well enough to account for these development projects. Yet I have seen Fixed-Price proposals for projects where developments are ‘sort of’ scoped.
Key Lesson an IT Manager Needs to Know Here
You should always be asking SAP if:
- Isn’t there a solution available that already has much or most of what you’re asking for?
- Is it going to be supported by SAP in the future?
That second question – support, is way trickier than it looks. Especially if your solution landscape includes a partner add-on. Many partners are small. It takes a lot of steady cash-flow to both develop new SAP functionality and to deliver support for it.
There’s another aspect of partner developed software solutions – how are they gathering new requirements? You see, one of the competitive differentiators that I think SAP had and has are the SIGs or Specialized Industry Groups.
One of my more interesting tasks as an SAP Industry Principal was to attend various SAP special interest groups. Some of the groups, which included the airport operators’ group, the airline industry group and the MRO (Maintenance, Repair and Overhaul) group and the Railway Industry group, were where I was able to pick up on industry specific requirements. I then would make a business case to develop these requirements for my industry, which would eventually work their way into the Product Roadmap and eventually, get developed (or not).
Each year, I also had to prepare and submit a formal business plan for each of my industries, which would include my assessment of the demand for these ‘white space’ solutions I was asking for.
Don’t Miss Out on Standard Solutions
This is why I would urge every client who is evaluating an RFP to have someone look at the software proposal part of it and see if there isn’t even more available than what they are proposing. Maybe it won’t make any sense in this phase of your SAP lifecycle, but perhaps it will it in the next phase. It will also make it easier for the SAP Project Manager to just say no to scope changes, if everyone knows it is available or will be available in the next phase.
Success has Many Fathers, but Failure is an Orphan
As you can, I have some strongly held opinions about what causes SAP projects to succeed or fail. There are potentially many other causes, but these, in particularly have popped up on many projects, across decades of experience.
The good news, many SAP projects are successful, so we know how to do it right.
The bad news, many SAP projects are hobbled by well-known issues.
I can help you with every stage of your SAP project, including developing the functional and technical requirements, turning that into an RFP, selecting a service provider, and leading your project implementation. Just grab a spot on my calendar to discuss how I can help you.
