Re: Not given work we *are* qualified for

[Tim Altom <taltom -at- IQUEST -dot- NET>]

Dear Lord, this is funnier than most of the Dilberts I've seen lately! A
colleague friend of ours returned from a long foray into other places and
times recently and recounted how she'd been doing business analysis and
other interesting things for company branches throughout North American and
in Asia. She laughed and said "These are all the things you and I have
always done anyway, but we called it "information consulting" or some such
rather than tech writing. We charged twice as much and got treated
wonderfully."

Tim Altom
Simply Written, Inc.
317.899.5882
http://www.simplywritten.com
Creators of the Clustar Method for task-based documentation
-----Original Message-----
From: Stuart Burnfield <slb -at- FS -dot- COM -dot- AU>
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>
Date: Thursday, April 23, 1998 1:41 PM
Subject: Not given work we *are* qualified for


>I agree that we need to educate people about technical writing, so we
>can concentrate on the work we're qualified for. It's not that we can't
>type memos and take minutes, it's just that other people get paid to do
>that, and we get paid to do different, necessary work other people
>can't do.
>
>I wonder though, has anyone else experienced the reverse?
>
>A couple of times, interesting, unusual tasks have come up that I was
>perfectly suited to. Not because of anything special about me, but
>because they required fundamental tech writing skills.
>
>The first happened when I did my very first Information Plan, a la
>JoAnn Hackos and 'Managing Your Documentation Project'.  I was pretty
>pleased with it and sent out review copies to all the project stake-
>holders, their friends and relatives, passers-by, Craig Shergold, and
>so on.
>
>Everyone loved it. At that stage the company had very good technology
>but a very haphazard process. No-one had ever seen a single document,
>written near the start of a project, that described briefly, in plain
>English, the project, the product, the market, the user population and
>their main tasks, schedules, dependencies, risk factors, and so on.
>
>Then the confusion started. The boss loved it, and said:
>
>BOSS: We should do this for every product. Let's update the development
>      procedures to say that someone should write something like this
>      at the start of every project. . .
>
>ME:   No worries, I've been wanting to do this for months.
>
>BOSS: . . . but who should do it? The lead developer? Project manager?
>
>ME:   I'll do it. I have to write it anyway, for my documentation
>      planning.
>
>BOSS: No, I mean something *like* this, but for the project, not the
>      manuals.
>
>ME:   But I have to research and write all this stuff anyway. That's
>      what I do.
>
>BOSS: Yes, something just like this, but not about the manuals.
>
>ME:   But the documentation plan is all in the last few topics. That
>      can be between me and (my supervisor). The first three pages are
>      all about the project -- they don't even mention the docs. That's
>      the part everyone likes.
>
>BOSS: But you're the technical writer. This should be done by. . .
>      (frowns)
>
>ME:   Tell me what should be changed to make it OK as a development
>      document? Do I need to add some headings? Take some out? Change
>      something?
>
>BOSS: (riffle riffle) No, it's perfect. But. . .
>
>And so on. I had done all the tech writerly things -- talked to all
>the people who had a piece of the puzzle, wrote it up in a brief, clear
>document, and sent it to the people who needed to see it.
>
>My boss could see that "something like it" would help every project.
>But he couldn't see it as a task for a writer. If it was a technical
>writer's document, it couldn't be a software development document. If
>it was a software development document, surely it shouldn't be written
>by a technical writer?
>
>
>The second example was a nice idea we had to handle custom software.
>We tended to do a lot of custom work to win big deals, so keeping the
>documentation, the software and the customer's procedures manual in
>sync was a problem. We hit on the idea of putting the procedure manual
>online and making it the interface to the software -- find the
>procedure, read the instructions, follow the link to perform the task.
>
>When we were discussing how this would work, I said each team should
>have one or two techies to do the coding and testing, a TW to write up
>the procedures/instructions, and they would all do the analysis
>together. The others couldn't see the point of putting a writer on-site
>with the techies.  The most they could picture was that you could write
>standard blocks of text to go with the more common procedures.
>
>In this case I think they discounted the analysis and workflow aspects
>of the job, and saw it as largely a software job. I suspect what would
>have happened is that they'd package up some scripts and custom menus,
>then throw it back at the customer and say, "Here, now all you have to
>do is write the procedures."
>
>
>I should stress this company is great to work for. They're good, smart,
>fun people. They like me and respect my work. But for a long time there
>was definitely a box labeled "TW".
>
>Regards
>---
>Stuart Burnfield
>Senior Ignorance Worker
>Prolix Communications Pty Ltd
>mailto:slb -at- fs -dot- com -dot- au
>
>
>
>