Re: business analyst?

["Gary S. Callison" <huey -at- interaccess -dot- com>]

On Tue, 2 Sep 2003, andrea_w_brundt -at- hotmail -dot- com ("Andrea Brundt") sez:
> Any tech writers out there ever worked as a business analyst?
> I've heard the job can sometimes be a good next step for a tech writer
> (I've also heard that tech writing can be a good next step for a
> business analyst).

If you're the sort of tech writer that pulls down $50/hr, an entry-level
business analyst job may be a step down. If you only make half that, it's
probably a step up. Depending on the size of the organization, there may
be more room for advancement as an analyst, and it's often a good
stepping stone to project management. 

> So, my question -- have you ever worked as a business analyst?

I've driven projects from the Statement of Work that gets the contract, to
the software requirements specification, done the alpha testing, wrote the
test plan for client beta testing, and written the training materials and
the manual. The first two are really analyst-type functions much more than
tech writer functions, but being able to write clearly doesn't hurt any
there either.

>  Ever worked closely with one?

Most projects aren't like what I just described. I'm usually married at
the hip to an analyst to decides what the goals, the business rules, and
the functional requirements of the project are. Projects live or die
painfully based on the quality of the requirements handed to you by the
analyst. Where a tech writer just has to plan documents, the analyst gets
to plan the entire product. 

Scene between Ace the mechanic and Danny the cop, from the movie _Running
Scared_ (as best as I can remember it, anyways...)
 "Can you do something with this?" 
 "What, you want ray guns, missiles, oil slick, you wanna be James Bond?" 
 "I dunno, just... ...not this"
 "Let me tell you what you want: you want to come and go like the wind, right?"
 "Right."
 "Invincible, invulnerable, invisible."
 "And I want it Thursday at 9."
 "It won't be invisible until 5."

That's a program analyst at work. The customer? They have no idea what
they want, but they know "it should integrate with our existing database,
solve all of our problems, and it should be orange". That statement is
completely meaningless, and it is the analyst's job to make order out of
that chaos. Suppose the system needs to take data from somewhere, do
something to it, and then put it somewhere else. Suddenly there's
three business rules: 1) Get the data, 2) magic happens, 3) output the
new and improved data. Then you look at those oversimplifications of the
process and start to break them down. Where's the data come from? What's
the data dictionary? Error-correction and sanity-checking? Will the user
need to review records and make spot corrections? You answer all of those
questions and a host of others, and pretty soon "get the data" is ten
pages of subparagraphs under 'functional requirement #1: import data'...
It requires a lot of the same knowledge that good technical writers
already have, but there's a further level of abstraction; instead of
documenting 'what is' or 'what hopefully will be soon', you're inventing 
something based on what you think is the best way to solve the problems
the client needs solved - which aren't always the problems they _ask_ you
to solve - and then documenting it, and working with the client to ensure
that what you're doing is going to work for them.

>  Any thoughts on the overlap between tech writing and business
> analysis?

A really good tech writer probably has a better shot at being a good
business analyst than a bad one does, and vice versa. But then again, I
think Scott Adams missed "people who can't write coherently" when he
points out that, in the future, non-computer users will be "on the luge
ride to the dung-flinging Olympics". 

-- 
Huey