Field Notes Inside an Integrated Communications Agency

project

  • How Web Agencies Select Clients

    I was recently asked by a close client contact, "How does Capstrat determine which Web projects to do and which not to do?"  She wondered why we pursued some with vigor and turned down or passed on so many other projects.

    I told her it was one part reputation, two parts politics, one part economics and a thousand parts experience.

    As far as reputation is concerned, we want to do work that matters. We want to feel great about making HTML products that create value for people and help communities. We want the world to know that we want this. We also want to do work that is exciting and cool--work that makes other potential clients notice us.

    In terms of politics, we are a relatively big (88 FTE's) independent firm in the southeast and have alot of big clients. Because we are an integrated firm, it follows if we are doing crisis or reputation management, we are also likely doing interactive and advertising or marketing of some sort. To me it’s all storytelling. Another perspective sees it more about relationships than politics. This is an important piece. We like to work with people who understand projects worth doing are worth sharing risk. To that end, we work with people that trust we can measure and mitigate project risk. It generally takes a good relationship dynamic to make a good project succeed. Client is just as important as agency. Clients tolerant of candid discussions about doing what it takes to succeed are clients we value.

    Last, it is about economics. We want to do work that wont break us financially. Believe me, there are many projects on which we take a bath because it is a relationship investment or a cause we are willing to support. But mostly, we do work for clients that understand and value the price of a deliberate and considerate strategy.

    So, here is one approach we take on the Web team to help us figure out how to spend our resources:

    Client Challenge or Problem

    What is it?

    What’s causing it?

    Are there unstated problems hiding behind their stated problems?

    What business benefits will they gain by solving these problems?

    Is this problem worth solving?

    How does this project relate to the company’s current top priorities?

    Our Solution

    What form ought it take? (components, timeframe, $, etc)

    Why do we feel this is the best solution for the client?

    What other options (competitors) are they considering?

    What additional information do we need to do an estimate / proposal?

    Urgency

    When do they need the solution live?

    What is driving the date?

    Is the client team on the same page regarding vision, scope, urgency and ownership?

    Access

    Who are the decision makers? Do we have access? Will they trust our ideas?

    Who owns the vision for this project? Who is the person driving this day-to-day?

    What is the decision process?

    What are the decision criteria?

    Expectations

    What do they think it will cost to solve their problem?

    How long do they think it will take?

    What resource commitments are they willing to make?

    Have these expectations been set internally?

    Are the client’s expectations in line with ours?

    If not, what’s our plan to calibrate expectations?

    Money

    Is this a funded project? If yes, how much?

    Whose budget will this come out of?

    If not, how do projects get funded? How can we help?

    Are there unanticipated potential revenue streams we can help tap?

    Are there creative budget sharing ideas to follow?
  • Speed up speed up…wooooow way too fast. The modern day Interactive tortoise and the hare. What projects are better?

    Our project timelines run the gambit. I haven't been able to nail down what is better, so fast you can't keep track or so slow that you can't remember when the project actually started. They both have pros and cons and in the end it is hard to tell what is just right.

    Recently a few projects have come in that moved so fast we couldn't apply our standard process (whole other post) and although it's not ideal there are some positives. You move so fast that no one has time to over think and overspend, but it does leave room for late nights and missing things. Missing things doesn't mean they get swept under the rug, it means really late nights with multiple people working on a project...and a then a blown budget. But they aren't all bad, if you get a good scope document and everyone involved from the get go, it can run really smoothly. Enough budget and resources can make anything run smooth, even if the schedule is start to finish 2 weeks.

    On the other side of the spectrum I have had a few that run slower than molasses in January. They seem like a dream, and that's exactly what they are. Things move so slow in snippets of time it is hard to remember what happened from week to week. The possibility of knowledge transfer becoming fuzzy is high and team turnover can happen. The group that kicked the project off might not have the bandwidth in 4 months time when things come around to them and in some cases might not be around anymore. However, if you have your original team and manage not to procrastinate you can execute some well strategized thoughts without

    Timelines are like organic chemistry and each property, structure and reaction changes the compound. I don't know what the perfect timeline is. But if I had to guess it is anywhere from 1 week to 1 year.