RE: Ready to Scream

["Giordano, Connie" <Connie -dot- Giordano -at- FMR -dot- COM>]

Tamara,

Welcome to my world!  It seems the more complex the application, the more
likely you are to have concerns about business/operations policies and
procedures included in the help system.  You are at a bit of an impasse, but
unless the project plan can be modified to accommodate the time it takes to
develop those topics, you may stuck with just the basics.

If the project calls for a post-mortem after delivery, you should try to add
your concerns to the list of issues.  Best not to attack the other team
members for lack of respect, it gives them reason to continue dissing ;)
Point out that there was a successful delivery, and that your initial
analysis shows the help system to be satisfactory.  However, you can note
that the original scope of the project included the operational info, and
that anecdotal evidence suggests it will be of even greater assistance to
the end user.  Your best scenario may be a compromise.  I've had several
results with this kind of situation:  1)operational stuff should be
incorporated in a future release; 2) Operational stuff is irrelevant, and
should be dropped from any plans; 3) Operational stuff is highly specific to
a client, and can be included if the client is willing to pay for the
additional effort.  4) Operational stuff should be mentioned as additional
resources and linked to the system if possible; 5) strictly internal
products don't really need the operational stuff, because it's available to
employees via the intranet, or a handbook.

It's a little difficult to tell what may be most appropriate for your
situation, I gather (perhaps incorrectly) that this application is designed
for internal use?  You may want to advocate for 1), 3) or 4) as feasible
options, depending on resources.


It's difficult when you want to provide the highest quality possible, and
you feel as if you're being prevented, but some battles are simply lost
causes from the start.  Experience is usually the best judge whether you can
win it here, or just move on.

Good luck, and keep the throat lozenges handy:)

Connie P. Giordano
Senior Technical Writer
Advisor Technology Services
A Fidelity Investments Company
704-330-2069 (w)
704-330-2350 (f)
704-957-8450 (c)
connie -dot- giordano -at- fmr -dot- com <mailto:connie -dot- giordano -at- fmr -dot- com> 
 
"I am always doing that which I can not do, in order that I may learn how to
do it." - Pablo Picasso 



-----Original Message-----
From: Tamara Reyes-Muralles [mailto:trm -at- telusplanet -dot- net]
Sent: Wednesday, April 17, 2002 4:16 PM
To: TECHWR-L
Subject: Ready to Scream



I was hired in October, 2000 to create a Help system for a company that has
never
had a Help system with any of their custom made applications. No standards
or
procedures were place. The project was still in its design phase when I
started.
Today, we are developing the application and it is
milestone two. Before I created the Help system, I did an audience analysis,
created instruction and style standards, and meet with the clients and the
feature
team.  The initial plan was to build a Help system that encompassed the
application
and the department's business rules and operational procedures. As time as
passed,
changes were made to the project and the application.  I created three
levels
of quality assurance checks to
ensure the Help system was being created properly. I had all SME's and the
client
sign off the final draft.  At the end of each milestone, I did
another check on each topic. I would check all hyperlinks, etc. I also, at
that
time, I had the QA manager do a final check to ensure all content was in the
topic. I wanted the QA manager to check everything, because the SME's were
signing
off topics and not even making changes.

The operational procedures were never put into the Help system. Time lines
changed.
 I was instructed to only document the application (project
manager).  The clients that were signing off my topics were the "big" guys.
Recently, a different client has been reviewing topics and the User Help
system.  He is not in management, but a frequent user of the application. He
has expressed concerns regarding the Help system and he feels it is not
being built correctly. He wants the Help to answer questions that are
operational
in nature. I had conducted usability tests with other frequent
users and I was told the User Help system was being built properly. Maybe
this
concerned person has a different perception.

The Help system is being built exactly how I have been instructed. However,
when I started, I did suggest the Help system be built around what the
clients are doing at their desk. For example, what must they do before they
use the application. This suggestion was only noted.

I am ready to scream. The feature team and client underestimated how large
the
Help system was going to be and how much resources would be needed to
make it. For example, how to install, configure and log on topics were never
considered. Nor were topics that dealt with navigating through the
screens, etc. They did not anticipate I would have quality assurance
checklists
in place. They never considered that when a bug defect was logged my topics
would be impacted. For example, when a form is changed, my screen shots have
to be replaced, etc.  To be honest, I underestimated the scope of this
project.
Because I have never been on a project like this, I never considered
everything
I would have to do. Also, I am really getting annoyed with my consultant
co-workers.
The developers have no idea what I do. I am never taken seriously.  However,
even though I am annoyed, I know I can proudly finish the project. My
contract
has been extended to September.

I have a question for the technical writers on this group that have built
many
Help systems.  Have you been asked to document just the application? Have
you
been asked to add operational/desk procedures in the Help?  What
about the company's business and business rules?

Tamara


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com

Are you using Doc-to-Help or ForeHelp? Switch to RoboHelp for Word for $249
or to RoboHelp Office for only $499. Get the PC Magazine five-star rated
Help authoring tool for less! Go to http://www.ehelp.com/techwr

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