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.
One more thing to add to Pierre's summary: The unexamined process is not
worth living.
Hackos (it's all I know) is about measuring and revising a process as much
as it is about instituting one. Andrew, et al., know their "non-processes"
work because they use their outcomes as tests. Some things are too big for
that, as your experience tells me. The failure was not only the process but
was also the failure to revise the process, probably because of ineffective
feedback. That you knew nothing of the plan was a bad sign. They should
>have read Hackos: big budgets mean big losses. Bad process management, just
like bad writing, is sufficient for failure, though it is not necessary.
Oh, and as Brecht said, "Pity the army which requires heroes."
Barry
>At 01:47 PM 9/29/99 +0100, you wrote:
..I would share my experience of the role of methodolgy in large
sophisticated companies.
>
>I worked as part of a large team of writers on a huge software project. I
>was always hearing that a development methodolgy was being applied to the
>project but never saw any sign of it being applied to documentation, which
>was fine by me - I just got on an did some jolly good work.
<snip>
>The project folded losing the company a fortune and my work went in the bin.
