Pricing Part III: Cost Benefit Analysis

So, we've talked about models, we've talked about price targets from the vendor perspective, let's get into the buyer's point of view.

Software has a supposed value.  Your business accomplishes X today through some combination of labor, fixed costs, and recurring costs.  Take a reporting system, for example.  Maybe you just use Excel, some databases, and some degree of home-brewed automation.  So, your fixed costs cover software and hardware, recurring costs for maintenance, and then labor for the amount of manual effort required to design and deliver the product.

A solution to replace your system should effectively pay for itself by reducing long term costs and/or saving effort.  Pretty obvious, right?  But how can you be sure?  The system you built in house might have low one-off costs, albeit offset by higher labor demands.  You could quite possibly spend the same money on a new system or on adding more human resources.  Adding people, while not easy, is on some levels much less risky than taking on a new system.

You could bring in consultants to try and assess deeply that value of buying another system, but this too is fraught.  Consultants like change.  Change and uncertainty is what keeps consultants in business.  The consultant might even think that his or her company will get a piece of the action when it comes time to deploy the new system.  Similarly, an in-house assessment is tricky because of vested interests in the current solution.  Your purchase of a new system potentially means eliminating jobs, just like putting a more advanced machine into an assembly line.

All you want is the cost-benefit analysis.  The decision to buy a software solution just needs to add to the bottom line over a reasonable amount of time, without distracting your resources from higher-value activity.  But you can barely trust anybody to give you a straight answer on cost-benefit.

To get to the root of the matter, you can attempt some thought exercises.  Would you buy at a million dollars? 10 million dollars?  Would you take it for free, just knowing that there will be effort to implement the new system?  Try plotting a function of the cumulative costs of your options and, if they intersect, see how many years it might take for your purchase to add value.

For example, your current solution can be modeled as a function of time.  For year X, it's something like:

f(X) = (1 + X) * ((human labor + annualized hardware costs) * uncertainty)

Human labor is, of course, the cost of the people to build and maintain the solution.  For something built in house, it's likely to be quite high.  You might have several fairly expensive developers plus maybe an offshore QA or integration consultant.  You will need more hardware over time, but you can cap ex that.  Uncertainty is a coefficient that recognizes the non-scalability of your solution: developers leaving, new requirements that are not in scope, and so on.  You can experiement with different values, but try something like 1.2, as +20% is kind of a standard fudge factor.

What about buying?  There area few more inputs.  Something like this:

f(X) = software + hardware + implementation + (1 + X)*(maintenance + human labor)

Ideally, there is no uncertainty coefficient because your vendor is competent and the solution is a good fit.  Your human labor expenditure should be substantially lower.  So, this function crosses the y axis at a much higher point, but has a lower slope (in theory).  The question is, how many years does it take for this function to save you money?

That's something I'd like to know more about.  Is there an accepted number of years within which a business decision needs to add value?  This could apply to many kinds of major expenditures--equipment, office space, marketing, etc.  Cap ex rules inform on this somewhat, but I'm inclined to think that there are less codified rules out there that experienced executives use to make this type of decision.

Getting to No

Business writers like to talk about reaching consensus and influencing other people.  This is often in the context of closing a deal, or requesting a raise, or otherwise "getting to yes".

Let's talk about getting to no: the art of disabusing people of bad ideas.

It's actually a fairly common interview question for client-facing jobs: tell me about a time when you had to convince somebody that he/she was wrong.  This question assesses how you handle conflict, your ability to navigate workplace politics, and your ability to empathize enough with somebody else to understand just why they're clinging on to bad idea.

By the way, let's assume that the bad ideas we're talking about here have at least a trace of legitimacy, unlike my repeated requests to turn one of our empty offices into a ball pit.

Some thoughts:

• Be respectful.
• Unless you really don't want anybody to like you, you can't just say "no"
• Work isn't always about being liked, but when you've got a relationship with your colleagues or customers, it helps to treat their point of view with respect and to try and reason through things.  Maybe they're right and you're wrong.
• If you injure somebody's pride, that person may react by holding on to a bad idea even more strongly.  You know the trope about a grumpy sys admin holding up a new IT project?  This happens when ops team members aren't taken seriously enough because they aren't on the business side.  Respect gets things done.
• Empathize.
• Build support for your lack of support.  Talk to stakeholders individually.  Be a politician.  Figure out what's driving this decision and what everyone's interests are.
• Put yourself in their shoes, can you see their point of view?
• Make a case.
• Gather real evidence, don't just shoot something down because it feels wrong.  Speak to the interests of the stakeholders.
• Communicate your concerns in person or on the phone, and in chunks that are easy to digest.  Nobody is going to want to read a long email explaining why he or she is wrong.  We have a capacity for ignoring information that makes us feel bad.
• When you discuss the risks of a bad idea, do so with impartiality.  Rather than attacking the validity of a feature that might slow down system performance, talk about the importance of the user experience (i.e. speed and reliability).  Talking points like this are powerful rhetorical tools because, basically, nobody can disagree with you ("No!  This flashy feature is more important than whether or not the system runs!").

Let's take what is probably a common example: 

You've got a salesperson who might have misstated some technical information about your product.  The customer IT has some very strong opinions about this, and while the business users don't really care, they tend to trust their IT team.  Your developers won't get within a mile of this deal and your delivery team is going to face the fallout from having mis-sold the product.

You're now staring down a very painful project, what do you do?

First, don't embarrass your sales guy.  Really.  It won't get you any closer to solving the problem.  The only person who can credibly contradict your sales rep is your sales rep.  Chances are, the sales guy isn't particularly wedded to his misstatement of your product's capabilities.  Make him comfortable with going back to the customer and clearing up the misunderstanding.

Ask yourself why the customer is hanging on to this idea.  Maybe it means less work for them, maybe they told the CTO about it and she's excited, maybe they think it will get them a bigger bonus because the solution is so spectacularly perfect.  Consider that the customer might have legitimate technical, personal, and professional reasons for supporting this misconception.

When you try to take this idea off the table, think about how to address these lowered expectations: there are positive tradeoffs on the tech side, your salesguy can talk to the execs, following your own best practices & staying within the capabilities of your software will make this a raging, bonus-inflating success.

Ultimately, you're just getting everyone's best interests aligned, right?  We all want this thing to work, don't we?

By the time you're ready to publicly debate this idea, you should already have convinced some stakeholders to take your side.  You should already have a solid case for saying no.  All you're really doing is showing the last hold-outs that they're on the wrong side of history.  If you've laid your groundwork well, the customer might even reject the idea without further prompting from you, and the project will chug along without any hint of prior discord.

On Business Travel pt II

I'm here at an airport bar.  Actually, I've found the loneliest, most out of the way bar in the entire terminal.  They've got a great beer selection and I can work in peace.

Why bother traveling, anyway?

Let's imagine you're running your own small company.  What justifications would you use for travel expenses?

• Training or knowledge transfer
• "Big" presentations (sales, investors)
• Meeting new people at scale (conferences, college recruiting events)

However, my top reason for flying everyone to the same place:

Eating and drinking together

Sharing a meal changes the dynamic between people, deeply.  Basically, I've never had a problem with anyone who's had a drink with me.  Several times, meeting somebody for a drink has been the difference between grumbling about a demanding client and putting in that extra effort because you know they're good people.  In an occasionally contentious business environment (that's the nature  of making a living by selling software), liking the people on the other side of the phone matters.

You can't just tell people to be friends with each other.  And if you can make friends via a power point demo, I salute your social acuity.  So, you need that after work drink or dinner.  It matters.

My take is, traveling for work is most valuable when it gives you the opportunity to take your relationships outside of the office.

So, if somebody is considering traveling for a brief sales meeting, and that meeting doesn't provide the opportunity to really develop a personal relationship with the buyer or partner, then I would not be convinced that it's a trip worth taking.

