According to IDC Research, worldwide spending for big data and analytics will hit $187 billion in 2019. And from IDG, within the CIO Tech Poll, data and analytics are expected to have the greatest organizational impact [out of all applications] over the next three to five years.
Companies are investing in analytics, and to get the most out of their investments, they use strategy to pull it together.
What an Analytics strategy is and how to define one
An analytics strategy identifies a set of business, organizational, or functional goals for what you want to accomplish with analytics, and follows with aligning stakeholders to those goals. Alignment means buy-in and agreement, and sets expectations around what each stakeholder’s role is for ensuring success of the program.
Beyond goal setting and stakeholder alignment, the next step in strategy is to define how you will decompose the goals into a set of implementable metrics and how you will deliver these metrics within a technical program across a timeline. You can fill in this step by answering four questions on the who, why, what, and how of your program. The answers will define the backbone of your overall strategy, and from strategy, you define an integrated program and the projects that will deliver it.
The who of your strategy defines the intended audience for the analytics program. The who is any unit, function, or group of users that require insight for the data you have or can acquire.
An example of a function are teams within HR, like recruiting, compensation, or benefits. If increasing productivity is a main strategic goal of your organization and if analytics will support that strategic goal, this would translate as increasing productivity of new hires by ensuring they have access to company knowledge and tools to do their jobs. This objective requires an analysis of hiring cycles to ensure training and onboarding programs align to recruiting and hire efforts. The who is this case are HR analysts, recruiting managers, and training program managers, as well as IT support and helpdesk (for technology onboarding), and any other teams that have a hand in the overall onboarding process.
Roles. Within each of the functions you define as the who are user roles, such as analyst, manager, director. Defining user roles helps clarify the level of data detail the user will consume, which is useful when you get to the what and how components of the strategy, i.e., what data you will analyze and how it will be collected, aggregated, and visualized for the user.
If you are defining an enterprise or sub-enterprise strategy, the who may be multiple groups of users across functions, or a team of executives that oversee multiple functions. An example of this is an executive scorecard, which has a target audience of C-level executives, whose purview spans multiple functions within an organization.
Defining the who is also input for the way in which you will deploy the analytical solution and how you will drive and measure adoption of it. Power users, analysts, and more technically trained users need less application-level abstraction and less adoption efforts. More business focused users may need more training, more application abstraction, and more pushes toward adoption efforts, all of which you should consider in the overall strategy, because adoption scale can lengthen the development cycle.
If the who defines organizational function and/or user groups, the why defines why they need analytics in the context of their user role. This step is closely aligned to decomposing the program goals that I wrote about in the earlier part of this article.
Using the earlier example of HR analytics, if an organization’s goal is to increase productivity, this applies to new hires to ensure they are as productive as possible in their new jobs. Aggregating data around projected recruiting and hiring cycles (what time of year, how many new hires, and in which departmental area) will drive training programs and onboarding efforts. Aligning these two HR functions helps ensure expedient onboarding and training, and the analytics support this alignment.
At a strategic level, it is not necessary to dive into specifics of detailed metric definitions, you will perform that process during requirements definition. The goal at the strategic level is to provide over-arching definition that you will decompose at the program and project levels.
In my experience, the why is the hardest of the four questions to answer, because it requires a large amount of discussion, negotiation, and agreement by stakeholders about what they are measuring and how it drives the strategic goals of the organization. Because defining the why drives the what and how, which are the two largest components of the strategy (and most expensive to develop), you should not undercut the investment of time to get this right.
The what answers questions about the data, including:
- What data you will use in the analysis
- Where you will source it from
- How you will integrate it
- What level of granularity you need
- What volume of history you need
- What aggregations and metric definitions you need
The what is inextricably linked to the why. What data you are analyzing and why drives how you will transform the data and whether you will apply scientific models, like machine learning or predictive models.
The what is also a perfect place to overlay data strategy to provide a superset of governing principles around the data, such as security requirements, access requirements, and history requirements.
The how is the technological meat of the program and defines the technical methodology that will transform data into insight consumed by end users. The how includes technological platforms, application and data integration, data transformation, and query and visualization layers. The how can also specify whether you intend to deploy a self-service user model and through what means users will access the analytics, such as through web, mobile, email, message, chatbot, embedded form, or through some other means.
The how is also the place where you can introduce specific technology approaches, such as database and computing platforms, query and visualization tools, and whether you are considering building vs. buying technology.
At a strategic level, it is not necessary to identify all the technological and process details, the intent is to demonstrate a direction of thinking or organizational thought process around what the future of your analytics technology platform will be and how you will deliver it and support it for users. This can also be driven by over-arching technology principles your organization practices, such as building vs buying, or only using cloud computing vs. onsite.
Throughout the process of defining the who, why, what, and how, you should use a method for prioritizing the answers to these questions, because you won’t be able deliver everything out of the gate. Prioritization enables you to define short, mid, and long-term objectives and deliver them in a phased approach.
After defining the backbone of the strategy that answers the who, why, what, and how, the next step on your analytics journey is to define an integrated technical program for how you will deliver on all the moving parts. The program provides a strategic view for end-to-end delivery and decomposes the view into one or more phased delivery projects. Each delivery project has a discrete output, where the output is a unique component within the overall program.
Delivery projects organized using an agile methodology enable you to practice iterative development and execution, which means deliverables can be re-prioritized based on fluctuating environmental circumstances, and can be decomposed into development cycles of 2 to 4 weeks.
Where to go from here
With a strategy defined and a program outlined, you are ready to start using the processes, people, and technologies that will deliver the goals of the program over your target timeframe. Program delivery requires a range of people resources, including program manager(s), project managers, business and systems analysts, solution architects, data engineers, application developers, visualization experts, testers, trainers, and documentation specialists. You can use in-house resources or you can work with a consulting company for specialized resources to augment your current staffing for short-term purpose.
However you staff your program delivery, your strategy becomes your guiding document throughout the process, and provides the roadmap for your analytics applications that deliver business value, that are sustainable and supportable, and that your users want and like to use.