Why the Scientific Method Does Not Apply to Reservoir Engineering

The scientific method isolates a single variable and tests it repeatedly until the pattern of behavior is known, and the western world has built modern civilization by deconstructing and understanding the natural world in such a way. Engineering has followed along and applied the quantitative, if minute, individual insights into simple then progressively more complex systems. Indeed, most fields of engineering conduct the design process by starting with a blank sheet of paper and proceed to construct plans. And, in many cases, the design can be prototyped, tested and refined in a trial and error process resembling that of science.

Reservoir engineering is, however, more like reverse engineering. Nature had the blank piece of paper, and she constructed the reservoir according to her own caprices. Unfortunately for us, she then concealed her work under cubic miles of rock. The first job of the reservoir engineer is not to design but to decipher.

Like a cinematic treasure hunt or Sudoku, we must use partial, isolated data points to interpolate a picture of the whole. When we do think we understand and finally get to plan how we will manipulate the system for maximum recovery (read "development plan"), we can only implement it once.

Drilling wells is frightfully expensive; we can't exactly ask for a do-over. We might be able, at a substantial cost, to sidetrack and redrill a wellbore, but we can never recall a hydraulic fracture treatment and replace it with a better model. We can't reset the reservoir to virgin conditions and try the waterflood a second time.

If we plan to drill a number of shale wells, then it is tempting to think that we can use the drilling program as a laboratory for experimentation. One technical paper from a decade ago argued, in a manner I've seen a number of times since, that X was proved to be better because the two wells using that method performed 20% better than the two "control" wells. If the world of reservoir engineering had as few variables as a laboratory, then the empirical trial-and-error might be more practical. As it is, the natural variation of shale well results swallows whole any 20% improvement when the well count is low. It is normal for the best decile of wells in an area to recover five times what the bottom decile captures, all else being approximately equal. So proving an advantage requires large datasets across which natural variation can be averaged.

Some excellent work has been done in this way, in the rear-view mirror with really large data set. It is just that the dataset costs billions of dollars and requires years to create. By the time the "laboratory" experiments are complete, the lessons are most useful for the next play since the subject play is substantially developed.

Before an office tower is built (and it obviously can only be built once and thus shares a similar constraint), extensive analysis and modeling precedes construction. By contrast to a $100 million office building, our industry may spend $100 million drilling 10 or 15 shale wells designed by close-logy or guesswork. Worse, the company may short-sheet data gathering and outright refuse the engineer who wants to spend $50,000 on modeling. I shudder at the thought of riding an elevator in an office building constructed with as little engineering as in a typical shale development.

Some money can be made by taking action, for sure, in the development phase. The most money in this phase can be made by taking optimized action. (And I use that term loosely in the context of the uncertainty common to our problems.) The beauty of modeling, whether of frac design or of reservoir production or of exploration strategy, is that it allows actions to be taken, tested and retried multiple times in the virtual world before the single-shot action is taken in the real world.

The raw material of analysis is data and time, and those may feel like costly luxuries or even risky detours. But by comparison to the magnitude of the capital being deployed and to the risks of losing out by poor design. . .

Please argue with me in the comments below. Or else follow my musings.