Asset Finance Systems: Project Initiation "101"

Asset Finance Systems: Project Initiation "101"
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
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
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
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
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 success. 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 projects 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 methodology 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 requirements  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 development 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 engagement 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 documentation  Almost continuous stakeholder engagement (3) Waterfall vs agile? Waterfall Agile Or can you take the best from both?
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 waterfall  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 projects  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 design. 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
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 documentation.  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 between 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
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

Asset Finance Systems: Project Initiation "101"

Recomendados

Más contenido relacionado

Presentaciones para ti(20)

Similar a Asset Finance Systems: Project Initiation "101"(20)

Más de David Pedreno(20)

Último(20)

Asset Finance Systems: Project Initiation "101"