5. Clear Two-Way Communications
The
difference between implementing changes correctly and implementing them
otherwise can boil down to sound communication. According to the American Heritage Dictionary, 2nd ed.
(Boston: Houghton Mifflin, 1982), communication is defined as “the
exchange of ideas, messages, or information, as by speech, signals or
writing” and represents another best practice for implementing change.
Thus, as the organization tasked with managing change, the change
management team must
Understand that communications can always improve, and therefore strive for continuous improvement Communicate through a standard forum, and in several media if possible, based on the audience Embrace
feedback, so as to improve communication quality and quantity
To facilitate the preceding goals while practicing continuous improvement, a communication plan
should be put in place. The communication plan seeks to reach all
stakeholders, soliciting both input and feedback. It identifies the
various stakeholder audiences, embraces different and effective
communications media, and continuously looks for ways to improve.
Key
challenges to creating and maintaining a good communication plan
include differing physical locations, assumptions, knowledge,
expectations, effort, time, perceptions, barriers between IT
departments, barriers between business organizations and IT, and a lack
of feedback/two-way communications. To minimize these differences, the
following toolsets and approaches are often used:
Monday meetings between the business and IT/SAP TSO Regular weekly SAP TSO staff/follow-up meetings “ERP Team” or other core mySAP Team meetings Published meeting minutes Dialog between management and business/IT groups Project plan schedules with clearly identified tasks, milestones, and responsible parties Business-unit representation within and between the various IT teams that make up the SAP TSO Change management Web site or intranet site Email between and within the various groups, including the use of standard email distribution lists Shared
information/knowledge management repository, for example, a
collaboration site hosted by SharePoint Portal Server, or a Lotus Notes
database, or even a simple file share for starters Various “feedback” approaches (covered later) Department-wide
team-building exercises and other non-work-related activities where
valuable informal communication can take place
Although
the preceding list represents a nice variety of potential communication
methods, the next section illustrates what many of my SAP clients
actually do in their real worlds of end users, customers, and deadlines.
6. Communicating Changes in the Real World
Communication
tools and approaches like the following are used regularly by some of
my customers. Some of these approaches are quite effective, but others
are debatable. Judge for yourself:
Effective:
Leveraging a comprehensive change control application—Quite a few SAP
customers look to the capabilities found in a number of different
change management applications or utilities to manage, track, and
report against their projects and processes. I know of one case where a
Web-based application was written specifically for the customer. In
most cases, though, I subscribe to the “buy it, don’t build it
philosophy”—the same philosophy that drives many SAP implementations in
the first place. Effective: Weekly
change control status meetings, and project plan updates—In this case,
the Change Control manager discusses current projects, pending
projects, and resource issues/constraints with the entire team each
Friday morning. These projects tend to drive most of the changes
implemented in their release strategy, from hardware and OS upgrades to
database migrations and SAP business enhancements. Updates to a master
Change Control Project Plan provide for a single repository for all
notes, updates, resource tracking, and so on. Effective:
Weekly change management status reports linked to a Web site—Like the
SAP customer described in the preceding paragraph, another customer
also meets regularly to discuss pending changes. However, each Monday
morning, the change management team lead disseminates a status update
to a standard email distribution list composed of key business and IT
folks. The current and pending changes are prioritized by functional
area or technology stack. The unique thing about this particular team
lead’s approach is his use of a company intranet site to host all
archived updates, status reports, and other commentary regarding each
planned change or test project. Scheduling, deadlines, and resource
requirements and commitments are highlighted here as well. The site
also serves as a repository for change processes, a vehicle for
feedback (another link generates an email back to the team lead), and
more. Questionable: One of my customers
utilizes a very large dry-ink “whiteboard” mounted in the conference
room where the change manager holds his meetings. There, in black and
white, a running status update is maintained for each change
wave—detailed changes, problems, and the person responsible for
“fixing” the problems are all listed in a matrix format on the board.
Of course, this approach is limited in that future status is difficult
to communicate, the board tends to get messy after a change wave has
been listed a month or more, you have to physically walk into the room
to see status updates, and the risk of losing everything is possible if
an enterprising member of the janitorial staff takes it upon himself to
clean up the board. Questionable:
Another customer of mine takes the use of sticky notes to a new level
when it comes to managing hardware and OS-based changes. Here, the data
center’s operations manager also plays the role of SAP liaison to the
business (in conjunction with the SAP Basis manager, who also owns the
database layer). Planned changes, and the dates scheduled for the
change, are noted and communicated via sticky notes and other labels
that are physically placed on the server or disk subsystem that will
undergo the change. As a change is promoted, the sticky note is moved
to the next server or set of gears in the SAP landscape. In this way, a
sticky note follows the change from development through production. I
am by no means an advocate of this approach, but it would be unfair to
say that it doesn’t completely work. On the contrary, it seems to work
quite well for this operations manager. The approach in general is
dangerous, though, in that we all understand that sticky notes are
susceptible to “falling off” over time. And from a status perspective,
it seems unlikely that such an approach facilitates keeping others in
the loop. Besides, there’s only so much space on a note—updates or
changes to the original plan must make for some really hard-to-read
sticky notes. Questionable: Another
limited approach to hardware/OS change control involves the use of a
binder or log, where future changes and planned upgrades are tracked.
The originator of the change, the name of the wave (if any) that the
change may be a larger part of, and the implementer of the change are
tracked here as well. Although this approach is more “publicly
accessible” than the sticky note approach, I still think that tracking
and mapping changes back to the master project/change control plan is
difficult at best. And I see a lot of opportunity for missed deadlines
and similar lack-of-communication issues. In
the future? One of my forward-thinking colleagues envisions a day when
devices and applications will be smart enough to track and communicate
their own status within the larger scope of change control releases.
For example, an entity scheduled to undergo a change would “know” it by
virtue of a connection to a master project plan. When queried
physically or via a Web browser, the entity would respond with a clear
status communiqué, like “My processing microcode is scheduled to be
updated from 2.41 to 3.10 on Monday. For schedule or implementation
questions, please contact Dave Future. For technical questions, please
contact Jan McKay. And have a great
GlobalXYZ day.” All of this capability would be made possible through
intelligence built into each entity, enabling it to “absorb” its Pert
Chart bubble and information regarding relevant tasks, responsible
parties, and so on. Finally, the actual upgrade would amount to simply
pushing a physical or virtual “make it so” button, complete with
feedback like “Are you sure, Dave? You might want to rethink this move,
as I have been scheduled to run the monthly closing on Monday.” You saw
it here first.
My
recommendation is, of course, to employ all three of the first
real-world communication plans described in the preceding list, as most
of my other customers tend to do in one form or another. Some of the
other approaches might have value, too, but only if backed up by
“robust” communications vehicles like the first three.
|
