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.
Jeff Scattini wonders: <<My manager's manager wants to create a
comprehensive training system for one of our software products that
will culminate in a certificate of competence to reassure the
countries that we serve.>>
You might want to explore some of the other certifications available
for really complicated software. None will apply exactly to what
you're doing, but each will give you insights into the kind of
perspective different developers take towards certification. One form
of certification should be close enough to what you're doing that you
can adopt its general principles, mutatis mutandis.
I believe Adobe has such a program, but probably the best-known one
is the MCSE (Microsoft Certified Systems Engineer) and its related
MCP (Microsoft Certified Professional) programs. An overview of this
program and links to other certifications can be found at <http://
en.wikipedia.org/wiki/MCSE>, though you'd probably be better to go
direct to the source (http://www.microsoft.com/learning/mcp/
default.mspx) for details. Sun, Red Hat (linux), and others offer
comparable certification, but you can find MCSE and related training
guides in any good bookstore.
<<The manager would like to start implementing this training system
by the end of the year. The program is large and complicated and
incredibly interdependent on different lines of parallel functions
that eventually intersect to generate forms and reports.>>
In this case, the certification should focus on the really important
parts, namely how to string all the functionality together. Think
"high level", not "command X in the Y menu". Those lower-level
details are also important, but are essentially useless without a
deep understanding of the framing context provided by higher-level
issues such as the overall software metaphor, how different parts
work together or conflict, and so on.
This is not an easy task, because it requires you to understand the
product at a very high level. Talking to product managers and senior
developers can provide insights into how _they_ see the product and a
reality check on your own perceptions. Interestingly, and as an
aside, this kind of analysis will occasionally reveal parts of the
software that simply make no sense (usually because nobody ever did
this exercise before designing the software) and other parts that
make a great deal of sense and whose methodology should be integrated
into the other parts as soon as possible.
<<Add to all of this that I'm not intimately familiar with the
program myself and the relevant information is scattered across a
number of training presentations and a number of different SMEs and
I'm at a loss on how to move forward in an effective and efficient
way.>>
Step 1, then, is to identify all these materials and all these human
resources, and create a diagram (however primitive) that shows their
interactions and unites them into something resembling a logical
order. Then take a deep breath, forget about the magnitude of the
task you're about to start, and dive right into it: focus on the
first link in the chain, then the second once the first is complete,
and so on. (I've heard it said that nobody would ever write a book or
manual if they fully appreciated all the work involved. I can say
this from personal experience too, having just completed my own first
book -- see below. For people who believe this, the focus on smaller
chunks can be very reassuring and can give you the confidence you
need to get started.)
Another aside: if you find that nobody possesses the full global view
of the product, make sure everyone knows that _you_ now do. This kind
of knowledge is tremendously valuable to developers, and can be a
great way to make yourself a value to them... once they learn they
can come to you for information that you'll share with no strings
attached. At some future point, you can begin creating resources such
as an intranet to compile all this information into one place so it
will be available to everyone. Talk about proving your worth!
----------------------------------------------------
-- Geoff Hart
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
www.geoff-hart.com
--------------------------------------------------
***Now available*** _Effective onscreen editing_
(http://www.geoff-hart.com/home/onscreen-book.htm)
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
