RE: Why'd that take so long?

["Ed Manley" <edmanley -at- bellsouth -dot- net>]

This is a tough issue, Martin, as it's about credibility as much as it is
about logic and understanding. I have faced these issues. For what it's
worth, here's how I handled it.

When working for managers who do not understand the time it takes to produce
quality documentation I have had to ask myself some serious questions.

The first being: Are their concerns legitimate? Are you in fact spending
time making it nice when they just want it delivered? Especially with Word,
writers can get seriously bogged down in style, template and formatting
issues.

Perhaps management is focused on production; deadlines loom, the company
needs income and the product with its attendant documentation has to be
delivered NOW! to generate revenue, quality be damned.

Perhaps they believe that a lone writer should be able to handle the
workload - in which case what value have Policy and Procedures Manuals and
Style Guides? Do these things in fact have value if value is described as
getting "just enough" documentation delivered?

Have they had experience with a writer who satisfied them in the past? If
so, what are you doing differently? You mention that the previous writer had
poor skills - but did his work product satisfy them? If so, you really do
have a problem, because they are unlikely to want to listen to "excuses"
about why old work needs revision and new work requires prolonged set-up
and/or new ways of doing things.

How much of your workload is new content and how much revision of legacy
documentation? Perhaps it would be faster to write all new stuff and not
spend time trying to salvage what somebody else did.

Have you considered using off-site by-contract writers to deal with
formatting issues? If you concentrate on writing content you could contract
with part-time writers to help with the chores that are bogging you down -
folks willing to work from home and charge next to nothing. There are quite
a lot of us out-of-work tech writers available to do this. I suspect that
having a writer jump in onsite will cause you more grief than give you
relief until you have some of these issues resolved. Or, have the writer(s)
you bring onsite concentrate on nothing but content while you get styles,
practices and tools sorted out. You mention getting a writer in for three
months: unless you are a very good interviewer and assessor of skills I
think it likely that it will take that long for a new writer whom you expect
to do the same work you do to even get started producing anything of value.
Consider what specific tasks you can farm out very carefully. Maintain
control of any writer hired.

Do NOT ask management to hire another writer and let them take it from
there.

Track metrics. Keep a journal of the work you perform and share these
metrics with management. Give them details. If they only see that it took
three weeks to deliver a doc then they are much more likely to question your
work habits than if they see that you spent two hours on this, ten on that
and three on some other specific task that added up to those three weeks.

Those metrics can then be used to estimate delivery time for all new work -
both you and your management will have a detailed understanding of what
tasks must be done to produce the doc, how much time each task has taken in
the past, and how much to expect it will take in the future.

I use TimeWin software on certain projects to track my work in fifteen
minute increments. I can at any time defend writing time billed and make a
case for my estimates. Require any writer you hire to do the same, at least
at first, until you get a clear picture of why, how and on what the time is
being spent. I would seriously question any writer who told me (s)he spent
four hours formatting a document.

Ask your manager to spend an hour working with you; with them beside you go
about doing what you do. Let them see how time-consuming maintenance chores
can be. Let them question why you are doing any thing. The XP practice of
pair programming can just as aptly be applied to writing - get them to sit
with you and co-author a document. This may give them an understanding of
what you do and why it takes the time it takes.

Exclamations such as "Hey, it takes what it takes - trust me" are more
likely to cost you than help.

You do mention your resentment at having to explain your time, but in a
situation where you lack credibility you may have to suck it up and be very
precise about what and why. Over time you will prove to these watchers that
you are doing what has to be done, and only that.

Ask your manager to define exact expectations. Perhaps you value things
differently. Produce only those artifacts that are of value to management,
and produce those only at the quality level they demand. There is no room
here to make yourself feel good about the product - you can do that once
credibility is restored and no one is questioning your time, if you must.

Read the essay at http://www.agilemodeling.com/essays/agileDocumentation.htm
very carefully - these are some excellent tips and questions.

Try modular documentation as well as single-sourcing. By this I mean write
small topical documents with a narrow focus that can later be combined into
a larger single document. This way the each product or project manager can
see in real time where you are with specific content of interest instead of
waiting for the whole doc to come out. This is likely what they mean when
they say they can write a doc in an hour - that they can write a few
paragraphs and paste in a screen shot and have the content of interest to
them at the moment. So, do the same, then combine all of these parts to
build your final document. Think of this as iterative and incremental
document creation.

Be extremely careful with this suggestion, as I do this only in certain
high-trust environments: Keep all of your drafts and work-in-progress
available to your manager on a shared drive. Let them see what you have at
any time. Remember these aren't your documents - they are the company's. I
say again; be careful here... A draft or work-in-progress released is a time
bomb waiting for somebody to distribute it in an email, making you look like
a complete schmuck. If you do this clearly mark each page as daft. or draft,
whichever.

I don't hold out much hope that you can "quickly explain" why tech writing
takes more time than producing a memo or a PowerPoint presentation because,
in most cases - it shouldn't. Reread the agility essay.

Hopefully these tips may help you gain credibility in short order, and
thereafter be trusted as an asset dedicated to helping them get the product
delivered. Believe me, that is what most managers want. In my humble
experience they could care less about anything not directly supporting
profitable on-time delivery, and will not question the needs and activities
of anyone whom they trust to be dedicated to those ends.

I wish there were a better answer...but it sounds like you will have to
justify yourself before they will believe you.

I suspect that this is one of the toughest tasks a writer faces.

Good luck,
Ed




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Buy RoboHelp Deluxe starting at only $798: you'll get RoboDemo, the hot new
software demonstration tool that's taking the Help authoring world by storm,
together with RoboHelp Office. Learn more at http://www.ehelp.com/techwr-l

  Your monthly sponsorship message here reaches more than
  5000 technical writers, providing 2,500,000+ monthly impressions.
  Contact Eric (ejray -at- raycomm -dot- com) for details and availability.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit http://www.raycomm.com/techwhirl/ for more resources and info.