Buy versus Build

A discussion broke out on the MSDN/TechNet SharePoint Forums this week that started to approach the subject of build versus buy. It is something I have had to put a fair amount of thought to in the past so I decided it might make for an interesting blog post.

As a developer, I enjoy developing. It is always fun to dig into code and solve a problem or fill a need. Unfortunately I don’t get nearly as much time to develop as I used to or would like. It ends up being something I do between meetings, on weekends, or in support of a project when the other developers are not available. As I’ve moved through the roles of developer, team leader, architect / program manager I have had to look at things from different angles including that of what is best for the company or the users the solution is being deployed for. Sometimes those personal goals and enjoyment have to be set aside in support of the company’s and users’ best interest.

One of the main trends of computing over the past 10+ years is the move towards interchangeable components, services, etc that can be stitched together offering reuse and decreasing the total cost of managing systems. SharePoint is a great example of this as a platform that has a rich market of third-party vendors. There are 100s of available solutions, web parts, etc that are publically available.

Here are some considerations when evaluating whether to Buy or Build solutions.

Requirements – Is there a solution available that meets the requirements? Is there something close enough to consider as an option? If not, and its needed then its clear you would have to develop it.

Initial level of effort – Do you, or does somebody on the team have the skills and know how to develop the solution or is this a learning opportunity? How long do you expect it to take? If it is full of unknowns or if the projected cost based on a standard rate ($50 an hour?) comes to 80% or more of a commercially available solution it probably isn’t something that should be custom built.

Are there other things that are a better use of your time? The last few organizations I’ve worked with I’ve had a running backlog of projects averaging two years. It is normally easier to purchase components than it is to add to the headcount. Purchasing components or solutions makes it that much easier to deliver value quickly.

Ongoing maintenance and support – Do you or does the group have the time to support the solution going forward? You may have time now, but if you squeeze it in what happens when they come back for changes or you need to upgrade? Will you have time to work on it? You can rely on the vendor for this in most cases if you purchase support for the solution.

On the flipside, make sure you take into account the vendor’s stability and history and make sure that they will support the solution going forward and/or still be around. I have made the mistake of purchasing a solution from one company that sold me a dead-end product that was replaced.

Quality / Grade – Do you, or your team have the skills to meet the needed quality and grade of the solution? In most cases the commercially available solution has a team supporting the development effort to include qualified quality assurance professionals.

Budget – Do you have funds available for the purchase. In some cases there just is not money available, we are in a recession after all, but smart businesses will find the funds if the solution does add value and save time. Mature organizations probably understand this a little better, and therefore tend to have larger budgets to support the purchase of technology.

Summary
By taking these considerations into account it will help you make decisions that add value to the organization and its end users.

5 Replies to “Buy versus Build”

  1. Mike, you are spot on with these thoughts. I, too, enjoy developing – but unless you work for a software development house, you really need to pause to think before committing to a big development effort. Of course, I’m speaking from the “corporate IT” viewpoint.Most important callout above – Ongoing Maintenance and Support. Typically, project teams pitch the total cost to develop, but they undersell the ongoing maintenance – and it’s always more than you think.Other thoughts …http://bit.ly/2bQechttp://bit.ly/7PMwhttp://bit.ly/Q1zrfhttp://bit.ly/DtYWA

  2. Excellent comments!I had a section about re-use in an early draft but it didn’t seem to fit in so I cut it out. Re-use is very important to me, and it can help decrease the costs as well as to increase the quality.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: