Technical Reviews

Quick reference

• 00:04 Hi, I'm Ray Sheen,
• 00:06 let's talk now about an aspect of project control known as technical reviews.
• 00:10 If your project has technical development,
• 00:12 you will probably need to do a technical review.
• 00:16 If not, then this session won't have much for you.
• 00:19 You may recall there's several types of meeting.
• 00:24 We often characterize them is one or more types.
• 00:26 Information meetings,
• 00:28 these are regular scheduled meetings that focus on updates and status.
• 00:31 Problem solving meetings,
• 00:33 these specially called meetings that focus on a specific issue and it's resolution.
• 00:37 And decision meetings which occurs at certain times in a project and are focused
• 00:42 on making a significant decision about the direction or progress of the project.
• 00:47 The technical review is a decision meeting.
• 00:49 It's goal is to approve a set of technical deliverables on the project.
• 00:54 Let me caution you about mixing meeting types, this leads to confusion for
• 00:58 the team and the reviewers.
• 01:00 They don't know what is expected of them during the meeting or
• 01:03 at the end of the meeting.
• 01:05 So let's dig into technical reviews.
• 01:08 Technical reviews are normally between the Core Team on the project and
• 01:11 a group of independent technical experts.
• 01:14 These experts can be internal subject matter experts or
• 01:18 external industry experts.
• 01:20 By independent,
• 01:21 we mean people who have not been part of the project development effort.
• 01:24 They don't get to check their own work.
• 01:27 The purpose of the review is to do an in depth analysis of the technical activities
• 01:31 on the project and review the technical documentation.
• 01:35 This review is to make sure that the approach and results made through
• 01:38 requirements and the standards that are embedded in the project objectives.
• 01:42 These reviews are at major technical milestones or
• 01:45 decision points on the project.
• 01:47 Normally, there's a set of deliverables that can be reviewed and a decision can be
• 01:51 made although the technical work done to create those deliverables is acceptable.
• 01:56 Some of the more common technical review milestones are concept selection,
• 02:00 design freeze, demonstration of successful qualification, or
• 02:05 demonstration that the product is ready to the market.
• 02:08 By the way I have been in review to shortest an hour,
• 02:11 when there are only a few items to review.
• 02:13 And I have been in several reviews that took as two weeks to cover everything.
• 02:18 Preparations is the key to a successful technical review.
• 02:21 First, reviews are conducted when a set of technical deliverables are ready.
• 02:26 So, make sure that all the work is done before you have the review.
• 02:29 Many organizations have checklists that indicate what is required for
• 02:32 each type of technical review, use it.
• 02:36 Second, these are formal meetings, not hallway conversations.
• 02:40 Set up an agenda, take minutes, record the action items.
• 02:43 If you're developing products for a regulated industry, the minutes for
• 02:47 these meetings are required to be in the product file.
• 02:50 I also recommend sending the documentation to the reviewer several days before
• 02:54 the meeting so they'll have a chance to prepare.
• 02:57 Expect an in depth discussion on the technical approach.
• 03:00 These experts are supposed to analyze your work and
• 03:03 ensure that you didn't overlook anything.
• 03:05 They're expected to find what you missed.
• 03:08 They'll want to look at every drawing, every test, and every document.
• 03:12 As I indicated, most organization have checklists or
• 03:14 templates to assist the project team in preparation.
• 03:17 If your organization has one, use it, if not, check online for some examples.
• 03:23 Finally, if it's a large review, I'll often divide it up.
• 03:27 I might divide it into categories of deliverables like mechanical, electrical,
• 03:31 and software.
• 03:32 I've also divided large reviews into several interim reviews
• 03:36 that occurred over a several weeks or
• 03:37 months, ending with a final review that brings everything together.
• 03:42 Let me finish off wit a template for the way I like to run technical reviews.
• 03:47 Start with an introduction of the team members and reviewers.
• 03:50 I then review the charter to align the reviewers with the project goals and
• 03:54 constraints.
• 03:55 Followed by the specific requirement documents or
• 03:57 standards that the reviewers are to be using in their analysis.
• 04:01 Now, provide all the technical information.
• 04:04 I usually summarize first, and then dig into each area that is being reviewed.
• 04:08 You should have on hand a copy of all the technical artifacts created in
• 04:12 the project, such as drawings and specifications, analyses and
• 04:15 test results, and any quality plans or process flow documentations.
• 04:20 If it's a product development project have the product there also.
• 04:23 Then discuss open technical issues or risks remaining with respect to those
• 04:28 deliverables, including your approach for how you'll resolve those issues.
• 04:32 If this is a large review,
• 04:33 you probably will break this into sections where you'll cover mechanical first,
• 04:37 electrical, software, logistics, whatever things are being reviewed at this meeting.
• 04:42 Now ask for the decision, the experts should either approve or
• 04:46 reject the technical package that has been reviewed.
• 04:49 Finally, compile your action item list and file your minutes.
• 04:53 Technical reviews are used to manage progress on technical projects.
• 04:58 Their goal is to ensure that the project results would perform as required

Lesson notes are only available for subscribers.