Spence Green

Over the last several days, my project has gone through the Critical Design Review (CDR) process. Although the format differed from the CDR that I had organized in February, the presentation problems, organizational needs, and technical outcomes were similar. CDRs have become a staple in most engineering organizations, and government contractors in particular must hold them.

In my experience, most project teams scramble to meet the CDR deadline, often submitting work that is incomplete or unconsidered. This circumstance harms both the team and the customer. For example, our group tried to meet a program management quota of 30 slides per person. The “fluff” did not escape the customer’s notice, damaging the team’s credibility.

Instead, I suggest that CDR teams emphasize quality over quantity and use the CDR forum to educate the customer and capture requirements. Think of the CDR in as:

• A pre-validation meeting: Demonstrate analytically the design’s compatibility with the current requirements set. Eventually, the customer will validate the code against the requirements. Show him that you have integrated all of his needs into your current design.
• A training exercise: Have you ever listened to a fellow developer describe a complicated algorithm or component? That guy is working on your system, but you don’t easily understand his approach because you aren’t familiar with his area of the code. Now think of the customer. He must digest the entire design with NO experience in any part of the system. Use the CDR to train the educate the customer, not overwhelm him. Other members of the engineering team will benefit as well, for their awareness of the system will increase.
• A requirements capture meeting: Each presenter should identify a list of design issues and requirements questions prior to the presentation. During a CDR, you have the customer’s undivided attention. Instead of lecturing him, ask him questions and make him think.
• A technical design forum: The team’s engineers should attend every CDR brief. Require them to take notes and submit evaluations. A CDR exists within the same genre as the Fagan inspection and the requirements review. Treat it with the same formality.

Below is a list of guidelines for maximizing the CDR’s benefits. Both project managers and engineers can use these suggestions, for a well-integrated team blurs the distinction between these two roles.

Planning and Preparation

• Don’t use a boilerplate checklist: A CDR’s main objectives are gathering and disseminating information. Circumstances dictate the best methods for achieving those ends. This is not brain surgery. Develop a considered approach based on the project, avoiding “Big M” methodologies.
• Emphasize quality over quantity: Don’t use slide quotas. Treat slides like money and spend them wisely.
• Use the 4-6 rule: Each slide should have between 4-6 bullets, and each bullet should have between 4-6 words. If a slide requires elaboration, talk through the slide using a whiteboard or create a handout for the audience.
• Print the Presentation: Every participant should have a bound copy of the presentation. In this way, you may include complex drawings and figures that may be difficult to read on the projector.
• Plan an internal CDR (iCDR) or “dress rehearsal”: The team should go through the entire CDR sequence together at least a week prior to the real conference. The presenters should speak as if giving the real presentation and the audience should not interrupt the talk unnecessarily. The latter observation brings us to…
• Identify a moderator: CDRs inevitably stall under the weight of digressions. Identify a moderator keep the meeting moving.
• Identify a scribe: It is too difficult to compile a piebald stack of scribbled notes after the meeting. Identify a scribe, give him a laptop, and require him to enter observations formally into Telelogic DOORS or an equivalent tool. Important comments and decisions are often lost immediately after a discussion takes place. Instead, capture all of the comments (annotating them by speaker and slide number) and present them as a “Minutes of Meeting” document to the customer.
• Assign a Master Reviewer: Select a technical leader with broad system knowledge to review all of the slides prior to the iCDR. The reviewer should eliminate redundancies, identify major themes, and resolve formatting inconsistences. The body of slides should reflect a coherent picture of the system. A single mind can evaluate the team’s work with respect to this objective.
• Detail = Credibility: Everyone knows that block diagrams, state charts, and data schemas require time and effort to develop. Include them in the presentation. Together, they show that the team is operating at a satisfactory level of precision.
• Think about Food: Don’t order the usual corporate garbage: donuts and coffee for breakfast, sandwiches and chips for lunch, Coke in the afternoon. Set the tone for the day with food. Start the day with fresh fruit, toast and French jam, fresh juices, and smoked salmon. Stimulate the body with healthy food, then stimulate the mind with a careful presentation. Impress the customer.

Execution

• Choose good communicators: No leaning on furniture. No staring at the projector screen. Use vocal inflection. Discard nervous habits. Dress well. A CDR is not a political rally, but it is also not Thursday night at the pub.
• Use amphitheater-style seating: Ensure that audience members can talk to each other. “Lecture room” seating prohibits discussion.
• Ban Blackberries: Place a box at the door and force people to dump their weapons into it. This is a serious discussion that requires undivided attention. Distractions caused by Joe Flowingut and his HIGH PRIORITY ISSUES!!! cannot be tolerated.
• Use two projectors: Display diagrams on one projector and talking points on the other.

Post-Op

• Debrief: Hold an engineering meeting immediately after the CDR. Sluggishness usually occurs after such an ordeal. The PM should develop a near-term list of action items and assign them after the last slide is presented. Don’t wait for the final analysis before you start moving forward.
• Requirements changes: Identify them, analyze them, and present them to the customer.
• Design changes: Get the engineers working on these immediately. Impact analysis should be the first step.
• Risk assessment: Develop a risk list and use it to re-evaluate the project schedule.
• Action items: Develop a list of action items for the customer. What do you need from him? What issues must he address? Set a date for follow-up and get your questions answered while the issues still occupy his mind.

A CDR comes from the “Waterfallish” world, but it works well at the beginning of an Agile project as well. Although design work may be performed during Agile/XP iterations, architecture must necessarily come first. A raw feature set must also be developed to allocate builds and iterations. These work artifacts are obvious candidates for a CDR.