THE CHOICE: PACKAGED OR CUSTOM SOFTWARE
Today, more and more managers face the task of implementing software solutions to solve operational challenges involving quality, business process improvement, compliance, data management, customer service and more. Typically, the choice boils down to selecting between off-the-shelf packaged software systems or developing custom software. It is not an easy decision, and it is one the company will live with for years to come.
Off-the-shelf packages are widely available and often appear to cost less than custom developed software. And on the surface, packaged solutions may seem to provide all the features necessary.
While custom software is generally thought to cost more and take longer to develop and implement, this may not be true in all cases. Custom developed software provides a company with control over design, better upgrade and maintenance options, and more agile functionality.
Before jumping in with both feet, it is important to take a close look at these assumptions. Several factors that are sometimes overlooked require an understanding of how the software is developed, the total costs of putting any given system in place, and intangible factors.
Below are 7 key factors for choosing between custom and packaged software solutions. While it is clear that custom software is designed for specific in-house processes (meaning it is ‘process centric’) and packaged software is intended for many customers, (or ‘market centric’), applicability in any given situation depends on many factors.
1. DESIGN AND DEVELOPMENT
Assuming functionality to be equal, it appears at first glance that there are only two main differences between custom software and packaged software: price and time to deliver. But let’s look a little deeper.
The design and development of off-the-shelf software may appear to be focused on the processes which interest customers. While this is partially true, the reality is that work priorities of packaged software developers center on their company’s specific marketing goals. Developers of packaged software are motivated to meet market specific objectives rather than those of a specific user. The end game is a product or a component of a larger product, not necessarily a solution to address an operating issue or a specific process.
According to Steve Sawyer with the School of Science and Technology at Penn State, for large packaged software companies,
“Finally, due to the rewards of being a first mover in this field, the packaged software industry has two ways to achieve success: developing a large installed base and/or creating new markets.” [i] (Sawyer 1999, 8)
The packaged software developers’ goal is supporting their own company’s marketing strategy, product sales trajectory and sales volume goals.
On the other hand, the thought process of custom software developers is ‘company focused’ and concerned with how the end product works when applied to the processes of their client. Users, project owners and stakeholders are engaged early and often in design and development, and the project progresses via continuous review and consensus meetings. Every effort is made to ensure the software works with the company’s processes and accomplishes the goals of process owners.[ii] As a result, custom software developers tend to be ‘process centric’ rather than ‘market centric.’
There are two additional and important design and development considerations: (1) the capacity of the system to integrate with existing software and, (2) compatibility with internal hardware.
The custom designed software can be planned with integration in mind. Existing software is not only known but can be utilized to test integration as development proceeds. For example, an internal sub-project may require tying together a new production control system with an existing accounting system. Adjustments can be made as design proceeds.
In the same way, any system design done internally will use a company’s existing hardware. Moreover, any new equipment requirements will take into account both the new system as well as existing in-place systems.
In the case of packaged software, integration with existing systems may be difficult or impossible. Support, warranties, upgrades, and functionality may all be negatively affected by trying to integrate the purchased package with existing internal software. Further, system hardware requirements are defined by the packaged system and may require new equipment additions or modifications.
2. IMPLEMENTATION
Each type of software requires a different approach to implementation. The major difference between the two is in the type of personnel tasked with completing the installation. Custom software is most often installed by the development team along with users. Purchased packaged software is installed by either internal company personnel or by third party contractors, neither of whom were involved in developing the software.
The custom development team must, as a natural part of the development process, interact with the process users and engage them in the project specifics. As a result, the development team and users are accustomed to working together and are familiar with the new system. Should the need for a change arise, the change request can be handled quickly, and the response can be almost immediate. All involved individuals are present and available to address the issues.
Installation of packaged software proceeds in an entirely different way. Original developers are rarely involved in the system’s implementation, have no interaction with company’s personnel, and, as mentioned, retain a market-centric focus. Implementation will most likely be handled either by the company’s internal process users or by an outside contractor. The downside is that the company’s implementation team will be unfamiliar with the system, or the outside consultants will be unfamiliar with the company’s internal processes. This confusion can slow down the implementation or create problems and miscommunications.
Also, when a system change is required, the change must be made through a formal request process. The change request must travel from the requesting company to intermediary personnel at the packaged software company who pass the request along to the developers. The change order process adds time to any request, and there are no guarantees that the changes asked for will be suitable for or even included in future programming.
3. PROCESSES
In general, many organizations may see more benefits from custom software development. The compatibility of software to a company’s operating processes might be the most important element in deciding between custom and off-the-shelf.
In addition to applicability to internal processes, custom software can become a vital part of the company’s brand promise. A custom-built, branded customer interface gives customers a personalized, tailor-made experience, plus rapid and accurate communication, providing a channel for direct sales and engagement, new product introductions, marketing offers, or general communications.
Packaged software generally provides an array of process options, which may or may not match what the organization needs. The result is that companies have to modify processes or accept a compromise in process effectiveness. In some cases, however, packaged software is designed to support ‘Best-of-Class’ or industry best practices and can actually help companies upgrade and improve their process efficiencies. Working with many different users gives packaged software designers the opportunity to select the very best process options to build into the packaged solution. Purchasing the software means purchasing these best of class process options.
4. COSTS
Packaged software is thought to be cheaper than custom software. This isn’t always the case, however, especially when total or hidden costs are taken into consideration. While it is true the purchase price of a package may be cheaper than the development cost of custom software, there can be additional costs over and above a company’s initial investment. For example, installation of packaged software may require hiring outside consultants or third-party implementer to install the system. Not quite so obvious may be costs associated with required changes to internal processes, required upgrades over the life of the product, additional personnel training or retraining, purchasing new hardware required by the system, or even adding personnel. Lack of integration may also add hidden costs as employees develop home-grown workaround systems to compensate for the lack of functionality.
Also, packaged software is sold under a license arrangement rather than an outright purchase. As part of the license agreement the purchasing company is restricted to a certain number of users or ‘seats.’ While this might work for some firms, others may find that the license provides for many more seats than are needed or provides for too few. In either case, the differences represent hidden costs for a packaged system.
On the other hand, time and effort required to develop customized software can be expensive. Not only are there programming costs, but the time to complete can be lengthy. While developers work on the custom software, process inefficiencies continue and business opportunities may be lost.
A manager weighing the buy/build options for acquiring new systems, should look not only at the obvious and visible costs but also at hidden and intangible costs. A thorough cost analysis can easily shift the decision from one side to the other.
5. SPEED TO IMPLEMENT
Implementation of packaged software can be done fairly rapidly in many cases. Mid-sized systems can take less time than large packages and can be up and running fairly quickly. With major packages such as Oracle, JD Edwards, or SAP, implementation time can extend over months or even years. Nevertheless, packaged software is readily available and comes ready to install. All development, design, and testing has already been completed.
Custom software, on the other hand, may take a good bit of time since the software must first be designed and developed in-house using personnel that will likely be involved in other activities. The development schedule may be delayed if in-house personnel are not available or are sidetracked onto other projects. Further delays could occur if the company has plans to change the processes or expand the business. Delays at the front end of the project will, undoubtedly, mean delays with final implementation.
6. SUPPORT AND UPGRADE / TRAINING
Once packaged software has been acquired, the ongoing development of upgrades, versions, and patches tends to track with the supplier’s overarching marketing approach and not the user’s specific process requirements. Along with routine process-driven changes, often, the packaged software company will add functionality designed around marketing goals. These kinds of upgrades may not be needed or used, but will ultimately be paid for by the customer.
In some cases, the upgrades or version releases involve additional costs. If new version releases occur too often, then this can result in system ‘churning’ and impact operating efficiencies as personnel must constantly adapt to revisions and changes. Also, ongoing system support and maintenance may be terminated for a particular package even if the current system is working well. Without continuous support, a company must decide whether or not to purchase a new version or even a different system.
Also, packaged software often requires a significant amount of training which can be done either by contract trainers or by sending personnel to off-site training centers. Both of these efforts are costly.
Custom developed software avoids many of these problems but, in doing so, presents others. In house support can be close at hand, but the availability of staff to provide the support may be an issue. As process changes dictate system changes, development staff may be overwhelmed by the amount of effort required. In other cases, important, knowledgeable staff members may leave the company taking with them ‘brain knowledge’ which leaves behind a knowledge gap. Also, because all interaction is internal to one company, cross fertilization of methods and best practices that might be gained through a package system, is missing. Developers and process owners will follow the practices they know and could inadvertently program inefficiencies and unnecessary cost into system functions.
It is possible to minimize training costs because both developers and users have worked with the system since its inception. Also, all training can be handled in-house by the same individuals responsible for designing and developing the software originally. Once again, however, the availability of staff to complete these tasks could be an issue.
An excellent option for a small to a mid-sized company is to partner with contract developers who can manage the design, development, implementation, and support in much the same way as internal staff but can be available on a consistent, ongoing basis. A contract team serves as added personnel at a time when workloads are heaviest, but are temporary and will leave when no longer needed.
7. FLEXIBILITY
Custom software development focuses on satisfying process owners and is, by definition, process centric. Because custom software is designed internally, the resulting system provides a level of flexibility not available with packaged software. Changes can be implemented as needed without sending change requests through various levels of organizational bureaucracy. Custom software is tailored, agile, and, in some cases, more cost effective than packaged software. It can be an excellent choice for small to medium sized companies.
The tailor-made advantage is not available with packaged software. Buying off-the-shelf provides customers with a unique set of predefined functions from which each customer must select those that are most applicable. Any flexibility for these systems will be represented by whatever options are available within the package itself. When a change is needed, a change request must be submitted through the supplier’s organization and which, may or may not, generate any results or may require a great deal of time before the change is included in the software. Lack of flexibility is offset by a greater scope and more features within a packaged system. Cross fertilization of industry best practices occurs more easily with some software packages providing a secondary benefit to its customers.
CONCLUSION
The choice for selecting between packaged software or development of custom software applications is often a difficult decision. Packaged software is widely available and often has a lower cost than custom built solutions. Custom developed software provides a company with complete design control and more agile functionality.
ABOUT ESPRESSO MOON
At Espresso Moon, our custom designed software will fit your business precisely and provide for you the functionality you require. From the very beginning, we work with your in-house subject matter experts and process drivers to define the processes around which the software will be developed and to ensure that the software fits your requirements exactly as you envision. Espresso Moon is recognized as a leader in custom designed software and has developed nearly a thousand bespoke software solutions for companies across the globe and throughout the country. If you are looking for a sleek, agile, custom design software solution, consider Espresso Moon as your choice for software development. Give us a call today, and we can arrange a meeting to discuss your requirements and to develop a plan for designing and developing the software package you require.
REFERENCES
[i] Steve Sawyer, Packaged Software: Implication of the Differences from Custom Approaches to Software Development (School of Sciences and Technology, The Pennsylvania State University, 1999), p8.
[ii] Ibid, p7-9