Peer Review Process

Policy

For major deliverables, technology plans, RFPs, procedure documents we will under go a full review.  For other documents, the author must ensure they are proof-read by another staff member before delivery.

Time for proof reading should be taken into account when writing a document.

Review time will be included in new scopes of work - 4 hrs/major deliverable.

Time that is used for review but goes over the scoped amount should be accounted for under the project code but as unbillable.

Purpose

The purpose of peer review is three fold:

• To increase the quality and consistency of documents we deliver to clients.
•  Peer learning opportunity for consultants.
• Develop consensus around our consulting methodology and recommendations.

Proof Reading

Criteria

Any deliverable that is not covered in the Peer Review process.

Roles & Responsibilities

Proof-reader

• Reads the document and comments on areas
  
  • That are good.
  • That they think should be adopted as standard.
  • Where they do not understand the document (or don’t think a lay person would).
  • With missing or outdated information.
  • That do not follow best practice (as we develop best practice).
  • Spelling, style, formatting and calculations if appropriate.
• Reviews the work and returns with comments within the time agreed to.

Author

• Asks a member of Tech Services (eventually we would like to include all of Consulting Services) to review the work with particular regard to:
  
  • If the author thinks there is a weakness in the work, they should choose someone they think can supplement that.
  • Should make sure not to always choose the same person.
• Specifies the time line for review and sticks to it.
• Reviews comments and incorporates them as they see fit.
• Make a note of the types of comments received in order to guide professional development goals and improve future documents.
• Brings ideas for standards or common issues that were brought up to the team for group consideration.

Procedure

Author identifies and gains commitment (with time line) from proof-reader.Author sends document to proof-reader on the day agreed upon.Proof-reader reads documents and makes comments (whether notes on a hard copy or  in an electronic format is to be agreed upon by the reader and author).Proof-reader returns document to author within 24 hours.Author decides whether to incorporate changes.

Peer Review

Criteria

For full tech plans, RFPs, policies and procedures manuals,  presentations or other significant deliverables.

Roles & Responsibilities

Reviewer

• Reads the deliverable in advance.
• makes comments on areas that are good, that they think should be adopted as standard, things they don¹t understand and suggestions for improvements.
• Attends the review meeting.

Author

• Chooses the reviewers with regard to:
  • If the author thinks there is a weakness in the work, they should choose someone they think can supplement that.
  • Should make sure not to always choose the same person.
  • From the Tech Services Group (but may include all of Consulting Services later or if particularly relevan).
• Leads the review process.

 Facilitator (Consultant’s Supervisor)

• Ensures the tone of the meeting stays positive, focused and supportive of all staff.
•  Takes notes on areas that we should revisit as a team. 
•  Takes action on issues as necessary.

 Procedure

 At least 14 days before client deadline:

• Author identifies 2 reviewers and arranges a review session with them and the facilitator.
• Author arranges meeting venue.

 1 business day before the review meeting:

• Author send deliverable to reviewers and facilitator.

 Before the review session:

• Reviewers and facilitator read document.  Should look for
  
  • Areas that are good.
  • That they think should be adopted as standard,
  • Things they don¹t understand
  • Suggestions for improvements.

Note: Spelling, style, and formatting suggestions, and calculation errors can be can be communicated in advance.

During the meeting

Meetings will be no longer than 45 minutes (ideally we’ll get 4 day tech plans down to 20 -30 minutes in the end).

Author walks the group through the document.

Reviewers make comments on what they’ve previously noted and anything else that comes up. 

Facilitator intervenes to keep the meeting moving and focused.

Author makes note of types of suggestions made for future development goals.

Facilitator makes notes on issues that deserve further group discussion.

After the meeting

Author decides what to incorporate and edits the deliverable. 

If necessary, Author gets the document proof-read again.

Author sends document to client.

Reviewers reflect on best practices!

Author publishes the meeting notes.

Facilitator acts on issues that affect wider audience (i.e. new best practices, standards issues, gaps in group knowledge).

We will review the procedure after 5 full reviews to see what we have learned, whether we can make it better, shorter etc.