New zealand school of music
deployment plan
Deployment Date: TBC

Revision History:

Date	Name	Version	Description
12/03/17	Jane Young, Project Manager Michael Clarke, Web Project Support	v1.0	First draft for consultation

Key Stakeholder Signoff:

Approver Name	Title/Unit	Approval?	Date
Sarah Smythe	Engagement and Events Co-ordinator	Pending	13/02
Dugal McKinnon	Acting Director	Pending	13/02

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:

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

Action	When	Who
All new site content in Matrix is loaded, checked, and published in a publicly readable state.	No later than 72 hours before go-live.	NZSM and project team
All NZSM staff have been loaded into staff directory using a vuw.ac.nz address.	No later than 72 hours before go-live.	Sarah Smythe
Confirm redirects from old site URLs to new locations in new site	No later than 72 hours before go-live.	NZSM and project team
Decision point: go or no go?Is the project owner comfortable with going live? Are all the key stakeholders on board? Are there any unresolved issues?	10:00, XXXday beforeXXX	Dugal McKinnon
Day of go-live
Push NZSM site from cms to www	09:30am
Switch URL from /nzsm-cms to /nzsm. Check there are no conflicts.
Add and test new page remaps
Add and test deleted pages remaps
Check image variances – news, events, standard pages.
Update staff profile links in Active Directory		ITS
Site is now officially live
Undertake regression testing to ensure website is working as expected
Check staff images
Decision point: Continue to monitor or operationalise?Is there any reason to be concerned about the performance or stability of the live system? Can we now treat the system as fully functional and return to a business-as-usual environment?		Dugal McKinnon based on recommendation of project team
After go-live
Announcement email sent to NZSM staff confirming that the new site is live and asking them to let us know if there are any problems.		Sarah Smythe
Monitor feedback through helpdesk and other channels.		Web team
Submit sitemap for new site to Victoria Google Search Appliance and Google.com for indexing	ASAP after go live
XML export supplied to NZSM as an archive of the nzsm.ac.nz site	22 Feb	Squiz

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

Name	Team	Role in deployment
Nathan Irwin	C&M	Team leader - web development and design; to oversee the deployment process.
Michael Clarke	C&M	Web Project Support, to undertake deployment tasks and testing
Jane Young	C&M	Project Manager, to co-ordinate communication with NZSM and Comms and Marketing directors
Dugal McKinnon	NZSM	Acting Director of New Zealand School of Music, business owner of website. Final decision-maker at all decision points. Acceptance sign-off on transition to business as usual.
Sarah Smythe	NZSM	To assist in checking and make recommendation to Dugal McKinnon on release. Communicate with NZSM team.
Ian Edwards	Webstruxures	Provide support for the implementation of the website.

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.

When	What	Who
XX	Confirm content is approved for release.	Sarah Smythe
XX	Email to NZSM staff about changes and when the new site we will be going live.	Sarah Smythe
XX	Email to NZSM staff confirming the site is live and outlining what has changed. Include key message about new functionality and let them know what they need to do if they find mistakes.	Sarah Smythe
XX	Manage process for feedback	Web team via ITS helpdesk

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:

Scenario	Contingency	Escalation point and approver
Earthquake or natural disaster prior to system deployment	If the earthquake is severe enough the deployment will be delayed	Madeleine Setchell
Earthquake or natural disaster during system deployment	Either suspend the deployment until the crisis has passed if the system is stable, or revert, if necessary.	David Archibald
ITS resource unavailable during deployment	Substitute resource, or delay to deployment if no substitute resource is available.	Bruce Parrott
Websites team resource unavailable	Depends who is not available. Most absences can be covered. The deployment will only be delayed if an action cannot be undertaken	David Archibald
Webstruxure team resource unavailable during change window	Depends who is not available. Most absences can be covered. The deployment will only be delayed if an action cannot be undertaken.	Nathan Irwin
Business Owner or Sponsor requires further work prior to deployment in order to approve deployment	Sign off to be sought from Acting Director of NZSM. If content can't be resolved deployment will be delayed.	Dugal McKinnon
The launched site is not publishing or displaying correctly	Delay deployment.	Jane Young
The launched site fails post deployment testing on features considered critical.	Attempt to fix. If a fix is deemed too difficult or diagnosis fails, revert to previous configuration	Jane Young

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

Name	Role
ITS Helpdesk	Forward requests about the NZSM to the web team using the ResolveIT helpdesk
Websites team / web helpdesk	If any issues are raised in existing Online Services channels review this if it is a technical issue raise a bug in Jira. If it is a content issue forward this onto sarah.smythe@vuw.ac.nz
Jane Young, Project Manager	Review and categorise issues on a daily basis. Will co-ordinate web team activity to resolve bugs
David Archibald	Business owner of the system in its business as usual state. Will evaluate issues escalated as business as usual impacts

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

Name	Role
Dugal McKinnon	Acting Director, NZSM
Sarah Smythe	Engagement and events coordinator, NZSM
David Archibald	For impacts on BAU management
Bruce Parrott	Critical IT related issues.

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

Handover criteria	Completed?
All highest and high priority issues for the site have been resolved or are being address in a manner agreed upon with all key stakeholders	Yes
Key stakeholders have agreed that all works deemed 'in scope' for the NZSM project are completed or resolved. Any remaining works can be transition to normal production and support operations.	Yes
The Web team, or others, has assumed responsibility for all deferred/open issues and is ready to resume normal production processes.	Yes
All changes to workflows and content management on the new content have been implemented.
At least one NZSM team member has undergone the required web publisher training.	Yes

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

Browser not supported