Re: Project Communications

["Steven J. Owens" <puff -at- NETCOM -dot- COM>]

David Harrison writes:

> I've just been asked to accept a new task and I'd really like a bit
> of knowledge form the group or just an opinion or two.

> Our company is midway through a major project and they feel that
> their internal communications isn't working as well as it should and
> so they want someone (me!) to address the situation. (heard it before
> huh?) They have an internal communication strategy document which
> lists roughly who should inform who about what and when/how often. But
> like so many other company policy documents, its stays on a shelf
> gathering dust and people moan about not knowing what is going one.

     Well, as a writer you're the communications expert.  Seriously.
In a previous life I was a "product information" specialist at a
company that seemed to have something of a handle on this.  Most of my
following comments are in reference to this company, since in most of
the subsequent jobs I've had, things were far more messed up, and only
got better because of things I brought in from that company.

     At that company, the new director of engineering (a guy from
Hewlett Packard) decided to rename us "Product Information", because
he felt we were important not just as producers of docs for the
outside world, but as information gatherers and sources for the rest
of the company as well.  I think he was definitely right, and to a
certain degree, his push to change the perception of tech docs was
successful.

     Think about it; I don't know about your department, but in that
job, we had about 50-60 engineers and 5 tech writers (and one real
tech writer boss).  The writers worked on several projects each, and
ended up being a lot like "beat reporters".  I frequently fielded
calls from people in different departments (about 200-300 people total
in the company) - and in engineering - looking for the right place to
ask a question.  I held it as a point of pride that I gave people
answers, even if it meant walking down the hallway to check with an
engineer on whether or not they were the right person to talk to.

     At the same time, the change in perception also helped empower
the writers (note, though, that when the office manager came around to
ask us what our job titles were for the new business cards, we all
said simply "writer"! :-).

     Still, you need some specifics:

> Here are the main problems that I can see:

> 1) Any company policy document that exists only in paper form will
> end up on a shelf and die - how do you keep it forefront in people's
> minds? Does anyone have experience of a time manager/scheduler which
> has been used to prompt people to issues regular communications? Is
> this really a matter of mentality and interfacing? Or do we need third
> party to act as memory jogger, nosey parker, aide memoire etc.

     There was an article, a few years back, in the CACM
(Communications of the Association for Computing Machinery) I think,
about why groupware fails.  Five reasons, I remember one was that they
seldom trained the people involved in how to use it.  Another, one of
the biggest ones, was that the people expected to use the groupware on
a daily basis were not the ones that benefitted from it.
I.e. scheduling software that mainly provides managers with a way to
control & track the employees is not going to be readily embraced by
the employees.

     I think people drastically underestimate the power of a simple
old whiteboard.  Make that a simple, BIG old whiteboard.  We had one
at one end of the tech doc (excuse me, Product Information) section,
which listed all of the books currently under development, with
expected completion dates for each stage of development, and the
writer responsible for the book.  This made a great way to stay
"synchronized", and I always thought something similar for engineering
projects (much bigger, outside the engineering director's door) would
have been good.

     One of the most important aspects of the whiteboard is that it's
an omnipresent visual reminder, that the information it conveys
becomes part of the office's daily environment.  Anything that would
replace this role should have the same kind of omnipresence.  That's
why groupware that exists as a disparate part of the desktop
environment isn't likely to be as effective.

> 2) Too many communication strategy items just read "communicate
> matters of importance". People don't seem to be able to decide what's
> important and it ends up as all (information overload) or nothing
> (mushroom theory). Has anyone had success appointing Information
> Managers who attend the majority of meetings with the sole purpose of
> weeding out relative information and ensuring that it gets
> disseminated to and through the proper channels?

     To a degree, that was our job as writers in the job mentioned
above.  We were actually and actively assigned to project teams from
the start, as the information specialist.  Part of our job was to
convey general information to the other writers, who conveyed it to
*their* teams as appropriate.  See my comments below on meetings.

