Business Improvement Definition (25%) Flashcards

1
Q

Interview: applicability

A
  • Elicit facts and information about the business situation and their role in it.
  • Gain overall impressions of issues and background from management
  • Confidentiality
  • Drilling down into detail
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Interview: Advantages/Disadvantages

A

Advantages:
1. Builds relationship with stakeholder
2. Confidential
3. Understand stakeholder perspective & business overview

Disadvantages:

Only one viewpoint
Take lots of time

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Observation: Applicability

A

Applicability

  • To identify ‘Unknown unknowns’
  • To identify non-functional requirements
  • To identify operational, environmental & technical constraints
  • To identify workflow sequence, peaks, troughs
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Observation: Advantages/Disadvantages

A

Advantages:
1. We can get a good understanding of the processes, problems, politics etc
2. Helps devise workable, acceptable solutions
Disadvantages:
1. Can feel like ‘Big Brother’ – unsettles the observed
2. Your presence may impact the process

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Workshops: Applicability

A

Provide an excellent collaborative forum in which issues can be discussed, conflicts resolved and requirements elicited from several perspectives at once
Useful at differing stages throughout the business change lifecycle to identify problems, elicit/negotiate requirements, and to investigate options

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Workshops: Advantages/Disadvantages

A

Advantages:
1. Fast (?)
2. Stakeholders involved and committed - feel ownership
3. Developers and stakeholders understand each other
4. Simple method of resolving issues/options
5. More creative solutions are produced

Disadvantages:
1. Hard to schedule
2. Group dynamics need careful managing
3. Hidden agendas

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Scenarios: Applicability

A

Applicability

  • To clarify/explore detail behind functional requirements (use cases)
  • Provides a basis for ‘alternative’ flow analysis
  • Provides a basis for user acceptance testing
  • Provides a basis for evaluation of COTS

deeper dive into process mapping

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Scenarios: Advantages/Disadvantages

A

Advantages
- Aids visualisation and discussion of real life situations
- Can be used to build test scenarios
Disadvantages
- Can become complex, especially where many alternative paths

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Surveys: Applicability

A

Applicability

  • To get quantification/scale of a problem or issue
  • Need to get many people’s views, possibly geographically dispersed
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Surveys: Advantages/Disadvantages

A

Advantages

  • Easy to get results from large groups over geographically disperse regions
  • Can be anonymous
  • Quantitative statistics can be used in business case
  • Can uncover hidden problems/requirements

Disadvantages

  • Low response rate
  • Ineffective unless carefully designed and analysed
  • Not suitable for situations where much detail is required
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Document Analysis: Applicability

A
  • Used to identify document-based processes and how they interact with people, the organisation, information and technology
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Document Analysis: Advantages/Disadvantages

A

Advantages
1. Can yield good information on Organisation/Process/System
2. Can identify NFR’s (security etc)
Disadvantages
1. Don’t get differing viewpoints
2. Dry & Tedious
3. Reliant on document existing and having access (not confidential)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Root cause analysis tools

A

Fishbone / Mindmap / Rich Picture

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Fishbone diagrams

A
  • A problem and its causes are represented as the skeleton of a fish
  • Head = the problem
  • Spines = the possible the causes
  • Similar to mind map but its purpose is strictly diagnostic rather than recording.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Mind maps

A

Business system or problem in the centre

First level branches (from central point) - main issues i.e. equipment

Second level branches - more detail i.e. photocopier broken

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Rich Picture

A

An overview of the entire business situation with informal notation

Includes: organisational/human/
cultural aspects/process/ information flows of a business system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Stakeholder Wheel

A

Internal: Employees/Managers/Owners

External: Customers/Suppliers/Regulators/Competitors/Partners (e.g. resellers/outsourcers)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Stakeholder Wheel use?

A

To identify stakeholders

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Techniques to Analyse/Manage Stakeholders

A

Power/Interest Grid
CATWOE
RACI Chart

20
Q

Power/Interest Grid

A

Constant active management (high power and interest)

Keep satisfied (high power, med interest)

Watch (high power, low interest - could change)

Keep onside (med power and no-high interest)

Keep informed (low power, high interest)

Ignore (low power, low interest)

21
Q

Why is CATWOE useful?

A

Identifying different perspectives

22
Q

CATWOE

A

