Risk based reviewing

Reviewing is only useful if there is a risk to cover. If no problems exist with specific documentation, a review can be an unnecessary activity.

If the review is done based on lessons learned, for example from previous projects or previous iterations, you can read the article Implement lessons learned.

Next to the lessons learned, there can be explicit risks to be covered with the review. You can imagine that reviewing for correct functional flows is something else than reviewing for correct use of language or completeness of data flows.

Determine risks

Risk determination heavily depends on experience and insights of the stakeholders. The definition of importance is based on the business value, business risks, product risks and the author’s insight.

The moderator can play a role in the process of risk determination; if the moderator does not initiate this process probably nobody will, or it will be done too late. If a risk analysis is already done, this might be input as well. To get the risks clear:

  • Check with the author. Are there any parts of the document that the author would like to give extra attention to? Reasons for this might be uncertainties about parts of the document, extra high business value, critical technical descriptions or dependencies with other documents, systems or projects.
  • Skim the document. A requirements document should be reviewed for completeness, traceability, clarity and correctness, while a technical design can be reviewed for data flows or process flows. Test cases can be reviewed for coverage and implementation plans for process flows. You can imagine that reviewing the requirements on a correct data flow description will probably not lead to useful review comments.
  • Implement the lessons learned.
  • Use your gut feeling. Is a document rushed or does it use veiled language? Do you see textual errors at first glance? Does it not conform to the agreed templates?

Focus the review

When the risks are determined, the moderator investigates which roles should be able to review with an extra focus on these risks. Software testers most likely should be able to review for missing data flows and looping process flows. The business consultant will be able to review for coverage and completeness.

The focus can be overlapped or divided. Some risks can be covered by two or more review roles (overlapped), or the focus on risks can be divided over multiple reviewers.

The focus of the review, per reviewer or in general, can be communicated together with the review requests. It also implicates that if a reviewer does not perform the review, the risk coverage will be lower unless a replacement reviewer can be found.