Here is a simple economic truth. Fixed overhead continues to eat into your cash month after month. It doesn’t differentiate facile, efficient businesses from slow, disorganized, quality-challenged ones.
If it takes eighteen months to get a new product out the door and into the market, and if a product’s gross margin is ten dollars but the corporate overhead is a million a month, it will take the sale of 67,000 more units to break even than if it were to take only six months to market. If the total annual potential is 100,000 units, the slower cycle to market just cost the company two thirds of a year in the product’s profits. With today’s rapid obsolescence, that could be the entire life cycle of the product itself, lost because of being slow to market.
And profits from the sale of the product create cash for development of the next product. If the time to market is slowed by inefficient development, the risk of a competitive product overtaking yours increases dramatically.
[Email readers, continue here…] So the truth of the statement is self-evident. Because fixed overhead burns cash, extended development cycles burn more cash, preventing earlier sale of product, to create even more cash. Efficiency in development pays off in less cost and earlier competitive products, often producing greater market share in the process.
Have you considered how to make your operation more efficient as an important way to increase cash flow? Most of us are quick to worry over cutting costs. Some of us worry over how to greatly increase revenues. Few of us worry over how to squeeze more efficiency out of the development cycle or from the organization itself.
That’s your challenge for the day, week, and month.
Love this challenge. The development cycles in most companies are long. While managing twelve projects at DEC and lots of people, I took time out to calculate the time from project description to release assuming no development time. It was nine months, and that’s fast compared to many other companies.
Large amounts of time were taken up with the initial approval process and the sign-offs upon completion.
If you’re developing software, as I was, then the actual creation of the software becomes a consideration. The time required depends strongly on two things: quality of software engineers and quality of management. Never skimp on these. Better engineers cost more, but an excellent engineer can be ten times as productive as an average one, have fewer post-release bugs, and a more maintainable product.
Management is often overlooked as a factor here. Managers must have the respect of their somewhat difficult software engineers. Software projects just have too many ways to go awry. Decent rapport between software developers and software managers will make a huge difference in the creation time and quality of the final product.
Even if you have all of these pieces in place, you still must make crucial decisions, often early in the project, about trade-offs. Then, you have to keep to them. More features, better performance, and a cleaner user interface often require much more development time. The size (number of code lines) also is an important factor, especially for post-release activities.
I’ve yet to see a software project where the initial specification was not changed during the project. You must have an early review system to catch problems as early as possible so that adjustments have the least impact on schedules.
And people wonder why software projects always tend to be late. I bid and performed many projects during my 15 years of independent contracting and completed every one on time. It can be done.
And what is assumed in Dave’s message but not stated – you have to know what your monthly burn rate is in order to begin to estimate the cost of inefficiency (or the benefit of increased efficiency). If your financial reports are late, poorly prepared or ill-formatted for your comprehension, you likely will not see the cash crunch coming. Just as Harry Keller urges competent software engineers, you have to have a competent financial person on your team. And your spouse doesn’t usually qualify, despite the compensation savings. Trust is good, but trust in competence is better. If you don’t know your numbers, you can’t use them to your advantage or avoid the pitfalls they can reveal.