Business Analysis Approach Template

by https://www.businessanalyststoolkit.com/

If you have any questions or comments please contact Alexandra Cordes at

[email protected]

Instructions:
This approach template contains examples and annotations in grey “annotation” font. When
writing your project statement, remove the “annotation” font and replace it with “normal” font.
This title page should be removed altogether. This document is intended to consolidate your
understanding of the issues and deliverables required in the business analysis components
of a project. It does not have to be used as a formal deliverable but may be used in the
absence of an existing project plan. Also a PDF copy is included in this pack so you can
reference back to our original instructions and examples.
Business Analysis Approach for <<Insert Project Title Here>>

<<insert logo>>

<<Name of Organisation>>

Business Analysis Approach

<<Insert Name of Project>>

Version <<insert document version number>>

<<Month>> <<Year>>
<<Insert document status, e.g., DRAFT>

Page 2 of 13
Business Analysis Approach for <<Insert Project Title Here>>

Document History
Document Location
Enter the file location of the document here.

Revision History

Version From Author Change Summary

Distribution
This document has been distributed to:
Name Title Date of Issue Version

Approvals
This document requires the following approvals.
Name Signature Title Date of Issue Version

Page 3 of 13
Business Analysis Approach for <<Insert Project Title Here>>

Table of Contents
1 Introduction ...................................................................................... 5
1.1 Purpose ....................................................................................................................... 5
1.2 Objectives .................................................................................................................... 5
1.3 Background ................................................................................................................. 5
1.4 Scope .......................................................................................................................... 6

2 Organisational Context .................................................................... 7

2.1 Current Condition ........................................................................................................ 7
2.2 Root Cause Analysis ................................................................................................... 7
2.3 Target Condition .......................................................................................................... 8
2.4 Criteria Success Factors ............................................................................................. 8

3 Planned Activities & Management .................................................... 9

3.1 Deliverables................................................................................................................. 9
3.2 Risks .......................................................................................................................... 10
3.3 Quality Management ................................................................................................. 11
3.4 Communications Strategy ......................................................................................... 11
3.5 Stakeholder Engagement Plan ................................................................................. 12
3.6 Requirements Management...................................................................................... 13
3.7 Follow Up .................................................................................................................. 13

Page 4 of 13
Business Analysis Approach for <<Insert Project Title Here>>

1 Introduction

1.1 Purpose
Briefly describe the purpose of the business analysis activities required for the proposed
initiative.
For example:
This document describes the scope of business analysis activities for determining a suitable
technology solution to support the data collection, reporting and analytical requirements for
operations management, service delivery and capacity planning for <<the organisation /
business area>>.

1.2 Objectives
Briefly describe the objectives of the business analysis components of the project.
For example:
The overall objective of the project is to implement an operational reporting system for <<the
organisation / business area>> by <<insert date>>.
The objectives for the initial business analysis component of this work are as follows:
• Validate and document requirements for data collection and reporting of staff
activities for the purpose of operations management, service delivery and capacity
planning; and
• Develop a business case which evaluates technology options and recommends a
way forward for implementation of a solution.

1.3 Background
Briefly describe the project background and the impetus for initiating change.
For example
Substantial work has already been carried out to gather requirements by the recently
established <<name of business unit>>. These requirements will be fully reviewed, validated
and documented in a Business Requirements Specification, which includes business and
user requirements defined as follows.
• Business requirements are higher-level statements of the goals, objectives, or needs
of the enterprise. They describe such things as the reasons why a project is initiated,
the things that the project will achieve, and the metrics, which will be used to
measure its success.
• User requirements describe the stakeholder needs of the system to meet business
demands.

Page 5 of 13
Business Analysis Approach for <<Insert Project Title Here>>

1.4 Scope
1.4.1 Scope Inclusions
Define the business analysis activities and deliverables that are in scope of the project.
For example:
• Review of existing documentation and requirements definition conducted to date,
• Stakeholder consultation to elicit business requirements,
• Development of a business requirements specification, and
• Development of a business case including technology options and recommendations.

1.4.2 Scope Exclusions

