Abstract
The purpose of this paper is to present a framework to reduce bias in the design and evaluation of hydraulic fractures. When we mention "bias", we are referring to human nature. If someone knows what the answer is supposed to be (what someone else wants, or to provide a consensus), they are much more likely to provide that answer - even if it is not correct. In addition to frac design (and re-design after pre-frac tests), this process will be extended to the process of post-frac evaluation and the analysis of the frac flowback and other well tests. The process consists of three parts, to be done in isolation from each other. The first is the actual frac design. This includes the gathering of the geo-physical and reservoir property information, the creation of the geo-mechanical model, the selection of equipment, and the execution design to meet the operator's objectives. It also includes any re-design required based on DFIT/minifrac analysis, performed prior to the frac. The second part is the review of the fracture operation, often called the Frac Replay. This is where the actual field data (rates, pressures, concentrations, etc.) and geo-mechanical model are used to simulate the pad and proppant placement and concentration in the fractured interval. The final part is analysis of the frac flowback, as well as any subsequent well tests. If designed and executed properly, the flowback/well test data can provide an independent validation of the effective fracture length, fracture efficiency and drainage radius/volume.
The reason for performing these three parts in isolation is that it utilizes service companies, consultants and in-house experts to the operator's advantage. If they are not performed independently, the answers are highly susceptible to a forced consensus, especially if the party doing the design or performing the frac job wants to demonstrate the effectiveness of their work. If the results of all three independent parts point to the same conclusions, the operator has more confidence in the outcome. If not, the differences can be examined, with an eye to improving future designs and executions.
