9/15/12 How to Become (or Manage) a Successful Business Analyst - Business Analysts Handbook

1/5 businessanalyst.wikia.com/wiki/How_to_Become_(or_Manage)_a_Successful_Business_Analyst
Spring 2006,
By Glenn Brl
Completing information technology projects on time and on budget is both essential and a struggle for most
organizations. Business analysts can help shepherd projects through to successful results by gathering
requirements from a business area and presenting them in ways that are understandable and actionable by the
organization.
Unfortunately, the business analyst's job description is often vague. While many organizations know what needs to
be done, they don't know how to identify and develop the skills necessary to meet these needs. As such, we've
outlined here eight essential competencies necessary for success in this job. For each competency below, we
explore the skills, knowledge and abilities inherent to each competency and provide practical tips for using these
competencies as guidelines for improving the efficiency of business analysts within any organization.
Business Analyst Competencies
By definition, a competency is made up of three components: knowledge, skill and ability. Knowledge considers
"what is being measured?" Skill looks at "how is it done?" Ability examines "to what degree can it be done?"
Competency #1: Eliciting Requirements
On the most basic level, the business analyst's job is to gather and document user requirements. Requirements are
needed by a user or client to solve a business problem or achieve a business activity, and they are tied to the needs
of business, rather than the constraints imposed by technology.
This means that the business analyst's job has more to do with identifying the desired results than the actions or
resources required to reach these results. The purpose of gathering requirements is to provide an understanding of
the problem or opportunity before trying to propose the solution.
Competency #2: Creating the Business Requirements Document
A Business Requirements Document (BRD) is an exhaustive, written study of all facets of regulatory, business,
user, functional or non-functional requirements. It is a detailed profile of primary and secondary users and comes
directly from the requirements the business analyst has already gathered. It only makes sense, then, that the BRD
should be written by the business analyst.
After the document is completed, the business analyst and the client, or user, meet for a formal review and to
formally approve the BRD. The document is then shared with the rest of the development team, including the project
manager. In creating the BRD, a business analyst should define the various sources for requirements and the
placement and relevancy of these requirements.
How to Become (or Manage) a Successful Business A
nalyst
9/15/12 How to Become (or Manage) a Successful Business Analyst - Business Analysts Handbook
2/5 businessanalyst.wikia.com/wiki/How_to_Become_(or_Manage)_a_Successful_Business_Analyst
The Essential Business Analysis Skills
Analyze & solve problems
Understand the business
Communicate effectively (write & speak)
Manage client relationships
Facilitate discussions
Negotiate & build consensus
Model data & processes
Plan & manage activities
Facilitate & develop business strategy
Understand & manage organizational change
For example, senior business analysts may identify such items as the project charter and vision, business-case,
requirements work plan, vendor request documents and business contract documents. They may also work with the
project manager to define the project and product scope. Any requested changes to any area of the BRD before or
after work has begun must be carefully reviewed by the business analyst who would then work with the client or user
to make the necessary changes. Business requiremet vary as per the co-ordination which tends to grow the
business system.
Competency #3: Modelling
Modelling refers to the ability to conduct structured analysis. In business analysis, modelling is used to support and
enhance text-based requirements, help identify and validate requirements, document and communicate requirements
and, finally, organize information into coherent ideas. The most common types of business analysis models include
business models, process models, data models and workflow models.
Experienced business analysts develop models such as business interaction charts or entity relationship diagrams
and examine how the business process works now, in order to develop improved charts and help troubleshoot in the
future. When looking at models, the business analyst is looking for problems and opportunities that will change the
process or the deliverable.
Competency #4: Object-Oriented Analysis
An object model is an abstract representation of the process and data requirements of a system, based on
separating the system into units called objects. Each object includes the data and operational characteristics of one
business item. Object-oriented analysis is particularly important to business analysts as a business-planning tool to
depict the hierarchy of business functions, processes and sub-processes within an organization.
Generally speaking, individuals working on object-oriented analysis should be competent in structured analysis.
Object-oriented analysis requires a clear understanding of both the process and data modelling techniques, including
the ability to separate systems into objects.
Junior business analysts may get involved in the functional separation of the as-is state of a project, including
9/15/12 How to Become (or Manage) a Successful Business Analyst - Business Analysts Handbook
3/5 businessanalyst.wikia.com/wiki/How_to_Become_(or_Manage)_a_Successful_Business_Analyst
forming a simple model of this state. From this model, an intermediate business analyst may consider developing
activity diagrams to further clarify requirements.
With diagrams in hand, a senior business analyst is likely to begin designing the to-be state during one-on-one
interviews, group interviews and the documentation process. Essentially, each of the processes involved in object-
oriented modelling ensures that the requirements are properly communicated to the developers and administrators.
Competency #5: Testing
When it comes to testing in business analysis, the first thing to understand is that the term applies to several
different levels of work. First, business analysts are looking to test the products to validate whether the requirements
have been met. They develop test scripts, test plans and test scenarios based on the as-is state as well as the to-be
models. Testing requirements should be done in recurring stages to ensure that, by following the requirements, the
desired deliverables will be met.
The second level of testing is more familiar. This is testing the functionality of the physical product - testing lines of
code and user testing of graphical appeal, speed and functionality. Black box testing and glass box testing fall into
this category. As with the first type of testing, this testing also makes sure we reach the desired state, but it is
based on user acceptance.
In testing situations, business analysts design test cases and review the results from these scenarios.
Competency #6: End-User Support
It's a common misconception among project teams that the project ends when the deliverable is completed. This
isn't true. Business analysts should be aware that end-user support after the product is delivered is almost as
important. The role of the business analyst is not to act on behalf of the training team, but to complement the
training team's efforts with their knowledge of the business requirements.
Much of the documentation created in the process of identifying the deliverables is invaluable to the development of
training needs and end user support, including user manuals and reference materials. Business analysts work with
end-users after deployment to clarify any high-level questions that need to be addressed. They also work closely
with training managers and facilitators to define requirements to deliver the training supporting the business needs.
Finally, business analysts assess and evaluate all feedback from team members, those individuals involved in the
deployment of the product and any pilot or "test" groups, to ensure that the requirements necessary to correct any
issues are addressed in future releases, iterations or versions of the product. It depends as per the requirement
Competency #7: IT Fluency
How much IT knowledge is enough for a business analyst? The IT background for a competent business analyst
depends entirely on the environment and possibly the industry vertical within which he or she works. It's important to
remember that IT fluency is just one of eight competencies that a successful business analyst must have. Also, just
9/15/12 How to Become (or Manage) a Successful Business Analyst - Business Analysts Handbook
4/5 businessanalyst.wikia.com/wiki/How_to_Become_(or_Manage)_a_Successful_Business_Analyst
because an individual is fluent in a given technology does not automatically qualify him or her as a business analyst.
This is a mistake made by many organizations.
In theory, a great business analyst should have the wherewithal to understand which resources would be appropriate
to help define and validate both requirements and specifications within a given project and product scope.
In examining the different stages of a business analyst, a person at the junior level would need to have a clear
understanding of the IT products and tools necessary for the business to function. An intermediate business analyst
may understand interconnectivity and relationships between the tools and, perhaps, system architecture and
information architecture. A senior business analyst will demonstrate his or her IT fluency across an industry vertical.
He or she may also have a very clear understanding of how different IT products are related, interface with and
connect to each other, as well as the positive or negative impact they may have in a given situation.
Competency #8: Business Process Re-Engineering
Considered the "big-picture thinking" of business analysis, Business Process Re-engineering (BPR) is a rapidly
growing part of business analysis. In fact, lately many companies have been grouping business analysts around this
specialty and developing teams of [process analysts]. This is the phase in which business analysts seek out both
problems and opportunities. BPR uses a variety of modelling techniques in order to look at the bigger picture, while
still thinking tactically.
Business analysts' responsibilities are often to identify, using various modelling techniques, possible areas of
improvement to walk the client or user through each step of the process, examining individual tasks that could
potentially be improved and then to actually make suggestions for improvements.
You've Defined the Competencies . . . What Next?
Now that the competencies have been spelled out, how do companies go about developing business analysts? First,
they must develop and document specific job functions, and the task or tasks related to a particular level of
competency. Next, they should assess existing knowledge. Finally, they must provide the training needed to develop
the competencies outlined above. The first step in ensuring that an organization's business analysts have the
knowledge, skills and abilities necessary for success is to develop job functions, associated tasks and activities,
and expected inputs and outputs that would in turn support an organizations defined competency.
When job descriptions have been determined and approved, it's essential that organizations "take inventory" of the
competencies their business analysts already possess. There are specific assessments to test these
competencies. Such tools will establish the knowledge level of individuals in each competency area and of the team
as a whole. If knowledge isn't base-lined, improvements cannot be observed for overall performance for the individual
and the organization.
After establishing the business analysis knowledge and ability levels within an organization, the next step is to
implement training to improve any competencies that may be lacking. The competencies above can also serve as a
validation tool for such training. They can be used to ensure that the performance improvement program is
Bitdefender Total Security 2012
9/15/12 How to Become (or Manage) a Successful Business Analyst - Business Analysts Handbook
5/5 businessanalyst.wikia.com/wiki/How_to_Become_(or_Manage)_a_Successful_Business_Analyst
comprehensive, that no behaviours or competencies are missed, through proper training, on the job experience as
well as the appropriate coaching and mentoring.
Keeping in mind the eight competencies, as well as the necessary people, processes, tools and technology, will put
an organization on the path to better business analysis and, ultimately, to more successful projects.
Glenn Brl has more than 14 years of experience in many facets of business, including project management,
business analysis, software design and facilitation. In his current position as Client Solutions Executive for ESI
International , he is responsible for supporting a global team of business consultants working with Fortune 500
organizations in a variety of sectors, including financial services, manufacturing, pharmaceutical, insurance and
automotive, as well as government agencies. Glenn can be reached at [email protected]
This article was reprinted here with permission from the Author.