So, you have identified a need in your business for which you believe would be a great candidate for a software solution.Now
question is …
Do you “run off” and engage (one or more) developers to build this software system(s) for you?
And/or …
Do you “run off” to “nearest” and/or your favorite on-/off-line software store and buy a commercial-off-the-shelf (COTS) package solution, and if so which one?, to meet these business needs?
Which one of these alternatives is most efficient and (overall) cost effective solution to satisfy your business needs as soon as possible?
That is “The Question”!, To Buy? or To Build?, isn’t it?
Getting answer to this question is actually not nearly as difficult as you might imagine! ;)
All you need to do is execute a “Buy vs. Build” analysis and/or a Software Selection process for type(s) of software that meet these of your business needs and chose best, most efficient and (overall) cost effective solution, right?
The “Big Boys”, larger companies and corporations, often perform, and/or engage consultants to perform, a formal “Buy vs. Build” analysis and/or a Software Selection process on many to all of their significant software purchases.
You should execute a “Buy vs. Build” analysis and/or a Software Selection process, for any significant software purchase, before you decide whether it would be most efficient and cost effective, in long run, to build an application “from scratch” vs. buy a COTS (commercial-off-the-shelf) package, and if so which one will best fit your current and future needs!
This may save you a significant amount of money, time, effort and *headaches* in both short term and in long run!
As otherwise, you may end up paying to “recreate wheel(s)”, which really doesn’t make sense, does it?, and therefore none of us wants to do, do we?
Or …
Purchasing a package only to find that it doesn’t (and possibly can’t) meet your needs and/or cost of modifying such a package to meet your needs is prohibitive, in which either case you will most likely “scrap” this package (now a.k.a. “shelfware”), you just bought and paid for, and pick or build another one and possibly repeat this whole (costly) cycle again, you know?
We will not have luxury of going into detail on either how to perform a formal “Buy vs. Build” analysis, as this would require extensive discussions of how to define, analyze and estimate software development projects for which there are many books on these subjects, and/or how to execute a formal Software Selection process, as this is a topic for which whole Methodologies have been developed and are used (I know, as I assisted in initial development and used just such a Software Selection Methodology for one of largest global software and services corporations ;)).
We will, however, in this article, attempt to outline some of factors that you should consider when performing your own “Buy vs. Build” analysis and/or Software Selection process(es) for yourself.
Firstly, in either case you will need to define (and prioritize) your requirements / selection criteria such that you may evaluate how each of these “Buy vs. Build” alternatives will meet your immediate and long-term business needs, right?
Further, throughout these processes, you will want to insure that you compare these options in terms of “apples to apples”, you know?
Therefore, I would recommend that you compare both(/all) of these options in terms (of “Total cost of ownership”) including total time and cost to get application into production and/or market and total cost of supporting and maintaining application for its expected lifespan.
The “formality” with which you execute these processes should be proportionate to your investment (in terms of long-term / “Total cost of ownership”) in application and its criticality in your business.
First, let us consider “Build” option.
Some of advantages of “Build” option include:
1) You get an application specifically developed to satisfy your business requirements/needs and designed to fit your specific business processes.
2) It is more likely that you will be able to adapt your software system(s) to changes in your business needs and/or processes, as you would either presumably have application source code and/or access to original developers of it, right?
3) You may develop your new application(s) to interface and “play nicely” with other software in your overall application architecture.
Some of disadvantages of “Build” option include:
1) The typical project duration from conception to production(/market), through complete software development life cycle, for a custom developed application may be significantly longer than that for implementing a package solution.
2) The initial development costs of producing first release(s) of your application(s), including associated documentation and training materials, are typically higher than those for purchasing a package solution.
Briefly here are just a few of additional factors that, IMHO (in my humble opinion), you may wish to consider in determining whether or not it is best to “Build” an application “from scratch”, including:
1) In addition to estimated “coding” time and cost, make sure you also consider all of time and possible costs to complete definition, analysis and design phases, prior to “coding”, and subsequent testing and implementation phases required to complete overall software development life cycle for you application.