> 3) People who should be receiving information, complain about too
> much/little. Is it best policy to proactively tell them everything
> (this could be regular presentations which allow question answer
> sessions) or passively make it available through intranet,
> noticeboards and newsletters for users to find? Has anyone one found
> another medium which falls successfully between the two?

     Finding the balance point between the two is the trick; convey
enough shallow information for people to be aware, make deep
information available via intranet or some other groupware.

     In the company I mentioned, the writers had weekly meetings.
These worked, and they worked very well, but only because they were
run very tightly and because our boss trained us to be good meeting
participants - I think this is a critical point, she actively trained
us, and she led by example.  Her skill at this may have come from the
news media writing she'd done (TV).  I imagine in that environment,
time is critical.

     First, and most importantly, was simply that she brought a
detailed agenda to the meetings, distributing the agendas a half-hour
or so beforehand if possible.  Each meeting started with us going
around the table and giving a "two-minute summary" of anything new on
our projetcs in the last week.  This was something we worked very
diligently at making quick & painless; she was quick to slate any new
questions raised onto the agenda for the latter part of the meeting,
and eventually we got good at adding them to the agenda ahead of time.
Eventually she started rotating the chair among the writers, week by
week, and making us responsible for assembling the agenda as well.

     Sometimes we used a whiteboard agenda instead of individual
copies of a printed agenda.  There are merits to both approaches - the
printed agenda can be used to make notes, but the white board is good
for keeping everybody focused on the same issues.

     Then came preassigned agenda topics, which had more lattitude,
then free discussion.  Again, the boss and eventually the writers
developed good meeting skills; we learned to figure out when a topic
needed a separate meeting or more research, or just needed to be
tabled for a week to let us mull it over.

     Most of the meetings were about half an hour, plus 5-15 minutes.
Occasionally we had all-afternoon "offsite" meetings at a bar, to let
us be more informal and relaxed.

> 4) Does anyone (preferably this side of the Atlantic as budget is
> finite) consider that they have a really good methodology that they
> would like to share, sell, provide some consultancy or show a visiting
> team?

     Wish I did, but I'm not in the snake oil business :-).

     Anybody you get in to do this sort of thing has to do more than
conduct a one-day presentation to the world at large.  We did some
usability work at the afore-mentioned company; the approach we used,
that seemed to work, was a combination of strong championing by
management, with choosing a small team of employee-level champions -
the writers - and bringing a couple of process and then usability
experts in to walk us through the steps with respect to a real
engineering project.

     It helped a lot that, as the writers, we already had a strong
legacy of championing the user at that company, and we were relatively
eager, looking at the usability project more as additional tools to
help that.  It also helped a lot that the writers were the best
performers in engineering; consistently making deadlines and pulling
off projects, consistently improving the books overall.

     I won't say that the whole department came up to the level of
that project in the ensuing months, but it definitely improved
overall.  A more sustained effort (bringing the experts back in six
months later, maybe this time to work with an engineering team) might
have pushed it farther.

> 5) Can anyone recommend any good reading or source material on the topic

     Most of the reading I could recommend personally is based on the
more general issue of software projects than specifically communication:

     _Code Complete_ and _Rapid Development_ by Steve McConnel
     _The Mythical Man-Month_ by Frederick P. Brooks
     _Death March_ by Ed Yourdon

     In general, the CACM and IEEE Software magazines seemed to have
good articles on this kind of stuff, but I haven't had access to them
in a couple of years.  If you're at a software development company,
you might have an easier time getting management to pay for
memberships & subscriptions to these journals.

> 6) And for anyone who's been there before - do you think that this
> is a genuine opportunity or am I being set up as a scapegoat who will
> carry the can in months to come?

     I'm afraid I can't say.  I don't know your company, but my general
perception is that writers aren't high up enough on the totem pole to
be a good scapegoat.  There aren't enough dependencies that hinge on
you.  On the other hand, if somebody really wants to hang you out to
dry and has the authority, you're kinda screwed.  Good luck.

Steven J. Owens
puff -at- netcom -dot- com


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=