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.
Subject:A Long Time Ago From:"James Barrow" <vrfour -at- verizon -dot- net> To:"'List,Techwriter'" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 23 Mar 2007 06:27:46 -0700
In a Tech Pubs department far, far away...
In my little part of the world there's an IT department (me), and a project
management office (PMO; them). The org chart for our entire organization is
very strange. Project managers don't really get down in the trenches and
manager projects. Instead, they sit in ivory towers and allocate resources,
create timelines, etc. IT managers do all of the day to day activities.
The IT dept. has a dozen current projects and zero documentation. Zip.
Nada. None. One of these projects is upgrading a system (legacy app) that
users have been using for several years. The new app contains significant
changes, but is based on the legacy app. The developers for the new app
have been hired and are sitting in the cubicle farm...doing nothing. Why?
Because they need some sort of documentation for the legacy app before they
can proceed.
More background information:
There are 12 software modules used by 10 different facilities, and they have
all established ~50 processes and procedures that are different from
facility-to-facility. So my plan was to select the two largest facilities,
interview the users to capture their critical processes, then produce a Tech
Design, Business Use Case and Business Requirements for each (remember, I'm
reverse-documenting this)*. This resulted in a doc plan consisting of 16
documents. The IT department was happy.
Enter the PMO. "Oh no, no, no. You must document every process and
procedure, for every module, for every facility." This increases the doc
plan to 133 documents...due on April 13. Doable? I have no idea any more.
So here's the question: In your opinion, what documentation do you think
would be necessary to assist developers in creating a software upgrade?
* My logic is this: The Business Requirements provide a straightforward
list of what the original stakeholders wanted the system to do. The
Technical Design doc would show them the specs. The Business Use Cases
would provide a 'story' showing the basic "Ws" (who, what, where, when,
how).
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-