Customer: who benefits/recipient of transformation
Actors: who carries out transformation
Transformation: core activity/process of biz system
World view: A belief statement - why does the organisation/biz system exist
Owner: who controls the biz system (& can change/even close)
Environment: PESTLE

23
Q

RACI

A

lists the main tasks or deliverables down the side & stakeholders along the top

R - responsible for creating/developing the deliverable/performing the task.

A - who is answerable for the quality of the deliverable/task.

C - provides information relevant to the deliverable/task.

I - are informed about a deliverable/task, though they may not have contributed directly to them.

24
Q

Gap Analysis

A

Comparing the ideal system (e.g. from Consensus BAM) with the existing systems

As is vs To be

Can also be used to compare requirements and COTS product and on individual skillsets

25
Identifying Options
(Problem definition & investigation) 1. Identify options (can be radical and 'do nothing' - should be biz and technical) 2. Short list options 3. Develop (cost benefit / impact risk) 5. Produce business case
26
Why should we consider feasibility of options?
Helps to eliminate unsuitable options
27
3 types of feasibility to consider
Business e.g. physical infrastructure / cultural fit / process compatibility Technical e.g. security / availability Financial e.g. Funds available/borrowing available
28
Business Case contents
Introduction and management summary Description of current situation Options considered Analysis of costs and benefits Risk assessment Impact assessment Conclusions and recommendations Appendices
29
Describe the contents of the 'Background and objectives' section of a business case
Intro - sets the scene /why is the biz case being presented Management Summary - distil the whole BC. Includes: what was the study about/options (ad and disad)/recommendation Current situations - explained with the problems and opp identified
30
Options section - Business Case
Summarises the options considered and explains why some should be rejected.
31
Categories of costs and benefits
Tangible costs: e/g/ project staff costs/equipment/training Intangible costs: Recruitment/loss of productivity Tangible benefits: staff saving/reduced effort/faster customer response Intangible benefits: increased job satisfaction/customer satisfaction Can both be Short and long term
32
Impact vs Risk
Impact - will happen Risk - might happen
33
Impact Assessment
Impact on the organisation needs to be explored for each option e.g. Org structure (reorganise departments) / interdepartmental relations / supplier relations / promotion criteria
34
Risk Assessment
For each risk: 1. Description 2. Impact assessment: what is the harm if risk occurred (quantitative preferred) 3. Probability: precise measures or low/med/high 4. Countermeasures 5. Ownership (for countermeasures)
35
Investment Appraisal Techniques
Payback Discounted cash flow Internal rate of return
36
Payback/break even
1. Calculate cash flow for the year (savings less costs) 2. Add CF for the year to cumulative cash flow 3. Break even when CCF is positive
37
Discounted cash flow and net present value
Takes into account the time value of money Apply discount factor to net cash flow to get the NPV
38
Internal rate of return
The internal rate of return technique turns the DCF/NPV calculations on their head and asks, 'What discount rate would we need to use to get a net present value of zero after [x] year?' The result - which can only be obtained by trial and error - simulates the return on investment that the project has generated. IRR is used to compare projects when making investment appraisal decisions. Projects with a higher IRR are preferable to those with a lower IRR. However, for an investment to be approved, the IRR should exceed the organisation's cost of capital or, if it using its savings, the interest rate payable by the bank.
39
Programme vs Project
Programme A programme is a group of projects which require coordination in order to bring about a business change Project This is one aspect of a wider business change programme. A discrete piece of work
40
Requirements Engineering Framework
- Requirements Elicitation - Requirements Analysis - Requirements Validation - Requirements Documentation - Requirements Management Elicitation - Information about requirements Analysis - Improves the quality: generates gaps and questions and determines if more elicitation needs to take place. Analysis produces defined requirements Validation - Are we willing to accept these requirements/benchmark them? Any issues identified during validation pushes them back into analysis Management - change control process
41
General requirement
A type of requirement that documents high-level business constraints and policies Business requirement
42
Technical requirement
A type of requirement that documents high-level technical constraints and policies Business requirement
43
Functional requirement
WHAT the solution should do
44
Non-Functional requirement
HOW it should do it i.e. performance/usability etc
45
Use Case Diagrams
- Functional model - summarise functional requirement Rectangle - System boundary (part/whole) Stick figures - System Actors (/user roles) interacting with the system (their goals) Circles with verb noun - system functionality Association - shows how the interaction between actors and the system