Re: Tracking document complexity

Subject: Re: Tracking document complexity
From: Dick Margulis <margulis -at- fiam -dot- net>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 18 Nov 2003 10:59:47 -0500




Kate Robinson, quoting my post but anonymously, wrote:

...Writers should be working to complete deliverables that are accounted for in a project plan. Each deliverable should be associated with the anticipated amount of effort needed to complete it (person-days, basically). ...

Then the question is how well did the writer do in terms of producing the deliverable in the expected time, and the metric at the end of the year is the ratio between estimated effort and actual effort.

...

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, or a dev deliverable slipped, or a customer
requirement changed midstream, or some sexier project swiped the writer(s)
or SME(s) in the middle of the project.
That's why Gantt charts show dependencies. If you don't have the inputs yet, the clock doesn't start ticking on the cycle-time, and the end date gets pushed out. Not your problem.

It's also NOT all equal. Producing a new set of docs is not at all the same
task as updating an existing set. Producing an updated set of docs that
includes reorganizing the standard content into more useful deliverables is
not the same task as producing an updated set of docs that uses the same
organization we've used for the past three years.

That needs to be accounted for in the project template. You don't use the same template for a major new initiative that you do for a new model of an existing product.


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

Right.

At some point, it's probably possible to come up with a formula that uses a
standard formula AND multipliers for factors that complicate the
documentation task, such as the SME availability or need to reorganize that
I mentioned above. (The "weenie surcharge" -- which is a pure percentage I
apply to both time and cost estimates -- that I developed to deal with drama
addict clients decades ago is still useful and necessary, but needs to be
hidden more carefully in the corporate world.)


You're looking at too fine a granularity. Look instead at averages over a large number of projects for the overall length of time to produce the deliverable. We all know there will be exigent circumstances that affect the performance on any given project The point is not to punish people for missing a deadline but to figure out what a realistic deadline ought to be, given the variability of the process.


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.

Focus on the company's needs, not the manager's personality. You'll live longer.

Is that terribly different from any other job function?

No , it isn't. And that was my point.

Dick

---
[This E-mail scanned for viruses at mail.fiam.net]


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

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: WORD inquiry?
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