QA/QC Process Structural Engineering Firm

Typically my review consists of verifying calculations are correct, references provided and confirm the assumptions are correct and codes correctly applied.

Plan review consists of review for constructability, match the calculations and sufficient details provided

QC isn’t the issue, it’s a symptom of mismanagement. EOR should be reviewing anything they are signing off on. Also staff should have ownership in their work and pride.

I always ask new hires if they actually enjoy their work cause I don’t want to work with someone who doesn’t want to be there. If someone asks me to review their work I tear it apart to find any possible errors or mistakes.

Once had a person provide me with a footing design for a moment resisting foundation and it was really small compared to my past experience, the person had left the company at this point because we weren’t doing enough building design, long story short they used kip-ft for the overturning moment and lb-ft for the resisting moment

We have a QA system however it’s largely divorced from the actual quality control., and is more aimed at satisfying the QA auditor people who have their own strange view of the world. Lots of check box busywork that doesn’t really do much.

If your employer isnt following standard engineering process then I’d be job-hunting bc of their disregard for the welfare of employees. Likewise, if you’re more than a year out of school and havent beaten process to death between college and PM/quality management/DoE/other training then I'd find a good corporate training program.

Every project’s FMEA identifies the risks, their frequency and severity, and possible courses of action – redesign, accept, or mitigate via analysis/testing. That drives decision-making and the analysis/testing needed. Beyond that, you need to be holding independent design reviews to solicit outside feedback and having a supervisor/SME spot-check/approve details throughout.

The frequency of design reviews and checks/approvals obviously depends on the size of the project. A quick 1-hour solo project is probably only going to be reviewed/approved for a few minutes at the end, whereas months/years-long team projects should be reviewed at least monthly. Consequently, you may or may not need a formal stage/gate process.

One thing we do is, at the start of the project, initiate a QA/QC risk level for the project. In other words, we have three tiers of project magnitude that call for three different levels of quality reviews.

This does two things - one, it allows the EOR to assess the complexity of the project or its exposure to risk - the design then proceeds with the EOR aware of how much (or how little) another engineer will be reviewing it - compels the designing engineer to actually be more careful to a degree on the lower tier projects.

Second, it allows more simple projects to not be bogged down by onerous processes or reviews that simply aren't necessary.

Also - the CASE checklists are fine but should not be confused with a good engineer doing a proper review - the checklists are simply tools within the process...not the process itself.

You have a checklist; now you just need a checklist that assigns who is responsible for checking the checklist. In a small company, that should be a (the) responsible engineer. Larger companies tend to have/need actual QA/QC people, since there's actually enough work to warrant one or more bodies to do that work. Larger companies may have a System Engineering Management Plan (SEMP) that is a higher level checklist of roles and responsbilities for any given project; a SEMP can be as simple as a single page, or have multiple pages, depending on the size/type of project. An internal project might have fewer roles and less oversight (simpler SEMP) vs. a larger customer project that requires more oversight and has more paper deliverables.

strguy11,​

As I see it, QA can do four things...

1. Restrict tasks to qualified persons (QPs), like professional engineers.
2. Define work methodology. This is how McDonald's gets burgers and french fries prepared by semi-literate teenagers.
3. Provide official to-do lists and checklists.
4. Identify red flags that tell management that quality standards are not being met.

I think that a lot of QA procedures are written to impress auditors. I wonder how good the auditors are at spotting bullshit.

IME most companies use a PDM/PLM app to automate engineering QC via standardized workflows and approvals. For example, the app typically doesnt allow engineers to roll their parts' CAD/print status to "released" until analysis/test/other reports have been uploaded and approved. Likewise, until the PM or lead has uploaded preliminary scope, budget, timeline, and other docs, and those docs have approved, they typically cant add engineers onto a new project. Depending on the employee's role and company need, workflows might be two steps or many and there might be two approvers or many for each workflow.

Stateside, ten years ago you could hire an external auditor to bless a crappy engineering process and regulators would accept that for infrastructure project approvals and safety audits. Today you typically need to submit docs showing that a robust process was followed, and that approval shortcuts are near-impossible, ie process maps from PDM/PLM.

CWB1,

Does PDM/PLM solve civil engineering issues? In manufacturing, we need strict change control, and we want to re-use as much stuff as possible. Just about everything in civil engineering is one-off, and failures are catastrophic. In manufacturing, you need an elaborate sign-off process because you are managing multiple stake-holders. In civil, I suspect you need a second pair of eyeballs which belong too someone experienced and very capable.

I have seen PDM/PLM software in the hands of people who are basically process driven. There is not a good understanding that the node on their process diagram is an abstraction of a real part that requires manufacturing time, that must be shipped to a customer by a certain date, and that can kill people if it fails.

Yup, its used on infrastructure projects the same as others. Some dont use it, some use it purely as a database for CAD & prints, and others also use it for process control and other purposes. Infrastructure development is the same as manufactured products in most ways. Large, complex, and/or safety-critical have many stakeholders between customers/owners, site operators, various engineering & trades contracts, multiple regulatorary agencies, 3rd parties (outsourced QA & others), and internal team & management, not only in new builds but iterative development. Preliminary approvals and commissioning/post-build testing can be a lengthy PITA bc of it. And just like in manufacturing there are plenty of knowitalls trying to shortcut the system, do everything themself, and fly under the radar.

Common sense and staff input do need to regularly be applied to process, bc bad process could be needlessly slow/difficult or fail to prevent mistakes, incompetence, and other human issues as you mentioned. Risk should also be considered an independent variable, not to be conflated with project size or other details. On a tiny low-risk project, completed solely by one generalist you might only require their manager's review/approval. If the same tiny project was higher risk, you might want to also have a CAE manager or other SMEs do a quick review/approval. In either case, PDM/PLM and the process are just tools to keep everybody reasonably organized and accountable. I'm a big advocate bc I've seen many failures due to human factors - my Ishikawa usually shows either a knucklehead in design forgot/skipped an easy analysis (ie bolted joints) or a knucklehead in the shop forgot/skipped a step in the build process (ie using his torque wrench).