|
In last month's issue of the CIDM e-newsletter, JoAnn Hackos
wrote about what makes an effective information-development
manager. The following are responses to that article:
Donn Le Vie
Technical Publications Project Manager
Personal Client Architecture Components Group
Technical Communications Council Manager
Intel Corporation
I'd like to clarify my position for CIDM readers:\
Technical publications organizations or managers need not be
less "obtrusive" or be apologetic for their need to
collaborate with engineering or development. My position is
that engineering/development organizations actually control
the perceived obtrusiveness of technical publications
organizations, so the solution lies with overcoming
preconceived misperceptions. You do that with three central
strategies:
- Have in place a proven high-quality, repeatable
information-development process
- Educate those you collaborate with about your
information-development process
- Understand the language of your collaborators
Have in Place a Proven Process
You have to be able to back up the talk with the walk.
Fine-tune your process so that it works every time to yield
high-quality information products.
Educate Those You Collaborate with about Your
Information-Development Process
To get visibility into technical organizations with whom you
collaborate, you have to teach others—even
evangelize—about how your process works. Show them the
successes from previous projects. Show them on an X-Y plot
how the relative level of effort (RLOE, Y-axis) for everyone
increases during the development phase of a project when
they first engage the information-development team during
that phase (the X-axis shows the various phases of your
organization's product life cycle). Then show them an X-Y
plot of the much lower overall RLOE over the project life
cycle when they engage the information-development
organization during the earlier stages, such as the
exploration or planning stages. This comparison works great
when your information-development project-management life
cycle parallels that of the product life cycle.
Understand the Language of Your Collaborators
Information-development professionals—especially
managers—need to be very good at shaping the environment by
influencing or persuading others. We also need the skills to
work conscientiously with existing circumstances to ensure
quality and accuracy. It also helps that we excel at
cooperating with others within existing circumstances to
carry out tasks or strategies. These
characteristics—influence (I), conscientiousness (C), and
steadiness (S)—comprise three of the four Dimensions of
Behavior characterized by the Personal Profile SystemŽ. The
fourth behavioral dimension is that of dominance (D), which
is characterized by an emphasis on shaping the environment
by overcoming opposition to accomplish results. People
exhibiting this behavior (engineers and programmers are
notoriously high D types) tend to make quick decisions and
solve problems without consulting others (they prefer to
jump to the solution space without defining objectives or
much planning), are highly task-focused to get immediate
results, and have little patience or interest with any
projects, programs, or initiatives that distract them from
their task-oriented, problem-solving environment.
For balance, high D-type people need others who are skilled
at weighing the pros and cons; who can calculate risks;
structure a predictable environment or process; research
facts; who can deliberate before deciding; and who recognize
the needs and input of others. If you know how others
process information and approach their particular
professional specialty, you can be more effective in getting
your message across.
JoAnn and I point out that there's no need to be apologetic
or unobtrusive. Don't wait for an invitation from
engineering or development; inject yourself into the process
as a stakeholder. Your job is to ensure your organization
produces top quality, value-added information products. The
proper balance of assertiveness, diplomacy, education, and
moxie will go far in changing the misperceptions engineering
or development has about "obtrusive" information-development
processes.
Donn Le Vie
Tim Grantham
Supervisor, Documentation, Thermo CRS
www.thermocrs.com
I think that information developers should not only not
apologize for what they do but also actively evangelize
throughout the organization for the business benefits of
their expertise. Here at Thermo CRS, the documentation team
not only produces all the hardware and software product
documentation, it also produces and maintains the content of
the Web site, edits and sometimes writes marketing and
corporate communications, produces training materials,
writes the work instructions for the production staff, and
provides training to all staff on business communications.
It wasn't always this way: I was originally hired to create
a documentation team that only produced traditional
documentation. But by persistent lobbying, volunteering,
demonstrations, developing business cases, and some
shameless bragging and flattery, I was able to convince the
company that the documentation team could add a ton of value
to communications performed by other functions in the
organization.
I guess what I want to say to information developers is
"think big, and deliver."
Regards,
Tim
|
