How do I track action items from a mechanical design review?
Log every comment in one list during the review, each with an ID, the view or drawing zone it refers to, an owner, a due date and a disposition: accepted, rejected or deferred. Close an item only when the change is in a named revision, and record which revision closed it.
Why review comments disappear
Most meeting tools are built for actions like "send the quote by Friday". A design review comment is different: it points at a feature, and it is only done when the model changes and someone confirms the change is right.
On a small team the comments end up in meeting notes, a chat thread and the CAD owner's memory. The change gets made, but nothing links it back to the comment. Two reviews later, someone raises the same issue again, and nobody can say whether it was fixed, rejected on purpose, or forgotten.
Formal programs solve this with a record per comment. NASA's systems engineering handbook expands RID as "Review Item Discrepancy or Review Item Disposition" (NASA). A small team doesn't need the forms, but it does need the same idea: every comment gets an ID and an answer.
Worked example: 520-0144 battery door latch, review 3
Review 3 of the latch produced five comments. They go into one log, kept in the part's folder next to the review pack:
/520-0144 Battery door latch/
/review-03/
520-0144_P2_review.pdf
/views/ V01 to V04
520-0144_review-03_log.csv
The log after the first week:
| ID | View | Comment | Disposition | Owner | Due | Closed in |
|---|---|---|---|---|---|---|
| R3-01 | V02 | Latch spring arm too thin for 5,000 cycles | Accepted | CAD owner | Nov 2 | P3 |
| R3-02 | V03 | Hard to open with gloves | Accepted | CAD owner | Nov 2 | Open |
| R3-03 | V01 | Change color to match the housing | Rejected: color is set by the molder's resin order, not the model | Product | n/a | Closed |
| R3-04 | V04 | Add a drain hole | Deferred to EVT (engineering validation test) | Mechanical lead | EVT review | Deferred |
| R3-05 | V02 | Check snap engagement after R3-01 | Accepted | Supplier | Nov 9 | Open |
Step 1: Log live. One person types while the CAD owner drives the model. Each comment gets the next ID and the view it refers to, in the reviewer's own words.
Step 2: Give every item a disposition within two working days. Accepted means it will be changed. Rejected needs a one-line reason, as in R3-03, so the next review doesn't reopen it. Deferred needs the milestone it moves to.
Step 3: Close against a revision. An accepted item closes only when the change is in a named iteration or released revision, and the person who raised it has looked at it. R3-01 closed in P3 when the reviewer checked the new section view.
Step 4: Open the next review with the open items. Before any new topic, go through every open and deferred line. Items that are open twice in a row get a new owner or a new date.
Step 5: Check the log at release. Before Rev A is released, every accepted item is closed or explicitly deferred. The released drawing's revision description can then point at the log, and the reasons stay findable later, as in How do I document why a part was designed a certain way?
Ways to track design review action items
| Method | Good for | Main risk |
|---|---|---|
| Meeting notes document | Very small reviews with two or three items | Items aren't tied to a view or revision; nothing shows what's still open |
| Spreadsheet log per review | Small teams; easy to sort by owner and status | A new file per review; easy to lose the thread across reviews |
| General task tracker | Teams that already run their work in one | Tasks live away from the model; "done" means the task closed, not the part changed |
| Comments on the PDF drawing | Comments tied to an exact spot on the sheet | Comments stay with one file version; hard to see what's open across files |
| Change requests in PDM or PLM | Released parts with a formal change process | Heavy for pre-release iterations; reviewers outside CAD may have no access |
When this stops working
- The same comment comes up in two reviews in a row.
- Items are marked done, but the change isn't in the latest model.
- Reviews run on several parts at once and the logs live in different places.
- You can't tell, a month later, why a comment was rejected.
At that point the comments need to sit on the part and its revisions, not in a separate log beside them.
FAQ
What's the difference between a review action item and a change request?
An action item is a comment from a review, usually on a design that hasn't been released yet. A change request asks to change a released part, and usually goes through a formal approval before a new revision is issued.
Should rejected review comments be kept?
Yes, with a one-line reason. Without it, the same comment comes back at the next review and the team argues it again.
Who should close a design review action item?
The CAD owner makes the change, and the person who raised the comment confirms it. That second look is what catches a change that was made but doesn't solve the problem.
How do I link review comments to a drawing revision?
Record the revision or iteration that closed each item in the log. At release, the revision description can point back to the log so the reasons can be found later.
Internal links
- How do I run a design review when reviewers don't have CAD?
- How do I document why a part was designed a certain way?
- How do you do revision control without PDM?
Sources
- NASA, Systems Engineering Handbook, Appendix A (acronyms): https://www.nasa.gov/reference/system-engineering-handbook-appendix
Kyumi is building one place for the part, for the engineers who design it and everyone who builds it. Join the waitlist.