When we started building SnapScale, I knew from my own experience on capital projects that process engineers spend a disproportionate amount of time on document verification rather than engineering. But having a strong intuition about something and understanding it precisely enough to build a product around it are different things. So before writing a line of code, we asked a small group of process engineers on active projects to track how they actually spend their time over the course of two weeks.
The results were useful precisely because they were not uniform. They varied by project phase, by the size and seniority of the team, and by how much of the document work had been systematized. But certain patterns appeared consistently enough to shape how we thought about SnapScale's design.
The Tracking Methodology
We asked nine process engineers across five different projects to keep a daily log of their working hours, categorized by activity type. The categories were intentionally broad: engineering calculation work (simulation runs, equipment sizing, hydraulic calculations), document preparation (writing and updating process documents), document review and verification (checking documents for errors, comparing documents against each other or against project basis), meetings and coordination, and other. We did not define these categories precisely, because we wanted to capture how engineers themselves categorize what they do, not impose our own framing.
The tracking period was two weeks, chosen to cross at least one P&ID revision cycle on most projects. We accepted that two weeks is a sample, not a representative average over a full project lifecycle. Phase matters significantly: a process engineer in FEED spends time differently than one in detailed design, and within detailed design the profile shifts as the design matures. Our sample covered engineers primarily in mid-to-late detailed design, where document volume is at its peak.
The Aggregate Finding
Across the nine engineers, the two-week average broke down roughly as follows:
| Activity | Avg % Time | Range |
|---|---|---|
| Engineering calculation and simulation | 22% | 14% to 31% |
| Document preparation and updating | 19% | 11% to 26% |
| Document review and cross-checking | 31% | 22% to 41% |
| Meetings and coordination | 21% | 15% to 28% |
| Other | 7% | 4% to 12% |
Self-reported time allocation, 9 process engineers, mid-to-late detailed design phase, two-week sample period.
The result that we had expected but that was still striking in the concrete numbers: document review and cross-checking consumed more of the average process engineer's time than any other single category. It took more time than engineering calculations.
What "Document Review and Cross-Checking" Actually Involves
When we asked engineers to describe what they were logging in the cross-checking category, several distinct tasks came up repeatedly. Checking that process data sheets reflected current P&ID conditions after a P&ID revision. Verifying that equipment datasheets submitted by vendors matched the process conditions in the current project basis documents. Reviewing instrument datasheets against the instrument index and the P&ID. Comparing line list entries against the P&ID at milestone review points. Reading vendor pump curves and checking that the operating points matched the hydraulic analysis. Reviewing cause-and-effect matrix entries against the safety requirement specification.
None of these tasks require advanced engineering judgment. They are comparison tasks: does value A in document X match the corresponding value A in document Y? The engineering judgment is in knowing which values matter and what constitutes a significant discrepancy. But the mechanical act of finding the two values and comparing them is not engineering in any meaningful sense. It is data retrieval and comparison, done slowly because the data is stored in heterogeneous document formats without a cross-reference layer.
The Seniority Problem
One of the clearer patterns in our sample was that senior engineers spent a higher percentage of their time on cross-checking than junior engineers. This is counterintuitive at first: you would expect junior engineers to be assigned the most tedious checking work while senior engineers focus on the higher-judgment tasks.
The reality is more complicated. Junior engineers do get assigned checking work, but they also require supervision on that work, and when they find a discrepancy they often do not have the project knowledge to correctly assess its significance. So the senior engineer ends up reviewing the junior engineer's findings, checking the same documents again, and making the judgment calls that the junior engineer could not. The senior engineer spends time doing the cross-checking and time doing the supervision of someone else's cross-checking.
This pattern is wasteful twice over. Senior engineers do the highest-value engineering work least efficiently when they are absorbed in document comparison. And the supervision cycle means the same check is done multiple times rather than once. We are not saying that cross-checking should be unsupervised. We are saying that when the primary constraint on finding a discrepancy is the time taken to locate and compare the two relevant values, that constraint is a tooling problem, not a supervision problem.
Project Phase Variation
The engineers with the highest cross-checking percentages (35% to 41%) were all in the phase immediately following a major P&ID revision cycle. This made sense: after a set of P&ID revisions is issued, the downstream documents that reference those P&IDs all need to be reviewed against the new revision. Process data sheets, line lists, instrument index, cause-and-effect matrix, relief valve sizing basis. The review workload concentrates in the weeks immediately after a P&ID issue and then falls off as the updates propagate through the downstream documents.
The engineers with the lowest cross-checking percentages (22% to 24%) were in a quieter period between P&ID revision cycles, where the main cross-checking work was vendor document review rather than post-revision propagation. Vendor document review is intensive but more bounded: there is a defined set of datasheets in the current review batch, and the checks are scoped to that batch rather than open-ended.
This phase variation has a direct implication for how a cross-check tool should work. The peak burden comes precisely when the cross-checking is hardest to schedule and most likely to be done under time pressure. A tool that processes document revisions as they are uploaded and flags discrepancies immediately, rather than requiring a manual review cycle after the fact, addresses the workload precisely when it spikes.
What This Shaped in SnapScale
The tracking exercise confirmed several things that shaped the product. The primary value SnapScale needs to deliver is time reduction on cross-checking tasks, not additional intelligence about the project design. Engineers know what to check. The bottleneck is finding the relevant values across documents, not knowing which values matter.
This meant we should build around document ingestion and cross-reference extraction, not around design analysis or recommendation engines. The engineer should see a list of current discrepancies with the specific values and their source documents, and be able to confirm or dismiss each one quickly. We are not building a system that tells engineers what to think about their design. We are building a system that removes the navigation cost from the checking work they already know they need to do.