Demystifying Interactive Process [Part I:Introduction]

When you want to build something that will live in the Interactive space (internet, web, mobile media, web 2.0, social networking, etc.) there’s a set of basic steps you need to follow in order to complete the project. Those steps have been culled from what’s called the SDLC, or Software[Systems] Development Life Cycle, a pattern which has been used in software and network systems development for years prior to the adoption of the same basic principles within the arena of commercial Interactive projects.

There are many variations available out there and in many cases the actual steps of the process will be determined entirely by the specific needs of the kinds of projects you’re building, but in general you can render down the SDLC as it applies to the Interactive space by considering a model called “The 5D’s”, even though it’s got two M’s in the very end.

The 5D’s Interactive Process

The phases of the so-called 5D process break down as follows:

  1. Discovery (exploring want vs. need, could vs. should)
  2. Definition (setting expectations through uber-specific documentation)
  3. Design (planning the architecture of information, experience, AND traditional visual Creative)
  4. Development (putting the plans to work, coding the behaviors)
  5. Deployment (getting it from Development environment to Live)
  6. Measurement (tracking metrics and analyzing them against success benchmarks)
  7. Maintenance (updating, upgrading, and minor edits to existing functionality and content)

Note well that there are actually 7 steps, and more than just the letter ‘D’ used to describe them. But it started with just the 5D’s, and got Measurement and Maintenance thrown in as logical followup steps to acknowledge the fact that interactive projects require more effort beyond ‘Deployment/Launch/Go Live’ to consider the project successfully completed. [Props where props are due, the two additional ‘M’ steps were added on the recommendation of the inimitable Elisa Carson, a very wise and savvy Interactive Producer I had the pleasure of working with at a past job.]

In the series of articles I have planned, I’ll be looking into the 5D process day by day and outlining some of the basic items which need to happen at each stage, as well as what kinds of professionals will be involved in the team as each phase happens.

A Resource for All Clients and Interactive Professionals

There’s a certain class of Interactive Professionals who are employed in specifically designed Interactive shops which eat, live, and breathe the 5D’s or some other house-grown variation on the SDLC. This won’t be of any use to those privileged few, the proud, the lucky… but what about the rest of the world who may or may not be involved in Interactive builds for very much of their job duties? What about the poor administrative assistant who ends up doing all the coordination work to help her too-busy-to-learn boss keep the new website project going? Suddenly “Web Master” duties are getting farmed out to already overworked corporate professionals. And what about small businesses operating outside of the ‘professional Interactive space’ who want to utilize the internet to help them make money, but are frankly put off by the Technobabble that usually accompanies such endeavors?

This series of posts is aimed intentionally at a broad audience. As such, we’ll be looking at this from a high level of general steps. Each house, each developer, each studio, and certainly every Interactive Producer has their own specific process which has developed to help them build the things they build for the clients they work with. But I dare say that the overall phases of the process outlined here should be present in more or less this order for every Interactive job that gets developed. It streamlines things, it manages expectations, and it includes all of the “best practices” of the overall industry.

Follow along as we go over the basics for the next week or so here at Internet Kerfluffle, and hopefully this will help get everyone using the same words, with the same expectations, for the same steps.

Special Case: Those Familiar With Print Process

As a former graphic designer with over a decade of experience in the Creative and Production realms for ‘traditional media’ (e.g. Print, or ‘offline’ media), my first exposure to Interactive was working as an Interactive Producer in an otherwise-completely Print-based agency. The results were disastrous as expectations went kerplewie and project budgets immediately either ran overboard big-time, or else clients were unhappy with their results, 9 times out of 10. It was that experience that led me to find my training in grad school for a Masters of Interactive Communications from Quinnipiac University (detailed on Graduate Interactive Communications, my grad school blog for those who want to poke around a bit into my experiences there).

