copyright © 2002 bolton institute dept. of computing and electronics – mia module lecture 12:...

Copyright © 2002 Bolton InstituteCopyright © 2002 Bolton InstituteDept. Of Computing and Electronics – Dept. Of Computing and Electronics – MIA ModuleMIA Module

Lecture 12: Release and Post Release Management

Damien Markey


Lecture 12: Summary

• Planning for delivery• Launch and promotion• Handover of site

– Responsibility– Warranty– Post- launch control


Delivery

• You have built and tested the site• What to handover and when?• Depends on who handing over to

– Is the site to be managed by an internal team or by an external maintenance team?

– If CD/DVD, is it going to be updated (and how)?

• Not the end goal of the project (but the beginning of the end)


Delivery Packets

• Common elements of delivery are– Production Style guide– Handoff packet/Gold CD– Reviewing and Archiving documentation– Post mortem meeting– Schedule maintenance training for

maintenance team


The Need for a Production Style Guide

• If the designers who built the site are not going to maintain it then there is a risk of the design “drifting”

• After a period of time new designer's may alter the look and feel

• They may also which to change common elements (navigation buttons, titles etc)

• To prevent drifting but allow flexibility a production style guide is completed


The Production Style Guide

• Common elements of a production style guide are:– Sample graphics for the site (including

layers and additional code)– Structure for Title tags

• Include the section and company name or is it made only relevant to page?

– Naming and filing convention for images• All images in one folder or global images

stored separately?


The Production Style Guide - 2

• CSS specifications– Naming convention

• Folder set up – Naming and structure

• Commented code• Case naming of files and code• Absolute and relative linking

– Where and why



• Common/shared code – JavaScript, CGI scripts etc

• Database description• Template definition

– What and where templates are used– Description of content and code for each

• Site structure– Where all files are– Where all files are placed during upkeep



• Page descriptions– Page outlines– Typography– Size and colour of

text– Navigation

• Description and any complex coding

– Forms

– Menus• Description of

where and which menus used

– Any additional information such as Meta tags

• Legal information– Usage rights for media– Licensing issues


Handoff Packet/Gold CD

• This is the final deliverable of the site • It contains all the content used to create the site and

comprises the following:– All graphics in pre-authored format– Fonts used (or where they can be bought)– Image on usage rights/copyright– All HTML pages, templates, CCS and code– Design guide for maintenance team– Technical specifications of the site– Populated site folder structure


Documentation

• Gather all relevant documentation that shows their progress and change to your project

• This includes– The original proposal– Creative Brief, User, Competitor and Client

Analysis– Usability testing results (if performed)– Additional Charge/Change request forms– Any correspondence which displays client

approval of changes


Documentation cont.

– Project Plans (all versions)– Look and feel designs– Printouts of designs through the design

and build– Printouts of information architecture and

site structure throughout production– The style guide

• When a client gets sent the final bill they may not remember everything they asked for!


Post Release/Maintenance Training

• No site, by it’s nature, is finished• Majority of users prefer a site with good

content that is constantly updated (e.g. bbc.co.uk)

• To avoid design drift (and your well designed site falling apart during update) regularly train the maintenance team

• Work through the production style guide with the maintenance team

• Have refresher courses at agreed intervals


Launch the site

• Going live may be quick but should not be rushed

• Good planning will minimise risks but some are unavoidable/hard to predict:– Some issues may not become apparent

until the site is live e.g. Firewall issues• Before go live

– Prepare the audience– Prepare to inform a new audience– Prepare the live site, through soft launch


Prepare the Audience

• Lots of people do not like change (even if it improves things)

• Inform the current audience that the site is going to be overhauled months in advance

• If possible offer a “taster” of the new site before going live

• People may have book marked pages that no longer exist– Provide informative “Page not found”

pages that inform and guide the user


Prepare to Inform a New Audience

• No site will be redesigned without wanting to improve the success of the site

• That will usually include more visitors• Advertising the site will increase user visits

– This can be done online or offline• Offline can be print, poster, TV etc• Online can include links from other sites

or site that appeal to the same target audience as your site


Prepare to Inform a New Audience - 2

• Online advertising example– If you are a mortgage bank you may want

to put banners on an estate agency site• Ensure that the marketing for the site does

not drive the launch date• If the marketing starts the day you go live

then people may visit a site that has unforeseen problems

• Provide an appropriate pause for live testing


Prepare the Site

• A soft launch provides an opportunity to launch the site without an increase in demand

• Launch during off peak hours, to minimise locking out current users– Off peak hours vary depending on the site but are

usually between midnight and 6am• The site can then be tested and any transition bugs

found and hopefully addressed• Have a holding page whilst the site is being updated• Have a regression plan to return to the original site if

there are major errors


The Launch

• All production should have been halted after final testing

• Copy all the packaged Gold CD files to the main server

• Any databases or separate application servers should already be running in the appropriate location

• Perform agreed final QA testing on live server (if you have not been able to do so already)


Warranty and Post Release

• Small scale bugs will occur so agree a warranty period and cost with the client at the start of the project

• Warranties usually cover any errors found in first 30 days of the site going live

• Anything after that is chargeable (unless the site falls over completely due to your coding!)

• Have definite sign off and handover to the client


Warranty and Post Release

• Once the site is live and maintained by someone else they could cause problems

• State and agree responsibilities, and handover dates for them, for all deliverables

• Ensure that the maintenance team document their work

• Ensure they stick to the Production style guidelines

• Send the invoice and wait for the money!• Review the work you have done


Post Mortem Meeting

• With the site live, documentation and production style guide finished you will have a good overall impression of the project

• Now is the time to review your work and the project• A meeting to find out where any problems occurred

and how to avoid or overcome them next time should happen

• Any process improvements made from the project should be highlighted

• This is not a “finger pointing” or “boasting” session! Be objective

copyright © 2002 bolton institute dept. of computing and electronics – mia module lecture 12:...

Documents