Sometimes I feel like Sisyphus, compelled for eternity to push a huge rock uphill only to watch it roll back down again.
“A couple of Power Point overviews, some manager talking points, and a few audience-focused launch messages and we should have what we need to complete this project,” the project director informed me. “We need to be really focused to get this project completed on time and within budget. There’s no time or budget for stakeholder assessment or feedback, and besides, the technology is fairly intuitive.”
And the rock rolls back down . . .
I had been asked to join the implementation at the eleventh hour, one week before the kickoff meeting, and was listening to the project director clarify the scope of my assignment. He had not planned to include a change resource until an executive wondered out loud during the previous week’s steering committee meeting whether someone was in charge of the “change management” for the implementation of the new travel and expense system.
A week later I was sitting with the project director wondering the best way to roll the rock back up the hill.
The project team was composed of highly skilled IT implementers who were effective people managers and driven to work Herculean hours to bring the project home under budget and in record time. They had a laser sharp focus and the ability to ignore anything and everything that would prevent them from getting the job done. Despite those factors, the warning signs were there:
- The budget and timeframe had no room for error,
- Change management was an afterthought for the project manager, but on the mind of an executive,
- Change management activities were added at the last minute to “check the box.”
Whenever a project leader minimizes the value of change management—especially when an executive expresses concern—there will be problems lurking. It’s a variation of Murphy’s Law.
Initially, the problems may surface as technical glitches or insufficient system capabilities. But the longer the problems persist, the more it becomes apparent the issues are something beyond the technical. The requirements are incomplete or inaccurate. The end-users are concerned about functionality or required changes to their work flow. The tool doesn’t integrate with other technologies that support related work processes. Managers or administrators feel threatened that the new tool will negatively impact their authority, expertise or job duties.
Even if there are no problems during the implementation, once a change is ready to “go live,” the organization usually needs more than superficial information about the changes they are about to experience.
Checking the box of change management means that the tail is wagging the dog. Organizations initiate change to improve the business, not simply to complete a task. This means that change always has a purpose. But if the purpose is ignored in favor of the details of the task, then the risk—the likelihood—is that the purpose will not be achieved.
Change initiatives are understandably run as project management exercises. It ensures that implementations are on time and within scope and budget. The tools of project management provide a mechanism to manage the technical components of an initiative with comprehensive attention to detail. But projects are about so much more than the technical. Whether the project is a technology implementation, reorganization or merger, a new program or process, a change of strategy or a change of policy, change initiatives are by definition designed to change the way the business performs.
The discipline of change management provides the mechanism required to complete the business transformation. Change management enables project leaders to identify how job roles will be impacted. It defines the future skills and competencies required of employees. It provides coaching, mentoring and communication strategies to support front-line supervisors. It engages employees in the design process and it gathers feedback to make sure technicians create solutions that will work in reality. And it also helps project leaders understand how to adapt the initial plans to increase the chance of delivering on time and within the budget.
Do project leaders need change management? No. Darwin was right. People adapt. But if you need to accelerate the pace of evolution and reduce the amount of turmoil along the way, then you must go beyond checking the change management box.
3 thoughts on “Checking the Change Management Box”
People will change, especially if there are both incentives to change and penalties for not doing so, however over what period of time and with how much lost time and energy? Too often systems engineers think it’s a “Field of Dreams” scenario – Build it and they will come, however more times than not, it simply doesn’t work that way. You need to engage your constituents in the process early, make adaptations based on testing and feedback, and most importantly, engage senior management as early adopters and best practitioners. I can’t tell you how many systems have been scrapped for lack of adoption.
Thanks for your terrific insights, Chris. It sounds like you’ve experienced the challenges of life on the front lines. Your Field of Dreams analogy is spot on and shows that optimism is no substitute for engaging stakeholders early . . . E