I remember how, as a young data analyst years ago, I used to love describing my analytical approach and methodology when dealing with business stakeholders.

Even when presenting my findings to senior management, I would proudly spend half the time articulating the complexity of the work required to achieve the results we would soon be discussing.

Reflecting back, it’s obvious some of that was simply my way of gaining credibility and authority within the organisation. It was a common issue not exclusive to me or my industry at the time.

There was, however, something larger at play.

Data analytics teams were becoming a must-have for any organisation, and it was often hard to figure out where and how these teams fit within an organisation. Business leaders were being challenged to evolve through better use of data and data-based technologies. They knew they had to; the benefits were becoming clearer. They just didn’t understand how.

These new data people were seen as an odd bunch — outsiders who lacked context, sometimes a threat. Let’s face it: The change wasn’t always embraced with open arms.

For all these reasons, it was easy to see how keen analytics professionals could often feel pressured to explain themselves far beyond what would seem logical, sometimes even aggressive in their assertions.

Eventually, through my own maturation, as well as some astute advice from wise mentors, I broke the habit and learned to trust in my own expertise and reputation. I learned to cut to the chase and focus on the insight and its value to the business. Validation of the awesomeness of the work (and its creator) could come later.

Winning over hearts and minds proved much more valuable than preaching how effective our statistical methods were. Those who prospered in our field understood tangible business results and realised benefits were the only factors worth obsessing over, regardless of the people, politics, and process at play.

Now in this relatively new era of all things Big Data, I’ve started feeling as if those bad old habits have begun manifesting themselves again, and in more pronounced ways.

I speak to young data rock stars now and am consistently amazed by the passion and excitement around data technologies, analytical methods, and customer-facing applications. Simply put, they are doing things we could only have dreamed about just 10 years ago.

The one thing that troubles me, though, is the degree of focus on software, hardware, and code as related to Big Data, instead of the actual business problems these things are meant to address.

We’re all starting to talk a bit too much about the awesomeness of the “stuff” and forgetting to cut to the chase. Our decks are looking a little too cool, a little too light on substance and benefit.

Real stories of data scientists spending inordinate amounts of time exploring new algorithms or data management processes without clearly defined purpose or mandate are all too common.

Don’t get me wrong. It is essential that we understand the limitations of our hardware and software. In fact, it is more important now more than ever that Big Data practitioners explore and push the boundaries between technology, statistics, and data platforms.

That being said, and blasphemous as it might sound for a Big Data blog, we need to be careful about how much of the Big Data buzz we bring to the boardroom, and think carefully the next time we’re so compelled to roll our eyes at the person across the table that just doesn’t seem to get it.

Frankly, it’s all starting to remind me of those old days and the organisational data divide – just more dangerous now because the stakes are so much higher.

So how do we deal with the issue?

It’s a difficult balance to strike. Here are some things to consider, food for thought at least, when thinking about your own Big Data initiatives:

• Have you drafted a plan and/or roadmap? Have you shared it? Resist all temptation to use industry terminology. I’m not suggesting you completely simplify the effort or meaning of it all. This is about speaking a common language the business currently understands today.
  
  Speak to specific objectives and how you will measure the business benefits. Drive a realistic roadmap hard, communicate the plan, celebrate success (always tied back to goals you originally set), and the data-based culture will evolve around you.
  
  Simply put, you can’t change a culture if people don’t actually understand what you’re talking about or how it relates to what keeps them up at night.
  
  
• Are you building data solutions for capabilities that exist in your organisation? There are no wrong answers here, but awareness is essential. Maybe you are focused on solving something that is meant to be leveraged by a capability that is being developed in parallel. That’s great, just make sure it is.
  
  It’s easy to get caught up in the latest, coolest Big Data toolsets only to lose sight of whether or not you’re capable of actually leveraging the outputs. Recommendation engines are amazing things, but are you capable of leveraging the outputs? If not, then that development plan needs to be just as aggressive and realistic as the data side of the equation.
  
  Unless you’re working in a research and development function, mining and processing data just for the sake of doing it will serve little value – and will likely harm the team’s reputation. Exploration is great, but are you mining for gold or just breaking more rock because you can?
  
  
• What is your data analytics team working on right now? You should know. If not, find out and make sure you always know. Regardless of your position, make sure everyone above your pay grade knows.
  
  It’s important for your analysts to believe senior management cares about their work and takes personal interest in the team’s output. It’s also critical that leaders do their part to ensure the data is being leveraged across the organisation – and that they can speak to the value on any given day.
  
  
• Is your programme proportionate? Your roadmap should include net new capabilities as well as enhancements to existing capabilities. In fact, it’s usually best to prioritise solving old, meaningful problems before moving into new, unexplored territory.
  
  Your stakeholders will appreciate you taking care of them first and your programme will gain loads of credibility, which is important equity you will need later when new, more controversial capabilities start to take shape.
  
  Your team should incorporate processes and structure so that both short-term and long-term projects can be supported without compromising one for another. Technology and tools should also be invested in proportionate to the actual size of the current and foreseeable challenges you face.
  
  Most failed Big Data initiatives have one thing in common – a disproportionate degree of investment in any one area (people, process, priority, technology, etc.).
  
  
• Are you looking back, reflecting, adjusting? You should be. Often.I’m always telling my own team here at The Globe and Mail that we should look back on things in six months and see tangible difference and change across the organisation.
  
  Are the newsroom, ad sales, marketing, and executive teams more data-driven in their decision-making than before? Is the collective degree of intelligence around our audience and products more advanced than it was six months ago?
  
  Ask these types of questions on a regular basis and make sure you’re adjusting your priorities and initiatives accordingly.

In upcoming blog posts I will explore Big Data roadmaps, technologies, and analytical methods in all sorts of gory detail. This is going to be fun. Hopefully it inspires some great conversation and healthy debate.

I look forward to your comments and questions. Feel free to reach me anytime at gdoufas@globeandmail.com.

Chat soon everyone.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .