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.
Subject:Pricing a project without access to the software? From:Geoff Hart <ghart -at- videotron -dot- ca> To:techwr-l List <techwr-l -at- lists -dot- techwr-l -dot- com>, Pippa Cohen <cohenpippa -at- googlemail -dot- com> Date:Fri, 19 Sep 2008 08:55:58 -0400
Pippa Cohen wondered: <<I was given a brief run through of a large
application that needs to be documented, just so that I could get an
idea of the system as a whole. I never got to see screens in any
detail, and I certainly didn't see every screen that needs to be
documented. However, what I did see seemed very intuitve to use, and
not too technical.>>
Tech always looks easy when it's being demoed by the person who
developed it or one of their colleagues. The ugly reality only
appears when you try to figure it out yourself, without someone
present to explain what you're doing. Make sure to protect yoursel,
in writing, by guaranteeing access to their experts. Insert a clear
penalty clause such as "it won't be done until you answer my
questions, so take as long as you like" -- though you might want to
express that a tad more diplomatically. <g>
<<The application is Windows-based and requires a fair amount of
effort to install. The client is not keen to install it on my laptop,
for me to complete a detailed review and then quote for the work
(which I can understand at this early stage), and for various reasons
it isn't feasible for me to do this on site.>>
If the software requires that much effort to install, don't you think
a significant portion of the documentation will be the installation
manual? And how can you possibly document that without doing the
install yourself? fwiw, there's absolutely no valid excuse for making
modern software difficult to install unless the company earns a
significant portion of its income from selling its consulting
services to install and configure the software. Whether it's ethical
to make something deliberately difficult to install I leave up to
you. I think not, but perhaps that's why I'm not a dotcom millionnaire.
I'd be very wary about accepting such work. I've done this kind of
thing once while I was a wage slave, and it was only tolerable
because the developer was available throughout the workday to provide
feedback and missing information. And the developer was both eager
and willing to test my docs to ensure they were correct. Documenting
what you _think_ you see and understand is very, very different from
actually testing those guesses to see whether you were right. I never
did get to test the docs or play with the device (there was only one
device, it was very expensive, and the developer was working on it
full-time), but I was confident from my interaction with the
developer that he was doing the QA conscientiously.
<<Their preference is to generate a list of screens from the
database; a developer will then annotate each entry in this list with
a level of complexity, and it will then be sent to me to quote (a
fixed price) for the work.>>
If you're going to work this way, I'd strongly recommend teaching
them about Camtasia or some such so that they can give you movies of
how the software works. They may not be _good_ movies, but at least
they'll take you one huge step beyond static screenshots. Movies show
the flow between tasks and modules, something that can be quite
difficult to infer from static screenshots.
<<I have never worked in this way before and am nervous about quoting
for something where I haven't been able to really go through the
system for myself...>>
Were it me, I'd insist on an hourly rate for the first large group of
screens until I got a feel for how hard the work was going to be and
how long it would take. (Don't forget to include your time spent on
the phone or waiting for e-mail with answers to questions.) I'd also
be very clear that without having the software to use, most of what
you are documenting will be guesswork, and someone at the company
must sign a legal waiver that they accept full responsibility for
testing your docs to ensure they're correct. Since you can't test
them yourself, you can't provide that reality check. And make it
clear that you'll provide one revision for free in response to their
reviews, but after that, revisions are billed by the hour. Give them
an incentive to do it right the first time.
Only once you have a clear idea of your productivity should you begin
thinking about providing fixed-price quotes, but make sure to use
your low-end productivites, not your best or average productivities,
when estimating. In my experience, the software gets progressively
rougher around the edges as you draw closer to the ship date, and
often the most thorny and least friendly parts of the software are
the ones that get delayed right until the end of the project. (After
all, the easy ones get done right the first time, no?)
ComponentOne Doc-To-Help gives you everything you need to author and
publish quality Help, Web, and print content. Perfect for technical
authors, developers, and policy writers. Download a FREE trial. http://www.componentone.com/DocToHelp/
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
