We know that many factors play into completing a successful SAP S/4HANA implementation. We also know that there are often bumps in the road—both expected and unexpected—along the way.
In this three-part series, we uncover the common factors that lead to failed projects, what steps an organization can take to avoid them, and how to plan for better decision-making. ASUG News sat down with John Belden, project execution audit practical lead at UpperEdge, an organization that helps customers negotiate their deals with SAP and system integrators (SI).
John has more than 30 years of experience implementing SAP systems. In the first part of this series, he identified common traits that can lead to a failed project and the early first steps organizations can take to avoid them. In this next part, we discuss the critical first steps an organization should take for the implementation phase. We also explainwho should be at the table and how to plan for high-level decision-making and budget expectations.
Sharon: What are the most critical first steps businesses should take before implementing SAP S/4HANA?
John: As an organization engages with an SI, it should ask for an inventory of what key decisions will be required over the first three to six months of the project. Then, the stakeholders should align that key decision inventory with the governance structure that they think they’ll put in place for the project. From there, they should ask themselves if the governance structure includes the right group of people. Are these the people you will charge with making these key decisions? That’s the very first step.
Sharon: Is it essentially the organization’s own road map of milestones?
John: Yes, it’s a road map of decision-making.
Usually, when people measure the success of project management, they tend to think about the critical path—that sequence of activities within the project that if you string them end-to-end are the long pole of the tent. I think it’s more important to focus on the crucial path—the sequence of key decisions that need to be made throughout the project. It’s more important to make sure that your organization is staying on track with making the decisions. It’s relatively easy to say how long it will take to build a piece of code or build a design. It’s not easy to say how long it will take to think about whether you want to do “assemble-to-order” or “make-to-order” with your system.
Oftentimes, these decisions become holy wars within the company, and it takes much longer than anybody would anticipate.
Sharon: Who should be at the table during the decision-making process?
John: First and foremost, always include those who have the most invested in the outcome of the decision. These are these key business leaders.
Second, you should include those people who are best informed to make the decision, and oftentimes, that means your consultants must be in the room to provide you with the good information you need to be able to make good decisions.
Lastly, I recommend that there be an independent third party that doesn’t have a stake one way or the other. Sometimes you get your best advice from people who have the least to win or lose.
Sharon: What types of issues contribute to poor decision-making? How can customers avoid this?
John: The way that we’re wired oftentimes contributes to making a bad decision. For example, if you think of the techniques you may have used to manage a $100,000 project, you’ll find that they don’t necessarily apply to managing a $100,000,000 project. Making decisions, managing the budget, and any other factors you need to consider are completely different. Your way of thinking about what’s important in your management versus what’s important to the overall benefit of the company changes the more there is at stake. All those biases go into and create conditions with which bad decisions can be made.
The other two things that contribute to bad decision-making include budget and schedule. Whenever you go into a big project, the project team wants to share progress with the executive team on how things are going. The executive team is usually more concerned about where the project falls within budget and schedule as opposed to number of process designs completed. As they go through the project and the pressure gets put on budget and schedule, then that’s when the project team begins to make bad decisions.
To the extent that they can, organizations should bring on operational continuity metrics or business case acquisition metrics into the process very early on.
For example, tell the executive team, “We are still on track to achieve a $50 million reduction in inventory, and we know that because we’ve done these designs.” Put those metrics up front along with budget and schedule, and it will take the pressure off when you get closer to go-live because the executive team understands metrics.
Sharon: How do you plan for your migration budget and set realistic expectations? How do you stick to the plan?
John: You need to have independent evaluation of the budget up front. You have to be very careful when you get bids from SIs because their main objective is to win the proposal. So, they’ll always come in with the lowest reasonable cost, but that’s not always the full scope.
I’ve seen budgets described 17 different ways from Sunday. I can go out and ask for five different bids from five different vendors, and every one of them will say, “It’s between $20 and $30 million.” But each one of them will strategically leave out two or three things in their proposal so that they can come in with a low number. Then you will discover those later, and you’ll have to go back and add them in. So, an independent review from somebody who doesn’t necessarily win or lose, but who is able to evaluate those proposals, is paramount. That’s number one.
The second thing is having a fact-based analysis of the contingency itself. You have to look at all the different things that could go wrong in the project, and build up a contingency number that can be supported by facts, rather than a number that is just layered on there because it’s a standard of your organization.
The third thing to consider is contingency win-back tactics within the program itself. As you go through the project, you need to constantly be thinking of ways to save money and put the contingency back into play.
Sharon: So, the organization needs to be informed about first what it is asking from the SI, but also what the SI is proposing, as well as be flexible throughout the project?
John: Absolutely. These are very big, complex efforts, and things are going to be missed. It’s inevitable. I've seen clients try to plan everything, but you can't build a perfect plan for a three-year project. Things—divestitures, changes in the economy or your resources—happen. For most organizations that are running small projects over a short period of time with a smaller controlled number, the application of some sort of fixed amount of contingency such as 10% to 15% isn't going to be a wrong decision. But big complex decisions that cross organizational boundaries, cross business planning years, cross other initiatives, that 10% to 15% contingency—unless you're well-versed in planning these big projects—probably isn’t going to cut it.
Bottom line, you need to be flexible and informed.
In the final part of this series, John will discuss tips on how to partner with the right SI, the consultant’s role, and change management.
Register for the ASUG on-demand webcast, “Top 10 Questions to Ask Before Migrating to SAP S/4HANA.”