RE: The role of tech writers when working with business/systems analysts

Subject: RE: The role of tech writers when working with business/systems analysts
From: Rose -dot- Wilcox -at- aps -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 23 Apr 2004 13:06:23 -0700


> What is the relationship of tech writers to business or
systems analysts in
> your organization? I'm working with a client that uses all
three, and it
> seems like technical writers could do many of the same
tasks that analysts
> do. Recently, someone in the organization who was
searching for an analyst
> said that there was no such thing as an analyst anymore;
that technical
> writers with specialized skills fulfilled these roles now.
I found that
> interesting because many of the systems analysts that I
have known
> preferred to do programming, not documentation.

In a previous department I worked in, we had business analysts and me,
one technical writer, who worked as a requirements writer. The BAs
gathered the high-level requirements from the customers (all internal),
and then the Business Manager would give the go/no-go to go into the
detailed Requirements for the customer request. After that, I would
meet with a group including reps for the customers, developers, testing
and BAs. I would either rewrite the high-level requirements for a small
enhancement or I would write detailed requirements (with as many drafts
and reviews as necessary) until we could obtain sign off. Most reviews
I did as meetings, so we could come to agreement on language (argh!).

This lead to some complications, mostly entailing conflict in how the
developers wanted the wording (because the requirements were defined as
being input into the design, so their argument was they had to
understand it well enough to design it) and how the customers defined
the wording -- as they wanted the requirements to be defined in terms of
business functionality rather than design. I was for creating a
standard which measured the requirements on the side of the customer
needs, rather than design needs. We were missing a document in our
flow... I think a functional spec might've taken up the slack in
translating from customer business requirements to actual system design.


However, the boss, who was the Business Manager, decided the problem was
the developers and the customers, and decided that they could no longer
attend the Requirements meetings. Instead, I was to give the developers
a review and field their comments. The BAs were the ones who funneled
the customer requirements to me. I found this problematic for a couple
of reasons. One was that the BAs sometimes didn't understand the
customer requirements well enough to answer my questions, so I sometimes
had to get "special permission" to talk directly to the customers. I
usually had to have a BA with me, which wasn't a problem, except for
making the process a little slower (getting time on everyone's
calendar). (I wasn't allowed to talk to customers directly because I
was a member of IT, and therefore presumed to be too technical to
communicate with customers.)

Another complication was that some of the BAs would also take on the
task of funneling *developer* comments to me, which they understood even
less than the business comments. I solved that by pretty much insisting
on a direct line of communication between myself and the developers.

The Business Manager's stance on customer communication couldn't be
easily budged, but I might've worked through it if our entire department
hadn't been decimated by layoffs. At which time I was laid off and
rehired at a lower rate until I found another job, left and then came
back and rehired for a little higher rate (long story) but now am
working on process documents rather than requirements.

The moral of the story for me is that a Technical Writer type can serve
as a good Business Analyst if you know both the technical side and the
business side. Management should support this by giving you direct
lines of communication.

The BAs I worked with were, for the most part, unclear in their writing
styles. One of them spoke English as a second language. One of them
wrote screen plays and did fantastic diagrams, but wasn't very techie,
so some of that BAs writing was confusing and misleading on the
technical side. One of them was very well educated, but couldn't write
worth a darn (each time we read her high-level reqs we all said,
"Huh?"). The best writer, ironically, was the least educated of the
group, but she wrote fairly simply and understandably. She was just so
well versed in the business that she would leave out stuff that the
developers and testers needed to know... because she took that level of
knowledge for granted. All of them would've benefited from mentoring in
their writing. However, management didn't think writing was very
important, so that never happened in my area. So if your management
allows for that, you should be able to make a great impact in this
position... if you have mentoring skills.

I see a lot of roles that overlap between my technical writing skills
and BA skills. During my job searches (to leave here and then to leave
the job I got into after here), I marketed myself as a BA with some near
successes. (One job that I was second for, another where one boss loved
me but the other wasn't sure, etc.) I think if I had stayed out there
searching, I would've been able to lateral into a BA position.

As far as system analyst, I don't think I could, because I believe the
level of expertise in a specific system would be greater than my good,
but generalized, knowledge of various technical systems would be. As
far as business analyst, I may be a little too technical, actually, but
can fill out by studying the business the way I have studied technical
subjects. The overlapping roles include learning customer needs,
communicating those to various levels in the organization in various
forms, acting as a customer advocate, helping with testing, setting up
User Acceptance testing. Skill sets include project management,
communication, writing, problem solving, and knowledge areas include
technology and business. Things to study include methods of
communicating requirements (including Use Cases, dude), User Acceptance
testing, handling difficult and not-so-difficult people, business (in
specific and in general), any regulations and regulatory agencies that
affect the business, and project management.

A technical writer that is considering a switch to BA might also
consider which types of Businesses he or she might prefer and who is
hiring in their geographic region. Health care is big here, and it is
hard to get into without specific health care experience.

Sinc.,


Rose A. Wilcox
Center for Process Excellence, CHQ 8th Floor
602-250-3195
Rose -dot- Wilcox -at- aps -dot- com

'If you want to criticize my methods, fine. But you can keep your snide
remarks to yourself. And while you're at it, don't criticize my
methods.'
Giles
Bad Girls




"MMS <apsc.com>" made the following annotations.
------------------------------------------------------------------------------
--- NOTICE ---
This message is for the designated recipient only and may contain confidential, privileged or proprietary information. If you have received it in error, please notify the sender immediately and delete the original and any copy or printout. Unintended recipients are prohibited from making any other use of this e-mail. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we accept no liability for any loss or damage arising from the use of this e-mail or attachments, or for any delay or errors or omissions in the contents which result from e-mail transmission.

==============================================================================


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5 - ALL NEW VERSION. Now with Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more!

Now is the best time to buy - special end of month promos, including:
$100 mail-in rebate; Free online orientation on content management
functionality; Huge savings on support and future product releases;
PLUS Great discounts on RoboHelp training. OFFER EXPIRES April 30th!
Call 1-800-358-9370 or visit: http://www.ehelp.com/techwr-l

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.



Previous by Author: RE: How do I say I do information mapping without Information Mapping?
Next by Author: RE: Linguistic quirks: beside or against myself?
Previous by Thread: Re: The role of tech writers when working with business/systems analysts
Next by Thread: Hyperlink Index entries in Microsoft Word


What this post helpful? Share it with friends and colleagues:


Sponsored Ads