Define the business analysis activities and deliverables that are not in scope of the project.
For example:
• The definition of functional capabilities the system will be able to perform in terms of
behaviours or operations and data requirements.
• The development of a functional specification including wireframes, activity diagrams,
functions, features, entity relationships, data exchanges and business rules that
apply to the flow of user interactions and system responses, and
• System implementation (including change management).

Page 6 of 13
Business Analysis Approach for <<Insert Project Title Here>>

2 Organisational Context

2.1 Current Condition

Describe the problems that exist which have contributed to the need for change. Problems
must be written in practical business related terms so the decision makers can understand
why this proposal is put forward. Read more about defining the problem in the article 6
Strategic Categories for Describing a Problem Statement.

For example:
• Lack of consistent management processes and standards to support best practice
operations management. This is caused by lack of inherent operations management
practice and operational management training and experience.
• Lack of consistent and standardised information available to support management
processes such as capacity planning and forecasting. This is due paper based
business processes (lack automation).

2.2 Root Cause Analysis

Use the Five Whys technique for your root cause analysis. According to this technique, you
haven’t got to the root cause of a problem until you’ve asked the question “why?” at least five
times. Guidelines for using the Five Whys technique is described in the article “Why” is the
How of Getting to the Root Cause of a Problem. Put your answers in the table below.

Steps Answer
First immediate cause
Cause for the first immediate cause
Deeper cause to the preceding cause
Deeper cause to the preceding cause
Deeper cause to the preceding cause

Page 7 of 13
Business Analysis Approach for <<Insert Project Title Here>>

2.3 Target Condition

Describe the target condition by describing how core issues identified will be addressed.
For example:
The target condition for the implementation of a reporting system is to automate and
standardise data capture, reporting, and analytical requirements to enable the ability to:
1. Support operations management best practice through timely provision of information
and reports,
2. Quantify production and non-production work at an individual and team level for the
purpose of understanding productivity measurements,
3. Facilitate volume trending, forecasting, and operational contingency planning,
4. Provide a long term, strategic view of staffing requirements linked to forecasted
demand volume, attrition, and performance,
5. Minimise crisis management through regular resource planning which is based on
accurate historic and current data,
6. Plan and leverage staff resources to gain efficiencies in customer service, and
7. Develop and manage quantifiable individual and team performance targets and
standards.

2.4 Criteria Success Factors

Describe the elements that are necessary for the project’s success.
For example:
• Increased invoice processing by 25%.
• Reduction of non-production time spent at a team level by 15%.
• Decreased operational reporting errors by 30%.
• Increase in service response times for client enquiries by 20%.
That the above examples would not apply to the overall example given in this template.
However, they exemplify SMART success factors.

Page 8 of 13
Business Analysis Approach for <<Insert Project Title Here>>

3 Planned Activities & Management

3.1 Deliverables
Described the planned activities, the reason for the activity, deliverables and delivery dates
in the table below.
Example activities are shown.
Activity Reason Deliverable / Format Delivery Date
Perform document
review
Conduct
requirements
workshops
Develop a Business
Requirements
Specification
Submit draft
Business
Requirements
Specification
Present Business
Requirements
Sign off Business
Requirements
Specification
Develop a Business
Case
Submit draft
Business Case
Presentation of
Business Case
Sign off Business
Case

Page 9 of 13
Business Analysis Approach for <<Insert Project Title Here>>

3.2 Risks
Describe the risks that may occur. Risks should be identified according to the Risk
Management Framework defined by your organisation.
Example risks are shown.
Description Risk Mitigation
If business SMEs are not available Moderate Ensure the Project Plan is reviewed
in the required timeframe, then the and signed off by the business.
quality of the output, the project Publish project timeframes in
schedule, and/or budget may be advance.
impacted.
Gain appropriate buy-in from Senior
Leadership.
Ensure business commitment
received to timeframes during project
planning.
If Senior Leadership does not Moderate Strong communication with Senior
clearly understand and/or articulate Leadership team on project
the expected outcome, then the deliverables.
outputs of this initial project will not Solid engagement with Senior
provide value and will put at risk Leadership through all activities of the
continued use of the system. project.
Senior leadership involvement in
Project Steering Committee.

