A unique combination of tools, software cost evaluation knowledge, and a repository of industry information enabled PRICE Systems to make a major impact on a 1995-tax case.
Retained for expert testimony in the area of software fair market value assessment, we examined a heritage software system with a value assessment difference between petitioner and respondent of 17 to 1! Based on relevant analysis of comparable industry experience, we produced a fair market value within 6% of the eventual case settlement value for the contested software. By contrast, the fair market values of opposing software experts missed the mark by 360% and 470%.
In rebuttal testimony, we systematically disassembled the opposing values, pointing out significant flaws in methods employed. Four of the five opposing expert rebuttals opted not to take issue with the PRICE Systems expert testimony. The result of the case settlement clearly illustrates the dismissal of not only the petitioner and respondent value assessments, but those of the opposing experts ("A" and "B"), as well.
Had PRICE's assessment been performed during the actual business acquisition, both respondent and petitioner could have avoided the considerable time and expense of legal proceedings. Resolution of the tax issue in this case consumed over six years at an expense greater than the settlement value!
The value assessment was performed over a three-month period at an expense of less than 2.5% of the settlement value - a return of 25 to 1 in time and almost 50 to 1 in expense!
Establishing value for software assets is not tricky or complicated if the concept of fair market value is always the guiding principle. Unfortunately, software value has been and continues to be assessed under conditions that often run contrary to fair market value. A few assessment areas where we have detected general weaknesses are:
Expense vs. Value - Not all software department expenses produce asset value, and not all software value originates from software department expense. Can your assessment methods handle this?
Software Support Asset Value - Just like a house, new features can be added to software over the period of use. Do your methods identify asset adding activities separately from maintenance activities?
Re-used and Unused Software - Once implemented, software can be used over and over, often with little incremental expense. In addition, software can be added without accompanying removal of that which it replaces. Do you know the extent of re-used and unused code in your enterprise software right now?
Method Neglect - Do you use a disciplined system for estimating and tracking software? Is it well understood within your organization? Is it integral to both the software engineering and project management processes? If not, credible software value assessment is practically impossible.
Systems Imbalance - Software performance metrics, accounting record, and value assessment methods should use like-conventions, if not identical data structures, to support use of one another. Are the conventions for your systems in balance?
Ostrich Effect - Sound value assessment demands an eye of industry norms with regard to practices, trends, and performance data. How do your enterprise software assets compare to others in your field? Do you have the mechanism to address this issue?