How to Estimate Projects Without Being Absolutely Hosed
Employees are often distrustful of their business partners when they're asked to give estimates. Instead, build your communication skills to take advantage of the estimation process benefits.
Welcome to the Scarlet Ink newsletter. I'm Dave Anderson, an ex-Amazon Tech Director and GM. Each week I write a newsletter article on tech industry careers, and specific leadership advice.
“I want to read the requirements more carefully before I give an estimate.”
“We just need something quickly. Anything will do.”
“Ok, but this is just a rough guess until I can think abut it more carefully.”
“That’s great.”
“I’d say 2 weeks.”
“Great. Thanks. Glad to hear our plans are feasible. We need to launch in 2 weeks. Please begin.”
“!#@&$&@^!”
Sound familiar? In any halfway decent sized organization, there is frequently a tension between the need of the business to have estimates, and the fear of individual contributors of being committed to something they can’t achieve.
In this article, I won’t walk through how to estimate your work. That’s far too specific to your line of work, the type of project, your company, etc. Instead, I want to focus on why estimates are important (despite being stressful), how to break down what type of estimate is needed, and how to communicate estimates without getting yourself into trouble.
As a side note, my preferred article title was “How to Estimate Projects Without Being Gazumped” because I just learned the word gazumped, and I really wanted to put it in an article title. But I’m afraid that putting an uncommon word in an article title would decrease my click-through rate, so I’ve unfortunately changed things up a bit.
Welcome to those of you new to Scarlet Ink! Each week I send an article to all subscribers. Free members can read approximately half of each article, while paid members can read the full article.
For some, half of each article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member!
Why are estimates hard?
Many (most?) well paying jobs are creative jobs. You’re paid well because you do inventive, unique work. If you were doing repetitive work, they wouldn’t need to pay you for your big brain.
By definition, by doing a creative job, you’re doing something which hasn’t been done before. Doing something unique and new means that it’s difficult to know how long it will take to complete it. You might have done something similar, but it should be impossible to measure accurately. The more valuable your work (because it’s unique and inventive), the harder it should be to estimate.
There are always going to be aspects of a project which will feel familiar. Imagine you’re a designer, and you need some UI elements for a website. You know (for example) that there is login functionality, and you’ve done login pages before. There are a few forms, and a few different types of content to display.
Great. You haven’t worked on this website, but you’ve done similar things. You can ballpark how much work it will be, but you can’t know with precision. Why is that?
Because the product manager may not like the colors, and will ask for more options to look through. The logo of the new site might be wider than expected, and not fit with the style you’d selected. The color scheme chosen for branding might make the planned gradient look bad.
Similar issues happen with software engineering. You may know the vague outlines of how much work is involved, but there are hundreds of ways that the exact assignment might take longer than expected.
This is true for all types of creative jobs. We are likely to be familiar with the skeleton of the work, but there are larger or smaller ambiguous aspects which may come to bite us later.
Our unexpected stumbles come from three major areas.
Mistaken assumption breaks things. You assumed that the logo size wouldn’t break your design. You assumed you could connect to the database from your servers. Assumptions are made (conscious or unconscious) and those don’t always pan out.
Small changes break big things. The product manager’s request to change the login process to a two-step process triples the cost of building the feature. A designer’s minor change for the menu system requires a complete rebuild of the navigation structure. For whatever reason they come up, small changes can bite us in a big way.
The work is harder than expected. We thought it would be relatively simple to complete a task, but it turns out that it’s not simple. “We’ll just connect the device via Bluetooth. Hmm, that’s odd. Why is Bluetooth not working?”
Considering how hard estimates are to get right, why can’t we avoid them? And I’m saying that because I’ve regularly had engineers / designers / product managers ask if we could please just this once skip estimating our work because there were too many unknowns.
Why are estimates important?
I’ve broken down the importance of estimates into four main categories.
One — Budgeting / prioritization.
The cost of a project is highly tied to the amount of time / work that goes into it. This means that the ROI (return on investment) of a project is directly tied to how long it will take.
That exciting, cute little feature is an absolute steal for 2 days of work, and a horrible waste of time for 2 months of work.
Related, the priority of approved work is frequently directly related to the ROI. You would immediately fix a quirky bug if it took 1 day to fix, but if it takes 2 weeks, you might put it off for a couple of months.
Two — Coordination.
We coordinate to hit important dates, and between other teams.
For example, you are preparing for a big marketing launch. Imagine Steve Jobs standing in front of a crowd delivering his famous iPhone launch speech. Imagine how many hundreds of teams had to estimate and coordinate work before the event to ensure that the full product could be ready by the announcement date.
Similarly, your team is rarely doing work in a vacuum. Teams have integration points, and understanding when those points will occur is critical for coordination purposes. Being able to say, “We’ll have that API ready for you by July 17th.” is an essential ability as organizations and projects grow larger.
Three — Outcome estimation.
Less obvious unless you’re interacting at higher levels in your company, but being able to estimate the timing of outcomes is important for most businesses. Particularly if the thing being built is expected to deliver financial results, knowing when those results will land is critical.
“We expect a 15-20% increase in sign-ups starting July 15th when the X feature launches” is something a financial team may need to report, and those increased signups starting in September could seriously impact corporate finances for the year. Like it or not, companies need to be able to predict their performance as much as possible.
Four — Effective work.
This is the most controversial one. There are people who don’t believe this is effective at all, or even believe it is counterproductive. They’ll say that the pressure from dates lowers the quality of work, and that ends up costing you more in the long run.
Others believe that estimating (and the corresponding date-driven schedule) is absolutely critical to making effective progress at work. The idea is that dates and pressure drive output. They believe if you keep a healthy amount of stress (eustress, which I discuss in this linked article) on people, they will perform better.
I’m personally in the camp which believes that date pressure is certainly uncomfortable, but it’s a healthy part of delivering results. My experience leads me to believe that work tends to expand to fit the available time. A task which could be delivered in 2 days will take 2 weeks if that’s the deadline. And similarly, work which could take 3 weeks can often be done in 1 week if the team is willing to be inventive.
I think dates / estimates help with being effective in two main ways. First, it forces us to knuckle down and deliver. I certainly spend a higher percentage of my time typing an article when it’s due the next day. Second, we cut the “nice to haves” when we have a tight timeline. If we think building the perfect version of a feature will take 6 weeks, you’ll probably get 80% of the benefit if you build a cheaper / faster / slimmer version in 2 weeks. This is also a core element of the invent & simplify leadership principle.