ommunicate a Vision of ChangeBy Myles Bogner and David Elfanbaum | Posted 2011-04-06 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
Leverage your change management practices with agile development teams to foster IT delivery adoption.
Communicate a Vision of Change
In the book The Heart of Change, co-authors John Kotter, the Konosuke Matsushita Professor of Leadership, Emeritus, at the Harvard Business School, and consultant Dan Cohen, view the core pattern associated with successful change as “see-feel-change.” To move stakeholders from negative thoughts, an ECM program must communicate a vision of the change that is compelling enough to both overcome negative preconceptions and motivate positive participation.
Some IT and project managers tend to treat people who will be affected by software initiatives as if they were Vulcans, not humans. Of course, most individuals are more like Kirk than they are like Spock: They don’t rationally evaluate information and form impressions based solely on logic. Instead of withholding judgment on an impending change—such as a new software initiative—people tend to make gut-level intuitive leaps that are often negative and resistant.
In Switch: How to Change Things When Change Is Hard, authors Chip and Dan Heath use the metaphor of “Rider, Elephant and Path” to describe three primary areas that must be addressed in change management.
The Rider is our inner Spock. A stakeholder cannot support a change until he or she can understand its purpose, as well as the concrete changes that will likely occur. The 50-page technical documents and 100-element flowcharts that developers often create must be translated into clear, high-level infographics for nontechnical people.
The Elephant represents our subconscious and emotional levels. ECM can influence the elephant through communications that create positive feelings and mitigate negative emotions, such as mistrust, anxiety and anger. For instance, messaging may focus on how the change will solve an existing problem that vexes stakeholders.
The Path addresses the environment in which the change occurs. These include alterations to the physical environment (such as the arrangement of office space) and processes or procedures (such as Kanban, a just-in-time production concept).
There are a number of formalized ECM models that have been developed to standardize change management within organizations, with processes and practices that support the entire lifecycle of a change initiative. The principles and activities described in this article can be adapted to any existing corporate ECM infrastructure. They can also be applied in organizations that do not yet have an ECM process.
Ironically, the more successful an agile project is in rapidly developing new capabilities, the greater the ECM challenge may be. Although agile’s customer-led iterative approach significantly reduces the magnitude of changes related to each software release, it greatly increases their frequency. Instead of having to adapt to a single release with a significant number of changes created within the waterfall sequential design process (typically with multiyear release cycles), stakeholders must deal with a series of small, incremental releases every month or two.
Having an ECM program is especially important for enterprises transitioning to agile from a phase-based development methodology. Corporate cultures that are accustomed to traditional development release cycles can be strained by a shift to more frequent releases and the higher level of stake-holder involvement required throughout the process.
The impact of a new agile implementation cuts across technology and functional groups, from top management down to the frontline worker. An ECM effort can help break down the sensation of feeling burdened that’s caused by the need for day-to-day customer involvement.
Introducing basic ECM concepts to an agile team can actualize the potential of existing agile practices to foster positive change. For instance, customer-focused user stories and acceptance tests can be informed by ECM considerations.
This new perspective can tangibly improve the way the IT and business sides of an organization work together. The resulting synergies build a heightened level of trust and provide a means to measure and track the success of both the technical quality of software and its acceptance by users.
If the customer already has an institutionalized change-management practice, bringing ECM personnel into the agile team’s release-planning process is a good first step. They will be able to anticipate potential change-management issues related to a release and work with the team to synchronize their efforts. For customers that are transitioning to agile from a traditional waterfall methodology, ECM involvement is a good tool to foster participation by business stakeholders.