Building a Better Analytics Organization - Implementation (Part 7)

Welcome back to Part 7 of Building a Better Analytics Organization. In parts 1–5, we covered a number of challenges that analytics organizations face and in part 6, we covered a comprehensive solution. In this part, we’ll discuss how to implement the solutions within your organization. But for this section, I’d like to take a slightly different approach. 

Part 1 — Introduction, common tasks, and an introduction to challenges for an individual and for a team
Part 2 — Overview of the common areas where problems can occur and the specific problems that individuals and teams face
Part 3 — Details of specific problems when working with code
Part 4 — Details of specific problems when working with visualizations
Part 5 — Details of specific problems when working with tables and views

Part 6 — How to solve the challenges

Part 7 — Implementation tips

Instead of focusing on a technical, how-to guide, of installing or configuring various tools (you can find plenty of guides on the internet), I wanted to talk about the obstacles that you’ll likely face when attempting to implement new solutions.

In Part 6, I mentioned that you would likely encounter various sales objections, with almost no validity for those objections. The objections are generally due to a resistance to change, lack of knowledge, or part of office politics. Unfortunately, they are opposed to what I would classify as real objections, which are related to financial resources constraints or competing priorities.

If we think back to our solutions, almost every single organization has a software development team and I can almost guarantee that the software development team is using Jira (or another issue tracking system) as well as Git for a code repository. Aside from these two pieces of software, all of the other solutions are built around and adjustment of how people utilize the software that exit in your business today.

But since Jira and Git are an integral part of our solution, it is worth calling out that there can be an increased cost for user licenses. However, I rarely view this as a concern because some analysts already have access and a license to one or both of these tools today. Also, in the grander scheme of costs, it’s a rounding error to the company’s bottom line. But, it could still be a potential objection.

Regardless of the validity of the objections, you’re most likely going to run into them and you’ll need to overcome those objections. In the remanding part of this article, I’m going to walk you through some of the objections, discuss additional challenges, and provide a few tips on how to successfully implement your solution. Now, before I talk about tips and solutions, it’s crucial that I cover the landscape that you’re constrained by.

The Landscape

In your environment, you’ll need to understand and account for:

• People — Those who needs to buy into the solution, who will ensure compliance, and who will do the work
• Practices — How work will be performed
• Programs (Technology) — Tools utilized
• Politics and Emotions — Hidden reasons for doing/not doing something
• Priorities — What is the most important thing to be working on

People Overview

In order for your implementation and solution to be successful over the long-term, you’re going to have to ensure that you can get the right people to help you implement the solution. But you’ll also need to ensure that people are utilizing the tools and practices on a day-to-day basis. If either of these areas break down, your solution will ultimately fail and your environment will most likely end up reverting back to the brittle state that exists today.

When we think about people, there are four groups of people that should be considered: The implementers, the end-users, the stewards, and the blockers.

Implementers

The implementers are the people that will be in charge of putting the tools and practices into your environment. And since many of the solutions revolve around practices, you’ll probably be the person that is working to implement the best practices. Fortunately, you can leverage everything that I’ve written, as a starting guide for best practices.

For tools, you probably already have Git and Jira in your environment, so there’s a good chance that you won’t have to do much work. You’ll probably need to invite users, configuration permissions, and create a new project, but all of these tasks are quick and easy to complete. The other tools, such as your database, visualization platform, and cloud storage already exist, and there isn’t anything new to configure. The exceptions might be that you need to create a new shared directory on your cloud storage, set permissions, and invite users.

Once you have the tools in place and best practices documented, you’ll need to communicate these changes to you end-users. But before you start on that path, you’ll want to ensure that you have support from the Stewards.

Stewards

Stewards are the individuals that will be responsible for ensuring day-to-day compliance of the best practices. They’ll also be the individuals that can help troubleshoot and answer end-user questions. Without these people, your end-users might say that they agree with these practices, but there’s a good chance that they will cut corners and circumvent best practices at times when they are feeling overwhelmed with tasks. It’s the steward’s job to ensure that everyone sticks to the rules of the road, so to speak.

