RE: Building a documentation knowledgebase

Subject: RE: Building a documentation knowledgebase
From: Mailing List <mlist -at- ca -dot- rainbow -dot- com>
To: "'chevotilburg -at- postmaster -dot- co -dot- uk'" <chevotilburg -at- postmaster -dot- co -dot- uk>, TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Mon, 16 Feb 2004 16:37:43 -0500

chevotilburg -at- postmaster -dot- co -dot- uk note:

> The requirements is all very high level- "put all the
> information into one
> area - but it has to be suitable for all depts to access"
> .The first thing
> they want to try is a general template. I am worried that
> this is going to
> be the next run-around the writers have been given in past years.
> We have only one trainer and she, like me, have seen the training and
> writing dept shrink over the years.

If both you and the trainer have (legitimately) full
calendars without this new make-work project, then
something has to suffer -- either your regular work
output or the creation of the new monster.

One thing that you could do is to point this out
and suggest that the company rent the services of
a consultant who has some actual experience in this
area. The consultant would take on the project,
and hand off the resulting database/knowledgebase
(and the secrets of its care and feeding) to you,
when the creation phase of the project is completed.

Another thing to do is to learn just enough about it
that you can put together a convincing proposal,
emphasizing the massive amount of work to be done,
and some likely-sounding stages/phases to accomplish
it. Put in some time-frames with "resource-loading"
of the current writer and trainer "resources". Provide
both the full-time and half-time rates for the workies
who will perform the work (which might be you, or
might be some other person(s)), to illustrate the
effect this will have on your existing planned workload.
You could emphasize the point that what management
wants is probably suitable to a much bigger company;
one that can support a full-time database/knowledgebase

Another possibility is to suggest that the company
engage a consultant merely to lay out the scope of
the work. That should take just a few weeks at most,
and give you a working document on which to base
further decision-making. An advantage is that YOU
don't have to tie yourself in knots, faking your
way through an unfamiliar process, while juggling
your existing workload, and the company doesn't get
on-the-hook for more than a few weeks of consultant
fees. Later, if the company decides to go with
consultant labor to do the actual project, you can
use the document to help in your screening/hiring.
You can also use the document as an authority to
backstop any arguments you care to make about how
the project should be tackled.

A final possibility (if you can't fly any of the
others, and get stuck with the chore) is to make
very sure that you suck as many other people into it
as possible. Emphasize that there's no point dropping
YOUR version of a solution onto multiple groups in
the company. To achieve their buy-in and compliance,
you need their participation in the initial definition
and proposal stages. Once you have a body from each
affected group committed that far, you've basically
got them committed to do (large chunks of) the ultimate
work, too. That very fact will encourage them to
cooperate with you in keeping the scope manageable. They
won't want to saddle themselves with tremendous extra
workload, on their (presumably) already full plates.

My boss' boss, the Veep of Engineering, got it into his
head that he wanted some kind of centralized, repository-
based, re-usable source of data for customer documentation.
I went through minor hell figuring out what this would
mean in "real life". I was looking at several possible
solutions, all of which were massive efforts, when along
came the saviour... our company was bought. The buyers
had recently gone from paper/PDF documents to almost
entirely WebHelp. WebHelp, published via RoboHelp became
my new standard for documentation. Just like that.

So, I spent the last quarter of 2003 converting the bulk
of my Setup and User and Reference guides into Help, using
RoboHelp. Now, everything is an html page. I'm into my
second project -- based largely on the first -- and using
RoboHelp's conditional feature to allow the material to
be selectively published for either of two products. I'll
be adding a third project in a couple of months, re-using
about 50% of the original, adding yet more new content,
and a third set of condition tags to automatically publish
only the desired content for each product/project.
My Veep is thrilled. The support people are looking at
linking my Help pages and their FAQ and Technotes sections
of the company website.
The closest we have to a "training" group is our pre-Sales
Engineering Support and our post-sales Customer Support group.


Previous by Author: RE: GoLive vs. Dreamweaver
Next by Author: RE: errored out, or erred out?
Previous by Thread: Re: Building a documentation knowledgebase
Next by Thread: Re: Building a documentation knowledgebase

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

Sponsored Ads