Here are some other thoughts:

Training

Traveling for training is overrated.  The last few times I've traveled for work, it's been for the sake of training.  You know, when you spend several days in your email, listening to the trainer out of one ear?  Or, when you're the trainer, and you realize nobody can possibly pay attention to you for a full week?

Knowledge transfer is a compelling reason to bring people together, but I'm not sure it works as well as you'd hope.  Maybe it's more a matter of execution than intent.  How do you keep everyone's attention for 8+ hours a day?  But if you aren't using the entire duration of your presence onsite to train people, then are you justifying your trip?

Presentations and Meetings

You will always be slightly more effective with a physical presence.  Giving a presentation to a mix of physical and remote participants is a drag.  It's difficult to speak at the phone and speak to your meeting participants at the same time.  However, it is worth considering how telepresence has improved recently.  Google hangouts have brought previously expensive telepresence technology--basically, figuring out who is speaking and giving that person the virtual floor--to the consumer for practically nothing.

Being present in person is not a solution to short attention spans, just an improvement  Big meetings over the phone always result in participants losing focus and dropping out.  You still get this behavior when you put everyone together in a room, you just see a little bit less of it.

A few other ideas about putting people together for a meeting or presentation:

• Large time zone differences
• If you have X hours of work you need to get done each day over several days and your teams are based far apart.
• FYI, my current company (mostly French) and past employer (partly British) managed several weekly calls between teams in Europe and teams on the US West coast.  What you might observe is that a greater frequency of international collaboration decreases the budget support for related travel.  In this case, travel is perceived to be not valuable.  Given that you'll probably have another series of calls on the same topics next week, why spend any additional money?
• Telepresence is not appropriate for your audience
• You're trying to meet with large numbers of people, and with people who are not connected to your organization
• Conferences, for example.  Or, if you're recruiting and there is a particular school or community that you are convinced you need to access.
• Lack of preparation
• The contrapositive is important here.  If you've got a presentation and you know what you need to say and the point you are trying to make, you should be able to handle it remotely.
• That said, you can't always be prepared on that level.  When you don't have a lot of access to your audience & you can't anticipate their needs (as often happens early in the sales cycle), sometimes you're best bet is to go there and wing it.  Winging it is easier in person.

I'm going to say that again, as somebody who is almost always winging it:

Winging It Is Easier In Person

Another way to look at it is, real or not, your physical presence increases your credibility, provides you with more visual cues on your audience, and taps into your social intelligence in order to make you a better presenter.

I've kind of surprised myself here because I think that business travel is a very poorly controlled cost and many execs overestimate the importance of physical presence... but I've come up with what I feel is some compelling support for the kind of quotidien travel I see in sales organizations.  I do want to talk more about the expense management aspects of travel at some point.

On Business Travel

A brief digression.

Tomorrow, I'm headed to Charlotte, NC for a brief business trip.  My company uses Carlson-Wagonlit Travel (CWT) to manage most of our arrangements.  I still have to choose my own flights and hotels, etc. but it's all based on the options that CWT provides.

Usually, this process is awful.  I can easily find better flights on Kayak, or with my carrier of choice, or basically through any other service that provides flight information free of whatever meddling happens between CWT's retrieval of flight data and presentation of options.  I am exhorted at every turn to save money, but no reasonable hotels are found close to my clients.  I almost never have to rent a car and find the idea of booking a flight, hotel, and car all at once somewhat uncomfortable, like it's an abnormally large commitment.  The net effect is, left to my own devices, my desire to do the right thing by the accounts payable office typically ends up costing my company quite a lot in terms of lost productivity.

This time around, I embraced the process and ignored the warnings.  I would use the system correctly, common sense be damned.  CWT ranked some cheaper options, like a redeye, ahead of the direct flights, but recovering from rough travel could disrupt my entire week.  A decent hotel was easy to find, as prices in Charlotte are less than half of what you might see in NY or LA, to say nothing of Paris.  I added the car later.  It all worked.  It was all easy.

