Locked lesson.

Upgrade

About this lesson

Project technical reviews are formal decision meetings between team members and a panel of subject matter experts.

Exercise files

Download this lesson’s related exercise files.

Technical Reviews Exercise.docx
60 KB Technical Reviews Exercise Solution.docx
60 KB

Quick reference

Technical Reviews

Project technical reviews are formal decision meetings between team members and a panel of subject matter experts.  The purpose is to review the technical approach, technical documentation, the solution to technical risks, and to approve technical results.

When to use

Technical reviews are conducted at technical milestones when a key technical deliverable has been completed.  Examples would include a concept selection, the completion of design or coding, or the completion of verification testing.  Depending upon the project, there may not be any technical reviews or there may be as many as a dozen.  Technical reviews are normally held as a single meeting, but for large complex technical projects, there may be interim reviews leading up to the final review or the review may be divided into subgroups.

Instructions

Meetings occur for one of three purposes.  They are to convey information, solve a problem, or make a decision.  Most technical review meetings are to make a decision about the technical approach or solution used in the project. . Be careful not to mix purposes within a meeting unless you have clearly explained what you are doing.  Otherwise, some meeting attendees will be confused and unprepared.

  1. Use organizational templates and checklists to prepare for the review.
  2. Identify and invite an independent panel of technical experts – either in-house or industry experts.
  3. Collect the technical documentation supporting the deliverables that are to be reviewed.
  4. Provide the documentation to the panel before the meeting so that they have time to review the material.  (If material is classified or confidential, be certain to provide appropriate protection.)
  5. Schedule enough time for the meeting to allow the panel to review and comment on all information.
  6. Start the meeting by reviewing the technical requirements and appropriate standards.
  7. Review a summary of technical documentation in a presentation.
  8. Review the details of the actual technical documentation – break into smaller subgroups if appropriate.
  9. Collect the findings from the panel and clarify whether the review is complete or needs to be repeated.
  10. Assign action items and follow-up with the panel as actions are closed.

Hints & tips

  • Prepare for the meeting.  Review your documentation to be sure everything is ready.
  • If you have known risks or open issues, prepare a discussion to address them.  Explain the issue, options, and your proposed path for resolution.
  • Let the core team member with responsibility for the area being reviewed lead the presentation and discussion of the topic.  Include extended team subject matter experts.
Login to download
  • 00:04 Hi, I'm Ray Sheen.
  • 00:05 Let's talk about an aspect of project control known as technical reviews.
  • 00:10 If your project has any type of technical development,
  • 00:14 you will probably have a need for a technical review at some point.
  • 00:18 Let's dig into technical reviews.
  • 00:20 Technical reviews are normally between the core team on the project and
  • 00:24 a group of independent technical experts.
  • 00:26 These experts can be internal subject matter experts or
  • 00:29 external industry experts.
  • 00:31 By independent,
  • 00:32 we mean people who have not been part of the project development effort.
  • 00:37 You don't get to check your own work.
  • 00:39 The purpose of the review is to do an in depth analysis
  • 00:42 of the technical activities on the project and review the technical documentation.
  • 00:47 This review is to make sure that the approach and results meet the requirements
  • 00:52 and the standards that are embedded in the project objectives.
  • 00:55 These reviews are in major technical milestones or
  • 00:58 decision points on the project.
  • 01:00 Normally, there is a set of deliverables that can be reviewed and a decision can be
  • 01:04 made whether the technical work done to create those deliverables is acceptable.
  • 01:08 Some of the more common technical review milestones are concept selection,
  • 01:12 designed freeze, demonstration of successful qualification, or
  • 01:16 demonstration that production is ready.
  • 01:19 And by the way, I've been in reviews that were as short as
  • 01:22 an hour when there are only two or three technical changes, and
  • 01:26 I've been in reviews that took two weeks to cover everything.
  • 01:30 Preparation is the key to a successful technical review.
  • 01:33 First, reviews are conducted when a set of technical deliverables are ready.
  • 01:38 So make sure that all the work is done before you have the review.
  • 01:42 Many organizations have checklists that indicate what is required for
  • 01:46 each type of technical decision, use it.
  • 01:49 Second, these are formal meetings, not hallway conversations,
  • 01:53 set up an agenda, take minutes, and record action items.
  • 01:57 If you're developing products for regulated industry, the minutes for
  • 02:01 these meetings are required to be in the project history file.
  • 02:04 I also recommend sending the documents to reviewers several days before the meeting,
  • 02:09 so that they will have a chance to prepare.
  • 02:12 Expect an in depth discussion on the technical approach, these experts
  • 02:16 are supposed to analyze your work and ensure that you did not overlook anything.
  • 02:20 They're expected to find what you missed.
  • 02:22 They will want to look at every drawing, every test, every document, so
  • 02:27 be prepared and have everything available.
  • 02:30 As I indicated, most organizations have checklists or
  • 02:33 templates to assist the project team in preparing.
  • 02:36 If your organization has one, use it, if not, check online for some examples.
  • 02:41 Finally, if it's a large review, I will often divide it up.
  • 02:44 I might divide it into categories of deliverables like mechanical, electrical,
  • 02:49 and software.
  • 02:50 I've also divided large reviews into several interim reviews that occur over
  • 02:55 several weeks or
  • 02:56 months ending with a final review that brings everything together.
  • 03:00 Let me finish off with a template for the way that I like to run technical reviews.
  • 03:04 Start with introducing the team members and the reviewers.
  • 03:08 I then review the charter to align the reviewers with the project goals and
  • 03:12 constraints.
  • 03:13 Don't overlook this point.
  • 03:15 The reviewers may not know why you're doing this project and
  • 03:18 what the business expects to achieve.
  • 03:20 They may be looking at things from a totally wrong perspective,
  • 03:24 gain alignment on this before going on.
  • 03:27 Follow the charter by citing the specific requirements, documents,
  • 03:32 or standards that the reviewers are to use in their analysis.
  • 03:36 Now provide all the technical information.
  • 03:38 I usually summarize first and then dig in to each area that is being reviewed.
  • 03:43 You should have on hand a copy of technical artifacts created by the project
  • 03:48 such as drawings and specifications, analyses and
  • 03:51 test results, even any quality plans or process flow documentation.
  • 03:55 And of course, if you have a physical prototype,
  • 03:57 make sure you have that available.
  • 03:59 Then discuss any open technical issues or risks remaining with respect
  • 04:03 to these deliverables, including your approach for resolving those issues.
  • 04:07 Now as for the decision, the experts should either approve or
  • 04:11 reject the technical package that has been reviewed.
  • 04:15 Sometimes, they'll provide a conditional approval.
  • 04:17 Meaning it's approved to go forward but
  • 04:19 there's some cleanup that needs to be done.
  • 04:21 Finally, compile your action items and file your minutes.
  • 04:25 Technical projects are useful to manage the progress on technical projects.
  • 04:30 The goal is to ensure that the project's results will be performing as required.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course