Hofstadter's Law or The Planning Fallacy

Hofstadter's Law claims that "It always takes longer than you expect, even when you take into account Hofstadter's Law." Similarly, the Planning Fallacy refers to the tendency to underestimate completion times for complex and inter-related tasks. In my experience, the problem is not so much the underestimation of discrete tasks, but the underestimation of all other related tasks and events. For example, a project manager may accurately estimate the time required for a designer to complete 3 screen designs and the time required for a developer to implement those new screens; however, he will grossly underestimate the time and effort required for more "administrative" tasks like financial / justification analysis, project funding, time tracking, documentation, questioning of designs and assumptions by stakeholders, testing, user acceptance, rollout to production, sign-off and post-production project close-out activities.

In their paper "If you don't want to be late, enumerate," social psychologists Justin Kruger and Matt Evans concluded through various experiments that most underestimation occurs when individuals focus exclusively on core tasks and ignore related tasks. For example, in estimating time required to prepare a meal, cooking time is accurately estimated, but time to prepare ingredients, preheat the stove and set the table were not properly accounted for. They found much better results when study participants were asked to "unpack" multifaceted tasks - what we might call completing a thorough work breakdown structure.

I have an rule of thumb for creating initial, lightweight project SWAGs (Scientific Wild Ass Guesses) that has worked well for me over the past several years. I call it the "Work Times Three" approach:
1. Make an initial estimate of the core work and time involved in a project - requirements gathering, design, development, testing.
2. Multiply that by three.
3. The result is an close aproximation to actual time-to-completion, starting at project approval, that can be used for early decision-making.

I've used a factor of three successfully in the past, but anything from 2 to 4 can be good multipliers based on your organization and project. The multiplier you use should be based on the following risk factors:
a) More project complexity (number of discrete requirements and specs) = higher multiplier.
b) More uncertainty (requirements, specs, available resources) = higher multiplier.
c) More personnel means more communication and administrative overhead = higher multiplier.
d) More functional groups (IT, marketing, etc) = higher multiplier.
e) More organizations (contractors, vendors, partnerships, etc) = higher multiplier.
f) Less familiarity with project type, technology or processes = higher multiplier.

So, if I assume that the core labor required for a project is approximately 4 weeks, but that 3 internal functional groups and a new vendor with new software will be required, my initial SWAG may be 4x3 = 3 months from the initial "OK to proceed" to completion.

Of course, at some point you have to do a detailed bottom-up estimation or plan. The trick again is to sufficiently account for non-core tasks (documentation, approvals, testing, holidays and vacations, customer rollout, etc), and to sufficiently account for lag-time between tasks.