While I was studying full time on nights and weekends in the professionally-based MS program all about understanding the business of the Internet, I moved to another job with another historically print-based marketing and promotions agency, where I would frequently get into shouting matches with my coworkers on the Account side because of the impossible things they were expecting as a matter of course. The experience took some getting used to, but by the time that layoffs came for the entire department  I had learned some very important things about the difference between the Print process that all of the agencies in Connecticut and their clients were used to, and the Interactive process.

I can boil down the main difference as follows.

  • In the world of Print, there is great flexibility in the process of developing materials. Once the materials are launched, however, the results are fixed and cannot be changed, only re-done from the beginning at great expense.
  • In the world of Interactive, there really is NO flexibility in the process of developing the project. Yet once the project is launched, you have a lot of flexibility over minor changes and updates.

Before my colleagues jump on me, let me explain what I mean by ‘NO flexibility in the [Interactive] process’.  Obviously, when looked at entirely by itself, there’s always going to be some measure of flexibility to any process. But when you compare it to Print, you can begin to get a better sense for what I mean.

Print Emphasizes Form, Interactive Emphasizes Function

In the world of Print, you have a date by which the materials need to be in the market, and you have your printer telling you how long they need the files in advance of that date in order to make it to market.  There is no question in Print what the final product does. It displays, wherever it is put with whatever gimmick it’s got to make the target audience look at it, and consider doing what it tells you to do. (Drink more Ovaltine™!) Up until the date that the Printer needs those final files, and sometimes even a bit after that, the Client and the Creatives and the entire project team can change every single thing about that project — what it’s going to look like, which products will be featured, what the headlines say, where the Call to Action message is, what color the background will be, etc.

Once it’s printed, though, those particular posters, or newspaper ads, or billboards, etc…. they exist. They’re done. You can throw them away and print new ones, but you can’t really change what you’ve already done. You have to start over again with different files and print whole new different posters.

Thus, PRINT = Flexible Process, Fixed Result.

In the world of Interactive, things are quite a bit different. Opposite, really. In order to determine the date that you’re going to be able to get Interactive projects into the marketplace (e.g. Launch/Go Live date) you need to count -forward-, not backward. And what you are counting forward from is nothing less than a completely detailed and 100% specific definition of EXACTLY what it is that you will be building in the interactive space, and more importantly, what it’s going to have to be able to do. You can change the process, but EVERY decision you postpone until ‘later’ in the process creates higher and higher risk that the entire project will derail, run late, or become VERY expensive, VERY quickly (and needlessly).

The reason for the difference is that in Print, the end result is a Thing that gets provided by someone else. That Thing already exists. Everyone knows what it does. It provides a surface to hold the Creative being Printed. In Interactive, you are building a miniature piece of software. If all you want is something to hold the Creative being Printed, then you’re in luck because those are the easiest kinds to build. But once you want to actually take advantage of the bells and whistles, the interactivity and responsive behaviors that online information software like web sites have to offer, well then you’re going to have to be very specific extremely early on in the process.

Unlike the world of Print, in Interactive there’s no such thing as successfully starting a project without knowing exactly what you’re going to end up with when the project is done.  In reality, in the world of Interactive, what you are ‘launching’ is not the message, it’s the medium itself. Once a web site is up and functioning as planned, you can go back into the exact same project and update things… so long as it doesn’t “break” the functionality or the overall organization built into the site when it was developed. You have a lot more control over the basic parts of the project even after launch. But before you can even begin to work, you really need to know exactly what it is you’re going to do for the end product.

Therefore, INTERACTIVE = Fixed Process, Flexible Results.

What That Means For You

