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




DescriptionPicture
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


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.
  1. Fill in the comment field
    • What exactly needs to be revised?
  2. Select “Ask for further revision”
  3. Click on “Change status”

Option 2: Reject change request:

  • Use only in exceptional cases!
  1. Always: Enter a reason or discuss it personally with the author.
    • Otherwise, this has a highly demotivating effect!
  2. Select “Reject change request/draft”
  3. 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.





Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article