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.
How does management track your development team's progress in writing code?
Maybe that same technique would work for documentation too. But first make
sure you accurately identify how your management tracks development.
The answer might lie in your project plans. Most IT project plans I see have
a fairly complex project plan for development that breaks the planning and
coding effort down into an elaborate waterfalled sequence of
compartmentalized steps, with each development task broken down into its
parts and dependencies carefully defined. You can track each individual step
and identify its percent complete, which gives you an idea of overall
progress.
But keep scrolling down to the bottom of the Gantt chart, and you will
usually see a single line item for "Documentation" going all the way across
the project - no complexity, no dependencies, no sequenced steps. Since
there are no individual steps to be tracked, the only possible metric is a
binary Complete/Incomplete.
Is that what your project plans look like?
One solution is to write the doc sub-tasks yourself. In other words, take
that single "Documentation" line and add all the required predecdessor tasks
and dependencies, break it down into milestones, etc. If somebody outside
your department needs to provide info or assistance, buy some new software,
meet with you to describe the planned architecture, whatever - create that
as a task and assign that person to it. Then ask your project manager to
merge your documentation plan into the main project plan. Depending on your
project manager, the project manager will either (a) be grateful that
somebody else wrote the project plan, or (b) slap you for being cheeky.
Your management is seeking a meaningful metric where none is to be found.
Since the numbers they are getting aren't meaningful, they are trying to
impose meaning on them. Management deeply wishes that technical writing
could be measured by something like page count. This would make tech writing
less of a knowledge skill and more of a commodity. Unfortunately, tech
writing doesn't work that way.
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
