What is wrong with my SAP Implementation Project?

Due to the complexity of this topic, this article is a slightly longer read, but I encourage you to have a look and give me feedback on your personal experiences. So it doesn’t become too lengthy, I do not intend to dig into all the relevant aspects, yet highlight some of the most important considerations I have encountered.

As we all know, implementing SAP (or any standard software), or migrating to another version of an SAP installation, is complex, to say the least. These projects have “many moving parts” and there is a high risk of failure or ending up in escalations, causing painful financial losses and operational disruptions.

The considerations I mention below may seem like a horror story, but it does not have to be.

As Patricio Palma indicates, "...all implementation projects must control 3 main aspects: solution, data, and people. Most projects are focused only in the solution but underestimate the importance of the other two....Finally, the main goal to be successful in a sustainable way is to protect the Clean (SAP) Core and good extensibility using the right techniques when necessary.".

We could all agree that these endeavors need to be highly planned and structured in their execution.

With an adequate and disciplined implementation strategy and methodology, and an experienced team, these projects will reach their objectives on time and budget and generate significant business value.

While there is no recipe for success, what follows are some of my lessons learned, and considerations to take into consideration when embarking on an SAP implementation or migration project:

• Understanding of High-Level SOW’s which leave the door open for discussions during the project execution. A somewhat vague or “open” contract could be positive or negative, depending on how it is managed. Nothing new under the sun: To seal deals and win over the competition, contracts are sometimes purposely left vague to allow for later detailed definitions, during the planning phase - especially using the project charter and detailed scope documents, as well as the detailed project plan to refine scope and responsibilities.

The Delivery team needs to understand why this sometimes needs to be done, and why this could be beneficial if managed with transparency internally and with the customer. The Sales team never has enough information to prepare the perfect proposal on time and will often need to find a balance between what they know and the clock ticking on closing the deal.

Once the deal is "probable", getting at least the architects and the potential project manager on board during the pre-sales cycle will make the proposal more concrete, create an internal consensus, and enable the team to start with their feet on the ground once the deal is signed. Having them in some conversations with the customer leads, helps to foster trust.

Once the project starts, there will always be a risk that things go astray, especially due to scope management.

During project implementation, all changes to the original contract must be formalized via change requests (also zero-dollar change requests). If this is not done correctly, when the brown stuff hits the fan, all parties will resort to revising and bickering about the original contract and conversations become difficult.

Before signing the SOW, the customer must be informed about and on board with the gray areas, and how the Change Management process will work during the implementation. More comments about this follow further below.

Running a (paid) small prototype or analysis phase before committing to a longer project lowers risk, provides more clarity on scope, both for you and for the customer

• Management Involvement

As Reto Sager points out, Once a contract is signed, management has to stay on board and stay very close to the project, not only in steering committee meetings but also occasionally in normal status report meetings, to keep a finger on the pulse and be ready to assist the team when needed.

I also agree with Reto, that clearly, customers are frequently not ready (capacity-wise) to implement large transformation projects. The staff they have is benchmarked for daily operations, not for large transformational projects. This is true for the business as well as IT.

This needs to be considered at the beginning of the project as the absence of business and IT people from the customer side is a recipe for failure, and putting the extra load on these teams results in resistance, over-work and frustration.

• Fostering effective communication and tracking by project management and stakeholders. A communication and tracking plan must be agreed on at the onset of the project, including the frequency of status of team coordination, operational and executive status meetings, and reporting formats.
• Project Management, Methodology. During implementation, disciplined planning and tracking is a must. Weekly or even daily project status reports need to be accurate, exposing all risks, issues, and progress information based on a very detailed and shared project plan. This is even more valid for projects using agile methodologies. Use SAP Activate, and adapt it to your needs but don’t reinvent the wheel, use the templates and processes provided, they were created based on many, many years of experience and lessons learned. Mostly, it can be adapted to a combination of Agile and Waterfall if needed. Stick to formal documentation of meetings, decisions, reports, and for example acceptance of phases.

Ensure that your project manager has a senior coach in the background.

• ?Impossible high-level implementation roadmaps. Wishful thinking is common, and PowerPoint can be very sexy and flexible, especially when management insists on an “aggressive” roadmap. I have yet to see a roadmap with parallel releases in for example a 3-multi-year program roadmap, that did not get re-planned frequently or got canceled altogether.

Yaser Al-Jughaiman pointed out "...that CEO's should take responsibility and accountability to the implementation of the road map especially if the program is complex and full of industry specifics. Since it is a complete business process reengineering of the whole organization structures.".

