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.

Tags: ,

4 Responses to "Buy versus Build"

Leave a Comment