How are all late projects the same?
This is inspired by an article by software management legend Tom Demarco. Demarco co-wrote Peopleware: Productive Projects and Teams, a highly influential book that delivers what the title promises. In his article, he writes how all late projects are the same, which uncovers a deep truth that is often ignored about failed projects.
Demarco states the obvious: all late projects are late because they started late. Yes, that’s obvious and unhelpful, until you unpack it and start questioning the fundamentals of your project.
The first possibility is that the market changed. Competition beat you to market. Or alternatives surfaced and destroyed demand. If you had seen the opportunity earlier, you would have started earlier. Or if you had more competitive intelligence, you might have skipped it altogether. So the project is late because of a forecasting or market analysis error.
It could also have been low tolerance for risk. We’ve all heard of products that failed because they came too soon and the market wasn’t ready. So management waits until there is no doubt at all about the viability of the product and now has to catch up. However, Demarco points out that Google came 15 years late to the search engine game yet has crushed the competition. If they failed, would it be correct to say they came late? Or that they built the wrong product? Blaming market timing is kinder to management.
The final reason is the mind blower. Yes, on the surface it’s because the engineering estimate was incorrect. It’s taking longer to build than we thought.
But a late project is not a failure until its cost exceeds its value. This is what Demarco – and I – have seen over and over. A software project can be late, way over budget, and a huge success if management properly calculated the value. When they don’t, the project is deemed a failure, engineering is blamed, and nobody learns a lesson about software economics.
If the project is going to cost $X and will save or make 1.5X in return, that may seem like a good investment. But only if you can guarantee the cost won’t exceed $X. An experienced executive or entrepreneur knows they should not start unless the projected return over the years is 3X or more.
You might think that there are some projects that “have” to be done. Laws, regulations, obvious operational needs. Sarbanes-Oxley. PCI or HIPPA compliance. “Cost center” activities.
That’s wrong. It’s hard to admit, but killing the project or liquidating the business might make more sense. And more than once, a legal requirement has caused that to happen. On the flip side, companies like Airbnb and Uber have decided that the upside is so huge, it’s worth breaking and fighting the law.
Bottom line: there should be a considerable upside to every software project. When there is, budget and schedule will cause a lot less stress.