How to improve design and engineering for upstream projects
Upstream capital projects are dynamic and complex endeavors. Their criticality continues to increase, as producers look to meet market demand and carbon reduction commitments, in addition to producing revenue faster through project acceleration. This situation puts significant pressure on project teams, including those that develop engineering, as faster speed is desired without increasing cost and compromising quality standards.
There is a lot at stake for all parties involved, as project criticality and complexity increase. However, many attempt to address the situation by doing more of the same, hoping to achieve better project performance, including engineering. We find, for instance, that across upstream projects, there is an intense focus on project administration, such as reporting and forecasting of engineering progress through specific processes and tools, including home-grown spreadsheets.
But, if the parties look to achieve better performance to get revenue faster and increase competitive advantage, is more of the same enough? Probably not, based on project results. As simple as it sounds, if upstream engineering teams look to achieve better performance, how work is performed must be examined, as more monitoring of what has already happened (after-the-fact approach) is not going to deliver the desired performance. We must shift our attention to how we do engineering work, and how we control what needs to happen—in other words, how we produce. But to explore what the upstream oil and gas industry can do about this, we must first identify common denominators in engineering work. This way, we can get a better appreciation of inherent challenges.
COMMON DENOMINATORS
Based on experience across many projects, we have learned that there is a high probability that the following common denominators will be present in an engineering production system. These should not be taken for granted for your upstream projects, but rather validated. Also, these are not listed in any particular order, and many, if not all, are also applicable to other types of capital projects, not only upstream.
Engineering is performed by resources that are not necessarily co-located, but rather do work from multiple locations (e.g., cities, states, countries working in different time zones). This is in contrast, for example, with offshore installations, where resources are at the point of installation. Multiple locations create additional interfaces to those already expected between engineering disciplines. As units of production (e.g., a deliverable) move through the multi-location production process, build-up of completed or incomplete work occurs at interface points forming queues. The larger the size of the queues, the longer the wait times for the deliverables in the queues, which makes engineering cycle times unnecessarily longer than expected.
Multiple engineering deliverables need to be produced, each by a certain date (not always the same for each deliverable). Depending on project size, hundreds to thousands of deliverables need to be produced within a given time window, some by a single engineering discipline, while others may require the involvement of multiple disciplines, including reviews and approvals by one or more parties. Due to the technical nature of engineering, the completion of a given deliverable may be needed to start or complete others. This intrinsic complexity introduces high levels of variability in the production process, especially arrival variability of work from one operation to another.
As engineers perform multiple types of engineering operations, the frequency of release of work between these operations—including how much work is released at a time (transfer batch size)— becomes a key factor that drives variability levels. To compound this effect, engineering teams experience long review cycles, which are, by themselves, sources of variability, due to rework.
Some engineering deliverables are driven by regulatory requirements (e.g., project must comply with local regulations), others by internal governance (e.g., funding approvals), while others are required for technical purposes (e.g., to start fabrication work). And, of course, not all are 3D models or drawings, but a variety of documentation that goes into procurement, fabrication, installation and commissioning packages.
This implies that engineering deliverables are produced through several production processes, many of which are standard for specific groups of deliverables. Furthermore, and in contrast with fabrication, assembly, installation, and commissioning, characterized by a production process design that is linear (e.g., need to do task A, then B, then C), engineering, especially early stages of design development, is characterized by more iterative production processes under which one decision by a single discipline may affect an existing design already produced or decisions already made by another discipline. This is when process integration and effective management of how work flows and is released between interfaces becomes particularly important.
Engineering teams are typically structured, based on a matrix organization, so technical disciplines (e.g., structural, mechanical, electrical, process engineering) share their capacity across either multiple projects or sub-projects within a single project, Fig. 1. This creates tension between those responsible for managing the projects / sub-projects and those leading each discipline, as limited execution capacity exists within each discipline. One way of seeing this is that project managers fight for capacity, so the work under their direct responsibility is progressed, as planned, versus others. How engineering teams prioritize and allocate shared capacity across deliverables has significant implications on cycle times, because work that is neglected just waits.
It is rare to be involved in engineering work that does not have some sort of master schedule. Even though this is in place, engineers tend to use their “list of deliverables” and associated target dates captured in registers as the reference for their work. Contrary to the common belief, engineers do not typically use master schedules for their work—managers and schedulers do this to track progress against the established baseline.
A single engineer is not linked solely to the completion of a single deliverable, so it is common to see that an engineer knows what he/she needs to do, but this does not always mean that a single engineer understands the end-to-end process to produce a deliverable. The more production processes are multi-disciplined, things get even more interesting, as nobody has a clear picture of the overall production process (the exact “how to”) for a single deliverable.
For years, the industry has developed asset design and engineering in 3D environments, so this has become standard practice. Digital prototyping tools are used to produce the design of the product (asset), visualize its evolution during design and engineering, produce alternative design options to inform decision-making, and ensure there are no clashes between components and systems of the asset, as engineering is developed.
There are probably more common denominators that we could list to make this more comprehensive; however, our main point is that the likelihood of finding an engineering work environment like the one described above is extremely high, no matter where we go. So, one question is: Is this inherent complexity going away anytime soon? Very unlikely. So, now what? What can we do to optimize engineering production within the constraints of an environment like this?
PROJECT PRODUCTION
As discussed earlier, we must shift our attention to how we do engineering work; in other words, how we produce. In oil and gas, many relate the term production to just the production of oil and gas, meaning what occurs, once the project lifecycle is completed. However, there is also project production, and not only that, there are different types of project production, including knowledge and craft work, from design, engineering through to fabrication, assembly, installation, commissioning and decommissioning of assets, as well.
Project production, like many other types of production outside the oil and gas industry, is driven by the science of operations. Because we have project production, there is at least one production system that produces a given output, and, therefore, the behavior of the production system can be understood by application of the science of operations.
In essence, project production systems are configured to deliver or respond to certain demands. Project schedules set demand, based on business / project objectives. So, from a schedule, we can determine that the project production system should be able to produce, for example, 1,200 engineering deliverables in a calendar year, meaning an average demand of 100 deliverables every month. If the project production system is not able to produce the rate of demand, we will experience schedule delays. If the project production system has the capacity to produce more than the demand, there is an opportunity to accelerate or just meet the demand. Contrary to the common belief, schedules are not representations of production systems, but rather set the demand in which the system should respond, Fig. 2.
The science of operations defines, with a high degree of accuracy, how the throughput (a rate) of a system relates to the amount of work being processed and waiting to be processed, known as work-in-process, as well as the time it takes for a unit of production to move through the system, known as cycle time, Fig. 3. Relationships like Little’s Law, the VUT equation, the cycle time formula, are just examples of several robust relationships that define how production systems behave, including those of engineering. If we intend to improve engineering production, we must look at how we produce and what the science of operations tells us.
Food for thought. With a project production framework in mind, the following are some things to consider for how to improve design and engineering for upstream projects.
1. As units of production (e.g., a deliverable) move through multiple engineering production processes, there is an opportunity to better understand how the production process(es) should behave (e.g., what “optimal” is for a given set of conditions / parameters). To achieve this, we can use leading-edge technology to create digital models of engineering production systems complemented with operations science to analyze the behavior.
As engineering production systems are shared-capacity systems, we can understand the effect of shared capacity in throughput and cycle times, identify optimal levels of work-in-process, while clearly identifying where bottlenecks are and even how bottlenecks change position over time (a bottleneck is an operation with the highest capacity utilization—the ratio between demand and capacity). In simple terms, we can strategically target actions for improvement, based on model outputs.
2. Even though we may find ourselves in front of large numbers of deliverables, teams may be blind to the fact that they execute work through a limited number of processes that repeat for many of the deliverables. We will call these “standard processes.” Standardizing work contributes to reducing (not eliminating) variability, hence, reducing cycle times during execution. This idea is complementary to the standardization of products (parts, components, assemblies), which many are already working on.
3. The allocation of capacity to execute work is very dynamic, so a systematic way of controlling work must be in place, including what work and how much of it is released for execution, addressing changes (sources of variability), and rapidly determining what specific resources get assigned to which work within a short period of time. To clarify, when we refer to allocation of capacity, we do not mean creating a manpower histogram using master schedules as in conventional project management practices. We refer to the dynamic allocation of specific engineers to the work, including the ability to plan and re-plan work due to variability.
The examples shown in Figs. 4 and 5 contrast a workflow view of a short-term engineering schedule (across all resources to do that work) and a view that looks at how work gets released for a single resource, exposing gaps where that resource is out of work. Control is key in dynamic environments, so concepts like last responsible moment can be used to drive priorities for the allocation, as well as to avoid creating unnecessary work-in-process (e.g., don’t open or start workstreams you don't need to start).
4. It is useful to look at a different set of performance indicators to understand how engineering production is behaving now and compare it to what it should be. These include throughput, work-in-process, cycle times, capacity utilization, as well as sources of variability. These should complement other indicators like those used in project controls. By doing this, teams can focus on production-based continuous improvement.
If you are responsible for engineering or directly involved in the creation of engineering deliverables for upstream projects, what do you plan to do to improve performance in such a complex environment? We recommend you augment your current practices looking at how you produce engineering including modeling, optimizing, controlling and improving your engineering production systems.
- Dallas Fed: Outlook improves, even as activity little changed; break-even prices increase (April 2024)
- The last barrel (February 2024)
- Oil and gas in the Capitals (February 2024)
- What's new in production (February 2024)
- First oil (February 2024)
- E&P outside the U.S. maintains a disciplined pace (February 2024)