Page 10 of 13
Business Analysis Approach for <<Insert Project Title Here>>

3.3 Quality Management

Describe the activities that will be undertaken to ensure the quality of project deliverables.
For example:
• There will be <<daily/weekly/fortnightly>> project status updates to the project
manager,
• All major deliverables will be subject to a quality review and formal sign-off by
<<insert names>>,
• The project will involve continuous stakeholder involvement and interview sessions
will be documented by the business analyst and validated by the relevant
stakeholders,
• The project manager and <<insert role name(s)>> will peer review all formal
deliverables,
• Industry standards and best practices will be applied to the elicitation and analysis of
requirements, and
• Changes in scope will be controlled via the change control process, <<insert
reference>>.

3.4 Communications Strategy

Describe the planned communications with stakeholders that will occur throughout the
project.
A simple example is shown in the table below.
Input From Project manager Business analyst Business analyst
Business analyst
Reported To Business sponsor Business sponsor Business sponsor
Project manager Project manager
Frequency At project Informal daily End stage
commencement and Formal weekly
as required
Information Project plan Status report Handover of
Sign off Issues/exceptions deliverables
Sign off

Page 11 of 13
Business Analysis Approach for <<Insert Project Title Here>>

3.5 Stakeholder Engagement Plan

Provide an overview of the stakeholder engagement process.
An example is shown in the table below.
Title Consultation for the implementation of an operational reporting
and analytical system.
Representative • <<Stakeholder class>> on <<date(s)>> for <<type of
group/s being engagement activity>>, including:
consulted o <<Name and role of stakeholder>>
o etc
• <<Stakeholder class>> on <<date(s)>> for <<type of
engagement activity>>, including:
o <<Name and role of stakeholder>>
o etc
Managing Officer <<Name and role>>
Start Date <<Insert date>>
End Date <<Insert date>>
Purpose Consult with stakeholders to determine a suitable technology
solution to support the data collection, reporting and analytical
requirements for operations management, service delivery and
capacity planning for <<the organisation / business area>>.
Method Requirements elicitation workshops will be conducted with
stakeholders within the <<business area(s)>>. This will be
followed by a single workshop to present the business
requirements documented and validated.
Based on the business requirements, a business case
describing technology options for implementation will be
developed. This will be followed by a single workshop to present
the findings in the business case and recommended approach.
Output After each workshop, minutes will be written describing the
issues, constraints and individual stakeholder requirements.
Publication Meeting minutes and workshop outcomes will be documented
and made available to the relevant stakeholders.
Issues An issues register will be maintained to keep a record of all
issues that arise through the consultation process that may
affect the implementation of the system.
Risks Any risks that are identified during stakeholder engagement will
be updated in the Project Plan.

Page 12 of 13
Business Analysis Approach for <<Insert Project Title Here>>

3.6 Requirements Management

Describe how requirements will be collected, analysed, documented, and managed
throughout the lifecycle of the project.
Requirements Identification Describe the methodology that will be used to identify
requirements, e.g., interviews, workshops, surveys,
and existing documentation.
Requirements Analysis Describe the methodologies that will be used to
analyse requirements.
Requirements Prioritisation Describe how requirements will be prioritised, e.g.,
MoSCoW.
Requirements Traceability Describe the method for requirements traceability, i.e.,
will a traceability matrix be maintained.
Requirements Documentation Describe the methodology that will be used to
document requirements including versioning.
Requirements Management Describe the methodology that will be used to manage
requirements. Include the change control process for
changed requirements.
Tools & Environment Describe the tools that will be used to manage
requirements, e.g., Sparx Enterprise Architect.

3.7 Follow Up
Plan Actual
Insert a plan here that will measure the After follow-up, record the results of
effectiveness of the change. Ensure that implementation.
you’ve “baselined” the current condition with Record the date of actual follow-up.
some measurable data e.g., the length of
time and cost a process takes to complete.
Using the critical success factors, the
implemented change can then be measured
and compared with the baseline data.
Indicate when it will be measured, and by
whom.

Page 13 of 13