Periodic Reviews are a necessary part of any formal process. They are a fundamental part of ISO-9000 and other design maturity methodologies. Like checklists, they normalize the work efforts and provide a concrete method for feedback. If they are done properly, they have tremendous value. Done poorly, or for the wrong reasons, they are somewhere between a waste of time and an outright hazard.
The best overall review system for design/development projects is MIL-STD-1521B, which covers an entire system of reviews for a large, complex project. Although this spec is out of print, it is public domain and available at many sources for free, I got mine here. The review structure is classic and scaleable. There is a lot of practical guidance in this document. NAVAIRINST 4355.19D has a great deal of detail and is where to go if you really want to get a by the numbers review process.
Most programs do not implement the entire 1521 or 4355 process. That is unnecessary except for the largest, most complex systems, like moon launches or sports stadiums. Instead, study the organization and information for each review, and implement the reviews that are applicable to your project. You may only need one review. Of course, your contract may require some number of these, especially if they are for the DoD. If so, there are probably Data Item Descriptions (DIDs) that specify the content. The DIDs also provide a bucket to bid the effort required for each review, and are good to cite as backup in your Basis of Estimate.
For a formal review, with an audience and a presenter, plan about 12 slides/hour, 4-6 bullets per slide. Treat the bullets as reminders of what to say, don't read them word for word. They are also the notes you want the audience to take with them. If there are to be diagrams or other graphics to be studied during the presentation, I recommend two projectors side by side. One for text, one for drawings/reference, especially if there are new people in the audience. It is a good break to invite people out of the audience to more closely examine a drawing or table. Present material for about 45 minutes, then break to closely examine and markup, then summarize and resume. Makes long reviews more tolerable.
If you are showing drawings on a second projector, consider projection on a white marker board. Comments can be written directly on the board modifying or referencing the information displayed on it. For instance, fasteners on a packaging concept, or placement of components or annunciators on a panel or user interface. During the break, the reviewers can mark the drawing, and you can use a different color marker to circle the comments as addressed. Then take a picture with your cell phone. Easier to work with than a large paper plot. There are applications that will let you do this digitally, but I have found these, like other AV equipment, are notoriously unreliable. Reviews cost a lot per minute, stay away from anything that may not work.
Concentrate on showing graphics, tables, and other visual subjects. Try to only present setups and summaries using words. At a power conversion conference, I was told that if I didn't show a schematic by the third slide, the audience would leave, and I saw it happen. Too many words will kill a slide, and a presentation.
Presentations with remote attendees are a given. BE SURE to check the equipment for these 30 minutes early. In my experience, 20% of the time the remote version of the presentation was not viewable as planned at the start time. Permissions have to be updated, drawings did not display properly, apps that worked last time needed to be updated, etc. So dry run your presentation with someone off site if you can, or ask your admin to do it. It is an additional cost, but again, if you have 20 people in the room, what is the cost of a 15 minute delay?
Don't overlook meeting security. One company I worked for had one call in number for everyone, and never changed it. That means that if I competitor got a hold of it (and it was passed out quite a bit), they could listen in on all of our multisite reviews - providing tremendous intelligence on our plans and situation to anyone who cared to listen. Talk to your IT people about the security needed and provided.
Given that web techniques have provided the ability to tune in on practically anything, anywhere, anytime, do we need formal reviews? Perhaps we don't need the packages anymore, but we do still need the review as a mark point. The purpose of a review is principally to state "This is our current state, this is what we are going to do in the future. Now is the time to comment." Even without a presentation, a review is a valuable marker point in the progress of a project.
Reviews are still a useful method of making sure that a subcontractor or division is spending time on YOUR project, and not being diverted to finish some other project. That is why these reviews are typically linked to progress payments. Review unsatisfactory? Do it again, and show progress this time, to get the progress payment.
I recommend that the modern internal review be performed as a teleconference with the responsible players to go over a project review website. Attendees view the website remotely, and immediate interaction is via phone or Skype type application. That way the users can punch around to look at things, which most people want to do anyway. Errors can be corrected as the review progresses, but actions should be recorded and worked. Don't try to design a solution in a general review.
It is important to keep records of reviews for ISO and other modern processes. For an internal review, I recommend publishing a form with the topics relevant to the review and using it to capture the minutes. An example of such a form is attached below, for a modification of a standard product for a specific customer per a contract. Yours will certainly be different, but you get the idea. Just creating and publishing this document is a useful exercise.
Placing this minutes template on the website (or at least, the agenda) prior to the review allows the users to enter data before the meeting, which speeds things up considerably. This also allows the participants to comment the agenda, to enter issues they would like to cover during the review.
These reviews are typically one man shows where the Project Engineer, System Engineer, or Program Manager presents the status of the project/program using formal methods. A good company policy will make certain slides and summaries standard, since the purpose of the review is for management to compare projects. If you belong to a functional organization, your presentation approach should be standardized to enable this. If not, the review will sag, and management will (probably rightly) conclude that your department is not being completely open about the status of the projects.
Your subcontractors should also have a review system in place, no matter how basic. Put these in the Statement of Work to the contractors, and spell out what you will be looking for. Makes a good point for progress payments in longer design cycles.
If you are doing contract work for someone, and they are managing many integrated subcontractors, they will want you to follow their format. This makes it easier for them to understand and compare. If you are wondering why they want you to spend money on putting something in their format, that is why. It makes it easier to review many programs.
This is a review performed by an individual or group accomplished in the technical area, and familiar with the type of product, but who is not currently involved in the detail of the design or execution. The importance of a fresh set of eyes cannot be overstated. These reviews tend to pick up gross errors, usually a by-product of groupthink. The expert will presumably be immune to the pressures and joint assumptions of the design team.
The expert is looking for errors, but also looking to understand why unusual or complex approaches have been chosen - what was the requirement, how will it be checked. It is expected that some redesign, or at least more analysis will be the outcome of these reviews. That is why you are doing them. Be suspicious if they find nothing of interest. Experts rarely agree.
This review is performed by an external expert, using the documents that are controlling your activity, to verify that everything called for in the documents and processes is being performed as required. This has a kickoff, interviews and analysis by the external expert(s), and an final report. This may be an audit of any of the quality systems you have in place, but typically is of either the Process or Specification compliance mechanisms. What other functions have quality systems? Look here: Priorities. They can all be audited in the same way as Process compliance.
Functional Configuration Audits (FCA) and Physical Configuration Audits (PCA) are in this category. These audits employ an expert that reviews the controlling documentation and verifies that everything called for in the specifications has been implemented and verified per the requirements, whether an operational requirement or test (FCA) or a physical delivery like a drawing package, software package or physical article (PCA).
External reviews are to convince the customer that everything asked for is under control, and all problems are understood. The rules of customer communication apply. This "customer" may actually work for the same company as you, depending upon your organizational structure and type of product. The most important aspect for you, with the knowledge of the customer, to bring out the remaining issues between you and the customer and disposition closure. You will have an audience there that may be able to help with closure on many of them. Since this may be the only window into your design by some of the customer representatives, you must present enough detail to allow them to understand the approaches.
Some customers may have a Data Item Description that specifies exactly when and how each review will be performed, for instance calling out sections of 4355. Sometimes it is their own process. Look for this, it very embarrassing to find it after the fact. In the old days, we were required to submit the actual slides 30 days prior to the review. This was to allow the customer to make sure that the information to be presented suits his purpose. That is an outrageously long period of time these days. Instead, I recommend submitting the slide titles. These reviews indicate to your customers company at large how good a job your customer COG is doing. So they may want to have an input into what is presented.
For really big reviews, I broke the review into sessions, like a conference. The first day was the overall system and other management aspects of the program. The second day had sessions: Manufacturing, Reliability, Electrical Design, Software Design, Packaging, Quality, Test, Requirements, Finance, etc. These ranged from one to four hours, and ran in parallel. We then gathered on the third day to go over the actions out of the reviews and summarize the results. This was much more efficient and engaged the customer reps much more fully. This could easily be implemented on large software or construction elements.
Internal reviews are completely different from external (customer) reviews:
Little explanation of the company structure and goals is required - your peers already know this.
Customer special requirements and interpretations must be presented to be sure that attendees understand the situation - a customer wouldn't need this.
Serious issues, including those with no known acceptable solution are discussed and dispositioned against resources. You would never present a problem without a solution to a customer. But these are the most important ones to present at an internal review.
Finance and manloading are in acceptable topics. These would never be presented to a customer.
An internal review is your chance to present your biggest problems to your management and staff, with the goal of applying the knowledge and resources of the company to help you. The fluff and motherhood stuff you find in customer reviews is not needed, and brass tacks are presented. They are also usually shorter, and more likely to have conflict.
Internal reviews are a big part of the Meritocratic system, but not embraced in the Colonial system. If there is a serious problem to solve, Meritocratic managers will want to bring in as many minds as possible to address and solve the problem. Colonial managers will want to carefully closet and control discussion of the problem, and the alternatives. Be sure to pick the right technique for your organization.