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 staging.nike.com vs. something up at Nike.com… 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.

Demystifying the Interactive Process [Part V: Development]

This is the stage of a typical Interactive/Software Development Lifecycle where the rubber meets the road. By this point in the process the Strategist has assisted the client in identifying specific desires and establishing metrics for them (Part II: Discovery). There is a formal Scope of Work, Estimate, and Project Plan made (Part III: Definition). The Information Architect has established the basic structure of the interactive experience and the Creatives have stepped up to translate the wireframes into key visual comps or designs (Part IV: Design).

Now it just has to be built. Piece of cake, right?

Yes, But…

Development is going to be one of the more difficult phases for the average Project Manager to wrap their head around when it comes to making plans, scheduling, and performing schedule adjustments once the project is underway. This is due 100% to a communication barrier, a veritable chasm which splits any agency into two distinct groups: those who code, and those who do not.

The language barrier is a simple one, and very easy to overcome once the PM is aware of the dynamic involved. The simple fact of the matter is that a coder speaks a language which requires an exacting level of precision and accuracy, a level of precision and accuracy which is typically misunderstood and completely unappreciated by non-coders. Ironically, earlier in this series I focused on how Project Managers typically feel frustrated because *we* tend to use language very specifically as compared to everyone else on our team, and yet it’s the exact same dynamic which can result in a developer agreeing that yes, doing things this way is certainly -possible-. In software development, really, given sufficient resources, time, and expertise, most anything is ‘possible’. This is why it’s very important that PMs on any sort of interactive team need to cultivate a relationship with the folks in development, and they need to take an active interest in learning as much about the big picture of what’s going on inside the Development process.

The Development Process

I’m an outsider to the development world myself, so allow me to present the extremely broad strokes for what Development actually entails. First, the Developers are going to want some sort of an official hand-off once the project is ready to move into Development. Coders tend to appreciate linear and specific instructions. So provide them with linear and specific instructions, or else turn the Development Hand-Off meeting into a time when you can work with the Developers to jot down the outline of their linear and specific instructions.

In an ideal world, the Business Analyst or the Information Architect has already generated Functional Specifications to go along with the Wireframes. These two documents together provide the best starting point for any Development team because those documents contain the specific plans that the Client has already approved.  The Developer can now check the Func Specs instead of trying to translate the PM’s response to questions about what the Client wants. The Developer can look at the overall effects being called for in the Wireframes or Use Case Scenarios (“on rollover, display X from Wireframe 3.2.12”).

Once the Developers think they understand what’s being asked (note the relative wiggle room in this statement), they will then begin to apply their own brand of planning and execution to things. It will start with the Developer opening up the code and “taking a look under the hood”. There’s more than one way to write code for most complex tasks, to the point that several coders make the case that writing code is a form of literature unto its own. It communicates the mental state of the original coder.  That’s why, unless the development team is building from scratch (and even then they should be repurposing code structures from other successful house projects, not reinventing the wheel) it’s always possible that the Development team will return quickly with bad news… “The project’s going to take a lot more work than I thought.”  Why didn’t they flag this earlier? They hadn’t opened up the code until then.

First build it, then break it

Then the coders get to work. This is where the Keebler Magic happens. The coders will begin a staring match with their computer screen and alternate between lots of clickety-tappety, lots of frownity-glare-ity, and random bouts of cursety-swearity. (Those are technical terms. Don’t believe me? Watch a coder at work.) First they’ll build the code. Then they’ll do everything they can to try and break it. Once things have gotten to the point that the Developers get bored with breaking the code, they’ll declare it done and turn things over to the QA process. Anything that happens beyond this point will always and unfailingly be someone else’s fault. Doesn’t matter who the coder is. It just sort of comes with the territory.

All along while the actual coding is going on, the Design is also likely being put together to work in an interactive environment. As Development nears a close, any of the heavy-lifting that the back-end developers are doing will eventually be married to the front-end Design-heavy coding that Production Artists are doing. Adjustments are made until it all synchs up right, hopefully on schedule.

QA, you say?

At this point Quality Assurance will take over. The project will most likely be put up in some Staging environment (which means it’s NOT the place where the project will ultimately find a home). Staging environments are usually password protected, but sometimes protected by the complete lack of interest that anyone has in half-baked projects anonymously posted without any advertising or push for visitors to get there. In smaller shops, QA is handled by a coder who didn’t actually code the thing. In larger shops, QA is a separate career specialist who focuses on finding as many mistakes as they can.

QA will then try to interact with the project on a variety of different computers, different browser versions, and different communications platforms (like Mobile) when appropriate. The QA person will look at the Func Specs, Wireframes, and Use Case Scenarios and check to make certain that everything works right and looks right. Their job is to find all the errors possible BEFORE the client takes a look at what might be a broken program or page.

Quality Assurance is actually one of the steps in the process which fits equally well in both Development and Deployment. I personally favor putting QA at the end of Development, because QA is handled internally. If there are any errors to be found of sufficient intensity, then after QA is done the project will return to the Developer to fix or update things as needed. It’s only once QA signs off on the project, or once the Developer has made all of the fixes and overruled the QA process that Development truly ends.

What to Expect As a Client

If you are working with a team for the first couple of times, you can expect there to be some bit of learning curve to happen in the Development phase. This is a difficult phase for the Client side of the house because while the Developers are happily clickety-clackety-ing you won’t see anything, or hear anything, or be given anything to sign off on. UNLESS there’s a change to the scope, or unless the developers got knee-deep in someone else’s code and discover a huge problem that couldn’t be foreseen otherwise, no news is good news but the wait can be uncomfortable for clients used to more of a micromanagement style.

This is the part which can be frustrating for another reason, too. A more subtle force is at work here, and that’s the fact that Coding is much more an exercise in Creativity than it looks like from the outside. There’s often a couple ways to accomplish the same intermediate steps, but putting them together one way will empower more robust use of those features and functions at the end, while combining them in code a different way could actually PREVENT the development of more complex features down the road. Because of this variability in coding methods and informational structures, coding can be a very personal matter. In larger development houses there will be a House Coding Style and standard which the shop is expected to follow. In smaller development shops, it’s up to the individual developers.

Pregnancy Trap

Because of this, you run into what I call the ‘pregnancy trap’. The old office chestnut goes like this. “It takes a woman 9 months to bear a child, but if I give you 8 other women does that mean I can have the kid in 1 month?” The pregnancy trap. Certain efforts need to be assigned to a single person, or a dedicated team that works on things from start to finish. If you’re working on a ‘pregnant’ task then adding more people won’t make the process go any faster. Some things in life just take as long as they take, and they can’t be hurried by throwing more money or more resources at it. Developing, more often than not, is exactly like that. (Except when it isn’t… building a trust-based relationship with coding teams can make all the difference. Until client, PM, and developers trust each other, or at least learn to trust the PM, this phase will produce round after round of unexpected troubles.)

Obviously, trust becomes a huge factor here. Since Developers are usually kept far away from the Client in many organizations, you’re going to need to trust your Project Manager. One thing that you can do to alleviate stress in long-term development cycle projects is to ask the PM to set up periodic checkpoints WITHIN the Development phase. They don’t have to be client reviews, but just times when the PM estimates that different pieces of coding will be done. From there, the PM can simply review where the project actually -is- during the Development phase without trying to coax the Developers from their keyboards.

Once Development is done, User Acceptance Testing — the part of the project where the Client gets to try everything out — will begin, and UAT is where I mark the formal start of the next stage…. Deployment.