Thursday, January 31, 2008

Why no one wants software: a case study

No one wants software.

Really, no one.

What they want is documents ... pictures ... loan applications ... insurance claims ... Software is just another tool they can use to maybe produce more of the things they really want, better or cheaper.

What this means to legions of unhappy, cynical programmers is that no one cares about the quality of the code. Nope. They don't. And odds are, they shouldn't.

Here's a little story to illustrate why. (By the way, this is the kind of thing you'll see in an MBA course. If you don't already do this kind of thinking, you should stop telling yourself there's no value in getting an MBA.)

The pitch

I'm in charge at an insurance company. I have a manual, paper-based process that requires 100 people working full time to process all the claims.

Someone comes in and offers to build me a system to automate much of the process. He projects the new system could reduce headcount by half. It will take six months for a team of four people to build.

If you're a programmer, and you think this probably sounds like a winner, try looking at the real numbers.

The direct cost

100 claims processors working at $8/hour. $1.6M per year in salaries. (Let's leave benefits out of it. The insurance company probably does.)

Four people on the project:
  • architect/dev lead, $100/hour
  • junior dev, $60/hour
  • DBA, $80/hour
  • analyst/UI designer, $75/hour
Total $325/hour, or about $325k for six months' work.

Still sounds like a winner, right? $325k for an $800k/year savings!

Except the savings doesn't start for six months. So my first year savings are at best $400k. Damn, now it's barely breaking even in the first year. That's OK though, it'll start paying off nicely in year two.

The hidden costs

Oh wait, then I need to include training costs for the new system. Let's figure four weeks of training before processors are back to their current efficiency. Maybe a short-term 20% bump in headcount through a temp agency to maintain current throughput during the conversion and training. Add the agency cut and you're paying $15/hour for the temps. 20 temps x $15/hour x 40 hours x 4 weeks = $48k one-time cost. Now my first-year cost is up to $373k.

And don't forget to add the cost of hiring a trainer. Say two weeks to create the training materials plus the four weeks of on-site training. Since this is a high-skill, short-term gig (possibly with travel) I'll be paying probably $150/hour or more. $36k for the trainer.

So if everything goes perfectly, I'll be paying $409k in the first year. And actually, I don't get even the $400k savings. I can't start cutting headcount until efficiency actully doubles. Generously assume that will be three months after the training finishes. Now I've got three months of gradually declining headcount, and only two months of full headcount reduction. Maybe $200k in reduced salary.

Of course you need to add a percentage for profit for the development company. Let's go with 30%. So ...

The balance sheet

Software$325k + 30% = $422.5k
Training (temps)$48k
Total Y1 cost$506.5k
Projected Y1 savings$200k
Y2 savings$64k/month

The project breaks even near the end of the fifth month of year 2. And that's if NOTHING GOES WRONG! The code works on time, it does exactly what it's supposed to, I don't lose all my senior processors as they see the layoffs starting, etc. etc. etc.

The other pitch

Then a lone consultant comes in and offers to build me a little Access database app. A simple data-entry form to replace the paper version, a printable claim form, and a couple quick management reports. Two months' work, and I'll see a 10% headcount reduction. The consultant will do the training, which will only take a week because the new app will duplicate their current workflow.

Software$200/hour x 8 weeks = $64k
Training$200/hour x 1 week = $8k
Total Y1 cost$72k
Savings$12.8k/month (starting in the fourth month)

The project breaks even six months after the project is done, so early in the ninth month of Y1. Since the scope was much less ambitious, the risk is also lower.

The obvious choice

Which sales pitch do you think I will go with? Does that mean I don't respect "proper" software development practices? And, the bottom line: should I spend more money on the "better" solution? And why?

No comments: