Looking for a sure-fire way to scare your IT dept.? Tell them the board wants recommendations on a new software platform - buy or build - to vote on at the next meeting.
When nonprofits become frustrated with their current technology (or they realize it has become out of date), they decide to overhaul it. This is a very complicated task and rarely done more than once every five years, so the team that did the last one is generally not around to shepherd the project again. All of the lessons learned are gone, leaving the new team with the same problems but without the benefit of experience.
Buy vs. build is a complicated decision. The smart way to approach this problem is through a series of questions. What do we need the system to do? What are the costs and time limitations? Does the existing system need to be scrapped entirely, including institutional knowledge of using the existing system? Is what we need now what we will need in a few years? How do we avoid the huge expense of another overhaul in another seven to 10 years?
Point/counterpoint: Buy vs. build
If money is no object - or an organization has a complex, unique IT environment - building software can be an attractive choice. Built specifically for your association, the system will do everything you need it to do, while an off-the-shelf product might need to be tweaked or modified to accomplish the same. However, there are risks. Development delays and cost overruns are common to custom development projects.
Planning for a custom solution also takes on a much higher priority than buying a product. E-commerce might not be on the technology roadmap for your organization for another three to four years, although it needs to be planned for in the initial project architecture. Otherwise, you might find that the e-commerce solution that best suits your needs won't integrate nicely with your current systems. Here, you'd be faced with another expensive decision. An existing product will most likely have a ready-made ecosystem of partners that actively update and integrate with each other, lessening the risk of incompatibility when you are ready to add e-commerce (or any other platform expansion).
As the custom solution begins to age, support, legacy code and new technology integration become factors. Being "custom" means that there aren't going to be a variety of support teams that are already familiar with your system and who can offer competitive rates for the work. There also won't be updates being developed periodically to keep your (now aging) system current.
Buying software alleviates these forward-planning issues and several more. While a product-based solution might not provide 100% of the functionality that a custom solution would, the longevity, cost control and stability of the technology might be more important. For example, buying a product means there's a company who stands behind that product, actively updates code and features, and supplies support.
Take into consideration staff's use of the system now and in the future. Will everyone need to be trained because you have a custom solution - hence, THE ONLY one? Or, could there be a population of recruits who already understand the basics of how a product solution works? The later scenario will shorten the learning curve for new staff for many years and allow them to be more productive sooner.
When buy actually means build
There is a trap some fall prey to even when following the previously discussed advice. This is termed "consultingware." Packaged as a product purchased through software vendors, this is actually a build situation. The challenge here is that it almost always leads to an incomplete solution, specifically designed to require customization services, and is nearly impossible to upgrade without substantial cost.
Providing continued customization services helps many software vendors reach their revenue goals. If the organization either cannot afford or chooses not to continually revisit this customized software system, the result is obsolescence of the product over time.
"True" software companies, on the other hand, try to minimize the amount of consulting service required, so they can move on and sell and install their software for the next client. "True" software companies maximize their customers' initial software investment by protecting their upgrade path.
It is no wonder many organizations are confused. Most software vendors operate in a way that almost guarantees that the organization will get stuck in time with unsupported versions of software. To make matters worse, out of self-preservation, they all say they can upgrade (largely through customization of the base product). While that might be at least partially true, organizations often do not understand that the more customization is added to the base product, the larger the problem of future upgrades becomes.
Sometimes consultingware vendors say things like, "we will roll our customizations into your base product." The fact is, it takes incredible management talent to keep track of all the customizations to a client's base software. What's more, most customizations are extremely technically challenging to integrate with other products. For that reason alone system implementations from software consultants often come in over budget, and take much longer than planned.
In the face of the question "to buy or build a new software system," the choice seems to break down to fancy over functional. Build being the fancy, Maharaja option. Buy being the functional, less feature-rich option. Once you really dig into the process, there is much more to think about. Being happy with the choice a few years in the future (long-term satisfaction) is often not part of the process. Consider this: was this lack of planning five to eight years ago to blame for the process repeating today?
Details: Bob Alves is CEOof Advanced Solutions International, Alexandria VA, www.advsol.com.