What Kind of Management Structure Is Needed to Govern a Data Analytics Program?

By Dennis D. McDonald

Introduction

When thinking about developing a new data analytics program, two questions you need to address are:

1. What services do you need to provide?
2. To whom do you need to provide these services?

I’m assuming here that your organization already provides products or services of some sort and that, through a new or enhanced data analytics program, you want to take advantage of the data associated with these products or services. Also, if you’re like many other organizations, the processes and systems that support your existing products and services may be run somewhat independently.

Partly as a result of this, the data associated with these processes and systems may need to be organized and managed somewhat differently from what you’re doing now.

This is especially true when your organization has been around a long time or has grown by acquiring other companies. Even if a comprehensive manufacturing or financial system underpins much of your organization, you probably also have a variety of specialized systems supporting individual operations that may need to be handled (i.e., “governed”) differently in order to gain maximum value from improved analytics.

An initial focus on management requirements

Which gets us back to (1) what services does your data analytics program need to provide, and (2) who are the customers for these services?

Answering these questions has implications both for the technology used for data management and for the manner in which you structure and manage the business processes associated with improved analytics.

While I believe you have to do both of these things I’m going to focus here on the second question. I’m fairly “old-school” when it comes to planning and building information systems. That is, first you decide what your requirements are and what services you need to provide, then you decide which technologies you need to adapt, develop, or purchase to help you meet those requirements.

Basic management questions

Here are some questions to ask to help you determine the management requirements for your new data analytics program:

1. Do you need to support users both inside and outside your organization?
2. Do you need to support users with a range of analytical sophistication, i.e., “Help me find and interpret the data!” versus “Just give me the file!”
3. Do you need to manage and potentially standardize data from a variety of sources and formats?
4. Do you need to support both day to day decision-making as well as longer term planning and strategy?

Once you start to answer these, how do you decide on the type of organizational structure and staffing you’ll need? The answer will depend to some extent on the level of maturity or sophistication your organization already has with respect to managing data and making it useful. This involves determining your staff’s basic analytical skills and how comfortable they are with crunching numbers and interpreting the results.

It also involves the possible need to add skills and tools. For example, analyzing and interpreting unstructured data requires a different skill set and tools from “standard” structured or financial data. The same goes if there’s a need to organize and manage real-time or sensor-based data on top of existing service call, customer, or transaction data.

Back office and user facing services

Another important consideration will be the need to balance when the service organization must take the lead on analysis-supporting and infrastructure activities, and when it must respond to requests generated by its target users. These are sometimes referred to as “back office” and “user facing” services.

“Back office” activities might include building and maintaining data and other resources in advance of need. They might include: developing or purchasing a variety of tools that need to be learned and customized; building and updating specialized data warehouses or repositories; and, transforming, formatting, or standardizing data for use in a variety of systems.

How all these processes integrate with your organization’s existing systems and processes – and with the people who manage these processes — must be addressed — and the sooner the better.

Basic service functions

“User facing” services may need to accommodate different types of requests involving:

1. Communicating with various users about their needs.
2. Developing simple (or complex) profiles of these requirements.
3. Deciding what resources will be needed to satisfy the requirements.
4. Managing and tracking the work that needs to be done.
5. Following up when the deliverable is turned over.

As suggested earlier, some users will be satisfied with file downloads, APIs, and well-documented clean data. Others will need more support of a developmental or analytical nature along with consulting or technical assistance.

It is quite possible that the same organization may need to provide both types of services. So, what kind of organizational structure will make sense given a likely diversity of requirements?

Potential organizational models

Several possible models come to mind, each of which might contribute something to your own organization:

1. An IT department that supports various enterprise functions and systems (including the development and/or support for specialized tools).
2. A project management organization (PMO) that provides management and administration support to multiple projects at various points in their life cycles.
3. A customer service or call center that methodically intakes, processes, and satisfies the data analytics needs of a diverse and changing user population.
4. A collaborative and potentially research-oriented organization that actively engages both in data analytics and supports the collaboration and sharing of data with other researchers.

An important question raised by the fourth alternative is the degree to which the data and its analysis will be “open” and shared with other organizations and users.

Are you building a resource that will focus primarily on data and analytics that are primarily to benefit the sponsoring organization? An examples of this might be an analysis operation associated with liability insurance and the services associated with it. Data analytics in such an environment might appropriately be viewed as competitively focused and therefore confidential and not to be shared. Services could be focused on key enterprise decisions and functions such as risk analysis, pricing, product development, and market research, functions that are typically not conducted “out in the open.”

An alternative approach would be represented by NCI’s Genetic Data Commons which, at first glance, looks like a “traditional” open data portal with a search function, file downloads, and APIs. Looking closer, though, you see a complex operation that embeds itself within research processes performed by many different institutions. It provides support for data sharing for cancer research and the people and institutions involved. The goal is to support open research via data sharing, not just journal article publishing.

Conclusion

The point here is that a data analytics organization doesn’t just crunch numbers and build predictive models and visualizations. It’s an opportunity to manage data as a resource in a way that potentially must cross traditional organizational boundaries if it’s to be successful.

As suggested above, there are a variety of models the organization can follow with an initial design being driven by which users and uses cases will be targeted, how much support (and of what kind) will need to be provided, how the data to be analyzed will be gathered and managed, and the extent to which the organization’s processes and deliverables will be open or shared.

Copyright (c) 2016 by Dennis D. McDonald.