Alternative Role: Technical Writer as a Business Analyst.
By Dishaa Ganapathy, Business Analyst/Technical Writer.
As a technical writer, are you discontented with your
involvement in projects where all the crucial work has
been debated, designed, and developed? Do you feel that
the current job market, growing scarier by the month,
is friendlier toward people who can handle multiple
roles? Do you wish to determine the needs of a client to
help define a solution as well as document it as a final
product? If you have nodded faintly or vigorously to these
questions, venturing into the business analysis arena may
be an idea worth considering.
Performing the role of a business analyst can be a
rewarding experience, like most things in life, if one has
the right expectations about the role. A technical writer
wanting to work as a business analyst may be interested
to know what similarities and differences exist between
the two disciplines, if any. This understanding may
enable a technical writer realize skills that he/she already
posses and acquire new ones.
This short article aims to highlight similarities between
the two disciplines. The article also points out areas
where important differences between business analysis
and technical writing arise and cite some basic resources
for a newbie business analyst.
Commonalities.
In the IT realm, professionals from either technical
writing or business analysis have certain similar
expectations:
Desire to
• work with technology
• Good verbal communication skills
• Skillful structuring and presentation of information
to an intended audience
• Ability to analyze needs of the end user
Domain Knowledge and Tools:
To produce quality documentation, a technical writer must have a good understanding of the application/technology that
requires authoring. To effectively elicit requirements and
document requirement specifications, it is crucial for a
business analyst to have a good understanding of the
business domain/technology. Both technical writing and
business analysis offer its professionals specialized tools
that enable them to handle their tasks with efficiency.
While technical writers use FrameMaker and RoboHelp,
business analysts have at their disposal tools like Rational
Requisite Pro and MS Visio to define, model, and track
requirements.to
• work with technology
• Good verbal communication skills
• Skillful structuring and presentation of information
to an intended audience
• Ability to analyze needs of the end user
Domain Knowledge and Tools: To produce quality
documentation, a technical writer must have a good
understanding of the application/technology that
requires authoring. To effectively elicit requirements and
document requirement specifications, it is crucial for a
business analyst to have a good understanding of the
business domain/technology. Both technical writing and
business analysis offer its professionals specialized tools
that enable them to handle their tasks with efficiency.
While technical writers use FrameMaker and RoboHelp,
business analysts have at their disposal tools like Rational
Requisite Pro and MS Visio to define, model, and track
requirements.
Information Gathering: Both roles require individuals
to interact with cross-functional units to get the necessary
information. A technical writer works with developers,
testers, business analysts, and support teams to document
end-user documentation. A business analyst must interact
with the business stakeholders, end-users, developers,
system architects, testers, and technical writers to
facilitate, document, and coordinate the delivery of a
business solution. The skill to not only ask the right
questions but to ask them in the right manner is crucial to
both disciplines.
Writing: The main job of a technical writer is to write
end-user documentation in a way that helps the audience
perform tasks. The business analyst, on the other hand,
writes requirements for a specific audience in a way
that helps them understand and agree upon system and
business requirements to arrive at a viable solution.
Presenting information in a logical structure, with clarity
and accuracy, is an essential component for either role.
Understanding the End-user: Both roles require
individuals to sit down with end-users and elicit
requirements. This means understanding the end-user,
finding out their concerns and issues, and delivering a
product that addresses those concerns and issues. This
may include addressing user interface design issues,
prototyping, and getting involved in usability testing.
Points of Departure
Looking at the commonalities, some might not consider
technical writing very different from business analysis.
As real and valid the commonalities are, there are indeed
crucial differences between the two disciplines. To help
the reader understand these differences, the analogy of
a blind person versus a person with vision drawing an
elephant may be useful.
Different Contexts: Setting aside ideal conditions and
work modes, typically, a technical writer is brought into
a project after the requirements are agreed upon. The
system design and development are complete and the
testing phase is in process. The system is in front of the
person ready to be tried, tested, and documented.
A business analyst is presented with a radically different
environment. When the business analyst starts a project,
the target or intended system/solution is not present. The
only thing that exists is an idea or business need from
which a suitable system or solution must be built that
meets the business need. Much like
the blind man drawing an elephant
by touching and feeling the body
of an elephant, a business analyst
has to gather, elicit, and probe for
information from different sources to
produce a document that transforms
business need to a well-defined
requirement specification. With
the help of facilitation, modeling,
documenting, and other techniques
the business analyst must draw as
clear a specification as possible.
Domain Knowledge and Tools:
Though domain knowledge is
good-to-have for a technical writer,
it is quintessential for a business
analyst. Since solution architecture
and development depends on
requirement specification, delivering
the specification within a specified
time frame is essential. Domain
knowledge—or the lack of it—can
be a critical factor in determining if
requirements are complete and if the
solution is delivered in the approved
time frame.
Let us consider an example where
user X wants to reduce the time he/
she takes to make coffee. A business
analyst is tasked with finding out
possible issues in the current process,
cull out the needs for a target system
that mitigates current problems,
and effectively fulfill needs of user
X. Since the success or failure of a
solution depends on the effectiveness
of requirements specification, to
elicit the right requirements is vital.
To this end, a business analyst is
vastly benefited by prior knowledge
of systems and process – in this case
of coffee making. Having precedence
or prior domain experience equips
the business analyst to ask the
right questions and cull out not-so apparent
requirements.
A business requirement document
and a software requirement
specification document can then be
effectively drafted. Therefore, a prior
understanding of relevant business
process goes a long way in getting
the right requirements in.
On the other hand, once the target
system is built—in this example, say
a coffee maker—a technical writer
may be able to easily document the
coffee-making process by just seeing
how the coffee maker works, even
though he/she may have never seen a
coffee maker before.
Information Gathering: The
method of gathering information
varies greatly as well. As a technical
writer, boundaries for gathering
information are defined, since the
system/solution is already built.
But as a business analyst, effectively
moderating requirements elicitation
sessions is paramount from the
perspective of time management.
Many times, business owners are
not entirely sure what they need.
A simple question, such as “do you
want milk added to the coffee or
not?”, could result in endless hours
of discussion. Thus it is imperative
to ask the right questions and in
the right manner. During tight
deadlines, the KISS (Keep It Simple
Stupid) guideline works well.
Though a technical writer interacts
with the entire project team, the
interaction is relatively minimal and
not varied. On the other hand, a
business analyst not only has a wider
range of audience to interact with—
from the business stakeholder to the
technical writer and tester, but the
nature of interactions differs widely.
From the stakeholders, the business
analyst must gather information. To
the developers, testers, and technical
writers, the business analyst must
disseminate the requirement
specification and keep the team
updated of changes to requirements.
The business analyst must review
test cases, user guides, and in some
cases may even execute test cases
and writer end user documentation.
Therefore, the business analyst is
involved throughout the lifecycle of
a project.
Writing: The method of writing
varies as well. In technical writing,
words such as “will” and “shall” are
hardly ever used. Business analysts,
who provide guidelines to testers and
developers for building a solution,
often use words such as “will”,
“must”, and “shall.” For example, “the
system must be able to send email
notifications to registered users.”
Getting into Business Analysis
For a technical writer considering a
move into business analysis, several
criteria may need to be met. These
include a person’s interest in waiting
to make a transition, available
opportunities, and necessary skills.
Moreover, it may not be necessary
to make a complete shift to business
analysis. A person who has moved
into business analysis can continue
working on technical writing tasks,
thus doing a bit of both. Search on
Indeed.com for “technical writer/
business analyst” yielded a dozen
results country wide.
Websites:
IIBA: International
• Institute of
Business Analysis (IIBA®) is an
independent non-profit professional
association serving the growing
field of Business Analysis. Website:
http://www.theiiba.org/AM/Template.cfm?Section=Home
• IIBA has created the Certified
Business Analysis Professional™
(CBAP®) for Business Analysts. For
more information, refer to http://www.theiiba.org/AM/Template
cfm?Section=Certification.
• Modern Analyst: A great
community for business and systems
analysts. Has a good collection of
articles, news, and features to help
practitioners participate in and
contribute to the business analysis
community.
Website: http://www.modernanalyst.com/
Books:
• More About Software Requirements:
Thorny Issues and Practical Advice by
Karl E. Wiegers
• The Business Analyst’s Handbook by
Howard Podeswa
• Seven Steps to Mastering Business
Analysis by Barbara A. Carkenord.
• Writing Effective Use Cases (Agile
Software Development Series) by
Alistair Cockburn
• Getting It Right:
Business Requirement Analysis Tools and
Techniques by Kathleen B. Hass,
Don Wessels, and Kevin Brennan.
Dishaa Ganapathy has over eight years
of experience in the IT realm. Her
interests include, but are not limited
to, technical communication, business
analysis, usability, and information
design.
In her spare time, Dishaa is interested
in outdoor activities, such as, hiking and
canoeing. She also enjoys watching Food
Network and Classics on Turner Classic
Movies.
