Re: Progress reporting
Those of you who have some sort of formal/semi-formal way of
reporting your progress on documentation projects, what do
you do?
Hi Kevin,
Check out Joann Hackos' Managing Your Documentation Projects. It's a rough read (which is kind of ironic, I guess!) but has some interesting ideas on how to quantify the process of designing and creating documents.
Consider this formula:
Work effort = (hours per topic) X (topic count) X (a factor of quality) X (a factor of risks and dependencies)
For example,
- 4 hours per topic (from the last topic)
- 100 topics (based on an initial assessment of scope)
- 75% quality factor (which is, for example, a document without an index or graphics)
- 125% risk factor (because, for example, the product won't be available for another 2 weeks and looks like it will be less stable than the last project)
That works out to about 380 hours.
Of course, those factors are attempts to make things more mathematical than they are. The trick is to decide on what the factors are, and stick with those decisions. If you stick with the decisions, and change them only based on the actual experience of a project, the numbers will get more accurate and useful over time. I'm oversimplifying hugely. But you get the idea.
Here's a caveat -- I'm a big advocate for planning, but only when it brings a demonstrable value to a project. As anyone who has built a skyscraper or developed software knows, there comes a point at which you have to shoot the architect and get to work.
The process is far from perfect, but it's documented and repeatable, and better than having no process at all, for a few reasons:
- I am also a lone writer, so I'm often pulled in a few directions at once. When a new project arises, you're better able to assess the effect on other projects.
- I am the only one at the company who has much experience with documentation. Having a process in place makes what you do more transparent to the people who sign your paychecks. When they ask what you do, you can tell them in precise terms.
- I work at a company that (like many others) has fairly quick, unpredictable release schedules. When a deadline gets moved up, you have defined chunks that you can remove to save time, or use in negotiation (e.g. you can reduce the quality to meet the deadline). Essentially, when things change you can make conscious decisions about how you're going to proceed, instead of just having another Red Bull and hoping for the best.
Good luck,
Brian
_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Robohelp X3, from eHelp, lets you quickly and easily create professional Help systems for all your Windows and Web-based applications, including Net.
Buy RoboHelp Office X4 by June 13th and receive
$100 mail-in rebate, Plus FREE RoboHelp Plus Pack.
Order RoboHelp today: http://www.ehelp.com/techwr-l
---
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.
Previous by Author:
Re: # Frame Users
Next by Author:
Re: "Wi-Fi" origin?
Previous by Thread:
Re: Progress reporting
Next by Thread:
Re: Progress reporting
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads