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 groups: The 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.
.jpg)
0 comments:
Post a Comment