I have been a software project estimator for 20 years. Like many people who have worked a long time in their profession, I find myself applying my work experience to other events in my life. So, when a family member tells me that he or she will be back from a trip into town at 3:30, I look at their past performance (project history) and what they propose to do (project plan) and add an hour. Usually, I am closer to the mark than they are.
I live on a narrow peninsula that juts into Puget Sound. There is only one road that connects me to the nearest gas station or grocery store which are three miles away. This year that road is undergoing a construction project that is adding bicycle lanes on both sides. Since I am a bicyclist, I don’t complain about the inevitable traffic delays this is causing (long term thinking/delayed gratification). During one of those 20 minute delays my mind began to mull over how I would estimate this road construction (enhancement) project. Based on past local road construction history, if I simply estimated by analogy, I would be reasonably certain that the project will overshoot both schedule and budget which normally represent a best case scenario. But, I am a parametric estimator and began to consider how I would size this. Obviously, the amount of road in the project (the user specified deliverable) would be an important part of the equation. But, it would be only a part. A great deal of preparation (configuration) would be required before any pavement is laid. In fact, six weeks into this project all of the work has consisted of digging ditches, inserting drainage pipes, refilling those same ditches, compacting and leveling them. A good size estimate would need to incorporate that, too.
When estimating software, we often base the project size on the deliverable: how many function points, or lines of code, or reports/screens/interfaces/etc. the project proposes to deliver. Then we adjust the productivity based on the difficulty of delivering these (environmental factors) to produce a schedule/cost/effort estimate. For many software projects, this approach works well. However, when configuration comprises a significant component of the work to be done, it too should be incorporated into the project size.
A few years ago, QSM worked with a large vendor of ERP systems to help them more accurately estimate the installations of their products. They had been doing bottom-up spreadsheet estimates and were dissatisfied with the results. They were dubious that a product designed to estimate software projects would be useful for them since, as they said, “we don’t develop software. We implement systems.” But, they had run out of options and were willing to give us a try. We analyzed scores of their completed projects and came up with these results:
- To their surprise they did develop software: lots of it. Most customers required modifications to the vendor’s products which required them to code extensions, reports, new screens, and interfaces. In fact, the software code comprised 40-60% of the size.
- When we combined the configuration and developed code to determine project size and modeled the completed projects, the patterns for schedule and effort were similar to those for Business IT projects in our historical database.
- Parametric estimation using SLIM-Estimate was a good fit for the ERP implementations they needed to estimate.
- Accurate project size needed to incorporate both the configuration and customization components.
So, for my local road enhancement project, project size consists of the final delivered product and a whole lot of things they need to build to get there (configurations). Since I am not a road engineer, I will not be doing a parametric estimate on this project and will estimate it by analogy and past history. These indicate that although the project is slated to complete by September, I don’t think I’ll be using those new bicycle paths until next year.