Being realistic and using an “open kimono” from the start between all parties is rewarded with bilateral trust and credibility. Agreeing with unrealistic roadmaps that end up blowing in the wind may get the initial budget released by the board, but they pave the way for future escalations, constant re-planning, and big negative financial impacts.

• Resource management. Be careful of positioning inexperienced consultants (because they are cheap, and you want to grow the team).

?o?? Staffing and the A-Team. Shoot for staffing the best candidates to lead PM, architecture, technical, and functional roles: The A-Team. Even though it is very important to grow the team with less expensive resources, only include a few juniors paired with the seniors, as the coaching distracts, and exposure of less experienced consultants to the customer may lead to uncertainty. In SAP implementations, the customer will always expect the A-Team

?o?? Capacity and occupancy control. Ensure that resources are engaged as per plan, and avoid overload and burnout, frustration. The capacity planning should be updated (plan versus actuals) ideally weekly. Have 10-minute 1:1 calls with team members frequently to measure the temperature

?o?? Fragmentation of dedication. Do not assign resources to too many initiatives at the same time. Switching for example from one project to another 3 or 4 times a day is exhausting, inefficient, and requires a special skill set, so make sure if you need to do this, that the consultant can handle it only for a brief period

• Inefficient conflict management. This is not only the job of the project manager, who is especially focused on internal and customer team members. The project manager should "export" conflicts that are not directly related to the project, which is when the stakeholders, and account management need to step in and ensure that misalignments with the customer, for example regarding contracts, do not filter down to the project team.
• The effect of “SAP is so expensive”. Indeed, it is not cheap. Buying and owning a Mercedes Benz is also not cheap, but there are compelling reasons for owning one. The business case is where this investment and operating costs are justified and are normally but not always prepared by the customer.

Unfortunately, to artificially mitigate this cost factor with customers who are increasingly more budget-sensitive, some consulting companies knowingly deliver underestimated initial commercial offers and responses to RFPs, with zero or negative internal margins. This is done to beat the competition and win the deal, with the underlying thought that later change requests will make for a longer-term higher margin, possibly spread over various projects. This may work if the customer is already committed and implementing the first project, and because it is costly and risky to change the implementation provider.

Yet, this “setting a trap” practice is a recipe for failure. Customers are not always flexible with budgets, and cost overruns, lack of confidence, and transparency will lead to frustration, inevitability, scope shrink, or project cancellation.

The real costs and benefits of the project or program need to be transparent, based on Business Value (i.e. as per the Business Case mentioned above).

• A lack of business buy-in and resistance from end users. If it’s a new SAP implementation or a migration from another system, there will almost always be an element of end-user and/or IT resistance to moving to SAP. Business buy-in is key, the lack of it will impede project progress and ultimately can impede the GoLive.

Business needs to be embedded in the project from the outset, not only during the UAT.

Ensuring business transformation and management strategy communication is key. When in the role of systems integrator or consulting implementation partner, it is our responsibility to make the customer aware of and assist in enabling this.

• In this same vein, incorporating Customer Organizational Change Management and training as a track of the project helps to augment end-user acceptance.

?A very encompassing definition phase, testing, and user acceptance phases also facilitate this.

• ?Unique business processes and accounting practices. SAP software is highly standardized and customizable and incorporates best practices from almost any industry one can think of.

The core idea behind implementing standardized software, and moving to standard industry processes, is to migrate away from home-grown solutions and processes, reduce technical debt, improve efficiency, and agility, and enable innovation.

Including a Business Transformation team to accompany these implementations will permit the modernization of business processes to match evolving market demands. The investment in SAP can only be realized if the business model is gradually transformed to harness the software features and capabilities.

Sure, it does not always work to standardize. However, I have seen the customer’s management lay down the commendable rule in some customers: “We implement the SAP standard, and any exceptions need to go through the internal change management process”.

This will depend on the flavor of SAP being implemented. On-premise versus Cloud, SAP Public Edition over the SAP Private Edition.

Once I buy my Mercedes Benz, I will change the seat position per driver, but I will likely not fiddle with installing rear-view mirrors from let’s say a Fiat.

Steve Watts pointed out: "Second-guessing how SAP works. Too many people arrive on projects and want to do things their way. Stop it and potentially remove the person from the project. This goes for Enterprises Architectes and Digital Security staff.". I agree.

• Partial use of SAP to enable manipulation of accounting data. I have experienced with various customers that accounting teams fueled by business try to, after a closing period, manipulate data from SAP to bypass the strict and normalized accounting rules embedded in the system. In some cases, customers will even export the data from SAP, manipulate it, and then re-import it into SAP. These practices are unacceptable and even if internal customer controlling could be convinced to accept modifications post-closing, the external auditors will detect it eventually, and the customer will end up in complex audits like for example SOX compliance. When these happen, more frequently than not, the differences will be blamed on “SAP”, not on data manipulation.

