Fighiting Estimation Fatigue - Part 1: Software Project Management perspective

Software Estimation is often considered as a black art which is mostly neglected during the inception of an Information Technology Project, nonetheless almost always is used to formulate two most important attributes of a project i.e. the cost and the deadline, and often with a rigid expectation of high level of accuracy to hit the targeted project deadline. 

There is a viscous cycle in the whole estimation thing: when executives ask the Project Manager for estimation, it is often portrayed as, which should always be the true purpose of estimation, which is, to get a "ball park" figure to gauge the depth of the water or to be exact, should the executive be bother about the project and invest her time to materialize the project from its conceptual level. But, as soon as the estimation is handed over for that project, that number is considered as a commitment from the project manager. Later on, if that project deviates from that supposedly “ball park figure” estimation, the project manager is personally held liable for that deviation. 

 

So the project managers are either unwilling to provide an estimation at all or pad the estimation to cover themselves from the uncertainties and unknowns of projects. This is a classic “catch 22” situation for most of the project managers who are managing software development projects or planning to start a career as Project Manager of Information Technology.  Now, the million dollar question would be: how an IT PM should walk on that double edge sword, if you will, to provide true estimation of software project without falling into that “commitment” trap.

I am working on a series of blog posts where I would try to answer that question including overview of some of the well-known, in terms of market share and most commonly used, software cost estimation models such as Function Point Analysis, Use Case Point, and Heuristic method. I would create a framework and guideline to help the IT Project Managers to choose the right estimation model for their software projects. The posts would also have a list of best practices that would help to fight “estimation fatigue” and prepare Project Managers to duck the most common pitfalls where they’re forced to respond with a “ball park figure”, sometime at a water-cooler conversation, at a very early stage of projects. There is an important, but often ignored, characteristic of software estimation which is called “the cone of uncertainty”. I would also touch upon that characteristic in brief by showing how to effectively use that phenomenon to build confidence and earn the trust of the executive sponsors and senior management of your organization.