Infrastructure · Design review
How to review design-change impacts on a project
A drawing comparison identifies visible differences. A design-change impact review follows those differences into requirements, interfaces, supporting evidence and project decisions. The output should explain what needs to be reassessed, who owns it and what is required before the change can proceed.
- Confirm the authorised comparison baseline before reviewing a new issue.
- Follow the consequences into related packages and supporting evidence.
- Record approval and verification of implementation as separate events.
Define the change before opening the drawings
Write a short change statement: what is proposed, why it is needed, which asset or package it affects, and which decision is now required. Include the originating request and identify whether the material is a proposal, a review issue or an approved revision.
Record the old and new document identifiers and revisions, along with the associated transmittal or issue record. Confirm whether the drawings belong to equivalent stages and scopes. A comparison between a preliminary layout and a detailed issue may show development as well as the particular change under review.
NASA’s configuration-management guidance describes a sequence of proposing, evaluating and approving changes, followed by incorporating them and verifying implementation. Use that as general background while following the authority and release process established for your project.
Review the drawing package, then inspect the differences
Start with the sheet register. Match sheets by their drawing identity, and list additions, deletions and replacements. Page order alone is unreliable when a package has been reorganised. Check title blocks, revision descriptions, scale, orientation and referenced details.
Use overlays or comparison views to locate candidate changes. Check each important difference against both source sheets: scan alignment, line thickness and export settings can create visual noise. Review notes, schedules, dimensions and cross-references as well as geometry. Revision clouds can help navigate an issue, but the review should also consider content outside the clouds.
- Capture the sheet and region where each material change appears.
- Describe the change in plain language and retain the original source reference.
- Flag mismatches between the revision description and the visible drawing content.
Follow each change into the affected decisions
Ask the relevant disciplines to assess consequences using the same source versions. The purpose of the following prompts is to surface questions and owners. Technical acceptability, commercial entitlement and programme effects need their own competent assessment using the applicable project records.
| Area | Review question |
|---|---|
| Requirements | Which obligations and previously accepted evidence rely on the changed design? |
| Interfaces | Which adjacent package, discipline, supplier or asset uses the affected information? |
| Design evidence | Which calculations, models, specifications or reports require review? |
| Delivery | Which procurement, fabrication, construction or access assumptions might be affected? |
| Cost and programme | Which quantities, commitments or activities need assessment by their owners? |
| Verification | Which inspections, tests, reviews or handover records need to be revised or repeated? |
Keep findings, recommendations and decisions distinct
For each finding, record the source, the potential consequence, the information still needed and the responsible owner. State the basis for priority using the project’s existing risk process. Avoid an unexplained score that gives a precise-looking answer without a reviewable rationale.
The change record should then show the recommendation, the authorised decision, any conditions and the date. Where a reviewer finds no material impact, retain the scope of their assessment and the evidence used. A decision for one discipline should not silently close another discipline’s unresolved question.
Verify what was implemented
After approval, check that the issued drawings and related records reflect the decision and its conditions. Update the affected requirements links, evidence references and open actions. Communicate the release through the project’s controlled document process so recipients can identify what supersedes the earlier issue.
Close the change when the required implementation evidence and follow-up reviews are complete. Preserve the approved baseline and decision history. This gives a later reviewer a route from the original request through the assessment to the configuration actually released.
Connect comparison tools to the review workflow
A PDF comparison tool helps a reviewer locate visible differences. A connected requirements and evidence record helps identify what those differences might affect. Give the findings a durable home in the project record so they can be assigned, assessed and closed.
ToM Assurance Suite brings drawing evidence, requirements, interface risks and reviewer decisions into a connected project context. Its drawing-analysis outputs include candidates for support, contradiction or insufficient evidence. Those candidates remain reviewable before they become the basis for an authorised decision.
Before you close the review
- The change request, purpose and required decision are recorded.
- Old and new revisions are identified, with added and removed sheets accounted for.
- Material differences are linked to their source sheets and locations.
- Affected requirements, interfaces and delivery questions have owners.
- The decision records the authorised reviewer and any conditions.
- Released documents and follow-up evidence have been checked against the decision.
ToM Assurance Suite
See how requirements, design evidence and interface risks support a reviewable project decision.