Okay, Ford, take it away!!
In my previous post, I detailed the nuanced definitions for intelligence, information, and insights. Here I will explore the three key roles needed to successfully transform your group into one that uses intelligence.
Engineers
First are your Engineers. I use this term loosely; they do not have to be Engineers by profession, but they must possess the technical or scientific skills to effectively work with information. The specific titles of Engineers may include Data Architect, Data Analyst, Data Engineer, Machine Learning Engineer, or Data Scientist, and the following flow chart illustrates the differences among these positions. The people in these roles find the right sources, define new ones, and succinctly and cohesively compile the information. They may also provide analysis and recommendations on systems and procedures for creating new sources, working closely with those in the next role to transform the information into usable insights.
Business Analysts
Next are the Business Analysts. People in this role should not only comprehend the concepts and theories used by Engineers, but they must also have a strong understanding of the needs and operations of one or more specific business departments. They are key to applying business needs to the intelligence process – in fact, they are responsible for the intelligence process. The Business Analyst is not a researcher waiting for a task. Those who excel in this role are business operators who understand the nuanced needs of the department. Their in-depth business knowledge allows them to apply the discovered information, providing valuable insights to those in our final role.
Decision Makers
Finally, the Decision Makers. Recalling from the previous post: intelligence that does not support a decision or action is useless. To be successful, the intelligence process demands that Decision Makers are personally involved in the conduct of intelligence activities. Unlike the Business Analyst, they do not need to understand the processes and theories; rather, they must possess an appreciation for the immense capabilities and subtle limitations of intelligence, including the available information, personnel, systems, procedures, and products. People in this role must establish priority requirements that drive collection, production, and dissemination. If the Decision Maker does not effectively define and prioritize intelligence requirements, the collective effort falters. While the Business Analyst provides a recommendation, it is ultimately the Decision Maker who defines the meaning and use of the intelligence.
Working together
The Business Analyst-Decision Maker relationship is paramount. The Decision Maker must provide guidance and support to the Business Analyst while also allowing them sufficient latitude to manage the intelligence process and the Engineers. The Decision Maker must present the problem or questions that need addressing. Requirements are made by the Decision Maker, not the Business Analyst. The Business Analyst actively advises the Decision Maker on what intelligence may meet the specific requirements. And once the Business Analyst provides a candid, objective estimate, the Decision Maker assesses the estimate and makes an independent judgement. Once the decision is reached, the Business Analyst must fully support it – all while maintaining the detachment necessary to advise if the situation has changed or new sources with fresh information become available. There must be trust between these two leaders; the Decision Maker will find greater success if the Business Analyst feels they can challenge the thoughts and direction of the Decision Maker. Intelligence must be heard with candor and a keen focus on the insights. But once the decision is made and action has been given authorization, there must be full support from the Business Analyst. The Decision Maker must realize that intelligence is the business of estimates, not certainties. If the Decision Maker harbors unrealistic expectations, they may discover that the Business Analyst is reluctant to risk any predictions for fear of being wrong. There must be trust.
Reporting structure
Great consideration must be given to the reporting structure of the individuals in these two roles: that is, the Business Analyst should not report directly to the Decision Maker. These two should be close to peers, challenge each other, and promote candid conversations. If the Business Analyst’s performance and compensation is decided by the Decision Maker, the Business Analyst may be less willing to challenge and offer recommendations. Again, there must be trust.
A real-world example
I was recently approached with a third-party system that could show us real-time reporting. Our Venue Operations (an amazing group responsible for making sure every concert, game, or match is a success for the fans) could respond to an issue immediately. We built a proof of concept and began exploring. In our first action-based meeting, we asked our Venue Operations team if there was room for this large live-data dashboard in the Operations war room. There was not. We asked if they had the staff to respond anywhere in the venue at any time. They did not. So, we began asking probing questions related to the type of live data they could act upon. After a while, we settled on alcohol sales. Venue Operations could shut down the sale of alcohol with a quick call over the radio. We now had our requirement. We took this back to our Engineers and described the problem and the intelligence goal. Not only could we give Venue Operations a live number of alcohol sales, but we could also provide them with insights. We could look at the time of day, type of show (e.g., country music vs rock vs Disney on Ice vs hockey), and how these factors impacted alcohol sales. Most importantly, we could identify a tipping point: At what threshold of alcohol sales did reported incidents rise? From this original discussion, we made another recommendation. We were missing a key role: Venue Operations Business Analyst. We needed someone who could work with this department’s leadership to continue improving their use and understanding of information. After our presentation and recommendation our Venue Operations leadership, the Decision Maker, liked the approach and quickly offered their approval for a new position. We killed an unnecessary intelligence project, real-time incidents, and prioritized an actionable one and had approval from department heads. Unfortunately, I can’t tell you how this story ended. This was all done in February and March 2020. As you look at implementing and becoming a data-driven, decision-making company, you must do more than understand the terms: you must understand the roles. Understanding roles will allow you to identify gaps, and know what your role is in this process. In my next post, I’ll dive deeper into the process itself.
Thank you, sir. We are now waiting for the third post. I’m working on part two of this post on the most advanced 21st century business model – the part that explains how to use the elements without using the entire framework. I’m also working on a post on topic no one is talking about it. But it’s going to be important to business to solve this in the next year because in five years what I’m calling the “transition to (buying) power” is going to be either nearly complete or complete. And finally, I’m working on a post about how to encourage not just interaction but participation in the business world – when the barriers are being broken down every day between the consumer and the business buyer. In the interim, I have four more really interesting guest posts coming up and I’ll do one or two interim post on some of these things and on the CRM Watchlist 2022. One last thing, I would encourage you to sign up for the CRM Watchlist 2022 if you haven’t yet. We have solid participation already. If you want to register, please email me at paul-greenberg3@the56group.com and ask for the registration form for CRM Watchlist 2022 or if you have any questions email me at the same address. If you want more info on the Watchlist, read this. It covers most of what you need to know.
