«Dead Estimators Society - 5 Techniques To Improve Your Project Estimates

A few weeks ago I got together with some friends for a group I founded called "Robin Williams Tribute Night.” The rules are simple:

Somebody in the group picks a classic Robin Williams movie and then hosts a movie night in their apartment for everybody else in the group.

New York City apartments being low on space, many people in the group have small or no TVs. However a few members own projectors and we’ve utilized these to turn unused walls into 100 inch projection screens to excellent effect.

At the most recent movie night, we were setting up to watch Dead Poet’s Society and one attendee asked me how long until we’d start the movie. He had a birthday party to attend later in the night but still wanted to catch as much Robin Williams as he could before leaving.

Basically, he wanted an estimate.

The people had all arrived, the popcorn and chocolates were all laid out, the couches and pillows had been arranged, the wine had been poured. The only remaining task was to set up the projector and push play.

No problem I told him. 15 minutes… tops.

T+0:00: I amble over to the projector’s owner who is deep in conversation with a few other attendees. I patiently wait for a break in the discussion to ask him to start setting up for the movie.

One of the conversationalists suddenly asks my opinion on the topic and without even noticing, 15 minutes passes before I feel a tap on the shoulder.

T+0:15: Refocused, we start setting up the projector. First step: power outlet.

Hmmm, no outlets in easy reach of our ideal projector location. A discussion begins on the pros and cons of locating the host and asking for an extension cord vs rearranging the furniture to use a different wall.

Many attendees take the opportunity to weigh in on the subject.

T+0:20: While the discussion rages on, I decide to take action and locate the host who turns out to be deep in the kitchen cleaning up. I explain the situation and request an extension cord. No problem she says. She’s sure she has one around here somewhere.

We head off across the apartment, picking our way across lounging attendees and make a wide berth around the extension cord vs rearrange debate that continues on without me.

T+0:23: We reach the closet and a quick peak inside doesn’t look promising. Piles of towels, hardware, and knickknacks complete for space amongst the shelves. “Hmmmm. I’m sure it’s in here somewhere.”

T+0:30: Success! Just as I’m beginning to contemplate running downstairs and buying an extension cord, our host peaks out from behind the closet door and hands me the cord.

I head back into the living room triumphant with the cord held high.

We plug in the projector and start setting it up on a small table we’ve chosen for the purpose. But there is one problem. This projector usually hangs from a mount in the ceiling. The controls are on the bottom of the device and its remote control has been left at home.

A focus group is formed to brainstorm structurally sound methods for holding the projector in an aloft yet stable position.

T+0:40: The focus groups is successful. An ingenious method of perfectly sized book stacking has been devised and implemented to the cheers of those assembled. Handshakes and back-slapping all around.

We connect the projector to the laptop that contains the movie, turn on the projector, and place the laptop on the floor, the only stable location not filled with attendees’ butts.

Partial success! The screen of the laptop is indeed projected on the desired wall, but the picture is distorted and too low on the wall.

The chief architects of the book stacking solution reassemble and get to work with gusto.

T+0:50: Our architects have succeeded once again and the screen is looking clear and perfectly placed. We pull up the movie and spend a few minutes wrangling the guests who have migrated about the apartment while we dealt with the technical difficulties.

T+1:00 minutes: We turn out the lights and press play to much cheering and excitement!

Only there is one problem, no sound. Groans ripple through the assembled watchers. What now??!?!! Somebody near the projector yells for quiet. As the noise subsides, we all hear what he is hearing, the soundtrack of the movie coming through oh so faintly from the projector itself.

"Usually I have it plugged into a receiver at home. I didn’t know it had its own tiny speakers. I thought it would play through the computer."

The lights are turned on and the owner of the laptop comes shuffling over and dives deep into the computer’s configuration settings while the other attendees start conversing and meandering off to the far reaches of the apartment.

T+1:15: Suddenly there is a loud blast through the plugged in tower speakers and the movie’s opening lines come through crystal clear. Cheers thunder through the apartment and everyone re-assembles.

The movie is re-started, the lights are turned out, and the last viewer shuffles to their seat and just as they reach it, a crash and a shout! A glass of wine has been kicked over onto the laptop…

The importance of estimates

Spending time working on and improving estimates isn’t as much fun as just diving in to an interesting project but it’s necessary in order to ensure that everybody involved is on board with its potential costs in both time and money.

How many projects would never have been begun if all involved had spent some time estimating the timeline? How many other projects would have had their details drastically altered if you actually knew how much the current spec would cost? How much anger and frustration could have been avoided? How many otherwise profitable business relationships have ended?

I understand why estimates are important but they’re so damn inaccurate!

One of the many critiques of estimates is that they’re often wrong, so what good are they? I completely understand this frustration. But over the years I’ve encountered five techniques to make estimates more accurate and useful.

Technique 1: Break Up Your Tasks

It’s a reality that humans can only hold a handful of variables in their head at any one time. This makes estimating large tasks extremely challenging.

The easiest thing you can do to improve your estimates is to break up complex tasks into smaller pieces.

Technique 2: Padding Estimates

The vast majority of people I’ve worked with have been overly optimistic when doing project estimates. Even if that person had an overall pessimistic outlook on life, it strangely did not carry over to project estimates.

It’s possible that we all have an inflated view of our own abilities but my guess is that the real reason is less hubristic:

