There are many economic aspects to think about when purchasing a tool. This post discusses some of the basics covering: burdened costs, assessing the value of a tool, make versus buy decisions , and training costs.
Correctly accounting for the burdened costs is critical when understanding the costs of internal development. This is important for both “make versus buy” decisions and to understand what a productivity improvement is worth in lowering expenses.
The development costs are more than just the internal developer’s salary. This should be the total costs that the company spends for that person’s time. The benefits for the internal employee should be included, then a portion of other costs such as the rent. There may be other costs that should also be added. For example, if there is one technician for every three hardware engineers then one third of the technicians’ burdened cost should be added to the burdened cost for the hardware engineer. A more in-depth discussion is available at the following link (though a bit “salesy” as they partly promote their solution): http://www.infoplusacct.com/cms-pdf/Labor%20Burden-PDF%20version.pdf
For example, in high-tech a typical yearly burdened cost for a development engineer in the Bay Area is between $200,000 and $250,000. This cost will vary depending on the region of the country, the experience of the engineer, and the particular expertise involved. The costs can easily vary up to 100% within the same company within the same location. Most yearly burdened costs for an engineer are between $75,000 and $400,000 a year.
Value of a Tool
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
- Abraham Lincoln
The value of a sharp and efficient tool can be great, and there are times for when selecting or building the right tool is critical. Just imagine how taxing it would be to undertake a large software project without a compiler. However, the first question about a tool is “Is it worth it at all?”. Does the tool provide enough value to justify the purchase or the development of a tool?
Assessing the value of a tool depends on how it fits within the project. A tool that enables the team to take on a complex project may be invaluable. Another tool may accelerate the completion of tasks that are on the critical path for a project. The primary value of such a tool comes from the improved time-to-market for the overall project. Another tool may provide a general productivity improvement for team members. The value for such a tool may be in lowering the expenses to complete the project. Lastly, another tool’s primary value may be in being able to debug complex issues that will hold up the project when they are encountered. The biggest part of the value for such a tool may be the peace of mind that it brings to project management.
It is interesting to follow how the value of a tool evolves over time. When a tool is a new concept the focus is on improving time-to-market and user productivity. Early adopters may receive tremendous gains from being first to use a tool. As a tool becomes more commonly used the focus becomes keeping up with your competition. You may feel that you are being left behind, or will have difficulty keeping pace without the tool. Once a tool is in widespread usage often it becomes a recruiting issue. The lack of the tool may make it hard to hire engineers that view the tools as inferior without the capability. Also being trained on the tool may become a requirement to be considered for certain positions.
Make Versus Buy Decisions
Most commercial tools started as internal custom tools. Then as the number of users grew, some companies decided they could make a profit to selling tool products to those users. With third party commercial tools available a company is presented with a “make versus buy” decision.
In doing such an analysis it is important to make sure that it is a fair “apples-to-apples” comparison. The first issue in making the comparison fair is to understand the true burdened costs for the internal development option. Other variables also need to be taken into account. For example, if the commercial tool has better documentation than the internal tool. You must either add time to improve the internal documentation, or assess the lost productivity in using a poorly documented tool. The Total Cost of Ownership (TCO) of the tool needs to be assessed, including the ongoing maintenance, calibration, and training for the tool.
There are issues that go beyond just the economics in a “make versus buy” the decision. Other factors such as risk and control need to be included. The presentation at this link provides a good checklist of those other issues when procuring an outside product. http://www.maxwideman.com/issacons4/iac1402/sld002.htm
For complex tools the training costs associated with using a tool can be a significant portion of the cost of integrating a tool into a development organization.
First there are the actual fees for the training class itself. If the expertise is rare and in-demand these fees can easily run into the thousands of dollars per engineer. Of course on top of that is the burdened cost of the time of the engineer that is taking the class, the cost of travel, or other specific expenses in taking a class.
Lastly there are the hidden training costs. These come from the lessened initial productivity when using a new tool. It may take a few weeks or months before someone is fully proficient in the new tool. They are still effectively training themselves, even though they are not in a classroom. Also the person that is the internal expert on the tool may become deluged with questions from colleagues during the learning phase.
When these costs are factored in, it becomes apparent why the ease-of-use can be a critical decision criterion when selecting a new tool. It also explains why companies are generally reluctant to switch tools, and almost never switch tools in the middle of a project.
I hope this summary has been valuable, and caused you to think about the economics of tools. Please comment if you have a specific example that relates.
Packet Plus, Inc.