Author: Panna Visani (2015)

Adept Change Management

Presentation for

A leading provider of Payment Services in the UK (Confidential)

The QuestionWe would like you to give a presentation on the aspects detailed below. In this presentation you should include any assumptions made and alternatives considered.

The assessment will be of the approach taken rather than the factual correctness of the business understanding.

An economic region currently has a three day clearing and settlement payment management system. This processes up to 50 million payment transactions a day. Their wish is to move to a real time clearing approach.

Abc Ltd has a solution which is thought to meet most of the requirements.

OverviewA solution by Abc Ltd may fit the requirements.How do we understand & analyse the requirements ?How do we make sure that requirements are not missed ?Context diagram – present a high Level view of the real-time

systemsKey differences to a Non-real-time system How to validate requirements working with Solutions

ArchitectureRisks & Considerations of the approach taken

The Approach - Overview

Strategic Analysis

Business Analysis/Benefit case

Systems Analysis/Landscape

Requirements Engineering

Solution Developme

nt

Manage Change

Context Overview

(Brief)

•KEY SENIOR STAKEHOLDERS

•PESTLE

•SWOT

•Interviews, Surveys, Research Etc

P.I.D.

Business Case (ROI)

•Quantitative Benefits

•Qualitative Benefits

•Opportunity costs

•Risks / Issues

•Existing PAIN points

•AGREE Scope of Change

HL Requirements, HL Solution Design. Validate Fit (GAPS)

Check Business Case

• HL Requirement ELICITATION•FUNCTIONAL, NF,• General Project, Legal, Compliance, etc)•Technical•Key STAKEHOLDERS - Baseline Requirements.•Confirm Feasibility in terms of TECHNICAL (HL

Solution); FINANCIAL (Business Case) & •GAP Analysis

HL to GOOD detailed

Requirements

•Specific, Clear, Complete, Consistent, Testable, Relevant, Owned, Achievable, Prioritised

•Interviews, Workshops, Documents, Data Modelling, Use-case modelling, Systems Modelling.

Iterative Agile

Dev, Test, Deliver & Ratified with User Involvement

•Team responsibility – includes Users, Dev, Analyst, Designers, Architects.

•Working proto-types/ models.

•Design. Dev, Test & Deliver progressively to a set number of drops

Business Architect

SolutionArchitect

Business Analyst

(Product Owner)

Dev &Test teams

The Approach – Hybrid Methodology

Context Overview

(Brief)

•KEY SENIOR STAKEHOLDERS

•PESTLE

•SWOT

•Interviews, Surveys, Research Etc

P.I.D.

Business Case (ROI)

•Quantitative Benefits

•Qualitative Benefits

•Opportunity costs

•Risks / Issues

•Existing PAIN points

•AGREE Scope of Change

HL Requirements, HL Solution Design. Validate Fit (GAPS)

Check Business Case

• HL Requirement ELICITATION•FUNCTIONAL, NF,• General Project, Legal, Compliance, etc)•Technical•Key STAKEHOLDERS - Baseline Requirements.•Confirm Feasibility in terms of TECHNICAL (HL

Solution); FINANCIAL (Business Case) & •GAP Analysis

HL to GOOD detailed

Requirements

•Specific, Clear, Complete, Consistent, Testable, Relevant, Owned, Achievable, Prioritised

•Interviews, Workshops, Documents, Data Modelling, Use-case modelling, Systems Modelling.

Iterative Agile

Dev, Test, Deliver & Ratified with User Involvement

•Team responsibility – includes Users, Dev, Analyst, Designers, Architects.

•Working proto-types/ models.

•Design. Dev, Test & Deliver progressively to a set number of drops

Waterfall

SPR

INT

SPR

INT

SPR

INT

SPR

INT

Assumptions: Context – Strategic AnalysisThe Payments Eco-system in question comprises of the following entities:

A Central Bank

Commercial Banks

A Financial Regulator

Automated Clearing House (ACH)

There is growth in E-Commerce and improvements in Logistics allowing retailers to offer same day & Next day delivery.

The regulator is seeking payment services that offer greater end-user protection and with a faster cycle, to accelerate the growth of this economy. Also, by modernising the payment system, it seeks to attract foreign investments, which in turn drives economic growth.

The government wishes to instil a formal economy to ensure less cash is used, and thereby benefit from related taxes.

Assumptions: SWOT AnalysisStrengths

Has a Cheque Clearing Payments System (?)

Has an electronic Payments System (RTGS) controlled by a Central Bank ?

Has regulatory bodies & policies

Has ATMs ?

Weaknesses Clearing system takes 3 days

RTGS is only for Low Volume, High Value inter-bank settlement

Opportunities - To move to Real Time Person-to-Person Payments

Real Time Business to Business Payments

Real Time Credit-Card settlement processing

Improve Access to Alternative Payment Service Providers, increase competition & reduce costs

