How Much Application Redundancy Is Ok?
Ben Pippenger: Hello out there and welcome to another episode of SaaS Me Anything. I'm Ben Pippenger, here to answer your burning SaaS management questions. Now I'm going to start today a little bit differently than we usually do on SaaS Me Anything, I'm going to start with a confessional. Disney Plus, Netflix, YouTube TV, paramount, Apple TV, Amazon, Peacock, HBO Max. I have to confess that I subscribe to all of these at my house. But is that okay? Sitting here I can justify each of them. However, if I'm being real, I could probably cut back. In business this type of redundancy across the apps you're using is just all too common. So what's the right balance? How much application redundancy is okay?
Ben Pippenger: In today's episode, we will cover why redundancy is so prevalent in SaaS portfolios today. What makes it so hard to fix. And then developing and executing a strategy to reduce redundancy in your stack. So let's go. First and foremost, let's define what is application redundancy. Application redundancy is when you have multiple different software applications that perform the same or similar functions within your company.
Ben Pippenger: From our SaaS Management Index, the top three biggest culprits are online training classes, team collaboration and project management tools. I would bet if you were to count the number of project management tools you know about, you probably would run out of fingers on one hand. It happens in abundance. No software stack is immune to redundancy, and it's often the number one thing we hear from prospects and customers that they want to address.
Ben Pippenger: So why is it so prevalent? Well, first reason why is that there's a lack of centralized SaaS management. Employees and lines of businesses are purchasing applications outside of processes, not knowing there was already a similar tool in the stack. Second reason is that employees are bypassing existing processes and purchasing policies and buying software directly on their expense cards and submitting them back for reimbursement. In both of these cases, this activity contributes to overall sprawl of SaaS within your companies, but also the sprawl of redundant software.
Ben Pippenger: So why is it so difficult to resolve redundancy? There are really two key reasons here. First one is internal politics. Oftentimes, SaaS tools are sponsored by, or preferred by different groups or business leaders within your organization. You should expect to face pressure or even objections even with cost savings numbers in your hand. Second reason is around change management. Consolidating tools isn't just flipping a switch. It requires enablement, operational support, data migration, and a clear communication strategy and timeline in order to be successful. The goal here is not to completely eliminate all redundancies. In fact, some redundancies may be okay.
Ben Pippenger: How do you determine the right amount of redundancy for your organization? Well, here are a couple things to keep in mind. Let's reflect back to my confessional from earlier where I listed off all those different streaming services. At my house on the weekends, we typically like to watch Premier League soccer. You can catch some of those games on regular cable or through YouTube TV, which is the method that we subscribe to. But a lot of those games are only available on Peacock. So that is what helps me justify the fact that we need both YouTube TV and Peacock. It's a feature that Peacock has that YouTube TV does not.
Ben Pippenger: So what do you need to consider when you think about redundancy in your business? First thing is, you need to consider just looking at the amount of redundancy software you have. How do I want to address this? How big is the problem? What's the biggest impact that I could have by helping remove redundancy? Second thing you need to consider is how aggressive do you want to get with removing redundant applications? Do you want a policy of, we don't want any redundancy and we're going to remove everything? Or maybe you're looking at an overspending figure or spend target that you want to cut back, and that's going to be the guiding factor for which applications you're going to be pulling back from from a redundant perspective. And then third thing to consider is your company culture. What is your company culture for change? What is your appetite? How much can you endure? There is a decent amount of change here when you think about consolidation and moving people from one app to another. So definitely take that into consideration as you're thinking about what your strategy is going to be for removing redundancies from your environment.
Ben Pippenger: A couple additional considerations to think about as you are thinking about which apps you want to remove. Number one would be features and functionality. In my example earlier I shared around Peacock and YouTube, that's exactly the factor here that helps me determine that I need both of those services. There may be specific features or may be specific functionality that redundant tools have that require you to have both. The second thing you consider is preference. Employees and people are going to bring preferences to work. They're going to want to use certain tools to get their jobs done. So definitely take that into consideration when you're building out your strategy.
Ben Pippenger: Another business example here would be when you're looking at project management tools, engineering teams are often going to be using tools like Jira to manage their backlog, get visibility to roadmap, and communicate out timelines. Teams like marketing may be using tools like Asana. So definitely different preferences as well as different features that each of those tools have that may justify the need to have both of them within your inventory of SaaS applications.
Ben Pippenger: So what are the steps you need to take to rationalize the redundant apps in your stack? First thing is to start by getting a picture of what you have. So you need to understand how many applications you're using, how much you're spending on each application. What the subscription costs are. The life cycle of each application. Specifically think about the start date and the end date. As you think about removing redundancies, those are really important dates to have, so you know when to notify and cancel subscriptions. Understand who owns each of these applications, and then the categorization of the applications by functions so you can complete that redundancy analysis of your inventory.
Ben Pippenger: Next, you need to understand the value you're getting from all these applications. Really take a close look and examine the ROI you're getting from each app or other quantitative metrics that are important to understand and how those are going to be impacting your key business objectives.
Ben Pippenger: Outside of the data, it's also important to have conversations with the line of business users as well as your end users on the value they're getting from the tool. This is often an indicator of the potential pushback you may receive when sun setting a tool. But it's also informative in knowing where to eliminate. Understanding their sentiment toward the application, whether they're using it and why and how they're using it.
Ben Pippenger: Last thing here is to identify what you can eliminate, consolidate and replace. Do you have multiple instances of the same application you can consolidate? Do you have multiple versions of the same application function? So for example, the project management function we talked about earlier. Do you have applications or application suites such as G Suite or Microsoft 365 that have functions that overlap with existing tools?
Ben Pippenger: And then how do your utilization usage rates compare across those similar applications to determine which ones to remove? As they say, even the best laid plans can go awry. No matter how well you plan and strategize, you must have executive sponsorship to make your rationalization efforts successful.
Ben Pippenger: The big takeaway here is that redundancy is okay, but you need to create a strategy for how to be smart about it. First thing is you need to know what you have, understand what those tools do and the value they deliver to your organization. Second, develop a strategy for redundant apps that takes into account your overall savings goal and your organization's appetite for change. And then last, align your strategy to a timeline and action plan to remove the targeted apps from your SaaS inventory.
Ben Pippenger: All right, that's it from us today. We will catch you next time.
Redundant applications get a bad rap. Between wasted spend, low adoption, and operational inefficiencies, you’d think eliminating all redundancies would be the answer. Think again. In this episode, Ben Pippenger explains when application redundancy may be ok, factors to consider in your strategy, and best practices to consolidate your software.
Have a question you’d like answered on SaaSMe Anything? Submit yours here.
- [00:08 - 01:08] Introduction, Ben has a lot of streaming subscriptions, addressing redundancy
- [01:11 - 01:47] What is application redundancy, and what are the biggest culprits?
- [01:47 - 02:22] Why is app redundancy so prevalent?
- [02:22 - 03:05] The difficulties of resolving redundancies
- [03:04 - 03:36] Determining the right amount of redundancy for your organization
- [03:36 - 04:33] Considerations for tackling organization redundancy, the scope of the problem
- [04:33 - 05:04] Features and functionality, app preferences and favoritisms
- [05:29 - 06:04] Steps to rationalize the redundant apps in your stack
- [06:04 - 06:18] Understanding app value and their ROI and importance to business objectives
- [06:18 - 06:42] Anecdotal data and feedback about apps from end users
- [06:40 - 07:03] Identify what you can eliminate, consolidate, and replace
- [07:03 - 07:20] Utilization usage rates in understanding what to remove
- [07:18 - 07:47] The big takeaway on redundancy
SaaSMe Anything is the bi-weekly podcast that brings clarity to the chaos of SaaS, hosted by your resident SaaS expert and Zylo co-founder Ben Pippenger. Connect with Ben on LinkedIn here.