1. 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 second of three articles 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"
richmondgrp.com
#2 of a series of 3 articles on system selection
and implementation for the asset finance and
leasing industry
Richmond Consulting Group

2. ASSET FINANCE SYSTEMS: PROJECT INITIATION
richmondgrp.com
Introduction
This is the second article of three covering systems selection, initiation and execution for compa-
nies in the asset finance and leasing sector.
Article 1 - Asset Finance Systems Evaluation “101”
In this article, Richmond Consulting Group looked at 10 reasons to upgrade, gave some pointers
on how to select a new system and shared our experience of what success looks like.
To view the article please click here:
https://www.slideshare.net/DavidPedreno/asset-finance-system-evaluation-101-richmond-consulting-group
Article 2 - ASSET FINANCE SYSTEMS: PROJECT Initia- You are here
Article 3 - Asset Finance Systems Execution “101”
In the next article Richmond Consulting Group will be looking at some best practices for:
 Testing
 Migration and cutover
 Business change
 Benefits realisation
… with a focus on asset finance and leasing
Article 3 is due to be published 7th December 2019

3. Project initiation - our top 10 tips to get your project off to a solid start
ASSET FINANCE SYSTEMS: PROJECT INITIATION
richmondgrp.com
10 TIPS
Know what success
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
In the next few pages we take a brief look at:
 the Project Initiation Document
 implementation methodologies
 “Use Cases” as a documentation standard to consider
9
10

4. ASSET FINANCE SYSTEMS: PROJECT INITIATION
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
 Plan to co-locate teams if possible

5. ASSET FINANCE SYSTEMS: PROJECT INITIATION
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?

6. ASSET FINANCE SYSTEMS: PROJECT INITIATION
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

7. A closer look at Use Cases - a requirements documentation technique
ASSET FINANCE SYSTEMS: PROJECT INITIATION
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 ro-
bust 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

8. 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
www.richmondgrp.com
Richmond Consulting Group
22a St James Square
London
SW1Y 4JH
United Kingdom