The Journey to Digital: Part 3, Insight Transformation
Companies have a choice today. They can be the disrupted or the disruptor. I made this case in Raiders of Every Industry: The Journey to Digital, Journey To Digital: Part 1, Table Stakes, and Journey to Digital: Part 2, Data Transformation.
In those previous posts, I laid out our perspective on what a true digital transformation requires. I introduced the need for automation in the form of machine learning in software and platforms, and described how I advise clients to build their data strategies as core data assets. In this post, I focus on the third phase: Data Science transformation.
Data Science Transformation
With the next stage, data science begins to lift off:
What needs to be done differently at this stage? This is about mapping out the decisions people make across the enterprise. You’ll use this full map of those decisions to create a backlog of decisions for your data science teams to tackle. Then to prioritize the backlog, you’ll assign a value to each decision, taking into account the likelihood and ease of implementation.
This phase is also about getting the entire organization to think about how to leverage data analytics to provide new insights, instead of using it to support preconceived notions.
Decisions vs Research Projects
Most organizations without mature data science programs hire data scientists and let them run amok. Okay, maybe not run amok, but often with no clear enterprise-wide strategy or prioritization of which projects to focus on.
Save yourself headaches by following some simple steps…
- Define the strategy
- Identify the decision classes
- Build the portfolio of decisions supporting #2
- Value each decision
- Prioritize each decision
- Execute
- Lather, rinse, repeat
Define the strategy:
I encourage clients to define an enterprise-wide strategy for data science just as they would with anything else, so that they tackle their tasks in a deliberate manner.
The effort starts at the top. The leadership of the organization needs to define the strategy of the decisions or at least anoint a small group of empowered senior leaders to define the strategy. Decide whether you need a Chief Data Officer. Decide whether you need a decentralized, centralized or federated/hub-and-spoke model for your data science teams. (Ultimately, you should aim for a federated/hub-and-spoke model, but getting there might be tough until you prove value or unless you have a clear mandate from the CEO.)
Identify the decision classes:
Theoretically, you can start this step while you’re still building the strategy. However, if you’re planning to bring on a Chief Data Officer or Chief Analytics Officer, give that person a significant say in how you structure the decision classes.
In any case, the classes should represent high-level decisions like Customer Retention, Supply Chain Optimization, Talent Retention, and Research Pipeline Optimization.
Build the team with senior leaders in the analytics organization as well as in each of the different parts of the businesses. Don’t take this step lightly. It has consequences for how you organize your data science teams into Agile squads or tribes each focused on a class of decisions. I’ve sometimes seen the organization of data science teams simply follow the structure of the larger organization, but that can leave money on the table since it can mean you’re overlooking the most valuable decisions: those that cross boundaries. But realistically, the existing structure of the organization is a good place to start if funding is aligned by function. You’ll only realize the true value over time, and we all know team structures are fluid at best in most enterprises.
Build the portfolio of decisions:
Once you’ve established the decision classes, start identifying the specific decisions people make. For each representative who worked to define the decision classes, ask them to go back to their own parts of the business and work with their leadership to identify the decisions they make.
At the same time, have leaders document how they make decisions today, what data (if any) they use to make those decisions, whether the data is of adequate quality, whether there’s adequate governance, and whether they already use a specific model. Additionally, ask them to assess whether the group who would ultimately consume a new model will actually use it. This last part is incredibly important. The best model in the world has no value if no one implements it.
Value each decision:
As with any investment that an enterprise makes, building a data science team should be measurable. A key metric is return on investment (ROI). And to truly assess ROI, you have to assess the value of each decision.
But more than that, knowing the value of each decision helps shift the conversation from the costs of data science to the benefits to the organization. Assess the value for each decision in partnership with the CFO or a designate so that you quantify decisions in a way that’s relevant to senior executives and to the CFO herself. Having this metric can help justify building the team and can help demonstrate the team’s longterm success (or failure). Remember that tracking the team will mean looking back after they deploy the models to continually assess whether you realized the intended value.
Prioritize each decision:
Once you have a portfolio of decisions and a sense of the value for each decision, it’s time to prioritize. You have a few options. You can simply start with the high-value decisions. You can start with the decisions that combine high value, easy implementation, and high chance of implementation — or any combination.
However, if you’re just getting started, consider focusing on high chance of implementation. Specifically, identify your best advocate and focus on decisions that support her organization. As I said above, models have no value if no one implements them.
Finally, recognize that your prioritization isn’t static. It should change over time based on the shifting priorities of the organization and based on the maturity of the data science program overall.
Execute:
With the portfolio of decisions prioritized and valued, start tacking the decisions themselves. Here, how you structured your data science program — centralized, decentralized, or hub-and-spoke — will dictate how you address the portfolio. A centralized program is the most straightforward; a single team runs down the list in priority order. For the other two team structures, the relationship of the decision to the value chain determines how to divide the portfolio among the various data science teams. With the hub-and-spoke model, an enterprise-wide team can take on decisions with low likelihood of success since those are the decisions most likely to cross multiple value chains.
Regardless of the structure, note that each decision will almost certainly need more than one model. The first step in tackling any decision is breaking it into component parts. These parts become the backlog for the data science teams themselves.
Lather, rinse, repeat:
Data science isn’t a static process. You’ll continually need to update and refresh the portfolio. Also plan to assess the priorities themselves, at least monthly or quarterly. And finally, regularly assess the actual value you’re creating compared to the value you anticipated. Without rigorous metrics that reveal the real vs forecasted value of the data science program, growing the program — or even sustaining it — could be a struggle.
