Which Came First: The Time Estimate or the Time-Suck? Forecasting the amount of time to allow for a project can be an exercise in futility.
By Jeffrey Fermin Edited by Dan Bova
Opinions expressed by BIZ Experiences contributors are their own.
What's the first thing you do when you start work on a project? Some version of "create a time estimate" probably is high on your kickoff list, but that might not be necessary. In fact, it might actually set you back on a project.
People don't like hearing that estimates often are a waste of time. Unfortunately, these projections typically suffer from three major shortcomings.
- Time. It takes a lot of time to create an estimate, and it usually means hauling senior staff and team leads into snooze-inducing planning meetings. Afterward, you'll still need to verify the results with other leaders.
- Rework. You'll need to redo your estimates if the project specs change after work begins. If we're honest, that happens in most scenarios.
- Negligible value. Estimates often don't add enough value to make the time and effort worth it. You'd be better off building new features, squashing bugs or investing in any number of activities with a higher ROI.
Related: The 80/20 Rule of Time Management: Stop Wasting Your Time
Why are we so bad at time estimates?
Inaccuracy is an obvious flaw in time estimates. Even the most seasoned project manager has watched a detailed estimate go off the rails. The good news: It's not your fault. Our brains are stacked against us.
- Flow state. When we're fully engaged in work, we enter flow state. It's the ideal state for team members to work together, but it messes with our perception of time. It makes us think a task took only an hour when it might haven taken three.
- Switching costs. Time estimates often don't take switching costs into account. This is the gap between Task A and Task B, when we're not immersed in either task. Switching costs climb higher when we try to multitask.
- Planning fallacy. There's even a psychological phenomenon that describes how bad we are at estimating the amount of time to allow for tasks. The planning fallacy persists, convincing us we can accomplish more in a shorter span -- even if we have previous time logs from a similar project.
Our grasp on time is slippery at best, and our memories are very fallible. Yet we have no other framework than to create future projections based on memories of the past. It's no wonder time estimates almost always come up short. In actuality, the bigger wonder is that they're ever accurate at all!
Related: 3 Road-Mapping Sins That Could Kill Your Next Product
Sometimes they're a necessary evil.
As you may have gathered, I'm not a fan of estimates in general. But they can be useful at a high level in certain situations. If your company lands a seven-figure contract with a six-week timeline, you need to figure out how to make that schedule workable. Creating estimates necessarily will be part of the process.
Here's where we see one often-overlooked skill for senior team members: the ability to assess all the resources at hand and then create a list of everything needed -- time, tasks and people -- to get the job done before deadline. As you build your team, look for people who possess that skill or who can grow to learn it. This aptitude serve you well, further down the road.
Related: The Art of Timeliness: 5 Tips to Help BIZ Experiencess Meet Deadlines
Making time estimates work for you.
Once you're past the high-level estimate, there's little value in getting any more nitty-gritty. You can try to create point-based or time-based estimates that get more specific, of course.
The problem? As soon as you share those estimates across departments, everyone starts creating time estimates and plans based on your timeline. Then you run into a hitch, and three other teams stand around tapping their feet. Because they built launch plans around your initial timeframe, they thought the product would be marketable two weeks ago.
I've been a part of the product-development process for several teams, and the experience has led me to believe that date-based planning is just a bad idea. You end up cutting features or scope, rushing things out the door or shipping subpar software.
If you absolutely must create an estimate -- whether for a time-based project for your investors -- your best option is to multiply your estimate by 1.5 or even 2, if you want to be extra-generous. Building in that much slack helps negate the fact that it's almost impossible to know a project's entire scope at the outset. Even if you have 99 percent of the information, the amount of extra effort it takes to get that last 1 percent is disproportionate compared with what you'll gain.
Any truly great product manager or leader should be more concerned with quality than they are with arbitrary deadlines. As you've probably deduced by now, our teams don't use estimates. If there's no escaping this unpleasant task, just make sure you approach it from the right mindset and understand what you're getting into.
