I’ve been itching to respond to this post - let’s hope my enthusiasm results in something useful and not just a bunch of strident drivel.
The dynamic described in “two parts to every analytics project” is present in nearly every project, or equivalently, nearly every project is at its core an analytics project. Even something like weight loss can be considered an analytics project. First you figure out what needs to be done to lose weight and to manage your progress (including buying diet books, exercise equipment, special food/supplements, etc.), then it’s actually executing on the approach.
A main part of my job is to advise clients that are pursuing large technical projects on how to be successful. The two-part dynamic always comes up, and what I tell people is “tools are hard, but they are the easy part.” There are a lot of reasons that this dynamic exists in so many areas:
Internal org factors:
- People tend to want to continue to do what has rewarded them in the past
- Doing new things involves making mistakes, which does not feel good compared to doing things the old way without making mistakes
- If metrics and incentives have not changed, people who embrace the change can easily be punished compared to those who continue to excel at what is being measured and rewarded
- Peers don’t tend to update their patterns of what they reward and punish, so new behaviors often get punished by lower reputation, ridicule, or even shunning
External org factors:
- It’s much easier to sell a tool or a book or plan for a fixed project to implement technology than it is to achieve changed results
- It’s much easier to train an inexpensive resource to execute a rote approach to installing a tool or implementing a fixed method than to get someone with sufficient experience to help navigate implementing a change so it achieves the desired customer results
- External orgs can’t control many of the factors that make or break their customer’s success, so if they base their success criteria on whether the customer is successful on their terms, they will be perceived as failing more often and suffer the consequences of that perception.
These are all the reasons for the data leader’s observation about what is required for change. It’s back to carrots and sticks - either there is enough incentive for people to push through the above drawbacks to achieve the change (which there almost never is at scale), or the consequences of not doing so must be severe enough to overcome these factors. Those consequences can only come from a senior leader if the goal is change across the entire organization.
This is why one of the keys to becoming more data driven (or making any successful change, for that matter) is to select a scope small enough to where there is either enough desire to make change, or enough ability to impose consequences. Value-focused, incremental change, with a short enough duration to not get derailed by unexpected disruptions and to allow for learning about what really propels us towards our goals, and what does not.
Once we find something that works, then we can advertise that success and use that to build momentum for bigger efforts. Success changes the dynamics of all the internal factors above. If team A is now outperforming team B because of a change, team B is going to start to fear falling behind and become motivated to start changing themselves. Team A members now have a higher reputation, which causes them to be sought out by others. Success and commitment creates a higher tolerance for mistakes, which improves the learning cycle.
To sum up, I’ll be surprised if you find any counterexamples of large-scale change through other dynamics, but I’d be very keen to be proven wrong as we would all benefit from having more ways to be successful than what I have found so far.