Given the importance of the steward(s), you’ll want to seek out individuals that believe in your solution, have passion for a better way of working, have the technical know-how to utilize these tools, and have the ability to positively influence others to adopt the new practices. Chances are, these individuals will be the leaders, managers, or architects on each team.

End-users

The end-users are the analysts, engineers, and data scientists that need to adopt and adhere to the new practices. While this probably sounds straight-forward, there are a few obstacles to overcome when dealing with end-users.

First, not all end-users are created equal. Each person has a different set of skills, experiences, education, attitude, aptitude, way of learning, priorities, and baggage. Second, not everyone is going to believe in this new way of working. It will be your job to navigate these challenges and bring the right people into the fold as quickly as possible to avoid having too much resistance to change, which can ultimately grind your efforts to a halt.

Blockers

Blockers are the individuals that could potentially disrupt or squash your efforts. There are almost limitless reasons as to how or why someone might squash your efforts and the people that carry out these “attacks” can come from within your team or outside of your team, and they can range from the most junior person to the CEO. If you’d like to ensure success, you’ll need to think about the world of possibilities for these “attacks”. Also, I should note that not all of these “attacks” are nefarious; some are accidental, but we’ll cover more of this topic in a few minutes.

Practices Overview

Defining how your teams should embrace this new way of working will be critical to success as well. Your end-users will need to be equipped with the proper training, have access to documentation and how-to guides, will require support from leaders and peers, and will require oversight to ensure that the new practices are being utilized. If there is a gap in any one of these areas, you will run a risk of having your end-users revert back to the path of least resistance.

For example, if we assume that you have a team of excited analysts that recognize the challenges and want to embrace a new solution, these analysts will won’t have much success if nobody every trains them on how to use Jira, Git, and the other tools. And even with their training, situations will arise where they will be pressured to complete tasks and feel the need to cut corners; abandoning the creation of Jira tickets, omitting checking in code, avoiding code reviews, and saving documentation for a later day (which will probably never come). So, before you start requiring compliance of your end-users, ensure that they have all of the support, training, and oversight needed to ensure success.

Programs Overview

There isn’t a lot for me to cover when discussing Programs. This is because we’ve talked a lot about the challenges and solutions in my previous articles. Again, my main call-out when thinking about the programs or tools is that you’ll want to ensure that your team has the proper training and support.

Politics & Emotions Overview

Like it or not, everything is political and has an emotional component. People are going to support you (and your cause) because they like you, others may attempt to thwart your efforts because they don’t like you, and you’ll also be competing for the hearts and minds of others, as those people jockey for position and power for their own self interests. Now this may sound a bit harsh, and not all of these things are necessarily malicious. But the fact remains that humans almost always have their own interest that will be place ahead of yours.

Priorities Overview

Last on our landscape items to consider is priorities. Everyone has a set of priorities that they are already working on and they also have management pushing priorities onto them. If you’re asking people to learn new skills, they’re going to have to find time to fit this time into their already busy schedule. And if you’re asking people to perform new practices, these people are going to work slower than average until they build up the knowledge and muscle memory. This “slowness” is also going to impact the tasks that they are already trying to perform. Suffice to say, you’re adding more work for them to complete.

In order to have a successful implementation, you’ll have to show and convince people that these practices can actually help them to move faster. You can think about this like keeping your desk, garage, or anything else organized. When you know where everything is supposed to be located, you can find what what you need a lot faster than if you aren’t organized. And when code is written with convention, you can understand the code faster than without conventions, much the same as how much easier it is to read a book that uses proper proper punctuation and structure versus none at all.

Challenges

Now that you’re armed with an overview of some of the obstacles, I’d like to provide some specific examples of challenges that you’ll want to be aware of.

Management Probably Doesn’t Care

