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.
Re: Structure vs. Substance? - am I missing something?
Subject:Re: Structure vs. Substance? - am I missing something? From:Damien Braniff <dbraniff -at- iss-dsp -dot- com> To:TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 15 Jun 2000 09:32:51 +0100
> Maybe a little late (off at Forum 2000) but am I missing something fundamental
> here? To me you have a job to do (any job!) and, the first time it's done
1 Work out SOME method of doing it - e.g you have the Widget Co. software
that needs an installation and user manual so what do you do? Install it
yourself and write down what you do? Play with the software and see what it
does? Whatever it is you're doing you will create some sort of
process/structure to get it done (highly informal no doubt).
2 So you've accomplished your first task and it's done - what happens next?
You get something similar to do so you think to yourself what did I do the last
time? Did it work? So you take the same route and adapt it as necessary and
off you go.
3 What next? Yet more? And before you know it you have a process/structure
in place for whatever it is you're doing - probably still very informal.
Now if you happen to work in a large organisation somebody might say that looks
like a good idea and before you know it you have a FORMAL process/structure that
everyone doing what you're doing can use (in fact in this case it would probably
be a merging of several individual processes etc). No process/structure simply
'appears' - it evolves as a response to a need to do something, in our case
formatting content etc so that it's easier to produce and (hopefully!) use.
Once in place it should NEVER become static - things change and it should
continue to evolve. To me, processes/structures are like Word, FM - they're
tools of the trade to use as the situation warrants. We have heard several
complaints over the years about writers having to use Word when FM would be so
much better... (we've all seen the tool wars!) Is this any different to saying
I'm must use process/structure xyz? It's just another tool - sometimes the
process/structure works well and we're happy; sometimes we think this is rubbish
and we should be using process/structure abc or even 'I could do better
myself'.. So what! At times (just like Word/FM) we have to bite the bullet and
get on with it - this is what the customer wants us to use so that's what we
use. We can recommend change, and SHOULD if we think we can improve the process
- just as we can suggest switching to FM or whatever but in the end it's just
And finally, as with all tools, it's how and when you use them that counts. For
my sins (when times were hard here) I did Quality at university to add another
string to my bow and have been involved in ISO9000 (another process/structure -
note it's a living structure with a new, revised version out!) and the problem I
found (same with all structures/processes?) is that people don't really
understand it, don't use it properly and so get buried in the paperwork that can
accompany it. I was taught that, contrary to belief it has nothing to do with
quality, just consistency. Get your quality right and get ISO 9000 and you'll
get consistent levels of quality (good or bad!); it's about documenting what
you do and then following it - easy if you actually document what you do and not
what you think you should be doing! Anyway I digress. I've seen relatively
small companies drown in ISO and another (who actually understood it) small s/w
company who had less than 30 procedures for the whole company. I guess what I'm
saying is that ANY process/strucure used properly in the right situation should
be beneficial. Used wrongly/in the wrong situation and it'll create more
problems than it solves.