Training Tech Stack Audit: How to Cut Redundant Tools

Training Tech Stack Consolidation: How to Audit and Cut Redundant Tools

Tech stack consolidation in training means auditing every tool that your L&D department uses, including LMS, authoring, virtual delivery, compliance tracking, survey, and reporting tools, etc., and either killing off or merging those that duplicate functionality, lie dormant, or aren’t worth the license fee anymore. Tech stack consolidation is just another name for something IT departments have been doing with their software stacks forever but adapted to the peculiarities of the training technology stack.

If you have to make a list of all the systems that you access during your workweek as part of your training function, can you do that? The fact is that most L&D directors simply cannot, and it is precisely the root of the problem. An average enterprise-level L&D function operates between 9 and 12 different systems, such as an LMS, content authoring, virtual classroom, compliance tracker, survey tools, two or three spreadsheets that no one wants to refer to as the systems, as well as several point solution tools for a specific issue you encountered some time ago.

And yet, this whole stack didn’t appear overnight and hasn’t been developed intentionally. This stack was formed from one perfectly sensible decision to the next, until now it costs you your budget, the quality of your data, and precious admin time.

This blog post will walk you through the process of auditing your training tech stack and will help you to understand which tools you should get rid of and what to do before talking to a vendor.

Why the Average Training Team Runs 9-12 Systems (And Doesn’t Know It)

Training tech stacks are not built intentionally; they develop organically. A new compliance mandate is introduced and a point solution emerges to meet the requirement. A department wants improved virtual classes and introduces its own webinar service. A manager needs rapid pulse surveys and decides to use a survey app for free. After a few years of doing so in multiple departments, you have nine to twelve systems in your enterprise training tech stack.

The quantity in itself is not the problem. It is the fact that these systems were not selected in a way that made sense within a unified stack. They were acquired as solutions to isolated problems without even investigating whether a similar system was already being used or whether a selected one could easily be configured for that purpose.

This is precisely what distinguishes a training tech stack audit from other software audits. The tools in question were not procured in an official procurement process, meaning that there is no record of what is currently in your stack.

This pattern repeats itself across many enterprise environments: according to Zylo, most enterprise software packages have been purchased independently from IT management, which is why stacks become fragmented without any decision to do so on your side.

In short, your stack developed not because you deliberately planned it but because nobody kept track of it.

What a Training Tech Stack Audit Actually Involves

A technical rehearsal audit is a thorough evaluation of every piece of equipment that the team utilizes in organizing, carrying out, staging, and recording a rehearsal, analyzed according to its ownership, price, frequency of usage, as well as several interdependencies.

It is not a catalogue of actions with equipment, that bothers people. When done properly, it answers four questions:

• What exactly do we have? All equipment we can have access to, not only that which is under control of our IT.
• How is it used? How regularly is it being accessed, who uses it?
• What is its price, overall? Licensing, integration protection and administration time necessary for its working.
• What does it include? A list of similar devices that solve the same problem in the similar way.

You don’t just skip to “let’s make some cuts.” If inventory is not done, there’s really no other option but to guess. Guessing is where teams end up cutting something that is being used three departments later while also preserving a tool nobody used for the past six months.

An audit is a matter of hard figures and numbers, not of discussions on tools that are liked or disliked by someone.

The Real Cost of Training Software Sprawl

The costs associated with training software sprawl often appear not as a single large item on a budget sheet but as many little ones which accumulate, together with a host of operational expenses that do not make it onto the spreadsheet.

Before looking at the costs there are two main categories to consider:

Direct costs

• Redundant licenses that all entail use of overlapping tools (e.g., two survey platforms, two authoring tools, and two different ways to run webinars)
• Expanding contracts that lead to automatic renewals when no reevaluation of the necessity occurs
• Expenses related to integration and maintenance of systems not designed to interact with one another

Hidden costs:

• Scattered learner data throughout systems generating data fragmentation and lack of unified view over progress, engagement, or compliance
• Lost time spent on switching between platforms, entering identical data repeatedly, and reconciling reports manually
• Unstable learning experience with employees being to remember which application works for which course

Sprawling data is the most costly problem even though it is the hardest to quantify, to give an example, if you keep training data in one system and compliance data into other; then it will be impossible to answer the question ‘does the training work?’ without manually putting data together each time!

We mention this same operational burden more extensively in our Training Operating System blog, sprawl not only costs money, but does not allow you to run training like a connected system.

The largest cost of sprawl is not the license fee, but fragmented data utilized.

How to Audit Your Training Tools: A Practical Worksheet

Here is a simple approach you can employ without spending on anything. Give a period of two to three weeks for this process to complete, as it is not a quick one-time job if you want to do it correctly.

