Governance Best Practices to Improve ERP Implementation Success

Governance Strategy and Best Practices for ERP Software Implementations

Analyst firm Gartner once advised that approximately 75 percent of all ERP software projects fail to achieve their objectives. The reasons for failed ERP deployments are many and varied but one thing they all have in common is failed governance.

IT governance operates in a model whereby boards and senior business executives defer technology strategy and decisions to the IT leaders but create oversight and controls so that the technology delivery aligns with the interests of the business stakeholders and ensures that the IT and business objectives and strategies remain complimentary and synergistic where possible, and not separate or possibly in conflict. It's not easy, but when done correctly, enterprise software projects have the maximum likelihood of being successful.

Drilling down a level, the IT governance model and its benefits are directly transferable to ERP software implementation projects, if you follow four best practices.

1. The first governance best practice is to create your ERP project governance as a subset of the corporate governance. The more your enterprise software or ERP project governance compliments the corporate governance, the more likely your ERP system will link to and directly contribute to the organizations top objectives, and the more likely the ERP implementation will be successful. In this context, your ERP software project governance should include a mission and vision linked to the company mission and vision, accept project risk in a way the company accepts business risk, and apply a holistic view to understand how the ERP system will benefit stakeholders throughout the organization. This means you need to identify and consider the interests of many stakeholder groups, and then architect the ERP software design in a way that project output or deliverables for one group may provide the input or reusable value for others. This requires ERP design that identifies objectives, business processes and information reporting holistically, and avoids contributing to yet more shadow systems and information siloes.

2. The second enterprise software governance best practice is to apply a governance framework which aligns business and IT objectives and outcomes. But that's no easy task when it comes to business software systems. Here's why.

   Business leaders want easy to buy, easy to use, quick to deploy, purpose-built business applications in order to quickly respond to fluid market conditions and changing business strategies. However, IT leaders want standardization on fewer business systems and technologies in order to use more of what they have, reduce system integration, aid security, deliver better services and lower IT costs. When the objectives are not aligned it creates a gap between IT and the business.

   The problem is exacerbated as most businesses have a single method for selecting, implementing, managing and retiring business systems. They generally classify business systems by type or three letter acronym (EPR, ERP, MRP, MES, SCM, HCM), but generally do not differentiate the business applications based on their capabilities to achieve user objectives such as ease of use, productivity or delivering information, or company objectives such as innovation, differentiation and agility.

   To resolve these perennial challenges, there are a several enterprise software governance models to consider. One is Gartner’s Pace-Layered Application Strategy, often just called Pace. This governance model aligns the methods business leaders use to create competitive advantage, described in terms of common ideas, different ideas and new ideas, with a technology method which categories business software into layers called Systems of Record, Systems of Differentiation and Systems of Innovation.

   

   A single business software system may cross all three layers. For example, an ERP application is most often a System of Record, but the order entry or Configure Price Quote (CPQ) functions may be Systems of Differentiation while mobile-based inventory picking or new social media-based methods for demand planning and forecasting may be Systems of Innovation. Also, different businesses may classify the same business software system differently, and the same application may evolve among layers due to maturity or obsolescence. It's important to recognize that a mature System of Record is generally required in order to support more nimble Systems of Differentiation and Innovation.

   This technology portfolio segmentation supports more flexible and united governance goals. Rather than viewing the ERP application as a single piece of technology – to be managed, maintained and replaced in its entirety – IT and business leaders can mutually choose individual ERP components based on their highest and best value to the company. Systems of Record will include ERP foundational components that perform core processing, safeguard data integrity and ensure compliance, and therefore benefit the business by incurring fewer changes and longer life cycles. However, ERP software components designated as systems of differentiation and innovation will be updated or replaced more frequently in order to aid more fluid and flexible business strategies.

   ERP software deployment dramatically improve their likelihood for success when business and IT leaders create a governance model that identifies the ERP capabilities that best support common, different and new ideas for competitive advantage and then choose to manage those capabilities within the flexibility or constraints of systems of record, differentiation and innovation. The result is a more flexible ERP system that can distinguish its capabilities in order to get more life and value from foundational components and allow more investment in those capabilities that can drive competitive advantages for the business.

   

3. The third governance best practice is to expand the thinking when creating ERP software objectives. When determining business software objectives, business users normally answer the WHAT question (e.g. what do we want to achieve?), and then IT answers the HOW question (e.g. here is how we'll do it). However, governance thinking is much more focused on the WHY question (e.g. why do we want to do this?). When evaluating your ERP initiatives and objectives, applying a governance mindset to focus on the WHY questions, in concert with the WHAT and HOW questions, will enable you to better prioritize the actions and activities which lead to the most strategic and highest payback outcomes.

4. The fourth best practice is to support your enterprise software governance with resourcing, communications, cadence and tools.

   Resourcing will include assembling the user committees, project team and at least one steering committee. These groups should be made up of cross-departmental teams. A good team building practice is to first to identify the right roles, then identify the responsibilities and skills required for those roles and then to match those roles to the right people. This is different than the more typical approach of identifying resources with availability and assigning them to roles. It's no secret among experienced project teams that the right people for a team are quite often the people with the least availability. That's not a coincidence, and probably why my dad used to say if you want something done, give it to a busy man.

   
   

   Governance communications generally include weekly project team status reports and monthly steering committee reports. Agile ERP implementations will also include agile specific reports such as sprint based burn down charts, velocity charts, stage gate reviews and iteration retrospectives. If there is a change management program (and hopefully there is) it will deliver communications to a much broader audience based on a Communication Plan. Status report content is mutually defined by the content creators and recipients, but normally includes overall project status as well as status broken down by program area (e.g. status for the data migration, software customization, system integration, staffing, change management, scope, time, cost, quality and outcomes). Program risks and Issues should be separately reported, noting that risks are events which may occur and need mitigation while issues are events which have occurred and need resolution. ERP implementation deviations that cause impact to project goals or the project management cornerstones of scope, time, cost or quality need to be separately reviewed and generally include accompanying remediation plans.

   ERP project governance cadence will include the many on-demand and recurring meetings, such as weekly project team meetings, monthly steering committee meetings and agile-based meetings such as the daily standups, backlog grooming, release planning, sprint demos and iteration retrospectives. These get togethers should use agreed upon agendas, deliver meeting contents in advance of the meetings, be led by informed facilitators and realize planned outcomes. Unproductive meetings represent significant productivity leakage that often flies under the radar or is even accepted as the status quo. A governance best practice is to plan and measure meeting outcomes, and alter the agenda or even cancel the meetings if not getting the expected outcomes.

   Software tools are needed to automate ERP project planning and execution. It's best if a single tool or a few integrated tools can be used to track and report project status, project progress, risks and issues, change control, performance metrics and agile measures (e.g. product backlog, release backlog, sprint backlogs and other agile reporting mentioned above). Common tools include Rally and Jira for relatively simple projects or Microsoft Team Foundation Server (TFS) and IBM Rational Team Concert for more sophisticated projects.

The ERP software governance methodology, model, management methods and expected outcomes should be memorialized in a standalone governance plan and reviewed during weekly project team meetings and monthly steering committee meetings.

The ERP governance plan is the single best tool to empower the company to view the ERP project through the windshield, and not just the rear view mirror, and is essential in order to steer the ERP effort to a planned destination, and not just be along for the ride.