Project delays and Extremistan

As a follow-up to the post on project bottlenecks, I had forgotten about this quote from Taleb's The Black Swan:

With human projects and ventures we have another story. These are often scalable, as I said in Chapter 3. With scalable variables, the ones from Extremistan, you will witness the exact opposite effect. Let's say a project is expected to terminate in 79 days, the same expectation in days as the newborn female has in years. On the 79th day, if the project is not finished, it will be expected to take another 25 days to complete. But on the 90th day, if the project is still not completed, it should have about 58 days to go. On the 100th, it should have 89 days to go. On the 119th, it should have an extra 149 days. On day 600, if the project is not done, you will be expected to need an extra 1,590 days. As you see, the longer you wait, the longer you will be expected to wait.

In the context of the staged process I described, I can definitely see this happening. As each stage misses its cut-off date, the latencies keep building up. The way Bayes rule works, the earlier probabilities get discounted as you reach a new milestone, and the weight of the future fat-tail data factors more prominently in the new estimate.

Since the same dispersion math figures into reserve growth and oil creaming curves, one can see how the rule of diminishing returns on long-term payouts plays into resource depletion as well. Once a reservoir reaches a certain level of depletion and the creaming curve starts flattening out, the estimated time to reach that same level of relative depletion will keep growing. The operator has no choice and makes a decision to shut-in the reservoir at that point. Again, since project scheduling and oil reservoir estimates possess the same level of uncertainties in early projections, it makes sense that no one really understands exactly how long these operations will take to play out. Thus, you see businesses take a "wait and see" attitude on when to shut down.

As expected business schools have actively researched the scheduling problem. This paper by Francesca Gino and Gary Pisano, "Toward a Theory of Behavioral Operations", describes most of the issues that crop up. They start with what I referred to as the 80/20 rule (they call it the "90% syndrome"). Helpfully, they do make the larger point of discussing the essential uncertainty in the process (why I rely on the Maximum Entropy Principle).

Why do product development projects always run late?
The first anomaly has to do with product development project performance. One of the most vexing management problems in product development is the tendency for projects to run late and over-budget. For instance, Ford and Sterman (2003a, 2003b) use the term “90% syndrome” to describe “a common concurrent development problem in which a project reaches about 90% completion according to the original schedule but then stalls, finally finishing about twice [the time] the original project duration has elapsed” (Ford and Sterman 2003b, p. 212). The phenomena has been documented in numerous case studies and examples (e.g. Cohen, Eliashberg and Ho, 1996) and widely discussed in the product development literature (e.g. Wheelwright and Clark, 1992).

Several studies in the OM literature have investigated the issue of improving timeliness and predictability in product development. Many prescriptions and formulas have been offered (see, for instance, Crawford, 1992; Gold, 1987). Most of this work has explained lateness in product development with the uncertainty inherent in development processes. At any of the stages of R&D, indeed, product development managers are asked to evaluate the available information about currently-under-development products and based on such information make decisions about whether or not to continue development. As many case studies have shown (e.g., Gino and Pisano, 2006a; 2006b), product development decisions are made under uncertainty, they are far from perfect and are affected by behavioral factors (such as sunk costs, escalation of commitment or even emotions).

To deal with uncertainty, OM scholars have developed tools and suggested approaches to better manage product development. These suggestions include the use of experimentation to resolve uncertainty early in the development process (e.g., Thomke, 2003), the use of parallel versus sequential sequencing of product development tasks (e.g., Loch, Terwiesch and Thomke, 2001), the use of cross functional or heavy-weight teams (Clark and Fujimoto, 1991) or the utilization of standardized project management tools like 3-point estimation techniques. In sum, OM research has tackled the lateness problem in product development by suggesting better tools, processes or organizational structures.

One of the puzzles behind the lateness problem, which should make one suspect of the uncertainty explanation, is that project duration is not symmetrically distributed. If true uncertainty were at work, then in fact, we would expect to see (and hear about) projects which were both late and early. The asymmetric nature of duration suggests other factors may be at work. Furthermore, case study research suggests that behavioral factors may underpin the lateness problem (see e.g. Gino and Pisano 2006a, Pisano et al 2005) Extant behavioral literature provides a rich trove of possible underlying explanations for project lateness, including the planning fallacy (e.g., Buehler, Griffin, and Ross, 1994; 2002), wishful thinking (e.g., Babad, 1987; Babad and Katz, 1991), and overconfidence bias (Einhorn and Hogarth, 1978; Fischhoff, Slovic and Lichtenstein, 1977; Oskamp, 1962; 1965).

Good points in mentioning the role of concurrency in reducing bottlenecks, but amazingly they see asymmetry and attribute that to something other than uncertainty. They evidently don't do math and thus haven't discovered the maximum entropy principle on productivity rates, and ultimately rely on their wrong intuition.