An engineering-information reporting model covering 52,000 RFI, submittal and deliverable events across packages and disciplines, with ageing, cycle-time and approval-performance analysis.
On a construction project, RFIs, submittals and deliverables move between contractors, designers and the project team every day. A register can contain thousands of records. Simply saying “we have 200 open items” does not tell management which package is stuck, which records are old, whether new RFIs are arriving faster than they are being closed, or where repeated revisions are happening.
I wanted to turn a large engineering-information register into something that points management toward the actual bottleneck: backlog, ageing, revision cycles, late deliverables or a responsible-party workload.
I structured 52,000 portfolio-safe engineering-information events into one reporting model covering RFIs, submittals and deliverables, then analysed them by package, discipline, responsible party, age, cycle time and approval outcome.
Standardise the different register structures and date fields.
Calculate open-item ageing, cycle times, monthly opened-versus-closed flow and package summaries.
Create management measures such as first-pass approval and on-time delivery.
Show where backlog and information risk are concentrated.
With the problem and data purpose clear, the next section shows the result first. The detailed steps below then show exactly how I got there.
Utilities records only 61.2% first-pass approval and 18.3% on-time deliverables, so the problem is wider than RFI count alone.
Yatify engineering-information reporting model · 52,000 eventsDesigned a common event model for RFIs, submittals and deliverables.
Separated open-item ageing, closed cycle time and monthly workflow movement.
Built package and responsible-party exception reporting.
Validated event IDs, dates, record types and closure logic.
Engineering teams can lose time because information becomes a bottleneck before physical construction is affected. The analytical problem is finding which packages, disciplines and workflow stages are creating delay risk in the information flow.
The 52,000 records contain RFIs, submittals and deliverables. They follow different workflows, but the management questions share the same core fields.
record_idrecord_typestatuspackagedisciplineresponsible_partycreated_datedue_dateclosed_dateThe current analytical cut-off is 2026-12-18
Opened − ClosedJan 2025: − = + RFIs.
Meaning: backlog grew sharply in that month even if some RFIs were being closed.First-pass approved submittals ÷ assessed submittals × 100Utilities: 0.0%; Drainage: 0.0%.
Meaning: these packages are stronger candidates for a revision-cycle/root-cause review than packages around 75% first-pass approval.Deliverables closed by due date ÷ deliverables assessed × 100Utilities: 0.0%; Drainage: 0.0%.
Meaning: the problem is not only RFI volume; required engineering outputs are also missing planned dates.Reporting cut-off − Created datePKG-ROAD-01: open RFIs with a median age of 0 days.
Meaning: I would immediately drill into the oldest records and their responsible parties rather than presenting only the count of open RFIs.The headline chart gives the decision signal. These additional views show whether the same conclusion survives when the data is sliced another way.
The team closed many RFIs, but not enough to keep pace with new queries in that month.
It has the largest RFI count, so it deserves a backlog review — but count alone is not the only risk measure.
This is materially weaker than the packages around 75%, so I would inspect rejection/revision reasons.
This points to a broader information-delivery issue, not simply an RFI administration problem.
Synthetic data cannot establish real industry performance benchmarks. The schema demonstrates information-management analytics, not a specific CDE vendor implementation.
Every interactive chart above already has a CSV button for its exact plotted numbers. These files are the deeper audit trail: source extract, model, SQL/DAX and validation.