Implementation planning and having a realistic plan is one of the most important steps in a digital transformation process. However, most organizations and even consultants get the implementation planning piece of this wrong. Why is that? What do organizations do wrong? And how can we create a realistic project plan?
In our experience as digital transformation consultants, we can make a pretty strong argument that the most important part of any digital transformation is the implementation planning phase. It's that step after you've chosen the technology or technologies you're going to deploy, but it's the step before you actually start deploying.
The problem is that too many organizations sort of gloss over that step and just jump right into deploying systems without taking the time to make sure that they've got a realistic project plan. More often than not, organizations have unrealistic expectations around their implementation plans. They take too long, cost too much, and don't deliver the expected business value. Quite frankly, this is a big part of why so many digital transformations fail.
Now, when putting together an implementation plan, one of the first things you can do that's very effective is to look at implementation benchmarks. I'm not talking about anecdotal examples of one company that did something one time, but a subset of data that looks at broad cross-sections of organizations that have been through digital transformations.
Let's look at what some of the benchmarks are. This is data that we've gathered and been studying for over 10 years. In fact, we've been capturing, recording, and really studying and understanding the industry. These benchmarks are not best practices necessarily, nor are they necessarily best-case scenarios, but they're the average. They represent what happens in the average organization, such as how much time and money they spend on their transformations. The reason this is so important is that if we have these benchmarks, we can use them as sort of a gut check to see if we're in the ballpark of what the average organization experiences.
The first thing we need to consider is the implementation timeline. The average implementation for any ERP project or digital transformation is typically 18 months. Again, this is an average. A large multinational organization is probably going to take three to four years or more, while a smaller to mid-sized organization might only take nine to 12 months. But the average for organizations across the globe, across industries, and different sizes is 18 months.
There are two different ways to look at the average implementation cost. I'll share with you two different metrics here. One is that two to three percent of a company's revenue or annual turnover, however you describe it, is spent on a transformation. Sometimes this can be as high as three to four percent for a smaller organization because they have less scale and economies of scale with the costs distributed.
However, the average is somewhere between two and three percent of annual revenue. Another way to look at this is if you're a 100 million dollar company, you're likely to spend two to three million dollars on your total cost of ownership for your transformation. However, this can vary depending on the scope, complexity of your business, where you're moving from today versus where you're headed in the future, and other variables that can factor into this.
Another average cost metric that you can look at that can be very helpful is to look at three to four times your technology cost. In other words, whatever you're spending on software, take three to four times that and that's typically your total cost of ownership. Keep in mind that this metric is largely based on the old on-premise model, and the subscription model that most vendors are moving towards is throwing this number off. In some cases, you need to translate the subscription model into what it would be in an on-premise situation and multiply it by three to four times, and that'll give you your total cost of ownership that may be spread out over multiple years.
One other metric that's just worth noting, but it doesn't necessarily affect your implementation plan itself, is the fact that somewhere between 50 to 52 percent of organizations that go through the digital transformation have some sort of material operational disruption. This is a material disruption to their operations at the time of go-live.
Ranging from anywhere from two to four weeks onto several months depending on how significant the disruption was. That's something to be aware of as well as you want to have a solid implementation plan so that you're mitigating risk and doing things in a way that doesn't lead you into the path of being one of these 50 to 52 percent of organizations that have a material operational disruption.
These are some benchmarks that you can use as a starting point just to get a view of a back of the envelope number of what your implementation duration and cost might be. What we typically do with clients is we'll take these metrics and we'll apply them or move them up or down depending on complexity, size, industry, technology they're deploying, and all these different things that factor in, but at least gives you a starting point on what your overall duration might be.
In addition to metrics, the next step is to structure the implementation plan. I’ll outline what software vendors will typically communicate, the implementation structure, major steps, and other considerations can extend the duration of the project.
Typically, software vendors suggest a process where you have your design and requirements phase, which is usually the first phase of a project. I'm not going to get into the whole waterfall versus agile discussion here, because that's a whole other conversation. I'm going to act as though this is a hybrid approach where we're going to do sort of waterfall and sort of agile.
Let's figure out what that duration looks like and how it's going to apply to you. So, design requirements typically happen early on, then you have your software build, which is usually the next phase, and then you have testing, followed by training. Finally, you go live wherever you're supposed to.
Let's assume here that this proposal you get from your software vendor is for an 18-month implementation. So, we've got an 18-month process according to your vendor, and again, that number is going to vary. You probably have a proposal that has a different number. We see some clients that get proposals as low as three months, and some that are as high as three to four years. So, it really just depends. But most of the time, it's safe to assume that your software vendor is going to be underestimating not because they're bad people or they don't know what they're doing, but because there's a lot of stuff missing from the overall project plan.
The first step then is to compare whatever is being proposed here, including the dollars, whatever the budget is, from your software vendor and compare it to some of these metrics. If you're somewhere in the general ballpark, you might be relatively close. But I'd venture to say that whatever proposal you're looking at is probably a lot lower than what you're getting proposed here versus what the average metric shows.
So, what are some of the missing components that influence how long and how much money it's really going to take to implement your digital transformation? We've got a proposal here from our software vendor. They've given us a duration, they've given us a budget, and they've given us some tasks within the plan. Now we ask ourselves why would this number be so understated and why are these numbers so much more likely to be higher than these numbers? Well, there are a few reasons for that. It's because there's a lot of things missing from the software vendor's proposed plan.
Keep in mind that a software vendor's proposed plan is for one piece of an overall program or one piece of an overall digital transformation. And, it's the other pieces that aren't in the purview of the software vendor that typically drive the most time, cost, and heartburn during transformation. But, the problem is most organizations don't realize it until they get into the project. Then they end up wondering why this timeline doesn't ever materialize or they don't ever get close to it. It's because there's a lot of stuff that fits in the cracks here or that should fit in the cracks that pushes things out.
The key to this, before I get into what some of those missing components are, is that the sooner you address these things and the more you plan to invest in these additional activities, the less time it's going to take you. And that's the irony of it all. If you wait until you're halfway or two-thirds through the project and then realize, "Oh wait, I need to invest in activities A, B, and C because it's not in our plan here," by then you've created some massive delays in the project already. You should have been doing those things early on.
So, what are those things? I'll talk about them right here.
One is business process improvement. I'm going to represent this by showing you the strain it has on a project plan. Business process improvement generally extends beyond this year. The process improvement is going to push things out quite a bit because when you get to this phase, when the software vendor and the system integrator come in to define your requirements and start designing software, they need answers right away. They need to know how you want the software to work, and we're going to build it for you.
Yes, there are some limitations based on how the software works, but today's ERP software and digital technologies are so flexible that there are a million different ways you can run your business using the same software. We need to have a good vision of what our business processes are. If we don't, then what ends up happening is this stage right here gets extended, and it takes a lot longer to do this now because we don't have a vision of what we want to be when we grow up. Therefore, this delays the project.
Or, if for some reason, it doesn't delay the project, and this is potentially even worse, it doesn't delay the project, but they end up just building the software the way they're most comfortable, that doesn't fit with your business, which may not delay the project here, but down here, you're going to run into massive delays because it wasn't built in a way that supports your business and its objectives.
Another thing that can push out a project significantly and should be factored into a realistic implementation plan is organizational change management. You need to take the time to define that up front so that you speed things up here. So, you're investing a little bit of time and money up here to save a lot more time and money over here.
Change management is very similar, although change management is typically happening in parallel. If we wait until later to do change management, we are almost certainly going to extend the go-live significantly because we've had resistance building all along the way. We've had change management issues. We may not see it or feel it yet until we get to training, but it has absolutely been developing and percolating. If we wait until later, it's going to delay the project even more. But having said that, we want this parallel activity to be starting as early as possible, probably here during the business process phase, the pre-implementation phase, and continuing throughout implementation.
And then one more thing I'll share with you is what I'll call the non-software technical workstream. This includes things like data mapping, data migration, architecture, how the different modules and systems are tied together, and how we're going to integrate different systems. All of this needs to have a very clear plan and vision that starts up here before you ever start designing, building, and testing. The reason for this is that in parallel with this, you're going to have to be doing a lot of those activities to make sure you're cleaning up data mapping, building the integrations, and testing the integration. When you get to the test phase, you'll be doing a number of those different things that are maybe outside the scope of a single ERP or a single software, but they're very relevant to an overall digital transformation.
The reason I'm pointing out these missing components is that they put a strain on the overall duration, especially when we don't do them at the right time or place and don't invest the right resources and money in those activities. I already talked about what happens with the business process and some of the tech work streams if we don't do that work upfront and start our change management work upfront.
Yes, we might spend a little bit more time upfront before we ever start the clock running on the 18 months here, but if we don't do that, it's probably going to extend it by a lot more than three months in that example of taking the three months upfront. These are just a few examples of how those strains happen. So, now we need to figure out how to get a realistic plan based on everything I've just mapped out here.
So, the next step now is that we need to take the proposal that we get from the software vendors and wrap it in all this other stuff. We need an overall program plan, not just a project plan for one work stream, but a program plan that includes all this stuff. Generally, where we start, rather than trying to guess what all this is going to be when we don't really know at the point you've made a decision around what technology you're deploying. We don't really know how long this is going to take. Yes, we've got benchmarks here. Yes, we can make some initial assumptions or guesses around whether or not this is realistic, but we don't really know.
So, how do we know? How do we find out what a realistic plan is? Well, the first thing I'd say is this phase right here (I'm out of room here), but this phase, we'll call it the pre-implementation planning, is the most important phase to accurately determine how long the rest of this is going to take. Generally, for most of our mid-sized to larger organizations, this is a three to six-month process of doing all the stuff I mentioned here: defining your future state target operating model, your future state organizational design, doing some initial change impact, doing an organizational readiness assessment, creating a technology roadmap in terms of how different technologies are going to fit together.
How they're going to integrate, how the data is going to migrate, how systems are going to be decommissioned, how and when are we going to decommission systems, what are we going to do in the interim while we decommission certain systems and start to bring on new systems, do we build interim interface points, all that stuff. You've got to have figured out and know the answers to before you can really determine what this is going to be.
The time and money you spend up here during pre-implementation planning is absolutely going to give you a lot more clarity and confidence in this plan. And then once you do that, then you can start to really map this out and say, "Okay, yes, the vendor thinks it's going to be 18 months, but based on what we know about how much we're changing our processes and how big of a change it is organizationally, how complex we are as an organization, the way we've staffed the project, and the available resources internally, that gives us some variables that we can use to flex this up or down in terms of duration and cost."
This is where you start to take some of the science and convert it into art or to augment and add in art to how long a project is going to take. And you start to work through some of the different variables that can give you a better, more accurate representation of what the implementation time, cost, and resource commitments are going to be. This phase two also gives you a better idea of what the risks are. So now you can start to get your handle on what the risks are and how we're going to mitigate those risks and really start to attack those risks from a risk mitigation perspective.
Now, for more benchmarks and best practices to help you with your implementation planning process, I encourage you to download our Digital Transformation Report. It's an annual report published each year that provides a number of implementation benchmarks to help you understand what some of the other organizations are going through within their digital transformations, and it gives you some good data points to help you in your implementation
If you are looking to strategize an upcoming transformation or are looking at selecting an ERP system, we would love to give you some insights. Please contact me for more information eric.kimberling@thirdstage-consulting.com
