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…

This article is an excellent one from Craig Buckler. Happened to read this and being a developer myself basically, I…

Software estimation is difficult.

At Dynamics GP Land Steve Endow writes about the 30% rule while preparing estimates for Custom Software Development. He talks about how while estimating, its generally a good idea to add 30% extra time to account for risks, changing requirements and overheads. Steve has found this to be practically useful while reviewing budget to actual.

The most interesting thing for me from the post is Steve's point about how often making an accurate estimate means you end up being less…