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:Re: Should I run or is this project doable?... From:Andrew Plato <intrepid_es -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 13 Mar 2001 23:56:11 -0800 (PST)
"Johanna" wrote:
> They tell me that
> they will go beta at the end of March and that they
> want to release their final version, with
> documentation (a system overview and 2 user guides),
> end of April. Today is March 13; these people have no
> idea of what it takes to produce documentation... what
> do you think was my first clue?
What does it take? 97 months worth of planning? Just sit down and learn the
product. Sure the deadlines are tight but not impossible. If you want to plan
out every minute detail don't take short term contract jobs. They practically
NEVER lend themselves to extensive planning and analysis.
> 1) 50% of the UIs are currently 'unavailable'. The
> developer is adding them as he goes along. (This is
> contrary to their initial estimation that the test
> system was 80% complete.)
This is common at small startups. If you learn the system well enough you
should start anticipating where the programmer is going.
> 2) The UIs are, well... not UIs. The software is
> essentially a database running in the background using
> active server pages and a web browser.
Get a working UI. That should be priority number one.
> 3) As I mentioned before, there is nothing written
> down spec wise and additionally, the developer is
> given to tweaking the "interfaces" here and there. You
> know what I mean, adding a field here, deleting a
> field there, etc, etc, etc.
Again, this is very common. A lot of early stage development is done this way.
It doesn't matter if it makes sense or not. Its the way startups work. 3/4 of
my clients still work this way (and they make money).
You need to become an expert user. You need to anticipate their moves or at
least know approximately where they are going. Volatile environments require a
different kind of thinking and reasoning. You must be able to handle change and
chaos.
> 4) The timeframe is... well, just plain stupid as
> anyone can figure out.
Its tight but doable.
> What do they want from me? They want task-oriented user guides
> developed for ma and pa types running small
> businesses, all written for the lowest common
> denominator.
You just answered your own question. They want docs for ma and pa.
You can do this. You just need to shave off ALL extraneous stuff and do a quick
and dirty doc. Do not waste any time:
Lock it all down and get moving. 6 weeks is plenty of time to do a quick and
dirty doc. You need to understand the product and the technology first. Don't
even waste time writing anything until you know the product.
> What will I do?
>
> How does this solution seem?....if they tell me exactly
> what those tasks will be.
If you make the documents dependent on them telling you what tasks need to be
documented, you will probably fail. Turn the situation around. You go figure
out what tasks need to be documented and you tell them what you're going to do.
You might succeed then.
> Am I on the right track here... or am I just deluded
> and money hungry at the moment?
It seems to me you're looking for a simple solution to a complex problem. I am
sorry, but one does not exist. You are confronted with a complex, volatile
project. You can't expect a clear path from point A to point B in such an
environment. You have to blaze that path yourself. If you are unwilling or
unable to blaze a path, then walk away. You're better to leave the client with
nothing then to hammer them for a solution they cannot give you. You were,
presumably, hired to figure out the documentation. So, figure it out.
Complaining will not get the documents done nor will it make your client more
supportive.
Andrew Plato
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/
IPCC 01, the IEEE International Professional Communication Conference,
October 24-27, 2001 at historic La Fonda in Santa Fe, New Mexico, USA.
CALL FOR PAPERS OPEN UNTIL MARCH 15. http://ieeepcs.org/2001/
---
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.
