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: Process, not bureaucracy From:Dick Margulis <ampersandvirgule -at- att -dot- net> To:techwr-l -at- lists -dot- raycomm -dot- com Date:Mon, 06 Sep 1999 12:12:58 -0400
SteveFJong -at- aol -dot- com wrote:
> Cam, I think we're talking very much at cross purposes here--but the
> difference is appropriate for a topic called "process, not bureaucracy."
> Let's compare your example with something I had in mind.
[much snipped]
Folks,
Isn't this what Capability Maturity _means_?
The point, it seems to me, is to look at how the most _capable_
organizations with the most _mature_ processes (not the most arthritic
bureaucracies) achieve their results and to ask the questions:
1. What adjustments do we have to make in our processes to achieve at a
similar level?
2. What is the best way to propagate the cultural changes we need in
this organization in order to implement those adjustments?
Everyone wants to be productive. When an organization's management
empowers people rather than threatening them (the manage by fear
technique so prevalent in many companies), people are generally happy to
understand the organization's goals, how their individual contributions
advance the organization toward those goals, and how they can work more
efficiently toward those goals.
When change is managed badly, or assigned to the wrong implementation
team, or based on a flawed "improvement" to existing processes, the
whole notion of process improvement loses credibilty with the people
affected.
_Maturity_ in this context is analogous to the maturity of individual
personalities. We would not ascribe to a rigid and legalistic person the
highest level of maturity, and we should not do so with an organization,
either. A person or an organization can be old and rich without being
mature.
What are some of the obvious lessons?
1. DO NOT just hand our new policies and procedures with an order to
follow them. DO explain the conceptual framework in which change is
taking place, its value to the company, and its value to the individual.
2. DO focus on WHAT a person is being asked to deliver, WHEN it is due,
and how the QUALITY will be judged. DO NOT focus on HOW the person
should do the work.
3. DO NOT issue vague or ambiguous requirements. DO provide guidelines
and templates that are thoroughly vetted and tested and that help an
individual accomplish something real.
4. DO NOT ASSUME that a one-hour slide show after lunch is sufficient to
explain the Capability Maturity Model, the company's new process, and
where everyone fits into it. DO plan for a phased implementation of the
process, just as the process itself assumes a phased approach to
projects.
5. DO NOT CONFUSE a PLAN with a SCHEDULE. You can schedule carpenters or
auto mechanics; that's why flat-rate books work. You cannot schedule
writers or other creative people. Tell them what you want and when the
plan requires it; then get out of the way, so they, as professionals,
can figure out how to meet that deadline.
