<!--test task for Deloitte Product Owner 230822--> ### Case study For this presentation, I take the example of XY, a tax software. It runs on the local servers of multiple clients and is integrated with their payroll, banking and accounting software, E-commerce platforms, and CRM. We want to replace it with the new application, AB, which clients require for the latest compliance, and which has a modern development framework which is more fit for our developers. XY as well as AB are data-driven, which means that they gather financial and tax-related data, receive real-time updates on tax regulations and carry out predictive analysis for the current year’s tax liabilities. #### Brief You have been allocated ownership of a new SaaS product that will replace an established application that has been used within the organisation for the past 5 years. The product is data driven with multiple integrations to other systems including physical hardware which you have overall accountability for but do not administer. It will be released in a staggered fashion. It is accepted that the new product does not currently have the same level of functionality as the previous application however the vendor are keen to develop new features. You will have support from a more junior member of the team. #### Assumptions 1. We don’t have to create a new database - instead, we migrate or re-use the existing one. 2. We only have the task of migrating clients to a new version, plus handling the integrations. 3. It is possible to only focus on migration, and postpone the creation of new features until the migration is complete. 4. The new application is ready to use and we have access to its documentation, specifications and technical support team. 5. The application is in constant use and cannot be stopped: means that we have to continue processing the incoming data during the rollout of the new application. 6. We have good reasons for migration. For example better compliance, a newer framework which is going to be easy to work with and add new features. 7. Ideally, the new software is a new version of the previous one, which might mean that it is largely compatible with what we had before. #### Risks The risks are introduced by the issues that impact the project in four main ways: [source](https://www.montecarlodata.com/blog-data-migration-risks-checklist/) 1. Extend the length of the migration 2. Lower productivity in the new environment 3. Generate internal or external compliance violations 4. Expose or lose valuable or sensitive information For example: - The database might not be compatible. In this case, we’ll have to either redesign the database and migrate the data or seek an alternative product that would be compatible. (1) and (4) - The teams might not always be available, or there may be staff changes, as people move between projects - we’d have to renegotiate our expectations. (1) - Not all of the integrations may be possible to implement. They might need to be added as new features later. (2) - Hardware might be out of date and will have to be replaced. The use of local hardware can be evaluated against using cloud solutions in terms of costs and security. (3) and (4) #### Approach We can break the method into four general stages, coming from a more general to a more detailed view of the context: discovery, strategy, communication and planning. We use a guiding principle that states that we ‘need to make sure everyone on [our] team – plus other stakeholders like marketing and support teams – understands what [we’re] trying to build, why [we’re] building it, how long [we] expect it to take, and how the project is tracking towards release.’ [source](https://www.atlassian.com/blog/agile/product-managers-guide-release-planning) 1. Discovery phase. - **Hardware**. Check if the hardware is fit for the new product. Since we do not manage the hardware directly, there needs to be a discussion with hardware administrators about its compatibility with the new product specs. - **Database**. Because the previous version of the product has already been established for the last 5 years, we need to understand how we treat the data that has been accumulated and processed during that time. This may mean that access to some or all of the data will have to be retained, and the processing of new data during the process of migration cannot be stopped. We have to acquire and analyse the existing database and check how compatible it is with the new product. - **Integrations**. Evaluate which ones are realistic in which release. For our present example, the tax software application XY, let’s assume that it can be integrated with the client’s payroll, banking and accounting software, but for the E-commerce, and the CRM which some of our clients use, there are no existing integrations and they will have to be developed from scratch as new features. 2. Strategy. - **Goals**. Evaluate if the new product is indeed something we need to migrate to. Since it doesn’t have the same level of functionality, there must be something else which makes it more appealing to the users compared to the previous one. Define non-goals - what we won’t do (eg CRM and E-commerce integrations are not featured in the new application, so we’ll have to do them later as new features). - Defining **release objectives**. For example: - v.0. Pre-alpha. Before formal testing. Database interconnectivity. - v.1. Alpha. User roll-out: 10%. QA: 25%. - v.2. Beta. User roll-out: 20%. QA: 50%. - v.3. Limited. User roll-out: 50%. QA: 75%. - v.4. Expansion. User roll-out: 75%. QA: 100%. - v.5. Full-Scale. User roll-out: 100%. QA finished. - v.6 New features. Planning of work on E-commerce and CRM. - **Roadmap**. The difference between a roadmap and a project timeline is that the _roadmap_ is ‘what’ and ‘why’: more high-level and focuses on creating communication between stakeholders, teams, and executives; the _timeline_ is ‘when’ and ‘how’, used for day-to-day coordination. In other words, a roadmap is a tool that helps product owners to discuss a variety of product-related trends, such as market trajectories, customer insights and feedback, company goals, and effort constraints, by presenting it in a visual form to the stakeholders.[source](https://www.atlassian.com/agile/product-management/product-roadmaps) - Sanity check: show how realistic is to do the work in the allocated time. - Defines the priorities and dependencies. - **Deployment strategy**. The difference between release and deployment is that release is the moment when end users get access to new code or features to serve a business objective, while deployment is the process of putting executable code in its final destination. [source](https://docs.launchdarkly.com/guides/infrastructure/deployment-strategies) For a case such as this, a blue-green deployment strategy might be appropriate. [source](https://www.redhat.com/en/topics/devops/what-is-blue-green-deployment) This means that we deploy the working application into an environment independent from the existing application, and release gradually, switching more and more client servers into the new application with each release. - **QA**. Writing test suites, creating a set of cases for smoke tests, and regression testing. [source](https://conf.dataart.com/display/CA/~WBS) - **DevOps**. In collaboration with DevOps, we discuss such project needs as creating dev and staging environments, treatment of the database and a strategy for practical steps for staggered rolling out of the new application and blue-green deployment. - **UAT**. We develop this strategy with the UX designer, lead engineer, QA engineer and the client. [source](https://usersnap.com/blog/user-acceptance-testing-workflow/) Consists of planning, execution, documentation, evaluation, reporting & lessons learned. Yet, not all of it should happen in the end. The point is to start iterating early, so ideally we could be doing a UAT session before each release. Usually, UAT generates not only feedback but change requests, which might be tricky to treat separately. However, they are best packed into the final release. 3. Communication. - Creating a unified **communication environment**: a wiki space, documentation hierarchy, chat channels, and Jira/task tracking workflow. - Client communication plan. We’d have to develop a protocol that would allow us to coordinate the roll-out with the clients. Since the release is iterative and staggered, we’d need to keep the clients updated on when they should expect the release and provide the means of collecting feedback. To keep the communications focused, we have to identify one point of contact per client. - **Team structure**. Define the team. Make sure everyone got access to the tools they need. Depending on the resources available, we will require one core product team, one team that would work on integrations and a QA team. If more resources are available, the work could be done faster if we have a team per integration working in parallel with an expanded QA team. - **Meetings**. Establish the meeting cadences: daily stand-ups, sub-team synchronisations, stakeholder and client meetings. - Daily stand up, 10:30 am @ 10 minutes; - Weekly production progress meeting, Tuesday at noon @ 1 hour. - Stakeholder meetings. Tuesday at 1 pm @ 1 hour. - If using sub-teams: meetings per sub-team. Monday and Thursday, 30 minutes. - Meeting with hardware administrators: ad hoc, more meetings in the beginning when we need to create a staging version of the database, then more meetings when we require to create interconnectivity between the database and new application so that both old and new apps could read and write to and from the database in blue-green deployments - Regular client meetings: to establish a regular flow of feedback. Either weekly or more often, depending on team velocity and delivery timeline. 4. Planning. - **Requirements**. Create a product requirements document and iterate with stakeholders - Create **user stories** in collaboration with developers. Connect the project wiki, where the issues are described initially, with an issue tracker. - Create project **timeline** and budget estimate. #### The realisation of the proposal Some final words on how we’re going to prepare for the work listed above. As mentioned in the brief, we have a support of a junior member of staff. Their exact duties will depend on their skills, however, they must be present throughout all of the four phases: discovery, development of strategy, creating the communication environment and in planning. Their day-to-day activities will be tactical and might include: - Collaborate with the product team to define the product vision and strategy. Helping to set the objectives and key results. - Making sure the roadmap is up to date so that it serves as the source of truth for everyone involved. This requires critical thinking and following up with other team members on each aspect of the project. - Collecting customer feedback. - Making sure that the production progress adheres to the timeline. The outcome of the kick-off phase will be the full proposal document that would outline the information I’ve talked about today and will have a more precise WBS, scope estimations for all parts of the team preferably broken down per release, key user stories and drafts of roadmap and a product map.