When organizations decide to invest in a major technology acquisition, they understandably want to ensure that their new tool or system is the best possible fit. Such purchases are major expenses, and the useful life of such investments is typically set at five years or longer — an eternity, as technology is measured. These are consequential decisions, and it’s almost never easy or cost-effective to “exit early” in order to migrate to an alternative.
Historically, many organizations purchased custom-designed systems to ensure that a system would meet the organization’s specific needs. Such unique solutions, however, are both slow and expensive to develop, require ongoing maintenance over time to ensure that they remain compatible with then-current technology (e.g., Microsoft Windows operating system updates and security patches). These solutions also may be difficult to update if the organization changes its own workflows — something that often happens when organizations merge or update their business focus.
In contrast to the custom-crafted approach, other organizations have elected to use only commercial off-the-shelf (COTS) tools and systems. This typically results in up-front cost savings and, often, lower maintenance costs over the life of the system. However, these tools typically do not — and cannot — match existing workflow. Like Cinderella’s step-sisters, organizations using pure COTS solutions are trying to squeeze themselves into a glass slipper that may not fit.
Both of these approaches have benefits and drawbacks. Is it possible to combine these two seemingly opposing philosophies into a common approach that yields optimum results for an organization?
Good Preparation Yields Good Results
Key to any successful technology deployment is a strong understanding of the organization’s needs. Moving forward without this key knowledge runs the strong risk of overlooking or misunderstanding key requirements.
There can be significant consequences if a tool is selected or designed with the wrong functionality. One long-standing way of collecting these requirements is to bring in outside consultants to conduct a needs assessment and write up the results into a report that will form the basis of a functional specification for a tool or system that meets these stated needs.
Consultants are not the only way to complete this process, of course, but gathering comprehensive system requirements is a detail-oriented process that may take extensive time not available to internal employees who already have full-time duties. The further process of turning these requirements into a written functional specification takes additional time and effort, and it may need an understanding of industry jargon, to ensure the specifications are easily understood by technologists. In the name of moving forward in a timely manner, consultants continue to be one of the fastest and least disruptive (though not necessarily the cheapest) ways for an organization to properly document its needs.
Regardless of who conducts the assessment, the questions at the core of a needs assessment remain relatively constant. At a minimum, an organization should answer the following questions, before evaluating any tool or technology solution:
- What overall need would this tool satisfy?
- What outputs (reports, charts, etc.) will be requested?
- Does this tool have to pass information to any other tools or systems used by the organization?
- Will this tool require special security for the information it manages or contains?
- Can this tool be run in the Cloud, or must it reside locally?
- What is the desired budget and timeline for deploying this new technology?
- Are there external events or deadlines driving this timeline?
- Who within the organization would be impacted by the new tool or system? Does this change anyone’s current job duties?
- Who is expected to operate and manage this tool or system, once it is deployed?
These and other questions will more precisely define what the organization would like to buy and provide a concrete basis for any product evaluation.
Moving ahead without a careful study runs the risk that requirements will change on the fly as additional needs are identified. At a minimum, re-configuration in mid-project will slow down a deployment. More commonly, additional needs will increase the implementation price, as additional programming or configuration is required. Worst of all, discovering additional needs during the process of deploying a tool may uncover the fact that an unsuitable tool has been selected.
Accept Change: Workflow Evolves with Technology
Few events cause as much employee tension as the introduction of new technology into an organization. Adding a new tool, or changing one solution for another, impacts employees in many ways.
Some tasks that were central to an employee’s daily work may suddenly no longer be required. Conversely, technology may now require new tasks that were not previously envisioned. Although organizations typically plan for new technology to support existing work and workflow wherever possible, they should also recognize that new tools might provide not just different ways, but possibly more efficient ways, of completing tasks. It would be a disservice to disregard such opportunities. The goal should always be similar or enhanced final work product, not the preservation of all previously required steps in the creation process.
Though perhaps not at first glance, this issue fits squarely into analysis of custom tool creation vs. a COTS purchase for an organization. Custom programming has sometimes been used to preserve existing organizational workflow, even when technology could provide a more efficient path to complete the same work. An organization’s analysis should be careful that the custom requirements documented during the needs assessment remain appropriately focused on organizational goals first and existing workflow second.
Technology Should Not Drive Core Organizational Functions and Goals
It is altogether too easy to look at a COTS product (or an applications development environment) and be impressed by a particular feature that it contains. However, when evaluating solutions, an organization should never lose track of its core needs. Adjusting internal workflow to take advantage of a new tool is one thing; adjusting the content of a key organizational product, because the tool cannot provide the desired and necessary output, prioritizes the solution ahead of the organization it ostensibly supports. The needs assessment and functional specifications are critical tools for reducing the likelihood that snazzy peripheral features might obscure the fact that a proposed solution cannot meet key requirements.
For example, one area where organizations should show greater flexibility is that of data reports. COTS systems may have specific ways of formatting and presenting data that differ — even materially — from the way that this information has previously been reported. For an organization, the most important factor to consider is whether a report contains all the desired information or not. If it does not, then it is important to understand whether it would be possible to develop an alternate report that meets the organization’s needs.
If the report does contain all the necessary information, but presents it in a new way, the organization should evaluate whether the presentation is weaker or merely different. In both cases, it may be possible to use a third-party reporting tool like Tableau, or SAP SE’s Crystal Reports or Business Objects to develop a report that not only provides desired information but presents it in a way that is effective for the organization’s needs.
Buying a complicated piece of technology is never easy. When an item is simple or inexpensive, most purchasers can use a basic “take it or leave it” approach to deciding whether a product meets their needs. However, complicated or expensive systems — like case and document management solutions — will require a more nuanced analysis.
There is significant potential for cost savings in using COTS products over custom-designed tools, but only so long as the COTS product can meet the critical needs of the organization. If no COTS product can meet these basic, fundamental needs, then custom programming, even with higher ongoing maintenance costs, may still be the best way forward for an organization.
This article represents the personal opinions of Mr. Jacoby and does not constitute an official position held by any of Mr. Jacoby’s clients or employers.