Re: Organizational oddity

[Michael Lewis <lewism -at- BRANDLE -dot- COM -dot- AU>]

Your IS people are either missing the point of documentation, or they
have inflated ideas of their interface design skills! Would a car maker
fail to provide an owner's manual? Would a photcopier sell if it didn't
come with instructions? Just because the software's built to order
(presumably with user department input at the design stage) doesn't mean
the user is responsible for figuring out how to use it. Anyway, IMNSHO,
the documentation is _part of_ the user interface; leaving it out means
supplying an incomplete product.

Jane Lorenzen wrote:
>
> I work for a large retailer whose I.S. department has no technical
> writers.  When they develop new software (for internal use only;
> we're not in the software business), it's up to the users to create a
> manual.  Generally, one of the end-user SMEs or managers who worked most
> closely with the developers writes up some how-to information
> in Word.
>
> The problem we're running into (aside from the obvious quality issue of
> having documentation written by end-users with no training, interest, or
> experience in technical writing) involves updating the documentation
> once the software is updated.  The end user representatives who were
> involved with the system development move on to other positions, and
> when changes are made to the systems, the "doc" gets lost in the shuffle
> and is not updated.
> I am the only tech writer in any of the end-user departments.  My
> applications are the only ones that have online help (not many buyers
> or inventory managers are interested in doing winhelp).
>
> In the Information Plan for my latest project I pointed out in the
> "Maintenance" section that maintaining the doc will be done by
> god-knows-whom, because once the project is complete a) the
> client-side project manager's job will be complete and he'll move
> back into a merchandising position, b) I'll be assigned full-time to
> another project, and c) the users certainly aren't equipped to work with
> Winhelp.  Without the continuity of a fixed tech writing department,
> outdated docs, both the online help I've developed in
> past assignments and the paper training guides produced by end-users,
> will be an ongoing problem.
>
> When my manager asked me what the solution might be, I said, "I.S.
> should have tech writers.  They'd produce and update docs as systems are
> developed and updated."  So now he wants me to "write something up" for
> his manager.
>
> It sounds strange, but having tech writers in I.S. is a radical idea
> here.  It's unlikely that we'll convince I.S., which has always seen
> documentation as "the users' problem," to start seeing it as part
> of the services that they provide, especially in our current downsizing
> mode, but I think we'd see a big improvement in both our interfaces and
> our documentation if we could make tech writers a permanent fixture in
> I.S.
>
> Do any of the rest of you report to the end-user department, as opposed
> to the development area?  How do you handle these issues?
>
> Any other comments, supporting arguments, etc., are most welcome.
>
> Thanks,
> Jane
> utarzan -at- hotmail -dot- com
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>

--
Michael Lewis
Brandle Pty Limited, Sydney, Australia
PO Box 1249, Strawberry Hills, NSW 2012
Suite 8, The Watertower, 1 Marian St, Redfern 2016
http://www.brandle.com.au/~lewism
Tel +61-2-9310-2224 ... Fax +61-2-9310-5056