Project Manager problems - need advice please?

Subject: Project Manager problems - need advice please?
From: "Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 19 Jun 2002 09:10:52 -0400


Anthony reports: <<I ended up doing milestones just for it. As a result,
the larger Internet Architecture Manual project lagged behind a bit.
They're fine with that, but have no grasp of milestones and such on the
larger scale of the Architecture project.>>

>From what you say later in your message, it doesn't seem like what you're
calling milestones are particularly important to the developers. Seems to me
that all they want is (i) a decent current draft of whatever the current
priority item happens to be and (ii)a general idea of what progress you've
made on other aspects. That being the case, one strategy might be for you to
use the milestones exclusively for your own planning, but keep an ongoing
and updated record of where you're at available for their use.

<<In time I have learned that this environment is a chaotic one... At this
company they just check in on you with no warning
and expect you to cough up this rough draft no matter how horrible looking
it is. Usually about every two weeks.>>

That's awfully common, as any quick scan of the archives will reveal. Under
these circumstances, you know two things: First, you have 2 weeks after
their last visit to prepare the next lump of docs. Second, you must focus on
producing "good enough" docs by the end of that two weeks. Forget about
polishing them to a fine glow: just get it right, get it clear, and get it
into their hands. Later, with luck, you'll have time to go back and produce
something to be proud of. But if not, you've produced something "good
enough".

<<I talked with the manager a few minutes ago and told her about my wishes
for a more normalized schedule at least something regular I could shoot for
so I didn't waste a lot of precious time constantly repolishing drafts to be
turned in. She understood where I was coming from, but had no
suggestions.>>

Don't forget: your manager may have no power to control the chaos elsewhere,
and if that's the case, you'll have to learn to deal with it too.
"Constantly repolishing" is the key phrase here: you're trying to produce
superb work in an environment that won't give you the time to do that. So
stop trying. Here's a suggestion: Write a first draft that is technically
correct and helpful to readers, then edit it quickly--and only once--so it
reads well. If you have time _later_, go back and make it superb.

<<Overall, I feel like they are content with the results so far. I am not
getting any negative vibes from them in that regard. What I am seeing is
that they really need the manual, like my work, but have no idea what they
should expect even though I have given them an initial outline, a vision,
and an expanded diagram on the internet architecture.>>

Sounds like you should keep doing what you're doing, though with a bit less
polishing. If they like what you're doing, why change? Over time, you may be
able to persuade them to adopt a slightly less chaotic approach, but don't
assume that this is going to happen. It may not.

<< They're experience with technical writing is a staff writer who works
with the development team along the way. So her work is on display
constantly and that represents their comfort zone to me. As a result of all
this they are uncomfortable with my passive approach of not constantly
walking over with new drawings and such.>>

This is a red flag to me: It sounds like this company is one of the few that
actually encourages you to work with the developers, and that's a pearl
without price. Given that you have this opportunity, seize it with both
hands and start emulating the staff writer. Don't spend so much time in
consultation that you annoy people, but do make sure that you keep the
development team in the loop. Make yourself a part of the team, no matter
what the org chart says.

<<My fear is that if these checkups are too frequent they will not be
pleased with my output given that one can spend many hours in a week
researching individual details and this will not show up as writing or
diagraming in the draft necessarily. I've already
tried to handle the problem by documenting my time in detail and filing a
separate weekly progress report every Friday. They still seem to be wanting
more.>>

Stop documenting your time and start focusing on the results. So long as you
keep them well fed with documentation, and keep in ongoing touch with the
developers so they know what you're up to, they shouldn't give a damn about
how long something took. A job takes as long as it takes, and you already
have more than enough statistics to justify your work--if anyone ever asks,
which it doesn't seem likely they will. Use the time you free up by not
keeping records to produce more or better documentation.

<<What are some good questions or types of questions I should be asking?>>

Good questions are those you can't easily answer yourself and that show the
developer you tried to understand the situation before coming to them for
help. Other good questions are ones that show you're interested in the
product and the developer, because those questions build relationships you
can count on in the future.

<<What kinds of technical personnel should I be talking to?>>

The ones who can answer your questions. <g>

<<do you know of any... comprehensive list and outlines the types of
diagrams programmers use, their characteristics, how to construct one, etc.?
... I keep stumbling across some I have never heard of while talking with
the technical folks here about what they would like to see in the manual.>>

The only useful list is one that addresses reader needs. Your programmers
may be able to teach you some new ones that are unique to their field and
useful to your audience, and that's a great way to both learn and build
relationships. Don't waste your time researching all the possibilities: use
your relationships to learn the select few solutions that are most useful to
you. Don't forget: you're relatively new here, and nobody expects you to
know everything immediately. Don't pretend you do.

<<I feel like I am constantly on the edge of running out of ideas of where
to go next.>>

Fortunately, there's always techwr-l.

--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law."

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.

Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
---
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.



Previous by Author: Back to the Dark Ages? (Take II: a sneaky trick)
Next by Author: Single vs double quotes?
Previous by Thread: Can HTML help window stay maximized and icon stay in task bar when application is minimized
Next by Thread: doc management for contracts?


What this post helpful? Share it with friends and colleagues:


Sponsored Ads