The reviewer gets lost in the review and can no longer see the wood for the trees. The main objective of the review would be to check the correctness and completeness of the artifact. The following aspects can distract from this main objective:
Communicate the main objective of the review to the reviewer, i.e. correctness and completeness. This can be done in a training course and in the work instructions of the review.
In addition, the aspects to be reviewed can be assigned to individual reviewers. For example, formal aspects (coding rules, naming rules, requirement rules...) can be checked efficiently by a single reviewer, who then does not need to have the overview. Different content-related areas of the artifact can also be distributed among different reviewers.
Too much or too little is checked because it is unclear what should be checked. Only changes since the last review or everything?
Clearly define the scope of the review in the review documentation, create a formal review invitation with a clear definition of the scope.
Reviewers have very different quality requirements for artifacts.
Define qualitative requirements and guidelines for artifacts (document, code, ...). Rotate review partners so that a common understanding of the required quality is established over time.
There is no check for completeness, no check for what has been forgotten. It is usually easier to check the consistency of the existing material than to find out what is missing or has been forgotten.
Deliberately check the artifact for completeness in a first reading.
Create a checklist with topics that must be included in the artifact.
Check whether higher-level documents (e.g. system requirements when reviewing software requirements) have been fully mapped. Requirements traceability helps here.
A review should be performed by a reviewer who had nothing to do with the creation of the artifact. If the "entire project team" was involved in the creation of the document (e.g. requirements or architecture/design), where can we find an independent reviewer?
You can appoint someone for each artifact who does not work on it. Or even better, you can involve an independent reviewer from outside the project team. The disadvantage of the "external" solution can be that the reviewer has too little domain knowledge of the specific project and is therefore not very efficient. On the other hand, they can contribute new ideas and impulses to the project.
Or you can use at least two reviewers to ensure that at least the four-eyes principle is fulfilled everywhere.
The content requirements are not clear to individual reviewers. They only exist in the minds of some of the reviewers and sometimes also the authors. As a result, the content requirements are usually not consistent.
First document the higher-level requirements, e.g. before the software design review clarify the requirements specification for this software.
One of the most common problems is focusing on formal aspects instead of content. Formal aspects (e.g. correct formatting, correct revision history) are important, but content is more important. However, checking the formal aspects is usually easier (and takes less time) than dealing with the content.
Teach reviewers that content is more important than form. This can be done in a training course and in the work instructions of the review.
In addition, the aspects to be reviewed can be assigned to individual reviewers. For example, formal aspects (coding rules, naming rules, requirements rules...) can be checked efficiently by a single reviewer. Someone else can then take care of the content.
More attention and time is given to the correct formal process than to the content review.
Communicate to the reviewers that the content is more important than the formal process. This can be done in a training course and in the review work instructions.
Projects? Ideas? Questions? Let's do a free initial workshop!
No Comments