Saturday, 21 August 2010

The product-to-service financial ratio


Yesterday I saw a tweet by Frank Scavo:
Chatting with a vendor about implementation cost to software license cost ratios.
What followed next was somewhat of a diabate (sic) by me with Frank and Dennis Howlett.

Only today I found out I missed half of what Frank said, because I kept swapping between Twitter web and TweetDeck - Lessons Learned for me to never do that again while in the middle of a conv. Sorry Frank, you're an angel, given the benefit of hindsight, and I thought you were pretty OK even before that...

Back to the topic: there is a clear, direct and fairly linear relation between the initial cost of a product, and the additional cost(s) involved servicing it. In IT, every day life - everywhere.
I was painting the front of my house yesterday, thinking about this post. The brother of an old friend of mine used to "pose as professional painter" whenever he needed money. He'd go to big mansions, tell them they needed a paint job, and make them an offer. Usually, the people were glad and gave him the work

The secret to that? Asking a lot of money! "For a regular house, I'll ask 1% of what I estimate the house to be worth", he said. "If it's a bit more wood, I'll double, sometimes even triple that."
I was stunned. I always (I moonlighted a bit as jack-of-all-trades back in those days) used to estimate the work in hours and material, put in my rate et voila. Not him - he sometimes made 200 euro an hour just painting...

Ages ago, my wife went to the garage with our old car, and came back with a huge bill: double the then current value! The car was pretty old and had one, at most two years to live, and they installed a completely new exhaust pipe, brand new tires all over, and whatnot. I complained, but they didn't care. So I wrote a letter (yes it's really long ago) to the company's CEO, got a response and 60% off the price - he also agreed the cost of the service was too high given the value of the product itself

I bought myself a new laptop yesterday, a budget one costing less than 500 euro, for my new startup. A soon-to-be ex-colleague asked me on Twitter: "No SSD?" and I responded:
No, minimum required size would be 64 GB = 120 euro, being 1/4th extra. I'll put my swap mem on an SD, way cheaper
The (admittedly very sexy) hard disk would be 1/4th of the current price of my laptop! No way...

In big IT companies, there isn't much enthusiasm to be found for selling Open Source products. I always wondered about that, and asked around. I got always the same answer: "The software costs are so low that our sales tariff sticks out like a fly on the wall". Even when I tried "Yes but they would even make money given the fact that they hardly have to pay for the software!" I'd get that look - yes you're right but this is just how it is (viewed upon)...

In IT, there are socalled packages. SAP and Oracle are examples of those, and they "pre-cook" applications: HR, Financials, Call-centre, etcetera. I've always been a bit jealous of colleagues who worked with those applications because they have a higher salary, period. Which felt a bit frustrating because sure, they specialise, but heck, they also monoculture. When Baan died, most Baan expert "died" along with it, because it was all they could - which proved my point of the monoculture and the narrowness of their point of view

Still, they made more money than I did because the rates were higher - simple as that. Now why are the rates higher? Because the product is more expensive.
"It is a complex product" they say - that can't be the case, a package is supposed to be simple and save you time: that's why you pay upfront for functionality that's already there.
"We have to tailor-make it to the customer's needs" - big deal, that's what we COBOL / Java / .Net and whatnot people do every single day - and we're still cheaper
  • In Switzerland, they fine relative to your income - that's why people don't mind getting a $290,000 speeding ticket
  • Taxes are relative to your income
  • Damage deposits are relative to the item price itself
  • Down payments are relative to the total sum
  • etcetera...
Morale of the story? We all tolerate a similar bandwidth between value and cost. And that's the reason why SAP and Oracle implementations are so expensive: because they can...

4 reacties:

Peter Evans-Greenwood said...

First thought: what does this mean for Salesforce.com consultants (which I hear is where a lot of the SIs are heading)?

What's more interesting is when you consider techniques like comparative pricing. There was a great post (which I can't find at the moment) the went through some of the tricks used on menus to try and get us to pay more. Tricks like putting a slightly cheaper items next to an expensive item to make the expensive item more affordable, or putting an extremely highly priced seafood platter at the top of the menu to "manage expectations". What are the analogous tricks in the software servies world?

Wim Rampen said...

Hi Martijn,

Nice observations..

Humans make complex and most of the times unconscious trade-offs of the costs and the value to them.. Businesses like to think they do a more "fact-based" decision making, but in fact they're just a collection of humans too..

We really do not know a lot about what's of value to the Customer.. and because we do not really understand how value is created, we just use rules of thumb like the painter, or the software vendor with their 20 % of license fee as "support costs"...

If we really understood the relative contribution to the value created with the (end) customer, SAP and Oracle, including their consultants, might just be a whole lot more expensive, or worthless for that matter..

Martijn Linssen said...

Interesting question Peter! I have no idea what SFDC consultants ask / make
With regards to comparative pricing: there are lots of tricks indeed. You must remember the sales tariff versus the purchase tariff versus the Charge-out-rate?...

Thanks Wim! Astute observation about the business humans! It's really hard to measure it all, and it doesn't help that SAP and Oracle offer what i call "future lock-in": the money spent on it all runs in the millions and all that won't even start to pay back or ROI well within years from now. So, anyone saying "it wasn't worth it" within 2-3 years is simply ignored or decapitated
And before the 5 or 10 years are over, there have been updates, customisations, add-ons, and it all gets very complex measuring exactly what you paid for which, and what the return is

Salesforce.com might challenge them a bit, but of course they do observe the product-to-service ratio as well: they simply ask a little less than what their competitors do...

eva.santisteban said...

Good post!,

Each time that I asked why technical consultants and functional consultants had different rates (salaries) got the same answer: "Functional also is consultant, technical not"
- Who use to say that?, ... a functional consultant. -

Who is the people in charge of contracting an IT project in the company?: CEO (with functional background), Financial Staff, etc..
The question is how you make notice to your client that the price is good.

But fortunately times are changing and each time more IT specialist are reaching higher levels in the company, so can value more the technical work. They can understand better what you offer.

What I mean is that the value/rates/salaries etc is a question of perception based on comparison or other kind of basis.

My experiences in ERP implementation is that is something to suffer and pay in high rates. Even if you are implementing an Open Source the cost is very high because the projects have the same kind of problems.

Post a Comment

Thank you for sharing your thoughts! Copy your comment before signing in...