Asset finance systems projects guide 101

This article consolidates three earlier articles on system
evaluation and selection, initiation, and implementation for the
asset finance and leasing industry
ASSET FINANCE SYSTEMS EVALUATION ,
INITIATION AND IMPLEMENTATION"101"
System evaluation, selection, initiation and
implementation for the asset finance and
leasing industry
Richmond Consulting Group
richmondgrp.com

richmondgrp.com
SECTION CONTENTS
Systems evaluation and selection 3
Project initiation 10
Data migration and cutover 16
Testing 21
Business change and Target Operating Model 27
ASSET FINANCE SYSTEMS EVALUATION , INITIATION AND IMPLEMENTATION"101"
2

SYSTEMS EVALUATION AND SELECTION
ASSET FINANCE SYSTEMS SELECTION “101”
richmondgrp.com
How do you know when it is time to change or upgrade your
current systems?
When you do upgrade, how should you go about it?
What are the success factors of a robust system selection
process?
How should we close gaps?
In this section, we look at 10 reasons to upgrade, give some pointers on how to
select a new system and share our experience of what success looks like.
3

10 REASONS TO UPGRADE YOUR SYSTEM
richmondgrp.com
Yes / No10 REASONS
Outdated technology
Your technology and software systems have not kept pace with current Fintech capabilities or
with your technology strategy

Inflexibility
Your systems do not offer the flexibility to accommodate new financial products, markets or
sales channels. If you do want change you need to ask your software vendor for code changes
instead of being able to configure straightforward changes with in-house staff

Poor customer experience
Partners (customers, dealers, brokers, manufacturers) are not being provided with the seamless
experience they have come to expect: a great online journey, flexible agreements and products,
and speed

Servitisation
Your current system is an end-to-end ERP with components and modules better performed by
specialist software and you want to move to a servitisation landscape

Compliance standards
Your current platform is failing the security, reliability or regulatory compliance standards that
you need

Cannot scale
Your systems cannot scale to meet your business growth plans

Too many manual processes
Current processes and workflows are too manual, and this is preventing you moving the dials on
your productivity and headcount ratios

Lack of analytics
Your systems are not providing sufficient, relevant data analytics and service-level metrics 
Need better integration capabilities
Your systems are not integrated sufficiently enough to provide frictionless processing

Baked-in custom coding
Current systems have been heavily customised, making upgrades expensive projects in their
own right &/or systems costs are escalating
10
1
2
3
4
5
6
7
8
9
4

THE RFP ("REQUEST FOR PROPOSAL ") PROCESS
The request for proposal (RFP) process is there to provide the best chance of selecting a software system that will be
a good fit for your business by:
 Allowing suppliers to understand the business requirements and propose a solution
 Allowing multiple proposals to be gathered, evaluated and rated on their ability to meet your requirements
Lessons learned
 Be clear about what success looks like & do not treat the new system as a cure for all ex-
isting business challenges
 Resist the temptation for requirements to replicate the legacy system
 Accept that requirements may be met in a different way than with the existing provider
 Hold detailed demos at the supplier premises to learn more than just how their product works
 Ensure suppliers demonstrate the same version and environment you are expecting to use
 If possible give suppliers real world scenarios so that they can demonstrate proof of concept
 Initial RFIs can be sent to a list of identified suppliers, both established and challengers. Detailed RFPs
should be kept to a manageable number (3 is often realistic)
 Be clear about where the gaps are and how you will meet them
 Assess the relative costs of total ownership over the expected system life, not just the headline costs
richmondgrp.com
€
Capture requirements
Plan the work Mobilise teams
Hold facilitated workshops for each
functional area
Document requirements
and decide scoring &
weighting schemes
Prepare RFI,
RFP docu-
ments
Obtain document sign offs
Send Requests for
Information (RFIs)
Research suppliers
Send RFIs to selected
suppliers
Collate replies, update RFP
+
1st round supplier
elimination
Send Requests for Proposals
& evaluate suppliers
Send RFPs to short-
listed suppliers
Collate replies,
record scores
Supplier demos to
validate RFP responses
+ update scores
Reference site
visits
Hold Gap closing
sessions
Final costs w/customisations +
Assess Total Cost of Owner-
ship of system over its life
Contract negotiations and supplier selected
5

Lessons learned
 Agree what success looks like
Take the time to decide what success looks like and let everyone know. Being clear about the
benefits you expect versus the costs you will need to incur helps keep everyone (staff,
software companies and project teams) focussed on why the change is being made and what you are
looking for from your replacement systems
 Facilitated collaborative workshops led by a neutral facilitator improves the quality of the RFP
 Stakeholder support is key
 Stakeholders to own the requirements. Avoid having project team members write requirements on
behalf of the project, as well as construct the RFP, and score the suppliers
 Clear requirements. Be clear in articulating your needs or risk suppliers inadvertently interpreting
needs that validates the use of their product
 There is no panacea. Avoid expecting the new system to be a cure for all existing business challenges
richmondgrp.com
RFP SUCCESS FACTORS - A CLOSER LOOK
Supplier
partnership
Clear RFP
structure and
Support of stakeholders and
management
Good quality business requirements
 Look to create a partnership with the
