Introducing Analytics Starts with Speeding up Proof of Concept (POC)

Creating a proof of concept for a new technology implementation should be a straightforward exercise for most CIOs and IT buyers, but it doesn’t always work out that way. Take advanced analytics applications, for example.

For some reason, every proof of concept (POC) seems to take on a life of its own. Each proposed use case requires a lengthy research process to vet the technology, leading to heated discussions between the affected user groups, resulting in inevitable disagreements about the different technology requirements and project priorities.

Sorting through these overlapping concerns can cause extensive delays leading to a dreaded deadlocked state known as POC analysis paralysis. Then, to speed up the POC approval process, many buyers end up making poor purchasing decisions – often trying to make one tool do too many things, occasionally due to in-house politics, and sometimes a combination of both – which the buyers later inevitably regret. It can become a vicious cycle.

The Same Old Problem

A scenario our team often encounters unfolds something like the following:

One IT buyer knows the technology requirements a specific user group needs. But someone from another department has a separate set of requirements based on differing priorities. By the time five to ten user groups weigh in with their different viewpoints, many months will have passed before the organization reaches a final consensus. And as the final decision is made, some new product release is introduced sending folks scrambling back to the drawing board to come up with a new proposal.

POC analysis paralysis is an enormous waste of staff time and effort. The pace of change for technology product releases is just too rapid these days. Gone is the era when a new data appliance or software application would have an annual release date. Nowadays, new products and solutions are continually iterated, improved, and brought to market with new features, often within months or even weeks.

Because the IT playing field is constantly shifting, there simply is not enough time to dwell on every purchasing decision for months. If you’re looking to introduce analytics into your company, you need to start sooner rather than later. In this ever changing climate, a sound strategy we recommend is to choose the best fit at the time, because the business must continually evolve to keep pace with market competition.

Here is where tensions arise between the IT and business sides of an organization. In working with our clients, the business side generally wants to move much faster than the IT side. Line of business executives may request a new tool for data preparation or data visualization, knowing there is some budget available for such a purchase. But the IT team is constrained by its need to adhere to technology standards and processes within the IT infrastructure.  The inherent complexity takes time for IT to analyze and resolve which results in frustration for the fast-moving line-of-business executives.

Pushing Past the Pain of Paralysis to Introduce Analytics

Our recommended approach is to address one POC at a time for each implementation, and not get caught up in thinking through how the technology may affect the whole enterprise. Businesses often harm their own best interest by seeking one solution to many problems. Building a diverse toolkit that can be supplemented by newer emerging technologies over time enables a business to maintain consistent advancement and competitive advantage.

For instance, it may make sense to adopt traditional business intelligence tools from vendors such as Cognos, Business Objects, or Oracle BI. Big data visualization tools can come from the likes of Tableau, Microstrategy, or Zoomdata. Makers of statistical analysis tools include SPSS and SAS Institute, while powerful machine learning is available from Google TensorFlow and IBM Watson.

The point here is no single tool can solve every problem. And the right tool is needed by your user groups and departments to do the right job. On the other hand, it’s important to rationalize IT spending to limit any functional overlaps or redundancies in product sets.

Try to narrow the scope for POCs by focusing on single departments. Sales and marketing teams may need customer analytics, while the finance group needs real-time data analysis along with some rear-view financial modeling. Buy a handful of licenses and test each product in the real world. Give it to the core users in their daily work for six months to understand what the tool can help your users achieve.

If another tool is needed in 12-18 months, perhaps the original tool can be traded out to be used by another work group. In this way, the organization can become more productive in a shorter timeframe, rather than dragging out lengthy POCs in which users are only “playing” with the toolsets, rather than using them regularly in the workplace.

In the end, the IT team needs to promote agility to drive the business forward, while business leaders need to respect the restrictions governing IT policies. IT needs to think more about the business use case before them, rather than obsessing over the rationalization problem in-order to help the business be agile and timely.

A business cannot successfully innovate by choosing one new tool every five years- such a practice is ultimately a path to competitive disaster. Embracing new technologies that can make a big impact on bottom-line outcomes right away is a much better strategy.

Remember, the data itself is never intelligent – people need a platform to extract intelligence from all those terabytes and petabytes of information. The ultimate end should be to ensure that each functional user can make the best use of his or her data to make better, faster, and wiser business decisions.

Click here for more on advanced analytics and big data!

If you enjoyed this article and want to receive more valuable industry content like this, click here to sign up for our digital newsletters!