Adapt & Overcome |
|
2/12/2017 1 Comment Reporting Is Not Analytics
To be in the modern business environment is to sail against a current of change. In today's context, technical skills and analytical acumen are paramount to success in a previously unforeseeable breadth of fields. Unfortunately, upon buzzword-ification, analytics has had much of its useful definition eroded. This was driven home for me last week when I read an inquiry from a well-meaning recruiter who was operating a little bit outside his comfort zone. Or maybe he was comfortable: A side-effect of contentment riding the tide, unaware that it threatens to whisk us toward irrelevance... One way or the other, only a few sentences into a job advert with a title that sort of made sense for my LinkedIn profile, he lost me with the scope of this position: "This individual will play a key role in the creation of business unit reporting functionality to empower key business decisions." The Issue With The OfferOkay, they're after a dashboard jockey. That's not the right flavor for me, but it could be for someone else. The problem is that the role is called "Analytics Manager". It entails no direct reports (nix "Manager"), and employs a troubling concept of "Analytics". Analytics, like a physical textbook, is entirely incidental. The value of analytics is information. The value of analytics professionals is generating the information and implementing a plan of action that works in his organization's context. If you leave this page with one idea, make it this one: Analytics Is Not Arithmetic Basic data blending and aggregate functions are tasks, not a career. That said, if a company wants to hire someone to create graphs from query results, far be it from me to stop them. However, armed only with this clip of the job description, the reader can easily tell this role is about giving information to the decision makers...not making decisions. What's worse, these decision makers likely (definitely) have some strong ideas about what they want reported. They need a mechanic to put the parts together.
Something a bit alarming: Until this role is filled, the decision makers in need of empowerment will, just have to sit around and keep making decisions without information. Okay, that's facetious, but it lets you know exactly how important this role really is to the company: They want someone to give new figures to the people who are already making the decisions anyway. At the end of the day, this position is the very definition of a nice-to-have. The ISsue With The OrganizationThese folks have the budget and opportunity to bring someone into their organization to analyze their data - probably the first time this "transitioning" company has had anyone do so - and the only value proposition they could come up with was reporting? It's like putting someone in a gold mine and having them count the rocks. This lack of vision jumps off the page to anyone who has been in the data science game and knows the strategic role analytics groups should be playing. Seeing a company hamstring their employees and themselves like this is disheartening, but not rare. The Issue With The Title...And My SolutionAm I taking this a little personally because I've held titles similar to the one advertised? Yes, but... The larger issue is that people will remain at least as confused as they are today by these titles unless we really iron out some details. Bottom line: "Analytics Manager" says basically nothing about a position, and it's up to hiring managers to understand the fine print. The title could apply equally well to a PhD mathematician and a sort-of-sober guy who can write queries with GROUP BY clauses. As a step in the right direction, I recommend the following, still-not-perfect-but-better titles and provide some definitions: Title: (Data) Analyst Ah, Analyst. I can see those sharp, wire-frame glasses now. This is where I and many others started the journey. There are likely as many suitable analyst backgrounds as there are analysts. Economics, statistics, mathematics, and other quantitative studies prepare analysts for their first full-time gigs. Analysts should be voracious learners: competitive and restless. While the young wiz-kids may come to conclusions a little too quickly, some guidance will help them do exactly what you need: Fail quickly, cheaply, and forward. Analysts work on statistical modeling and categorization problems under/with the guidance of a senior methodology developer who has more experience with the organization's data and preferred approaches. Expect analysts to come equipped with theory but light on applied experience with a need to develop effective business communication. When you need an analyst whose work directly drives business strategy, throw a "Senior" in front of this one. Title: Data Scientist Specific? No, but it tells the market you're looking for someone a few cuts above entry-level researcher. This title enables you to reasonably ask for an advanced degree, a programming background, and experience applying a wide array of classification and regression techniques to real-world data. He has worked directly with C-level executives and pivots quickly from theory to application to strategy. Importantly, your data scientist is self-directed: He wants to answer the questions you haven't asked. Someone with this title should be able to simply and effectively communicate the importance of his findings or lack thereof. Title: BI Analyst Plain and simple, this is your dashboarder. He's a spreadsheet wiz, and he knows some SQL principles. While not afraid of data, he's going to be a little bit naive when it comes to drawing conclusions. That's okay though, he's a couple years out of college or fresh from an MBA program, and he'll catch on quickly. While he's no statistician, expect a BI Analyst to understand the business needs above all else, and trust him to slice and dice the data to give you what you're after. But you have to know what you're after. Title: BI Developer A different beast from the BI Analyst, he likely has a computer science background and a Microsoft certification in tote. These folks have deep database knowledge that includes using tools like SSRS (SQL Server Reporting Services) to create custom reports from data warehouses. Being able (and expected) to bring disparate sources of data together programmatically naturally requires a more technical background. While this role may sound like an outsourced IT resource at first glance, there really isn't anything enjoyable about needing to send 3 emails and make two phone calls before minor tweaks can be implemented in a dashboard. This is doubly true for departments just setting up this capability. Wrap UPI don't fault companies for not knowing exactly what they're looking for. However, the way industry throws around "Analytics" titles today doesn't help employers or employees. Like "Big Data" and "A.I.", these titles get abused until they are entirely hollow.
It's time to make a change. Am I personally convinced of a conspiracy involving BI companies conditioning innocents to believe graphs and charts are analytics? Possibly.
1 Comment
12/27/2016 0 Comments Building The Business Case Mentality Whether setting up a new organization or beginning the transformation process for an existing one, you face a similar problem: There are a million things to do (and/or already going on). Some of them rely on others being done first. Some are superfluous. Some should probably be done by someone else. As an analytics function (especially a new one), there are always a tremendous number of opportunities to go after - many rough surfaces that need smoothing. Let's begin with a quick reflection on human nature: When faced with many options of apparently similar value, we probably won't get anything done.  What's worse, it makes sense that this situation would paralyze us. It can be completely justifiable to sit and wait for more information to become available. In Microeconomics, the study of real option value reveals how it can be optimal to wait before making any moves when more information is expected to come to light. Of course, business, even when it is options valuation, is not only options valuation. In reality, if you commit to a work stream - even the wrong one - you and your team will make progress and solve problems that need to be solved. A ship heading to the wrong port can still make better sailors, and may make some useful discoveries by accident. That said, you don't want be landing in the wrong place routinely. There are some guidelines that can help prioritize opportunities in terms of value to the organization you're working with. Step One: Approach Each Option As An Outsider It's easy to get tied up in the day-to-day but critical to remember that the daily grind is what created the processes you're here to simplify. You need to get your head above water, and the first thing to master is Meaningful Abstraction: The art of framing a problem in its simplest terms, and solving it with only its inherent constraints (dropping organization- and industry- specific constraints or norms people consider in their) daily work. Most bad processes are implemented because someone had his hands tied and either couldn't or wasn't willing to break down the barriers that needed to be broken. When you are going over the ways you can better equip an organization to do business, you need to free yourself of constraints others have internalized. By constructing a solution free of these limitations, you can look at the effect your optimal solution would have on the business as a whole, and, importantly, quantify the implicit and explicit costs the constraints place on the organization. Often, shedding light on the costs of (sometimes maddeningly arbitrary) constraints is enough to create the momentum to have them removed. When you conceptualize every available opportunity by looking at its full potential impact, you will be sure to give each one its due. Once you flesh out what each opportunity could potentially accomplish, you're ready to move on. Step Two: Align The Options With The Organization
Then I use these basic buckets to classify my opportunities and line them up against the organization's strategy. Immediately, some options will start looking juicier than others. If your organization is positioned as the low-cost seller in the market, opportunities around Buying just floated toward the top. Seeking out, say, an initiative that created a plug-and-play vendor model in your supply chain would make sense, since your overall strategy is dependent on having access to the best input prices in the market. A company that spends all its money on R&D may not, in general, care too much about hemorrhaging money when it comes to selling - especially at product launches - because payback timelines are critical in NPV calculations. Accordingly, it would weigh the opportunity to cut sales costs differently from a business that needs to run a very lean SG&A line. Leverage your business's strategy as a guide: There's no need to reinvent the wheel. Step Three: Be Obsessed With ROI & Context-Specific
In business school, this kind of equilibrium is hastily introduced to (and forgotten by) future MBA's as thinking on the margin. In Economics, we say it maximizes total profit. An Illustration: 
In practice, the approach maximizes ROI by:
While this might seem intuitive, it is actually discouraged by most companies through two avenues: Setting budgets months in advance of spending & creating operational templates. Think about the budgeting process for your organization. Does it facilitate this approach? If it became clear that the expected ROI of a CAPEX project was greater than that of an anticipated marketing campaign, how easy would it be to divert funds? Obviously, supplier relationship management (SRM) and some contract concerns may be in play when diverting large sums, but many businesses have such siloed budgets that even reallocation across marketing channels becomes unthinkable over time. Bottom Line: When the product launch template gives the marketing group a DTC budget, regardless of the anticipated outcome, they're going to spend it. By challenging the playbook and insisting on context-specific ROI calculations, you'll properly evaluate each opportunity at the right time and in relation to all other opportunities in that moment. What's more, by conducting this analysis, you'll gain a greater understanding of how investments across your enterprise tend to effect one another. Step Four: The Business CaseI imagine many readers have seen the aforementioned, uncritical approaches to making investment decisions out in the world. In truth, these practices span entire industries: Simple (probably true) notions are often used inappropriately to validate specific actions. Does advertising work? Sure. Is the next commercial you're thinking about running worth its price? Not so clear. Will it increase product adoption? By what amount? For how long? Without answers, you simply can't defend letting money out the door. These answers and the manner in which you derive or approximate them are precisely what belongs in your business case. A healthy business case should include exhaustive measurements or approximations of the costs and benefits of each program. This is where a lot of people give up, and it's why you got called in to streamline the confused web of business processes and priorities the organization has today. The larger the toolkit you can build to evaluate these metrics, the better your business case, and the more value you can unlock. Wrap UpWhile a lot of money flows out of a lot of businesses with nowhere near the level of scrutiny I lay out above, this approach will help you build a rock-solid project justification. Nothing answers "Is the juice worth the squeeze?" quite like cold, hard numbers.
By introducing this level of rigor, you will raise the bar for your organization and ensure that your projects are high-value, impactful, and visible. This is it. I've cracked the nut. We can achieve massive gains if we just change this one thing. Anyone who has done time in corporate America knows deploying anything is difficult, but deploying something that demands change - the removal and alteration of business processes - can be damn near impossible. The reasons for this are unique to every company and every business unit's place within the company, but the moral of the story is that, once you've done the math and have the platforms in place to deploy your work technically, you still have a lot of work ahead of you. I'm sure we're all familiar with the agents in play here. The Fiefdom People want to keep and control their territory. This is natural, but it still sucks - for everybody. Some folks won't answer emails, others will run to an EVP if they sense a project may change the work over which they have dominion in any way. After being CC'd on one email, these folks couldn't possibly know all the benefits your project brings, but they seem to have totaled up costs. Eternal Emily Favorite Quote: "I don't think I've been trained on this." There are many Eternal Emilies out there. She's been in one line of work for the last century...probably at the same company...likely at the same desk. Emily operates according to her job description, and she's the reason your company has process maps. She doesn't do "outside the box". She doesn't even like to get to close to the corners. The Pawn This guy has a problem: He knows your idea is sound, has seen the proof, and gets the concept from back to front...but it really should have been his boss's idea. When the question "Why weren't we doing this before?" comes up, he will chime in with a response. If your work is implemented and changes the way his unit works, that's a prestige problem for his organization, and political problem for you. The difference between him and the people in the fiefdom is that he doesn't even stand to benefit by implementing your work, making him much harder to win over and - likely - a more vocal opponent. The world has enough Fiefdoms, Emilies, and Pawns out there to bring nearly any change to a grinding halt. You are at an additional disadvantage: Your ideas are not easy to understand, and they usually require either math, programming, or both to implement. In the face of a scary, mathy idea, these folks can take advantage of institutional momentum to scare others into stillness, which, incidentally, is the easiest state to be in. Time to inject some good news: Even if you're proposing an extremely disruptive solution, because the company as a whole stands to gain from your work, you have a few levers to pull with each of these characters. To The Fiefdom's Leaders: Think about your own metrics. If your solutions falls under their scope in some way, they stand to save man-hours and/or expense. However, this message is not enough: The only way to drive this home is to make it tangible. If you want people to accept and implement your solutions, you must engage with the vassals of the world on their project pipelines. You need to point to the resources that would be freed up by your work and point, on their ridiculous Gantt charts, to what they will gain in terms of deliverables and efficiency. This level of engagement is difficult, and getting people to sit down at the table is a skill you develop only with repeated effort, but this is how you get the vassal to open the city gates. To Eternal Emily: It's important to remember that she is scared for a couple of reasons: 1) She doesn't want to change anything about the way she does her work and 2) She is terrified of being made obsolete. In her mind, "simplification" is a dirty word, and if anything is getting "streamlined", she's the rough spot that's going to be smoothed. What's worse, there are times when she is right. How can we get her aboard? Engage with her exactly when it feels most counterintuitive: Right in the beginning. Of course, she isn't your primary point of engagement within her business unit - that is somewhere closer to the top, but, by bringing her into the discussion before deployment, you're making her feel involved in the process. If she feels a little ownership and gets exposure to your entire plan, she will be less scared. Critically, she will feel like this is part of her work, implicitly broadening her scope, making her feel less trapped. Getting her buy-in early on may even lead to some improvements before roll-out. To The Pawn: Let's be honest, sometimes the best way through is around. Mention that the VP's have spoken and cooperation is afoot at senior levels. He likes to follow, and he loves to be seen following. If possible, have him included on communications that show someone in his chain of command wants this to happen. At the end of the day, you need to create a plausible reason for him to feel like a partial owner of your success. It may make his people more efficient. If it's more taxing, make sure you publicly ask his senior if the pawn's staff is properly resourced for implementation. No one hates another direct report. The key point is this: If he feels that cooperation is mirroring his boss's reaction to your program, you'll win. Wrap Up I've distilled the characters above from years of pithy and prescient observations made by people far more politically savvy than myself. And, while every difficult character doesn't fall neatly into these molds, I've found them to be useful archetypes that have helped me slide my own projects through cracks in corporate political structures that should have been far too narrow.
I offer them to my fellow analytical leaders: Go forth, win friends, influence people, and execute projects! |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
February 2017
Categories |
RSS Feed