It’s impossible to estimate the time it will take to solve problems that you have no idea will arise.

And a huge percentage of the time, unforeseen problems do arise. This isn’t a failure in ability. It happens to even the most skilled people. And the fewer number of times you’ve previously tackled the task in question, the more likely it is for unexpected problems to arise.

Even though my friend with the projector had used it to play a movie dozens of times at home, simply by changing the projector’s setting, it set off a cascade of difficult to predict problems.

And there was no way to estimate those problems before they arose.

So how do we deal with this problem?

One simple improvement is to pad your estimates.

Padding simply means that after you draw up your estimate, add some additional time to whatever number you came up with.

How much time should you add?

The amount you should add is proportional to how many times you’ve done the task you’re estimating before and how familiar you are with the technologies and people involved. The less familiar you are, the more you should pad it.

For example, I’ve washed the dishes thousands of times. I’ve got a pretty good idea of how long it takes based on the number of dishes that need to be washed. Every once in awhile a dish breaks or there is some unearthly grease that takes extra scrubbing time, but neither of those problems take a large amount of time to remedy. It’s safe to only pad that estimate a small amount, perhaps just 5%.

But if I’m building a website with an entirely new tech stack for a client I’ve never worked with before, I’ll probably double or even triple my original estimate.

Technique 3: Estimation Ranges

Another common problem is the fallout when an estimate isn’t hit right on the nose. For example, I’ve seen people give an estimate of 67.5 hours for a software feature. 67.5 hours??? That’s pretty damn specific.

I’d be willing to bet good money that the actual time spent will be above or below that. It’s basically impossible to be that specific with any kind of estimate, let alone something as complicated as software.

A better technique is to use a time range in order to give everyone involved a more accurate sense of the time a task will take. Giving a range like 60 - 75 hours is far more accurate and allows collaborators to properly weigh the best and worst case scenarios to decide if a project is worth it.

You will also build far more trust with everyone else working on a project because you won’t constantly be missing your impossibly tiny estimate targets.

Technique 4: Weighted Estimate Ranges

Ranges are a big step forward but they still don’t tell the whole story. In the previous example, the 60-75 hours estimate was an improvement over 67.5 hours. But in actuality, sometimes things go drastically wrong and something takes much more time than anticipated.

When this occurs I call that a Landmine. You make a false move or uncover an unknown issue with wide ranging consequences. When you’re moving over familiar territory, the landmine quotient is often pretty low. When moving through unknown territory, it’s more likely that you’ll hit a landmine.

So the actual estimate is more like 60-120 hours. However that range is pretty wide and in-accurately portrays the situation because 67 hours if far more likely than 120.

In order to solve that problem, you can use weighted estimate ranges.

In our example, the territory we’re moving over is reasonably well known. So our weighted estimate range will look like this:

• 60 - 70 hours: 50%
• 70 - 90 hours: 40%
• 90 - 110 hours: 5%
• 110-120 hours: 5%

A weighted estimate range gives everybody in the project a much more accurate look in order to weigh the pros and cons of proceeding with the project. If you’re not able to stomach the worst case scenario, perhaps it’s time to re-consider the scope of the project. Or if you’re going to take the gamble, at least everybody knows up front and has confronted the fact that this is indeed a gamble, drastically reducing finger pointing down the line.

Weighted estimates take longer to understand and they involve more complexity, especially for larger projects. You’ll want to weigh these drawbacks when considering utilizing this technique.

Technique 5: Points Style Estimates

I first learned about points style estimates through the software estimation and tracking tool Pivotal Tracker. The main premise behind points style estimates is that actual hour based estimates are impossible. And to make matters worse, people end up spending a lot of time and heartache trying to hone estimates that are likely to be incorrect anyway.

Points style estimation tries to solve this problem by abstracting away units of time and instead utilizes a points system. So instead of estimating a task as 5 hours, I would estimate it as 2 points.

Now where did I get the number 2 from?

Fair question.

As we already know, estimation accuracy can be difficult to achieve, especially for volatile and large-scope projects. Rather than spending a ton of time every week doing hourly estimates, we take a look at each task that needs to be done and rate it on a complexity scale.

The complexity scale is an abstraction so you can use one that works for you, but I’m partial to the fibonacci scale (0,1,2,3,5,8,13). 0 points would be something I can do extremely quickly without batting an eyelash. 1 point is quick and easy. 5 points is fairly complex.

Anything higher than 5 points is going to be quite an undertaking. Following technique #1, I usually try to breaks tasks larger than a 5 down into smaller pieces.

But how do you know how long each task is going to take?

Each week, your team will accomplish a certain number of points. The average of all the previous weeks totals will be your velocity or the average number of points per week that your team finishes. From there it is possible to get a fairly good idea of how much you’ll get done each week. Your volatility will be the average margin of error you stray for your usual velocity. Pivotal Tracker calculates all of this for you automatically.

What this does is effectively makes it almost impossible to be bad at estimating because as long as you are consistent, your estimates are based on past progress rather than individual future time estimates.

If you’re working on a complex long term project, points based estimation can be a worthwhile technique to consider.

Conclusion

There you have it folks. A few techniques to help improve your estimates.

Do you have any techniques that you use? Any questions about mine? Any hilarious or insightful estimation failure stories? I’d love to hear about them in the comments.

If you liked this post and want future web business and product development content delivered free to your inbox, sign up for updates.