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.
Subject:Re: Procedure vs. Task vs. Flow From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Fri, 14 Nov 1997 10:54:25 -0600
At 10:46 AM 11/14/97 -0500, you wrote:
>Greetings.
>
>I have been working to set up a policies and procedures writing format
>for my department. I already have people writing procedures and
>documenting workflow using templates and standard format.
>
>I just received a reference book that I ordered on writing P & P (wanted
>the reference primarily for writing policy, not procedure). Lo and
>behold, the book says something different than what I have already
>implemented for writing procedures. The book says that *Procedures*
>always involve 2 or more people, and that *Tasks* are the set of
>instructions that one person follows to complete a procedure step.
>
>I have set up a system where procedures for more than one functional
>group are *Workflow* documents written in playscript format. I have
>called individual sets of instructions *Procedures*, not tasks if they
>are for people within the same functional group (e.g. "Help Desk
>personnel procedure for doing such-and-such").
>
>Does anyone have some thoughts on whether using "Workflow" and
>"Procedures" is still fundamentally correct?
>
>
I think this is a case of getting tangled up in the phantom barbed wire of
language. According to your book, "procedure" has a definition, but probably
just to that author and for that purpose. In every resource I consulted,
"procedure" just meant "a defined way of doing something" with no number of
bodies mentioned.
Our policy here is to use common wording whenever possible, and when we're
having to subdivide a concept into words that can be misunderstood, we
define them or reduce them to graphics.
For example, if we were to set up a "work flow" that has "procedures" within
it and each procedure could have multiple "tasks", then by conventional
language, these words don't hint at our specific usage. We just need to
define them, or deemphasize the labels and make flow charts. My favorite is
the flow charts. They're cleaner, more communicative, and generally more
helpful. But they're also harder to update, harder to produce, and sometimes
hard for the chart-impaired to interpret.
Tim Altom
Vice President, Simply Written, Inc.
317.899.5882 (voice) 317.899.5987 (fax)
FrameMaker support ForeHelp support
FrameMaker Conversions
PDF Consulting and Production
