APA (the Advertising Producers Association) launched an interesting guide last month, the “IPA/APA Interactive Framework for Producing Interactive Projects in Advertising”. An interactive projects framework? I have always been fascinated by the standardization in non-digital work and the absence of it in the world of digital advertising projects.
What Is This Interactive Projects Framework About?
The press release says “it takes individuals through the entire process of producing interactive work from the initial brief to maintenance of the finished project.”
Also interesting is the fact that it “follows the pattern of the renowned 1987 Pliatsky recommendations on the production of TV commercials, which set the pattern and the paperwork for TV production not only in the UK, but across most of the English speaking world.”
Applying principles from TV production to software development? There are similarities (the advertising industry specific position of the client), but also big differences, first of all the much more unpredictable nature of interactive production.
Nevertheless I gave the document a good read, and came across some noteworthy aspects.
For Whom?
This document wants to provide a framework for advertising agencies working with 3rd party production partners. Nice to see the APA considers it a living document (iterative is always better) which will be updated regularly. It’s not aimed at the relationship between advertising agencies and their clients, although it heavily influences it.
Good
What I like about the framework? First of all it is very complete, but not exhaustive (chokingly) overcomplete. It mentions the minimum things without overdoing it. For example, the brief should mention at least a ballpark budget and the number of competitors in the pitch.
It’s also realistic. Including a complete discovery phase in a pitch proposal can be very time consuming (and costly) for a pitch candidate. The framework acknowledges this reality and sees discovery as something to be done after the budget is granted.
The importance of the SOW (Statement of Work) is also underlined. Too often projects are being started without any clear overview of what will be delivered at the end of the project. The SOW is an answer to this, and is also providing the opportunity to talk about scope and functionality as soon in the project as possible.
Good to see is the classification of Alpha, Beta and the Release Candidate and the need to show also alpha and beta to the client (which is too often not done).
The Continuum Between Agile and Traditional Approaches
However one element in the document felt a bit strange to me. The document sees only two possible production processes:
“it should be decided if production will follow the ‘fixed cost’ or ‘time and materials’ (agile) model.”
I believe reality is a bit more complex than this. Digital projects in advertising tend to live on a continuum somewhere between these to. A digital project will never be truly waterfall (opposed to a print campaign or a radio commercial). There are constantly things happening along the way that force as well the client as the agency to be flexible. That’s just the nature of software development, being unpredictable.
And that’s where agile entered the building, embracing this complexity.
But on the other hand, a fully agile project is not realistic in an agency/production partner relationship either. To work on a time/materials basis is something I have not yet seen in this industry, at least not for an advertising campaign related digital project (branded service design is something else). In reality most digital projects need a minimum scope definition upfront, because a client is not willing to put the money on the table when he doesn’t know what bang he’s getting for the buck. That’s just the reality.
Bottom line is that you cannot do full fledged agile by the book on a digital advertising project. The guys at agencyagile have this nice article on why agile estimating by the book doesn’t work in advertising.
They nicely summarize it as follows:
Agile estimating does work for agencies today, but mostly in environments that have more constancy like with product development teams and AOR-style teams that have built trust and rapport with the client. Adapting Agile estimation to less-constant work like new clients and new projects can be challenging, but worthwhile with a some adjustments in both expectations and practice. Ultimately, you’ll want to push the whole process upstream – this will be a bit painful at first, but better-booked projects, better resource estimates and happier teams follow pretty quickly.
So Is This Interactive Projects Framework Worth Looking At?
Yes. Putting aside my rather picky remarks about the grey zone between agile and waterfall where you’ll probably operate in agencies, this document contains all important phases, milestones and practices.