Okay, technically some people care, but this is a catchier headline and likely holds true for most non-technical teams. What I mean is that many people probably won’t care about the solution that you’re working towards because they don’t understand the problem in the first place. And if they don’t understand the problem and agree that there are major issues lurking in the background, why would they ever want to support your solution? They wouldn’t.

Think about your internet connection or Gmail for a moment. Do you really know what goes into keeping those services up and running? Probably not. But you surely notice when you can’t access your email, even if you don’t understand the root cause. You’ll probably lament on someone didn’t do a better job and how these problems could have been prevented. The same holds true when we’re dealing with analytics.

When stakeholders are receiving reports by their deadlines, the stakeholders are happy and probably assume that everything is working well. However, the moment that data is inaccurate, delayed, confusing, or conflicts with other reports, things start to dive into a tailspin. Suddenly, stakeholders can see symptoms of the problem and they demand and that the symptoms get resolved. This usually translates into investigating why two reports have different numbers for a metric such as, Total Active Users. However, because very few teams actually understand the root cause of such a problem, they end up treating the symptoms of the problem instead of the problem itself.

This lack of caring is actually quite a significant challenge. The reason is that if management doesn’t understand the problem or importance of having our best practices and tools in-place, they aren’t going to devote time, resources, or attention to solving this problem. This isn’t to say that you can’t have success with your implementation, but it does mean that you could find yourself between a rock and a hard place. What do I mean?

Assuming that most managers don’t understand or give proper attention to this situation, it is likely that they’ll view your efforts as being focused on the wrong thing. For example, assume that your job is to build dashboards, reports, and analyses to combat financial theft.
If you’re busy trying to document your code, database tables, or convince others on the team to do the same, there’s a good chance that someone is going to attempt to add up all of the hours that you’re spending performing these tasks as opposed to hunting down financial theft. And if it’s assumed that you’re doing the wrong things, chances are that this feedback will surface in your review, compensation, and day-to-day happiness with management. And if this proves to be the case, I’m sure you could quickly see your yourself abandoning the efforts for a better analytics environment.

Now, I’m sure that there are some people that will disagree with me and say that management does get it. This is a hard-sell to me as I can attest that very few analytics teams actually function these best practices in mind. But the fact that most managers don’t understand or devote the proper time to this issue isn’t all that surprising if you understand how analytics is usually structured within organizations.

Very few companies have an organization where all of the analysts and data scientists fall under the same reporting structure. This is a stark contrast to almost every other role that a company has.

Think about your IT department. All of the people that work in IT report to IT. You’ll almost never encounter a situation where the Finance team has their own dedicated IT team that is responsible for troubleshooting laptops, connecting printers, and setting security. But with analytics, every department has their own analytics resources and frequently, those resources report to non-technical and non-analytical managers.

Because of this structure, each analyst is left to his or her own way of working and the (good) practices used on one team are seldom used across an organization. Even in organizations where analytics is somewhat centralized, what I’ve described holds true because the central leaders are rarely addressing all of these challenges.

While I’ll stop short of diving deeper into this topic, know that this can be a significant challenge to your efforts and you’ll want to explore how much your manager(s) and other teams understand about the problems you face and if they are supportive of your efforts.

Talent & Knowledge

If you’ve followed along with some of my other articles outside of this series, you might have picked up on the ideas that analysts and data scientists should function like software developers, who utilizing convention, tools, and practices to make life easier, more efficient, and bug-free (or at least fewer bugs) for everyone. This opinion also highlights and suggests that mosts people in the analytics field aren’t functioning this way today. What this means is that you’ll likely be working with individuals that have never used an issue tracking system, a code repository, text editors, conventions, or engineering practices when “architecting” dashboards. I put architecting in quotes because technically speaking, there is an architecture that is required, even if the resulting dashboard doesn’t utilize best practices today.

Understanding that there’s a good chance that your team and end-users will be on a steep learning curve, you’ll hopefully allow yourself to have more patience and time when training your team. You’ll probably find yourself building more detailed documentation and providing additional hands-on training in order to bring everyone into a new way of working. But fear not. The tools that we utilize are not very complex and most people can learn these tools and ways of working, just like they learned how to use any other piece of software.

