A Long Time Ago

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).

Thanks,

Jim

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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 &amp; 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 &amp; Manual: http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.


Follow-Ups:

References:
RE: A breakthrough: From: Kathy Bowman

Previous by Author: Visio Question #1
Next by Author: RE: e-publishing a catalogue
Previous by Thread: RE: A breakthrough
Next by Thread: Re: A Long Time Ago


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads