Tuesday, December 10, 2013

How to Value Software

Having working software in hand will ensure a significant time premium when it comes to developing time-critical apps.
Valuing Intellectual Property, which is intangible in many ways, is becoming a relevant area of study in the domain of initial public offerings (IPOs) or mergers and acquisitions (M&A). Valuation of Intellectual Property is similar to valuation of real (tangible) properties in that the outcome of both exercises is to establish the current worth of the asset. However, it is different from the valuation of real property in that it is a type of commodity whose value is derived from the information it contains or represents. Information goods are, by nature, non-excludable (in that people who have not paid for the goods can still use it) and non-rival (in that the commodity can be used by more than one person at the same time). Intellectual property assets are further different in that they are essentially either commercial or product-based assets. Under commercial assets are included IPRs including trademarks, trade names, brands, GIs and character names. Within product-based assets are included patents, copyright, design, etc. The most important difference of an Intellectual Property asset compared to a real property is that its life is governed by statute (patent rights only last 20 years and so on) and is regulated heavily by market demand.
Value is not a specific figure but rather an alignment of assumptions. Typically, we use three components for valuation – cost-based, market-based and revenue-based – also thought of as value past, present and future. Timing and context are critical components of the assessment. For example, the complexity and customization needed to create an asset may cause a high level of cost variability and outcome uncertainty. Similarly, given sufficient time, multiple alternatives can be explored, but if deadlines are tight, the need to have a working solution requires a value premium. We will look at each of these elements to provide a reasonable approximation of the value boundaries.

Intellectual capital can incorporate both intellectual properties, such as patents, trademarks and licensing, as well as human capital such as employees. For acquisition purposes, the degree to which intellectual assets are formalized or codified increases the likelihood of retaining the value. If the employee experiences or methods are documented, those assets are more readily leveraged and potentially non-linear (highly scaleable). If those experiences or methods are known only to the employees, leverage or reuse will be more restrictive and will require additional employment agreements to capture those assets. Note that this estimate range cannot include the potential options value for market timing, for example, if the underlying asset (let'€™s say software) is necessary to win a contract or deliver to a deadline within a 3-6 month time-frame. In such a situation, the time premium can easily double the estimated value, depending on the opportunity.

Cost-based valuation can take into consideration the contracts that the seller has in place with the rest of his clients, to estimate an upper bound on the development costs, based on budgets for management'€™s involvement in contractor's time (and that would assume the project/product represented the majority portion of the firm'€™s time and effort during the year).

Market-based value focuses on alternative offerings that can provide the same functionality in the same or necessary timeframe. If the underlying functionality of what is being acquired is custom configured to the buyer’s offering, it is then outside the scope to find comparable acquisitions.

The only reasonable alternatives will be to consider redeveloping the code adaptations provided by the seller or to consider simply purchasing the rights to those licensing restrictions. But the difficulty here is timing. Given sufficient systems evaluation, it is likely that the seller€™s adaptations to the buyer€™s code can be recreated, but it is worth examining whether it can be done within a short enough timeframe and with the necessary reliability to meet the seller€™s strategic needs.

A second alternative will be to purchase only the rights to the specific portfolio that the buyer is interested in. The first step in this case will be to estimate a baseline bid plus a necessary premium for the time value of strategic enablement. We estimate that such a premium is dependent on negotiations, which are influenced by both available alternatives, as well as income opportunity differentials (that is, the positive income associated with immediate sales versus the potential time delays for alternatives). Clearly, the availability of alternative development resources for a given timeframe can provide greater leverage in negotiations. However, as we noted up front, even with significant resources, it is often difficult to scale development in a linear fashion. Without enough time or adequate alternatives, the premium can be outside normal valuation bounds.

Revenue-based valuation is the third component, which alludes to what future value and asset can create. As mentioned in the introduction, there is a contingency or options value based on the ability to enter markets immediately with a working solution. The option can be parameterised by estimating the value of the contract, the decision timeframe, the portion of the offering dependent on the underlying software and approximating the estimate of success variability for the contract. In addition, although future revenue can be ascribed to a particular product, from a practical standpoint, the time horizon is necessarily limited because the product itself can undergo modification and within the same time horizon, other alternatives can be developed or acquired (think of these as an augmented discount rate). For example, if the buyer’s launch was delayed by a year (to acquire alternatives), assuming no other changes (unrealistic), the upper-bound difference (cost) will vary. Of course, the strategic impact of such a delay can be severe, especially if pursuing a first-mover advantage. So, the actual value to prevent the delay can be much higher. Obviously, not all revenue in a service offering is attributable to a single software component. So one can more accurately adjust the revenue estimation based on a percentage component, and with necessary adjustments for other costs.
Software can present a particular timing estimation problem. Although software development methodologies can improve delivery consistencies, the rapid change of technology frequently creates faster and more efficient implementation tools, compared to the original development. Moreover, having an existing solution provides a working template for implementation, which can also accelerate the ability to provide an alternative. On the downside, however, most software development has limited scalability. Even with an extensive budget, doubling the number of developers will rarely reduce the development time significantly. A properly scoped original project is unlikely to be done significantly faster, even if more resources are made available. Therefore, for a time-critical application, having working software in hand, can command a significant time premium to the value, as has been discussed above