But be aware that when people have to learn a new skill, there could be some initial resistance, many times out of fear of failure of their ability to learn a new skill. If you’re patient and supportive, I’m confident that you’ll help elevate the skills of others and accomplish your goal of building a better analytics organization. However, I’d be remiss if I didn’t address a potential elephant in the room when talking about talent.

Some analytics teams or individuals might not be capable of this new way of working. Even though the tools and concepts aren’t particularly complex, this is relative to someone’s experience. If you’re a software developer, this statement probably holds true. But if you’re someone that has never written code, you might find these tools and concepts quite challenging to grasp.

The reason that I feel the need to call this out is because, again, not all analytics team members are like software developers. Software developers must know how to write code, but not all analysts know how to write code or work with databases. I’ve encountered a significant number of companies and individuals that have hired “analysts”, who on the surface are presented as if they work with databases, code, and visualization tools, but in reality they work more like junior project managers that have never actually written SQL or built any of the analysis or visualizations themselves.

If you’re organization leverages analysts that don’t actually write SQL, either because other people perform that work or because almost all of the analytics work is being performed in Power BI or Tableau, then you might have a few extra challenges to deal with and you might not actually have a strong analytics team at this point (as referenced in Part 4 where you can’t easily perform proper QA inside of a visualization tool).

How to Get Started

Now that we’ve briefly covered some of the challenges that you will likely encounter, let’s talk about a few recommendations to getting started.

Approach

Given these challenges, when rolling out changes within your organization and getting other on-board, you have two approaches (or a hybrid) of either working top-down or from the bottom-up.

With a top-down approach, you’ll need to help senior management understand the problems, care about the problems, and make an effort to influence the changes that you desire. With a bottom-up approach, you’ll need to influence your end-users and have proper oversight to ensure that they continue to utilize the best practices and tools.

I’d recommend a hybrid approach, where you gain management buy-in, which will allow senior management to help communicate your message and align the team(s), and where you have the buy-in from your end-users. If you can find the passionate end-users and team leaders that believe in the solutions, they will hold their team accountable to the new standards. And if you have senior management buy-in, you’ll reduce the risk of having someone suggest that team members are “working on the wrong thing”.

Develop Training

Start by assessing the current team(s), their skill levels, and how it might be best for them to learn the new material. Explore the development of training material (or leverage existing) to help others configure their laptops, solve problems, and use the new tools and practices on a day-to-day basis. It’s important that your end-users feel comfortable, supported, know how and where to get help, and feel like they can work in a way where they aren’t going to break things or get into trouble.

Culivate Stewards

As I mentioned earlier, if you want to have any chance of success, you’re going to need to cultivate stewards of these tools and processes. The earlier that you can identify and involve these individuals, the greater the chance of adoption and success. These individuals will carry the message, pull people onboard to support the mission, and will help train and troubleshoot issues.

Try (and make it incremental)

Rome wasn’t built in a day and neither will your new way of working with these practices and tools. But if you can focus on one area at a time, building upon the previous learnings, you’ll eventually have a well-oiled analytics engine. I’d recommend starting with Jira since it is the glue for connecting so many components in our environment.

Start by ensuring that team members are creating tickets for every task that they are performing. Then build upon that practice by ensuring that team members are using Jira properly (with quality comments, details, updates, ticket linking, etc.). From there, you can focus on general code practices, comments, and documentation. And once the team understands code structure and convention, you can migrate them into Git as a shared repository. And finally, you can build a better architecture with visualizations, tables, and views.

Closing

I hope that you’ve found this series helpful and that these articles have shed some light onto the problems that lurk within your organization, even if nobody seems to be talking about the issues. While I’ve provide a strong framework for success, know that there are new tools being developed all of the time to help make life easier for you and your team. I’d encourage you to continuously explore these new tools as they are released to see if they make sense for you, your team, and your organization.

Thanks!