Demystifying the Interactive Process [Part VI – Deployment]

By this stage the development is done, the code is married to the front-end designs and the internal team has had their chance to crawl around inside the guts of the interactive piece to break it before the Client or worse, the end users break it themselves. Once the internal team has had their chance to check their own work, the work gets turned over to the Client. At that point, we’re out of Development and moving directly into Deployment.

Although you might be tempted to dismiss Deployment as a ‘simple’ or ‘easy’ part of the process (‘just wrapping things up’), Deployment is perhaps the most busy time in any interactive project, with the most amount of ‘rushes’, ’emergencies’, and ‘fire drills’ happening. Do yourselves a favor… don’t schedule Launches of major interactive projects unless you can devote a good 80% of your attention to the Launch on the day it happens, and 40% on the day after it happened. For this reason alone, unless there’s a specific market driver to the date, never schedule a launch on a Friday or before a weekend. You -want- there to be staff in the agency’s office 24- to 48- hours after any major launches. Launch on a Friday and you’ll be stuck waiting for tech support til Monday morning (or paying for overtime).

User Acceptance Testing/UAT

Deployment kicks off with a phase known as User Acceptance Testing, or UAT. This is the time when the project, typically in a staging server environment (e.g. it doesn’t live where it’s going to be served up to the public, yet. Like Nike developing a site redesign on vs. something up at… just making up theoretical examples here). Everything is built and “done” from the initial round of creation’s standpoint. The project itself should exist and work in its final state, with only content tweaks and minor facade-level changes being made per Client requests. If you hit UAT and end up making architectural- or structural-level changes to the site that you didn’t plan for originally, then raise the red flag and get ready to move back into Development, or even Definition phase.

What to expect from UAT as a Client

During UAT, the Client is given the link to the project on the staging environment, and then they are given a set amount of time to find anything wrong or to break the site. At this stage of the game, what you as a Client -should- be doing is navigating to your project link from as many different computers, on as many different platforms as possible. You should be creating test scenarios and walking through sample interaction points to test and make sure the database is working properly, or to get a real sense of any problems that a typical user will encounter. What almost always happens, though, is the Client representatives give a good proofreading of the site and send back feedback which is aimed at how the site -looks- more than how the site -functions-.

At the very least, you as a Client should open up the Functional Specifications document which was created back in Definition, as well as the Wireframes document, and you should go page by page trying to do all of the actions and activities in the Func Specs, Use Cases, and Wireframes. Note any area where what was promised in the documents doesn’t work as promised in the project, and bring those areas up with your Producer. Either there were decisions which were made between the Func Specs and UAT which didn’t get updated in the Func Specs for timing reasons, or else there’s going to need to be a proper explanation why something promised from a functionality point of view is not being delivered as per agreed-upon expectations.

When all looks good and matches the written documentation or has been explained to satisfaction, the Client submits a formal approval to the agency and pulls the trigger on the rest of the Launch process.  If the web site is particularly large or involves complicated functionality, you might have a Formal Site Walkthrough meeting where the Agency walks the Client team through the website one, last time. At the end of Formal Site Walkthrough and any fixes that come about from it, the Client signals approval, and we move forward to the actual Launch process itself.

Code & Content Freeze, then Launch

Once the Client has approved the final project, the Agency developing it should issue a formal Code and Content Freeze. This is the point beyond which no changes will happen to the project until after the project is live. You need to freeze the coding and content revision process because part of what it means to have ‘flexible results’ within the Interactive Process is that coders and designers and content creators could and will tweak things to death unless you give them a point at which it’s hands off before launch.  What are they changing? Adding documentation, adjusting layouts, adding content, tweaking presentation of content, small tiny things that can be done at any time once the site is live.

Next will come the Launch process itself. Typically, the more complicated projects involve a series of coordinated steps where the new server space is created for the project, the hardware is set up, the files are transferred over, the DNS registry is updated, and finally, the site goes live.  To track all of the moving pieces and infrastructure-level sysadmin tasks, good Producers will generate a formal Launch Plan document and review it with both the internal team as well as the client team to present a checklist of launch steps.

Other projects will be so simple and straightforward that all you need to do is copy the files to the new, live server, or turn on the DNS registry changes and you’re done. Every project is different. If Agency or Client begins to feel iffy on the steps involved in the Launch, it takes about an hour to draw up a Launch Plan and circulate it for approvals. Don’t be afraid to ask for one, it’s one of the many services an Interactive Producer will provide.

The Post-Launch Scramble

It always happens. The site is perfect, every team member who ever heard the name of this project or went to school with one of the other team member’s children or siblings signs off on every document ever created… the project goes live…. and suddenly the CEO on the Client side is looking at this gem of an accomplishment that the Client team put together, and clicks on a broken link. The ONE broken link that escaped Inspectors 1-12 is the ONE link that the CEO clicks, gets an error message.

The Client Team goes into immediate panic mode and contacts the Agency team with a note of stern rebuke and strained panic in their voice to inquire, nay, demand to know why this one link wasn’t caught! Yes, it’s horrible that it happens and everyone takes great pains to ensure that everything works, but I have to tell you, these things just happen from time to time, and it’s always the Client Team’s high ranking supervisors who happen to find them.

This is why, as an Agency, the Launch is the busiest period of time. There’s going to be something wrong. You just hope it’s cosmetic (“You misspelled Smythe on page 2.4.12, second paragraph”) instead of structural (“We were supposed to put the Mission Statement in both About Us and Contact Us, but it only appears in About Us right now”)  or worse, catastrophic (“The password login screen brought me to the last user’s shopping cart, complete with credit card information populating all the fields”).  Knowing that no matter how vigilant the QA and UAT process is that there’s just going to be -something- that needs to be fixed or which doesn’t work -as expected-, as an Agency you need to ensure that there are dedicated resources on your team who are ready to drop everything else they’re doing to immediately tackle any unforeseen problems that crop up STAT so that the newly launched site gets rid of any hiccups -before- the general public notices them.

Once the project has launched and it’s out there, live, on the net, with all the immediate bugs either fixed or in queue to be fixed, then Deployment has been achieved. You might be tempted to think that this marks the end of the Interactive Project Development Lifecycle, but you would be forgetting two of the most important steps of all which follows any launch:  Measurement, and Maintenance. We’ll talk about Measurement next in Part VII.