TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I agree with Christina Hutchings, in that there needs to be an appropriate
level of visibility and accountability for all changes requested.
The problem is that change typically is not specifically managed at all. It
usually is left up to the person doing the production work to "do whatever
it takes".
Requested changes need to be assessed for their impact on schedule, budget,
and on people. Change should be formalized and managed.
As a manager, I have had good results treating each deliverable as a
mini-project with its own contract. The people who have a vested interest
in the deliverable sign the contract. Someone takes accountability for all
project steps from planning through production to delivery. Deadlines are
specific. The contract should clearly identify the scope of the project
(i.e. content of the document). A standard procedure for requesting changes
should be established - that includes forms, a review process, and a
feedback system. Changes can be categorized as (1) Change in scope, (2)
Content Update, or (3) Error. Scope changes are submitted to a review
committee. Some changes should always be incorporated (e.g. safety issue to
prevent potential injury). On the other hand, some changes can wait for the
next release.
Document Configuration Control should be a requirement. Once a deliverable
passes a critical date (freeze date, review date), then specific rules
should be applied to that document. This is a quality control principle
applicable for any industry.
It does not matter what procedures or rules are established. The key is
that everyone involved must "buy-in". This is a people business, and the
relationships established with all of the vested parties are very important.
The goal of the "mini-contract" is to improve communication and
understanding, and to clarify everyone's expectations - it should not be
used as an absolute to hold people's feet to the fire. On the other hand -
that may be necessary to get the job done within a given corporate culture.
If there is not a change management process in place, the end result will be
a publications (or training) department that is event driven (by other
people's fires!!).
Changes can also be handled using interim measures - such as publishing
"Interim Change Notes". The bottom line is that changes should not
negatively impact the agreed upon "mini-contract". This helps protect the
people who are trying to remain sane while producing the deliverables.
IMHO
Warren Phillips
Training & Documentation Consultant (aka Information Developer)
Lucent Technologies, Inc.
==========
phillipsw -at- lucent -dot- com
