Making the move to SAP S/4HANA isn’t a light decision, and it’s certainly not an easy process. There are sure to be unforeseen bumps along the way that will affect the scope, budget, and timeline of the project.
To get ahead, organizations can take the time to understand what common factors lead to failed projects, what steps they can take to avoid them, and how to plan for better decision-making when thinking about their own transformational projects.
ASUG News sat down with John Belden, project execution audit practice 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 and was responsible for a $220 million dollar project recognized as one of the most successful deployments of SAP at global manufacturing company, Timken.
We discussed some of the steps an organization can proactively take to mitigate risks, as well as how to focus and plan for a successful project. In this first article of our multipart series, we focus on identifying common traits that can lead to failed projects and the early first steps organizations can take to avoid them.
Sharon: What factors lead to major transformational project failures?
John: When I look at program failures in general, it’s usually because somebody has made a bad decision at some point. It’s not that anyone is in the business of making bad decisions, but when we look at the common factors that lead to failure, there are three poor decisions that commonly rise to the top.
The first is that the project is too large. They are three to 10 times larger than any project that the company has taken on in its history. That means there is a large volume of decisions to be made and most companies don’t have the conditioning to be able to make that many decisions in a short period of time. It’s no different than being a marathon runner. You can’t just jump out and run a marathon, you have to condition for it. Companies that take on these big projects, usually aren’t set up to make a whole bunch of decisions quickly and correctly.
The second factor is that big ERP projects tend to be transformational and have two dimensions of complexity. They are technically complex, meaning that there are a lot of parameters that have to be considered on these decisions. And they’re politically complex, meaning that there will ultimately be winners and losers based off the decisions that need to be made. Those types of decisions are very difficult and require senior management participation and support. Lots of companies aren’t ready to make those kinds of decisions very well.
And the last thing they have in common is that they’re generational. Companies haven’t done these projects for a long time, and therefore, they don’t have the people who have the experience and/or the situational awareness to actually manage these projects. They essentially don’t know where the boogie men lie.
Sharon: Can you share examples of business transformation projects that have gone wrong? What lessons learned can you share?
John: There are a couple that I can talk about. The first is a company called Israel Chemical based in Israel. It brought in a new CEO who wanted to consolidate all the acquisitions the company had made over a five-year period and put them under a unifying system. That started off with a project with SAP that was initially estimated as $100 million. It ended up ballooning to $500 million in projected costs and the CEO was let go as a result.
The overall lesson that I drew out of the court papers for this project was that the pursuit of that project was premature in that the CEO hadn’t aligned the organization or the objectives of consolidation and transformation. He just kind of went into it with the system as being the solution rather than the system being an enabler of some sort of common vision.
The other example involves a company called National Grid based in the U.S. It was a $300 million project meant to replace multiple ERP systems. The company provided more autonomy to its consultants than what would be advised. The decision was based off the belief that the consultants knew what they’re doing and so they should completely handle the project. The new system was put in one week before Hurricane Sandy hit the East Coast, which created all sorts of chaos for the organization. The company spent more than a $1 billion on the implementation and the recoveries from the project itself. In this scenario, the decision to go live, to a certain extent, was left to the system integrator (SI), that was under budget pressure and knew that it wasn’t going to be the one that was ultimately accountable for the failure.
Sharon: What areas should an organization focus on early in project planning to help mitigate risk and avoid failure?
John: There are four very early decisions that all projects make that then set the course for decisions that are made downstream.
The first decision is to consider internal talent that’s going to be brought on to bear the project. It’s best to bring on the talent that has both deep operational knowledge on how the company operates, as well as where it makes sense to take risks and where it doesn’t when you’re getting ready to go live. That talent must have good organizational IQ in that they understand the politics of the organization. They understand how decisions need to get made, and they can facilitate that process.
Sharon: Should the talent be pulled from across all lines of business, or does that not matter?
John: I would look for mid-level managers, but ultimately it needs to include people who have operational excellence and those who will be held accountable for delivering on the benefits of the program.
The second big decision that companies need to make is the actual selection of the SI, because it’s going to bring a lot of the thought leadership. An organization should look to the SI for experience on implementations and technical competency, because the SI needs to be able to fill that gap of situational awareness, especially for companies that haven’t done it for a long time.
The third big decision is the business case and making sure that it has both a strategic component and a process capability-based component. You need to show that the company needs to do this implementation because it is critical for the long term prognosis or health of the organization, and that you understand when you implement an SAP system, you know how it’s going to improve the performance of on-time delivery, pricing, inventory, etc. The organization needs to clearly understand these benefits and the business case needs to demonstrate them.
You need to be able to answer questions such as: “What are the capabilities that we’re going to introduce and what is the impact on our business performance as a result of those capabilities?” Having that embedded within the business case allows the decision-makers on the project to make trade-offs and priorities that they’re going to need to set if they go back to that business case as a foundation. It should be able to support that decision-making.
The final thing that’s really important to get right upfront is the amount of contingency that you’re going to allocate to these programs. Typically, a lot of companies want to go in for big projects and allocate anywhere between 10% to 15% contingency. That’s not nearly enough. A more realistic number is 35% or 50%, but that is a really hard thing for executive teams to get their heads around. The alternative, however, is if you don’t have sufficient contingency, and let’s say you’re operating at this 10% level, when you start to bump up against the top of your budget, and project managers begin to make decisions that are based upon achieving the budget and schedule rather than achieving the business benefits. They start to take risks with the business because there wasn’t sufficient contingency upfront. And then that causes this cascade of bad decision-making that ultimately ends up in failure.
In part two of this series, John discusses the critical first steps an organization should take for the implementation phase, as well as who should be at the table and how to plan for high-level decision-making and budget expectations.
Register for ASUG’s on-demand webcast and learn about the “Top 10 Questions to Ask Before Migrating to SAP S/4HANA.”