Agile approach to digital production

From Stndrd_wiki

This approach works in some situations depending on the client and team, but here's a thought starter / tangent about how to approach Digital Production within Creative / Strategic agencies:

Preface: This is something I've been thinking about and have implemented in certain ways with some of our current clients. This is kind of a tangent and requires tons of refinement, but I wanted to get my thoughts out there and get some feedback.

Ok, here we go.

Taking an "agile" approach to digital production.

Agile is used in web development as a way to keep projects moving when the end product is not well defined or needs to be flexible and responsive to discovery of new issue / opportunities. (http://en.wikipedia.org/wiki/Agile_software_development) I think some aspects of the agile approach can be applied to creative development as well.

The way to take a more "agile" approach to creative initiatives is to ... and I know this is a scary thought ... involve the client in the process from ideation, to design, to development and present this involvement as something that can be "fun" and make the project better and more collaborative. I'll present this idea based on how it affects Scope, Timing, and Budget.

SCOPE

The first thing that needs to acknowledged for this to work is that the scope of the project needs to be flexible. If you take a look at the "Digital Production Process" outlined in the Stndrd_ Wiki, you'll notice 4 stages in the process. In general I agree with these stages as a good framework for approaching digital production, but there are some things I'd add. In this agile approach, the Discovery and Exploration phases are still very important. This is where you spend a lot of time with the client getting to understand what the requirements of the project and their business are. This includes business, technical and creative requirements. Combining these requirements with the "idea" will lead you to a scope that is as well defined as possible at this point. However its important to acknowledge that this is still a rough idea and to not get hung up on the things that don't have requirements or require more information to determine, these are the things that will get worked out through the process of production and should be looked at as opportunities for further discovery.

TIMING

Traditionally, projects are estimated by taking a guess at how many hours each resource will spend on a project (beyond fixed out of pocket costs). This creates a number of problems.

1) Account managers want people to estimate their hours as low as possible so they can sell the project through.

2) Department managers want all their employees to track as many hours as possible to show how valuable their department is to the company and that no hours are being wasted on playing ping pong and what not.

3) Employees are motivated to either add as many hours as possible to a project if they have "room" or to track no time against projects if those projects are over their estimated hours.

4) Lets be honest, people are terrible at tracking their actual hours.

5) Project managers are motivated to keep the number of reviews and people attending those reviews to a minimum because ...

6) Clients feel like every phone call is costing them $1000 because the creative director, designer, developer, production artists, and PM are on the call at $150/hour.

The way around this may be to create estimates based on duration and the percentage of resources available during that time for each phase of a project. For example, for a design project the estimate might look like this:

Total Project duration = 4 weeks The Creative Director will spend 10% of their time on this project during the 4 weeks, the Designer will spend 50% and the Project manager will spend 25% at a blended rate of $150 / hour.

Creative Director = (4 weeks X 40 hours) X 10% = $2,400

Designer = (4 weeks X 40 hours) X 50% = $12,000

Project Manager = (4 weeks X 40 hours) X 25% = $6,000

Total Budget = $20,400

• Side note, if a resource has been slotted to work on projects that exceed 100% (probably more like 130%) of their total available time, then they are potentially going to be super busy and unhappy, depending on the projects I guess.

This is nice because it allows people to think in general terms, ie."Have I been spending way too much time on this project?" And worry less about the hours they are spending, ie. "Did I spend 1 hour and 20 minutes working on that email or 1 hour and 15 minutes?"

Its also nice because people can worry less about who they are inviting to brainstorms and reviews and how often reviews happen, which leads me to my next point / idea...

Check-ins: Don't specify a number of reviews / revisions allowed for each phase of the project. That makes you look closed instead of collaborative and inflexible as opposed to collaborative. Instead, set a duration for each phase of a project and include as many check-ins as required during that duration. Depending on the duration for each phase, check-ins could be daily, bi-weekly, or weekly. Don't wait more than 1 week between check-ins. If too much progress is made during a week, new ideas / requirements that may have come up during the week may become difficult to include the following week and may derail progress. (this is why more frequent check-ins may be better).

Check-ins don't need to take a long time. They should include a list of items that were discussed at the last check-in, their progress to date, and what items will be done by the next check-in. This is also an opportunity to call out any potential budget or timing concerns (this is sometimes referred to as the daily "Scrum" in agile development). Discussions and decisions during these check-ins should be recorded and available for everyone on the team (including the client). Using basecamp or Google docs to share these documents is nice because they can be easily referred back to when you need to point at why certain decisions were made and when.

Finally, creating project plans and estimates by duration is nice for tracking overages and change orders. If the phase takes longer than the agreed duration you have an opportunity to evaluate the why and potentially ask for more time or money. If the client has been in all the check-ins, a scope increase shouldn't come as a surprise. If increasing the timeline or the budget is not an option, you can reduce the scope and prioritize work.

BUDGET

This may be obvious, but people want to get paid for the work they do. Often partners are asked to provide estimates for their work that are not seen as estimates, but fixed bids. I suggest that estimates should be just that, an estimate for how much the project will costs based on what is currently known and those budgets should be tracked and revisited often during production. Here is how I would approach a budget...ideally.

Following the "Exploration" stage of the Digital Production Process, provide an estimate for all costs with a 10-20% over / under built in. Make it clear to the client that costs should fall within this range, and this is what should be budgeted for. Not only does this cover your costs if things go a bit over, it motivates the client to be efficient with their feedback and "contribution" to the idea. This estimate should included fixed costs you know won't change as well as estimated costs.

During the "Consolidation" phase you will further define the scope of the project by creating wireframes, developing designs, creating prototypes, etc. At this point the development partner should know enough about the scope to provide an accurate proposal for costs, either as a fixed price or time & materials. That said, all these costs need to be continuously tracked and revised through out the project during the check-ins. If something took longer to develop, the client will know within a week...at the latest.

Admittedly this "Agile" process will only work if the client is willing to move forward with some unknowns and is willing to be a participant in the process. It will also only work if the agency team is willing to work collaboratively as well and are ok with their ideas evolving. That said, I think this is how modern digital agencies should work. If you have a canned process and project plan at the ready to solve a clients problem then your idea is probably all ready out of date. With the speed at which technology changes our business we have to be willing to be more agile, more flexible and we should help our clients do the same. It will almost always improve their business as well.

OK, that is all. Please feel free to tear this apart.

Thanks

David