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.
Anthony Markatos wrote:
"Is there any way of estimating the Task Analysis portion of the project?"
Hi Anthony,
I've been following this thread with interest, since it's something that we
do frequently, and I've also gotten some really good ideas from it. In terms
of estimating the Task Analysis portion of a project (especially a complex
project), I usually start with an assumption about what the project will
look like - this assumption is based on the client's stated initial project
goals, requests, and ideas about size and delivery mechanism. At this point,
I'm usually careful to emphasize that this is an initial assumption, and
that it's essential to spend some time gathering data. This data may support
the assumption, or it may lead to a whole new strategy.
I begin the proposal by asking the client to authorize a Task Analysis to
help determine the strategic direction of the project. This Task Analysis is
a mini-project in itself, and usually requires about 3 - 5 days, again,
depending on the complexity of the project. I've seen some Task Analysis
phases require 3 - 4 weeks (for really BIG projects). I've found that client
are usually OK with paying for a 3 - 5 day Task Analysis, provided you're
careful to emphasize that this will help you deliver a truly appropriate
solution for their requirements.
Depending on the type of project, this typically includes:
- interviewing the client's SME's/customers to determine the direction they
want to go
- meeting with the client project sponsor (or sponsors, depending on the
overall impact of the project for the client) to determine their goals,
performance requirements, performance measurements, timeframe, budget, etc.
- reviewing the source for the project materials (that is, reviewing the
software, existing documentation, work practices that the software is
supposed to support)
- reviewing associated literature (such as vendor materials, reviews, etc.)
- talking with people who have completed projects of a similar nature (these
folks can be invaluable - they usually have great instincts about what
pitfalls to try to avoid, but it can be tricky getting them to talk to you)
The deliverable for this mini-project is a report describing the initial
strategy, a synopsis of the results you got during your Task Analysis, and a
strategy for delivering the project. Make the strategy as detailed as
possible (right down to including the names and resumes of the people you
propose to use during the delivery), and include mock-ups and information
architecture information if possible. The report should also include a
detailed estimate (including all the steps and the time required for each
step) for you to complete a prototype of the suggested strategy.
Anthony, I hope this helps you get your feet under you.
Regards,
Leslie Johnson
S.I. Writes
Calgary, Alberta