The Buy vs. Build decision process is very interesting to me as it is a small, common process that often leads to the undesired outcome.

I covered before the secondary costs that often block this process in this post: https://bashamer.wordpress.com/2011/04/14/institutionalizing-%e2%80%9cwinging-it%e2%80%9d/

In this new post I’m trying to see if there is a smaller solution that could have the desired outcome.

The decision process at some point has to come down to “if(Cost < Benefit) Buy();” Before I focused on the secondary costs that are added into the process by policies and procedures that exist in organizations. Chancing these procedures in its self would require a high cost and there is no clear and visible benefit to doing so. So the procedures won’t change.

So let’s look if we can make this evaluation easier by attacking the Benefit part of the equation.

The benefit to buying is that you don’t have to build it. Or in other words it is hours saved on initial development plus hours saved on maintenance. For hours saved on maintenance you can probably take 10% of the initial estimate for server components, 20% for components that interact with consumer software (Office for example) and 30% for web components due to the speed of evolution. I imagine mobile will be in the 20-30% range as well. All of these numbers a bit fudgy so apply your own experience.

So our function for benefit now looks like “HoursSaved*(1+(YearlyMaintanceEstimate*ProductLifeExpectency)/100)“. This is neat, but the units don’t work out. We are comparing developer hours to dollars, so we have to add a conversion factor.

Do you know your conversion factor?

Do you know what the company considers the cost of an hour of your time? I’ve only known it in one company and it surprised me. It was about 3x what I thought it was; it was 6x what I was being paid.

Let’s say the companies made this information public; you get your magic factor and learn that an hour of development cost the company $175 (probably in the ballpark w/ QA, defect incidence rate, management, utilities etc.)

When you can all agree that cutting a task in half saves $10,000. How easy would it be to then build up the momentum to put in a request to buy a tool to accomplish that reduction.

By making the benefit side of the equation easy to compute you can determine the opportunity. Knowing the opportunity is there will lead people to explore alternate solutions.