In a nutshell? It means that for any Interactive Project, the more specific you can be about things the earlier in the process, the more likely it is your project will be successful (which is defined by all Interactive Producers as ‘on Scope, on time, on [budget] target’. The more that you leave things open (and woe to you if you Interactive agency allows you to leave things open for long beyond the Discovery phase) the more likely it is that you will run into endless Change of Scope updates, budgetary overruns, and timing delays.

If you or the boss you work for is thinking, “We need to launch Project X in six months, we can just start the Agency working now and we’ll finalize plans in the next month or so,” that is a huge red flag of danger. If you want to save the day for the entire project, right then and there say the following:

“Let’s check with the agency and see if we have room in the schedule for a 2-month Discovery phase.”

Really, it’s that simple to avert disaster. To see why, check out Part II where we’ll discuss what a ‘Discovery’ phase is, and why they will save time and money in the long run.


5 Responses to “Demystifying Interactive Process [Part I:Introduction]”

  1. Helen Says:

    Nice Post, i like the article in your blog…
    i will visit this blog more often…
    Nice info in there…

    specially about
    Demystifying Interactive Process [Part I:Introduction]


  2. Alex Halavais Says:

    Hmm. This has me worried. Not even a nod to agile processes?

  3. Adam Pacio Says:

    Nope. I write what I know from my professional life and right now there’s nobody wanting Agile interactive development in the Agency world I’ve been swimming in. It doesn’t even come up as a viable option.

    But then, there’s a larger gap in general project planning skills than there should be in the industry right now… skilled digital producers and PMs are in short supply and lack some essential skills… like putting together a comprehensive project plan.

    There’s always a bit of a gap between the academy and ubiquity. It’s hard to get buy-in out here on many things presented in the ICM program as given. Agile development would seem not to be making the transition from the coding houses to the communications houses… even in the shop where we did both software dev & web dev, Agile dev was pretty much ignored as unwieldy. Ironic, no?

  4. Adam Pacio Says:

    I said in my previous reply that I wrote what I knew, and no one was using agile processes in the digital agency world that I had seen.

    Well, I’m now proven wrong. I’m working on a new assignment for another Madison Avenue agency’s digital arm, and now I’m smack in the middle of a shop which utilizes Agile development processes. It’s too early for me to be critical right now. I’m trying to soak it in and learn the new way of operating, with mixed success so far but it’s only the first week. I’ll do a followup post to branch out to Agile after this assignment is done, along with my own assessment of the strengths and weaknesses (and my own within the new process).

    So far, it seems to be working. And it seems to be a large influence on an a-typical work culture. More later.

  5. Adam Pacio Says:

    Following up on Agile.

    I’ve been in this shop for 6 months now and everyone walks around talking about how we use Agile development here… but then we just do straight up webdev and typical PM scheduling. We don’t actually carry out much in the formal Agile process at all. I’ve asked several people to explain what it means to be Agile here, and all the answers are different, and only a few of them get in the same generalistic ballpark.

    All in all, what being “Agile” seems to mean here is that we don’t micromanage to the day on our schedules. If we say that there’s supposed to be an internal review of creative on May 9th, for example, then it’ll happen somewhere ‘around’ May 9th as long as there’s still flexibility in the project timing. It doesn’t refer to having a dedicated team, because we don’t. It doesn’t refer to an iterative development process, because we don’t use that either.

    It means that you are just as likely to hear someone in the office referring to “What are the deliverables for this Sprint” (Agile terminology) as you will hear them say, “What are the deliverables for this Phase?” (non-Agile dev).

    The Creative group works in iterations, but that has always been bracketed off as a sort of ‘Here be Dragons’ area which PMs don’t typically intrude upon. As in, my schedules all read “Creative Ideation” followed by a range of dates leading up to an Internal Review followed immediately after by a Client Review.

    So. Still no Agile development process. Although, this particular swan is doing it’s best to quack like that duck, it’s still not a duck.

    Agile is much more prevalent in software development companies, but what I’m finding in dealing with vendors is that even though the point of the software itself is communication, a software dev company isn’t structured to work like a communications-based agency. (Heck, any Jr. PM who’s built a project with even an in-house Tech/Dev/Production team knows -that-).

    One thing I will say… I should retitle this series ‘Demystifying the Web Development Process’, since there are several points where mobile builds, social media, and app builds depart significantly from the steps outlined here. Future projects for rainy days.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: