itSMF event

1. 05.03.20
Pierre Olivier Reinards
Introduction to Business Analysis

2. 2
Agenda
1 What is Business Analysis?
2 How can Business Analyst make an impact on projects?
3 The main activities of Business Analyst in the different phases of a project lifecycle

3. 01
Why do we need Business Analysts?

4. Business Analysis is…
Solution (Output of the project & business benefit)
Identification and management of requirements (with stakeholders)
Evaluation of an organization’s needs
4
Source: PMI Professional in Business Analysis (PMI-PBA)FAQs, http://www.pmi.org/~/media/PDF/Certifications/PMI-PBA_FAQs_v2.ashx, read 23/03/15

5. What is a project?
“A temporary organization that aims to deliver a new product or service”
5

6. The Business Analyst
• Communicates with stakeholders
• Conducts stakeholder analysis
• Gathers/elicit business requirements
• Evaluates solution performance
• Verifies whether the end product meets the
stakeholder needs
• In charge of dispatching work package + refine
requirement + cost estimation ( CAPEX /
OPEX)
The project manager
• Responsible for project success of failure
• Identifies stakeholders
• Manages entire project lifecycle
• Ensures activities meet project requirements
• Communicates across project
6
The differences between a business analyst and a project manager

7. Origins of Business Analysis
Companies have undertaken information technology (IT) projects to sustain and adopt new
technologies.
 major problems or opportunities can arise and change becomes the only way to survive
 an IT project might be riskier than people think
What can go wrong with IT project?
 Schedule (tight deadlines / no deadlines)
 Features (bugs, too limited, too much)
 Lack of Resources (High Costs, developers ..)
 Stakeholders (unavailability, agenda mismatch, different personalities, communication etc.)
7

8. Why are Business Analysts Important?
8
52%
38%
10%
Large Projects > 1 M USD
Challenged Failed Successful
20%
4%
76%
Small Projects < 1 M USD
Challenged Failed Successful
Successful: delivered on time, on budget, with required features and functions
Challenged: late, over budget, and/or with less than the required features and functions
Failed: cancelled prior to completion or delivered and never used
Source: http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.pdf

9. Why are Business Analysts important?
9
20%
50%
30%
Systems’ Features Use
Often Used Hardly to never used
Sometimes / infrequently
74
59
69
Time
Cost
Feature
0 20 40 60 80
Projects Overruns
Small Projects
Introduction to Business Analysis
Source: http://www.immagic.com/eLibrary/ARCHIVES/GENERAL/GENREF/S130301C.pdf

10. 02
Business Analysts and their environment

11. Key drivers for BA projects
Political
•Brexit effect
•Internationalization
to growth markets
Economical
•Low GDP Growth
•Fintechs
•Alternative lending
platforms
•Growing SRI
•Rising inflation
•Centralization into
main offices
•Improve cost
efficiency
•Client focus
Social
•Increasing
involvement of
women
•Increased value of
CSR
•Increased flexibility
of workforce
•Collaboration
platforms
•Teleworking
Technological
•Digitalization
•Biometric
authentication
•IoT
•RPA
•Open API
•Blockchain
•Cybersecurity
•Mobility / BYOD
•Cloud
Legal
•PSD2
•MIFID II
•KYC
•GDPR
•Basel III
Environmental
•Low carbon
economy
•Supporting of
green technologies
Presentation title11

12. The Business Analyst is the bridge between the business and the IT
12
Easing the
communication
Translating
technical or IT
issues
Transmitting
business
requirements
to the
development
team

13. Project lifecycle
13
1
Conception
2
Planning
3
Production
4
Handover
5
Utilization
6
Closedown
Client
Users
Third Parties
Client
Project Team
Third Parties
Client
Project Team
Producer
Third Parties
Client
Project Team
Producer
Third Parties
Client
Users
Third Parties
Client
Third Parties
Stage
Interested
Parties

14. The Agile methods in a nutshell
14
The Agile
Methods
Extreme
programming
(XP)
Lean
Crystal
Kanban
Scrum
Feature
Driven
Development
(FDD)

