The 30% Rule

Estimating the cost of custom software development is difficult. I've tried to think of ways to make it more accurate and reliable, but unfortunately so far I haven't found anything better than the "30% Rule".

Many years ago I had the privilege of working with a veteran software developer named Jim Walters. Jim probably had over 25 years of experience by that time, and had years of experience developing complex, global software applications. As he and I began to work on a new project, a custom medical clinic scheduling and patient management system, we documented the requirements and then worked on an estimate for the project.

The scope was pretty significant, and the hours were correspondingly large. When we finally filled in the all of tasks that we could think of and put hours next to them, Jim added up the total hours in Excel. He then added a formula below the total where he multiplied the hours by 1.3, which he declared was the realistic estimate for the project.

When I asked him about the 30% factor, he said that over the course of many years and many projects, he and colleagues had analyzed their estimates and their actual hours to complete projects, and overall, they came to a conclusion: Despite their best efforts to estimate complex software development projects accurately, they typically ended up requiring roughly 30% more time than they estimated. 30% seems like a lot though, doesn't it? And adding a 30% margin on top of an estimate could give the impression that you don't know what you are doing--either you can't code "efficiently", or you can't estimate.

He explained that custom software development is complex. It is difficult to anticipate and gather every requirement before the project starts. Sometimes business users don't even know that some things are requirements. And sometimes business users change their minds. And nearly every complex software project runs into at least one form of technical issue, whether it is a bug, and incompatibility, or simply something that you haven't coded or used before, and therefore have to figure out and learn. It's complex and by definition, you've never coded this custom software before, and therefore you can't possibly anticipate everything in advance and bake it into an estimate.

So, we used his 30% rule to produce an estimate for the project, which we then presented to management for approval. After the project was completed and delivered, I reviewed the budget to actual, and sure enough, we came in at 128% of our original estimate.

Despite the apparent wisdom of the 30% rule, I've struggled to use it in most of my GP projects. One challenge is simply remembering to add the 1.3 factor--if a project is something I've done before, I sometimes forget the potential risks, and therefore forget to factor those unknown risks into my estimate.

More commonly, it has been very difficult to "sell" this factor to most people, even if they don't know that I'm using it. By presenting a realistic estimate that reflects the likely total cost of the project, you run the risk of giving people sticker shock. Salespeople want to sell the solution at a "competitive" price, which is almost always lower than your estimate. And then there are clients who see the total hours and assess that the estimate is "too high", or simply too expensive for them, killing the project. And if you are bidding against a firm that can't estimate accurately, does not provide a realistic estimate, or simply underbids, your estimate will look much too high, even if it is accurate, thereby damaging your credibility and trust with the client.

Even if these challenges make it difficult to use the 30% rule for estimates that are presented to management or clients, I still think it is a good practice to keep the 1.3 number in mind, and make certain preparations in case you do exceed your original (non 1.3x) estimate. It would allow you to be more cognizant of scope changes, the need for change requests, and the need for budget discussions during the project, rather than waiting until you are over budget to have those conversations.

If anyone has any other good suggestions for estimating custom development, I'm all ears!