Where the Project Was Really Won
On most industrial projects, attention naturally centers on the visible milestones — equipment delivery, panel installation, commissioning, and startup. Those are the dates everyone tracks and plans around.
But long before any of those happen, the project’s direction is already being determined.
During the design phase, the system is not yet being built — it is being defined. Decisions made at this stage determine how the plant will actually operate once power is applied and how predictable later phases will be. If those decisions are made early and clearly, the project tends to progress smoothly. If not, the consequences usually become evident much later, when they are more difficult and expensive to fix.
We saw this play out on a recent greenfield hydrogen production facility where we designed and implemented the control system.
The Challenge: Overlapping Engineering & Procurement
When we got involved, the facility was already moving ahead. Engineering, construction, and procurement were advancing simultaneously, with multiple teams working on different information at the same time.
There was enough definition to begin work — but not enough to execute confidently.
Where the Uncertainty Lived
Some control system inputs were still developing. The I/O list — the foundation for connecting field devices — was incomplete in some areas and continued to evolve as equipment and wiring details were finalized. Meanwhile, the control narrative describing how the process should operate was still taking shape. P&IDs showed the equipment layout, but they did not fully specify startup behavior, shutdown conditions, or operator interaction.
Higher-level decisions were also evolving. Remote access expectations, operator interface needs, and portions of the system architecture were clarified gradually as stakeholders aligned on how the facility would ultimately be operated and supported.
The result was a design phase in which some details were stable and others were still being defined. Rather than building around assumptions, the early effort focused on determining which items could safely progress and which required clarification before configuration advanced.
Before programming or hardware decisions moved too far, the objective was to establish a shared understanding of how the plant was expected to operate.
What We Stabilized First
With several inputs developing at once, the first step was not configuration. It was identifying which decisions would matter most if they were wrong.
I/O Definition
The I/O list was reviewed first. These signals determine how field devices connect to hardware and how panels are ultimately wired.
During the review, some signal types and channel assignments did not match how the equipment would be installed. At this point, corrections were simple — drawings and assignments could be updated while the design remained flexible. If left unresolved, the mismatch would have appeared later during panel fabrication or field wiring, when changes would require physical rework.
System Operation
The second focus was system behavior. The P&IDs described equipment, but not always how the plant was expected to operate day to day. Startup sequences, shutdown conditions, alarms, and operator actions were still being clarified.
Rather than interpret intent, the team worked with stakeholders to establish a shared operational description. This allowed control logic to be built around agreed behavior instead of assumptions and prevented conflicting expectations from surfacing during testing.
Architecture
Architecture decisions were reviewed in parallel. Remote access needs, operator stations, and system structure influence licensing, server sizing, and network configuration. These items can technically be changed later, but once configuration and testing begin, even small adjustments ripple across the system.
Aligning these expectations early created a stable baseline for the remaining work.
By the end of this phase, the project had something it lacked at kickoff: a shared understanding of how the system was intended to function.
Moving faster is not the same as moving forward. If you embed uncertainty into the logic now, you will pay for it during startup
Strategic Pausing: Why We Halted Programming to Verify Logic
As the design advanced, some areas became clear enough to move forward. Others did not. In those cases, moving faster would not have moved the project forward — it would have embedded uncertainty into the system.
Verifying Before Building
In one part of the process, the documentation described the equipment but not how it was expected to behave during operation. The overall function was understood, but the sequence of events, permissives, and operator interaction were not yet clearly defined enough to support reliable control logic.
The configuration could have continued based on interpretation. Instead, development in that area was deliberately paused while clarifying the behavior with the relevant stakeholders.
Work elsewhere continued. Where definitions were stable, progress continued normally. But where system behavior affected sequencing or operator action, the design was verified before the system advanced.
This required extra coordination and was not the quickest option at the time. However, it prevented the control system from being based on assumptions that would later need reprogramming and retesting.
The intent was not to slow the project — it was to ensure that progress, once made, did not have to be undone.
A Problem Found on Paper Instead of in the Field
The benefit of verifying decisions during design became evident as detailed reviews advanced. As assumptions were compared with actual hardware and operation, several conflicts emerged that would not have been seen until much later in the project.
One of the clearest examples came from the field device connections.
Overall, the signal assignments appeared reasonable. However, when comparing the I/O definitions to the chosen hardware, some analog signals were grouped in ways that the cards could not support. Two-wire and four-wire devices were assigned to the same channels, even though the hardware required them to be separate.
On drawings, the conflict was subtle. The system could have been built without anyone noticing.
The issue would not have surfaced until panel fabrication and field wiring began. Electricians would connect wires according to the drawings, devices would not operate as expected, and troubleshooting would start without an obvious cause. Fixing it at that point would involve tracing signals, reassigning channels, updating documentation, changing terminations, and coordinating multiple contractors while startup activities were already planned.
Instead, the mismatch was identified during the design phase. The solution involved updated drawings and revised assignments, rather than physical rework. The hardware remained consistent, wiring was completed smoothly, and testing verified the expected operation.
In a meeting, it appeared to be a small documentation change. In a project environment, timing mattered far more than size. Addressed early, it required coordination. Discovered during commissioning, it would have affected the schedule.
Similar clarifications took place throughout the design process — operational behavior, alarm handling, and safety expectations were aligned before finalizing the configuration. Each eliminated uncertainty from later phases.
The value of the design phase isn't that nothing will change–it's ensuring that necessary changes happen while they are still manageable, not after the system is built.
Final Perspective
Projects rarely begin with complete information. Equipment decisions, operating expectations, and construction all advance together. The challenge is not eliminating uncertainty but deciding when it is resolved.
On this project, the critical work happened before implementation — clarifying behavior, confirming assumptions, and aligning how the plant was expected to operate. By the time configuration began, the system was no longer being interpreted. It was being built.
The result did not appear as a specific feature or component. It appeared as predictability: fewer open questions, fewer reinterpretations, and a shared understanding among the teams responsible for the facility.
Design does not remove complexity from a project.
It determines whether complexity is addressed early or encountered later.
Pigler Automation works with industrial facilities to design, implement, and support control systems. Much of our work begins during early project planning, where defining system behavior has the greatest impact on execution.
