About a decade back I was attending a workshop on Function Point (FP) estimation technique. Being a senior developer I could understand almost nothing from that workshop, nor was I trying to understand. After the session we were given a case study of a small Sales Inventory application, and we were asked to estimate the same for Effort and Schedule – good that the faculty did not ask for estimating the size though that was the key learning from the session. After some deliberation I decided to use my guts to get a figure both for Effort and Schedule, and guess the result … my educated guess (guesstimation) was 99 percent accurate! Well, that’s what it (Estimation) was in those days. We had plenty of techniques to do software estimation and few of us diligently followed quite a few of them, while most of us used our guts to get a number and then used any of the popular techniques to match the guesstimated numbers (I call this as back-calculated). Moreover, the reviewers also followed the same techniques while reviewing the estimation.

If we dig this issue further we can’t blame those who often use their guesstimation powers to get the number (with +/- 30 percent variance) and I think the main reason is only one. In the last ten years industry really did not spend time and energy to innovate an accurate estimation model or framework. At the same time, IT companies were never challenged by their customers for the quoted cost & schedule. This was primarily because of huge dollar savings through outsourcing implementation work to low-cost countries like India, Mexico, and China. The customer never felt the need to be educated in this subject. During the 1990’s the customer was even ready to outsource work in time and money model (T&M model). Unfortunately, with T&M model IT companies never felt the need for an accurate estimation model as at the end of the day customers were being charged by the offshore headcount and not on the size of the work.

However, during the late 1990’s and the opening years of the present decade, customers felt that they were paying more with T&M model and enforced the Fixed Price Model for any software implementation work outsourced to offshore or near shore. That’s when industry was faced with the challenge of estimating accurately during proposal stage and software estimation became one of the most critical tasks as part of engineering lifecycle.
Having said this, I think industry was a bit late to recognize the need for an accurate model for estimation. Since, by then the nature of outsourced work had changed. It was a paradigm shift from the low-value coding & bug fixing work to high value enterprise implementation for full engineering lifecycle. While the customer started expecting more and more in less cost, IT companies struggled with cost overrun and poor quality. At the same time, industry leaders like SUN, IBM, and Microsoft challenged the Legacy Applications by coming up with higher-end servers and PCs and arguably few robust enterprise frameworks for delivering application much faster and customers started showing interest to migrate their existing mainframe applications to modern technology frameworks using Enterprise Architecture (EA). Many implementation frameworks evolved — like Enterprise Unified Process (EUP), a modified version of Rational Unified Process (RUP), Zachman Framework, and TOGAF, to name a few — though the perfect usage of these frameworks is still a challenge.

I think the key constraints to accurately predict costs, timelines, and schedule on software projects on Enterprise Implementation include:

1. The increasing complexity and segmentation of technologies and skills: