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.
Normally, I don't have too much problem with Andrew's
postings - at least he slaps us back to reality.
> Ram the damn project through and quit waiting for
> approval. You know the
> cliche: "it is easier to ask for forgiveness then to
> be a sniveling little
> weasel begging for approval."
I cannot agree with this statement. "Ramming a project
through" sets the contractor (me) up for a lot of
damage. Incorrect or missing information is just the
least of the problems...what about your reputation as
a writer? Future business contracts?
If you produce shoddy work, word will get around and
you won't get much business.
The approval process is in place for a reason - to
manage the project. The client gets an idea of where
the project is, what else needs to be done, and where
it is going. It also give him/her/it a chance to
evaluate the contractor's job performance.
> When a client is lazy with me, I start hammering
> them. I show up unnannouced at
> a cubicle, send lots of emails, phone calls.
> Anything to keep the job moving
> forward. Stopping work, folding your arms, and
> having a little tantrum because
> your client didn't respond to you is immature and
I doubt that Scottie was talking about doing that...I
don't know of very many people who would. Most would
do just what you're suggesting. However, if the
project was at a critical stage and the client stopped
responding, yes, I'd be very concerned.
> Most companies could care less about the
> documentation, they just want the damn
> thing done. So push on through, get it done, and
> then tweak it later. It is
> totally, inhumanly impossible to get a complex piece
> of work like a document
> 100% correct the first time. So, play the odds and
> just get the damn work done.
> You can make it perfect on the next revision.
It sounds to me like Scottie did just that: his client
didn't give him much feedback, and he continued on
believing that he was doing what they wanted.
Now, he has to redo the entire thing because *they*
didn't hold up their end of the deal.
And worse: what do think the company's opinion of him
will be, especially if this incident has delayed the
> Since I
> wasn't steeped in a bunch of
> processes and anus-restrictive methodologies, it was
> easy to just slam-bam the
> whole thing into a new form.
Processes exist for a reason. While some people and
companies get too hung up on them, for the most part,
processes are good things. Because everyone uses the
same rules, they can be more efficient and plan for
the future. Why waste time and money to writing a
manual and publishing it, only to have to rewrite it
and re-publish it because of incorrect or missing
information? If the process is done correctly, the
manual can be written and information corrected before
it is published.
> Most clients WANT somebody to boss them around a bit
> and make things happen. If
> you're a limp noodle who has to have a group hug
> every time somebody expresses
> displeasure then, sheesh, go get a job on the set of
> Ally McBeal and get out of
I doubt that very many people want to join a group
hug. However, a some discussion is necessary for
finding out what that displeasure is and what can be
done to improve the work. And I'd rather have that
displeasure expressed on a draft and not the final document.
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com