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: What is a Business Analyst? From:Keith Hood <klhra -at- yahoo -dot- com> To:Wade Courtney <wade -dot- courtney -at- gmail -dot- com>, "Steve Janoff \(non-Celgene\)" <sjanoff -at- celgene -dot- com> Date:Sat, 3 Nov 2012 18:06:30 -0700 (PDT)
Business analysis of course varies from place to place. In my experience, BA work mostly involves process definition. You have to figure out how the company is doing things, document that, do gap analysis and figure out if there's better ways of working, and document them.
The things that I've most commonly seen BA work involving:
Lines and means of communications between and inside different groups (management, designers, product producers) [designers and producers are not always the same thing] --- try to identify bottlenecks and ways to eliminate or get around them.
Workflows --- usually expressed in things like Visio diagrams, working out what are the real steps performed in getting work done, rather than what management thinks is being done, identifying places where feedback loops are needed, places where there are extraneous or too many steps
Control measures --- finding out what paperwork is involved to request resources or schedule things, identifying both defficiencies and excesses in paperwork requirements, working out ways to make the version control system work, needs for checklists and confirmation procedures to get hard information on when actions are actually done
Meeting control --- almost always too many meetings, figuring out how to get work done and at the same time minimizing the amount of time spent sitting around the table in the ridiculously-named conference room
And of course, trying to correct the almost inevitable lack of decent documentation, and the always inevitable desire of everyone else to pretend they can do their jobs perfectly well without bothering to refer to any documentation at all.
The major pain with BA work is, even if you're a regular employee of the company, you're treated kind of like an 'efficiency expert' brought in from outside. Mostly because the BA's job involves finding out how things really work, and those findings often are not palatable to other people.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Writer Tip: Create 10 different outputs with Doc-To-Help ― including Mobile and EPUB.
