Before we built Intervals, our flagship time tracking software, we were a professional services agency that designed and developed web sites. In a span of five years we built and deployed over 300 projects. As a small team of designers and engineers, we had to be efficient if we were going to be successful. And that meant dialing in our project management process.
There was one part of the process, however, that we always grappled with — estimating new projects. We got our estimates wrong more than a few times and lost money on those projects. These experiences were always painful, but, they also inspired us to create our time tracking software, Intervals, to ultimately fix the problem.
Based on our own failures, here are three reasons why estimating projects is difficult, and how time tracking software can help.
Emotions sway estimates
We naturally formed an opinion about every project we estimated. Some projects had an air of excitement and buzz. Some projects promised to be practical and profitable. And some projects seemed downright tedious and boring. The bias we each formed in our minds was noticeable in how we created our estimates.
We had a habit of underestimating most of our projects. However, the degree to which we underestimated each one was directly affected by our perception of the project. If the project was an opportunity to work on something new and cutting edge, for example, we had to be careful not to let our excitement sway us toward promising too much. If the project seemed boring, we wouldn’t put our best effort into the estimate.
Time tracking software solved this problem by giving us objective data that can’t be swayed by emotion. Data that reveals how similar projects have unfolded in the past. When we referenced past projects our estimates became increasingly more accurate with each new contract.
Scope is difficult to define
The typical approach to a project was to wait until the scope was complete before creating an estimate. The problem with this approach is that the requirements were difficult to encapsulate in a single document, and even if they were, they would often change mid project. This was especially true with web design and development, where clients couldn’t visualize the end product until you actually started building it.
If the scope is going to change unexpectedly the accuracy of your estimate doesn’t matter. It’s going to be irrelevant after that first change request. To stop this from happening, we would give our clients two choices. They could provide a more detailed, concrete scope that we would estimate up front. Or, we could do the work under a time and materials contract, estimating each phase along the way.
If the client chose to deliver a more detailed scope, we would reference the time tracking data from past projects to build a more accurate estimate. If they chose the second option, we would use time tracking software to keep track of the billable hours and use that data to build detailed monthly reports and invoices.
Experience helps, but…
Estimating is a learned skill that takes time to hone. Even after years of experience, some people will still struggle with estimating their own time. When we would create estimates we would start by breaking down the project into the smallest number of parts possible. Then we’d ask each person on the team to evaluate their portion of the work on each of those parts.
After months and years of estimating project based work, individuals on our team (including myself) would continue to underestimate their time. We learned to increase each of our estimates by a certain percentage to account for the discrepancy. Even then, estimating was still difficult.
We fixed this problem by configuring our time tracking software to keep track of hours using the same breakdown as our estimates. By tracking time on each individual part of a project, our data was structured in a way that made it easy to create estimates. When estimating a new project, we would still break it down into smaller parts, but then we’d reference past projects to see how long it took to develop those same, or similar, parts.
