Remember, FTR's have been demonstrated to be the #1 method for improving product quality!

A formal technical review is a method used to identify defects in an artifact before progressing to the next stage of development. Unlike system testing, formal technical reviews can take place at any stage in the development life-cycle, and as such allow for the identification, documentation and correction of defects earlier rather than later, therefore saving the company both time and money.
It is commonly accepted that not all organisations implement formal technical reviews for various reasons ranging from ignorance of the benefits they provide through to the effects they may have on time management aspects of the project. However, standards organisations such as ISO and CMM are pushing companies in the direction of formal technical reviews by insisting on some form of inspection to be in place before offering certification.

FTR's must be scheduled at least a week in advance!
Be prepared: Read the presentation in Wonderful web resources, assign roles, know your job.

Before the FTR:

• Ask for what you want.  A written form is helpful, in which you prioritize your needs, make specific requests from your reviewers about how you want them to read your materials and the kind of critique you want.
• Limit the scope of materials to be reviewed. Be clear about the quality, content, and focus of the feedback you would like to receive.  Indicate whether you want them to write a list of issues, put comments on the document, or whatever.
• Don't demand more than 2 hours of preparation time from your reviewers.
• Arrange delivery of the work product in advance so reviewers have adequate time to prepare.
• Reviewers:  Spend no more than 2 hours individually critiquing the work product.  Usually you will be asked to create an issues list, referring to the relevant QA criteria.
  

During the FTR:

• Moderator, usually QA leader, is responsible for running the meeting and orchestrating how the issues are to be presented.
• Reviewers raise issues based on their advance preparation.
• Get the big problem issues on the table early.  Don't get lost in minutely small clerical details.
• Identify problems, don't solve them.
• Focus on material, not the producer
• Elicit questions, don't answer them.
• Don't explain how your product works. An FTR is not a product demo.
• Watch the clock and keep momentum to get through all the issues in the alotted time.
• Recorder actively records all issues raised.

At the end of the FTR:

    Reviewers must make a decision:

1. Accept - the product is acceptable as is.
2. Rework - accept the product provisionally, minor erors have been encountered and must be corrected, but no additional review will be required.
3. Reject - the product has severe errors. You need to overhaul the item and schedule another FTR.

After the FTR:

•     Write up the issues list.
•     Examine the issues raised, determine which to take action on.
•     Assign each issue to someone as an action item and revise work product as needed.
•     Write review summary report:
•         what was reviewed and when
•         who were the participants and roles
•         what were the findings and conclusions (especially Accept/Reject decision)
•         the issues list, and include "action taken" for each issue raised.
•     Have reviewers sign off on summary report, indicating proper corrective action has been taken for each issue.
•     Include signed report in deliverable.

Review Guidelines

• Review the product, not the producer.
• Keep on track, don't drift.
• Limit debate and rebuttal.
• Enunciate problem areas, but don't attempt to solve the problems.
• Take written notes.
• Insist upon advance preparation.  If your reviewers aren't prepared, cancel the meeting and reschedule.
• Consider developing a checklist for the product being reviewed.

Related methods

Resources

Stewart Crawford-Hines, Formal Technical Reviews, Across All Maturities

Frédéric Boulanger, Painless Code Review from The OTTAWA SPIN.

Karl E. Wiegers, Improving Quality Through Software Inspections, Process Impact

Karl E. Wiegers, Seven Deadly Sins of Software Reviews, Process Impact

Jean M. MacLeod, Implementing and sustaining a software inspection program in an R&D; environment, Hewlett-Packard Journal, June, 1993

Karl Wiegers, Do Your Inspections Work?, A lot of useful inspection metrics are presented here, especially for insepection improvement.

Edward F. Weller , Lessons from Three Years of Inspection Data, IEEE Software, September/October 1993 (Vol. 10, No. 5).

Jason Remillard, Source Code Review Systems, IEEE Software, January/February 2005 (Vol. 22, No. 1).

Daniel M. Roy, Synergy of review techniques from PSP(SM) to Formal inspections, STPP, Inc. - Software Technology, Process and People, Inc.

Paul C. Clements, Active Reviews for Intermediate Designs , Technical Note, CMU/SEI-2000-TN-009

Collofello, J. (Arizona State University), Software Technical Review Process , SEI-CM-3-1.5

Cross, J. (ed.). (Indiana University of Pennsylvania), Support Materials for The Software Technical Review Process , SEI-SM-3-1.0

Goodies for Peer Reviews [from Process Impact]: This site provides a lot of very useful resources about inspection, including guidelines, checklist, tools and templates, etc.

The WWW Formal Technical Review Archive

Software Inspections, from CMU SE Software Technology Roadmap

Powerpoint presentation on FTR principles and concepts

NASA's Formal Review Guidebook

Software Inspection: slides from http://sern.ucalgary.ca/~chauth/courses/seng623/SoftwareInspection_v3.ppt