The Analytics Tipping Point
The world of analytics never stops. It is constantly moving and evolving. Even the most successful analytics programs will eventually reach an inflection point whereby end user demand outstrips near-term capacity. It is always better to be proactive and prepare for this increased demand rather than let it sneak up and catch you off guard.
What should you do when you feel your organization is approaching this tipping point?
Whether you are going down the road of an in-house build or relying heavily on partners, it is essential to keep the theme of constant adaptation top-of-mind. Steve Jobs once said, “If you don't cannibalize yourself, someone else will." This highlights the danger of approaching analytics with an unbending certitude instead of recognizing the need for flexibility. A strong, adaptive analytics program does not just satisfy the current cadre of analysts; instead, it opens new doors for them. Even more importantly, it creates net new end-users, or at least business units that want to be new stakeholders. With new users come new use cases, demand for more and better data, new ways to leverage data, and new methods that may not have been anticipated initially.
It is not easy to be willing to change the processes that extract, transform and load data, data model, semantic layer or end-user UX layer. Willingness to continually adapt requires rigor and governance, and also open mindedness to facilitate creative dialogue around past decisions that do not fit nicely into traditional development life cycle processes. The simplest solution is to move the conversation from “Can we do it” to “How best to do it.” Once this subtle shift in thinking is internalized, it becomes much easier for the team to embrace change and adapt.
What are the other important considerations to keep in mind when establishing an adaptive analytics program?
If you are relying heavily on partners or looking for a comprehensive ‘buy’ strategy, think about how adaptable your partners and/or platform can be. Discuss how use cases that diverge dramatically from the current or initial domain would be supported. Consider hypotheticals around new business units coming on board, M&A situations or major changes in regulations.
In-house build-outs allow for more control. However, asking internal teams these same questions can ultimately lead to a better end product.
Commit to manageable iterations. The key here is to break from a mindset that the initial deployment–whether it is a new data domain or just a new reporting method– has to be perfect. Instead, put something out there as a first step and then build on it. Two benefits arise from a commitment to iterations: 1) results come faster and more regularly while reducing risk; and 2) your user community is trained to expect these iterations. This last point cannot be underscored enough as it sets a cadence and offers relief when managing a long-term roadmap.
The third point, and possibly the most important, involves gaining velocity by multi-threading iterations. This means being able to run two or more iterations in tandem. The more iterations that are moving at any given time, the better you can now address more demand points simultaneously. With a mix of large and small effort iterations, this can turn into a fairly complex process. Easing into it, preferably with the help of a dedicated project manager, is recommended.
The closer business stakeholders work with the technical team, the greater the chances of success. Only when business and technical staff are dedicated and embedded together–thru direct or functional reporting–can you start to generate velocity. Having business staff dedicated to the analytics program while also developing technical knowledge that allows them to be directly conversant with their more technical counterparts can be hugely beneficial. Taking this approach, driven by the need to continually adapt to increasing demand, yields not only more velocity but also a growth-oriented workplace that benefits everyone.