An Estimate is not a Commitment

In our quest to shake off the shackles of the past and leave waterfall permanently in our rearview mirrors, we sometimes forget the still important task of estimating. It, like any other, is a skill that requires knowledge, wisdom, experience, and a lot of luck. In order for us to move toward better estimating, we need to identify areas of our processes and behaviors that are repeatable and quantifiable.

I would liken this to a professional painter and the action of painting a room. He follows a well-defined and measurable process. It is that process which, when put into practice, allows him to estimate the duration for properly painting the walls of a two hundred square foot room versus a two thousand square foot room.

So what behaviors and processes can we define as repeatable or predictable such that a dollar amount can be assigned to them? Let’s list some of the steps in our process and see if any fit the bill. Requirements gathering, writing user stories, design and architecture planning and development, unit and integration testing, domain identification and definition, database schema design, and QA.

After careful review, it may be that none of these things can be effectively quantified, partially because the process begins with a moving target - requirements gathering. Each project is as unique as the needs of our clients. Although there are similarities and the potential of some overlap from project to project, the uniqueness of each is one of the contributing factors to the challenge of estimating effectively. We must not be fearful in making our clients fully aware of this and invite and encourage them to become integral in the process.

Once a client sees a number it is no longer an estimate - it is a commitment. So when asked for an estimate, I respond with “two million dollars”. Usually I come in under budget.