Major Decisions May Not Matter That Much

Decision making is a critically important part of engineering. In this article, the author argues that the day-to-day project execution decisions are more important than major project decisions and deserve more attention.

ogf-2016-06-culturehero.jpg
Getty Images

Decision making is a critically important part of engineering. A great deal of structured work goes into making the major project decisions such as the concept selection. Comparatively very little structured decision making is used when making the everyday decisions on projects.      Despite the provocative title, I am not arguing that the major project decisions are unimportant and do not deserve a great deal of scrutiny. I am arguing, however, that the day-to-day project execution decisions are more important and deserve more attention.

Limits to Making the Early Decisions

Early major decisions can be hard to make because the options spread is often not that great. Indeed, that is a fundamental property of hard decisions. If one option is clearly superior, then the decision is easy. When there is not much difference between options the decision is harder, but unimportant.

The main reason why I think the early major decisions are not all that important is they are made at moments of very large uncertainty. The important criteria upon which the early decisions depend are recoverable reserves, capital costs, and schedule, but we do not know much about any of these criteria during the concept select phase. Actual recoverable reserves for a typical large project are between 60% and 80% of the predicted totals at project sanction. The capital cost overrun averages 33%. The schedule overrun averages 20% of schedule, approximately 9 months. So decisions made on the basis of recoverable reserves, estimated cost, and planned schedule are bound to be nonoptimal for the majority of projects.

Problems With Schedules

Consider the problem of schedule overrun. There are two possible reasons: poor estimates and poor execution. If poor execution is the main cause, and I suspect that is usually the case, then clearly the day-to-day decisions made during project execution are more important than the major early decisions.

If optimistic scheduling is the problem, then we can either put a lot more work into honing the early estimates, or accept the uncertainty and make a decision that minimizes risk.

Putting a Lot of Work in Upfront

How much upfront work can we justify for making the major concept selection decisions? Can any amount of work at this phase narrow the uncertainty enough to make a difference? Given the average errors at project sanction, I would say no. No amount of work is likely to narrow the error bands enough to make more effective decisions. The causes of these large errors are resistant to mitigation.

Optimistic Scheduling

One of the reasons we have schedule overruns is optimistic scheduling. There are many reasons for this as discussed below and these reasons will resist mitigation.

  1. Sensemaking and the planning fallacy. History is much more complicated that the history books suggest. We make sense of history by simplifying it. We tend to view the past as much simpler and more deterministic than it really was. When an event occurs, we may read past actions as leading inevitably to that result even if it would have been difficult to make those predictions before the fact. We make the same errors in predicting the future. Our vision of the future is simpler than the future really will be. The actions we take will not lead inevitably to our desired result. The future may unfold in countless different ways that could impact the project. When we make sense of the future in this way, we naturally view our tasks as simpler to accomplish than they really are. Plan-based scheduling is biased toward assuming success at each step. But it is not realistic to think that everything will go as planned. A problem with accounting for inevitable failures in our plans is that we cannot predict a priori which plans will fail or take longer than scheduled.
  2. Management pressure. Management is very interested in the project schedule and will often exert pressure on the design team to propose an optimistic schedule. As a result, the design team is often saddled with a schedule that it does not think it can meet. This can be very demoralizing, causing poor project execution.
  3. Early enthusiasm. Early plans tend to be ambitions because they are generated early in the project when enthusiasm is high.
  4. In-group favoritism. We are biased in our belief that we are better than others; better than other teams, better than other companies. It is common for anyone who belongs to a team to think that his or her team is better than other teams. Even when others have failed, it is not hard to believe that we can perform projects faster than they can.
  5. Complex design and complex organizations. Multiple teams and multiple contractors are involved in most project organizations. Each team has to finish on time in order for the project to finish on time. The more teams there are, the more likely it is that at least one will finish late. The more interfaces there are between systems and teams, the more likely it is that schedule slippage in one area will cascade to cause slippage in other areas of the project.

The Problem with Estimating

Similar arguments could be made for poor reserves estimation and poor cost estimation. Investment decisions must be made when there are large uncertainties in the three main success criteria and when significant cognitive biases drive us to optimistic answers.

Optimistic estimates in all these areas lead us to build things that are larger and more expensive than optimal and more complex than necessary.

The Solution: Keep It Simple Stupid

The obvious answer to this dilemma is to drive the industry to simpler solutions, and we can accomplish this through a number of actions. Build small, or smaller than you think you need. Build simply, or simpler than you are used to. Build quickly by designing smaller, simpler facilities. If possible, copy something that has already been built. Maybe build something reusable, or reuse something that already exists.


duhon-howard.jpg
Howard Duhon is the systems engineering manager at GATE and the SPE technical director of Projects, Facilities, and Construction. He is a member of the Editorial Board of Oil and Gas Facilities. He may be reached at hduhon@gateinc.com.