RE: Tracking document complexity

Subject: RE: Tracking document complexity
From: Goober Writer <gooberwriter -at- yahoo -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 18 Nov 2003 08:54:38 -0800 (PST)


> This is neat, but I suspect deceptive. In my
> environment it would be anyway.
> When we don't hit a deliverable, 99.999% of the time
> it is because we didn't
> get source from the SMEs,

Why not? Who didn't hound them enough? It's a 2-way
street, this communication thing. If it fails, it is
on part of both the sender and the receiver.

> or a dev deliverable slipped,

Which should impact the schedule, to which the
documentation is tied, right?

> or a customer
> requirement changed midstream,

Which should be handled as a change request and
validated against the current schedule.

> or some sexier project swiped the writer(s)
> or SME(s) in the middle of the project.

In which case the project should reflect the absense
of resources.

> We are trying to come up with meaningful metrics now
> too. My part of this
> effort is to break down tasks and timelines in ways
> that are meaningful
> given the particular project. Sometimes I can tie
> doc milestones to dev or
> deployment milestones. What I am finding more and
> more often, though, is
> that each project requires sensitivity to its own
> particular milestones.

Of course. You're not trying to create one huge,
inflated schedule for the whole project (dev, QA,
docs, etc.) are you? You need a high level schedule
that is broken down into smaller schedule "components"
in order to properly track the progress of each
effort. The high level schedule should update with
changes from the component schedules.

> This takes real-world experience and analysis of
> what to expect from each
> team and each product/project. Some are cowboy, some
> are high-risk. Others
> are predictable and managed strictly by the book.

This is why Project Managers get paid the quasi-big
bucks. ;-)

> Ultimately, the usefulness of numbers is based on
> the degree of trust the
> manager(s) who implement(s) them inspire. Writers
> who trust their manager
> will work to and be inspired by her ratings. Upper
> management that trusts a
> doc manager will reward and respect the
> documentation team's effort.

I don't get that last part. Can you elaborate?

=====
Goober Writer
(because life is too short to be inept)

"As soon as you hear the phrase "studies show",
immediately put a hand on your wallet and cover your groin."
-- Geoff Hart

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP FOR FRAMEMAKER TRIAL NOW AVAILABLE!

RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4

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



References:
RE: Tracking document complexity: From: Kate Robinson

Previous by Author: Re: stupid question: how do you spell that thing we do?
Next by Author: Re: stupid question: how do you spell that thing we do?
Previous by Thread: Re: Tracking document complexity
Next by Thread: Re: Tracking document complexity


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


Sponsored Ads