SIGDOC Newsletter
September 2003
:: Volume 4, Number 3
Features
Is Your Organization’s Technical Content in Sync?
By Rob Pierce
Technical communicators are almost unanimously considered writers in
a technical organization. However, technical content does not only consist
of a company's documentation deliverables. There is also a large - possibly
larger than the documentation deliverables - amount of technical content
created by Technical Support specialists in the form of technical notes
that are questions and answers to customer issues. In addition, there
are also training materials, sometimes created by a separate organization
from the documentation team.
Are these separate bodies of technical content - the documentation
deliverables, training materials, and the collection of technical notes
- consistent?
I am interested in learning what our members think about this question?
Is this a serious issue for an organization's technical content presentation
and usability to customers? Or, is it a passé consideration since
most organizations have this issue solved?
How do you make the technical support, documentation teams, and course
training developers of a company be more in sync?
Let’s assume our organization has one documentation team that creates
the documentation deliverables and the training materials. How do you
ensure that all of the documentation is in sync with Support’s
technical notes?
How can the two groups collaborate so that each body of technical content
helps optimize the collective technical content a company provides?
Is there a way of implementing a formal process that ensures writers
query the repository (that is, the database) of Support's technical content
for information that they might not have?
Is it feasible to consider implementing a change management system
that helps track changes and links Support and Documentation teams to
technical
content changes or new information that had documentation impact? Such
a change management system might ensure that information winds up in
one appropriate location, either in a documentation deliverable or a
technical note.
back to top For example, each record in a change management database could define
a field that alerts a documentation group to certain issues or changes
or features with documentation impact. Each record could also have similar
fields designed to alert the support group. An authorized user could
have access to track changes made by both groups.
The goal of such a solution is to improve, across an organization,
the scope of technical content provided by the Support and Documentation
groups. This improvement directly helps customers succeed with using
a product or technology.
If you worked for an organization that implemented such a change management
system, would such a system be useful? If management mandated that you
must follow the process to track changes that had impact on your documentation
deliverables, would you embrace the idea? Do you believe that both Support
and Documentation groups would use a process designed in this way?
The change management system could be the "link" between
the Documentation and Support groups, in order to help the two group
work
more collaboratively and in sync with maintaining their separate repositories
of technical content.
My experience has been that Support personnel are very interested in
such an idea. I would like to see what our readers have to say - both
their thoughts and their experiences in this area.
In looking at the current status of this situation, I would say that
there is a certain amount of redundancy and sometimes inaccuracy (that
is, not the most up to date information) between the content provided
by Support (in the technical notes) and the documentation deliverables.
There also does not seem to be a process or mechanism for both Support
and Doc groups to keep in sync with new content. They seem to more
run in a parallel fashion. Perhaps, if a process was put in place,
more consistency
could be achieved across an organization.
But it is important to remember that creating a process and implementing
a solution with a change management system still requires buy-in from
the people who need to follow the process.
back to top Tools can be designed to implement and facilitate a process but the
value is only realized when people use the tools and follow the guidelines
of the process. Still, you must first design and implement a process
before you can mandate the facilitation. Hopefully, the facilitation
follows when the clear view to its benefits can be seen.
The key to ensuring successful adoption of the initiative is for
both Documentation and Support groups to buy into the idea, so
that it will
be followed by both groups and not just maintained by one or the
other.
Using a change management to help single source information may
provide an optimal solution. By enabling both Support and Documentation
groups
to use the system, each group has a direct link to the other
group's relevant technical content. The groups can then collaborate more
effectively when developing new technical content. They can coordinate
where specific
content belongs.
For example, for a given change request record, a writer could
look at the Support information to verify that it was consistent
with
the documentation.
If the writer detected errors or inconsistencies between what
they read in the documentation with what they saw in a given
technical
note, then
they would have direct access to the Support contact and could
directly contact them to collaborate on what being documented
in each repository
of technical content.
From the Support perspective, this framework might provide
an efficient mechanism to ensure that defects that are found
internally
are
documented as a solution before the defects are discovered
by customers.
If the solution is created and the process to use it is followed
by both Documentation and Support groups, then the development
of your
company's
product documentation deliverables and technical notes will
be collaborative. And the technical content for your company
will
be consistently optimized
for your customers.
back to top |
