“Every Engineer Deserves a Buddy Who Never Misses a Code”

As an Electrical Engineer and MEP Consultant working on DEWA and UAE authority submissions, I’ve been thinking a lot lately about a stage of our work that rarely gets talked about outside the industry — the approval process itself.

Most experienced MEP design engineers I’ve spoken with share the same frustration: the approval stage sometimes undoes everything — unexpected errors, missed updates to regulations, or details lost somewhere in a long design process — leading to endless revision cycles.

Reflecting on my own submissions over the years, I keep coming back to the same question: local codes and regulations are accessible, sure, but realistically, how much time do we spend reading through them, cross-checking every clause, just to end up complying to a single reviewer comment weeks later?

What if there was an assistive tool that could help detect, review, and suggest corrections to MEP drawings before submission — something that works alongside how an engineer already thinks and designs, not against it?
I’m not talking about replacing engineering judgment — I’m talking about reducing the hours spent manually cross-referencing codes, so more time goes into actual design thinking, not repetitive compliance-checking.

I’d genuinely love to hear from fellow engineers on this: how much of your time on a typical project goes into revisions caused by things that could’ve been caught earlier? If you had a reliable assistive tool in your corner — something like a trusted buddy at work, quietly double-checking things before submission — would that actually change how you work? Or is there something about the process I’m not seeing?

Parents
  • I can strongly relate to this discussion, having gone through numerous  consultant, client, and vendor approval cycles on large scale construction projects.

    In my experience, revisions are certainly not always unjustified. There are genuine engineering mistakes, compliance gaps, and design coordination issues that must be identified before construction. Those reviews add significant value to the project.

    However, what I have observed more frequently is that many document rejections are driven by relatively minor issues like drawing presentation, formatting inconsistencies, documentation aesthetics, product data arrangement, or small compliance deviations that have little or no impact on the engineering design, equipment performance, safety, code compliance, or overall constructability.

    The challenge is that these documents often pass through multiple layers of review contractor, consultant, client, specialist consultants, and sometimes authorities. Despite this extensive review chain, documents are not always assessed based on the engineering significance of the comments. Instead of distinguishing between critical and non-critical observations, the entire submission is often rejected, resulting in another full review cycle.

    From a project execution perspective, this can significantly affect procurement, manufacturing, equipment ordering, and construction sequencing. Many of these non-critical observations could instead be issued as "Approved with Comments," allowing parallel progress while requiring the contractor to incorporate the agreed revisions before installation or implementation. This would maintain quality while avoiding unnecessary delays to the overall project schedule.

    As General Contractors, we are contractually responsible for coordinating submissions and delivering the project. However, maintaining the project timeline should not rest solely on the contractor. Every stakeholder including consultants, clients, specialist consultant, and vendors shares responsibility for enabling timely project delivery. Review comments should therefore be objective, risk based, and proportionate to their actual technical impact.

    Regarding AI assisted compliance tools, I believe they have tremendous potential, but there are practical limitations.

    Technical review comments are highly dependent on project specific factors such as client specifications, authority interpretations, contractual requirements, site constraints, engineering philosophy, and reviewer judgment. The same design approach may be acceptable on one project yet require modification on another. This variability makes it extremely challenging to develop a universal tool capable of consistently replicating expert engineering decision making.

    Where I see immediate value is in automating objective and standardized checks. AI can effectively identify drawing inconsistencies, missing documentation, incorrect references, formatting issues, layer standards, title block discrepancies, incomplete schedules, repetitive compliance checks against well defined codes, and other procedural or presentation related observations. Automating these repetitive checks would allow engineers and reviewers to dedicate more time to evaluating the aspects that truly require engineering expertise, judgment, and project specific decision making.

    Ultimately, the goal should not be to replace engineering judgment but to improve the efficiency and quality of the review process. If technology can eliminate avoidable administrative comments and enable reviewers to focus on genuine technical risks, it would significantly reduce approval cycles while maintaining the integrity, safety, and constructability of the design.

