While the Design Review type/process was a great enhancement, additional capabilities would benefit reviews that may span a long time, include large datasets, and include complex action items and need processes.
Problem Statement: Generally, for large system reviews - we have hundreds of documents, dozens of reviewers, and multiple disciplines involved in a review. While action items and annotations provide a mechanism to record "issues" against reviewed objects, there is no good way to track the relationship between annotations/actions, their associated objects, and work that needs to be done/tracked & have its own workflow. Specifically, with action items, there is no way to force interaction. It is just the assignee's statement of what is being done. To further complicate this, reviews may last anywhere from a meeting or two, to a year or more ( a recent lifecycle review for a major system closed out its last Review Discrepancies a year after the review started - and they had to manually track all of this with a spreadsheet)
1) Provide for a way to allow action items to have a "Process" - This would require action item attributes to be fully subtypeable, update/modify the action item view table to show IBA's, and the ability to modify the import/export template to modify action item IBA's
2) Develop a type/subtype of an object similar to a problem report to track issues against a review and/or subsets of review data. These need to have their own OIR's, lifecycles, workflows etc, be shown in the context of the review, and states synchronized when the review closes.
In the meantime:
I have started to whiteboard a process that would use a subtype of Problem Reports and create them against the "Review" and related objects. There are some limitations to this. One that I am struggling with is synchronizing the state of the "Discrepancy" when a review is closed - similar to how PR/CR states get synchronized to "Resolved" when the CN is closed