How I learned to love project estimates

This story was originally told on stage at Enterprise UX 2018. Watch the video here.

Do you love estimating projects? Or, does the thought of producing an estimate make you nervous and cranky? After all, estimating is usually a tedious chore, but with consequences! I used to be just like that, but today I’m going to share the secrets of stress-free estimating with you.

Let me tell you about the largest estimate I’ve ever been a part of. I was working for one of the largest media and entertainment company in the world, on the biggest, coolest project of my career. In order to secure funding we had to produce an estimate, and the policy from our PMO was that all of our estimates had to be 80% accurate.

Now, as you know, the best predictor of today’s weather, is yesterday’s weather. Similarly, the very best and most accurate method of estimating is to base your estimate on a previous project. But let’s face it, in our business, with changing technology and business climates, that situation is very rare.

The second best method is enumeration, which is a synonym for tedium. Based on the ambitious vision, we worked for three months to define features, which we divided into seven of what I called “Mythic Cycles.” A Mythic Cycle is like an epic, but epicer.

We developed a complicated spreadsheet that listed all of the screens we imagined we might need, and did process estimates like how much time it would take to get approval from the terrifying but brilliant creative director — all of which took our team of 6 more than 3 months to complete.

Our first estimate to build the veritable fairy castle of an experience was for 60 million dollars. The reaction from the executive team was swift and illuminating: to put it mildly, there was a general lack of faith in our number. It seemed like most of our leaders harbored two assumptions: 1) someone had a magically correct way to do such an estimate, and 2) they were pretty sure their slow and boring internal team didn’t know the right incantation.

So in order to feel more comfortable with the numbers — and to be fair, they were all going to be signing off on a huge capital expenditure — leadership decided to validate our estimate by inviting three vendor-partners to create their own estimates based on our discovery work.

Six weeks and almost 800k later, our partners (we’ll call them Grog Design, Gapient, and Gaccenture) produced estimates of 45 million, 72 million, and “at least 90 million” (the third vendor told us they didn’t believe we had done enough discovery). Ironically, the more the partners had worked with us in the past, the larger their estimate was.

And then something funny happened. One day, we ran an exercise with an agile coach that changed my life. Using the planning poker method with fibonacci numbers for scale, we ranked the seven Mythic Cycles in terms of effort.

We decided that the “Product Finder,” a feature that would allow guests to quickly and easily find whatever they were looking for on the property was the most well-understood problem. Since it was the smallest, we made it the baseline and gave it the point value ONE. In comparison, another Mythic Cycle, “Maps,” which entailed building a detailed and accurate 3D rendition of about 47 square miles of central Florida, we decided was roughly 10 times as much effort as building the Product Finder, so it was roughly a 10 and so on until we had guessed at the relative sizes of all seven Myths.

Now that we had a total number of “points” for the system, we had to build a bridge from the abstract units of points to a more concrete unit, you know, time or money?

We thought about projects we’d done in the previous year that were comparable to the Product Finder. We settled on a successful project that had cost one million dollars. At this point the estimate becomes simple arithmetic. Substituting one point for one million dollars of effort, we came up with an estimate of 70 million.

And we did it in less than an hour.

I promised I’d tell you the secret to loving project estimates. I lied. But what I can offer you is three tips that can help make estimating bearable:

1. Asking how accurate an estimate is or should be is the wrong question! The right question is how much effort should you put into generating an estimate in the first place? Estimates are tools for managing risk — so figure out what the riskiest part is and work hard on that part of the estimate, or better yet, figure out something you can do or make to reduce the risk and do that!
2. Eisenhower once said, “plans are useless, but planning is indispensable.” Mike Tyson put it more colorfully: “everyone has a plan until they punched in the mouth.” The estimate you made six months ago should be pretty different than the one you would make today, because you know a lot more!
3. And finally, repeat after me: estimates are not commitments. An estimate is not a promise, it’s a guess. The larger the scope and further out the time to complete is, the greater the probability of error. Therefore: the greater the size and complexity of the project, the less stress (commitment) you should feel.

No matter how many times you tell people that wireframes are not about look and feel, some high level stakeholder asks about the fonts or the word choice. Estimates are like that, only worse. Every time you give an estimate, someone is going to think that the estimate is a commitment. The real secret to loving estimates is to never fall for that.

And I don’t think you’ll be surprised to know that the last estimate ended up being the closest to the target. Final cost: 120 million dollars.