15. Agile from Spotify
15

16. The Agile methods vs traditional methods
* System Development lifecycle
16
AGILE SDLC TRADITIONAL SDLC*
User requirements Iterative acquisition
Detailed user requirements are
well-defined before
coding/implementation
Rework cost Low High
Development
direction
Readily changeable Fixed
Testing On every iteration After coding phase completed
Customer
involvement
High Low
Extra quality
required
for developers
Interpersonal skills and
basic business
knowledge
Nothing in particular
Suitable project
scale
Low to medium scaled Large-scaled

17. Description of the pros and cons of the different SDLC models
17
Waterfall model
Pros
Clear requirement before development
starts
Phase completion in specified period of
time
Easy implementation of this linear model
Primary phase of documentation to follow
for the quality of the development
Clear separation between responsibilities
Cons
No implementation of requirement changes
in the current development process
Problems linked to a development phase
rose after the phase is signed off (badly
structured system)
V-model
Pros
Highly disciplined model (suited for critical
projects)
Completion of phases one at a time
Tailored for smaller projects where
requirements are very well understood.
Specific deliverables and review process
for each phase
Cons
Very rigid and costly flexibility
Requires an update of the requirements
documents and test documentation if
changes occurs
Not proposed for short-term projects
Agile
Pros
Ability to respond to the changing
requirements of the project
No guesswork between the development
team and the business users – they work in
the same team, together
Face-to-face communication and continuous
input from the business users
Cons
Difficulties to judge the efforts and the time
required for the large project in the SDLC
Required senior developers
Risk of Agile standalone (vs other
infrastructure projects)

18. Different levels of Business Analysis
Strategic
Analysis
Tactical
Analysis
Operational
Analysis
18
Enterprise Architecture
Enterprise Analysis
Market Research
Business Intelligence
Management Consulting
Business Value
Product Owner
IT Business Analysis
Decision Analysis and
Business Rules
User Experience
Change Management
Product Management
Process Analysis
Production Support

19. 19
Business Analyst skillset
Business
Knowledge
IT
Marketing
Logistics
Finance
HR
Technical
proficiency
Project management
Software Development experience
Agile Scrum and Waterfall methodologies
Strong understanding of Software
Development Life Cycle (SDLC)
Unified Modeling Language (UML)
Business Process Modeling (BPM)
Active listening
Questioning
Problem solving
Negotiating
Communicating
Behavioural
characteristics

20. 03
Role of the BA in project lifecycle

21. Role of a BA in project lifecycle
1. Project initiation
2. Business analysis
3. Use modelling techniques
4. Validate deliverables
5. Development follow up & testing
21

22. 3.1
Induction

23. Project initiation
23
• A clear and finalised project scope will form the basis of business analysis
Define the project scope
• Identify the departments & processes that may be impacted by the project
Define the impact of the project on the organisation
• Are the basis of business/user requirements
• Understand the business challenges
• Identify stakeholders
Assess the business needs

24. Elicit requirements
24
Key skills:
Active listening
Questioning
Problem solving
Negotiating
Communicating
Elicitation
Drawing out
necessary
information from
stakeholders
Documenting
clear
requirements
Enabling the
solution
development and
implementation
Elicitation
session
A clear and
simple objective
must be met
Allow adequate
time
Only involve
relevant
stakeholders
Elicitation
techniques
Workshops
Interviews,
Brainstorming

25. Documenting and prioritizing requirements
25
The MoSCoW methodolgy to prioritizing requirements
• Identify essential requirement
• Enables to manage expectations
Validate documented
requirements =>
Key skills:
Presentation skills,
documentation skills,
technical background
A baseline for stakeholders to officially
confirm their needs
A basis for further analysis of the required
solution
Input for the IT team and other contributors
Basis for further documentation (Ex: user
manuals, training)

26. 26
The MoSCoW method
Should Have
Could have
Would be nice to have
Must have
• Identify essential requirement
• Enables to manage expectations

27. 27
Good requirement are…
Unambiguous
Precise
Consistent
Correct
Measurable
Traceable
Testable

