Imagine spending millions of dollars and a year or more on a system implementation or upgrade project only to have it completely fail because of lack of stakeholder buy-in. This is an all too familiar story for many organizations that do not engage proper change management support.
One critical decision is often overlooked when planning an ERP system implementation project: selecting resources to lead the most critical part of the project, change management. Organizations spend a significant amount of time qualifying the technical resources proposed by the large systems integration technology firms. During this process, the organization mechanically selects the systems integrator to also lead the change management portion of the project. This decision does not always achieve the expected result.
Should organizations use systems integrator resources or a specialized independent firm to lead the change management thread of a project?
There are pros and cons to either approach. Organizations believe they can staff all the external resources required for implementation from one firm, thus having one party to hold responisble. This simplifies budgeting and cost management components of a project because all external resources are provided by one firm. However, using systems integrators for change management results in budget over runs, lack of time and attention to change activities versus technical activities, ineffective resourcing, and tainted guidance.
During the proposal process, systems integrator change management resources will be factored into the technology firm’s overall budget proposal. However, when budget negotiations begin or constraints arise, change management resources are the first component of a budget to be cut. Most technology firm’s project teams assume a successful transition can be achieved with scaled back change management resources and rely on the technical configuration team to pick up change management activities. The scaled back model rears its ugly head after the implementation is complete. By then, the system integration team is gone.
A few years ago, an oilfield services client’s CIO called us in a frenzy. They had engaged a large systems integrator who was not working well with end users. The change management team was not engaging with the end users and the CIO could not get the systems integrator to develop a training strategy at a reasonable level of detail. We did a quick review of the systems integrator’s work plan and the change management resources had been stripped from the plan. During implementation, the systems integrator shifted change management time to the interface development to save costs. We brought this to the client’s attention and the CIO had some difficult discussions with the systems integrator.
Most recently, we received a frantic call from a client who had completed an ERP implementation using a large systems integrator for change management. The systems integrator stripped training out of the consulting budget, and the client’s internal team had to conduct all training activities. Unfortunately, this caused certain parts of user acceptance testing to be overlooked, which led to a whole series of issues post-implementation, including the inability to close the financial books on a timely basis.
Using change management resources from a firm independent of the systems integrator allows the client organization to have direct line of sight into the change management budget and activities. From the outset of a project, clients know what they are paying for and the change management team’s commitments are clear. There is less of a chance for bait-and-switch issues.
The level of attention and amount of time effective change management requires is often overlooked. Many assume a change management initiative can be completed by simply talking to a few stakeholders and crafting some email blasts. Effective change management requires a team to be thoroughly invested in all facets of an implementation throughout the course of the entire project. The change management team will not only interview stakeholders and develop communications but should also evaluate system design and define training. Each change management activity requires consistent resource commitment.
Systems integrator teams assume change management activities don’t require full-time attention. Their resources will often end up splitting time between multiple client projects. Other times, systems integrator resources are pulled into other activities within the same engagement.
Important details related to the impact of system changes are often overlooked or change management deliverable output is rushed. Both result in ineffective change management efforts and, ultimately, a lack of user acceptance.
Dedicated third party resources engaged for change management purposes are solely accountable for the change management aspect of a project. For example, one of our drilling clients leveraged Trenegy as a third-party to lead the change management thread for a large SAP implementation. Our client’s project manager created a separate set of metrics and status mechanisms to hold our team accountable for change management.
Our team had a laser focus on communications, acceptance, and training activities and there was no blur between these tasks and technical tasks. We had no excuses for flaws in executing change management activities, and the systems integrator had no excuses for not executing the technical tasks. Moreover, since our team was separate from the systems integrator, there was no risk for the change management team to be unnaturally pulled away to conduct technical activities.
Although most systems integrator firms package change management along with implementation or integration services, the two are entirely different service lines within the firm. Clients would like to think the two groups are playing for the same team, but they are not.
Similar to a large company’s Accounting and Human Resources departments, a systems integrator firm’s service lines function independently of each other and report to different divisions or sectors of the firm. When the two service lines are engaged on a project, internal struggles between the two group’s roles and responsibilities arise.
The root of the conflicts is money. The more billable hours a systems integrator project manager can get out of his technical team, the better the systems integrator’s project and service line perform. The systems integrator project manager would prefer to have his technical team conduct as much of the change management activities as possible.
During a recent client engagement where the systems implementer resources were used for change management and technical project components, struggles and competition between the two services lines emerged. The change management practice staffed the project with five resources, two of whom were to be solely dedicated to training material development. However, the ERP project manager determined the two training material resources should be removed from the engagement. The ERP project manager decided the training material development would instead be completed by members of the technical team. While the technical team resources were not experienced nor proficient at training material development, the ERP project manager wanted more resources from their ERP practice attached to the project.
The result was ineffective training materials developed by inexperienced resources.
Utilizing third-party resources for the change management component of a project eliminates service line competition. Resources from an outside firm will not be concerned with ensuring its service line appears in the best light. Additionally, the tasks and responsibilities of external change management resources cannot be dictated by the SI project manager. The SI project manager will not be able to assign change management tasks to the SI team, as these activities do not fall within the SI firm’s project scope.
Change management resources need to have some level of independence and impartiality from the systems integrator team. In other words, the change management team should report directly to the client team and not be under the leadership of the systems integrator consulting team.
Change management strategies, opinions, and concerns should be discussed directly and openly with client personnel to prevent the topic being ignored.
As discussed earlier in this paper, the systems integrator change management resources are subservient to the systems integrator technical or ERP project manager. Therefore, the systems integrator change management resources have a fear of challenging the implementation team when they see a red flag with how the technical team is addressing certain business process requirements.
We were recently brought on to evaluate an ERP project that was destined for failure. Prior to our arrival, the field services client utilized a combined systems integrator technical and change management team from a global consulting firm. During the first round of conference room pilots, several of the district managers caught wind of some new ERP procedures mandating their dispatchers to collect an inordinate amount of data prior to dispatching their service personnel for customer jobs. They foresaw the new ERP design could bring their business to a halt.
As part of our review, we interviewed the systems integrator change management team to hear their perspective. The systems integrator change management consultants only remotely heard of the problem and felt it was not their place to challenge the issue. Moreover, we found the systems integrator project manager would not allow their own change management consultants to participate in the conference room pilots. We did a quick review of the recommended dispatch process and agreed that the new process was not feasible.
Clearly, the client was being led down the wrong path. We found this to be just one example of other recommended technical solutions that were not practical or designed properly for the field services business model. We were asked to take on the change management activities.
During this process, we insisted on being a part of the conference room pilots. We spent considerable time challenging the proposed processes and working with the client and systems integrator technical teams to identify solutions to fit the company’s organizational capabilities.
Change management teams should not be afraid to challenge the systems integrator team’s decisions or question processes. If change management resources become too concerned with upsetting the apple cart, the change management team loses sight of their true purpose.
Managing the implementation of a new ERP or technology solution is all about minimizing risk to achieve success. Clients cannot minimize risk without direct line of sight into the heart of the ERP implementation: change management. With the independent change management model, change management issues are no longer masked, resources are allocated to support the project’s success, and the steering committee has a sounding board for a second opinion when project challenges arise.
