The Quality Assurance (QA) Review allows your company technical experts, engineers, and stakeholders to review documentation deliverables and other documentation during a project. The aim of the review process is to ensure that the correct information is delivered to the right people so they can efficiently perform Quality Assurance Reviews. The review results can then be efficiently communicated with the suppliers or contractors.
The document review work process is managed by three workflows.
-
The MDR deliverable submittal workflow submits the documents and routes them to a document review workflow, with an option to get a document controller check. It then triggers the QA Review Verification workflow.
-
The QA Review Verification workflow checks if the document needs a review. It then triggers the QA Review workflow.
-
All the documents received on a deliverable submittal are verified and sent to the QA Review workflow if that revision has been issued for an issue purpose that has not already been reviewed.
A planning submittal creates a document delivery schedule that consists of reserved
documents with associated delivery milestones for a given issue purpose, on a planned
date.
Any user with a document control role gets the consolidation step by default. The documents route to this recipient if the review matrix or the review plan does not have the reviewers defined. The consolidator then assigns any required reviewers.
Set the review and consolidation periods
The review and consolidation period are properties on the contract objects. The review and consolidation period can be set for each contractor.
-
Find the contract in the project and update its properties.
Relate the step definitions to set the column item for review progress
The SDxStepDefPropagateProgress relationship helps to link two step definitions where completion of one or more parallel steps of the End1 step will set progress percentage on the End2 step. The delivered step definitions are STP_SCLBProjComsConsolidateDocReviewResponses and STP_SCLBProjComsPerformReview. The End 2 step definition is related to both the step End 1 step definition and the progress step. This relationship can have multiple recipients; and the progress is calculated according to the review completion/rejection/waived off and/or if any new recipients are added.
To use your defined step definitions other than the delivered step definitions, you need to manually load the step definitions using xml load files. For more information, see Loader.
Details of internal process steps
The following diagram shows all the steps in the QA Review workflow.
A business administrator must relate the contract to a review matrix while creating
the contract.
-
The type of review (either matrix-based or review plan-based) is chosen by the user with a business administrator role at the time of creating or updating a project, and the review recipients are fetched from the matrix or the review plan accordingly.
-
On document submittal, if the contract is not related to a review matrix, the system sends Select Matrix on Contract step to the user's (with a global document control or document control role) To Do List to update the contract. After relating the contract to a review matrix, select Retry, a method available in the Actions menu of the step, to route the documents to the recipients. For more information on how to configure a review matrix, see Configure SDx document review matrix.
-
A consolidator is set from the review matrix related to the contract, even if the Generate Reviews by Matrix? on the project is not selected. If the document review matrix does not contain this information, the consolidator is set from the consolidation step of the workflow.
Any user with a document control role gets the consolidation step by default.
-
If any of the renditions fail to generate and attach, the system directs the workflow to the Correct failure step.
The steps that make up the workflow are described in the following table.
If you choose to edit the workflow, do not remove any steps marked as mandatory.
For information on how to upgrade a workflow template, and the changes that have
been made in various updates, see Upgrade the QA review workflow template.
|
Step name |
Description |
Mandatory? |
Comments |
|---|---|---|---|
|
SCLBProjComsSetPrgMilestoneDates |
Creates or updates a document milestone for the document issue purpose. Sets the milestone dates on the document revision. The next step is SetRevisionActualReceivedDate. |
No |
|
|
SetRevisionActualReceivedDate |
Sets the document revision receipt date. The next step is SCLBRelateLatestIssuePurposes. |
No |
|
|
CLBRelateLatestIssuePurposes |
Sets the latest issue purposes on the document revision. The same revision may be issued more than once, for a different issue purpose each time. The next step is Branch based on matrix not set on contract. |
No |
|
|
Branch based on matrix not set on contract |
Routes the workflow to the Select Matrix On Contract step if a matrix is not set on the contract. Otherwise, routes the workflow to the SCLBIdentifyReviewers step. |
No |
|
|
Select Matrix On Contract |
Allows a user with a Global Document Control or a Document Control role to select a matrix on the contract if the Generate reviews by matrix option is selected on the project. The next step is Branch based on matrix not set on contract. |
Yes |
This step is needed to assist the users to select the matrix if not present on the contract. |
|
SCLBIdentifyReviewers |
Identifies the reviewers based on the recipients defined in the matrix or the review plan item. If accepted, the next step is Delink markup layers to document. If rejected, the next step is No review required. |
Yes |
This step is needed to assign the users. For the matrix and the review-plan based configurations, the reviewers must be collected and assigned based on this step. |
|
No review required |
Exits the workflow. This is the last step of the workflow. |
No |
|
|
Delink markup layers to document |
Delinks any previous document review markup layers. Only layers added or modified during this review are preselected for rendition creation. The next step is SetMilestoneStatusToInReview. |
No |
|
|
SetMilestoneStatusToInReview |
Changes the status of the milestone to In Review. If this step is removed, the milestone status will not be modified. The next step is SetRevisionPlannedReturnDateFromContract. |
No |
|
|
SetRevisionPlannedReturnDateFromContract |
Sets the planned return date for the revision based on the contract. The next steps are SCLBProjComsSetStepTargetDatetoReviewer and SCLBProjComsSetStepTargetDatetoConsolidator. |
No |
|
|
SCLBProjComsSetStepTargetDatetoReviewer |
Sets the due date for the review steps. The next steps are Perform QA Review and Document receipt notification. |
No |
|
|
SCLBProjComsSetStepTargetDatetoConsolidator |
Sets the due date for the consolidation step. The next step is Perform QA Review Consolidation. |
No |
|
|
Perform QA Review |
Allows the user to review the document revision and create any markups. |
Yes |
This step is needed if multiple reviews are expected. If a single person is performing the review, the consolidation step can be used for review and consolidation of markups. |
|
Document receipt notification |
Informs the user who registered an interest for a document revision that the document revision has been received. This is an acknowledgment step. |
No |
|
|
Perform QA Review Consolidation |
Allows the user to review the document revision, consolidate the reviews and manage the markups created by other reviewers, and set the return code on the document. The next step is Validate Review Supporting Information. |
Yes |
This step is needed to filter out unwanted items and share appropriate review comments. |
|
Validate Review Supporting Information |
Checks whether there is supporting information. The next step is SetMilestoneReturnCode. |
No |
|
|
SetMilestoneReturnCode |
Sets the milestone return code to what was set by the consolidator. If this step is removed, the milestone return code will not be set. The next step is SetMilestoneReviewedRevision. |
No |
|
|
SetMilestoneReviewedRevision |
Sets the milestone reviewed revision. If this step is removed, the milestone reviewed revision will not be set. The next step is SetMilestoneStatusToCompleted. |
No |
|
|
SetMilestoneStatusToCompleted |
Changes the status of the milestone to Completed. If this step is removed, the status of the milestone will not be modified. The next step is Auto Close Unfinished Reviews. |
No |
|
|
Auto Close Unfinished Reviews |
Closes any review steps that are assigned but yet to be started. The next step is Auto Close Open Review Steps. |
No |
|
|
Auto Close Open Review Steps |
Closes any review steps that are in progress. The next step is Auto Close Open Information Review Steps. |
No |
|
|
Auto Close Open Information Review Steps |
Closes any review steps that are for information only. The next step is Assign Initiated Actions To Workflow. |
No |
|
|
Set Initiated Date On Actions |
Sets the initiated date on the actions raised. If this step is removed, the initiated date on the actions raised will not be set. The next step is Set Initiated User On Actions. |
No |
|
|
Set Initiated User On Actions |
Sets the initiated user on the actions raised. If this step is removed, the initiated user on the actions raised will not be set. The next step is Assign Rejected Actions To Workflow. |
No |
|
|
Assign Initiated Actions To Workflow |
Assigns any review actions to their workflow for issue. If accepted, the next step is Set Initiated Date On Actions. If rejected, the next step is SCLBPropagateRecipientForCorrectFailures. |
No |
|
|
Assign Rejected Actions To Workflow |
Assigns any rejected actions to their workflow for closure. If accepted, the next step is GeneratePDFRenditionsForDocument, If rejected, the next step is SCLBPropagateRecipientForCorrectFailures. |
No |
|
|
GeneratePDFRenditionsForDocument |
Creates a single PDF rendition of the document, including the markups that were selected by the consolidator and any attached files. This PDF rendition remains available even after the review is completed.
If the PDF is successfully created, the next step is SCLBProjCommsPropagateRecipientSubmittalUser. If the PDF generation fails, routes to SCLBPropagateRecipientForCorrectFailures. |
Yes |
This step is needed as, otherwise, the review comments cannot be shared with the submitter. The markups (selected by the consolidator) are not visible to the submitter (contractor) unless a rendition is created. |
|
SCLBPropagateRecipientForCorrectFailures |
Allows the consolidator to correct the issues that caused the PDF generation to fail. The next step is Correct failure. |
No |
|
|
Correct failure |
Allows the consolidator to correct the issues that caused the failure. The next step is Assign Initiated Actions To Workflow. |
Yes |
This step is needed as, otherwise, the issues cannot be corrected and the review comments cannot be shared with the submitter. |
|
SCLBProjCommsPropagateRecipientSubmittalUser |
Sends a completion notice to the user who submitted the documents for review. The next step is Completion Notice. |
No |
|
|
Completion Notice |
Allows the contractor to complete the review process. This is an acknowledgment step. This is the last step in the workflow. The next step is SetRevisionActualReturnedDate. |
No |
|
|
SetRevisionActualReturnedDate |
Sets the return date on the document revision. If this step is removed, the return date on the document revision will not be set. The next step is SetMilestoneActualReturnedDate. |
No |
|
|
SetMilestoneActualReturnedDate |
Sets the return date on the milestone from the document revision. If this step is removed, the return date on the milestone from the document revision will not be set. The next step is SCLBProjComsCheckIsDocAlreadyReviewed. |
No |