This is part of Insighter's Digest – an ongoing series from the minds at InsightOut. Follow us as members of our team offer new perspectives on the world of data and analytics straight from the source.
If you’re a business stakeholder (i.e. CFO, COO, VP of Analytics, etc.) currently sponsoring an analytics project, you’re well aware that these projects are incredibly complex, prone to error and/or failure. You likely don’t have the bandwidth to spend time and energy deciphering the technical updates from your team and may sometimes miss the red flags as a result.
Over 60% of the customers I have served have come from a failed prior implementation in analytics. In listening to them describe their experience – what went well and not so well – and reviewing their existing approach and documentation, I have observed a number of patterns.
With these projects, there are clear technical challenges that can also lead to problems, such as data quality and accessibility. However, there are problems that can arise that are completely within your control as a business stakeholder, which is the focus of this post. Having seen firsthand what works and what doesn’t over the course of my 15+ year career in this space, these are the commonalities that I’ve noticed are leading indicators of problems that you want to fix to ensure success.
Tech Talk over Business Talk
If you are hearing more discussion about technology than about the business, then you might be in trouble. On status calls, if you hear people debating which tools to use for an extended period of time, or focusing the conversation heavily on the tools they are using to visualize and aggregate the data rather than on the business challenges the analytics are supposed to support, there may be a few reasons for this:
- The technical team responsible for delivering the project may not understand the business and the outcomes the business is looking for from the analytics. If this is the case, they are going to defer to the things they know, which is technology.
- The technical team may just like technology (highly likely) and is not focusing on the business.
The technical team is there to serve the business, not the technology gods. Invite them to executive leadership meetings, and let them listen in on the challenges the business is facing. Ask them to state what the business is trying to achieve. If you don’t get a coherent answer, work with them to write it down and boil it down to three outcomes. Have those outcomes at the top of the agenda each time you meet. These projects can be complex, but we live in a world full of incredible tools that make it easier to achieve success.
Designs for Days
This one is easy. If you are designing dashboards or user interfaces to display the analytics and going through more than two iterations on those designs before developing them and getting the real thing in your hands, you might be in trouble. By iterations, I mean a session where you review the designs and request changes to the person who is designing them before meeting again to review those updated designs.
No matter how many iterations you do, once you actually have the real thing in your hands, you will want changes, which is good. So by designing iterations over and over again, there is a point of diminishing returns. Start with something very low-tech, like an Excel or Google Sheet and design the layout there, set an internal deadline to agree on the first designs within two weeks and then move into actual development.
Performance over Production
If you hear the technical team wanting to optimize for speed and performance of the analytics and dashboards before actually having access to them as a business user, you might be in trouble.
As an example, in one project I came into, the prior solution had been implemented using technology that was designed to support tera-bytes, but they were only needing to support a few thousand records of data. In this case, the solution still wasn’t in production. That’s an example of over-engineering for performance.
Optimization should come after, and all efforts should be focused on getting the first dashboard in the hands of the business users first. If there is a lot of historical data that is holding up the project, trim down the scope to only focus on a single year or quarter worth of data to review first. Much like the former point on designing, the goal should always be to get business users clicking buttons on an actual dashboard and against actual data as soon as possible.
Documentation over Distribution
This is an extension of the indicator above. If the technical team is talking about documentation, or is receiving requests to document the solution before actually getting the solution in the hands of the business users, you might be in trouble.
If they spend time documenting before rolling out the solution, the business users may still want significant changes to the existing solution. So their documentation could be recording wasted effort that isn’t actually what you end up with.
This is not to say documentation is not important, it certainly is and will become even more important as you move into support mode and distribute the dashboards to a larger audience. A great place to start is documenting the actual definitions and calculations of the individual metrics and making those definitions available to all users who are accessing the dashboards. That way, users can answer the question of ‘how is this calculated’ themselves and lighten the burden on the project team.
Resource Reallocation
If you have the following scenarios for resources on the technical team, you may be in trouble:
- A key resource is someone who has never delivered or worked on an analytics solution, but is considered a smart, capable resource. Even if they are, data analytics projects require a very unique skill set and the team involved should have prior experience. If not, you may end up with a solution…eventually, but it won’t be designed for future success or sustainability.
- A key resource is shared and splitting their time with other efforts. These projects require laser focus and the key individuals should be solely focused on only this one project.
If you are in the former situation, you may be able to get by with hiring an expert consultant to oversee the initial project build and then train the individuals internally on the best practices. This helps set a good foundation. If you are in the latter situation, you may need to adjust your expectations on the speed of progress.
In one scenario with a client, we discovered that it was a mix of both situations described above, where the company had hired an external resource who was splitting their time and also did not have data analytics experience specifically. The individual had a lot of technical knowledge and experience in developing real-time data pipelines and large scale infrastructure, but not focused within the data analytics realm specifically. Ultimately, when my team was hired, we had to double back on their efforts and make corrects in order to get the desired results.
In either case, it is best to have someone with experience who is singularly dedicated to building out the solution in the right way and in an efficient manner so as to generate buy-in and demonstrate meaningful progress.
Conclusion
Analytics projects have such a wide range of outcomes. On one end, it can be a completely wasted effort and sunk cost. On the other end, it can transform the way a business operates and become critical to success. With such a wide range, any correction to early red flags can dramatically move the odds of success in your favor.
If you find yourself in one or more of these pitfalls, correct one at a time. Communicate the importance of the effort, repeatedly, to the team and stakeholders. Reduce the scope and minimize the burden on the team involved to start making progress in smaller phases. Prioritize getting parts of the solutions live and in people’s hands and momentum will likely build from there. If parties object to these course corrections, be very wary and ask for justification. There might be circumstances that allow for these, but more often than not, I have found them to be very strong indicators that can keep you oriented towards the ultimate goal.
About the Author
Chad Rose is the CEO and Co-founder of InsightOut. With over 15 years of experience working with visionary executives, he is passionate about empowering organizations to realize the full potential of their data. Previously, he was the Director of Data Management at S&P Capital IQ, a leading financial information provider.