New zealand school of music
deployment plan
Deployment Date: TBC

Revision History:

Key Stakeholder Signoff:

Purpose

This document is intended to provide key stakeholders with a solid understanding of the scope, approach and execution planned for deployment of the new website at victoria.ac.nz/nzsm. It includes information regarding the approach, issue tracking, project communication, roles and responsibilities, resource allocation, and scheduling.

In Scope:

• Deployment - launch, publication and immediate support.
• Tasks and milestones that need to occur before, during and after launch to ensure a successful deployment.
• A process for when the site, and associated works, moves from project to business as usual.

Out-of-Scope: 

• Project works that need to occur prior to launch but are not dependencies for deployment.
• Further development work after launch

Overview

Communications and Marketing (CMG) are working closely with NZSM to deliver a new responsive website in the core Victoria template. This new site and content will replace the existing nzsm.ac.nz website.
The new site has been built on the responsive template within the Squiz Matrix Web Content Management System (hereafter "Matrix").
The content on the new website has been checked by NZSM.

Deployment details

The launch of the new content is planned for XXX, with the process starting at 09:30. We expect the deployment to take up to XXX.
The site is already present within Matrix. Final production deployment will involve XXXX.
Once the new site is live, we will supply an xml export of the old site to be retained by NZSM as an archive. We will also set up redirects to the core site.

Technical deployment

The Matrix environment consists of:

1. An authoring ('master') environment comprising an application server and a database server. This is where staff update web content. It is not available outside the Victoria firewall.
2. Two slave environments, each comprising an application server and a database server. The slave application servers run a caching layer using Varnish in addition to the Matrix application. The two slave application servers are load-balanced by the F5 Local Traffic Manager (LTM) to serve sites on www.victoria.ac.nz to external and internal users.

Key Steps for Deployment

Reversion

If at any stage during deployment the project owner decides to cancel go-live, the following steps are necessary to revert to the existing site:

• XX

We estimate that a reversion will take XX minutes to implement once the decision to revert has been taken.

Assumptions, constraints and prerequisites

• We assume any remaining work on functional components is completed and tested.
• We assume all web services, and their parent database and system are available.
• We assume NZSM, ITS and vendor staff are available to undertake and complete due tasks during the change window, and both pre and post deployment.

Points of contact, roles and responsibilities

Key people involved in the system deployment - XXdateXX

Testing overview

The solution is being delivered using existing production systems, and therefore comprehensive application testing is not required.
The website and new functionality has been tested by the websites team. Testing has been focused mainly on ensuring functionality is working as well as taking on board usability issues. No outstanding bugs identified so far are sufficient to prevent deployment.

Communication plan

A comprehensive communications plan has been developed by Kim Gray, Senior Adviser Internal Communication. This outlines how we will communicate with key stakeholders.

Contingency plan

This plan establishes procedures to recover the www.nzsm.ac.nz site following a disruption, based on both identified and unknown risks.
Possible scenarios (based on identified risks) and their contingencies are outlined below:

Post deployment support

The primary goal of the project team post launch is to provide quick resolution to issues effecting end-users. We expect to receive a large amount of general feedback on the site, as well as more specific issues and support requests. The feedback will come through the following channels:

• feedback form on the website
• ITS service desk
• email or calls to the CMG or NZSM

We will centrally log, sort and prioritise these requests for recording, communications (replies, escalations) and actioning using Jira and Confluence, our project management software. Once collated and prioritised, actions will be assigned directly in Jira.
The person logging the feedback will include the communication and assign an initial priority level, which will be reviewed at least daily by either Jane Young (or in her absence Paul Seiler).
Where possible, all communications to the CMG team should be submitted feedback in written form, so that we are best able to collate, prioritise and action feedback. Where possible, people should be directed to the feedback form on the website, rather than submitting emails, to aid collation and response.

Key roles in post deployment support

All issues assigned a priority of 'critical' will be escalated to:

Handovers

The following criteria must be met before the Victoria International project is closed. Any exceptions to the exit criteria should be noted and accepted by all key stakeholders

Responsibility for content management transferred to web publishers

Content Owners across the business unit will be responsible for ensuring the content is up to date. When they need changes made to content these will be undertaken directly by the NZSM web publishers.
The following conditions must be met before content will be handed over to a web publisher:

• Publisher has completed Squiz training and web best practice course
• Web team has ensured there will be no technical issues
• Web team is confident in publisher's understanding of the system and their role

If there are urgent changes required during the time between deployment and handover these will be made by the website team. A change is considered urgent if it:

• Is subject to time constraints
• Will have a substantive negative impact if the change is not made
• Is not new content, unless arising from an unforeseen circumstance that meets the previous two criteria

To support the handover process,:

• Web Best Practice training is available and all Web Publishers will undertake this as an integral part of their CMS training. Content Owners will also be encouraged to take this training.
• ResolveIT is available to support all Web Publishers.
• Websites have also supplied access to online DIY instructions to solve common issues in Squiz and the Edit+.