Articles
While finance and engineering departments interface for normal budgeting and expense approvals, successful complex technology sourcing endeavors require a much closer partnership. These deals can involve thousands of pricing line items and different vendor approaches that make it difficult to develop a realistic total cost of ownership (TCO) model, much less perform an apples-to-apples comparison.
A well-coordinated finance and engineering partnership can help navigate wireless technology complexities by developing a predictive financial model analysis to ensure that cost, scalability and technical viability are accurately modeled — and that the tradeoffs are understood.
Wireless Technology TCO Considerations
1) Hardware Architecture Drives Cost
Comparing technical solutions from different vendors is often challenging since the hardware and software architectures may represent radically different ways of implementing the same functionality (e.g., centralized versus distributed architectures, combining different functional elements within the same physical "box" versus different physical boxes). Varying technical solutions can also lead to different deployment approaches and costs. For example, two vendors may offer functionally equivalent solutions, but because of architecture differences, one solution may require more floor space at each cell site while the other requires more vertical space on towers near the antennae. As such, there are a number of considerations that must be taken into account when trying to normalize solutions that are functionally equivalent. In many cases, even greater complexity can present itself when competing technology solutions offer different functionality and features (which is usually the case) and such differences need to be appropriately valued in the financial analysis to support decision making.
2) Software License Costs Can Be Complicated to Model
There are also differences among software licensing agreements. While some software licensing structures are straightforward, such as a one-time fee or periodic recurring fees for a base software load, many software licensing structures are tied to the use of specific features and can increase as a result of consumption-based models. For example, it is very common for licenses to be based on the number of subscribers on the network or using a particular feature, the amount of traffic on the network generated by the feature, the number of transactions using the feature, maximum concurrent users of a feature, or maximum concurrent connections using a feature. All of these potential use cases must be factored into the financial analysis.
3) Demand is Dynamic
When selecting wireless technologies and vendors, executives need to understand the total cost to deploy and maintain a reliable network that will attract and maintain customers and generate revenue. This goes beyond unit pricing. To calculate total cost, the matrix of unit prices must be multiplied by the "demand set" of units necessary to build the desired network (e.g., the total number of hardware boxes/chassis/cards, the total number of consumption-based software licenses). This demand set must be defined by a high-level, functional set of requirements for the network (e.g., features and functionality offered to end users, geographic coverage, quality of service and performance, capacity), which in turn drives the "dimensioning" of the solution (i.e., how many of each pricing line item must be purchased). As the demand set is not a static or one-time model, a range of forecasts and deployment scenarios needs to be modeled. For example, the scenarios may be defined by either aggressive or conservative sales forecasts for subscriber growth, wide or narrow coverage requirements, and/or single vs. multi-vendor awards.
If finance and engineering collaborate to develop a useful predictive model analysis, they can identify the scalable options, the resulting pricing changes and the financial impacts of architectural limitations. One of the most important aspects of this analysis is that different vendor solutions scale differently. The low-cost vendor under a conservative forecast may turn out to be the high-cost vendor under an aggressive forecast because the technical architecture does not scale efficiently or the licensing pricing structure does not cap the consumption metrics on which the pricing is based. This analysis must test the vendors' solutions both technically and relative to the pricing approach to determine if it becomes unaffordable or if it does not scale efficiently.
Best Practices for Engineering and Finance Collaboration
To build a predictive financial model, Engineering and Finance teams need to learn each other's business beyond the normal level of engagement:
• Collaborate to identify every "lever" that drives cost in the vendor solution and develop
assumptions for the demand set to apply to the unit prices of those levers
• Finance:
° Help "translate" the business case into the scenarios or range of demand
sets to be tested by the model
° Become technically adept to ensure the financial model accurately represents
the vendors' technical solution and pricing structure
• Engineering:
° Perform technical due diligence of the solution to confirm that i) it supports the business case revenue
projection for coverage, quality and functionality, and ii) each hardware, software, and associated
service cost is dimensioned with the appropriate number of units to apply to each unit cost
° Understand how the vendor's solution and pricing structure work so that Finance can ensure the
analysis uses a demand set that ties back to the business case
By working in partnership, Engineering and Finance teams can more effectively support each other's efforts in identifying, quantifying and ultimately selecting wireless technology solutions that provide the maximum level of technical and functional capability for the best price.
Andy Sealock is a partner of outsourcing advisory firm Pace Harmon.


