How often are you asked to make decisions where there is a large chunk of “unknowns”? Sometimes the ambiguities in decision-making are overwhelming. When they are, it's time to go back to the basics, and recall the basic financial valuation model you may have learned in business school.
Two months ago, I was in a conversation with my team discussing a vendor's SaaS pricing proposal (user count/price/ month) versus the classic perpetual pricing model (one-time license with recurring maintenance). As we worked through the discussion, one person asked where my framework came from.
The credit for the model goes to my corporate finance professor, Bill Poppei of DePaul University in Chicago. Professor Poppei taught us a valuation model that requires every factor to be quantified so as to allow a comparison of investment alternatives. No factor was considered too complex. Simple and small factors got rolled up, but the big unknowns needed to be modeled. Through a series of weekly case studies, he taught us that all of the soft stuff - product strategy, marketing choices, quality improvements, new feature build outs, geographic expansion, product obsolescence, and virtually every characteristic of the firm - could be quantified and included in our models.
Today, when considering software and hardware investments, I can still see Professor Poppei sharing example after example where just by asking the questions and assigning a number, we had a better way to consider alternatives versus the all too often response of, ‘that’s really complex, my gut says…..’.
To illustrate this thinking, I'll share the decision framework that I used recently when considering how to license enterprise software. We were working with a valued partner on a new software solution. We worked through the full cycle of requirements documentation, RFPs, demos, pilots, implementation plans, validation approaches, and support arrangements. As we got closer to decision making, pricing negotiations reached a crescendo (as they so often do!). We had asked the vendor for two quotes - a SaaS model and a traditional perpetual license.
We took the quotes and started working through the process.
By exercising just a little more Excel muscle and applying fundamentals of corporate finance, you and your team will have raised the bar on your decision-making process
We agreed on user counts over a 5 year life cycle. Hosting costs were isolated and controlled for. The solution's technical architectures were both single tenant models with vendor administration and support. Interestingly, the vendor had solved the single versus multi-tenant model conflict with a very strong configuration framework. Differences in validation and upgrade approaches were accounted for in the model. Support SLAs were tuned to be equivalent. Of course, functionality was identical in all material ways and both the SaaS and Perpetual models provided for equivalent upgrade rights to new releases.
The basic framework of the alternative pricing models were:
• Option A (Perpetual model): $1,250,000 one-time plus 20 percent annual maintenance
• Option B (SaaS model): 1,500 users @ $25/month
We ran the numbers and controlled for differences in implementation costs, upgrade LoE, and validation services. We added up the cash flows and the SaaS model came in first, by a lot. Then we assessed the net present value of the cash flows - and the SaaS model's advantage increased. Some of our team thought we were done.
Instead, I channeled my finance professor and reminded our team that with the perpetual license, we can accelerate the depreciation of the license faster than with the SaaS license because the SaaS license costs are treated like rent by the accountants. That change narrowed the gap between the SaaS and Perpetual license dramatically. However, the SaaS model still was the better choice.
Next, we asked ourselves, what if we end up using the system for eight years instead of five? How does that change our model? We ran the numbers and the perpetual model was now was the winner. I used this useful life to surface another useful finance method – terminal value. In the classic financial model, the net present value analysis requires including a terminal value for the cash flows. It could be the same with software investments. When we looked into that comparison, the perpetual model crushed the SaaS model.
Raising a new factor, a team member asked about the SaaS early termination rights. Our contract allowed for cancellation after three years. Of course, in this scenario the SaaS model was the clear favorite.
Finally, we focused on probability weighted scenarios to be able to model our useful life assumptions. We shared this model with the business leaders to get their input. In the end, we assessed the risk of solution obsolescence as large. We weighted that single factor higher, and it tilted our analysis to the SaaS model.
We signed the SaaS deal, but if we are using the system eight years from now, we will have paid more for it than we would have if we had selected the perpetual license option. If we are still using the system 12 years from now, then we will have paid even more. However, the value of flexibility (‘optionality’ to the finance crowd) carried the decision.
In this case, our team benefited from using a nuanced financial model in order to make a carefully measured decision. Too often, we use the back of the envelope approach; forgetting important considerations, like NPV, taxes, risk scenarios and timelines. By exercising just a little more Excel muscle and applying fundamentals of corporate finance, you and your team will have raised the bar on your decision-making process.