Asset finance system project initiation 101. “Selecting and implementing a new asset finance system? In the second of three articles, we go back to basics to take a look at what you need to consider at the start of your project to give yourself the best chance of success.” This has necessarily been a brief look at Project Initiation. We welcome comments and would be happy to help you get your project off to a good start.
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