Geeks With Blogs

The Lanham Factor The (ir)rational thoughts of a (not-so)mad man

This entry is originally from the Roanoke Valley .NET User Group newsletter.

Buy vs. Build – How to Decide

Last month we talked about adopting new technologies. Related to adopting new technologies is the “buy vs. build” conundrum. You should always consider purchasing an existing system if you can find one that meets the requirements.  However, there are occasions when it makes more sense to build the solution.  Before making a buy vs. build decision, you still need requirements. Once you have a baseline set of requirements, you can consider Commercial Off-the-Shelf (COTS) products.

Buy vs. Build Considerations

Not everything is as cut-and-dry as we would like. It may seem that you can simply review the features of a range of off-the-shelf applications and compare the features to determine whether or not a product is a good fit. Unfortunately, it’s not that simple. You need to consider other aspects as well. I like to think of the considerations in three categories including functional, non-functional and business.

Functional items relate explicitly to the functional requirements of the given system. Can users attach notes to patient records?  Can users reconcile to a certain date?  Can users define their own templates?  These are often the obvious items to consider and generally lead to a quick analysis. Either the product supports the feature or it doesn’t. There are some exceptions to this, of course, but you get the picture.

Non-functional items relate to the supplemental requirements of the given system. Does it run on my network (e.g. 100MB vs. 1GB Ethernet)?  Is it browser-based?  Does it have an API for integrating with my existing financial systems?  Can I use it with Active Directory®?  These items can be obvious but some may be tricky. For example, the system may, print reports but you may not be able to customize them.

Business items relate to the overall business impact of the product. These items are the most often overlooked and yet can be the most costly.  What are the base and maintenance costs?  What are the initial training costs for both the business and technology staffs?  What are the refresher training costs? What is the level of effort associated with installation and (for disaster recovery) reinstallation?

To Buy or Not to Buy…

It may seem obvious that if the TCO for the COTS product is greater than or equal to the cost of building, you should buy. There may, however, be scenarios wherein you should build instead of buy, despite the TCO of the COTS products. While there are several reasons for going against the flow, one of the more substantial reasons is training.

If you can find a low-risk project, consider using it as a training effort. This will allow your team to learn that new technology without adversely impacting the business. What this really means, mathematically, is that you have included the cost of staff training in general in the gap analysis.

Tip:  Excel® makes a great gap analysis matrix. You can quickly evaluate various solutions (including building) and quantify your analysis and the final decision.

How do you make buy vs. build decisions?  What experiences have you had with your decisions?  Share your adoption stories and lessons learned with the rest of the NUG!

Happy Alignment!

Posted on Thursday, April 10, 2008 2:12 PM SILC - Solution Implementation Life Cycle | Back to top


Comments on this post: Buy vs. Build

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Brian Lanham | Powered by: GeeksWithBlogs.net