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.
