Continued from page 1
2) Are you planning to manage
project, and project team(s), yourself? And/or are you planning to “outsource” part to all of
management of your project? What are
costs in terms of time, effort and money for each of these alternatives? Which of these alternatives has
minimum risks to
successful completion of your application development project?, These are *important* considerations as failing to complete
development of your application(s) may make pursuing this option very costly!
3) What are
costs – time, effort and/or money – to also develop
documentation and training (if applicable) for your application(s)?
4) How do you plan to support
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
source code? Do you plan to handle future maintenance yourself / “in house”? and/or Are you going to engage
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
“Buy” option.
Some of
advantages of
“Buy” option include:
1) The time to get a package solution implemented such that you may start using it and reaping
corresponding benefits for your business is typically quicker than that for building
application “from scratch”.
2) The initial purchase price of a software package, although it may be considerable, is often less than
(initial) custom development costs.
3) The software vendor may deliver regular maintenance upgrades to
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
costs of all these “bug fixes” and enhancements alone.
Some of
disadvantages of
“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
box”. The software vendor may or may not be willing and able to modify
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
vendor’s next maintenance release to get
changes you want, or you may have to pay
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
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
additional time and cost, if it is even possible / an option, to modify
package to satisfy your current requirements/needs? A “general rule of thumb” I have used over
years is that … If you have to modify 50% or more of
“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,
vendor, and/or developers you engage be able to modify
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
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
development of these interfaces in
“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 Software Selection process, as discussed above, but …
Once you have narrowed it down to
top “scoring” candidate COTS software packages from your Software Selection process, this along with your assessment of
advantages, disadvantages and costs of
“Buy” vs.
“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
discussions herein will at least help everyone see
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 via
contact information available below.
I hope this all helps you all and Have a Great Day! :)
- Michael S. DeVries

Michael S. DeVries is the Moderator of The Virtual Consulting Discussion List (http://www.TheVCF.com/vcdl.phtml) and Principal of The Virtual Consulting Firm (http://www.TheVCF.com). Learn how to work from Wherever, Whenever: http://www.TheVCF.com/vcdl.phtml