It would be difficult to overstate the positive impact informed software purchasing can have on an organization. In the private sector, smart planning and implementation have become a vital part of the migration from dated legacy systems, a move that can pay dividends both now and in the future. Looking past the security and operational setbacks outdated software solutions can pose, a strategic outlook can increase productivity to a dramatic degree and help agencies derive even more value from their acquisitions.
First, however, those acquisitions need approval by stakeholders—a major concern anywhere in the public sector, but particularly when the public organization is a first response agency. Whereas decision makers in a business may face only a single level of approval, purchasers within police, fire, and EMS departments may potentially submit to oversight from immediate superiors, higher-level personnel within the city or state, and others within the chain of command, along with taxpayers. Each of these stakeholders are less willing to accept bloated software purchases than they may have been in the past.
While it may seem that increased public spending on software would make purchasing easier, more budget does not necessarily mean less scrutiny. Agencies everywhere have spent more than ever on their digital perimeters in recent years—a fact reflected in the explosive growth of industry-focused software—but financial accountability is still a fact of life anywhere tax dollars are spent, making even minor purchases subject to multiple layers of oversight.
Because of this, persuasion and explanation are as integral to a successful software purchase as technical acumen, a need that only grows in importance as the agency’s software budget does. Sharpening these abilities—and touching points ,such as an explanation, stakeholders enjoy hearing, relative to their roles and functions—is a must, especially when the person holding the gate does not possess sufficient expertise to understand the proposed buy on its technical merits alone.
Whether an agency is explaining an acquisition after the fact or seeking permission to cut the check, effective explanation comes down to identifying needs and finding products to meet them. Consequently, the agency should research internal flaws, shortcomings, or inefficiencies before any substantial external fact-finding (i.e., searching for potential software) occurs. For instance, they may recognize a need for better training software, uncover the ground-level problems that create that inefficiency, then begin the hunt for qualified products—a substantial difference from recognizing the need and immediately commencing the hunt. This process, most commonly called an internal needs analysis, is key to finding the correct tool and hugely helpful when finding talking points to raise with decision makers.
Most problems isolated during the analysis will come from frank discussions with people who will use the proposed software. The company purchasing a new training management platform, for instance, buys a product with potential to touch most corners of the institution: ground-level employees, their direct managers, current training personnel, and legal/compliance staff, among others.
Once identified, ask these staff members questions regarding relevant problems they face, either via formal interviews, or via a questionnaire:
The answers, along with any figures you may collect, such as how much it costs to train a recruit from the start of academy to graduation, for one example, should form the basis of your research. Agencies needing to explain an existing purchase, meanwhile, can follow the same general steps by speaking to relevant employees about problems the software has solved and processes it has improved. Approaching analysis with directed purpose makes it easier to elaborate on factors that add value to the upgrade, making it an important part of your effort to explain a software purchase.
The explanation process begins in earnest once the legwork is done and a suitable upgrade has been identified or purchased. Departmental structure, work division, and role duties will determine the specific offices a buyer must query. Most stakeholders voice concerns from a financial or practical standpoint.
Note here that there will sometimes be crossover between these two camps. Even in situations where one “gatekeeper” is concerned with both aspects, however, the upgrade’s ability to elevate procedural aspects of the job will be a key point of focus. The cheapest solution is not the best if it does not meet the baseline needs uncovered in your analysis.
Though it focuses on the construction industry, a piece in Electrical Construction and Maintenance offers several useful tips for developing function-focused talking points, the most useful of which comes down to four words: Small upgrades aren’t enough. Without “significant improvement,” the article says, stakeholders are less likely to tolerate the disruption and cost of implementing a new system or process. On the other end, temporary disruption and permanent change become increasingly easier to stomach as they improve and make the processes more efficient.
A growing trend in public-sector software platforms, the automation of core practices, underscores this idea. Envision a fire department that uses dated software and inefficient paper-based processes to track employee progression. While undergoing the process of digital modernization, they may experience short-term disruption (entering paper-based info and data from old systems into the new tool) and long-term change (utilizing a cloud-based system instead of the paper files long-entrenched employees are used to using). The benefits are certainly hard to ignore: supervisors are time-strapped, giving automated compliance checking and instant attaching of test scores to relevant profiles (as opposed to paper-based test taking and grading) immediate value.
Cross-functional interplay is another point worth impressing upon supervisors with an operational focus. The more functions a system can group under a single umbrella, the easier it is for appropriate people to access all of them—namely, supervisors—to view all relevant data in a single place. A given supervisor in a non-technical role may not understand exactly how cloud technology works, but they can undoubtedly appreciate the ease of viewing records from multiple interrelated sources in a single place, using a single login.
To that end, do not be afraid to approach functionality conversations from a “what’s-in-it-for-you” standpoint. People tend to view work and conceptualize performance from their own perspectives, putting themselves at the center of their own professional universes. Since most first response work is built on chain-of-command, explaining the group benefits (such as, “everyone will be able to take tests from a computer”) and the individual ones (“you’ll be able to view range scores and POST requirements from a single system”) with equal gravity is a smart move.
Conversations with financial stakeholders will naturally take a more objective, concrete bent than those held with performance-minded gatekeepers. Points from your own research—costs of current operations and financial inefficiencies effected by outdated systems or manual processes—should come alongside capital (hardware and servers, for two examples) and operational (monthly/yearly licensing, added warranties) costs. Come prepared to discuss, in detail, anything that may cost your agency above its current expenditures.
Potential financial benefits should be raised as counterpoints to any costs an upgrade might carry. Software vendors routinely publish this information on their websites or in industry whitepapers. They may be able to furnish data points more tailored to your specific needs at your request. Per-user, per-action, and per-year savings are three common figures a vendor may offer. Going the extra step and putting these in the context of your office’s current operations is a good way to drive the benefits home clearly and concisely.
Long-term costs may be somewhat harder to define, but will likely be every bit as important to your argument. This makes the flexibility and scalability of a cloud-based system a can’t-miss talking point.
Consider the methods used to build your current collection of digital systems. Tools were likely purchased as needed in the past several decades, with little regard for upgradability or interplay with future systems. Multiplied across the whole of the industry, it is easy to see why digital perimeters in responder organizations tend to be piecemeal affairs, and how modular, cloud-based platform offer numerous benefits in contrast. Built to work together, reducing siloization and the need to purchase costly “middleman” software from outside vendors, each acquisition increases the functionality of the whole. When built for individual purposes, the modules tend to cost far less than full-blown individual software products.
Just as important, cloud-based tools are built for continual refinement. Unlike the old days, a tool you buy today can remain on the cutting edge indefinitely, forestalling or outright removing the need to buy upgraded software for the same purposes five to ten years from now.
Cloud’s scalability and ease of access make it easier to adjust your purchase to future hiring and personnel needs. Using our training example, sending your entire roster to a daylong seminar across the state is an incredibly costly and logistics-heavy affair. Doing the same thing in an online learning module represents significant savings and can support a staff of tens or hundreds.
Combined, these factors position cloud as a technology of great value to financial gatekeepers, undoubtedly a reason agencies and governments at all levels have consistently increased their investment in the technology despite upfront costs, per Washington Technology. They also make cloud an excellent benefit to pitch to taxpayers, who tend to focus on the financial over the productive: A tool that effects long-term financial efficiency, particularly with regard to historically expensive government technology purchases, is one more likely to gain widespread support.
Depending on the context, the need, and the process being upgraded, there is little doubt software purchases can be a tough sell. That can be the case whether the solution has already been purchased, or you are preparing to pitch the idea to your superiors or a questioning public.
Understanding your audience and the points they are most likely to appreciate is undoubtedly the smartest strategy to employ when asked to explain, defend, justify an acquisition. Executing requires a deep understanding of your agency’s inner workings, its needs, and the ways your proposed solution can improve the former by addressing the latter. Be sure to make this knowledge a focal point of your research; by preparing yourself to pitch realistic benefits and field any question that come your way, it will be that much easier to keep your purchase above reproach from internal questioning or public scrutiny.
Posted on Mar 13, 2019
