Putting together the go-live plan

Having a detailed plan put together, which can be used for multiple simulations prior to the go-live, is important. It gives you an opportunity to get the go-live plan validated and address any bugs/issues due to missed steps in the release plan. It also allows you to make changes to the plan, allows more time to review with multiple groups and identify the missing elements, and helps educate the team about dependencies and the big picture. The following are some guidelines for putting together your go-live plan:

  • A smaller number of manual steps and more automation is ideal to ensure that you don't have too many steps to perform and track. As mentioned in Chapter 5, Data Migration – Scoping through Delivery, the validation of extraction, migration, and IT data should be automated as much as possible.
  • Include a configuration checklist and any new configurations which need to be completed in the production environment prior to the go-live. Adopt automation or document in detail what needs to be done to complete the required configuration.
  • Minimize dependencies; if activities can be completed in the production environment, mention that as a pre-release item. For example, if an integration solution requires creation of a new database, and if it can be done prior to the release, mention it as a pre-release item.
  • You may be implementing ISV solutions or integrations with third-party systems, or integrating with an application managed by a different team in the same organization. Coordinate with different teams to understand the dependencies and activities needed to deploy or enable their solution. There should be one single deployment plan for all the components which need to be deployed as part of the release.
  • Keep the overall deployment plan simple. Add additional attachments or links for the detailed steps which need to be performed.
  • Create a repository to collect the artifacts and documentation required for completing individual tasks including release notes, validation plan document, configuration checklist, code artifacts, and so on.
  • Put together a visual summary of the detailed plan (as referenced in Chapter 5, Data Migration – Scoping through Delivery). It helps in communicating with the stakeholders.
  • Every step, including logistics like booking hotel rooms and ordering pizza, should be put on the plan with their owners.
  • Ensure that you have not burnt your key resources with the release. Spread out tasks in a way that allows for downtime for the key resources. The real journey starts after putting the system into production, and you need everyone to stay energized for those first few weeks of transition.
  • Try to keep the plan simple and easy to follow for the team. I have used the following table to put together a plan:

Column

Description

Sr. No

This is the task number

Dependency

These are the task numbers that needs to be completed prior to starting. Used to define the dependencies between tasks.

Type
  • Pre-release: Identify all the tasks that can be completed prior to getting into the system's downtime window for release. For example, communication for the upcoming changes, installation and preparation of the future production environments, and tasks for tracking all the necessary sign offs.
  • Release: Tasks to be completed during the system's downtime window for release, such as taking the systems down, ensuring all transactions are complete and your source for data migration has the latest information, running extraction and migration tasks, communication at specific intervals during the release, taking SQL backups during the release, and identifying good checkpoints when backups should be taken (in case you have to go back to previous state). For example, before starting the posting of transactions, as you can't un-post them easily if you found an issue.
  • Validation: Tasks for validation, such as IT validation and business validation (verify the vendors and addresses, open balances, the validation of processes/functionality that were identified in the release validation, and so on).
  • Decisions (Go/No go): Identify the multiple check points when you need to make Go/No go decisions with the executive/project team.
  • Post release: Tasks to be performed after the final decision has been made to go-live. These tasks may go on for multiple days into using the new system. For example, pushing icons on user desktops/enabling users, communication for release, turning on automated processes, verifying acceptance of the outgoing EDI files by customers, verifying acceptance of positive pay files by each of the banks, and so on.
  • Roll back: You may have to roll back to state prior to the release in unfortunate events like when something goes wrong during the release, critical issues that are identified, or external, uncontrolled dependencies that caused the issues. In any case, you need to have rollback steps defined and practiced in the release simulation phase in order to have an uninterrupted availability of the systems to the business. The time needed for the rollback procedure needs to be considered in the release process the go/no go decisions need to be made in a timely manner to allow completion of the rollback procedure.

Description

This is the task description.

Owner(s)

This defines the owners to perform the tasks.

Start date/time

This is planned start time for the task. It is important to keep track of the timing on tasks that are on a critical path. Any delays in critical path items would impact the overall schedule of the release.

Time needed

This is the time needed to execute the task.

Comments

These are the comments and/or additional information.

Detail steps

These are the detailed steps to execute the overall task, if applicable. Attach or link to the detailed document if required.

Status tracking: Status, actual start time, finish time

Keep track of the actuals in release simulation cycles to adjust your plan, and work with the technical teams to reduce the time taken by critical path items.

During production release, keep track of the actual timings for each of the task.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset