In this final article on using Milestone Deliverables to drive ERP implementation success, I lay out our framework to drive successful organizational change management.

Now, before digging into the details, I’ll first debunk some myths.

Three Organizational Change Management Myths

Myth #1: Organizational change management is an airy-fairy, pie-in-the-sky, fluffy exercise that’s devoid of tangible value.

Debunked: As is the case with any consulting discipline, there are self-professed change management consultants who talk a big game but can’t walk-the-talk. Effective change management can and should be structure-able, plan-able, track-able and measurable.

Myth #2: Organizational change management is pretentious consultant-speak for training.

Debunked (… in part!): The phrase “organizational change management” may be pretentious consultant-speak, but it refers to much more than training. Training is but one component of change management.

Myth #3: Your organization’s ERP implementation project doesn’t need formal change management if it has a strong communications plan.

Debunked: Communications plans play an important role, but are insufficient to drive adaptation to new processes, organizational structures, and systems.

Organizational Change Management Defined

So, what exactly is organizational change management? That’s a tough question to answer. A quick review of various academic and business resources shows that a common definition has yet to be reached.

It’s this lack of consensus that drove me to Wikipedia. I had hoped that the “community” could deliver a more useful definition. Here’s how Wikipedia defines change management:

“Change management is a structured approach to shifting/transitioning individuals, teams, and organizations from a current state to a desired future state. It is an organizational process aimed at helping employees to accept and embrace changes in their current business environment.”

This definition has some good and, well, some ambiguous components. Let’s start with the ambiguous. Almost every component of an ERP implementation project is, to some extent, “aimed at helping employees accept . . . changes.”

The problem with a broad and ambiguous definition, of course, is that it makes it difficult (if not impossible) to evaluate the success of change management initiatives. Organizations should want to put themselves in a position to answer the following questions:

• Did our organization successfully manage change?
• If not, where did it fall short?
• And, by how much?

For an organization to put itself in this position, it would need a practical and well-parameterized definition. One that would be capable of being used as a benchmark to:

1. Identify whether a particular activity qualifies as change management; and
2. To the extent that it does, measure the success of that activity.

With this in mind, we prefer to take a narrow view of change management activities. One that excludes deliverables that are measured elsewhere (why double count certain activities?).

This gets me back to the Wikipedia definition. I particularly like the parts about adding structure and process to change management. These imply a degree of formality – an ordering of procedures. These concepts also happen to be at the core of Milestone Deliverables (if you don’t already know, this is our ERP implementation methodology). Using our methodology, we take a complex ERP implementation project and break it down into small, actionable and measurable tasks.

Without further ado, here’s how we define organizational change management for ERP implementation purposes:

The organizational change management deliverable of an ERP implementation project is comprised of activities that:

1. are primarily and specifically intended to transition key stakeholders
2. in a structured, process-oriented way
3. from the existing (“as is”) business environment to the future (“to be”) business environment.  

This Milestone Deliverables approach is based on a narrow, people-centered and structured view. To qualify as organizational change management, the activity must satisfy all three prongs of the definition.

To illustrate, let’s take a closer look at the conference room pilot phase. Without a doubt, it satisfies both parts 2) and 3) of the test. Also, one of the secondary purposes and benefits of this phase is that core team members become partially trained on the “to be” processes and new systems.

Although this training aspect is intentional, it is not the primary purpose of the piloting phase (quality control is the primary purpose). As a result, this phase (and the related deliverable) are excluded as an organizational change management activity under our definition.

Organizational Change Management – The Milestone Deliverables Way

With this definition in mind, we’ve devised an eight-part change management plan that allocates procedures that are capable of being planned, tracked, acted upon and measured.

Here are the eight parts of an actionable organizational change management plan:

• Part 1: Gap Analysis: During this phase, the project teams define the “to be” jobs based on the “to be” process maps. Then, on a department-by-department basis, the teams create a matrix or database to identify the gaps in skills, jobs and personnel (among other things).
• Part 2: Job Reassignment: Based on the Gap Analysis, the project teams reassign employees to the “to be” job roles.
• Part 3: HR Alignment: This is where the transition process starts. This part includes the following (among other things):
  • Formal drafting of new job descriptions
  • Commencement of new hire recruiting
  • Creation of transition plans for displaced employees
  • Meetings with transitioning employees
• Part 4: Communications Plan: The teams develop a plan to notify existing employees of the changes, and to provide them with discussion and feedback forums. It also includes developing a plan to broadcast recruitment needs. This communication plan relates strictly to the change management deliverable, and shouldn’t be confused with the communication plan that relates to the ERP project at large.
• Part 5: Training Strategy*
• Part 6: Training Budget and Schedule*
• Part 7: Select End-User Training Courses*
• Part 8: General End-User Training Courses*

* For a detailed discussion of Parts 5 through 8, please read my post Organizational Structure, Training and Data Migration: Part 2 of Milestone Deliverables.

In terms of timing, the plan should be prepared during the business process mapping phase. As you will recall from Part 1 of our Introduction to Milestone Deliverables, business process mapping is the phase when the project teams plan on getting the organization from its current state to its future state. This phase isn’t only about planning future business processes. It’s also about planning how to get the people to the future state.

Conclusion

The key takeaway is this: if the organizational change is not managed during the ERP implementation project, the project cannot succeed. The people will either be incapable of performing or will be unwilling to perform the revised tasks, or there will be no accountability for certain new tasks. In either case, the organization will not function as intended. For this reason, it’s critical that the success of change management activities be measurable. It’s also critical that change management activities be plannable and executable in a step-by-step, structured manner.

This concludes our three-part series on using Milestone Deliverables to drive ERP implementation. As a quick recap,

Part 1 focused on project planning, business process mapping and systems testing

Part 2 focused on organizational structure, training and data migration

Part 3 (this part) focused on organizational change management.

Need to implement an ERP project?

We wrote the book on the subject. Read Milestone Deliverables: ERP Project Management Methodology