Mick Fischer is the Project Manager for building a new research center at a university. To meet donor requirements, it is critical the project be completed in 24 months. However, the latest project schedule states it will take 28 months. In response, Mick schedules a meeting with the architecture, engineering and construction management teams to identify ways to compress the project duration. Several ideas are put forth, including significantly overlapping engineering and site work (to fast track the project), very early purchase of long lead items, paying overtime, offsite fabrication and even using workface planning to ensure high labor productivity.

Excited that these measures could compress the project duration, Mick heads back to his leadership with a proposal to use a fast-track project delivery strategy. He gets their full support and expectations are high that the project will be completed in no more than 24 months. University leaders are happy to hear the news and begin preparations to outfit and occupy the center based on that shorter timeframe. Mick knows that handoffs between all the parties involved are critical – architectural to engineering, engineering to construction, and construction to the university as the end user, so he establishes clear deadlines and an accountable person for each portion of the work. Profit is tied both to meeting individual deadlines and to meeting the overall 24-month delivery target.

Each accountable leader then established what they expected to have before starting their portion of the work. The engineering lead required complete architectural deliverables to optimize the sequence of the engineering disciplines with minimal recycle. Very early procurement of long lead items meant designing the center around what was procured instead of procuring what was developed through the design process. Construction required complete drawings and specifications for each craft (subcontracted) before starting any site work, which began with site preparation and foundations. The university required every floor to be fully completed before they would begin the acceptance process in order to optimize their own and limited internal resources.

Having figured out a way forward, the project is launched with great optimism and high expectations.

As the work unfolds, reality begins to sink in. Some of the architectural work got hung up with the university staff review and started to fall behind. The handoff deadline between architectural and engineering passes, and in spite of Mick’s demands, engineering refuses to start work with what was available, thinking that will limit their ability to work efficiently. Consequently, Mick adjusts the engineering and construction handoff deadlines to share the pain, while the project completion date is held firm.

Engineering placed early orders for long lead items with delivery at the earliest possible date and based on suppliers’ capacity. Foundation design could not be started until the structural work was complete. Site prep design could not be done until the foundation work was completed. Unfortunately, structural got hung up in the building permit review process, which pushed engineering further behind. Mick authorized overtime for the engineers to try to preserve the site prep and foundation handover dates, but they too were missed.

Some of the early ordered equipment just could not be made to work and it was more cost effective to reorder. However, that generated delays in construction. Other long lead items did arrive as promised, but had to be stored in a climate controlled warehouse for months at additional cost and was handled multiple times.

The foundation subcontractor started work at site after receipt of all drawings issued for construction so they could work efficiently and minimize their schedule timeline. Rebar was ordered first at an excellent price, but unfortunately, cut and bent rebar and rebar assemblies were fabricated in a different sequence than was needed at site since that was more efficient for the fabricator. That in turn delayed the foundation schedule. You know how the rest of this story played out. Needless to say, while the individual chunks of work were done efficiently, when they were all strung together, the schedule took something more like 36 months instead of the promised 24.

Stories like this are very common in the engineering and construction industry and apply to a variety of projects, not just buildings. As this story highlights, the delivery of engineering and construction projects around the globe is plagued with decisions about how work is processed and transferred from one party to another, from one person to another, between operations and even from one location to another.

These decisions are made daily, consciously, and sometimes even unconsciously. Human nature drives the desire to have everything needed before starting work to have control and ensure efficiency of the work. There is a specific term for this chunking of the work – “batching” – same principle as in concrete batching, as many are familiar with – but as a concept and practice, batching is well understood in other industries such as manufacturing, but unrecognized by many involved in the delivery of engineering and construction projects when it relates to work execution. Batching decisions are found throughout the project delivery process. For example, this occurs between engineering disciplines, during the planning and execution of fabrication, assembly, transportation, installation, completion of systems, commissioning, and start-up work. For many applying practices such as Advanced Work Packaging (AWP) and Workface Planning (WFP), chunking work into packages defines the type and size of the batch of work to be engineered and then executed. When purchase orders are issued with no agreement regarding sequence and throughput, someone will end up defining batches based on some criteria (typically to optimize what they are accountable for).