It is imperative that closings after posting periods are not modified, and that practices like back-posting are not permitted. When implementing the project, this must be made clear to the relevant areas and signed off by Controlling.

• Fostering effective communication and tracking by project management and stakeholders. A communication and tracking plan must be agreed on at the onset of the project, including the frequency of status of team coordination, operational and executive status meetings, and reporting formats.

This means everybody needs to communicate a lot but not sit on calls the whole day. The project team needs space to think and work, not to mention having a life. Micro-management kills incentives. Day-to-day coordination between team members can be spontaneous.

Challenge #1: Try setting a 15-minute limit on all meetings and have them in the mornings so the project teams can concentrate on their tasks in the afternoons. Decide which meetings need more than 5 people in them. When there are 30 people in a call of a duration of 1 hour, at an average rate of $60 US per hour, the meeting costs $1,800. If you have 5 of them per week, the project or company will need to fork out $36,000 per month for these meetings. Real case: A customer that had 65+ people in a coordination call once a day, to revise a project plan and they were a waste of time.

Challenge #2: Friday afternoons should be meetingless and hopefully open for team members to take free to compensate for all the extra hours they may have worked during the week.

• Data Intelligence. To know what you are up against, a special focus on analyzing and understanding data is important. This should be done as soon as possible even before the project starts, as it may be convenient to do data cleansing before you start implementing the main project. More information on this can be found here.
• Coordination and co-working with SAP, especially for S/4HANA cloud implementations. In any SAP project, there will be multiple areas of SAP involved, and they are understandably, not always seamlessly coordinated. Be sure to have an SAP delivery or project manager and stakeholder assigned, to coordinate between areas, and to react efficiently in the face of escalations. SAP needs to be at least informed on project status - even if the implementation is performed by a partner.
• Project Change Management. To avoid scope and budget creep, effective and very strict Change Management must be in place. This is very much a project culture topic that the customer needs to be made aware of early, and project management needs to implement. In my experience, consultants and project managers love to please their counterparts to show their commitment and expertise, and hence smaller and bigger changes start being made without the essential formality that is needed. It is OK to implement additional functionality without charging the customer (“zero dollar change requests”), but these also must be communicated and formalized, signed, as a change request
• Technical Integration and Interfaces. This may or may not be in your scope but is the Achilles heel of many a project. The SAP core implementation may be working fine, but if the interfaces, vendor, and customer integration do not work, the system cannot go live
• Training. End users can be trained formally but can also learn how to use the new system on a day-to-day basis by executing real-life scenarios during the system testing and user acceptance testing.
• Performance, Sizing, and Load Balancing. Key considerations in SAP implementations. SAPs help with up-front sizing is important. New operational models are available and there is a certain flexibility if you are moving to the cloud.

However, during the project, the Basis and functional team members need to work together to formulate the ideal mix of for example the assignment of application servers, background and dialog processes, and how to tweak the Load Balancing during end of day or end of month processing (or actual migration processing during GoLive), to ensure optimum use of available resources.

• Testing and Dress Rehearsal, Cutover Management. After something broke in production, how many times have you heard people asking, “But was this not tested”. It means: Test, test, test. Finding problems in production is astronomically more expensive than finding them in quality environments. The Dress Rehearsals should not be a formality, they must simulate GoLive, and verify the detailed cutover plan, and timing, as well as the team activity plan, and overall timing. Hence Dress Rehearsals are true simulations of going live, and if done properly, give a lot more confidence that the real GoLive will not have hitches.
• GoLive. The GoLive plan must be super detailed. Everybody needs to know what to do when, and every action be monitored by the project managers - there probably will be more than one shift, with teams participating from different time zones.

This advice from Steve Watts is spot on: "In meeting and real close to go lives. I would tell the team often. If there is nothing to say, say nothing. If there is nothing to do, do nothing. Noise and mucking around will only create distractions and issues. Only hope the skill set in the project while you need them and then release them. Hoping all skill over the lifecycle of the project is costly and a distraction.".

• Hypercare. The implementation team must be available and budgeted for 24x7 support at least during the first week of operation. Depending on how many incidents are detected, the support needs will dwindle, but the team again needs to be on board at least until the first month-end close and financial post-processing is complete. It’s customary to have 2 to 4 weeks of Hypercare support contemplated in the contract.

Thanks for reading and I very much look forward to comments and additions to this article.