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.
Many thanks to all who replied to my e-Learning strategy question. It looks
like I've got a lot of reading to do - hopefully once I've gone through it
all I'll know more than I do now!
============
Sanjay Srikonda replied:
<snip>
ROI is a very difficult thing for most
companies to point out when they cite documentation. Although happily, the
trend is changing in a lot of places, the larger the place, the more
"enlightened" I'm finding they are in terms of taking into account the true
meaning of documentation in their overall project plan.
1. What are you existing resources, do you have limited ones more in one
area than another?
2. Do you have a product that is already requiring "tech support"?
3. Do you have any feedback from clients as to what THEY want? A lot of
times a company will do what they perceive the client wants instead of
asking the client what they want.
<snip>
He also pointed me to the following article on ROI & general documentation:
John Locke suggested needs analysis with respect to the highly-customizable
end of our software:
<snip>
Documenting the advanced stuff is entirely necessary, but may only be
used by your own developers. Most companies these days want to install
products out of the box, even if it's enterprise level. Most customization
happens at the interface level--very little behind the scenes.
These conclusions come from my observations of customers of software that
provides a platform for expert systems, which sound similar. While the
customer will do endless tailoring and tweaking of the configurations, very
few will actually script anything sophisticated. If you want them to use
the
advanced part of your product, you're going to have to convince them (your
customers) that:
1. It's not difficult.
2. It will take x amount of developer hours for a solution of y complexity.
3. I can show you how to do it right the first time.
4. The end result will save you z dollars.
I've done just a little WBT in the past and have found one of the chief
advantages is that you can layer information in such as way as to allow the
learner to dig as deeply as they need to for their own understanding.
Within the same lesson, you can present an overview of the basics, and one
click away, you can nest a secondary lesson on a subtopic for those who
might be having trouble with the concept. Within the subtopic, you can
provide another level of information ("Want to learn more? Click here!")
that will allow the learner to follow their own mind. It's generally
advised
not to have more than three levels of information, or the learner is more
likely to get lost.
The same principles apply to online help.
The advantage to this approach is that you can pretty much dip into the WBT
with whatever resources you have and make incremental improvements without
a
major overhaul or a substantial investment.
===================
In addition, I reread the "Measuring Returns on Investments" chapter in a
very good book I have on CBT/WBT. It actually had some formulas you could
use to calculate ROI on a WBT project. Once I get through this reading
material I plan to try plugging some #s in. If it's useful I'll post the
results to Techwr-l along with the actual name of the book (sorry, it
escapes me at the moment - but it was recommended to me on Techwr-l awhile
back!!)
Thanks to all,
Abby Schiff
Director of Documentation
FactSet Research Systems Inc.
=========================
ORIGINAL QUERY:
<SNIP>
I work for a financial online/software company. We're in the process of
developing Web-Based Training (WBT) for our clients. So far we've stuck to
creating lessons on 'the basics' (essentially, the point-and-click stuff in
our software). However, now that that's done, we're not sure if we should:
(a) go for more depth across the basic subjects;
(b) try our hands at creating modules for the hard-core,
super-duper-powerful, customizable aspect of our software (which involves
learning a simple query language, writing code in it, & dealing with all
the scenarios and what-ifs that come with its infinite customization
possibilities.)
We do have a first-class help desk, so this is not an immediate do-or-die
question. However, we have limited resources in Documentation (which
produces the tutorials), Training (which runs first-rate instructor-led
training sessions that unfortunately don't reach enough users at once), and
Tech Support (which answers questions from users far and wide). In an ideal
world we'd have enough resources to 'do it all,' but we want to spend our
existing resources in the best way possible.
Is there any research available on the return-on-investment for creating
WBT on simple vs. advanced subjects? OR, is there any anecdotal evidence
from Techwhrl-ers who've encountered this type of situation?
<SNIP>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by DigiPub Solutions Corp, producers of PDF 2001
Conference East, June 4-5, Baltimore/Washington D.C. area. http://www.pdfconference.com or toll-free 877/278-2131.
---
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.