For the most part, processing and transferring work in projects occurs without a clear understanding of what a batch is or the unintended consequences of certain decisions regarding batching. Although generic terminology of a batch is often used, Operations Science defines two types of batches. One is Transfer Batch, which describes a group of items that are moved together from one operation to the next. The other is Process Batch, which describes a group of items that can be produced without a changeover, i.e., setup. Process batch can further be categorized as simultaneous batch (multiple items processed at once like baking a “batch” of cookies) or sequential batch (items processes one at a time). The larger the process or transfer batch, the cycle time increases due to the amount of time an item has to wait for the batch to be formed or waiting for its turn to be processed. Based on this, some of these unintended consequences materialize as longer schedules, higher costs as more resources may be needed to process larger batches, and higher amounts of cash tied up due to the work-in-process (WIP) that gets generated.

Batch Types in Production Systems

But despite these unintended consequences, operating based on large batches may be good for some. This is because many responsible for projects focus on achieving as high capacity utilization as possible by decoupling their work from the previous process using inventory, while ensuring the use of capacity on setups/changeovers is minimized. In other words, and from a process perspective, those that receive the work (the downstream party) may prefer big batches, so they are able to optimize what they do – like those accountable for each portion of the work in the above story. For example, fabricating “all” two-inch pipe before eight-inch pipes by having “all” the design information needed allows only one changeover to be made and ensures most of the time is spent on fabrication. Using this perspective, one can argue batching is good for every individual player in a project. However, if you own and operate the asset, and need the output the asset produces the soonest, excessive batching across the project will constrain you from achieving your business and project objectives.

But let’s explore this last point a bit further. To do this, we will use the schematic below, which shows a meta-level representation of a project production system including operations and the work in between operations. Like the story, our experience tells us that if you ask those responsible for fabrication about how much engineering they want to have before fabrication starts, there is a high likelihood that they will say “all of it.” Similarly, those who are responsible for the delivery / transportation look to have all of it ready at the end of fabrication and assembly, so they can optimize for full loads. Those that build want to have as many materials on site as they can before they start a given scope of work. The same effect occurs in between installation activities, as it is common to see a contractor or subcontractor not allowing others to get into a given area until they complete their own work, a large transfer batch resulting in increased wait-to-batch time. If you look at projects from a production perspective, an excessive batching frenzy unfolds in front of your eyes on every project, on every phase, every day. Once again, the negative consequences for those that own and operate the asset are quite significant – longer delivery cycles, excessive cost and high volumes of cash tied up in the system.

Batching Across Project Production Systems

But as you get deeper and analyze how the industry currently operates, batching work in ‘excessive’ amounts is so ingrained that the rules that drive batch sizes are not only established without knowing if they are optimal or not, but also survive over time – meaning they are inherited from project to project without being questioned. For instance, in a recent interaction with an engineering team involved in the delivery of an industrial facility, one of the discipline leads indicated that they transfer 100 electrical loop drawings at a time, but when asked why 100 drawings, neither he nor his team members could answer why, and stated this is how they did it on the last project. Further exploration and analysis enabled reduction of transfer batches to 20 drawings at a time incorporating technical engineering requirements.

In many cases, the batching frenzy we are referring to starts at a meta level, when work must be batched to comply with stage-gate processes causing work to accumulate at the end of a gate before it is released to the next one. Coincidentally, many following this practice also look to compress end-to-end project schedules, but surprisingly, continue to operate based on stage gates – for some, governance seems to be more important or relevant than the loss of revenue and competitive advantage associated with longer delivery cycles.

Although we can cite hundreds of other examples, there are a couple more that are common. For those in fabrication and assembly, there is a trade-off between batching work and set ups in the production process, which drives many to produce a large batch of the same type of elements / components / parts to reduce set up time. In commissioning, for instance, batching materializes when all sub-systems in a system need to be mechanically completed and pre-commissioned to initiate commissioning of the full system.

In summary, batching is and should be expected in project production, however, the question is what should the size of process and transfer batches be to avoid extending the time it takes to deliver the project?

You may be thinking that the goal should be to reduce batches to the minimum possible, meaning one unit at a time, a concept popularized by the phrase “single-piece flow”, however, this is not always economical or in many cases, not even technically doable. Operations Science provides the technical means to answer what optimal batch sizing is.

Next time you look at your work, “look closer” and watch how you and your team are batching that work. There is a high chance you will find yourself immersed in the excessive batching frenzy. If so, what are you going to do about it?