Monday, October 03, 2005

The Cost of Late Software

Whatever you may think the cost of late software is, it's at least an order of magnitude more.

Since software development isn't a capital intensive business, requiring lots of up-front investment in materials or equipment, most people would think the cost of a late software project is simply the extra cost of carrying the dev team's salaries for the extra time. Not even including the intangibles like credibility, reputation, missed opportunites, etc., the REAL cost of late software is much higher.

The example I always use comes from a small company I worked with a couple years ago. This company was about 20 people, with 1 flagship product on the market, and another one still being developed in the basement. So all of the company's $4 million/yr revenue came from this one product. It was a piece of enterprise software, that sold for about $50k for several thousand seats. The sales cycle was 6 months - from first introduction, to educating the customer, jumping through all the hoops, and finally closing the sale. The development team was 5 people, and they were working on the next version of the flagship product - a development cycle of 6 to 9 months.

For any company like this, a slip of 30% to the schedule is a BIG deal. Let's say it was a 9 month project. 30% is almost 3 full months. While the cost of carrying the 5 person dev team for another 3 months isn't a heck of a lot of money, the real costs are indirect, and not so obvious. But they are still quantifiable.

To figure out the real cost of the late software in a case like this requires a little modelling, and talking about it with each of the project stakeholders. With a sales cycle of 6 months, Sales teams often end up selling the 'next' version of the product, because by the time they close a deal, the current version has been replaced by the next version anyway. With a 3 month delay (one full Quarter), most of the leads the Sales team is trying to close will also hold their purchase until the software is done. No point in rolling something out, only to have to patch or upgrade it 2 to 3 months later. A whole Quarter's worth of revenue can evaporate in a snap. While it's technically not disappearing (it's merely being delayed), it might as well be for this fiscal year because while the revenue was put on hold, the expenses weren't. So the company loses money during that period. With a longer sales cycle, the Sales team doesn't have the time to quickly react, find new leads, run them through the whole sales process and close new deals to account for the ones delayed. For a company like I described above, that's a $1 million price tag on that 3 month slip in product schedule.

Even if you're not producing enterprise software with really big price tags and long sales cycles, your business has beened planned around so much money coming in during the year (revenue), and so much going out (expenses). Delayed revenue is lost revenue in the context of your current year. It means during the period when the product was supposed to ship and when it actually does, the company is losing money. It doesn't matter how much your product costs or how quickly you can sell it. Even more scary, since revenue for new versions or new products is typically on a slope, don't look at the first 3 months of revenue being lost (delayed), look at the last 3 months of the year - those numbers will be significaly higher. (Think of a product that is planned to earn $50k per month in the first few months, but climb to $100k per month by the end of the year).

Then there's the mis-coordination costs. Marketing dollars get pre-committed, often with non-refundable advertising spots. Or if not non-refundable, there's at least a cancellation penalty. In a company of any size, or with a customer of any size, there are people often booked to rollout these products around their ship date. When the ship date slips, it can cost both organizations for the time that those folks could have been doing other things.

Even if the organization producing the software doesn't sell it for profit - in cases where it's only used internally: The software project was undertaken to improve some facet of operations - to bring new capabilities, or likely to reduce costs. When the software slips, the economic potential of that application (even if it was just to save costs) is not realized.

Every day the software is late, the organization loses money.

The factors may differ from company to company, but the cost of just carrying the dev team's salaries for a couple extra months is usually only a small fraction of the indirect costs. If you sit down with a spreadsheet and run a quick model, the bottom line will often surprise you.

0 Comments:

About

I can't believe that 70% of software projects fail. It's embarrassing. Something is fundamentally broken here. Left to their own devices, people have a way of over-complicating things. It really doesn't have to be that hard. The trick is knowing what to look for and what key factors to manage. The rest is noise.

About Me

Hi, I'm Craig. I'm currently building a company called Devshop.com. Devshop has a new approach to bringing software in on time, and therefore helps eliminate the total cost of late software.
I started coding when I was knee-high to a grasshopper and I have worked for 5 different software companies in the last 12 years, as head of product development.
In early 2004, I became very frustrated with the fact that general purpose project management methodology is not working for the software industry. My personal belief is that to solve this problem, we need to start focusing on specific types of projects, rather than relying on age-old one-size-fits-all practices and techniques.