What I like about this process is how closely it ties each step together. The ultimate output of a strategy is a budget, and in an enterprise, your always fighting for some larger piece of the pie. That makes it imperative that your budget build a tight bridge between what you’re asking for and what you’re promising to deliver.
Heaven knows that budget processes are usually anything but rational. On the national political stage, such processes are visibly risible. But it’s not always much better in large private enterprise. Naturally, everybody wants more money and everyone thinks they have good reasons for it. In the world of analytics and measurement, it isn’t easy to prove your case. We may sometimes benefit (and I for one thank the stars) from the trendiness of “big data” and “analytics”, but we suffer constantly from the perception that investment in measurement produces a “soft” return and that we are a discipline that has consistently over-promised and under-delivered.
To no little extent, we deserve that perception. As I commented last week, doing measurement that matters is far less common than it ought to be.
By closing the loop between what you’re asking for and what you will deliver (and how that delivery will help optimize the digital channel), you can forestall many of the common enterprise concerns. You’ll also be delivering a budget and a strategy that are not only much more transparent and tightly connected than is common in digital analytics, you’ll be delivering something that is better than 99% of the budget requests Senior Managers see. Creating a tight linkage between real strategic thinking and tactical budget requests just isn’t the norm.
Fortunately, once we’ve gotten to this step in the process, we have almost everything we need already in place. We have the current state (Assessment), desired state (Model), the project plans (Data Science Roadmap), and the resourcing requirements by project. All that’s really needed now is a prioritization of the project plans.
Not that prioritization is an easy exercise.
I think it’s best handled in two steps. Recall that we broke up each of the steps into system components. So, for example, the business model, data science plan and data integration strategy are all grouped within systems:
By tackling a system at at time, you can reduce the number of projects to a more manageable and understandable level:
This slide summarizes a powerful story. It describes the analysts necessary to tackle the measurement within the Conversion System. It explains what those analysts are committed to producing (and when they’ll produce it) and it shows the technology tools necessary for their tasks. In conjunction with the Data Science Roadmap and the Business Model, it tells a complete story: what you want to accomplish, how you’ll do it, and the resources necessary to get the job done.
This is also a powerful antidote to corporate Pollyanna thinking of the sort that goes along with having 3 people on your measurement team while you talk about building a world class analytics program. Digital programs need to be able to show what it means to do the job right (the Model), how they plan to do it (the Roadmap), and the resources necessary for that.
If, for example, you want the basic site analytics to optimize conversion (Topology, Use Cases, and Funnel Analysis) done in the first half of 2013, you need two analysts devoted to these projects. Cut an analyst, and you know exactly what you’ll lose. Fund another analyst, you know exactly what you’ll get.
To me, that’s the essence of good planning, good budgeting, and good strategy.