The Virtual Consulting Firm – TheVCF.com

To Buy? Or To Build? … That Is The Question!

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” and 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 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 the 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 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 and chose the 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 the 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 the short term and in the long run!

As otherwise, you may end up paying to “recreate the 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 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 and paid for, and pick or build another one and 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 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 the initial development and used just such a Software Selection Methodology for one of the largest global software and 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 a 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 the “Total cost of ownership”) including the total time and cost to get the application into production and/or market and the total cost of supporting and 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 and 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 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 the application source code and/or access to the original developers of it, right?

3) You may develop your new application(s) to interface and “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 and 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 and cost, make sure you also consider all of the time and possible costs to complete the definition, analysis and design phases, prior to “coding”, and the subsequent testing and implementation phases required to complete the overall software development life cycle for you application.

2) Are you planning to manage the project, and 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 and 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 also develop the documentation and 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 and 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 and 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” and enhancements alone.

Some of the disadvantages of the “Buy” option include:

1) A COTS package may not satisfy all your business requirements/needs and may not fit your specific business processes well “out of the box”. The software vendor may or may not be willing and able to modify the package to better fit your business requirements and/or processes and 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 and 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 also 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 and 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 50% or 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 and it will need to, then you may find that you will need to have these interfaces custom developed. Therefore, you should also consider the development of these interfaces in the “Total cost of ownership” of this package, right?

4) What kinds of documentation, training and 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 a Software Selection process, as discussed above, but …

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 and 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 and 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 and 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 and request Your FREE Quote for all of your “Buy vs. Build” analysis,  Software Selections and/or any other ways in which we may Help You Now!, at:

http://www.thevcf.com/FreeQuote.phtml

We hope this all helps you all and Have a Great Day! 🙂