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