Martin, A very relevant question.
First, when you refer to “employees” I am assuming that we are talking about everyone involved including the IT staff developing the project and, most importantly, the group of people outside of IT who will use, and ultimately benefit, from the results.
It has always been my belief that a strategy and plan for managing change associated with any new initiative, whether an IT project or not, should be in integral part of the project plan. This component should be clearly owned by the project’s sponsor(s). Too often IT initiatives contain detailed plans for development, integration, testing and implementation but nothing to manage the cultural aspects of its implementation which are most often manifested as resistance to the changes needed for ultimate success.
I recommend, and use, John Kotter’s 8 step change process (Leading Change, Harvard Business School Press, 1996). Embed the 8 steps into the project plan and execute them throughout the project lifecycle. For instance, the first step, establishing a sense of urgency, is the role of the projects sponsors. They need to clearly articulate the rationale, the “burning platform, and the consequences of inaction. The second step, forming a guiding coalition, is really the interdisciplinary project team charged with making it happen. These people, from both the business and the IT side, must be chosen carefully and provided both incentives to succeed and consequences for failing to do so. The remaining steps can easily be integrated into a plan and should be treated with equal or greater importance than technical milestones.
Finally, everyone should be familiar with Kanter’s Law, “Everything looks like a failure in the middle.” One of the biggest hazards is abandoning the change agenda when problems arise and focusing only on technical things.
In all of my years in this business I have never seen an IT initiative fail because the technology didn’t work. The failure was always caused by human failure and failing to adequately plan for and manage change is one of the main culprits.
This is a terrific question and one that’s always timely, sadly. For as long as there has been IT and IT has been working with employees and business leaders on projects, there have been issues regarding implementation of new systems and applications and, frankly, resistance to change. To me, the key is deep involvement and buy-in from the affected employee base. Unless business leaders and their teams are in full support of goals and initiatives – and they own the results of the change – problems likely loom ahead. IT can’t put itself in the position of being the single point of blame, when it’s really up to the business and employees to speak up for what they want/need, be active participants in the development process, and drive adoption on their end. Part of this is being really specific about the goals to be achieved and who owns the goals. Once that high-level commitment exists, there are a lot of ways to ensure adoption, from having very active team leaders on the employee side who are involved in rollout and training, to having specific plans in place to deal with the recalcitrant, let’s call them, folks along the way.