New Media Development – What’s The Problem?

(This essary was originally written in December 2003)

Very few people involved in new media production have experienced an easy ride through any but the simplest of projects. Most people reading this will be in one of two camps: those that have been struck by the lack of “process” applied, and blame the failures they encounter on this, and those that have been struck by the complexity a web project presents, but cope as best they can and don’t see any magic bullets to do anything about it.It’s clear that boom notwithstanding, the making of websites and other Internet-based systems with which people interact are going to become increasingly important. I know you’ve heard something like that before a thousand times, but I mean it. It’s going to be big: bigger than radio, bigger than film, bigger perhaps than TV or print media are now. I believe the above polarisation in the management of the web development process reflects a phase in the evolution of the industry that needs to be addressed for the sake of the people working in it as well as for those using its services.Before we begin, however, let’s expand on the above “two tribes” thesis a bit more.

For the sake of convenience, let’s focus first on web sites as opposed to interactive TV, mobile or some other media. Most people regard the web as a form of media. A loose broadcaster/audience model exists for most web sites and people think of it as a medium to be consumed like print, or sometimes television, only with a back channel (if the “publisher” permits it). But should one look to that traditional media for clues as to how best to go about making a web site? Some people think so.There are parallels with traditional media, particularly with print and magazine publishing, but how far do these go? One common battleground is page layout: the art of graphic design has its tradition in print publishing, and without heavy modification, putting a page designed for an A4 magazine on the web is going to involve some pretty unsafe assumptions. So how far should a graphic designer or sub-editor be expected to understand the technologies that will render their design for the end user? What if the designer presents their design to the client before anyone knows if their ideas are even possible to achieve? Similarly with developers: they are enablers of ideas just like typesetters or sound engineers, but if they’re treated like that there will be problems. So how far do they need to be involved in the creative process?

Low-level technological details have high-level effects on team dynamics. These affect what should happen when, and alter the responsibilities people should have along the way. The imperatives of the creative process need to be balanced against those of function and budget. Throw in issues of intellectual property rights, content management, accessibility, security and brand values and you have a real quagmire that varies widely between projects. But perhaps clarity will come. How long did it take the film industry to solidify the roles of production coordinator, set director, or gaffer, for instance?

From another point of view, websites are basically software and their graphic design can mask complex function. So perhaps it’s better to abandon attempts to mine traditional media or marketing services production and accept that making web sites is sufficiently difficult an activity to be led by a software development method, like RUP, DSDM or XP? After all, any endeavour that involves more than a few people constructing something needs a plan – so why not look to methods that set out to manage complexity?

Arguing against project management would seem perverse, but it’s often too easy to “project manage” at the expense of successfully managing the project. For example, it’s not a good idea for some people on a team to adopt a way of working that the rest don’t understand, or produce documents that don’t get read; communicate things people don’t need to know, or communicate them in a manner they have difficulty understanding. That this often happens when “methodologies” are applied to new media projects (and even when they aren’t!) reflects the fact that these methods come from a different world. Budgets are smaller for web sites than for flow control systems or enterprise management suites. Web sites have development lifecycles (and even shelf lives) measured in months, not years. There’s just not enough money or time to construct object models from domain analyses and go through multiple iterations of functional prototypes while documenting the system with UML. Most structured methods can scale down, but only on their own terms – which usually means they can handle a team of ten (not including graphic designers, account managers, execs, external project managers and journalists) as opposed to one hundred and ten. But at that small scale the method is usually so skeletal it’s just common sense (make a plan, stick to it, test and review).

Websites aren’t all about function either – they’re often just as much about form and non-functional requirements that traditional software doesn’t need to deal with nearly so much. “Look and feel” on a website is an order magnitude more important than that of a desktop application. That recognition needs to be built into the production process from the start. It doesn’t help that web sites are often regarded (if not actually used) as a form of media or infotainment, not as tools to do a job of work.

Perhaps most significantly, however, is the fact that people involved in making web sites usually don’t come from software development backgrounds. Things like business analysis, regression testing or configuration management aren’t part of their worlds. But perhaps they will be eventually? After all, the first people to design cars were blacksmiths, not boat builders or architects. Whoever seems the closest match at the time starts the ball rolling.

So today, people tasked with new media production have tended to adopt a light, though highly inconsistent, project management approach with techniques and teams loosely based on print media, while perhaps taking a leaf or two from TV and advertising. The role of “Producer” to describe a technical project manager reflects the dynamic between the artistic and mechanical aspects this role is expected to have. Agencies “pitch,” they don’t usually tender; if someone asks about interaction design or usability, a graphic designer steps forward, and there’s usually nobody with the title of Business (or System) Analyst in the building. Documentation is light and tends to focus on business case rather than detailed function; operating contracts and statements of work (where there are any at all) take a back seat to “building relationships” with the client (not the “customer”).

In short, new media culture is pretty much right-brained. Members of a team working on a web site typically rely on meetings, “contact reports,” each other’s memory and a variable understanding of each other’s roles to keep on top of what needs to happen when. This would be fine if everyone involved was experienced enough to understand the overall process, risks and project phases they were passing through. But in new media they aren’t, and that’s a big problem.

This means that the first issue with new media production in its current state is that it doesn’t scale. There comes a point when enough people are involved, with enough ideas that need to be worked out, that the right-brained approach breaks down. And that point is often surprisingly soon in the life of many web projects. Unfortunately, as outlined above, attempting to apply a recognised structured method doesn’t help much either.

So the symptoms are familiar enough: misunderstandings, late delivery (or at least late working hours) and fancy footwork. The quality of the end product suffers because good ideas can’t be executed well enough, and the effects are confused users, failure to meet success criteria and a general feeling that web sites are somehow of their nature unreliable and promise more than they can deliver.

Over to You

Unlike other people who write about these things, I don’t have any prescription to remedy this situation (although I am keen on a few pills and potions…). It may be that there is a specific failure on behalf of one or more individuals in the production process to understand some underlying principles, produce effective documentation, communicate in the right way or conduct proper research. But for each argument there is a counter-argument – so how about it reader? There’s a link at the bottom of this page to comment. Give it a go.