Structured Reviewing – Execution

The execution phase is the ‘real’ reviewing phase.

It starts with an announcement from the moderator to the reviewer based on the project planning. The announcement is meant as a reminder to the reviewers to plan some time for the execution of the review.

When the document is ready for review, the author sends the document to the moderator. The moderator takes care of the rest of the review process, facilitating the reviewers and author, reminding and chasing and thanking them.

1. The author sends a product to the moderator
2. The moderator performs an intake and sends out the review requests
3. Reviewers review the product and fill a standardized review form
4. The moderator merges all received comments and sends it in one batch to the author
5. The author reworks the product and reacts on the comments (with a status and an optional remark) When done, the author sends the reworked version and the reaction on the comments to the moderator.
6. The moderator performs an intake and sends out the approval requests.
7. The reviewers approve or disapprove the rework
   
   

The author sends a product to the moderator

After the document is peer reviewed (to take out possible major issues), the author sends the document or a link to its location, to the moderator. This can be accompanied by some details like extra reviewers, a comment for the reviewers or some referred documents.

The moderator performs an intake and sends out the review requests

Before sending the document for review, the moderator performs an intake. This intake is meant to check for issues which distract the reviewers from performing a review. Missing page numbers, incorrect version numbering, empty chapters, ambiguous language etc. The intake should take no more than 5 minutes; the moderator is not a reviewer.

When the intake does not pass, the moderator requests the author to fix the issues. If the intake is passed, review requests can be send out. The review request at least contains:

• The document to be reviewed (preferably in pdf including line numbers)
• A (preferably personalized) review form
• The document name and version
• A review deadline (date + time)
• The expected time lines for the rest of the review phase (expected rework date, expected approval date)
• A marking which shows if the reviewer is optional or mandatory
• Optionally: a list of reviewers
• Optionally: specific assignments
• Optionally: check list
  
  

Reviewers review the product and fill a standardized review form

The reviewers review the document(s) within the given time lines. If it can not be done within time, the reviewer informs the moderator. Together the moderator, reviewer and author can decide what to do:

• Search for an other reviewer with the same role who can perform the review in time
• Stretch the deadline for all reviewers
• Stretch the deadline for one reviewer (author starts the rework but knows more comments will arrive)
• Accept the risks by removing the reviewer from the review list. (But still include the reviewer in the approval phase!)
• …
  
  

If the reviewer is done with the review, the form is returned to the moderator. The moderator will check if the form is filled completely and that the comments are globally clear, respectful, complete, in the agreed language etc.

When the deadline comes close, the moderator will send out a reminder to all who did not respond yet.

The moderator merges all received comments

After the review deadline the moderator merges all comments into one overview. Double comments are grouped, the comments are sorted in chronological order (preferably based on line numbers) and the merged comments are send to the author for rework.

The rework request contains:

• The (line numbered pdf) document
• The merged comments
• A rework deadline
• A remark that states that the reworked version and the answered comments must be returned to the moderator.
  
  

The author reworks the product

Based on the comments, the author reworks the document where needed. A response to each review comment is wished, especially in the case of a rejection. This way it will be easier for the reviewers to see what happened with their comments.

Each comment gets a state: Accepted, Rejected or Open. The Open comments need further discussion or are to be picked up at a specified (later) moment. Accepted comments have lead to rework, Rejected comments are not reworked.

Sometimes it’s useful to use “track changes” or color markings and strike trough to mark the changes. This is up to the project.

The moderator performs an intake and sends out the approval requests.

When the moderator receives the reworked version and the reaction on the merged review comments, the moderator performs a short intake again. This intake is aimed at checking that the correct version of the reworked document is send and to do a random check on the rework that is performed. This way the moderator can know that the document is really fit for the approval phase.

When the intake does not pass, the moderator requests the author to fix the issues. If the intake is passed, approval requests can be send out. The approval request at least contains:

• The document to be reviewed (preferably in pdf including line numbers)
• The merged review comments including the status and author’s reaction
• A deadline (date + time) for the approval
  
  

The reviewers approve or disapprove the rework

Next step: Approval

Please insert in this col ‘Sidebar Inserter‘ and select your sidebar(s).