Business

Analysis

Dr Rehan Syed

Topic 3 Business Analysis Planning

QUT-School of Information Systems 1

 Stakeholder Expectations

Project Context and Scope

Lecture
Overview Data Collection Techniques

Data Collection Plan

QUT-School of Information Systems 2

 Identify Stakeholder Expectations
Stakeholder Type of Information
Sponsor Regulatory requirements
Business requirements
Assumptions
Constraints
Risks
End Users Functional requirements
System requirements
Business rules
Implementation Team All
Executives Business requirements
Impacts
Risks
Assumptions
Constraints
External organisations Interface changes
Regulatory requirements

QUT-School of Information Systems 3

 Identify Stakeholder Expectations: Techniques
Customers, suppliers, regulators,
and other external groups

Sponsors, executives, domain

SMEs, and others who
interaction with the affected
group

End User, and others whose

work changes when the solution
Visualise/
Visualise/ is delivered
Keep Maintain
Maintain
Involve
theAll Focus
Focus
Momentum
Stakeholders
KeepDisplay
Involve
theAll
Display
Avoid
Invite Ideas
Momentum
Stakeholders
Ideas
Judgement
Ideas
Avoid
Invite
Judgement
Ideas

Project Team and others directly

involved with creating the
solution

Brainstorming Stakeholder Onion Diagram

QUT-School of Information Systems 4
Identify Stakeholder Expectations: Techniques
Towards:
• Risk taking
• Business goals, objectives and
solution approach
Attitudes
• Business Analysis (and analysts!)
Geographic
• Collaboration Factors
• Sponsor
• Team Members

• Designation
Power/Authority • Decision Making Consider Communicatio External
Culture
• Leadership n Frequency & Factors
Formality Factors

Influence • Strategic Expectations

Type of
• Buy-In factors Project

QUT-School of Information Systems 5

 Identify Stakeholder Expectations: Deliverables

• List of required roles

• Names and titles of stakeholders
Stakeholder • Category of stakeholder
List: Roles and • Location of stakeholders
Responsibilitie • Special needs
• Number of individuals in this stakeholder role
s • Description of stakeholder influence and interest
• Definition of stakeholder authority levels

QUT-School of Information Systems 6

 Identify Stakeholder Expectations: Deliverables

From Pre-read Scenario.

QUT-School of Information Systems 7
 Step 1: Identify Stakeholder Expectations: Outcomes
Project Name: XYZ Project Date: 25 May 2016
Project Manager: John Jones Project Sponsor : Jane Smith
Stakeholder name and Bill Brown, Senior Finance Officer
contact: (5th floor, ext. 3514)

Stakeholder Organisation or Unit:

Finance
Provides to the Project:
Initial funding amounts per month
Will approve/reject change requests that require increased budgets
Project provides to this Stakeholder:
Timeline for expenses Cost/benefit Analysis
Impact of the Project on this Stakeholder:
If the project exceeds budget, shortfalls will be sought from other
areas
Hot Issues for this Stakeholder:
Solid estimates

Stakeholder Profile (Example) Stakeholder Power-Interest Matrix

QUT-School of Information Systems 8
 Step 2: Develop Solution Scope

Project Size

Project
Constraints
Complexity

Solution
Scope

Stakeholder
Risks
Risks
Complexity
Complexity

Solution Scope Model

http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/2366/Solution-Scope-An-Insight.aspx
QUT-School of Information Systems 9
 Step 3: Determine Project Approach
Plan-driven Approach Change-driven Approach
Plan Analyse Implement Test Deploy Analyse
Implement

Plan
Test
time Deploy

• Minimises up-front uncertainty by ensuring the
solution is fully defined before implementation begins
• Maximises control and minimises risk
• Requirements can be determined in advance
• Used when managing stakeholder interactions may
be challenging
• Requirements approval sits with identified
stakeholders e.g. sponsor
• Waterfall methods and BPM are consistent with this
approach
• PRINCE 2
• SDLC
• PMI QUT-School of Information Systems
• Rapidly delivers business value in short iterations
• Higher degree of uncertainty around overall delivery of the
solution
• Used for exploratory approaches
• Used when incremental development is appropriate
• Approval rests with an individual who is closely involved with the
development process
• Agile Methods and continuous improvement methods are
consistent with the Change-driven approach
• SCRUM
• DSDM
• Agile PM
10
 Step 3: Determine Project Approach