Step 1: Make a complete inventory list. Gather information regarding all possible sources that may give any clue about the tool such as financial/AP records, identity provider logging, departmental budgets, and conducting a simple survey among department leaders asking “What are the training tools that organizations are not informed of?” The last step is important as a considerable percentage of training tools gets procured without the central process.

Step 2: Record the details for each tool. For each system record the following information:

• Name of the tool and vendor
• Main function (LMS, content creation, virtual delivery, compliance monitoring, surveys, reporting, etc.)
• Owner/departments
• Annual spending
• Contract ending date
• Active users in last 90 days

Step 3: Organize tools based on function instead of name. Divide into groups delivery, content creation, tracking/regulatory compliance, communication, and reporting. At this point overlaps become visible, you may discover that there are three tools for virtual delivery and none for skill reporting.

Step 4: Evaluate the usage of the tool and its effectiveness. For each tool assess the level of acceptance (how many individuals have actually logged in), importance (what happens in case of its absence) and integration complexity (how the tool integrates with other systems). In case a tool has low acceptance and low importance it is a good candidate for consolidation; if a tool has a low acceptance but a high importance level it means that the further exploration of this issue is needed.

Step 5: Chart the overlaps. For each category with more than one tool, ask the crucial question: can any of these tools perform the tasks of the other using a suitable configuration, or do they actually have different roles for different audiences, compliance criteria, and regions?

By the end of this process, you will have compiled something that many training experts have never seen before: a single, evidence-based outline of the entire tech stack. Tools should not be rated solely on cost, as this can lead to poor usage of the tools instead of a properly designed tech stack.

In short: going through five steps leads you to an evidence-based map of tools, every later decision concerning the tech stack being merely a guess.

Redundant vs. Necessary: How to Tell the Difference

Having a Duplicate Tool doesn’t mean it is a Dummy Tool; therefore, treating them both in the same fashion leads to ineffective consolidation projects among the stakeholders who use it. Before dashing to eliminate a tool from the list, ask yourself the following questions in order to uncover if it really is redundant:

Likely Redundant if:

• There is already another tool in the portfolio covering the same core functionality?
• The tool is mostly used by one department only, or the number of users is really small?
• The tool has been bought just to tackle a temporary issue which is no longer relevant?
• The tool doesn’t communicate with the main LMS or reporting tool; as a result, its output data is not being used elsewhere?
• It is hard to justify its maintenance cost given the amount of usage it has?

Likely necessary if:

• It serves a compliance or regulatory need that none of your other solutions can meet
• It works with a specific audience (or a union agreement, regional requirement, or specialized certification) that your main platform is unable to serve
• Its removal would entail recreating a workflow that your team utilizes daily
• It is widely used on a regular basis and integrates smoothly with the rest of your tools. The aim of this step is not to reach a certain target number of redundant tools, but to create a solution stack that comprises only those tools that indeed justify their inclusion in it.

In simple terms, being redundant does not mean being overlapping; the criterion is whether a particular tool is justified.

Common Mistakes Teams Make When Rationalizing Their Stack

Several themes can be observed with organizations that are working on narrowing down their tooling options without having gone through the process of auditing their usage:

• The act of cutting based solely on price. Choosing to cut the least costly tool is often not the best choice, especially if it is something that the compliance team is consistently using.
• Neglecting stakeholder feedback. If people find out about the decision to remove a tool after the fact, it may take even more time and resources to win their trust back than it would have taken to keep the tool.
• Accounting for only one instance of an audit. If you do not put a system in place for auditing at least one time per year, you might find yourself in a position where you are only several systems lower than what you had before.
• Trying to consolidate systems without the audit first. Acting before you comprehend each current tool’s function is equal to missing vital workflows, which can be problematic when changing platforms.
• Disregarding contract expiration. Getting rid of a tool after so many months into a two-year contract allows for no savings whatsoever! Be sure to look up the expiration dates.

It appears that in most cases rationalization fails not because of the strategy employed but due to management and timing.

From Audit to Action: What Comes Next

An audit alone does not consolidate things; it provides evidence for a decision. Once you have your inventory, usage data, and list of redundant versus necessary applications, you are in a position to make decisions about which software to eliminate immediately or as it comes up for renewal, and which applications and software systems are core to your operations.

Those are the questions that we tackle in the One Platform, One Contract piece, how to transition from “this is what we discovered” to a connected system of training applications that will simplify your program while still providing the functions that you need.

At this time, the audit serves as a practical yet vital primary step. A number of training groups have not done audits. The ones that have typically uncover more duplication, and savings, than they had planned on.

Ready to run your own audit? Download our training technology audit checklist to guide you through the process of inventorying, scoring, and identifying and eliminating redundancies.

The audit presents the argument but the results can only be achieved through implementation.

FAQ