Tag: budget

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 actually 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
Trainer $36k
Training (temps) $48k
Total Y1 cost $506.5k
Projected Y1 savings $200k
Shortfall $306.5k
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?

How to Fail by Succeeding

Dave Christiansen over at Information Technology Dark Side is talking about perverse incentives in project management, which he defines as:

Any policy, practice, cultural value, or behavior that creates perceived or real obstacles to acting in the best interest of the organization.

One class of these perverse incentives comes from the methodology police. These departments exist to turn all processes into checklists. If only you would follow the checklist, everything will work. But more importantly, if you follow the checklist you can’t be blamed if you fail.

How’s that for perverse?

A great example is that there is rarely any incentive to not spend money. Before you decide I’m out of touch with reality, notice I didn’t say “save money.” I said “not spend money.” Here’s the difference.

IT by the numbers

Let’s say you do internal IT for a company that produces widgets. Someone from Operations says that they need a new application to track defects. If you follow the checklist, you:

  • engage a business analyst, who
  • documents the business requirements, including
  • calculating the Quantifiable Business Objective, then
  • writes a specification, which is
  • inspected for completeness and format, then
  • passed on to an architect, who
  • determines if there is an off-the-shelf solution, or if it needs custom development.

At this point you’re probably several weeks and tens of thousands of dollars into the Analysis Phase of your Software Development Lifecycle. Whose job is it to step in and point out that all Ops needs is a spreadsheet with an input form and some formulas to spit out a weekly report?

Let’s put some numbers to this thing.

Assume the new reporting system will identify production problems. With this new information, Operations can save $100,000 per month. A standard ROI calculation says the project should cost no more than $2.4-million, so that it will pay for itself within two years.

Take 25% of that for hardware costs, and 25% for first-year licensing, you’ve got $1.2-million for labor costs. If people are billed out at $100/hour – and contractors can easily go three to four times that for niche industries – that’s 300 man-weeks of labor. Get ten people on the project – a project manager, two business analysts, four programmers, two testers, one sysadmin – and that’s about seven months.

If everything goes exactly to plan, seven months after the initial request you’re $2.4-million in the hole and you start saving $100,000 per month in reduced production costs. Everyone gets their bonus.

And 31 months after the initial request, assuming nothing has changed, you break even on the investment. Assuming the new system had $0 support costs.

But what if …

Way back at the first step, you gave a programmer a week to come up with a spreadsheet. Maybe the reports aren’t as good as what the large project would have produced. You only enable $50,000 per month in savings. That week to produce it costs you $4,000 in labor, and $0 in hardware and licensing.

You are only able to show half the operational savings, so you don’t get a bonus. You don’t get to put “brought multi-million dollar project in on time and on budget” on your resume.

And 31 months after the initial request, the spreadsheet has enabled over $1.5-million in operational savings.

What conclusion would you like me to reach?

Why is it that the rest of the world has functioned fine on estimating projects of many sizes and scopes, then sticking to them; while IT screams “OH WE can’t do that!”?

I’ll admit a large reason is because lots of people in IT are really bad at estimating. But part of the reason we’ve managed to stay so bad at estimating, and the main reason all estimates seem to be so far off, is that the business side wants the estimates to be low.

The common complaint is that IT projects are “always over time and over budget”. Since the IT budget (for software) is almost entirely salary, time and budget are synonymous. When you set the budget, you’ve just set the time.

But most IT projects — and nearly every one I’ve worked on — have a budget set before the detailed design is ever done. Or at least the clients have an idea in mind what they’d like it to cost. So without realizing they’re doing so, the clients set the time estimate sometimes before they’ve ever talked to the developers.

I had to help out some less-experienced people who were being asked for estimates. I told them the trick is to figure out a diplomatic way to ask, “What number would you like me to say?”

The funny thing is that this is not just being cynical, either. There’s real value to it. If you’re thinking four months and the client says three days, there’s a good chance you don’t have the same idea in mind for what you plan to do.

For instance, they ask you to write a search engine “like Google” to put on your intranet. You’re thinking a couple of months. They’re thinking end of the week.

It turns out they want you to buy a Google search appliance and integrate it into the intranet. To the client, “write” “create” “implement” “install” and all those other words we use that mean different things … all mean the same thing: work that the IT guys do.

So if you want to get the work — or if you’re an employee and have no choice in the matter — see what number they have in mind already and tell them what they can have in that length of time. If you don’t promise to deliver something in the given time frame, they’ll go find someone who will. Not that they’ll deliver in that time, but they’ll promise to deliver in that time.

Compare this to construction. The client may get five quotes for pouring concrete. If four of the bids are close to $50k, but one of them is $20k, the client will likely assume the low bid is unrealistic and choose among the remaining contractors.

But if a programmer or independent software vendor says some work will cost $50k, the client can find someone who will promise to deliver for $20k. The sponsor will either accept the lower bid, or use it to negotiate the first vendor down to $25k. When it ends up costing $50k, that project goes in the books as “over time and over budget”.

What would it look like if construction bids were awarded the same way? If for instance the client were required by law to select the lowest bid? Then contractors would low-ball every bid to get the contract. You’d end up with construction that always ran over time and over budget. You would need an endless supply of money to stay in business. You would need to be … the government.