Developers often get asked the question “how long does it take to make a program?” If you are working on a small project, and clearly, it could take a day or two, then you don’t need a lot of science to come-up with a reasonable answer. In contrast, if you are asked to produce a timeline for a project that will last for a person-month, this is more of a big deal. If you are getting paid by your ability to complete your work by the estimated timeline (aka “fixed bid”), it could be a huge deal.
Back in the day, I worked for a company that would write IT systems (programs) for companies. The sales process usually went like this: a sales rep knew somebody in an IT department (aka “the customer”). The customer needed some work done. The sales rep would listen to the idea and would convince the customer that we could do the work with a high level of quality, at a very reasonable price. The customer would push for a more exact price. At that point, the sales rep would either A) completely lose his mind and actually quote a price, that we (my programming team and I) would later, be expected to adhere-to, or B) bring-in a senior programmer to get more information, so we could deliver an accurate estimate.
When I first started acting as a technical sales liaison, I didn’t know what to do. So I did my best and made a few mistakes but I learned from them.
Finding a good technique
I was fortunate enough to remember my “software engineering” course from college (and I also kept the book). During that course, the professor had us learn software engineering, in a subjective manner. We split-up into teams, we came-up-with a med/large project to work-on during our course, and as we learned about different parts of the development cycle, we applied each of the techniques to our project(s).
One of the software engineering techniques that really stood-out (in my mind) was estimation. Our class did a compare/contrast of FP (Function Point analysis) and CoCoMo (Cost acCounting Model). I remember how surprised I was by my calculations. My estimates said that my team’s project was going to be much bigger than I had initially surmised. I couldn’t believe that it would actually take us that long to complete the project. I had even suggested that we should slash those numbers to something more realistic (IMO). However, we stuck with the FP and CoCoMo estimates because we thought there was a greater chance to learn, by leaving the estimates (formula results) unchanged. We would see who was exaggerating: me, or the formulas.
By the end of the course, I was astounded to find that the seemingly inflated estimates turned out to be very accurate. Additionally, the variances in accuracy (between FP or CoCoMo and the actual outcome) could be explained by a lack of clarity (requirements) before I started, or by scope-creep (expansion) that I allowed. Basically, the numbers were dead-on. If I had started with accurate requirements, it would have been scary-accurate.
My first professional estimate
I regaled my college experience to my boss. He was a sales rep, and he really wanted us to get accurate estimates. It was very important to him. When I first pitched the idea of FP to him, he said that it sounded like a lot of work and questioned if it was worth-it. I convinced him to let me try it on one project (requiring no effort on his part). The work, up-front was a little tedious because I needed to gather more details than a sales-rep is accustomed to. However, I recalled that the more information I had, the more accurate the estimate would be.
The result was excellent. We were accurate within 5% for a one person-month project (btw, that is very good). FP was a big winner again. My boss was so encouraged, that he evangelized all of the sales reps and tech liaisons in our office, to use FP for estimating development projects. As we got better at it, we also tuned our process for gathering information, prior-to making estimates. Then we produced even-more-accurate estimates.
Spreading the joy
My group was in a satellite office. Our main office was in Auburn Hills, MI. My boss started talking to the folks in the main office, about their methods for getting accurate estimates. They had two popular estimation processes: the “Vince” method and the “Steve times 2.5” method. Basically, Vince was a guy who was unusually gifted at determining accurate estimates in his head. There was only one “Vince” and it was hard to bring him along on all of the sales calls. because Vince was also excellent at programming. When he didn’t have a keyboard under his hands, he wasn’t making money. Steve was also completely brilliant and therefore, good at giving estimates. Unfortunately, Steve was actually 2.5 times better than the average programmer. He was a nice guy and gave his colleagues a lot of credit (perhaps too much). Vince figured this out and recommended that the sales reps needed to multiply Steve’s estimates by 2.5. When they did, Steve’s estimates were usually very close.
Unfortunately, we could not bottle the Vince or Steve method. There was no way to teach it to all of the sales reps. So to improve our scalability, the sales reps at the main office embraced FP, especially for very large projects. If you think about it, the accuracy of your estimates is going to have a strong effect on your profit margin. As IT became more competitive (after Y2k), it was hard to pass-up a paying project unless you knew you would lose money on it. FP gave us confidence to make good decisions in that regard.
In part 2, I will discuss some of the ways that FP is often deconstructed (or imitated) and I will discuss some of the other benefits that go beyond simply making an accurate estimate.