An Introduction to Driving ERP Implementation Success with Milestone Deliverables: Part 1
Our firm developed the Milestone Deliverables ERP implementation project management methodology over a 33-year period. It is now used to deliver ERP success in more than 40 countries. This short series of articles is designed to introduce you to the key components of our methodology - the components that are necessary to drive ERP implementation success. This first article focuses on the importance of project planning, business process mapping and system testing.
Last week, I delivered a presentation on managing ERP implementation projects as part of a day-long conference hosted by i-app - a reseller and integrator of Infor's Infor10 ERP Enterprise (LN) software (the newly renamed ERP LN and present-day iteration of Baan).
The title of my presentation - "Enterprise Software Project Management: A Fresh Approach" - is facetious, a bit tongue-in-cheek. My argument that a "fresh approach" is needed has nothing to do with new tools nor with revolutionary approaches to ERP project management. In fact, I ultimately argue that organizations should rely on a methodology like ours - one that's been battle-tested and proven successful over a period of decades.
I say that a "fresh approach" is needed because most companies continue to take a flawed approach to ERP implementation project management. It's this flawed approach that leads to an industry-wide ERP implementation failure rate of 68% (source: Standish Group 2009 CHAOS report) and a catastrophic failure rate of 17% (source: Harvard Business Review, 2011). And, if you're wondering what makes 1-in-6 projects a catastrophic failure, try an average cost overrun of $170 million and an average schedule overrun of 70%.
Milestone Deliverables is based on the premise that people (and teams) are most effective when they work towards small, achievable, actionable and measurable goals. Our methodology does just that. It breaks down a complex ERP implementation project into 13 distinct phases using 14 actionable deliverables.
Each deliverable is associated with tangible measures of success; including those related to cost, schedule and performance. These metrics act as signposts - or milestones - along the route to go-live. Project teams are required to stop and reflect at each of these milestone. This way, they can see whether they're on the path to success. And, in the event that they've deviated, they're in a position to take immediate, corrective action to get themselves back on track.
In this post, I focus on three phases of an ERP project: project planning, business process mapping and systems testing. For a project to be successful, each these phases has to be effectively managed. Poor management of any one of them is likely to send the project to its grave.
Project Planning
In many ways, a project plan should act as a GPS navigator for the implementation project. It should lay out a clearly marked roadmap - turn-by-turn - to a successful outcome.
ERP implementation success will ultimately be judged relative to cost, schedule and performance. It therefore becomes critical that each of the project's component phases contain corresponding milestones.
Our clients - and other companies that implement using Milestone Deliverables - break down their ERP project plans into the five following components.
Project Charter |
Defining performance success partly depends on the business value that the organization is trying to achieve. The project charter crystallizes the business rationales that drive the project. |
Scope Statement |
The scope statement defines the project's boundaries and is derived from the charter. It should contain two components:
|
Target Budget and Schedule |
Each of the project phases - and milestone deliverables - should be allocated a specific completion date and cost. |
Organizational Structure and Staff Requirements |
A formal reporting structure defines key communications lines, authorities and responsibilities. This helps prevent the "black hole of accountability" syndrome that can lead to unmanaged show-stopping issues, finger-pointing and lawsuits. |
Subsidiary Plans |
These are, in effect, mini project plans for various sub-components. Each subproject should be broken down into specific tasks, MSFs, budgets and schedules. Examples of subsidiary plans include: IT infrastructure plan, risk management plan, resource management plan, scope management plan, and communications plan. |
Business Process Mapping
In my article Without Restructuring, ERP Implementation is an Expensive Waste, I make the argument that ERP software can't make your organization significantly better unless there's a corresponding commitment to operational improvement.
Given the inextricable link between operations and ERP, it's absolutely critical that the future state of an organization's operations be designed alongside the software. This exercise of defining how the business and systems will process transactions is called business process mapping. These mappings show the work tasks - performed by people, systems and machines - that are required to push a transaction through the organization.
The following four deliverables collectively comprise the Milestone Deliverables process mapping phase:
Business Scenarios List |
This is the central organizing tool. It should be used to catalog each and every business process, intended handling method, related reference documents and status. To learn more about the Business Scenario list, read this article: The Business Scenario List - Seven Steps to an Organized Mapping Phase. |
Blueprint Whitepapers |
These documents contain the draft blueprints for the future business processes. Each blueprint whitepaper should accomplish two goals:
To learn more about blueprint whitepapers, read this article: Draft Your Blueprint Whitepapers with this Seven-Part Structure. |
Gaps and Issues Database: Risk Management |
This is the go-to database to track, prioritize and manage all ongoing project issues in a productive manner. Each issue is defined, assigned, prioritized, scheduled and tracked. To learn more about the gaps and issues database read this article: Five Steps to Slaying the Three-Headed Gaps and Issues Beast. |
Change Management Plan |
At the core, business process mapping is about change. For these changes to be successful, people need to adapt to the new ways of doing business. The change management plan provides a methodological process to implement the changes, and includes: gap analysis, job assignment, H.R. alignment, communications, training and budget. To learn more about the change management plan, read this article: Change Management Plan | Six-Stage Surgical Approach. |
Systems Testing
Back in 1999, Hershey's was implementing a trio of enterprise software systems: SAP, Manugistics and Seibel. It had decided to fasttrack its implementation to get the systems up-and-running in time for the busy Halloween season. So, Hershey's cut corners on its system testing to meet its aggressive deadlines.
What's the worst that could have happened, right? How about an inability to ship $100 million worth of inventory, a 19% drop in quarterly earnings and an 8% drop in stock price. (You can learn more about the Hershey's ERP failure in our case study: Hershey's ERP Implementation Failure: The Importance of Testing and Scheduling.)
When it comes to testing, our recommendation is that organizations shouldn't skimp. They're better off learning that things are broken in a test environment rather than in a productive environment. The risk is simply not worth taking. Using Milestone Deliverables, we break down system testing into three distinct phases, as follows.
Conference Room Pilot (CRP) |
In the CRP testing phase, the goal is to make sure that the ERP software can handle the most probable business scenarios (i.e. the 80% scenarios) for each and every functional department (click here for a discussion of 80% and 20% scenarios). The core team members participate in the CRP, and this represents an important element of their training. Learn about the six key tasks that must be completed in a CRP by reading this article: ERP System Testing #1 | The Conference Room Pilot |
Departmental Pilot (DP) |
In the DP phase, all of the organization's business processes should be tested - both the 80% and 20% scenarios. This testing phase should accomplish four main purposes:
To learn more about the DP testing phase, read this article: ERP System Testing #2: Departmental Pilot Stress-Testing. |
Integrated Pilot (IP) |
In the IP testing phase, the testing is focused on the validity of the tie-ins - i.e. whether the system is capable of handing-off a transaction from one functional area to another. The key to effective integrated testing is to create a realistic day-in-the-life test environment using a wide set of actual legacy transactions. To learn more about this testing phase, read our article: ERP System Testing #3 | Integrated Pilot Simulation. |
In Part 2 of the introduction to Managing ERP Implementations Using Milestone Deliverables, I'll cover the following three components that are also critical to ERP project success: a project's organizational structure, training and data migration.
Book & CD
Newsletter
Sign up for ERP news, articles and best practices.
We await release of part II
We await release of part II of this article.
In the meanwhile, may I submit one observation relating to organizational restructuring preceding the implementation of ERP. The article certainly places due wieghtage to this aspect.
The key persons of the implementation team need to create an environment, both with the senior management and with the respective operations management, to ensure that TO-BE process design happens simultaneously with the AS-IS process mapping.
This is THE opportunity to identify areas where the current processes - in terms procedural changes as well as in terms of change in the roles of the participating operational team members - would require change. This should lead to open-minded brainstorming of the scope of TO-BE process, both in terms of compliance to incorporating the technical design of the ERP program as well as organizations's capability and willingness to undertake required qualitative change.
Should the scale of complexity of changes- relating to culture or organization's physical and information structure - call for phasing out the scope, mapping out phased plan should be taken up without any hesitation. It would be necessary to ensure that minimum requirements of ERP program's technical structure - both individually for that process /module or collectively for the requisite integration with other process / module - are not compromised.
Equally important is to document the strategic and execution aspects of phasing of implementation of respective TO=BE process, both in terms of clarity of scope at each phase as well as role and responsibility of each interacting constituent.
This will greatly help in scaling up of the system maturity at later stages, since at this stage the issue has entered more into interpersonal behavioral domain than the technical expertise of the implementing team or degree of commitment of the operating team.
Hi Ashok, Thanks for your
Hi Ashok,
Thanks for your comments.
And, I agree with you. Change needs both starting and concluding destinations. In other words, companies need to know where they are ("as is" maps, existing employee capabilities/resistance, etc.) to map out where they want to get to ("to be" maps, redesigned org structure, etc.).
I also agree that a projected future state needs to be driven by strategic and operational goals. We believe that these tasks are critical parts of the planning phase, and should be defined in the project charter and scope statement.
Cheers,
Jonathan
We are several years into an
We are several years into an ERP implementation as we work through our diverse divisions. i.e. Grain Bins, Ethanol Plant, Commercial Buildings, Modular Homes, Jail furniture etc. All of these divisions have been in the midwest USA. We worked with a consulting firm for the first implementation and developed a dedicated implementation team in house for the remaining implementations. One of our next adventures is an implementation in France for a second Grain Bin division. Our plans are to implement as similar as possible to the grain bin division that is already on the ERP application. Do you have any suggestions for planning an implementaion using primarily an in-house implementation team based in the states?
Hi Jay, We've seen both
Hi Jay,
We've seen both successes and failures using internal resources - in much the same was as we hear about successes and failures when external consultants are used.
In my view, the general rules of effective ERP project management don't change, subject to the following caveats.
My concern with what you've said is that U.S.-corporate is mandating change on its French division. Buy-in from the French executives as well as employees is absolutely critical to your project's prospects of success. If the users and management don't buy in to the system, the redesigned processes and restructured organization, the project won't work - no matter how strong the mandate is.
In terms of generalities, it's also critically important that your organization manage the cultural differences. At the risk of over-generalization, American and French organizations take very different approaches to work. Typically, the balance of power in U.S. companies lies with management. In Europe, employees have much stronger rights. This difference needs to be well managed to properly effect the required changes - including business process mapping and job redesigns (among other things). Again, your organization needs to get stakeholder buy-in on this one.
A final point worth noting: the relationship between your organization's internal implementation team and the client (in this case, the France-based Grain Bin division) needs to be strong. There is an organizational history and relationship component that simply doesn't exist when outside resources are used. This relationship needs to be managed properly.
I'm happy to discuss this offline. Please feel free to email me at jonathang@pemeco.com.
Cheers,
Jonathan
1-866-282-5899 x 802
Interesting and insightful
Interesting and insightful piece of article. In my experience there are some critical factors to a successfult ERP implementation. Some of them..1. organizational change management. The two important pieces to Org change management..communication and strong training..this is critical to prepare the organization to the big change that an ERP implementation brings. The work force has to be made comfortable working on a new system. If the business process mapping and restructuring can happen with a view of the ERP to be implemented, the work force will be better prepared. No matter, if the system is technically sound and correct, unless it is properly used, the project may not be termed as successful. 2. A dedicated team from within the organization and if possible the implementation team. The team from within the organization has to consist of subject matter experts and technical experts..this really goes a long way in a successful implementation. 3. Testing - within the project..can't stress enough about this phase..typically should include three direct phases, unit, integration and user acceptance along with regression and performance / stress testing..depending upon where you are in the program. The restructuring of business processes address another important aspect of a successful implementation - least customization to the ERP product. Typically, customization to an ERP leads to issues which are not visible upfront but surface later in areas unexpected..very difficult to fix /address. However, since this is almost utopian to expect no customization, a very strong change management process control has to be implemented to address which will members from various parts / departments of the orgnaization and implementation team to assess impact of change and try and minimize any issues..
Post new comment