MVP launch preparation plan

Here is a list of activities that will prepare us for the launch of our first production release. This list includes both technical and non-technical activities and some of these activities will be repeated for future releases and some will not necessarily be required. Each work item is not of equal size.

Priority categories:

1=Critical

2=Important

3=High

4=Non-critical

Priorities defined:

Critical work items are considered must have before launch otherwise the launch will not happen.
Important work items will not block the launch, but not completing the item may compromise success of the launch, so they need to be completed before launch.
High items will not block the launch but they should be completed before launch or as fast followers as they will lead to success of the launch.
Non-critical items are nice to have before launch but they can be be done soon after launch as followers.

	Work item (summary)	Description (details and purpose)	Priority (Critical, Important, High)	Work type (Tech, non-tech)	PBI created (number)	Effort/ Complexity Size (L,M,S)	Are there dependencies outside TK	Key dependencies (teams or processes)	Planned completion date MM-DY-YR	Status details (latest progress or any notes)	Status (in progress, done)	Lead	Notes or open questions
1	Set-up launch preparation plan in confluence	Create a list of items to complete in preparation for MVP launch both technical software related items, release process related and key operational activities. Be very crisp on the priority of the work so that we are planning for completion of anything that will block MVP launch in production.	Critical	Both	N/A	S	-	-	06-04-21	Populating the plan with what is known already.	IN PROGRESS	Sunny	Closed this item once we have a somewhat firm grasp of the remaining work documented on this page.
2	MVP rollout strategy and declare target go live date	Figure out the segment of service requests that will be used in the system, including launch timelines and percentage of the population. This will be vital part of the MVP rollout plan as it will allow users to be prepared and additional procedural changes that need to be in place depending on the strategy. We can reduce the change management impacts by keeping engagement of non-impacted users to a minimum during the MVP launch. Agree on an approach for handling backlog applications.	Critical	Both		S							Determine the exact population that will be targeted with MVP. small vessel first registry 3rd party represented which registrars Do we leave the backlog applications where they are (i.e. mail log) or should the backlog be moved over to the new application. If its the later then need to decide how to do this, whether manual data entry or if we need to automate it.
3	Business approval completed	Send requests for approvals and confirm and document the approvals Examples of the approvals might be TAC, ARB, Authority to operate, sign-off from the business customers etc. Are there other that we are missing? If so, lets confirm and document them in here.	Critical	Non-tech		M							What are the different approvals that are needed?
4	Operational reporting needs	Come up with the key operational reporting needs for MVP and define how to fulfil the needs.	Critical	Both		M	Yes	Business and user team					Need to collect the requirements here for MVP in addition for post MVP.
5	Production release process for MVP	Understand the process that needs to be followed including mandatory approvals to go live in production.	Critical	Both		S							Do we have a documented process that can be followed? If not, we can document the process if we know who can explain this to us.
6	Provision and deploy to pre-production environments	Prepare the DEV, TEST, ACC environments in Azure cloud and push the code into each region without any errors and functioning application. This work will be a precursor for production launch and critical for end users to conduct UAT.	Critical	Tech		M	Yes	Cloud team? TNT?			IN PROGRESS		What are the exact regions that are in scope and required? Should we consider TNT in scope here since they are dependency for document management service and vice versa for workload management?
7	Provision and deploy to production environments	Prepare the production environment in Azure cloud and push the code in without any errors and functioning application. The application should be accessible to end users and ready for their use.	Critical	Tech		M	Yes	Cloud team? TNT?					Once the application is accessible and ready for use this work items can be closed. Should we consider TNT in scope here since they are dependency for document management service and vice versa for workload management?
8	Approvals to launch in production	This is the action of confirming that all of the required approvals have been obtained and that approvals will not be blockers to launching in production.	Critical	Both		?	Yes	?					This item is a reminder to make sure we double check that any administrative work is closed out. This is not about understanding what approvals are required as that was a precursor to this work item.
9	User identify management	Who can access the application and putting restrictions in place and what they can do in the application (read, read and write). What different roles are required? (readers, writers and admin). By Anyone in TC that has and within the network with the link would be able to access the application right now.	Critical	Tech		M	Yes	Business and Vessel registry users, Seafarer users					Need the different user roles defined and whom to assign to what roles.
10	Ensure that all of the PBI’s and features for MVP launch are captured in Devops	Having the technical scope for MVP defined and understood will allow team to be on the same page and put a stake in the ground. This will also allow us to declare a go live date which can be used to inform all dependencies (tech and nontech) so that plans and preparations can be put into motion.	Important	Tech	N/A	S	Yes?	TNT?	06-28-21	Started to clean up Devops to have one MVP launch Epic with related features and PBI’s documented.	IN PROGRESS	Troy	Can close once we feel confident we have remaining PBI’s in the Epic for launch MVP.
11	Shared learning from recent launches in MSS	Reach out to other PO/PM that recently launched new functionality to uses in production to learn about steps taken in preparation. MITRACK team launch	Important	Non-tech	N/A	S	Yes	MITRACK PO/PM	06-18-21	Received some information, compared notes against our draft plans and added anything new.	DONE	Sunny	We will also work closely with the Seafarer team to share and learn since both teams are trying to launch their MVP around the same time this year.
12	Understand application behavior in non-happy path scenarios	Test out the unhappy path scenarios and make sure we are happy with the current behaviour or invest in changes that gracefully fail for users.	Important	Tech	?	S							Need to discuss this and we close it out once we have a PBI that is completed.
13	Vessel registry high level process documentation	Documentation of business process flow for current state and future state for MVP iteration. This will help for testing of the end to end flow with workload management, and tweak the process so its as smooth as possible for end users.	Important	Non-tech	N/A	M	Yes	Registrar supervisors, Change management	06-14-21	First part of new process in draft continue to work on getting it completed.	IN PROGRESS	Hugo	What is the final form that the documentation takes? Vision, Miro etc.
14	Release notes and history documentation	Create a summary page in Confluence to capture application release and changes including the details of what was released and when.	Important	Tech	N/A	S	-	-	06-30-21	Page has been drafted need to create a structure and start populating with the key features (tech and user facing)	IN PROGRESS	Sunny	Is Confluence or sharepoint a better place for this material?
15	Revised registrar work instructions	After the new end to end process flow is ready, the detailed registrar instructions will need to be revised to match new process. In scope will be only the instructions that are impacted by MVP rollout and we will minimize change management activities as much as possible (keeping in same repository and current format etc.). This will help rollout training to the impacted daily users of legacy systems and new workload management. Official SOP required?	Important	Non-tech	N/A		Yes	Registrars and registrar supervisors	TBD				We need to define the scope of this work and who is best suited. This is different from training materials?
16	Training plan of registrars to use workload management	Provides an overview of what the new system is and how it works and features that are available This will be in preparation for MVP launch and getting users accustomed to the new tool.	Important	Non-tech	N/A		No?	Registrars and registrar supervisors	TBD				We need a plan to be created that answers: Who is best suited to create and what needs to be created. What training looks like What need to be created to support Who and how its executes
17	Creation of training artifacts	Creating or modifying the materials, procedures, user guides that already exist to incorporate the new system Updated process documentation to incorporate the new system and modified reality Bi-lingual contents required here?	Important	Non-tech	N/A		Yes	-Registrars -Registrar supervisors -Change mgmt	TBD				Should be answered by the training plan.
18	Execution of the training	actually present the training materials and artifacts and post production support materials (SOP’s, tips, guides) bi-lingual training required, through in person or video conference and who does the training	Important	Non-tech	N/A								Should be answered by the training plan.
19	MVP monitoring plan	Figure out the key metrics to track process and system stability and how to track the metrics or needed reporting to support. Without key metrics to track it will be challenging to detect issues and problems and to make sure rollout is having the desired impact.	Important	Both	-		Yes	Registrar supervisors, BI team					Need a discussion about this from a business and IT systems perspective.
20	Operational reporting requirements for MVP	Ensure that the reporting requirements are collected from the key stakeholders and they have access to the reporting as necessary.	Important	Both									Who are the key stakeholders for the purpose of requirements gathering?
21	Build MVP operational reporting	Create the reporting infrastructure and dashboards that were in the MVP monitoring plan.	Important	?									Depending on the requirements and approach this could combination of tech and non-tech.
22	Production release process post-MVP	Likely a re-run of the MVP process minus some one time things and no longer applicable actions This will be important to prepare for implementing any critical bug fixes so that we can move as quickly as possible without wasting time to understand the process.	Important	Both									Should the release process be the same post MVP launch, its good to confirm if any of the process (that exists when MVP is launched) is scheduled to change during the summer so that its documented reducing future impediments.
23	Issue management process	How feedback and issues will be reported by users and where/how they will be documented Should include the entire process that we use for MVP and beyond or de-scope that until we test our the initial strategy for MVP launch. Updates needed to the support desk. Communication of the new application and documentation to provide some level of user support	Important	Both									Is there any existing models that we can use to model around? Discuss with other teams across MSS before inventing anything new. Should also include a method to bring the work into the team for prioritization and documentation on the backlog.
24	Runbook (MBM)		Important	Tech							DONE
25	UXR strategy		Important	Non-tech							DONE
26	Execution of UXR strategy		Important	Non-tech							DONE
27	Summary of UXR results and identification of user blocking issues		Important	Non-tech							IN PROGRESS
28	Closure of UXR issues		Important										Priority of the work item depends on the types of issues. If the issues block the launch then this work is critical, otherwise it is important/high.
29	Go no go decision	Have a meeting that includes all of the key dependencies to provide a confirmation that they have no concerns with launching the MVP on the established target date.	Important	Both	N/A	S	Yes	All teams that lead to success of the MVP launch					Should we have an S2 (scrum of scrums) where representatives from across the dependencies for MVP launch come together to provide a thumbs up that they are ready for MVP to be launched and used in production? Have used this many times in the past and it proved valuable. I propose to have a recurring forum for this leading up to and post MVP launch, where ‘go no go decision’ is just a milestone step.
30	Communication strategy pre and post launch	How updates on the project will be shared and to whom Do we already have the right forums in place or do we need something special stood up (sprint review is not right forum, maybe we use daily email distribution, confluence page, or blog post on the teams share point, teams channel) Structure of the communication? What key metrics or highlights to share.	Important	Non-tech	N/A
31	User acceptance testing strategy	The plan should be drafted here, what needs to be tested and the start and duration and how success will be determined. This work item includes execution of the testing and compiling the results and sharing with stakeholders and getting approval.	Important	Both									We can collaborate with the other teams to partner on the plan as there has already been work done. We can split this into plan and execute and report results if we would choose.
32	Execute post production testing plan	Start to execute on the monitoring plan to validate the new process and report the status and issues that are found and closed out.	Important	Both									Follow the plan that was devised in the earlier work item.
33	New system of record for to house the procedures from the G drive	Training and help documentation is currently in housed in a different repository from workload management. Ideally we can bring the help documentation closer to where the need for it arise, inside vessel registry so its easily accessible during day to day. More thought and options need to be explored for this work. Supports accessibility and easy of updating and keeping documentation fresh and relevant.	High	Both?	-		Yes	Registrars and registrar supervisors					Determine if this should be in scope or wait for later.
34	Modifications to vessel registry forms (pending changes)	Long awaited changes that have not been made to the live forms. These changes should improve the process and client experience.	Non-critical	Non-tech

MVP launch preparation plan

IN PROGRESS