The following is an attempt in improving third party product adoption in software. Third party software often can lead to great savings, but it is often hard to get an actual piece of software on a project in a reasonable amount of time. Part of this may have to do with the process rather than developers who are to use it.

In many companies there are policies and practices that you are to abide by. One of the areas where these policies are strong is when it comes to spending money. In one company I worked for there had to be contracts in place, there had to be master service contracts negotiated and I recall spending an hour on a conference call to create a clause related to the mini-bar for any possible future consultancy services. These were both billion dollar companies, and the meeting had 2 technical resources, ~4 lawyers, and some management & sales. The topic ate about an hour of call time as well as hours of prep time. Assuming a low (but round number) of 100 / hr per person and this clause cost the two companies 1000 USD. I’m not sure what a full mini-bar runs, but I’d be willing to take the chance that we would have never made our money back on that clause. The total cost ofver the first 2 years of the product we were interested in was less than 5,000 USD

This seems like an extreme concept but it happens often in smaller instances. Smaller examples might be long meetings about cheap products; recreating a cheap product rather than going through the hassle of trying to buy one. The reason that these items happen is due to a lack of measuring non- monetary resources, and when things are not measured they have no value. So people take the rational approach of not buying off the shelf products and rather recreate the wheel.

Trying to add measurements to this process so that the costs are tied to time will be extremely laborious and requires relatively large changes in the business. Going this approach does not really resolve anything.

So ideally we want to minimize the costs of the decisions. Although there are many there are many processes to speed up decisions, there is one that is not often mentioned; making decisions in hind sight is very fast and accurate. This seems impossible.

What most purchasing decisions are is a predictive process. Predictions are often inaccurate, and to be more accurate it requires a lot of analysis. The hindsight scenario is a reactive process, where information is cheaper to acquire but it is unable to prevent anything.

For some decisions you want to have a predictive process, for big capital expenses (datacenters), or high risk expenses (people). But for many they are not (3 licenses of a 100 dollar piece of software). So a reactive approach is not always a good path to go. So if you want to institutionalize a reactive approach you do need some limits.

A simplistic model of a reactive approach is to offer people a budget per year of X (let’s say 1000 per developer). And allow people to re-claim this money by getting forgiveness. In effect a developer or group of developers can decide to buy a license on an afternoon, and if it works, and they can show the results they can go to the budget process and say “we want to have reimbursed 580 to buy a product that has shown these benefits (and savings)”. There is no risk and getting an accurate decision is cheap. People that make good decisions get to make more decisions, people who make bad decisions run out of money.

If the decisions process gets streamlined then hopefully third party tools become more attractive and people will spend less time re-inventing the wheel.