Yesterday I wrote about my deck staining project and how it, like software projects, was spiraling out of control. I mentioned I would make some comparisons to software estimates, but I don’t have the book I planned to reference with me. Oops.
Scott McConnell’s Software Estimation: Demystifying The Black Art covers a number of factors that can swing a software estimate greatly in different ways.
Here are three factors which affect the outcome of a project estimate:
Expertise of the team
How familiar is the team with the toolset and business domain. Has the team programmed in the language before and how familiar are they with the frameworks and libraries? Have they solved a business problem like this before? Is the team assumed to work on the project when it was estimated the same team that actually builds the software?
For my deck project, it was me, and I know about how handy I am. It was essentially a 1:1 ratio as far as the project went.
Similar projects
Has this kind of project been done before? Estimating a project with a similar scope to one done before will be more accurate than completely new idea.
With the deck, I knew the project was 3 times as large as staining projects I had done before, and I wanted to make sure to put on two coats of stain.
Unplanned Requirements
Part of honing in on an accurate estimate is understanding what the project really entails. Sometimes this is thrown under the category of scope creep - where the requirements aren’t clear until the project has moved further into the analysis and design phases, and sometimes all the way into development.
In my case, I chose to replace the balusters with cable rope. This was an expensive choice, but it will improve the results of the project - our enjoyment of the less-obstructed view.
There are many things that can change the outcome of a project. Hopefully, you can minimize these factors i your projects in the future.