Planning the Prepare Stage

Agenda What is the Prepare Stage? Why Prepare? When does the Prepare Stage start? How to Plan the Prepare Stage? What should be in the Prepare agenda? What are the outcomes of Prepare? Who is involved in the Prepare stage?

What is the Prepare Stage? The Pega Delivery Methodology is segmented into three stages designed at focusing on implementing Pega, one customer journey at a time. Prepare sets the project up for success

Journey Centric Delivery Flow There is a prescriptive delivery process to guide teams through a Pega project

Journey Centric Delivery Flow Pega no longer run ‘Inceptions’ Instead we follow a methodology that focuses on delivering customer journeys, one journey at a time, starting from the very first conversation with the client This includes refining 2 sprints in advance of commending build

Why Prepare? Define the journeys that will be delivered in the first Production Release (Minimum Loveable Product) Identify what data, interfaces, personas and features will be delivered Enable the project team so that they are ready to work on a Pega project i.e. stakeholders / the team understand the business objectives, methodology, roles & responsibilities and what the end solution will look like Ensure the team are ready to start building, minimizing any potential blockers e.g. Environments are ready, dependencies identified Ensure development and UI standards have been agreed e.g. Dev Ops, Definition of Ready, Definition of Done, Review the User Experience approach; will the scope deliver a loveable system? Ensure governance structures are put in place Build a repeatable process, Sprint after Sprint

How to plan the Prepare Stage? Not all projects are the same; this is true for Prepare as well Each Prepare stage will need to be tailored. We use the Journey Centric Delivery flow as a guide When planning the prepare phase, we review the Project Readiness Checklist to help evaluate the current state We review the Prepare Stage content on Pega Community to help formulate the right approach Create a high level plan to cover the full Prepare duration Confirm attendees Create an agenda for the first week (at least)

What should be in the agenda? A Sponsor address A project kickoff meeting A review of the business objectives (what is the business value?) A review of / defining journeys and the day 1 live plan Allow time to gather this information if required A series of workshops to discuss important topics such as: Governance, technical architecture, dependencies, usability testing review, Dev Ops, development/UI standards, change management, testing, environments and methodology DCO workshops to refine the first 2 sprints (Sprint 0)

What should be in the Prepare agenda? The Prepare Stage will typically take between 1 – 6 weeks depending upon: Complexity of the solution (e.g. integration dependencies, migration, number of DCO sessions) The number of MLP journeys Sprint length (i.e. requires more refinement) The level of UX engagement (i.e. is a full business review required?)

What are the outcomes of Prepare? Case Type Backlog that details the Minimum Loveable Product…. …this is a pre-requisite to Detailed Sizing (Costs) Day 1 Live Plan To-be Technical Architecture diagram Dependency Schedule Prioritised Backlog An Enablement Plan that will be executed during Prepare Journey Centric Test Plan Hardware Sizing Sprint Plan Creation of Stages and Steps (using DCO) Optional: Application Profile

Who is involved in the Prepare Stage? Partner / Pega Resources Practice Leader (Kick-Off) Engagement Leader Lead System Architect Lead Business Architect / Lead Decisioning Architect (for Marketing projects) User Experience Architect Client Resources Sponsor (Opening Address) Business Owner / SMEs Product Owner Solution Architect Lead Business Architect Various members of the Delivery Team will join during Prepare and be involved in DCO Workshops

What risks increase if we do not Prepare properly? Mitigation Time and Cost Wasted Provision environments early Refine 2 sprints-worth in advance of Sprint 1 Enable client resources so they are ‘Pega-Ready’ Definition of Ready / Done Journey Centric Test Plan We don’t build what the business really wants and needs Journey Centric approach using the Case Type Backlog Engage UX early and perform lean usability testing Critical path dependencies delay go-live To-be technical architecture Dependency Schedule The business are not ready for go-live Day 1 Live Plan (Change Management activities) Change not under control Establish Governance

Appendix

Example of a Journey Create a Collections Case 1st PROD Release 2nd Release 1st PROD release – the top line is the first journey, tested and goes live. It contains several integrations (source system extract The second line is the next release - The ability to determine the best payment plan to offer to a customer and send them a letter is a new journey. In this example a letter is sent to the customer (a new integration). Highlight persona – the end customer Highlight how robotics can be used to tie in existing systems then be replaced later – assists with selling in journey centric using Pega’s technology. Mash Up is another example e.g. At CBA we exposed Pega within CommSee using Mash Up - ease of integration with other systems

Day 1 Live Plan – What is different for the business ? Customer Journey : Loan origination. Callers to our contact centre will be taken through a new fact- find which will recommend a loan product, and start the application for the product. Business benefits : Reduce time to apply for a loan by 30% by reducing re-keying. Record fact find against the Loan for regulatory reporting. Systems Change : stop using the current excel based fact find, which means we can prove responsible lending more easily in the future. Loan applications will be auto started from the fact find. Expected Users : 50 model office, ramping to 300 over 3 months as we train. Expected Customers : All existing customers who call to request a loan. NOT new customers in this phase. Data Migration : None. The current excel fact find will be archived, and future responsible lending reports will be done from the new system Future phases : Expand fact find process to capture the information to apply for the recommended loan product, so we can auto complete the loan in the current systems and “wrap and renew” – keep using the current systems with a faster, automated front end. Timescales : First go live 90 calendar days after the project kick-off. Subsequent go lives every 45-60 days. Training : 1 day onsite training for all staff just prior to go live. Four ops staff will work as developers to be able to maintain the system after go live. The point of the D1LP: To support business change management by preparing the client for Day 1 given that they will have 90 days or less notice. It will help the business understand what and who will be impacted. We want to prevent any potential delays to go live by ensuring the client is thinking about what they need to do on Day 1 and the impending change. This is an example. ….. Software projects tend to focus on what the software is to do, rather than how the business will use it. This makes it hard for the business to understand who and what will be impacted on Go Live. This Day 1 Live Plan gives a simple summary of what will be different on the first day of live usage. It is intended as: A sales aid to describe the new world vision A training tool to assist with the business change management goals A development tool, to direct thinking about what the MLP should be It is used to help form the selection for the next sprint plan, and to guide decisions at Governance. Ultimately this forms input to the change management plan. This covers just the functionality for the MLP(s)- not the entire project scope