Introduction: Proper Planning to Reduce Risks of ERP Failure
In the first article, we discussed how a well-structured system assessment scorecard can help Small and Medium-sized Enterprises (SMEs) mitigate enterprise resource planning (ERP)[1] implementation failure risks at the system acquisition stage.
In this article, we outline certain steps SMEs can take to mitigate ERP implementation failure risks in the subsequent phase of implementation: the planning phase.
Briefly defined, the planning phase is the stage during which the organization prepares to “ERP-ize” its business. An ERP project requires much more than the mere installation of an IT software system. It requires organizational restructuring.
Generally, SMEs have to restructure their operations to satisfy the business flow parameters defined by the ERP software. These days, most ERP software packages are pre-customized to sectors according to certain industry best-practices.
The extent of organizational restructuring that is required depends on the structure of existing business processes, and on the technical and functional requirements imposed by the ERP software.
As with any complex restructuring project, ERP implementation is accompanied by certain risks of project failure. For example, failure can result from a runaway implementation that causes the project to become uneconomical. It can also result from organizational rejection of the restructured environment where such rejection impedes the achievement of the projected efficiencies.
In the following sections, we elaborate on these particular risks of implementation failure and how effective implementation planning can mitigate these risks.
Failure Risk 1: Run-Away Implementation
If an SME is planning to implement ERP, its primary reason for doing so is probably to achieve cost efficiencies. According to 2009 research by the Aberdeen Group, the need to reduce operating and administrative costs continues to be the main driver of ERP acquisition in the SME segment [2].
Since financial reasons drive the decision to implement ERP, it is critical that the implementation be completed within budget. A failure to deliver an economical implementation will mean project failure.
Since this section deals with ERP-related finance, it is important to briefly discuss some of the underlying principles.
The cost side of an ERP budget is based on a total cost of ERP ownership (TCO) calculation. TCO is the sum of the present values of system, maintenance and service costs. System and maintenance costs are fixed and largely determinable in advance.
In contrast, service costs are usually highly variable and difficult to project with accuracy. Further, service costs are proportionately significant. In 2007, service costs accounted for 45% of TCO for SMEs. Put another way, for every $100 an SME spent on ERP software, it spent an additional $81 on service [3]. As you will have probably guessed, service costs mainly reflect implementation costs.
Poor scheduling, improper resource allocation, project delays and scope creep (i.e. unplanned increases to the project’s scope) are the usual culprits for runaway implementation costs. The first three are generally well understood. Scope creep deserves a bit more attention.
During implementation, there is a holy-grail temptation to “ERP-ize” certain business processes that were not included in the original project plan. The rationale supporting a scope increase is that incremental efficiencies will be gained by “ERP-izing” the additional tasks. Implementation seems like the perfect time to widen the scope: the project is underway, consultants are on site and the teams are dedicated.
These temptations must be resisted. Implementation is seldom the right time to widen the scope (except for dealing with unforeseen items that must be addressed).
The reason the temptation must be resisted is because the argument favouring unplanned scope changes only accounts for the benefits side of the financial equation. Incremental costs must also be considered. These costs include direct service costs as well as the opportunity costs of delay. With respect to the latter, every unplanned day that the SME is unable to operate under the new system is a day of lost efficiencies.
It is fair to assume that an ERP project scope is designed to maximize the net ERP benefits (net benefits = cost efficiencies – costs). This means that all components of the project that yield a positive net benefit are accepted. It also means that all components that yield a negative net benefit (where the incremental costs exceed the incremental efficiencies) are rejected. Unplanned scope increases are typically components that would yield negative net benefits, i.e. they would be unprofitable. Since they diminish the return on ERP investment, these components should be rejected.
The following graph (omitted) depicts the relationship between a project’s gross costs, gross efficiencies and net benefits (net benefits = gross efficiencies – gross costs). As seen by the Net Benefits line, the ideal project plan is at Point A. At this point, all profitable components are accepted and all unprofitable components are rejected. Any project plan that lies to the left of Point A would mean that the plan could be profitably expanded. Any project plan to the right of Point A would mean that unprofitable components are being accepted. Scope increases are generally components that lie to the right of Point A.
The above profitability analysis explains why incremental scope changes are both unnecessary and unbeneficial to the project. As time passes, these incremental changes will either be ignored or implemented as part of a profitable optimization plan.
In summary, a well-structured plan can mitigate the financial risks associated with overly broad scope definition and scope creep. Such a plan will help keep the ERP project within budget and on time.
However, even if financial risks are mitigated, other types of failure risk still threaten the project’s success. One such risk is that certain key people will reject the new ERP system and/or the restructured business processes.
Failure Risk 2: Improperly Managed Change
Restructuring is a necessary evil. It causes the SME to undergo significant and disruptive changes. For example, the SME’s organizational and reporting structures will likely change as departments are shifted. Its operations will likely change as business processes are re-engineered. Daily tasks will likely change as manual tasks are automated. All of these changes mean that employees, management and executives will have to unlearn old habits and learn new ways of doing business.
Some people will embrace the challenges and opportunities presented by the change. These people will help move the project forward. However, there will be those who fear the uncertainties associated with change. These people may resist the project and may risk undermining its success.
Change resistors are powerful forces. Even relatively innocuous-seeming resistance can thwart success. Consider, for example, the case of a sales person at a manufacturer who decides not to input an order into the new ERP system. Instead, the employee calls the order into production – the way he had always performed the task under the old system. Although the order is now in the process queue, it was not registered in the ERP planning system.
This one omission can have severe and far-reaching consequences. Automated production planning, shop floor scheduling and material movements planning become inaccurate and unreliable. These inaccuracies will prevent sales people from providing accurate lead time quotations. As a result, sales relationships will become strained and customers will be lost. The unplanned production backlog will also cause an increase in inventory-related costs. Further, real-time performance reporting will become less accurate since the reports fail to include certain transactions. Unreliable reports will negatively impact management’s ability to make important and timely decisions.
In summary, a failure to buy-in to the new system and processes can cause the organization to fail to reap the efficiency and informational benefits of ERP. The result: an uneconomical ERP investment.
The above is but one example of a change resistor. Generally, an organization faces different groups that resist change for different reasons. Common examples of resisting forces include:
· A union that objects because its members’ job functions would change as a result of process re-engineering and automation.
· Employees who object because they have performed the same manual assembly tasks for 20 years and are afraid of or don’t want to learn new processes.
· Managers who object to donating their “A-players” to the implementation team. The loss of key performers would almost certainly have a negative impact on departmental performance.
· Executives who object to short-term business interruptions caused by the restructuring project, notwithstanding the long-term benefits. This moral hazard is caused by an incentive system that rewards the executives for short-term performance. Interruptions may cause the SME to miss compensation targets.
Fortunately, many of the various human capital forces that can sabotage an ERP-driven restructuring can be mitigated at the planning stage.
Good Planning Lessens Failure Risks
A good implementation plan accomplishes two goals:
1. It presents a clearly marked and easy-to-follow roadmap to implement the process changes and ERP system; and
2. It prepares the organization and all potentially affected stakeholders to adapt to the changed environment.
A plan that achieves these twin goals will significantly help the implementation project’s prospects for success.
Although each plan should be customized to meet the SME’s particular needs, there are certain fundamental principles that can frame the design of every project plan. These principles relate to project championship, project plan design and team formation.
Project Championship
Top management is ultimately responsible for allocating time, resources and money to the project. Its collective attitude towards the project filters down and impacts organizational commitment to the project. Consequently, top management support can make the project while its absence of support can break the project.
Given the importance of executive commitment, the project requires a top-level manager to convert the non-believing managers. This person must be both fully committed to the project and capable of influencing others’ commitment. In his capacity as project champion, this person will be responsible for ensuring that the project remains a top priority and is allocated the resources that are required. In other words, the project champion acts as an advocate who drives change, encourages perseverance and manages resistance. Ultimately, it is this person who legitimizes the project and the accompanying organizational change.
Project Plan
The project plan is a formal document that is instrumental in preventing runaway implementations and change resistance.
If done properly, the project plan helps prevent runaway implementations by memorializing the project deliverables on a timeline and allocating a specific budget to each deliverable. Each deliverable should be broken down into manageable and measurable tasks. A well conceived roadmap prevents scope creep, cost overruns and project delays.
The details of the project plan should be (to the extent necessary) transparent throughout the entire organization. Communicating the project plan will diffuse a portion of the organizational anxiety by eliminating ambiguity about the project and the future state of the organization.
In terms of its components, the main project plan should, at a minimum, include the following:
Project Charter:
This is an articulation of the project’s mission and vision. It clearly and unambiguously states the business rationale for the project.
Scope Statement
This defines the parameters of the project. The scope is broken down into measurable success factors and strategic business accomplishments that drive the intended results.
Target Dates and Costs
This sets out individual milestones. Identifiable, manageable and measurable goals are established. Target completion dates are set. Each individual milestone is valued. This step articulates the breakdown of the project into discrete sub-projects.
Project Structure and Staff Requirements
This sets out the project’s reporting structure, and how that reporting structure fits into the larger organizational structure.
The main project plan should be supported by whatever subsidiary plans are necessary. Common examples of subsidiary plans include: IT infrastructure and procurement plan, risk plan, cost and schedule plan, scope management plan, resource management plan, and communications plan. For present purposes, these last three subsidiary plans deserve a bit more attention.
Scope Management Plan
This is a contingency plan that defines the process for identifying, classifying and integrating scope changes into the project.
Resource Management Plan
This sets out individual assignments, project roles, responsibilities and reporting relationships. It also sets out the criteria for back-filling positions and modifying project teams. Further, this plan details human capital development and training plans. Finally, where necessary, it sets out the reward system used to incentivise project performance.
Communications Plan
A communications strategy is critical to manage change resistance. This plan codifies the procedures and responsibilities relating to the periodic dissemination of project-related information to the project teams and throughout the organization. Examples of common channels include email newsletters, press releases and team meetings.
A good project plan is only effective if the project teams are capable of executing the recommendations. For this reason, team formation and training are critical parts of the planning phase.
Team Formation
Successful execution requires an enabling structure. Like many well-structured organizations, an ERP project structure should contain a steering committee that has executive-level strategic responsibilities; a core team that has managerial-level delegation authority; and functional teams that are responsible for implementing the changes.
To facilitate communication and decision-making, each hierarchy level should have a member who is represented on the level below. For example, the ERP project manager should sit on both the steering committee and the core team, and certain key users should sit on both the core team and a given functional team.
The Steering Committee
The project steering committee should be comprised of the chief executive officer, the CIO, executive level business managers, and the ERP project manager. The committee has strategic-level responsibility for reviewing and approving the project plan, making changes to the plan and evaluating project progress.
The Core Team
The core team is responsible for managing the implementation project. It should be comprised of the ERP project manager, functional leads, the outside consultants and certain key end-users.
Functional leads should be top-performers who are reassigned to the implementation project on a full-time basis. They should be experts in their respective departments, should understand other departments’ business processes and should be knowledgeable about industry best practices. In many cases, functional leads will have to be backfilled in their day-to-day jobs.
During the planning phase, the core team is trained on the fundamentals of ERP theory and on the particulars of the ERP software. The purpose of the training is to ensure that the core team is capable of managing the development of the new business processes.
Functional Teams
These teams are responsible for implementing the business process changes in their respective functional departments. Each functional team is comprised of a core team key end-user, select end-users that cover all of the functional unit’s business processes, and a functional consultant with an understanding of the ERP software.
Organizing committed and capable teams is critical to the project’s success. The project teams will be responsible for managing the implementation and helping the organization adapt to the new business environment.
Conclusion
ERP implementation is a complex project that involves significant operational restructuring. The restructuring is accompanied by certain risks of project failure, including runaway implementation and resistance to change.
Fortunately, an SME can mitigate many of the ERP failure risks by properly planning for the project. At a minimum, proper planning requires a project champion to secure executive buy-in, the preparation and communication of a project plan that breaks the project down into manageable sub-projects, and the assembly of strong teams capable of executing the project.
[1] Briefly, an ERP system is intended to electronically integrate an organization’s functional areas, administrative areas, processes and systems.
[2] Jutras, C. (2009). ERP in the Midmarket 2009: Managing the Complexities of a Distributed Environment. Boston: Aberdeen Group.
[3] Jutras, C. (2007). The Total Cost of ERP Ownership in Mid-Sized Companies. Boston: Aberdeen Group.