Estimating project timelines is a skill everyone should practice. Part science, part art, part domain expertise, producing accurate timelines is essential for determining the opportunity costs associated with any endeavor. From a career perspective, this can be the difference between generating profitable and unprofitable work. As Patrick McKenzie writes in his frequently shared article “Don’t Call Yourself A Programmer, And Other Career Advice”: You really want to be attached to Profit Centers because it will bring you higher wages, more respect, and greater opportunities for everything of value to you. If you accept Mr. McKenzie’s premise, letting your project go into the red due to bad time estimates would be counterproductive to your career aspirations.
Given the importance of accurate time estimates for managers and managed alike, I’ve written down a few of the lessons I keep in mind when performing an estimate for my own projects. This won’t be comprehensive, or informed by anything beside personal experience and general reading. Your mileage may vary.
- Every six-hour task takes eight hours.
If the task is self-contained and takes less than a day, round the estimate up to a full day. First, most workers aren’t going to be productive for eight hours straight. Second, small tasks are psychologically different from multi-day tasks. If the worker knows they can finish the task by the end of the day, they are more likely to prioritize other activities that delay completion: addressing outstanding issues, taking a breather, reconnecting with coworkers, etc.
- Expect that you forgot something.
No one has perfect foresight. Someone is going to forget about, or otherwise not anticipate, a project dependency somewhere in the planning phase. Mitigation depends on bringing in multiple people/teams, identifying the core requirements, and planning backwards from the final deliverable to the kick-off.
- Plan for curve balls.
Some unexpected event is going to happen at some point. Data will be lost, an employee will quit, the client will disappear for weeks. The longer the project, the more curve balls will be thrown. Budget for mistakes or set-backs. Not doing so is the same as saying that everything will go 100% according to plan.
- Know the personalities of the people providing input.
One of my former managers said that he doubled the estimates he was given and then added an order of magnitude. In his experience managing overly confident twenty-somethings, a “one week” job often took two months to fully complete. Nevertheless, his rule of thumb was circumstantial. Estimates from Type-A twenty-somethings should be weighted differently than estimates from fifty-something career veterans.
- Calibrate your estimates.
Perform an estimate for work that has been done by yourself or your organization, and then compare that estimate to the actual time spent. If that option isn’t available, ask for additional estimates from coworkers that you trust (ideally more than you trust yourself). In either case, explain the delta and learn from it.
- Start with what you know.
Some tasks are going to be more familiar than others and will therefore be easier to estimate. Tackle those first, and use those estimates to anchor subsequent estimates. If you have experience coding a website, but no experience promoting a website, you might assume the former takes twice as much time as the latter and derive a ballpark estimate from that assumption.
- Review the data.
Once you have the data, go back and review your estimates. Learn from what you did right and what you did wrong. Edge cases to check for: Were your right estimates lucky guesses? Were your wrong estimates reasonable? Learning the wrong lessons from the results is detrimental. Learning the right lessons makes you even more successful at what you do.
- Better Project Management Through Beta Distribution: A formulaic approach to time estimation.
- Planning Fallacy: Our innate bias for overconfidence.
- Daniel Kahneman: Beware the ‘inside view’: Countering the planning fallacy with a perspective shift.