Hi everybody!
Dr. White here, the founder of the Business Analysis Doctor
A question that I see quite a bit in the community is "What do business analysts do??"
So, because this still seems to be a frequently asked question, I decided to weigh in to give
you a high-level overview of the life of a business analyst.
The truth is the responsibilities of a BA can vary greatly depending on the industry,
organization, and level of seniority.
I structured the business analysis process into 7 key competencies that are likely common
across the profession, then I’ll talk about some of the activities involved in those competencies.
Situation Analysis - This involved getting the appropriate information to help you gather
your bearings to make sure you understand what’s happening today, why a change is
needed and what’s the expectations are.
For projects that are opportunity-driven, well usually start by
Analyze current situation Identifying and communicating with the right
stakeholders ensure business needs are identified and defined.
Getting context on where we are today by performing a document analysis on existing procedures
and process maps A clear understanding of the project scope
in terms of the problem, opportunities, or constraints that need to be maintained.
Define future state (high-level) Define high-level goals and a general ideal
state Brainstorming on a range of high-level solutions
Clearly defined the business objectives, high-level requirements, solution scope, and key performance
indicators.
Gap Analysis Now that we know the current state and the
future state- now it’s time to develop a high-level plan (change strategy)
of key activities needed to get from where we are now to where we want to be
Key deliverables of the situation analysis are a refined business case or inputs to the
project charter.
While the BA may not be specifically responsible for creating these deliverables, we should
be involved in or contribute to developing or refining them to ensure that we have the
information we need to do BA work effectively.
Plan BA Work
The situation analysis gives us enough information to work with the project team to consider
the overall project approach or methodology – Are we doing waterfall, Agile, or are
we taking a hybrid approach.
In business analysis, a goal or objective without a plan creates waste
Plan out your business analysis approach activities in alignment with the overall project approach.
While the overall project approach is generally determined by the project team, the business
analyst has jurisdiction over the approach to business analysis activities.
Plan how you will identify and engage with stakeholders
Plan your requirements management and change control process
Key output is a detailed BA plan that should be used as an input into the overall project
plan
Key deliverable for planning BA work is a comprehensive Business Analysis Plan – This
plan may be adjusted as new information is received.
The plan should serve as an input to the overall project plan.
Gather and Elicit Requirements
Gather requirement involves collecting information that is given or readily available to us.
Eliciting requirements involves probing and asking the right questions in order to discover
new information.
BAs should Prepare for Elicitation activities with a plan or agenda
There are numerous techniques a BA could use to elicit requirements but common techniques
include: Interviews,
Workshop, Focus Group,
Survey, Observation,
Document analysis, Interface analysis,
Prototyping
Confirm elicitation and BA information Communication BA information to create a shared
understanding
Key deliverables for gathering and Eliciting Requirement is generally your BRD – Business
requirements document.
Documenting and Analyzing Requirements
Documenting Requirements – Is probably the most important part of the BA skillset because
this is essentially the roadmap for the technical team to implement solutions.
BAs need to be skilled in documenting requirements that are suitable for consumption for different
audiences, meaning we may need to present more technical requirements to the technical
team while communicating more product and process-related requirements to the business.
Common Requirements documentation methods include
A Functional requirements document (FRD), A software requirements specifications (SRS),
which would include traditional requirement syntax.
BAs in an agile environment would likely document requirements in the backlog in the form of
user stories or job stories.
Either approach might be accompanied by supplemental techniques such as
Use Cases, Data Models,
Concept Models, Process Models,
Prototypes and mock-ups
Analyzing requirements - There are over 100 BA techniques that can be used to analyze
requirements.
The BABOK guide discusses 50 of them.
Essentially, you want to analyze how well your requirements are structured in order
to communicate the right message to the right stakeholders and also confirm that nothing
was missed.
This is often done through verifying and validation.
Verify Requirements – Ensuring that requirements are correct and meet the requirements quality
standards.
A requirements checklist is a good way to facilitate this.
When getting approval from stakeholders, we want to make sure they care verifying that
the requirement correctly communicated the business need.
Validate Requirements – In addition to verifying that requirements are correct and meet quality
standards, you also want to make sure that the requirements you are documenting trace
back or fully represent the business requirements.
Create test cases – Depending on your organizational structure, the BA may or may not be responsible
for creating test cases.
Either way, you will want to ensure that every requirement that you have documented is testable
by being decomposed at an appropriate level or accompanied with some form of acceptance
criteria.
Key Deliverables – Software, System, Solution requirements specification (SRS), Functional
requirements document (FRD), Usable Backlog, and possibly some test cases.
Manage and Maintain Requirements
Tracing requirement – to make sure that detailed requirements can be traced back to
a business need and that all needs have an allocated solution.
Getting Approval – Early in the project, specific stakeholders will be designated on
the project RACI to approve requirements and requirements changes.
BAs will need to ensure that requirements are approved by all of the approvers prior
to allocating resources to them.
Change Request - BAs may also be responsible for establishing or facilitating the Change
Request and Review Process for requirements.
Key Deliverables may include a requirements Matrix, and completed change Control Forms.
Support Solution Design and Implementation
Facilitate Joint Application Development (JAD) sessions.
Contribute to design discussions and serve as a proxy to the business when if the technical
team has questions regarding processes.
Ensure design developed by the technical team conforms to and traces back to requirements.
Support the technical team during development activities and help keep the solution on the
right track.
This may also include working with the QA team to provide feedback to the developers
regarding any bugs or issues.
Key deliverable – Solution Design Document – Technical Specification created by the
technical team, however, the BA should be reviewing for accuracy and alignment.
Monitor and Evaluate the Solution
Measuring the performance - After the solution has been delivered for production, BAs should
be involved in monitoring the performance or success of the solution.
In addition, the BA is usually the point person for the business to contact if there are bugs
with the new release.
It’s a common practice that the BA triages the issues before escalating to IT to resolve.
Monitoring KPIs and success criteria that were established in the situation analysis.
If the solution is underperforming the BA should be investigating the user activities
and the solution components to identify the source of the performance variance.
If you are involved in a project that was initiated from a problem instead of an opportunity,
this might be the initial stage of your business analysis process prior to the situation analysis,
and then you’d circle back to this once the solution to the problem has been released.
Well, those are the 7 key competencies of what business analysts do.
Next week, I’ll discuss this from an agile analyst perspective.
If you found this information useful, be sure to like this video and subscribe to the channel
for more BA mastery tips.
If you have any more questions on what business analysts do, drop your question in the comments
and I’ll get back to you!
That’s all for now!
Have a productive and prosperous week!
Until next time!