When an Executive Doesn’t Commit to ERP

One of the most undermining dynamics that affect an ERP implementation is a lack of leadership commitment on the level directly below the C-Level. If the lack of commitment is recognized early on, there is the possibility of orchestrating a joint meeting with the C-level to air concerns and discuss differences. Opposition may boil down to a few specific issues which can be accommodated. If the resistance is unilateral, then it becomes the C-office’s responsibility to sell the importance of the ERP project’s success to a reluctant president or VP.

An ERP project can be underway with uncommitted leadership if there has been a leadership change in the organization, and the new executive lacks the level of commitment the previous executive had. In that case, a joint meeting with the ERP project manager, the C-level, and the new executive is required, to make certain everyone is calibrated to the same definition of ERP project success.

Smiling Assassins

The worst case scenario is when an executive publicly supports the project but privately destabilizes ERP implementation efforts both in word and deed. Recognizing that this is happening may be as simple as recognizing that the executive avoids or delegates ERP decisions; that the executive makes under-the-breath comments that are derogatory to ERP; that the executive fails to include ERP as a strategic imperative when addressing his staff; or that the executive does not make clear to his or her subordinates that a successful implementation is a condition of employment. Another common symptom is for the executive to publicly express greater and greater doubt about implementation readiness – without any specifics - as the ERP go-live date gets closer.

Uncommitted leadership puts the project manager and the ERP implementation team in an intolerable dilemma. The intolerable dilemma is the choice that must be made at that point: (a) providing unequivocal proof to the C-Level that the team is not getting executive support (b) aborting the project for a stated reason other than lack of executive support or (c) continuing with the implementation, with the project manager assuming the increased risk. Choice A - which is the best answer for the overall company - is difficult to execute (because clearly the executive in question knows how to be duplicitous) and will likely have an adverse effect on the project manager’s career after the project is done. Choice B only buys time and costs money; the ERP project – and the problem – still need addressed. Given the relative attractiveness of these two options, it is not surprising that most teams default to option C and hope for the best.

The good news about this type of failure is that it tends to be an ROI failure, not a business disruption failure. Because the right people were not involved in design, strategic decisions, review, and expectation setting, the whole solution was conceived of and implemented by middle managers. It works, sort of, but is not much improvement over what came before.