[77] in magellan
Good Reading: One Project, One Voice
daemon@ATHENA.MIT.EDU (Greg Anderson)
Mon Mar 1 09:00:00 1999
Date: Mon, 1 Mar 1999 08:59:14 -0500
To: itlt@mit.edu, magellan@mit.edu, cavan@mit.edu
From: Greg Anderson <ganderso@MIT.EDU>
Cc: DISCOPRT@mitvma.mit.edu
Good morning,
As part of the Enterprise Printing Project, Tim McGovern posted this
article to the team over the weekend. It may be of interest to many of
us involved with projects around the organization.
Greg
--------------------
http://www.computerworld.com/home/print.nsf/all/9902088E66
<bold>An effective communications plan can ease the pain that a big IT
project brings</bold> By <bold>Rick Saia02/08/99 It's time for the
big project. You have your budget, your assignments, your schedule,
your sponsors. But you're still not set -- in fact, you're setting the
stage for anger and frustration if you don't have a comprehensive,
effective plan for communications among everyone , the project will
affect.
"Communication really goes to the heart of a lot of IT projects"
because it can help ease the pain of change for end users, says Rob
Hennelly, senior manager of financial processes and systems at Sears,
Roebuck and Co. in Hoffman Estates , Ill. Hennelly created a
communications plan for a recently completed data ware housing
project.
In an IT project, Hennelly says, certain steps need to follow the
others, "and a communications plan is no different." The steps "need to
be part of an overa ll plan, and they need to build on each other," he
says.
How do you build a communications plan? It must contain three basic
steps:
* Identify your audience and its communications needs. Talk with users
who will be affected. Ask them what they need to know and how
frequently they need to know it.
Consider the needs of the divisions you may be working with, suggests
Fred L. Craig, year 2000 manager at the Automotive Industry Action
Group. Craig, who has developed communications plans for information
technology projects at General Motors Corp., says that, for example,
senior management may want reports in short synopses, end users may
want general messages, and a technical audience may want something
else.
The most important things users want to know, says Wyette Spotts,
manager of systems and programming at Universal Underwriters Group in
Kansas City, Mo., center on the question, When? If, for instance, their
new desktop operating system will be installed or they have to take a
training class or something else that will affect their workday, they
will want to know dates, times and the length of time involved
beforehand -- in writing.
* What are the most effective methods for communicating with the
audience? How does it want to receive news? There appears to be no
substitute for face-to-face communication, followed by phone calls,
Hennelly says.
He recalls a three- to four-month-long project affecting a 400-person
accounting group at a Sears office in Dallas. Four people sent there
from company headquarters in suburban Chicago helped ease the pain of
change "by just being there" and talking with the people in the office
during the project. "We built that
bridge between them and the [project] team," he says.
A good idea, Craig says, is meeting with groups of users. They will
tell you what you've done wrong, and "they're usually not bashful," he
says.
Spotts says that though he believes talk is fine, a project's official
mode of communication should be in "black and white," either on paper
or via E-mail. Follow up verbal communication with a written version,
he advises. That gives you the opportunity to bring across a point you
may have missed in a conversation, he says.
But if you're going to use E-mail, keep it short, to the point and
nontechnic al, emphasizing key points with graphical bullets, says Jo
Hoppe, CIO at book pu blisher Addison Wesley Longman in Reading, Mass.
"You can lose someone's attention with a lengthy E-mail."
Yet technology can help, Hennelly and Craig say. Craig says he sees
benefits in a knowledge database that people can access for updates as
well as for answers to common questions. He also has found "very
helpful" a database in which people can ask questions or offer
suggestions. A team member can pull those items off the database, and
the questions can be answered "officially" as a team to avoid the
possibility of team members offering conflicting answers.
* Who should deliver the message? To answer that, you may have to
assess how well -- or how poorly -- your IT people communicate with end
users. A project can have two leaders: one from IT, and the other from
the user side. Users tend to listen more to one of their own, Spotts
says. But having a strong leader from the user side can enable his IT
counterpart to focus on the technical end, he notes.
Don't say to a user, "This is what you have to do," Spotts advises,
because y ou risk giving him the feeling that he's just part of a
corporate "machine." Rather, Spotts says, because the user is the one
who's working with the system every day, allow him some freedom in
deciding what he has to do.
If you need advice on crafting a plan, call on your corporate
communications people, Craig suggests. That advice especially holds if
people outside the company -- such as suppliers, customers, unions and
stockholders -- must be kept in the know.
Spreading the Word
When your project is reaching a critical phase, give the most emphatic
message right before the impact, Hennelly says (An example: letting end
users know whe n the project team will begin replacing their PCs).
"Timing is absolutely critical," he says.
The communications structure must be properly in place, Hennelly adds,
or "you'll find yourself having to overcome a lot of bad will."
But even the best-laid plans may not be enough, Craig believes.
"No matter how good your plan is," he says, "you will always find
someone who says, 'I didn't know anything about this.'"
<italic>Saia is Computerworld's senior editor, Managing. Contact him at
rick_saia@computerworld.com. </italic>
<center>
</center></bold><center>
</center>