Reply
  • I can strongly relate to this discussion, having gone through numerous  consultant, client, and vendor approval cycles on large scale construction projects.

    In my experience, revisions are certainly not always unjustified. There are genuine engineering mistakes, compliance gaps, and design coordination issues that must be identified before construction. Those reviews add significant value to the project.

    However, what I have observed more frequently is that many document rejections are driven by relatively minor issues like drawing presentation, formatting inconsistencies, documentation aesthetics, product data arrangement, or small compliance deviations that have little or no impact on the engineering design, equipment performance, safety, code compliance, or overall constructability.

    The challenge is that these documents often pass through multiple layers of review contractor, consultant, client, specialist consultants, and sometimes authorities. Despite this extensive review chain, documents are not always assessed based on the engineering significance of the comments. Instead of distinguishing between critical and non-critical observations, the entire submission is often rejected, resulting in another full review cycle.

    From a project execution perspective, this can significantly affect procurement, manufacturing, equipment ordering, and construction sequencing. Many of these non-critical observations could instead be issued as "Approved with Comments," allowing parallel progress while requiring the contractor to incorporate the agreed revisions before installation or implementation. This would maintain quality while avoiding unnecessary delays to the overall project schedule.

    As General Contractors, we are contractually responsible for coordinating submissions and delivering the project. However, maintaining the project timeline should not rest solely on the contractor. Every stakeholder including consultants, clients, specialist consultant, and vendors shares responsibility for enabling timely project delivery. Review comments should therefore be objective, risk based, and proportionate to their actual technical impact.

    Regarding AI assisted compliance tools, I believe they have tremendous potential, but there are practical limitations.

    Technical review comments are highly dependent on project specific factors such as client specifications, authority interpretations, contractual requirements, site constraints, engineering philosophy, and reviewer judgment. The same design approach may be acceptable on one project yet require modification on another. This variability makes it extremely challenging to develop a universal tool capable of consistently replicating expert engineering decision making.

    Where I see immediate value is in automating objective and standardized checks. AI can effectively identify drawing inconsistencies, missing documentation, incorrect references, formatting issues, layer standards, title block discrepancies, incomplete schedules, repetitive compliance checks against well defined codes, and other procedural or presentation related observations. Automating these repetitive checks would allow engineers and reviewers to dedicate more time to evaluating the aspects that truly require engineering expertise, judgment, and project specific decision making.

    Ultimately, the goal should not be to replace engineering judgment but to improve the efficiency and quality of the review process. If technology can eliminate avoidable administrative comments and enable reviewers to focus on genuine technical risks, it would significantly reduce approval cycles while maintaining the integrity, safety, and constructability of the design.

Children
  • One method, or style of Method, is the Fagan Inspection (originally for software IIRC).

    Fagan_inspection

    The power is in the way that contributors are directed to narrow focus tasks, to avoid everyone falling into the same traps, and the right sizing of the head count so that synergy (synthetic extra energy) is gained. Everybody can contribute. A useful method if you can get it to work for your organisation.

    Another feature is to do a failure analysis on your documents/drawings. You will find that failure rates are consistent with the human effort needed for the tasks, so if there are 100's of hole positionings (that ought to coordinate with other drawing to match the positions) then you'll get many errors there. Its only the pre-known 'difficult' positions that get sufficient time to avoid mistakes [i.e. management 'positions' on a subject Wink]. 

    In a study I was involved with, the core 'error' in mechanical drawings, was that holes&fasteners problem. There are so many opportunities for failure, hence the failure rate. Many CAD systems are unable to operate design [checking] rules (e.g. the thread of the nut and that of bolt should be the same; the hole build-up should be deep enough to accept the bolt length; etc.

    Linking back to rules and regulations is harder as they are [unlimited] external environment factors, and often missing the rationales for their presence, becoming blinkered yes/no rules [see plug-in solar discussion..]

  • Suraj, your point about non-critical observations triggering full rejections instead of an “Approved with Comments” path is one of the most useful things I’ve heard in this whole process. It reframes the problem precisely: the issue isn’t just catching errors, it’s that review chains don’t distinguish critical from non-critical, so everything gets treated with the same weight. That’s a much sharper target than “reduce revisions” in general.

  • point about non-critical observations triggering full rejections

    This often misses the "who is the stakeholder" question. So many times I've been in specification reviews (military equipment boxes & sub-assemblies) where it's taken most of the meeting to resolve the "section 1. Introduction" to ensure that the senior stakeholders properly had a summary of what the specification was about, where it fit in, what was excluded, etc.

    It felt really frustrating with taking so long over page 1, of 64. It's not till one gets to a more senior position (or experience) that you start to realise just how important those safety rails of a well written introduction/scope make to the understanding of the big picture. 

    So much of the specifications end up being technical boiler plate implied directly by some phrase in the introduction, copied from a higher level system spec, e.g.  "North Atlantic Winter" ... vs "Arctic Winter".

    Criticality isn't a yes/no question. It's "Critical to who?"..