Like most technical writing teams we are small in number. As such, monitoring and tracking both the work that needs done as well as the work that is in progress can be a challenge.
So I’m currently casting my net far and wide to find a good way to keep a handle on this so that I’m always reasonably up to speed with where we are in the grand scheme of things. Forgive me if the following isn’t particularly well delivered, as I am thinking this through as I type it up.
First things first, we need a plan. Actually we need two. One is a high level map of the documentation structure for the entire product so we always have a view of what we are writing and where it will go, and the map will include indicators about the audience so we know who we are writing for at a given time.
Then we need to plan the next batch of work inline with the development teams, estimating what new content is need and how long it will take. Alongside that is the daily churn of small bug fixes and enhancements, some of which will need to be documented, and the supported streams of older versions of the product as well.
The occasional request via email rounds out the various routes in which new items of work are generated.
I’m ignoring, for now, passing comments by colleagues (most times I’ll just email them to our team email alias to make sure we’ve captured the request).
So, project plans, topic breakdowns, bug fixes and open requests for more information. Nothing to out of the ordinary I’m sure, nothing that each and every technical writer has to deal with.
Which begs the question, how DO you deal with it all? Over to you, how do you track your work?
For a high-level map with LOTS of drill-down options, ability to add notes, milestones, URLs etc., output to Office docs (including Word and Project) and a complete website of the map, consider MindMap (http://www.mindjet.com).
For general estimating, understanding what’s to be included, etc. take a look at Jean Hollis Weber’s “Is the Help Helpful?”. The checklists at the back are worth the price of the book alone (http://astore.amazon.com/cybertconsul-20/detail/1930919603).
I’ve worked only at two places…
At the place I am currently with, we use in-house products. One of them is free-to-use.
For project plans: Rational Team Concert (RTC)
For topic breakdowns: IBM Task Modeler
(http://www.alphaworks.ibm.com/tech/taskmodeler)
For bug fixes: RTC + Rational ClearQuest
For open requests: Same as that for bug fixes
At the place I was earlier:
For project plans: Microsoft Project
For topic breakdowns: Microsoft Excel (grin)
For bug fixes: Microsoft Excel or, sometimes, Bugzilla
For open requests: Emails.
I can’t really suggest anything for the plan or map of documentation structure, but have you considered a lightweight service management approach to the development process? Changes for planned work or work in progress (plan/build/test phases), releases when the changes are put into production, defect/incident and problem tracking for dealing with bugs and general requests/feedback. Something easy like Beetil could help you out there (yes I’m biased 😉 but we use it ourselves for similar activities)