1. Planning the Prepare Stage

2. 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?

3. 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

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

5. 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

6. 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

7. 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)

8. 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)

9. 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?)

10. 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

11. 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

12. 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

13. Appendix

14. 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

15. 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 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