To a degree, this trip has helped me understand better how business travel is supposed to function.  I have previously traveled on multi-segment trips to major cities or to the middle of nowhere, but almost never have I gone someplace "normal".  Maybe this is what most business travel is usually like: a medium-size city where you'll need a car.  Trips to conventions.  Trips to meet with "normal" customers with "normal" businesses that have factories or corporate offices in whatever midwestern state the founders are from.

The system works for these cases.  Costs remain in a predictable band.  You can set up policies to match these cases and you can watch those policies be effective.

You can't apply the same policies to major cities or remote destinations.

So, what kind of policies do you need?  When/why should you travel?  I think I'll have a little more to write about this over the coming week.

Pricing part II

Right now we have some potential frameworks for a price. There are still many other things we need to discuss before we can add some coefficients (cost per user, cost per year) to this model.  Let's think a little about the range of acceptable prices.

First, you can't price software based on the effort it took to create it.  Because you can produce and sell a potentially unlimited amount of the stuff, there's no concept of making some sort of margin on top of recouping the cost of development.

You can loosely base your price on the value it will add for the buyer, but this number will not be universal. Further, in many cases a business value analysis is a post-fact exercise delivered after the pricing proposal.  It is unlikely that the customer would let a vendor perform a weeks-long analysis of their current systems and workflows at an early stage in the sales process.

It sounds silly to say this, but the cost of software is essentially whatever the customer is willing to pay for it.  Vendors and buyers perform a dance that is all about hiding/discovering this number.  The actual price that either party is willing to accept could range considerably.  Imagine a software system that usually sells in the deep six figure range.  Ignoring the costs of implementation and support (which do matter, just not to the sales team), a vendor might be perfectly happy to get as little 500K or as much as a million bucks.  It's all down to the customer's budget and the strength of the vendor's position in the market.

If the vendor is sufficiently weak, they might sell a a million dollars' worth of software for much less than 50% of the price; just so long as they're not giving the stuff away.  The principle behind this is that it's all revenue at the end, that the effort was made to close the sale, so why not just take the money?  There are indeed negative consequences: services and support resources get tied up, more defects/enhancements are required from development, and so on.  

This impact to other teams does not scale with price.  The potential complexity of a deployment + increased development burden is possibly one of the only reasons why any sales team would walk away from a low margin opportunity.  However, technology teams are at a disadvantage at this point because these costs are very difficult to measure.  An experienced professional services consultant might say "I just know this will go badly" when a customer asks for the moon.  It is important for technologists to learn how to communicate the costs of bad deals in real terms, so that sales teams can learn that there is a point at which the margins are indeed too low.

What is enterprise software worth?

What should you pay for a big pile of code anyway?

Price transparency is effectively unheard of in enterprise software.  Even the most popular technologies, with posted pricing models and customer reviews, won't be able to tell you exactly what your implementation might cost.

But before we even get to rationales for the actual costs, let's consider some of the different dimensions that can be used to come up with a price.  Note that many of the options within these dimension aren't even exclusive.  Here we go:

1. Timing and Recurrence
1. Perpetual
2. Annual
3. Monthly
2. Support and Maintenance
1. Fixed percentage (usually 20%) on an annual basis
2. Included in annual license fees
3. Optional SLAs, training and support packages
3. Users
1. Named users
2. Concurrent users
3. Department or enterprise-wide
4. Content or Traffic
1. Disk space
2. Number of objects
3. Number of accounts (e.g. a mail backup service)
4. I/Os (such as traffic to a website, queries to a database, reports per month)
5. Hardware
1. Logical machines (this is going out of vogue due to need for horizontal scaling, virtualization)
2. Cores/CPUs
3. Data centers or geographic locales
4. In-house vs. SaaS

In a future post, I'll explore a couple common models and how a vendor might arrive at their price.