Review

The work should be iteratively reviewed by everyone involved throughout the initiative.

Work should be iteratively reviewed by everyone involved throughout the initiative. There are multiple layers of review:

Reviews may require returning to earlier stages (data preparation, analysis, or drafting outputs).

Standard Review Checks

Before customer review, all reviewers should:

  • Check for errors by sense checking results and comparing to existing resources
  • Proofread text to ensure factual accuracy and appropriate audience targeting

Self review

Review your own work continuously, and especially before requesting reviews from others.

Before Requesting Review:

  • Ensure all points in the QA section are addressed
  • Sense check against the agreed Problem Definition
  • Confirm customer agreement for any deviations from the PD
  • Sense check reporting outputs to avoid naïve conclusions
  • Run code with a ‘clean slate’ to ensure no local dependencies
  • Consider writing repeatable tests rather than ad-hoc testing
  • Document your code and methodology

Creating Pull Requests:

  • Create a PR on GitHub once happy with the code
  • If building on existing work, check the code diff and add comments explaining non-obvious decisions
  • Review the code diff to catch anything you missed
  • Keep PRs small and focused when appropriate
  • Request a code review once satisfied with your PR
ImportantGive colleagues sufficient time

Remember that your colleagues have other work; give them enough time to review your work properly.

Team Review

One or more team members should review all code and outputs before merging to the main branch.

Reviewer Responsibilities:

  • Sense check against the Problem Definition
  • Pull the code locally and run it from a ‘blank slate’ state
  • Add comments and suggestions to the PR
  • Ask the code author for clarification when needed
  • Arrange a call to work through the PR together if several questions arise

Critical Friend Review

The Critical Friend provides independent peer review throughout the project.

Review Process:

  • Request feedback frequently - Always before customer reviews
  • Validate against the Problem Definition - Ensure alignment with agreed scope
  • Review from multiple perspectives:
    • As the customer viewing outputs
    • As a developer using the codebase
  • Review holistically - Not just the code, but the entire work
  • Discuss complex feedback - Arrange calls when needed

Customer Review

Involve customers frequently throughout the initiative.

During Development:

  • Share draft outputs for review in their own time (not just screen sharing)
  • Be available for calls to discuss their feedback
  • Address questions and suggestions openly

Final Presentation:

When the initiative is completed, present findings to the customer and:

  • Ensure they understand how to use interactive elements (e.g., dashboards)
  • Discuss potential for future related work
  • Send a follow-up survey (if appropriate) to confirm all needs were met