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.
Tony,
Sorry this is long, but asking how I scope a project is not something that
is a short discussion.
While you ask how tech writers scope a project differently than engineers, I
wonder if you have an idea that engineers or any group scope projects in a
singular fashion.
In my experience as a TW, I have scoped 20 page manuals to 10,000 page
manual sets. In many (most?) cases, I have not had the luxury of Project or
Product managers, per se. I started in the RTOS industry in its infancy.
We had hot-shot engineers and capable management, but no niche skill
positions. Consequently, ...
I have different methodologies for different types of projects...
Small manuals and small projects are largely uninteresting for scoping or
any other discussion (other than design perhaps). Typically, I rely on a
large background of understanding and lots of templates for approaching
these types of projects and quickly getting into the task of
discovering/writing/reviewing/etc. I do not spend much time on any formal
scoping or estimating.
Large, relatively undefined, complex: I launch 3 or 4 different project
threads at once (if I am the lead):
I start by asking for all requirement docs/specs/napkins/etc. In other
words general research. I follow up with a general interview schedule to
make sure I understand what I read/was told. I then generally define the
types of information that needs to be delivered (i.e., API descriptions,
tutorial info, HW design, exploding diagrams, etc.). I discover what
information is not available. I take a war-room mentality to understanding
the scope. This becomes my white board (currently, my white board is 12 foot
by 8 foot and covers an entire wall). It remains fluid until I feel
comfortable about talking about all aspects of the project in terms of
information to be delivered. Then I write the documentation plan. The plan
is a bit more than Jell-O consistency :) It will change as requirements and
details are filled in. However, at this time I would guess nothing major
will change.
In parallel, I insinuate myself into any groups that are working on the
project (engineers, marketing, etc.). This is both ongoing research and
feedback to my project plans
In parallel, I discuss the plan with the team of writers that will do the
work (group think helps in large undefined projects).
In parallel, ensure I understand who the deliverable is targeted for: basic
audience awareness. I work with marketing and sales on this and then
triangulate with engineering to make sure sales/marketing/engineering and I
are on the same page. This will lead to issues of paper vs. online,
organization, discussion approaches, etc.
As for tools, I feel they are somewhat overrated in terms of scoping a
documentation project. They may be great for scoping the full project
(engineering reqs, etc.) Additionally, the details the tools uncover are
great for providing the specifics in a documentation outline, etc. For
example, I may know that I have to write a manual that describes all
Register Blocks on a specific graphics board. I will probably know every
block I have to document. I may also know the general purpose of every
block. I will probably not know how all the blocks interact until the board
is completely spec'd (and even then I won't know until it is implemented :).
Tools that help in defining system interactions will be of great help to the
board architects. They don't help me scope the project. They do help me
estimate the amount of pages/information that must be produced, but the
scope is at a much higher level.
I consider this a top down approach. Understand the nature of the
deliverable. Understand for whom the project is targeted. Get involved in
as many communication loops as possible. Read code, read specs, do
research. Fill in details. Write a plan based on the above and the number
of staff to implement the plan. Then implement the plan. Revise as
necessary (plan, docs, etc.).
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
