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.
> >But can process
> >help? I think so, if the whole organization buys in to them.
> =====================================================
> Your statement reminded me of something I already knew, but failed to
> dredge up as the ultimate response to those like Plato who think
> structure, process, and standards are often counterproductive.
(And I reply)
As is the case quite frequently in these postings, people tend to generalize
and paint with a broad stroke. Let's just simplify here. Structure is
important. Content is more important. Spending TOO MUCH TIME designing
structure, process, and standards IS counterproductive because you are
supposed to be producing content for the user.
Even simpler:
PRODUCTIVE!
Content (80% of your time), Structure (20% of your time)
COUNTERPRODUCTIVE!
Structure (80% of your time), Content (20% of your time)
NOTE: Notice that I haven't once said "Structure isn't important."
> I doubt if any of those anti-process folks would grant that same freedom
from
> restrictive processes to other departments of the company in which they
work,
> particularly the engineering groups upon which they rely for the
information
> they require.
GENERALIZATION ALERT!
Sorry my friend, we aren't "anti-process." (As Andrew and others have
pointed out several times.) We may be anti- "80% process/20% content", but
definitely not anti-process.
When our company moved from the DOS platform to the Win platform, do you
think the programmers sat around and designed structures and processes for
two years and then wrote the software? Nope. We actually kind of used the
Microsoft approach. We used a rapid application development (RAD) tool and
started whipping out apps left and right. We tested on the fly, got user
feedback, etc. It was all very crazy. In the process, we had a somewhat
shaky version 1 product, but we got out there first and now we are way ahead
of the competition and have a huge share of the market.
As time has gone on and our company has matured, we have developed some
processes and structures and have a much more efficient approach to building
apps and creating specifications. But in the end, as it is with the
documentation, our clients come first and if they want something changed in
the app, then we change it. We never respond to them by saying, "Well,
that's a great idea for a change, but it falls outside of our change request
hierarchy and we can only institute that on a blah blah blah etc. etc. Uh,
you'll see that feature in 3 years." (Gee, kind of like how Adobe handles
FrameMaker. How hard could it be to add multiple undo?)
>So, as I suggested in the post which started this thread,
> anti-process folks want to be able to blow smoke up their own ass (as well
> as everyone else's) without a reciprocal smoke-blowing entitlement granted
> to the other departments. They think they're entitled to some kind of
plenary
> indulgence that liberates them from the restrictive processes imposed on
> others,
> because "writing is so much more creative than anything else done in my
> company."
I don't know about the rest of you, but if my company is churning out apps
and I'm not churning out docs with the apps, I'm fired. I don't see how I've
been liberated from that pretty darn restrictive process. I guess if I
worked at a company with a fully-realized UML, I'd be able to kick back a
little and point my finger at the programmers. Oh well.
> The chef in the cafeteria probably feels the same way. But suppose the
chef
> also decides to transcend policies and processes so as to unfetter his
creative
> juices. If the result is that the food is not ready at the appointed
> time, it will be the anti-process folks who'll scream the loudest,
> demanding that
> the chef must submit to discipline and process, and his creative urges
will
> have
> to suffer if it means they don't get to eat on time.
Fascinating analogy...
Let's say structure equals the recipe and content equals the food. If the
chef creates food without staying strictly with the recipe (pinch of this
and a pinch of that instead of using the measuring spoons) and the food is
tasty and eaters like it, then fine. Who cares. As long as the eaters like
it. If he changes the ingredients substantially and alters the flavor so the
eaters don't like or he cooks something completely different and doesn't let
me see it and it doesn't match the menu, sure, I'm going to pissed off and
so are the eaters. How can I write a menu if I can't see/taste the food
ahead of time?
