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.
> A related subject is project management. I'd like to read not only
> how you (other writers) plan projects, but the tips you have for
> sticking with your plans.
That's a really good question. Documentation plans do, as you suggest,
have a *lot* to do with project management.
Fortunately, by the time you need to develop a documentation plan, there
is usually a product plan already in place. The product plan is usually
the result of agreements made by the managers responsible for each of
the key elements in the project (product development, financial advisors,
procurement, quality assurance, manufacturing, etc.) The managers, of
course, don't like to commit themselves or their departments to any
unrealistic schedules; and, of course, they want to be sure that they
have the resources (people as well as money) to meet their commitments.
As a documentation planner, your goal is the same. You want the cost
estimates and the schedule to be realistic. And, like the product
managers, you want to avoid any nasty surprises. After all, changes
cost both time and money. So ... the best tip I can give you (or anyone)
is to see the plan as a means to identify problem areas and risks early
in the schedule. In other words, the plan is more than just a schedule
and a set of instructions; it's an attempt to avoid crises by not letting
anything "fall between the cracks."
Another tip (which I learned the hard way) is: do *not* be so anxious
to impress someone or so eager to appear capable of handling the job
that you agree to an unrealistic schedule; if you do, you'll be forced
later to either compromise the quality of the documentation or ask for
more time.
Also, keep in mind that no one wants to be the first to tell upper
management that they need more time -- and that fact can result in
some game playing. If that happens, your best bet is to simply wait.
Then, when product development or quality assurance requests more time,
you will have an opportunity to justify more time for the documentation
based on the slip in development schedules.
I apologize for rambling ... but I promise to wrap this up soon ....
A plan can help you manage change because it requires management review
and approval, and it forces you to focus on things like:
- What is the reason for the changes?
- Are the changes really necessary?
- What are the benefits vs. the drawbacks?
- Do the changes improve the quality of the product?
- Will the changes require additional documentation?
- Will the changes require additional writers?
- What impact will the changes have on other departments?
- Is there an impact to delivery dates?
- Are the additional costs for the changes justifiable?
Sorry for the long append. Hope it's of some use to you and anyone else
interested in doing documentation planning or project management ....
Lori Lathrop
Lathrop Media Services
P.O. Box 808
Georgetown, CO 80444
(303)567-9533
INTERNET:76620 -dot- 456 -at- compuserve -dot- com