Plan vs Change Driven
Plan Driven Change Driven
Timing • At start of project or • Throughout project
• Early project stage • Based on (re)priority
Formality of • High formality • Mainly team interaction
Deliverables • Sign-off in entirety • Documentation follows
Detail in • Various levels • Detail as required
Deliverables • High level leads to lower
levels
Reqs Prioritisation • Formal agreement • Redone often
• Emphasis on effectiveness
Reqs Change Mgt • Only critical changes • Assumes reqs always
• Register/log all changes incomplete
S/H Comms • Formal methods • Informal methods
• Less Frequent • More frequent

QUT-School of Information Systems 11

 Step 4: Determine Communication Approach

• Identify the optimal methods for requirement gathering and

documentation.
• Different Forms
– Formal documentation
– Presentation
– Models

QUT-School of Information Systems 12

 Step 5: Plan Business Analysis Work
• Choose an appropriate BA approach This includes:
– which stakeholders need to be: • Identifying business analysis deliverables
• consulted about the approach • Determining the scope of work (see slide #9)
• involved in the decision • Determining what activities the BA will
• informed of the approach perform
– the rationale for the choice • Developing estimates of the effort involved:
• This is the planning phase for: time, cost, resources
– How and when tasks will be
performed
– What techniques will be used
– What deliverables to be produced

QUT-School of Information Systems 13

 Step 5: Plan Business Analysis Work
BA Work Breakdown Structure BA Risk Analysis
• Requirements gathering-related risk
– Stakeholders not knowing what they want
– BAs lack of understanding the business and/or skill
– Stakeholders unwilling to contribute time
– Stakeholders defining solutions, not requirements
• Solution-related risk
– Doesn’t meet the business need
– Stakeholder non-acceptance
– Too expensive
– Too complex
– Technology outdated by the time solution is released

• Performance Reporting
• Formal or informal
• Written or verbal updates on BA performance
• Preventative and Corrective Action
• Once performance issues have been identified, a (lead)
BA should address the issues with the appropriate
stakeholders
QUT-School of Information Systems 14
 Case Study: QLD Health Payroll
• Business Need: upgrade aging system
• Solution: In-house + vendor implementation
• 2 years later: no validated requirements
• Solution 2: IBM $6.19m, 7 month contract
– 47 change requests in first 2 months
– Go live 2010 (5th attempt), $101m
• 35,000 payroll mistakes
• Industrial strikes
• Resignation of the Minister of health
– Ultimate cost: $1.25 billion (20,200% blowout)
QUT-School of Information Systems 15
 Requirements Prioritisation Plan
• Relevant Stakeholders
must collaborate on
how requirements
should be prioritised
– If 90% classed ‘high
priority’ -> no priority
Prioritisation
– High expectations +
short timelines +
limited resources ->
essential functionality
• Business Value
– Relative value to the organisation
– Common when enhancing existing solutions
• Business or Technical Risk
– Risk is assessed and priorities assigned
– High risk first? So if it fails, it fails early …
– Low risk first? Ensures early wins …
• Implementation Difficulty
– Easiest to implement first or hardest?
Basis for
• Likelihood of Success
– Quick successes first = early wins for the team
– Gains support for the project
• Regulation or Policy Compliance
– Requirements implemented based on external compliance
rather than stakeholder interests
• Relationship to other Requirements
– Low order requirements supports a high value requirement
• Urgency
QUT-School of Information Systems 16
 Output: Business Analysis Plan

• Business Analysis Plan should include:

• Description of the scope of work
• WBS
• Activity List
• Change management process (for the
plans)
• The level of detail should be in
response to the key stakeholders’
needs

QUT-School of Information Systems 17

 Business Analysis Plan Approval

• Ensure approving stakeholders

understand and accept the BA Plan.
• Approval may also be needed for
requirements allocation, problem
resolutions, etc.
• Records should be kept
• When, who, decision, reasons,
other parties

QUT-School of Information Systems 18

 •Requirement Elicitation
• Recommended Reading:
• Business Analysis for Practitioners:
Chapter 4, Sections 4.1 to 4.8
Next Topic • Optional Reading:
• BABOK Chapter 4. Section 4.1 to 4.4
• Paul, Cable & Yeates. Chapter 5
• Prepare for Tutorial Workshop

QUT-School of Information Systems 19

Thank you 
QUT-School of Information Systems 20