Thursday, April 10, 2014

Analytics Journey: A Rocky Road between IT and Business

More and more organizations are building their analytics strategy and doing their analytics projects, but the journey won’t be going smoothly. Analytics is business project, but it needs both engineering and management disciplines. How to build the relationship between IT functions and business lines with regards to analytics?
A huge rocky road between IT and the business groupsThe bottom line is all about accountability. The IT folks usually want to deliver a bunch of reports which are of marginal use and the business group won't take responsibility for what they requested or asked for in the first place. Or the biggest error that the business groups usually make is NOT holding people's feet to the fire by requiring the business users use what they spec out. If you just pass it on to some analysts, it rarely goes too far. And while technology is a great tool, it’s only as good as the people using the tools. On the other hand,  if your IT group is being compensated for checking off lines in a project management/ GANTT chart, then you get what you deserve. The bottom line is that it all about accountability, and last but not least, rewarding those who make the most out of the analytic solution. When the rewards go out for those who USE the data, attitudes change. Reward the analytics champions.

The focus on 'what' is being built vs. the 'why.' In some cases, it is almost as if someone wants to say a 'what' has been built, regardless of the 'why.' In the end, this always comes back to poor senior management and leadership. Although there are a lot of talking past each other or essentially using the same words with different meanings. Often the focus is on the "what" is being built and not the "why" is it being built. The process of building IT requirements focus on the "what", and not so much about the "why". If more time is spent on helping the IT teams understand the business problem, they could come up with a superior solution to what is specified in the technical requirements documents.

The trick is to have a master plan in-place that both business and IT agree on, so that as the ground up starts to gain traction, you can build it out in a logical, well designed format. And you have ground up momentum using a top-down plan. Often time, there is a rush from the business to create or deliver a result and lack of understanding or appreciation for the technical challenges as well as GRC-governance, risk, and compliance issues that IT needs to consider (such as security, backups, etc). On the flip side, from the IT part, it often takes approach, with an over engineering and over compliance for something that needs to be done quickly, and appreciation to bend the rules and support a business need, allowing the business lines to take on the risk of noncompliance if they choose so.

Focus too much on schedule, not enough on VALUE: Firstly, it is that IT functions are always taught and incentivized to be obsessed with delivery dates and checking off a list of deliverables. On time and as asked for is great, but wouldn't the world be amazing if IT actually worked harder on making the product just perfect for the business need, not just one that perfectly meets the project spec? One of the best way to get a proof of concept off the ground is to find that business group that most needs and wants business data. They want data, they need data, and they will be willing to cooperate. Working with them, you can build out real working solutions - proof of concepts. And as they start to improve, in effect ‘win’, other groups start to want what they have. And they start to come to you, asking how you can help them as well. It’s the ground up approach. 

The gap between the language of business and the language of IT is getting bigger not smaller. It ends up with the very same situation foretold in Wittgenstein's parable "If lion's could speak, we still couldn't understand them". IT and business have to speak in the same language, just like many other projects, ‘lost in translation’ is one of the big pitfalls to cause analytics project fall, for many traditional organizations, silo thinking, lack of cross-functional communication and collaboration are the culture inertia which undermines project success. The high performance analytics team needs to have talent working on the IT side, but have had that experience on the business side as well; it's also a good call to action for people who have the technical know how in this area - a big need to learn what the business does not only to help with the immediate business problems, but also to make yourself more valuable. 

It is a rocky road to manage analytics project successfully, but through asking big why, communication clarity, master planning, and value focus, business and IT can work as a whole to overcome the barriers and build solid analytics capability in gaining their company’s competitive advantage.  


Post a Comment