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.
On Behalf Of McLauchlan, Kevin blurted:
>
> Sylvia Braunstein inquired:
>
> > I need to know how to manage the people and the documentation so we
> can
> > meet
> > the deadlines and so that the work gets done.
> >
> > I don't have other experience other than finding myself in that
> situation
> > without prior experience. I know how to manage myself because I know
> that
> > I
> > can rely on myself but managing other people is different. I know
that
> > when
> > I say that I will do something, I do it or if I can't do it, I make
> sure
> > that my boss knows so that he can make a decision about what to do
> about
> > it.
> > However, other people are not like that and I would like to know how
> to
> > handle the various situations so that we can deliver. I would also
> like to
> > know how to actually manage the whole department (3 people).
>
> Eat an elephant.
Oh? Was I too cryptic?
Um... what Geoff Hart said.
Break it down. The old joke applies:
How do you eat an elephant?
One bite at a time.
You suddenly need to be aware of the big picture - what goes on beyond
the borders of your (new, little) empire.
A good corporate project-planning process includes documentation (of the
process) like Marketing Requirements/Specs, Product Requirements (might
be the same as the Marketing Requirements, or they might separate out
the timeline stuff from the features and specs stuff), Engineering
Requirements/Statement of Work, i.e., what Engineering is going to do to
address the specs/demands they've been given. Those internal docs are
done by the respective groups and then made public for the use of all.
The customer documentation crew should also provide a document that
describes what you are going to produce, a Documentation Plan. The trick
is that you don't write it. Your writer does, for her/his product. Or,
if you have the arrangement where the group takes on the documentation
for the new product release and each member takes a portion (say, a
document or two each), then you provide the template and boiler-plate
and your crew provides a section each. It doesn't take much, just a
title for each document, a part number (or TBD if you'll learn that
later and fill it in then), a brief description and scope saying what
it's for, where it fits in the overall clump of docs that will be
produced to accompany the product to the customer, and a bit about your
(the writer's) requirements (need sample product by such-and-such time,
need "code-freeze" so the target stops moving so wildly, need special
equipment to allow use of the product, need access to some share time if
the product is too expensive for everybody to get their own sample to
play with....) and finally, risks if this or that can't be had/done.
By getting the individual writers to write the Documentation Plan - or
portion thereof - for the project, you get them to state in writing
their understanding of their responsibility.
Have meetings. Not just one-on-one. Meet with your group weekly (or more
often if necessary) to review progress, schedule changes, etc. If the
product-project milestones are sparse or have lengthy periods between
them, then create some reasonable milestones for just your group. That's
much easier to justify and to do, if you have a policy of performing
peer reviews of each others' work ( or if you'd like to establish such a
tradition). Without poking into a writer's daily activities, you can
have them agreeing to, and recording, expected dates to have
this-or-that progress, so that their buddy can then review. At your
weekly meetings, when you ask each writer if s/he is on track to this or
that milestone, inquire solicitously if they've received such-and-such a
deliverable from whomever was supposed to supply something.
Frequently re-iterate, to no one in particular, that you want to hear
about things going wrong or getting delayed or just not happening when
the problems first surface. Even if the independent writer is just
giving you a quick heads-up that they are taking care of this-or-that
difficulty, you want to know. What you don't want is to find out, as
something important is coming due, that the deadline can't be met and
the problem has been festering for weeks or months.
At your weekly group meeting, take notes and produce minutes that same
day. During the meeting, try to make an action-item out of anything that
is identified as needing to happen. Every action-item gets assigned to
somebody. Track all action-items from week to week, until they are
deliberately ended/completed/dropped. Keep meetings brief, but not curt.
If there's in-company news, take a few minutes to relate it. (Births and
deaths, promotions, departures, pending arrivals (so-and-so accepted the
offer and will be starting in Test Engineering next Tuesday).
If the company doesn't have a standard planning software, then get one
for yourself, so that you can break everything down into stages, assign
dates and deliverables, make GANTT charts. Some people get an idea of
what's on their plate from a list of dates. Others (I'm one) do better
with a visual representation of events, dependencies, hand-offs,
overlaps, etc.
Finally, when one of your staff has a problem getting something that
they need from somebody outside your group, get all the details, then go
to bat for them... and win. Repeat as often as necessary to build a
reputation as somebody who fights for her crew, but always in terms of
what's good for the company, what furthers the company's plans and
projects.
Your door, if you have one, should be closed when you are interviewing
prospective employees, when you are taking loud/distracting conference
calls, when you are strategizing with other managers, and when you are
counseling or disciplining members of your crew (or writing up
performance reviews). The rest of the time, it should be open. Well,
ok, maybe you should close it if you'll be napping.... Don't expect to
have time to nap.
Don't play favorites. Engage in friendly chit-chat, but be the one to
break it off in most situations.
Try not to be sardonic _every_ time you laugh publicly at the office.
Wrangle some money from the company to take your little group (or get
together with a closely related group) for an outing a couple of
afternoons per year. Bowling, go-carting,
sitting-sipping-sangria-on-a-patio (recommended only in summer or mild
climates...), VOLUNTEERING to sort incoming boxes at the local food
bank, anything where you can all relax together and not be worrying
about work.
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
