During an ERP implementation, much time and energy is focused on avoiding one of the most concerning – and common – hazards: a project that takes longer and costs more than expected. And this time and energy is well-needed to avoid the negative impacts on operations that a long, expensive ERP initiative can have. After all, the evidence of poorly managed projects is in black and white both anecdotally, as in the horror stories of high-profile ERP failures and lawsuits in the press, and analytically, as in the findings in our 2013 ERP Report, which show a majority of ERP implementations either fail to deliver on time or on budget.
With these challenges provide a gloomy backdrop to executives and project managers about to embark on an ERP implementation, most are not in the right mindset to think about or plan for challenges beyond the implementation – more specifically, how the organization is going to actually achieve all the business benefits the ERP software was meant to enable. Our 2013 ERP Report also shows that a majority of organizations fail to recognize even just half of the business benefits they expect to receive – and even less of the benefits that are fully possible but not expected from their new software. So how is it that these millions of dollars of opportunity costs fail to register on the radars of implementing organizations?
Unfortunately, CIOs, executive steering committees and project team members have trouble seeing past the immediate risk of implementation failure. First of all, if the implementation itself goes too far over budget or brings the organization to its knees during the process, then many of those executives won’t remain employed for long. Second, most executives realize that they won’t need to worry about business benefits if the implementation fails, so they devote a majority of their attention on not screwing up the implementation. It’s sad, but true: Maslow’s hierarchy of needs is to blame for the lack of focus on ERP benefits realization.
We all know that we won’t achieve what we don’t measure, so how can we provide a framework to allow executives and project team members to focus on benefits realization without losing sight of the more immediate – and oftentimes real – risk of implementation failure? Here are a just a few tips to help redirect a bit of upfront focus on potential business benefits:
Make the benefits realization plan real and actionable. Many business cases are simply a formality or exercise in motherhood and apple pie academia. Business cases are often created simply to validate what the organizations want to hear – which is that they need new ERP software – without any real merit or validation of the numbers. Instead, business cases and benefits realization plans should focus on not just high-level numbers but specific and tangible benefits that can realistically be achieved via the implementation. It’s never a perfect science but we can usually get close if we try.
Don’t force the numbers to tell the story you want to hear. More often than I’d like to admit, we hear executives and team members say, “The business case doesn’t matter because we need new ERP software either way.” This may be true at times (perhaps the legacy system is no longer supported by the vendor), but more often than not, there are other options, such as upgrading the current software, facilitating some business process reengineering, or pursuing other lower-hanging (and lower-risk) fruit. If done realistically and correctly, the business case may not support your original line of thinking.
Recognize that the business case will make the implementation less likely to fail. Given Maslow’s hierarchy of needs, this one may be the most important. Most don’t realize that the business case and benefits realization plan will help the implementation succeed just as much as it will optimize post-implementation business benefits. When the project gets overwhelming, competing stakeholders and priorities conflict with one another, and project governance is strained, the business case helps give the project and team direction and priorities. For example, ERP failures are often caused by too much customization of the software. With a solid business case, the project team and steering committee will be much better equipped to decide when and where customization does – and doesn’t – make sense in the context of what’s best for the business. This single example alone is worth the time and effort associated with creating a business case early in the project.
The bottom line is that organizations rarely implement new ERP software because they want new technology. Instead, they do so because they want to optimize business benefits. However, this simply won’t happen if there is no realistic and actionable business case or benefits realization plan to guide the implementation team’s efforts. At the end of the day, a clear vision of expected business benefits will not only help optimize post-implementation efforts, but it will also make the implementation itself much more likely to succeed by finishing on-time and on-budget.
Learn more by reading Chapter Seven of An Expert’s Guide to ERP Success.