Formal Review - Checklist

Modified on Wed, 2 Apr at 12:17 PM

In this article, you will learn:

The basics of formal review
Step-by-step process of formal review
What you should pay particular attention to
Differentiation from content-related approval

The basics of the two-stage Q.wiki release workflow can be found here: Function of the document approval workflow

Q.wiki guarantees the four-eyes principle through the two-stage release workflow. The formal release described here takes place after the content release, by a suitable person (e.g. QM team or Q.wiki implementation team). This person + deputy must be a member of the QM group. The different right groups in Q.wiki can be found here: Detailed overview of rights concept Q.wiki

Here, you can find out how you assign users to different groups: Add or remove users from Q.wiki groups

	Description	Picture
1	Previous step: Content approval
2	If necessary, show comparison with released status Only available if a released status already exists i.e. not for the first release of the draft design
3	Check whether the correct template has been selected: Is the content really a process? Yes: There are interfaces (column “Responsible”) Yes: The process refers to a longer period of time Yes: Scope and complexity justify the “process template” Is it a work instruction? Yes: Only one person carries it out (“Responsible” column is unnecessary) Yes: Short period of time
4	Manually change template if necessary Add or remove columns Change metadata so that page header is displayed correctly
5	Check roles: Is the role designation correct? Have new roles been used that have not yet been created in the Q.wiki roles? Create a new role and insert it into the page using the widget
6	Formatting and spelling check Correct spelling/typing errors directly Headings in the desired format “Heading 1 or 2”? Text in “Normal”
7	Check links and add upstream and downstream processes Links within the process description / work instruction Do the links make sense? Are there other pages that you know of that could be linked?
8	Check flowchart Comparison Flowchart for detailed description If necessary, delete flowchart area if it has not been created/is not needed
9	Editorial review Tipps for creating content in Q.wiki - Process description vs. Work instruction Is the page name correct, active and formulated conclusively? Has the person responsible for the page been selected correctly? Have redundancies occurred in Q.wiki as a result of changes?
10	Assign standards in edit mode in the metadata Have all the requirements of the standard been taken into account? Have the guidelines been followed?
11	Decide whether formal approval can be granted: Option 1: Ask for further revision only if an employee wants to make further changes before approval is granted clarification is needed more extensive changes/revision is necessary Attention: Smaller changes such as e.g. corrections of spelling mistakes can and should be made directly by the formal reviewer. This will set the page status back to “Change request” and everyone can edit it again. In addition, the employee who requested the release will be informed. Fill in the comment field What exactly needs to be revised? Select “Ask for further revision” Click on “Change status” Option 2: Reject change request: Use only in exceptional cases! Always: Enter a reason or discuss it personally with the author. Otherwise, this has a highly demotivating effect! Select “Reject change request/draft” Click on “Change status” Option 3: Issue formal approval If necessary, fill in the comments field The employee who initiated the approval receives this comment with the notification.