Chris Morton consults with Infor customers to rationalize the business benefit they can expect to realize by upgrading their business systems and processes. Chris Lewis, MAFM, MBA, and PhD candidate is a Vice President of Solution Consulting with 15 years of experience across the ERP landscape.
The problem du jour in today’s ERP landscape centers around Gartner research that suggests that more than 70% of ERP initiatives will fail to fully meet their original business goals. Most organizations take on transformative projects such as ERP implementations to achieve specific future state outcomes. The proliferation of thought suggesting root causes, recommending the application of strict project management principles, and consulting to guide companies through their “transformation journey” is widespread. The fundamental problem with all this analysis and recommendations is that they are grounded in project management. If only strict governance were enforced, the project would have been successful; if only clear milestones and functional requirements were identified, documented, and adhered to, the timeline would have been met; if only clear metrics were identified and measured with an accountable owner, success would have been assured. Therein lies the fundamental problem: upgrading business systems is traditionally viewed from the lens of a project rather than what it really is – a change in the way that the people within company operate. Technology is an enabler that allows for people and processes to become more efficient and productive, however this occurs only when people adopt the change required to meet positive change outcomes. Projects and things are managed. People are led. Instead, companies should leverage concepts drawn from design thinking: focus on the problem from an empathetic people first approach; spend time on the business challenges of your employees rather than functional requirements and scope; and orient on actual outcomes over metrics and KPIs.
Both project management and design thinking emphasize that one of the first activities organizations must undertake is to fully understand the problem. Typically, project management focuses on structured problems, where design thinking is thought to better approach unstructured problems. The desire to first understand the problem is where the similarities end. Project management puts an emphasis on defining current state, root cause analysis, proper scope, and quantified success criteria. In project management, there are strict boundaries placed around process and systems with a focus inward. In contrast, is a larger balance of time with experiences and empathy – attempting to understand the organizational needs and desired outcomes from a human-centric, rather than a technology or business process-centric heuristic. With a project management approach to business system change, a well-informed IT team can map out processes, key performance indicators (KPIs), and scope. But, with a design thinking approach, the people involved in the business are the key to understanding the problem that the organization is trying to solve.
Explore related questions
In the same Gartner report that cited a 70% failure rate, key findings included, “future business value that will result from the ERP initiative offers stakeholders within the organization the context they need,” and “ERP initiatives garner more enterprise-wide support when ERP application leaders demonstrate commitment to improving the employee experience.” To put a spin on James Carville’s quote, “It’s the people, stupid.” An approach to ERP projects from a project management perspective misses the mark as it emphasizes managing systems and processes, whereas a design thinking operational approach emphasizes leading the people within the organization to achieve the desired future state outcomes.
Business challenges, not functional requirements
The second shortfall of project management is the emphasis on scope and requirements. In the vast majority of the requests for proposals (RFPs) for ERP solutions that we have reviewed, an inordinate amount of time is spent in this area. There are often pages upon pages dedicated to business processes in and out of scope, and lengthy addendums of excel files listing desired functional requirements by business function or application module – with a majority of these requirements focused on standard, low level requirements already capable in the current state or those that any standard ERP package can support. Companies desiring to upgrade their ERP frequently have a detailed stratification of future requirements, and how the vendor’s ability to deliver those requirements impacts their chances of selection. While in the same document, there may be a paragraph, or in rare cases an executive summary, that lists the business challenges the people operating within the ERP are experiencing. And even when these are articulated, the business pains are vague, and not quantified. Things like, “we operate in a legacy system,” or “users spend time on manual tasks,” have become ubiquitous to the point of cliché. This common approach completely misses the mark because ERP – at least for the foreseeable future – is merely a tool used by humans. If companies leveraged a design thinking approach to an RFP, they would spend the vast majority of their time on the business challenges of their people. Exploration with the people in the organization would discover solutions not envisioned in a requirements document. Innovation from a company’s employees’ input would give stakeholders the context that Garner says they need. While basic requirements are certainly essential – emphasis should be placed on the people and their business challenges, not a laundry list of features to be checked off of a project manager’s wish list.
Metrics aren’t outcomes
A final reason that many ERP projects don’t ever meet business outcomes is because project management doesn’t focus on outcomes. It focuses on metrics and KPIs. But for a business, outcomes do not equal KPIs. In contrast, a design thinking approach homes in on the outcomes that solve the problem. William Bruce Cameron wrote in his 1963 book that, “Not everything that counts can be counted, and not everything that can be counted counts.” Indeed, KPIs are better suited to control of systems to measure efficiency, while outcomes speak to the broader business strategy. As an example, a KPI we often hear is, “we want to improve our on-time-in-full (OTIF) rate.” This is often used as a proxy for increasing customer retention. Unfortunately, a better OTIF does not ipso facto result in improved customer retention. Outcomes are complex, and a project management approach to outcomes results in maniacal focus on KPIs that may or may not have anything to do with improving the business. Nevertheless, organizations continue to rely on a metric driven approach because they are numbers, and numbers are easy to measure. Instead, companies should leverage KPIs to help inform leadership about the project, but they shouldn’t serve as a proxy for real business outcomes. When engaging ERP vendors in the RFP process, understanding how they determine, and measure value-based outcomes should be a part of the selection process. Identifying tools, assets, and resources to help drive a successful selection and implementations of their solutions is key to ensure the organization attains the positive outcomes projects such as these attempt to reach.
If you always do what you’ve always done, you’ll always get what you’ve always got. – Henry Ford
Industrial era thinking continues to handcuff ERP projects with an obsessive focus on managerial control of processes, functional requirements divorced from business challenges, and metrics masquerading as outcomes. It is a fair statement that project management principles bring discipline, efficiency, and some form of quantifiable measure of success. These principles are continually applied to ERP projects; and Gartner’s data shows that more often than not, this approach fails.
