Re: Fwd: gaining control of a dysfunctional environment?

[Beth Agnew <beth -dot- agnew -at- senecac -dot- on -dot- ca>]

The telling phrase in your post was that your boss doesn't think it's 
your job to manage documentation. This is the key, because you have to 
convince him that it indeed* is* your job to manage documentation. The 
profession of technical communication is one of building relationships. 
We need to have good relationships with all of the people with whom we 
interact and from whom we need to get information so that we can do our 
jobs. This is not always easy, especially for writers who prefer to 
interact with a page rather than a person.

You have said that you have failed to institute a document management 
process despite your best efforts. It sounds very much like your 
oganization has low process maturity. They don't like processes at all. 
Your job will have to become one of education and project management as 
much as it is techwriting. The good thing is that the document 
development process closely parallels the software development process. 
We're just about a half-step behind most of the time. If you are not 
currently doing a documentation plan, I would suggest starting there. 
This is equivalent to a specifications document for your manual. If your 
company doesn't do specs, this will be an uphill climb.

There is so much that should change to permit good processes that it 
will be difficult to convey it all in message format. However, you can 
start with the thin end of wedge by keeping a project log. Take notes of 
what you are observing so that you have concrete information upon which 
to base future actions and recommendations. Make friends with the BA and 
the PM, they can be your best allies. Begin to educate by telling those 
you speak with about how techwriting processes work. For example, when 
you want to resolve an issue and someone says it's not your job, 
pleasantly say, "Actually, it is a typical technical communication task 
for the user advocate, that's me, to be involved in resolution of issues 
that can affect users and usability. I am trained to help solve those 
kinds of problems in software development." If they don't believe you, 
keep referring to other authorities, such as the STC, and drop names of 
experts such as Jared Spool, Ginnie Redish, JoAnn Hackos, etc. (If you 
haven't got JoAnn's book Managing your Documentaton Projects, get it, 
read it, do it.) You can also mention that teachers of technical 
communication (me included) teach this, and that the STC is continually 
funding research in this. Educate them about iterations and signoffs in 
documentation, and you can subtly get across that software processes 
work this way too.

Does the opportunity exist for you to give a "lunch 'n' learn" 
presentation about what it is you do? Or say, the Capability Maturity 
Model? Or on Software Development Methodologies? They might not accept 
YOU speaking on the latter two topics, but perhaps you can work with the 
HR department to bring in an expert for some company-wide professional 
development. Also check out Pragmatic Marketing for Development. Once 
the company leaders understand that good s/w development processes drop 
mega-$$$ to the bottom line, they might start to be more accepting of 
positive change. Clip relevant articles that support your ideas and send 
them to DEV, PM, and whoever else can take the lead on this, with a wee 
note "Thought this was interesting."

Remind them that as the documentation writer, you are one of the few 
people in the entire company to see the big picture, as well as the 
detail level. Remind them that technical writers typically work with 
marketing, sales, customer support, QA, product management, and 
training, as well as development. Connect with other TWs for moral 
support and a flood of ideas.

Remember that you are a communication expert, and this is a problem in 
communication -- which you can begin to solve. Contact me off list for 
additional help.
Good luck!
--Beth

Anonymous Poster wrote: