- Table of contents
- Final Design Review (Presentation)
Final Design Review (Presentation)¶
The overall goal for the review is to share your project's outcome with your "customer", the project's client. In a business situation, this would be the final meeting with your customer, coinciding with transferring the project's outcomes to the customer, e.g. the prototype, software, design documents, etc. The team must clearly and concisely communicate the results of the semester's work to the Client.
The Final Design Review is a PowerPoint-based design review. It will be scheduled in cooperation with your clientand instructors for a time during the last two weeks of the semester. In some cases, the design review may be scheduled during the reading days or during finals week. One to two hours should be allocated for the review.
The FULL team should be present and participate in the presentation. The audience will be client, PE, CE, and may include other advisors, evaluators, and consultants associated with the project.
The dress code for the final design review is business formal.
Final review is NOT simply the final status update. It is NOT short round robin style talking points off a poster like the BDR meeting. It is an overview of the ENTIRE project, with evidence of the design process being followed. The full audience will the PE, CE, and client (all live), but also future students who may continue the work and other members of the client organization who will incorporate project output into their operation. They would start by reading your final report and reviewing the final review slide deck to get the complete picture. It is NOT a dear diary form of presentation. It mostly follows the order / structure of the Design Report. Because others / future teams will not see you present the slides, it's critical that all the essential information be on the face of the slides. ex: Do not plan to simply display an unlabeled graph and explain everything verbally.
- You typically need to have about 30-40 minutes of presentation - the balance of your time will be taken by questions and discussion.
- You only need about 30-40 slides to talk to for a 30-40 minute presentation - about one minute per slide.
- All remaining slides can be placed to the back of the presentation after a slide with "Additional Data" on it.
Use the Creating Strong PowerPoint Presentations wiki page to help you.
Sharing Video Content in Webex Meetings¶
When you show a video clip or animation, change the Webex preferences to improve the quality, as demonstrated in https://help.webex.com/en-us/article/nkjrl9eb/Share-motion-and-video-content-in-Webex-Meetings-and-Webex-Webinars
Using the Template¶
The template for the Final Design Review is available here: export:template documents\Final Design Review.pptx
There are no instruction in the template. All instructions are here on this page.
The template is intended to help the team cover all the items essential for the final review. While NOT an exact ‘recipe’ for all teams / projects, talk to your PE before changing it! It is created as a PowerPoint “template”. The footers are properly defined – edit them only using the Header & Footer menu item and be sure to check "Apply to All"!
Creating the Slides¶
Create a Project Management Forum thread with the scheduled meeting date. Please use that thread for collaboration on this PPT rather than and non-EDN resources, e.g., chat, texting, Google, Box, etc.
Copy this template to a new file named “YYYY-MM-DD-Final Design Review.pptx” where YYY-MM-DD is the planned meeting date so that the files sort easily by date this way.
Save this in your working copy of the repository on your PC in the "/working/Reports/Client Meetings" folder. Do NOT add a file version numbers – the repo already handles that!
Review and Edit your content! Commit to the repository as everyone edits using meaningful commit comments. As you edit, leave notes in the project management forum to explain what you've done and why to help coordinate the work.
The agenda provided is considered "typical". Keep the Project Overview as the first item. You may re-order the remaining topics or break them up slightly differently to best suit your team's storytelling approach. For example, you may do a demo first or do parts of the demo through out your meeting as needed.
The project overview should be complete enough so that new people attending the final design review can gain a sense context for the work.
The Agenda Items¶
The Project Statement / Goals slides should explain the “what” of the project. These slides help set the context for the presentation by explaining the basic information someone new to the project would need so as to understand the rest of the presentation. This material must come first. Subtopics include- Introduction
- Problem Statement
- Past Work/Project History
- Project motivation by the Client (the “why”)
- Semester Objectives (the “what”)
The Final Needs and Requirements slides should cover the most important criteria that define the success of the project. It is usually helpful to format this as a table. You may need to summarize items from the project's detailed Needs and Requirements workbook.
The System Evaluation slides should show how the work was evaluated against the requirements and should provide evidence of how well the work met those.
The first part of Accomplishments / Open Issues slides should focus on the major accomplishments of the team. Be sure to focus on the specific results / accomplishments rather than expressing this in "diary mode”.
Even the most successful of teams cannot accomplish all their goals in a single semester. The second part of this section should provide a summary of the open issues. While it is tempting to provide a list of "bugs" that is not the intent here. Instead provide a high level view of the items that were:- not started
- were started but not completed
- were completed but not tested or were tested but did not work as expected
The Conclusions / Recommendations slides should explain with justifications, the interpretation of your work. For the recommendations section, focus on high level items that the Client should leverage for their future work by themselves or perhaps for another Capstone team. Use the SMART approach and make sure the items are actionable. For example, it would be tempting for software projects to indicate "fix bugs" but it can be safely assumed that if the work is continued, any important bugs would automatically be addressed. Focus on new or extended functionality, alternative solutions that should be explored, design improvements that might yield better results, etc.
The Demonstrations material would include specific test results, simulations, or demonstrations of all or parts of the project working. Demonstrations include any “show and tell” opportunities! You may need to provide context, by including overall system block diagram(s), architecture, CAD rendering(s), etc. to help make the demonstration meaningful. It is helpful to provide a brief explanation of the demo and expected results on the slides as well as an interpretation of what the demo show.
This may be done anywhere in the presentation, as appropriate to how your team chooses to "tell it's story". There are advantages to having a quick demo at the start of the presentation, as in "watch this!". Now, having grabbed the audience's attention, you have earned the ability to present the material behind the demo. Based on experience working with your client, it may be preferable to hold the demo(s) off until the end of the presentation so as to not interrupt the "story telling" of your slides. Alternatively, it may make sense to have small incremental demos throughout the presentation to help emphasize material in a given section. The choice is up to your team!
See your PE for any questions.