28. Identify and involve contributors and stakeholders
•Business Systems Analyst, Systems Analyst, Process Analyst, Consultant, Product Owner, etc.Business Analyst
•Segmented by market, geography, industry, etc.Customer
•Broken out by organizational unit, job role, etc.Domain SME
•Project Librarian, Change Manager, Configuration Manager, Solution Architect, Developer,
Information Architect, Usability Analyst, Trainer, Organizational Change Consultant, etc.Implementation SME (IT Side)
•Help Desk, Network Technicians, Release ManagerOperational Support
•Scrum Master, Team LeaderProject Manager
•Providers, Consultants, etc.Supplier
•Quality Assurance AnalystTester
•Managers, Executives, Product Managers, Process Owners, KBRSponsor
28

29. 3.2
Production

30. Describe business requirements
30
Different types of analysis for
different types of requirements
Functional
Non-Functional
Technical
requirements

31. Analyse business requirements - Alternatives
31
•What is the current situation in my organization ?
Description of the as-is situation
•What must be the future situation for my organization?
Description of the to-be situation
•analysis of the steps needed to move from the as-is situation to the to-be situation
Fit/gap analysis
•A contraint is any limitation or restriction on possible solutions. Constraints can be business or technical-related.
•An assumption is a factor that is believed to be true with no actual proof.
•A risk is an uncertain event that may or may not occur and which may have a negative impact on the
project/solution if the risk occurs.
Constraints/Assumptions & Risks

32. Use modelling techniques – UML Use case & activity diagrams
32

33. BPMN : Business process modelling
33

34. 3.3
Development follow-up and testing

35. Prepare tests
Test plan
assumptions
schedules
roles and
responsibilities
scopetools
environment
deliverables
35
• Test scenarios: the
projected course of
action (What & How
to test?)
• Test cases: derived
from the scenarios
(why testing?)

36. Test environment
36
• The test environment is composed of the different systems and interactions, based on a
software and a set of data that simulate the existing system
• Is customer specific
• To roll out a test environment the DTAP method can be followed. It consists in a 4 steps
approach :
Development
Testing
Acceptance
Production

37. Business testing – Types of tests
37
Unit testing
(or FUT) :
• smallest part of the application that can be tested, like e.g. functions, classes,
procedures, interfaces
Integration
testing :
• tests on the interfaces, interactions of components that make up the system
System
testing :
• verify globally that the system delivers specification and purpose (can be
functional or non functional)
User
acceptance
• tests (or Customer acceptance tests) : testing by the End User of the application
on a real set of data (after correction of defects)

38. Execute tests & Logging and follow-up defects
Description
of the Issue
by the
Business &
User
Logging
Defect in
Test
Management
Tool
Follow-up &
Tracking Test
Manager
38
Logging of
test results
Comparison
of expected
vs actual
results
Reporting
incidents/def
ects
Retesting
fixed bugs

39. 3.4
Handover of deliverables

40. Validation of deliverables
• Validation
Ensure completeness of documents
Ensure correctness of documents
Obtain agreement from stakeholders
• Acceptance
Obtain agreement from stakeholders to move to next phase
40

41. Planning business transition activities
41
 Development & Planning of training activities
 Creation/update of standard operating procedures
 Completion or update of work instructions
 Coordination of the planned release with other on-going or upcoming activities
 Assurance that the business is ready to accept the changes
 Coordination of any interruption of the business
 Prepare pilot (in production)

42. Preparation for go-live, project handover and aftercare
42
• Change is moving from current state to future desired state
• BA role is to facilitate & involve all the stakeholders within the project
• Communicating decisions & the updated processes/flow from previous phases projects
• Adapt communication focus on internal and external parties (e.g: marketing communication /
manage resistance )
• transfer knowledge to target right audience & communicate clearly training objectives
Manage
organizational
changes
Prepare
internal and
external
communication
Organize
training for
operational
teams

43. Activity 1
What a mess!

45. Your feedback
45
SATISFACTION SURVEY
https://bit.ly/2TzhIfz