Communication Tips to Avoid a Common Stumbling Block in Data Analytics Projects
We all want our analytics projects to be wildly successful. A well-crafted dashboard can be central to business outcomes, and generally businesses consider data analytics critical to their success. Companies are investing in big data analytics projects more than ever, but putting resources towards analytics projects doesn’t guarantee their success. We can deliver a slick dashboard with loads of functionality, but if we misunderstand a foundational requirement during upfront planning, could our effort be for naught?
A project can be considered a failure for several reasons:
Exceeding timelines or never ending – this can happen due to scope-creep
Being abandoned before completion
Not producing value or insight to the business and not being able to assist with decision-making
In this post I want to focus on that last outcome and the disconnect that can be occur due to misunderstandings during the requirements gathering phase of a project. A few careful tweaks and intentional word choices can make a big impact to ensuring alignment between stakeholders and analysts.
I was blown away to see estimates in media and literature that the majority of data projects are likely to fail. Gartner Research estimated in 2015 that 60% of big data projects would fail over the next two years. Two years later, Gartner analyst Nick Heudecker tweeted that they had been too conservative in their estimate and that the rate had turned out closer to 85%. Then in 2019, Gartner predicted that through 2022 as many as 80% of analytic projects would fail to deliver business outcomes. So what is at the root of these failures, and what can we do to mitigate them? Well, further research has shown that many of the problems leading to big data and analytics project failures aren’t technological or skill-based but rather they are outcomes of the human interactions around the project.
A 2017 study by David Becker digs into the nature of these project failures. He surveyed data practitioners and industry analysts to identify over 100 different causes of failure that fall into these 17 categories, ranked by frequency of occurrence:
A majority of Becker’s categories are related to organizational management and culture, and a subset of these – the rows charted in blue – are specific to communication around a project’s requirements and deliverables: Did this project analyze the right thing? Can the organization gain the kind of insights it’s looking for based on the results that are delivered? A project can be conducted with sound data and methodologies and still fail.
Why might one find a communication gap in analytics projects?
Becker’s research suggests that a focus on soft skills across both the business and technical sides of the organization is needed to increase success rates.
We recently caught up with Wendy Lynch, PhD – an expert in data analytics and effective communication, who has worked with hundreds of companies to help them improve communication to optimize the value of analytics in a business setting – to talk about why communication matters and what we can do to hone our skills.
If an analyst doesn’t know how to extract the information they need from the businessperson, it’s likely the project will not address the real question.
Rachel Carriere: Wendy, can you offer any insight into why the intersection between business and analytics can lead to failures in data analytics projects?
Wendy Lynch: That’s an important question. Estimates are that big Data analytic projects fail 80% of the time! Meaning that the project never delivers business value. There are many reasons that projects fail, but most reviews find that the main problem is NOT lack of technology or talent. The problems happen in the handoffs between these two teams. Analysts misunderstand the business need, or the analytic question is poorly defined, or the answers aren’t clearly explained. It’s not surprising. In busy corporate environments, it’s common to have short conversations and cryptic email requests full of abbreviations and jargon. That’s just the way life is. Plus, anyone with expertise (in any area) develops specialized terminology. Whether you are an accountant, a data scientist, a pilot, or a surgeon, you will use language that makes sense to your similarly-trained colleagues--- but no one else. So, this problem is not unique to the interface between business and analytic teams. But, as analytics becomes more critical to almost every industry, it has serious implications. If an analyst doesn’t know how to extract the information they need from the businessperson, it’s likely the project will not address the real question.
RC: What are some of the reasons we find communication problems between business leaders and data analysts?
WL: There may not be two more different groups of workers than data science and business (for example marketing)! Think about high school: computer club and football team. Think about TV: Sheldon from Big Bang Theory meets Don from Mad Men. The most common personality in each group are opposite personalities on the Myers Briggs personality inventory. Plus, perhaps even more important, they are trained to value completely different achievements.
Data scientists often prefer to create the most complex, interesting, unique analysis possible - use their skills and knowledge! Business professionals want simple, scalable, concrete statements - easy for customers to understand! Data scientists are trained to highlight all the reasons they might be wrong (p-values and confidence intervals). Businesspeople want to be clear and convincing, not confusing or doubtful. You can see, it’s a recipe for tension and frustration.
Plus, ideas are interpreted through our own perspective. So, a request to find the “best” solution can mean the cheapest, most effective, or most popular. If we don’t take time to understand the meaning, we can end up wasting time and effort.
Wendy has introduced the role of an analytic translator. This is an individual with characteristics, skills, and training tailored to bridge the gap in communication between business leaders and data scientists.
RC: What are some of the key competencies for an analytic translator?
WL: I divide competencies in three categories: expertise (things in which the translator needs strong skills); experience (situations and environments in which the translator has been in many times); and attributes (characteristics and abilities that will be helpful).
Expertise
Communication skills including active listening, guiding conversations, and knowing how to use questions.
Strong analytic skills, where they have done hands-on analytics at some point in their careers.
Sense-making: the ability to express complex concepts in multiple formats to various audiences.
Experience:
Business acumen: Knowing how the organization operates and an understanding of its priorities.
Research synthesis: knowing how and where to find evidence and interpret scientific results.
Attributes: Empathy, adaptability, humility, curiosity, credibility.
Practical Application for Data Analysts
So, what can we as data professionals do to improve our communication skills and increase the rate of success for large-scale and small-scale analytics projects?
First and foremost, always keep in mind that requirements and results conversations for analytics projects are made up of people from different backgrounds. Business and analytics folks tend to have different expertise, different priorities, and different vocabularies. Even the same word across these groups can have different meanings (for example, “profile”). It’s important to remember these differences and tailor your conversation to ensure you’re relating to the folks with whom you’re gleaning requirements and delivering results. These are the points at which communication failures occur that can lead to a project failing to deliver value.
The Three Steps for Ensuring Requirements Conversations are Productive and Fruitful
When a request for an analytics project comes in, it’s typically delivered from the business side to the analytics side of an organization. The best way to make sure that this request is clearly understood and translated into business value is to have conversations to flesh out what is really wanted from the business. Follow these three steps for making those conversations more productive:
Recognize and Avoid Assumptions
There are two aspects to be mindful of to make sure you won’t get caught on an incorrect assumption: listening carefully and being thoughtful about the language and you and your stakeholders are using.
Remember to listen to everything that the requestor says. Human nature is to jump on the first part of the ask and run with it, but often the most important part of the request is not the first thing said. Be sure to listen to the entire statement before beginning step two, where you dig into the details.
Use clear language. Try to avoid analytics jargon or ambiguous terms, and be consistent about the terms that you do use instead of switching them up through the conversation.
Recognize when the stakeholder uses any ambiguous language. If the request contains a term or phrase that could have alternate meanings, take the opportunity to ask for clarification.
Some examples of ambiguous terms – terms that can mean different things across business and data science backgrounds – include profile, segment, attribution, property, aggregation, comparison, and the list goes on!
In your approach to these steps it’s important to remember that the person making the project request may not have fully honed their request, so their conversation with you is also an opportunity for them to think through the details. Just another reason it’s important not to take their initial statement at face-value and return with a result that may not deliver value.
Ask open-ended questions
Understanding the business context, the “why”, of the analysis request is critical to defining the project requirements. Ask the requestor what questions they want to be able to answer using the results of the analysis. Here are some examples of open-ended questions to ask:
How did the need for this project arise?
What questions do you want this project to answer?
What decisions are you making based on the output and what are the criteria for the decisions?
Who is the audience for the project output?
Who else will want to know about the results of this project?
Keep your mind on the terminology throughout this step’s Q&A. If the requestor uses ambiguous terms, don’t hesitate to ask them to define what they mean using an open-ended question such as “tell me more about….”
Lastly, don’t be afraid to ask a question that might feel overly simple or obvious – it’s always better to confirm an assumption than to let it cause a gap in understanding!
Repeat Back Your Understanding of the Project Requirements
The last step in the process is to take the time to confirm that you’ve understood what the requestor is looking for by repeating the requirements back to them, including the business context. Use your own words when framing the request because this can help uncover missed assumptions or language misalignments!
Repeat steps 1-3 as needed to hone the request until all aspects are agreed upon by all parties.
These steps, to listen openly, use clear language, and understand the business context and perspective, can go a long way to making sure that your analytics project reaches a successful conclusion.
Happy communicating!