software vendor
 Create a mutual vested interest in success
 Value the supplier as a resource with
experience of the industry and the
knowledge of what their software can do  Ensure the RFP is clear and
complete
 Ensure sponsorship and
management support for:
 Budget and schedule
approvals
 Finalising contracts
 Resolving disputes and
ensuring momentum
 Clear & completely defined
needs
 Consider facilitated
workshops led by a neutral
facilitator
 Stakeholders to own the
requirements
 Consider using collaborative
requirements gathering
Goals
To provide requirements that are complete, clear, and achievable
... so that software suppliers have understood your needs
... so that they can then validate that the desired solution and technology is available
... which will give the best chance of commencing a project that realises the desired benefits within the
expected budget and timescale
6

richmondgrp.com
ANATOMY OF AN RFP
EXAMPLE RFP CONTENTS
 Project overview and administrative information
 Problem statement/business case/issues/
opportunities
 RFP timeline & process
 Business requirements
 Functional “what” type questions
(Single needs statements (not long descriptions
containing multiple needs)
 Supplier qualifications / references
 Structure
 Support arrangements
 Stability, certifications, validations
 Non-functional requirements
 Reliability, security, performance
 Testing & training
 Documentation requirements
 Implementation support expectations
 Technology requirements
 Prices / total cost of ownership
 One-off costs
 Recurring costs
 Total cost of ownership over expected life of
system
 Contracts and licenses
 Timescales
 Contractual terms
 Deliverables
 Appendices
 Additional background information
 System landscape etc
Business requirements are used
to frame the RFP questions
7

richmondgrp.com
SUPPLIER RESPONSES AND SCORING - A CLOSER LOOK
Capture requirements + decide ranking, weighting & scoring schemes
Agree priorities
Rank each requirement according to priority e.g. using a 1 to 3 scale
range such as High/Medium/Low, with priority informed by factors such as:
 Need
(e.g. Essential/Opportunity/Market standard or Essential/Desirable/ Nice to have etc)
 Core/Non core
(useful if > 1 department or country is involved)
Agree weighting scheme - it is usually useful to weight:
 Each requirement within its logical category (function and sub
-function)
Key lesson learned
 Decide ranking, weighting and scoring schemes at the outset
Agree scoring scheme
Rather than a simple Yes/No score it is usually better to use a combined scoring and weighting scheme to
reflect closeness of fit and relative importance of each requirement. Scoring should be structured and
simple. Two examples:
1 2
 Weight by area e.g. 50% software functionality, 20%
technology,10% security etc
3
Agree requirements
4
Percentage of points
available for each
requirement from exceptional
(100%) to unacceptable (0%),
with percentages in between
Score supplier responses according to schemes agreed in advance
..with a score
assigned to
each
Example 1 Example 2
Scored supplier
responses
Site visit reports
8

richmondgrp.com
GAP CLOSING SESSIONS - A CLOSER LOOK
Lessons learned
 Gaps are inevitable between your requirements and the system capabilities that you will see during
the RFP process. If gaps are discovered during the implementation phase these can cause delays,
increase costs and at worst lead to project abandonment
 Validate software availability: software vendor capability ("we can do that") is not the same as available
functionality ("we have that")
 Processes might need to change
Accept that process requirements will be supported differently than in the legacy system. Your Target Operating
Model might need to change
 Try to avoid code changes
Closing gaps by commissioning and testing code enhancements can materially affect timelines, budget and the
total cost of ownership. Especially:
 Do not underestimate customisation costs. They include not only code enhancements but also unit, functional
and regression testing
 Beware the risk of creating so many bespoke enhancements that future version upgrades become difficult to
manage
 Approve all gap closing decisions
The project Steering Committee should authorise the gap closing decisions and estimated costs
Fit-gap analysis is critical for identifying how well the new system will fit,
or not fit, the organisation. The cost of meeting gaps are often the
source of cost overruns, and so rewards close attention.
 ***Involve the supplier, the stakeholders, and ideally have a
neutral facilitator***
 Challenge all gaps: re-challenge the requirement, look for
alternative ways of meeting the requirement, avoid customisations
 Document clearly the cost and benefit of meeting the gaps and how
they will be met
 If the number of gaps becomes too great, focus on whether a
Minimum Viable Product ("MVP") can be delivered on Day 1 with
temporary workarounds until a later code delivery
Facilitator
Stakeholders and SMEs
System supplier
Documentation landscape
High level requirements
document with updated,
scored supplier responses
High level
system
configuration
requirements
High level system
customisation
requirements
Site visit
reports
Gap closing documents
High level process
changes / Target
Operating Model
proposals
The gap closing sessions
Total costs of
ownership
assessments
Supplier
contract
9

PROJECT INITIATION
richmondgrp.com
You are about to start an asset finance systems implementation
project
What do you need to consider at the start of the project to give
yourself the best chance of success?
In this section Richmond Consulting Group looks at our top 10 tips to get
your implementation project off to a solid start
ASSET FINANCE SYSTEMS: PROJECT INITIATION “101”
10

Project initiation - our top 10 tips to get your project off to a solid start
richmondgrp.com
10 TIPS
Know what success looks like
Keep the reasons you are implementing your new system front and centre. Everyone on the
project - stakeholders, project teams, software vendor - should know what you are trying to
achieve. Know what success will look like. Obtain buy-in from the people involved and impacted

Engage an authoritative Sponsor(s) and supportive Steering Committee
Things will not always go to plan. Having strong sponsors and a supportive Steering Committee
will help clear roadblocks and see the project through to delivery

Use experienced people with asset finance and leasing domain expertise
Implementations rarely fail solely due to lack of software or technical expertise. Engage
competent project managers, analysts, leaders and staff with asset finance business experience 
Agree how the project will be managed
Work methodically. Select an appropriate methodology 
Agree the Project Initiation Document (PID)
Time doing this will be time well spent. Do not make this a “tick box” exercise 
Commit to delivering robust documentation
Well documented requirements, if executed properly, are a force multiplier that will aid mutual
understanding, and can form the basis for testing, training and user guides.

Clarify the link between business benefits you want and the functionality that
will deliver it
If this is not clear at the initiation stage, make a commitment to establish this early on during
project delivery phase

Avoid gold-plating the requirements
Agree the functionalities that represent the Minimum Viable Product (“MVP”) that you can live
with. Recognize that:
 Delivering MVP early is usually more valuable, less risky and simpler than over-reaching, and
then having to accept delays to deliver everything in one big bang. Use the 80:20 rule to move
functionality to future iterations/releases.
 Priorities can change, agility is expected
By the time go-live is imminent, a new initiative might arise that is more valuable than
delivering that last 20%

Plan for business change and changes to your Target Operating Model (TOM)
Engage the Change Management leaders early and work with stakeholders address the business
process changes that will result from the implementation

Partnership and collaboration
From the outset value your software suppliers and advisors as partners, ideally with a vested
mutual benefit in project success

1
2
3
4
5
6
7
8
9
10
11

richmondgrp.com
The Project Initiation Document - a formal baseline for the project
Lessons learned
 Business case and mandate for change
 Project objectives
 Project benefits
 Financial products in scope
 Financial product matrix
 Functional scope
 Business change management
 Data migration
 Assumptions
 Risks and issues management
 Quality assurance
 Testing and training
 Project change controls and management
 Communication plan
 Project reporting requirements
 Reviews and audit
Project management
Project plan and budget - high level
 Phasing and key tasks
 High level timeline
 High level milestones
 Budget
 Steering committee
 Project roles
 Project approach and methodology
Project governance
The Project Initiation Document (PID) deserves a lot of attention as it forms the contract, and common
understanding, between the project management team and the Steering Committee or Sponsor.
It answers these questions:
 Why are we undertaking the project?
Background, motivation and benefits
 What are we delivering?
In-scope items, success criteria, ideally using of illustrations and charts to show boundaries of delivery
(Minimum Viable Product MVP vs. full scope), and how changes will be handled
 Who is responsible?
Project structure: Project Manager, Steering Committee, Stakeholders, Supplier etc
 How will the project be delivered?
Methodology to use (agile, waterfall), communications, how QA / testing will be handled
 When will the project be delivered?
Milestone plan and main project phases
 What are the risks, issues and constraints?
The risks identified up front, and how they and future risks will be managed
 What is the financial impact?
Cost estimates and budget constraints and their review frequency. Cost vs. benefit over life of system
TYPICAL PID CONTENTS (SUMMARY)
Project description Scope
 A well thought out PID provides a project baseline & roadmap to reference throughout the project.
 Engage, authoritative stakeholders and a supportive Steering committee to clear roadblocks.
 Unforeseen risks can derail projects. Get the risks out in the open at the outset
 Decide how to deliver the project. Select a methodology that will work for you
 Set up good change controls at the outset
 Use the right people for the project and address resource shortfalls early
 Plan for cross functional teams comprising software vendor staff + Subject Matter Experts + Project facilitators
 There will be competing priorities—e.g. global vs local needs. It can help to focus on what the Minimum Viable
Product (MVP) will look like and plan for subsequent phases; also to control the Quality Triangle of: Budget/Total
cost of ownership vs. Scope/Quality vs. Time
 Plan for the business and Target Operating Model (TOM) change
12

richmondgrp.com
Implementation methodology - a closer look
Having a structured approach to delivering your new system will significantly improve your chances of project suc-
cess. The methodology and framework you use will sometimes be mandated by your organization, but where there
is a choice, there are three 3 approaches you could adopt: (1) Waterfall (2) Agile or (3) a hybrid approach.
Project Management Body of Knowledge (PMBOK) Prince 2
Issued by the Project Manage-
ment Institute, PMBOK guidelines
represent generally accepted best
practice processes for most pro-
jects most of the time. Recognized
as a set of standards by both ANSI
and the IEEE.
PMBOK Comprises 5 main process
groups and 10 knowledge areas.
Aimed at maintaining organization
and control of projects through
processes and stages with seven
guiding principles:
 Continued business justification
 Learn from experience
 Defined roles and responsibili-
ties
 Manage by stages
 Manage by exception
 Focus on products
 Tailor to suit the environment
Scrum Kanban  Kanban is an agile method-
ology but without iterative
steps, or fixed length sprints
 Teams pull tasks from a
prioritized backlog of tasks
 Releases are made continu-
ously or whenever deploy-
able product is created
(2) Agile
Agile project management is an iterative development methodology that values human communication and feed-
back, adapting to change, and producing working results. There are many Agile frameworks, two popular ones being
Scrum and Kanban:
 Work is done in time-
boxed sprints, of c. 4
weeks, selected from a
product backlog of re-
quirements
 Product is released for
deployment to a cadence
determined by the sprints
 Strong focus on cross-
functional teams, with no
set team roles
 Team members can specialize
 Focus is on continuous improvement of process, but does not
prescribe the formal meeting rituals of Scrum
(1) Waterfall and similar structured methodologies
The waterfall methodology has been around since the 1970’s
and will be familiar to most. It has utility from software devel-
opment through to packaged software implementations as
well as areas outside of IT.
Other non-agile methodologies have been developed which
have defined stages, principles and themes.
Two examples are:
 Key artefacts: sprint kickoffs, daily stand-ups, sprint reviews, sprint
retrospectives
 Requirements are decided
up-front
 No scope for change
 “Single project” view
 Build then test
 Highly structured
 Values comprehensive
documentation
 High stakeholder engage-
ment during requirements
and acceptance testing
 Allows requirements to evolve
 Change is expected and em-
braced
 “Multiple project” iteration
approach
 Build and test concurrently
 Self-organizing
 Values delivery over docu-
mentation
 Almost continuous stakeholder
engagement
(3) Waterfall vs agile?
Waterfall Agile
Or can you take the best from both?
13

richmondgrp.com
Implementation methodology - can you use waterfall and agile methods?
Implementing packaged software usually involves some development-like elements
Talking points:
 These example “Design & Build” components lend themselves to
Agile delivery approaches, even if the overall project delivery is water-
fall
 But the need to satisfy any sequential Requirements/Design/Build/
Test project tollgates, mandated by your organization, might need to
be negotiated
Some Agile techniques to consider
Here are some Agile techniques that can be useful in projects, irrespective of your overall methodology
Used by both
Kanban and
Scrum
projects
USE CASE DOCUMENTATION
 Kanban has crossed over to IT pro-
jects
 Their visual appeal is compelling
 A strong motivator to see progress at
a glance
THE DAILY TEAM STANDUP MEETING
USER STORIES KANBAN CHARTS
A powerful way to document requirements and de-
sign. Executed well these can form the basis of user
documentation, test cases, and training material.
(SCRUM) BURN DOWN LISTS / CHARTS
 Used extensively in Scrum projects,
the “Burndown chart” is another way
to illustrate team delivery progress
 Scrum focus is on delivery, but “work
remaining” is also a great metric to
measure progress
Lessons learned
 Execute your project methodically
 All methodologies stress collaboration. They differ in how to collaborate, in project roles and the
timing of stakeholder involvement
 Use appropriate software tools to assist - collaboration tools, project management software etc
14

A closer look at Use Cases - a requirements documentation technique
richmondgrp.com
Use Cases are a means for documenting requirements and design details and are equally suitable for agile
and waterfall-based projects. Their use (or an alternative) can be mandated at the project initiation stage.
Benefits:
 They help to capture the detailed functional requirements of a system, expanding on requirements
gathered at the software evaluation stage
 They can serve as the basis for the estimating, scheduling, and validating effort.
 Use cases can evolve at each iteration from a method of capturing requirements, to development
guidelines to the software supplier (or programmers) or , to a test case and finally into user docu-
mentation.
 Alternative paths can be captured that can improve system robustness.
 They are easily understandable by business users, and have proven to be an excellent bridge be-
tween technical staff and users.
Lessons learned
 Consider mandating the use of collaborative software to generate and control the generation of
Use Cases, especially where multiple teams are working on delivering requirements and design, and
changes are being made
 Richmond has invested in customising Use Cases for use of asset finance company clients, has a
robust set of example template Use Cases, and uses collaborative software to adapt / produce them
TYPICAL USE CASE CONTENTS (SUMMARY, EXAMPLE)
Actors and context Pre-conditions & triggers Business process
(scenarios and extensions)
User interface details
State model
Non functional requirements
Functional requirements
Post-conditions & results
Business object model
15

DATA MIGRATION AND CUTOVER
ASSET FINANCE SYSTEMS: PROJECT IMPLEMENTATION “101”
richmondgrp.com
You have started your asset finance systems implementation project
What are the typical pain points in the road ahead?
In the next few sections Richmond Consulting Group looks at three areas that will
need attention if the journey is to be a smooth one:
 Data migration and cutover
 Testing
 Business change
16

DATA MIGRATION AND CUTOVER - our top 10 tips
richmondgrp.com
10 TIPS FOR A SUCCESSFUL MIGRATION
Senior level stakeholder support is key
The main application implementation is often seen as the main focus of the project with data
migration treated as a necessary technical task. This would be a mistake - data migration is
never easy so engage senior stakeholder support to remove roadblocks

Do not treat migration as an IT-only responsibility
Engage the business in the migration at the outset, and ideally have them lead this stream of
work. They will have invaluable insights into the data, its quality, the need (or not) to migrate
specific data items, alternative data sources and mapping rules

Engage Finance teams early
Finance teams have an important role in ensuring that the new system remains reconciled to the
general ledger and in validating finance balances, including technical income recognition
balances

Conduct detailed data profiling before attempting to create ETL mappings
Do not rely on meta data descriptions to reflect data content. Similarly, ad hoc queries do not
always uncover full data content. Effort here will be rewarded with higher quality ETL mappings,
earlier data quality cleansing opportunities and avoidance of “Load and explode” syndrome
(where data quality and mapping issues are only uncovered late in the project when the first full
data load is achieved)

Minimize the amount of data to be migrated
It is tempting to migrate “all” data. Business teams will be well placed to assess whether data
items are needed in the new system. Minimising the amount of data to be migrated will save
unnecessary effort and cost

Start data cleansing early
Start early but carefully assess the risks versus benefits of where to cleanse data:
 Manually fix in the legacy system vs
 Automate data cleansing as part of the ETL transformation step vs fixing data in the new
system (the general rule is to avoid this)
Risks include risk of updating a live system vs risks of automating as part of the transformation.

Use a data repository that emulates the target system
This avoids impacting live systems, facilitates testing on a static system, and aids data cleansing
tasks

Mitigate the dependency of the migration system build on completion of the
main system build
Delays in the main system build will likely impact delivery of a final migration build. (1) Maintain
good project disciplines and (2) mitigate where possible by segmenting the data into
manageable parts - e.g. by addressing master data components first (business parties, contracts,
assets, banks etc) and then more dynamic data later

Build a detailed cutover plan and IT run book
These should be started early and be refined during, ideally, a minimum of three conversion
dress rehearsals

Loaded data is not necessarily good data
The main implementation teams will need to test that new system processes will work with
migrated data as well as any manually created test data. Delivery of migration data to the
implementation team should be planned to happen as soon as possible

1
2
3
4
5
6
7
8
9
10
17

richmondgrp.com
Planning and business input
 There is often limited planning
 IT teams are typically given a brief to move data to the new system, and without guidance
from the business make assumptions about what data is to be moved and its quality
Data profiling and cleansing
 Data migration is often meta data driven NOT content
driven (i.e. the working assumption is that the data
description accurately describes the content and is
consistent across all departments)
 Formal data profiling - analysing data content - is often
omitted until data issues are revealed at the test stage.
Instead ad hoc analysis is often performed in an attempt to
identify data content
 Data in the legacy system may have built up over time and
might not be needed in the new system.
 Data might be needed in the new system that does not
exist in the legacy system, resulting in the need to find
sources for the required data, using mapping rules, or by
the business creating the values
 Data will likely need cleansing and can usually be
automated once the rules are known - e.g. by de-
duplication, correcting invalid names and addresses,
cleaning formats, and standardising addresses
Design
 Migration teams often work with limited knowledge or
documentation of the source system, the new system, or both
 The configuration settings of the new system are performed (or
changed) as the implementation progresses leading to late
migration design updates
Challenges of a typical data migration
Project start
 Data migration is often treated as a mainly technical task with limited business input
 The existence of data quality issues is often not anticipated or the extent is under-estimated
 Teams sometimes have insufficient access to the target system until relatively late in the project
Lessons learned
 Obtain senior stakeholder support for the migration project
 Treat the project as a business project not an IT project - engage business teams who understand the
data, can make decisions. Involve legacy system experts + target system business experts
+ target system technical experts + the data migration team
 Base ETL mapping rules on a thorough understanding of data, not assumptions. This will materially reduce the cost
associated with amending code by up to 75%
 Resource data cleansing so that it can be active throughout the project. Do not leave this task until it is too late
 Data cleansing can happen in the source system, either manually or by some systems means. Automated cleansing
is usually more efficient and will capture new cases once the rules are in place
 Avoid attempts to migrate data to the new system for cleansing, although there are sometimes exceptions to this
 Anticipate data mapping to be iterative and continuous throughout the project. Document the mappings.
 Do not base ETL rules on small data samples using ad hoc queries and do not rely on metadata descriptions. This
will likely result in unplanned data cleansing and/or ETL design re-work late in the project
 Consider the use of a dedicated ETL software instead of a custom ETL build
 Consider implementing a dedicated data repository. This will improve the testing and error discovery efforts with-
out impacting active systems, allow testing and re-testing on a static data set.
 Decide how to de-commission the existing system (e.g. maintain an archive version). Budget for the costs of this
 Involve the Compliance team early. Any internal or external auditor involvement should be early, instead of after
the fact
18

richmondgrp.com
Data cleansing
Income recognition
Cutover planning
The RCG calc tool for conversions
Migration project test and validation pressures
The pressures that can cause a migration project to exceed its budget and deadlines:
# Item Example mitigation strategies
The need for the migration team to wait until the
new system is configured often results in full
migration testing being squeezed to the end of the
implementation timetable
Segment the data so that, for example, master
data can be validated before dynamic data.
Notwithstanding the risks of relying in unit tests,
attempt walkthroughs of small data sets to prove
migration concept
The new system will require migrated data to be
available to complete application testing (it cannot
be assumed that a loaded record is a good record).
Any delays to providing a valid migration to the
application test teams will risk impacting the overall
timetable
Ensure strong project management discipline,
engage stakeholders with authority to remove
roadblocks, and ensure the migration team
comprises the right mix of business and IT
“Load and explode”: unit testing often fails to
disclose data errors. The first indication that there
are data issues is often when the first full data
migration is performed with failed tests leading to
time-consuming re-design and build work
Conduct full data profiling before commencing the
migration design and build so that data is properly
understood. Then initiate data cleansing as soon as
possible
Ensure business teams have challenged whether
data needs to be migrated at all.
Validation of income recognition balances is often
under-estimated. This activity usually poses the
challenge of dealing with (re-)calculated values
rather than migrated values. Differences will always
arise.
For contract management (“CMS”) migrations, the
task of reconciling the various CMS finance balances
with the General Ledger, pre- and post-conversion,
is often necessarily undertaken in full only after the
main contract balances are successfully migrated.
Any delays to that happening will squeeze the
finance reconciliation activities.
Engage business and finance teams early to
address the income recognition and GL
reconciliation challenges, and to identify, explain
and document line item differences.
Use predictive tools, such as the Richmond
Consulting toolkit, to validate income recognition
balance differences
1
2
3
4
19

richmondgrp.com
Conversion cutover
In addition to the complexities of migrating data is added the challenges involved in managing the actual cutover
itself.
What is cutover?
 Bringing live a non-production system to a production (live) environment
 Moving data from legacy and other data sources to the new system
 Managing transactions in transit and timing differences (e.g. for bank and billing transactions initiated immediately
prior to the cutover date)
 Technical IT task to facilitate the above - e.g. possible hardware, operating system or database changes, replication
handling, disaster recovery handling amongst others
What is needed to manage cutover?
 A detailed cutover plan and run book covering all the steps and dependencies to achieve cutover, including
planned timings and decision points for moving from one critical stage to the next
 Approval hierarchy up to CEO/COO/CFO level to confirm moving through the cutover stages to a Go/No go live
decision (or rollback to legacy)
 Reconciliation and validation processes that will be used to support a Go/No go decision
 Advancing normal processing times to minimise the extent of transactions in transit &/or requiring re-entry to the
new system
 Staffing for the cutover dates and arranging out-of-hours system and building accesses
Lessons learned
 Plan early and involve all parties in the cutover plan - business, IT, software vendors, project teams
and other service provides - right down to who will provide the pizzas
 Undertake full Conversion Dress Rehearsals to establish, and then refine, timings and to confirm that
all steps can be completed in the available time. We normally recommend at least three rehearsals,
minimum
 Refine and automate validation and reconciliations - these need to be comprehensive enough to support a Go/No
go decision yet be achieved within a usually tight timeslot
 Ensure staff and all affected external organisations are aware of the change timetable and will be available for the
cutover dates
Finance validation and reconciliation - a closer look at one area
Significant finance effort is frequently given to validating the technical income recognition balances (e.g. unearned
interest). There will always be differences, even for ostensibly the same calculation bases in the legacy and target
system. There are many approaches to validating the balances; here are just two examples (there are other ap-
proaches too) which meet the “automate reconciliations” advice from the previous section:
In this example a validation tool is used to recalculate the
balances once the detailed calculation rules in the legacy
and new system are understood
In this example a “predicted balance”
approach is used
20

TESTING
richmondgrp.com 21

TESTING - our top 10 tips
richmondgrp.com
10 TIPS FOR A SUCCESSFUL MIGRATION
Senior level stakeholder support is key
Ensure stakeholders are involved and informed in the testing phase. Their support will be
needed to remove roadblocks, free business staff to support testing teams as well as undertake
User Acceptance Testing. Finally, stakeholders will need to affirm the critical go-live decisions
based upon test results and workarounds for any non-critical defects at go live

Have a realistic test plan and work methodically
Have a signed off test plan that sets out what is to be tested, by whom and when. Work
methodically using recognised test standards, and use test and defect management tools that
are available to you

Resource test teams carefully
Use testers with credible understanding and experience of the business. This might mean
seconding people from the business &/or using external expertise. External testers will need the
support of the business to work efficiently, so plan for this

Respect the different testing roles, responsibilities and goals
Software vendors are responsible for delivering working software.
System testing exists to ensure the software is fit for the purpose for which you will use it.
User acceptance testing is to validate that the software will be acceptable for acceptance into
the business. It is not an extra opportunity to perform functional testing or bug hunting

Accept that you will go live with defects
There is no such thing as zero risk and there is a cost to delaying a project to address every last
defect. It is the responsibility of the project and stakeholders to balance the cost of delay with
the risk of implementing non-critical workarounds and a defect resolution plan.
Establishing trusted relationship with the software vendor will be important.

Treat testing as an investment not an unavoidable cost
Look to re-use testing artefacts (plans, scripts etc) for use when the new system transitions to
your support teams.
Consider investing in test automation not only to support the implementation but to reduce the
cost and increase the efficiency of future release and upgrade deployments

Plan for the testing pressure points
Plan and look for ways to mitigate the pressure on down stream application processes (a failure
in one process preventing other processes from performing and therefore being tested).
Look for ways of moving migration data into the test systems as early as possible so that
processes can be tested against “real” data, not just manually generated test data

Partner with the software vendor
They will usually have good experience of testing their systems. Leverage their experience. 
Don’t forget to test…..
Do not forget to plan for the other types of testing that will usually be necessary: security and
penetration testing, performance tests, disaster recovery proving, operational readiness testing
and similar.

Involve test teams early
There might be a cost to this but the benefits can be big. Testers can be drafting test cases and
scenarios and hit the ground running when the time to test begins.

1
2
3
4
5
6
7
8
9
10
22

richmondgrp.com
Types of testing and responsible parties
Testing as an investment
View testing as an investment in your company’s ability to test future releases and upgrades rather than an
unavoidable project-only cost.
To do this, make it a priority to plan and execute the test plan so that opportunities are taken to re-purpose system
tests for later use. Also to be considered: automating tests for use over the life of the system.
Unit testing is performed by the software company developers responsible for delivering working software that has
undergone documented unit testing. Any customisations, interface builds and any system configuration should be
unit tested before delivery. Ensure:
 Acceptance criteria are agreed for taking code releases from the vendor
 The vendor has strong release and code change disciplines
Integration testing is performed to expose any defects in the interfaces and interactions between systems. In
practice this testing will often be performed by test teams and IT staff alongside the software vendor.
System testing tests the whole system, but here we use this term to also encompass functional testing of all parts of
the system as well as regression testing (testing that previously working parts of the system continues to work after
new code is released). System testing should focus on ensuring the software is fit for the purpose it will be used for.
The goal is not to find defects for circumstances that are unlikely to arise in practice
Resourcing the test team is covered below, but is usually one of, or a combination of: internal test teams, co-opted
business users, third-party testers.
User Acceptance Testing, undertaken by business users, is the final stage validation that the software can be
accepted into production once the software has passed the system testing stage. It should not be seen a last minute
attempt by users to find functional defects.
Who should be in the test team?
All industries are special in their own way, but the leasing sector (and the testing of leasing applications) really does
need specialist knowledge and experience in some key areas (for example payment calculations, commission
calculations, income recognition, accounting etc. Testing will make material demands on business users and project
teams to provide this knowledge.
Recognising the need for a testing team with the right mix of leasing domain knowledge and testing experience, an
effective test team will generally be resourced from a combination of:
 Specialist internal company test teams
 Secondment of business users to the project
 Outsourced, third-party testers
… with support from the software vendor.
23

richmondgrp.com
The need for migration data
Ensure testing is performed using migrated data as well as test data generated for specific Use Cases - refer also to
the data migration section on this.
The software testing lifecycle
The stages Example
Artefacts
Testing requirements
The Use Cases (or business requirements) have been documented, ideally
with test team involvement. Testers can now start analysing the business
requirements to help to identify the scope of the testing. Although this
stage is often omitted, we recommend not doing so.
Planning
Create and sign off a test plan clearly identifying the activities and
resources needed, including any test and defect management software to
be used, the tracking metrics to be used, an assessment of the risks (and
mitigations) and any company testing standards to be followed.
Analysis
Decide “what” is to be tested, with traceability from the requirements.
Test conditions should be clear and follow directly from the Use Cases, if
used (or requirements if not).
Design
Decide “how” to test by covering, inter alia: the test conditions , test data
preparation, test environment, and test metrics.
Implementation
Create the detailed test cases
Identify which test cases will form the regression test suite
Identify candidates test cases for automation
Script the test cases (manual &/or automated)
Test execution
Execute the test cases, log defects, and track their resolution.
Expect and plan for re-executing the test suite as code fixes are deployed
Conclusion
Agree exit criteria and reporting to stakeholders and others
CommentaryExample
Artefacts
Defect management
Key points:
 Use a defect management tool and ensure everyone is trained to use it
 Work with the software vendor to coordinate how the recording and
management of defects will be coordinated with their internal defect
management systems and reporting
 Agree severity and priority definitions
 Different defect fixes will have different timescales and resource implications
for the software vendor. Close cooperation and compromises might be
needed to maintain momentum
 Demand clear, well-written defect report narrative to give the software
vendor the best opportunity to fix the problem, and for other staff to follow
the issue, or create workarounds if necessary
24

 Involve testers early in the project, ideally at the requirements gathering stage
 Projects where business requirements have been allowed to evolve throughout the implementation
will face the challenge of testing a moving target. The importance of well-documented requirements
at the outset bears re-stating.
 Using specialist test management software will help efficiently manage the recording and execution of tests, the
recording and resolution of test defects, and aid collaboration and communication between testers, users, the
software vendor and other project teams members.
 Keep in mind that data privacy and protection rules will need to be respected with test data. This will often mean
obfuscating data so that client confidential data is not exposed to 3rd parties (software vendors, external testers
etc). Address this issue as part of the test planning process
 Ensure users are trained in the use of the software, and have training documentation developed for this purpose.
This needs to happen before they are asked to undertake user acceptance testing (“UAT”).
richmondgrp.com
The test dependency risk
Be aware of the linked dependencies in testing typical contract management systems and how this squeezes tests of
back end processes where upstream functions are failing. Finance testing is particularly vulnerable here. Recognise
the risk and adapt where possible.
Time to go live - negotiation will be needed
It is likely that you will go live with defects, although not the critical ones.
There is a cost to delaying a project until every last defect is fixed and this cost needs to be measured against the
cost and risk of implementing defect workarounds. Focus on delivering the minimum viable product into production
to realise benefits of the new system as soon as possible.
There might be strong demands to fix everything before going live. Every effort should be made to fix the higher
priority items without jeopardising timescales or the business. Strong realistic stakeholder leadership will be
required at this critical point, informed by a trusted relationship with the software vendor.
Caveat
This has been a necessarily brief introduction to testing for asset finance implementations. For the sake of brevity
much has been excluded, including:
 Security / penetration tests
 Performance, volume/load testing
 Usability testing
 Operational readiness tests
 Disaster recovery testing
 Development of smoke tests
 Migration validation testing, although touched upon in the migration & cutover section
Lessons learned
Whether and when to consider test automation
Automation requires some investment. However it brings agility to testing by allowing changes and re-tests to be
executed repeatedly and faster than a human could achieve. Well designed automation scripts allow for an increase
in scope/coverage of testing that would not be practical with manual testing.
Post go-live support staff will appreciate the ability to deploy releases and upgrades with a reduced need for
organising a large test campaign. It will facilitate a move to a continuous software delivery model with more
frequent code deployments than might otherwise be contemplated.
Bear in mind that it is not necessary to automate all testing. Focus on those items that test functionality that is likely
to be stable, and that can be repeated. Start small and extend the scope of automation as experience increases.
Tests that are only needed a few times should remain as manual tests executed by professional test staff.
25

BUSINESS CHANGE
AND
TARGET OPERATING MODEL
richmondgrp.com 26

BUSINESS CHANGE AND TARGET OPERATING MODEL (“TOM”)
richmondgrp.com
Why the need for business change?
Implementing a new system invariably impacts the business’s processes, people, and organisation, but it provides an
opportunity to re-engineer out inefficiencies, and move to a new Target Operating Model.
Benefits realisation
The need, and opportunities for, business change is often under-appreciated. However, it holds the promise of fully
realising the benefits of a major systems change, such as:
 Better customer and employee experience
 Reduced operating costs
 Re-focus on value-added tasks
A structured approach to managing the business change
The business change needs to happen in parallel with the systems change and should be managed in a structured
way. As an example. Richmond Consulting Groups preferred method is to use templates covering the following:
 Change definition and audience identification
[Change name -> Definition -> Audience impacted -> # of people impacted]
 Impact assessment
[Change name -> Roles impacted -> Process impacted -> Systems impacted -> Perceived effect -> Timing]
 Adoption strategy
[Goals and objectives -> Challenges -> Key messages -> Approach]
 Communication tactics
[Tactics -> Audience -> Goal -> Delivery channel -> Timing -> Responsible party]
 Training tactics
[Initiative -> Audience -> Purpose -> Method-> Timing -> Responsible party]
 Organisational changes
[Change name -> Team impacted -> Purpose -> Activities-> Timing -> Responsible party]
Lessons learned
 Appoint a business change management leader at the outset
 Engage senior stakeholder support for the business change initiatives
 Update the change management control documents/templates and then:
 Liaise and communicate promptly with affected business teams, hold them to account and obtain
sign-off for the changes
Example TOM control
summary
27

richmondgrp.com
Final comments
This has necessarily been a brief and high level look at some of the pain
points that frequently occur when selecting an asset finance system ,
initiating a project to implement it and some of the pain points in the
implementation itself.
It is, of course, not meant to be exhaustive - there are many project
topics that we could have covered - and is much summarised to give you
the key points.
We welcome comments and would be happy to help you get your
projects off to a good start, or recover one that is slipping.
A selection of our customers
28

Richmond Consulting Group is a leading business transformation practice
dedicated to the asset finance and leasing industry
Practical and pragmatic
Experienced,
knowledgeable, safe
Global reach - local execution
Delivering projects in Europe,
America and Asia
Asset Finance expertise
Serving our clients for over
20 years
Business
transformation
System
implementation
Data quality &
reporting
Business
continuity
Contacts
David Pedreno: +44 7802 446137
David Harmer: +41 78 808 01 99
Richmond Consulting Group
22a St James Square
London
SW1Y 4JH
United Kingdom
www.richmondgrp.com

Asset finance systems projects guide 101

More Related Content

What's hot (10)

Similar to Asset finance systems projects guide 101 (20)

More from David Pedreno (14)

Recently uploaded (20)

Asset finance systems projects guide 101