Threats

Expected growth of E-Commerce, Credit Card payments & M-Commerce (use of Smart Phones)

Disruptive Technologies

Consumer behaviour & expectations

WE WILL ASSUME THAT A BUSINESS CASE HAS BEEN BUILT, AND CONFIRMS THE FOLLOWING

The CENTRAL BANK & LEGISLATION ARE DRIVING THE NEED FOR THIS CHANGE

The Objective is for a Real Time Payments system to provide the following:

Assumptions: Business Case

• Payers experience is as easy as with CashSpeed, Convenience

• Payment accessible anywhere, without need for Brank or ATMUbiquity

• Privacy & integrity of individual must be guaranteedSafety

A Real Time Payments Model:

Remitting CustomerBeneficiary Customer

SENDING BANK RECEIVING BANK

CENTRALISED INFRASTRUCTURE(FASTER PAYMENTS SYSTEM)

CENTRAL BANK

1

23

5 4

6

7 8

SECONDS

MESSAGINGAT INDIVIDUAL

TRANSACTION LEVEL

A Traditional Clearing (Non-RT) Payments Model:Remitting Customer

Beneficiary Customer

SENDING BANK RECEIVING BANK

CENTRAL BANK (DNS)

1

2

3

AUTOMATED CLEARING HOUSE 4 ONLY

NET BALANCE IS SETTLED BETWEEN

BANKS

End Of Day BATCHED

Transactions

DAYS

5

Key Differences to Non RT: Handling of transactions in a Non-batched manner.

Clearing is still a Separate Step to Authorisation & Settlement. But, with Real-time payments, there is NO DELAY before a Payee’s Bank has access to the funds and can make them available to the Payee.

Faster Payments through a Real-Time Payments Service separates the Settlement stage clearly from the Clearing, since in most cases the ‘Payer’ and ‘Payee’ are not concerned with when the Banks settle their own accounts.

TIME (DAYS)

TIME (SECONDS) ………………END OF DAY

AUTH

AUTH

CLEARED

CLEARING

SETTLE

SETTLE

Ensure GOOD requirements –by meeting these criteria:

An Owner – Ensure the requirement is justifiable, and traceable

A Priority (MoSCoW) – Ensure the requirement is relevant, and necessary (has value)

Is Consistent (internally & with other requirements)

Is Testable – What are the ‘Success Criteria’ ? (SMART)

Is Clear, Unambiguous and not generalised (Specific).

Is Complete !

The High Level Requirements need to be sufficiently detailed to allow Solutions Architect to generate a High Level design. It should also be possible to walk through this document with appropriate stakeholders to validate these requirements.

High Level Requirements – User Stories

For Each High Level Requirement...apply techniques

Who

What

WhyWhen

Where

FUNCTIONAL

NON-FUNCTIONAL

TECHNICAL

GENERAL

And Categorise, to ensure completeness

Gov

Central Bank

End User

Regulators

Settlement

Payment Service

Provider

Merchant Banks

Banks

Building Soc.

Consumer Groups

Technology Providers

E.g. Who?ENSURE REQUIREMENTS ARE COMPLETE BY ENGAGING THE RELEVANT STAKEHODLERS

Identify key Stakeholders, Actors, Users, Internal, External

With Solutions Architects, develop a documented & logical model of the proposed solution based on the high level requirements.

BA to act as the Product Owner – Agile – as proxy for the stakeholder group.

Reference HL requirements as ‘Product Back-log’

Prepare Plan of time-boxed Sprints for groups of related functionality to be delivered & reviewed with the assigned user groups.

Reference MoSCoW priorities of HL requirements to optimise effort/time

During Sprint Planning - As detailed requirements are elicited, Validate High Level requirements, and split EPICs further as required.

Detailed stories should be elicited within each sprint with User review

Validate Requirements – User engagement

Key elements

- Requirements Catalogue (Product Backlog)

- ‘Modelling’ techniques – run work-shops to identify gaps.

- Use-cases and data-models

- User Stories, Epics

- Prototyping; review of functionality at the end of each sprint.

- Adjust requirements with feedback

- Build the actual solution incrementally, getting it verified along the way.

Validate Requirements – User engagement

Not pure Agile. Hybrid approach has some loss of flexibility by working to fixed deadlines, cost forecasting and risk assessments.

The best of waterfall - retains the clarity of scope, and dependency tracking.

May allow for effective delivery of Software in Agile fashion, while allowing product owners and hardware development to follow a traditional approach.

Requires tight collaboration – it ensures teams can define requirements, and still adapt to changing requirements, allowing feedback from both the waterfall & agile sides of the team, allowing for continuous delivery.

Best suited for re-use of software – similar products, and quick turn-around.

Risk of losing control of the Product Backlog; mitigate by using software with ‘version release planning’ features.

Risks, Considerations for Water-fall/Agile hybrid