Sweco Building Control Limited: A Quality Reviewer's 7-Point Submission Checklist

I am a quality reviewer at Sweco. That is not a neutral job description. I am not the designer of most documents I review; my job is to check the process around them. The regulated side of my work sits within Sweco Building Control Limited, and when I exchange notes with our colleagues in Sweco Sverige, the same disciplines come up. Quality systems travel.

If you have ever opened a signed report and asked how it got out, this list is for you. It is for documents that will be signed, submitted, or handed over to another organisation. It is not for personal notes or low-risk internal emails.

What this checklist is for

This checklist belongs at the end of a task, just before a document is released to someone else. It applies to design notes, permit applications, building control submissions, and technical reports. It also works for a final drawing package or an internal review memo.

It is not a spelling test. When I first started doing quality reviews, I assumed my job was to catch typos and inconsistent spacing. It took me about four years and several hundred documents to understand that the most expensive review failures are communication failures. Clean grammar does not solve a missing owner or a stakeholder who was never invited to comment.

There are seven checkpoints below, in the order I use them.

Seven checkpoints I run before anything leaves my desk

1. State what the deliverable is and what decision it supports

I ask the author to finish this sentence: this document is for [person], and it should help them decide [decision]. If they cannot finish it without adding a second sentence, the document will be ignored or misread.

I once reviewed a report labelled Draft for comments. No decision date, no named reviewer, no instruction. The client returned comments about punctuation because nothing in the document told them what to do with it. A two-sentence brief at the start would have saved three weeks.

Do this before writing the content, not after. It will force you to remove material that only sounds useful.

2. Prove the file matches the issue sheet

Check the revision number, issue date, and file ID. Then open the file and check the same information inside. The file name is not evidence. The cover page is not evidence. Evidence is what sits inside the document and matches the record outside it.

In a Q1 2024 audit I saw a drawing set marked Revision P4. The issue sheet said P4. The files contained mostly P2 details with P4 notes typed on the cover sheet. Anyone who used those drawings was about to build from old information.

This step is not exciting, which is why it gets skipped. Do not skip it.

3. Run the orphan paragraph test

For each paragraph, ask: which requirement or decision does this paragraph serve? If nothing in the document references it and no customer requirement needs it, delete it or make it justify itself.

Most documents I reject are not short of content. They have too much content doing too little work. If a paragraph makes a general point but does not lead to a conclusion, it creates doubt. Delete it before anyone asks what it means.

That sounds obvious, but it is not the same as copy-editing. You will not find orphans by reading for punctuation. You find them by reading for function.

4. Assign an owner to every action and every comment

Every comment should have a name, and every name should have a next action. If the answer is only that the comment was noted, that is not a closed loop. It is a delay waiting to happen.

Several years ago I said: Please red-line the drawing. The author heard: Make your markups red. So they coloured the comments red in the PDF and did not change the drawing. We found it during the next review meeting. The words were clear in my head; they were not clear in the instruction.

The fix is to put an owner and a verb on every action. Rita to update section 3 by Friday. Not: the document should be updated.

5. Ask who should be playing but is not in the room

This question has saved me more than once. The wording came from an email I saw after a project handover. The email contained a question I now put in every review brief: Why is Henry not playing?

Steven was on the approval matrix. Miranda was on it too. Both are good engineers. Neither one worked in facilities, and the building was going to pass to a facilities team at handover.

Henry was supposed to be the facilities manager. He was not on the distribution list. He did not see the drawings that affected access for maintenance. The system failed because the approval matrix only contained people someone remembered at the start, not people who could say what would go wrong at the end.

I now treat that as a technical question, not a people question. Who is affected by this document and not named on it? If the answer is more than one person, expand the review list before the issue date.

6. Separate reviewed from approved

Reviewed means someone has looked at a document. Approved means someone with authority accepts responsibility for it. They are different actions.

I have seen review matrices with one column labelled approvals. When a problem appeared later, two of the named people said they had approved because they had been copied on the email. The third said they had approved but had not opened the file. No one could tell who was accountable for the technical content.

Use two columns on the matrix: reviewed by and approved by. If a name is in the approved column, that person must provide the approval. Do not flip a status automatically because an email was read after lunch.

7. Write down the residual risks

A quality review does not guarantee a perfect document. A clear document ends with a short statement of what was checked and what was not.

For example: the report verifies the proposed route and the foundation assumptions, but it does not cover groundwater modelling. That sentence looks uncomfortable in a final report. It is also more honest than silence.

Leaving a known limitation in a follow-up email creates a risk. When the document is read later, the reader will assume the limitation does not exist.

Common errors I still see

First, a syntax pass is used as a technical review. It is not enough. A clean first page can hide a missing validation on page 40.

Second, documents are circulated to too many people. Twenty vague comments are harder to resolve than six direct ones. Choose reviewers by their connection to the decision, not by their place in the org chart.

Third, people send the document and ask for comments by Friday. A comment request is not a review brief. Name one question per reviewer when possible. That turns a general read into a useful one.

I am not against doing a few of these checks on paper. On a small project with one decision maker, it still works. But the more organisations are involved, the more important it becomes to make the process visible. Efficiency is a quality issue. When we moved our own checklist to a shared template in 2023, our median review cycle dropped from around five days to two. We did not do it by working harder; we did it by making the workflow answer the same questions every time.

If your review process leaves a central question unanswered, start there: who else should be looking at this before it goes out? Then check whether they are actually playing. That is the whole checklist. The steps are not complex. The problem is that people skip them when the deadline is close. Trust me, this list will not fix a late document. It will stop a late document from becoming an incorrect one that other people see.