Production in a digital environment is one of those artforms that requires the perfect blend of a range of disciplines in order to achieve a successful outcome.  Designers will be pushing creativity to its limits, Flash developers will be integrating and animating any manner of permutations and combinations of graphical trickery and the systems guys will be tearing their hair out with development environment modifications, database migrations and remoting methods in order to make it all work.  Hitting the perfect combination of the disciplines can be a beautiful thing if all goes to plan...

If not, then it can be hell (and we've all been there).  By working in a digital agency environment, you don’t have the benefits of being a large multinational with PM processes that have been honed with 20 years of lessons learned.  To top it all off – every project is different.  You can’t leverage the fact that you’re implementing a finance or order tracking system for the 1700th time.  That's why you're a boutique digital agency: you do stuff that no-one else has done.  You're the go-to guy - and you need to do it more cost effectively, with higher quality, more innovation, and on brand.  All in less time. 

Find me a PM model that works.  Now!

How does one go about this effectively? If you search the world for project management models that you could apply neatly to such a situation, you won't find anything in the billion dollar corporates that will quite fit the bill (and unfortunately the billion dollar corporate drive PM methodology, so the small guy is always cutting a subset out of the large PM models to fit his or her own need).

At the other end of the perspective, build-fix approaches often get taken to the extreme in agency environments.  The true build/fix model (Microsoft) is a model that exists entirely within the developer’s environment.  The key distinction here is that the build/fix methodology is contained to within the developer’s environment: accurate specs for work packages are provided to developers, they build it in to the stream, then ‘fix’ on the fly as other specified functionality packages are rolled in.  Rinse, lather, repeat.  

This process, however, is abstracted from the specification process.  What happens in a lot of agency environments is the specification lines blur: build/fix is no longer contained between a signed off specification and the developer’s environment, but client changes get injected directly in to the process – resulting in mayhem from poorly specified work packages ending up directly in developer’s hands (I am a firm believer that the traditional SDLC must exist up until the spec stage – after that dev team management methodologies should always be a RAD, extreme or build/fix approach. But I digress.).

The solution

I take my lead on the solution to this age old dilemma from a passion of mine: Formula1 racing.  A quick overview...

Formula1 is currently the world’s third most watched sport – behind the Olympics and the World Cup.  There are 18 rounds in a year, averaging 850 million viewers per round.

A Formula1 car can go from zero to 160km/h back to zero in four seconds.  They have enough aerodynamic downforce to drive upside down in a tunnel, and have chassis’ that are capable of cornering at 4g’s (that’s a 35kg lateral load on your neck!). 80,000 components make up a standard F1 car.

F1 teams have budgets between $66 million (Scuderia Torro Rosso) and $400 million (McLaren Mercedes) per annum.

How to win

The equation to win is pretty simple, really: build the fastest car!

Building the fastest car is really about combining the three primary F1 disciplines together in to an end product, the car, in the most efficient and effective manner (and also so that not one of those 80,000 parts fail in a race – this means that a car with a 99.95% successful component QA will still have 400 suspect components!).  The three primary disciplines are:

• aero (aerodynamics, or the way air flows over the body surfaces of the car to create downforce, and therefore, grip)
• chassis (suspension and internal mechanics, to maximise grip through weight distribution and chassis dynamics)
• engine (go forward!)
  

The end equation here is that the winning team is always the team that best integrates all three aspects of F1 (aero, chassis and engine) in to the end product (the car).

The tenuous link

In digital agencies, the winner is always the team that best integrates the primary disciplines (flash, back end and design) in to the end product (the solution).
In F1, the best example of success is displayed by Ferrari: they are a team that run a leadership based management structure: they have a team principle backed up with three heads of the departments.  The team principle is sole purveyor of the snappy decisions required to get in front in the time poor, performance oriented world of F1 (much like the time poor world we, as digital agency folks, often experience).

The worst example in F1 has to undoubtedly be Toyota: in their history they have outlayed over $1.2 billion in to the sport, and never come near winning an F1 constructor’s championship (Ferrari have won all but two since ’99 with a budget consistently less than Toyota).  Why?  They copied the PM methodologies utilised in their boardrooms of Tokyo to their F1 team.  But what happened was that decisions couldn’t be made quickly, and the multiple departments, without a decision maker acting as a catalyst for encouraging fast and cooperative decisions between the disciplines, sent Toyota floundering in regards to opportunities for better integration and team work.

The outcome for digital

The outcome, then, is to encourage integration of the disciplines, whatever methodology.  If you’re producing a digital project, you need to focus on encouraging cross discipline communication through integration and innovation – because often the best design idea will come from the dotnet developer locked in the dungeon.

We don’t lock our dotnet developer’s away.  Really we don’t.