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.
Re: What about the client's needs? (was: What would Andrew do)
Subject:Re: What about the client's needs? (was: What would Andrew do) From:Andrew Plato <intrepid_es -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 11 Jan 2002 23:54:24 -0800 (PST)
I think there is a common misconception that in order to practice the
"customer is always right" business philosophy you have to be a push over.
I think you can practice CAR without being a pushover. However, it
requires a lot of experience and the ability to read a client's level of
satisfaction.
Yes, some clients are pushy, disorganized jerks that will torture you for
a few bucks. However, I firmly believe that nearly all bad customer
relationships arise out of poor communication. This usually leads to an
escalation of rigidity. One side starts demanding more while the other
feels like they are giving too much. Eventually the entire project is in a
death spiral with both sides pointing fingers and hiring lawyers.
I have a client right now that gave us some troubles, changing dates
around, adding content, the usual. But, we finished the project on time,
within budget, they are happy with the work, and they paid us.
We were able to pull this out for a few reasons:
1. When the client started moving times and dates around, we accomidated
them and negotiated each piece as it changed. It was no big deal, they
just wanted to move some dates up. So we had to put in a few long nights.
Big deal.
2. We spent the time upfront to learn the company's technologies and
market, thus we did not have to worry about them "adding content" at the
last minute. We knew the breadth and depth of information that needed to
be covered. There were no "surprises".
3. When there were changes late in the game, our technical expertise
allowed us to anticipate those changes in advance and prepare accordingly.
4. We got to know the engineers very well, and demonstrated our expertise
with their product and the technology. This won us advocates within the
firm and thus more tolerance to moving dates, deliverables, and costs
around.
5. We analyzed who had to review the material. One was a marketing guy the
other was an engineer. Therefore, we made sure the early parts of the docs
were heavy in marketing speak to please the marketing guy.
The point is, we did a lot more than apply the Universal Technical
Documentation Project Plan handed down from STC. We built a custom
documentation solution that molded to their needs. And when things
changed, we did not throw a fit and rave about how the client doesn't
understand business, we rolled with the punches.
I think one of the more valuable lessons I have come to learn as an
independent consultant is that my audience is only partially the end user.
The first audience I must please is the people reviewing the
documentation. The docs must reflect their vision of the product.
This means writing documents that simultaneously address two, three, and
even four different audiences. That is not easy. And it requires a lot
more than a documentation plan to do successfully. It requires the ability
to understand not only the user's needs, but also the needs of marketing
people, sales people, support groups, engineers, etc.
Engineers want to see documents that extol the marvels and ingenuity of
their creations. Marketing people want to see documents extol the value of
the product. QA people want to see tight, meaningful instructions.
Management types are swayed by pretty graphics and concept diagrams. All
of this is important to the final product. You can't just focus on
delivering a document that suits the reader's needs. You need to get past
the gatekeepers and prove to them you understand the product.
I think this is an area where a lot of writers miss the boat and get into
hot water with clients. They focus so much attention on pleasing the
end-user, they forget to please the people who built the product. Like it
or not, these people are the gatekeepers.
Andrew Plato
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of
your book. What are you waiting for? http://www.iuniverse.com/media/techwr
---
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.