So, you have identified a need in your business for which you believe would be a great candidate for a software solution.
Now the question is …
Do you “run off” also engage (one or more) developers to build this software system(s) for you?
And/or …
Do you “run off” to the “nearest” and/or your favorite on-/off-line software store also buy a commercial-off-the-shelf (COTS) package solution, also if so which one?, to meet these business needs?
Which one of these alternatives is the most efficient also (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 the 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 the type(s) of software that meet these of your business needs also chose the best, most efficient also (overall) cost effective solution, right?
The “Big Boys”, larger companies also 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 also cost effective, in the long run, to build an application “from scratch” vs. buy a COTS (commercial-off-the-shelf) package, also if so which one will best fit your current also future needs!
This may save you a significant amount of money, time, effort also *headaches* in both the short term also in the long run!
As otherwise, you may end up paying to “recreate the wheel(s)”, which really doesn’t make sense, does it?, also 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 the 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 also paid for, also pick or build another one also possibly repeat this whole (costly) cycle again, you know?
We will not have the 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 also 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 also are used (I know, as I assisted in the initial development also used just such a Software Selection Methodology for one of the largest global software also services corporations ;)).
We will, however, in this article, attempt to outline some of the 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 also 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 the “Total cost of ownership”) including the total time also cost to get the application into production and/or market also the total cost of supporting also maintaining the application for its expected lifespan.
The “formality” with which you execute these processes should be proportionate to your investment (in terms of the long-term / “Total cost of ownership”) in the application also its criticality in your business.
First, let us consider the “Build” option.
Some of the advantages of the “Build” option include:
1) You get an application specifically developed to satisfy your business requirements/needs also 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 the application source code and/or access to the original developers of it, right?
3) You may develop your new application(s) to interface also “play nicely” with the other software in your overall application architecture.
Some of the disadvantages of the “Build” option include:
1) The typical project duration from conception to production(/market), through the 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 the first release(s) of your application(s), including the associated documentation also training materials, are typically higher than those for purchasing a package solution.
Briefly here are just a few of the 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 the estimated “coding” time also cost, make sure you or else consider all of the time also possible costs to complete the definition, analysis also design phases, prior to “coding”, also the subsequent testing also implementation phases required to complete the overall software development life cycle for you application.
2) Are you planning to manage the project, also project team(s), yourself? And/or are you planning to “outsource” part to all of the management of your project? What are the costs in terms of time, effort also money for each of these alternatives? Which of these alternatives has the minimum risks to the successful completion of your application development project?, These are *important* considerations as failing to complete the development of your application(s) may make pursuing this option very costly!
3) What are the costs – time, effort and/or money – to or else develop the documentation also training (if applicable) for your application(s)?
4) How do you plan to support the developed application(s)? By training “in house” staff to support it? And/or engaging external developers and/or support staff?
5) How do you plan to handle maintenance on this new application(s)? Do you have the source code? Do you plan to handle future maintenance yourself / “in house”? and/or Are you going to engage the original development team (assuming they are willing also available) to make any future additions and/or changes to your system(s)? If so have you negotiated / “locked in” a rate for these future maintenance efforts?
Etc. Etc.
Now, let us look at the “Buy” option.
Some of the advantages of the “Buy” option include:
1) The time to get a package solution implemented such that you may start using it also reaping the corresponding benefits for your business is typically quicker than that for building the application “from scratch”.
2) The initial purchase price of a software package, although it may be considerable, is often less than the (initial) custom development costs.
3) The software vendor may deliver regular maintenance upgrades to the software package, including a number of “bug fixes” and/or enhancements, which you may receive for a “fixed maintenance fee” such that you do not have to bear the costs of all these “bug fixes” also enhancements alone.
Some of the disadvantages of the “Buy” option include:
1) A COTS package may not satisfy all your business requirements/needs also may not fit your specific business processes well “out of the box”. The software vendor may or may not be willing also able to modify the package to better fit your business requirements and/or processes also even if so, this may be costly.
2) A software package may be less able to quickly adapt to changes in your business needs and/or processes. You may have to wait for the vendor’s next maintenance release to get the changes you want, or you may have to pay the vendor to make these changes specifically just for you also wait for them, or they may not be willing (and/or able) to make these changes to their software package for you at all.
Briefly here are or else just a few of the additional factors that, IMHO, you may want to consider in evaluating / selecting a package solution(s), as part of your “Buy options”, including:
1) What is the additional time also cost, if it is even possible / an option, to modify the package to satisfy your current requirements/needs? A “general rule of thumb” I have used over the years is that … If you have to modify 50r more of the “code” to make it meet your needs, then you are probably better off re-writing it “from scratch”, you know?
2) Is it maintainable?
Meaning, will you, the vendor, and/or developers you engage be able to modify the package to meet any changes in your current and/or future requirements/needs? If not, then this package may become “shelfware” should your needs change at some point, you know?
3) How well does it integrate and/or “play well” with the other applications in your overall application architecture?
If it does not “interface nicely” with other applications in your overall application architecture also it will need to, then you may find that you will need to have these interfaces custom developed. Therefore, you should or else consider the development of these interfaces in the “Total cost of ownership” of this package, right?
4) What kinds of documentation, training also support are available? And how good are they? Bottom line … a package you and/or your staff can’t use isn’t worth much now is it?
Etc. Etc.
Granted, again, there is a lot more to both a good formal “Buy vs. Build” analysis and/or Software Selection process, as discussed above, however …
Once you have narrowed it down to the top “scoring” candidate COTS software packages from your Software Selection process, this along with your assessment of the advantages, disadvantages also costs of the “Buy” vs. the “Build” alternative, as discussed above, will allow you to make a good informed decision about which solution is better for you also your business, namely to “Build” or “Buy”, in this case, right?
I hope that the discussions herein will at least help everyone see the value (and potential time, effort also money savings) of performing a “Buy vs. Build” analysis and/or a Software Selection process “up front” vs. ending up with something that either doesn’t meet your (short- and/or long-term) needs and/or is too costly to maintain.
If you have any further questions regarding and/or would like further assistance with any of this, please feel free to contact us via the contact information available below.
I hope this all helps you all also Have a Great Day! :)
- Michael S. DeVries
About the author:
Michael S. DeVries is the Moderator of The Virtual Consulting Discussion List (http://www.TheVCF.com/vcdl.phtml) also Principal of The Virtual Consulting Firm (http://www.TheVCF.com). Learn how to work from Wherever, Whenever by subscribing to The Virtual Consulting Discussion List also receive several FREE Gifts! at: http://www.TheVCF.com/vcdl.phtml
