This one sheet serves three purposes:

• brief/quick preparation for your audience prior to the meeting (“pre-meeting briefing”);
• a guide for the PTR meeting, for you and your audience members; and
• a take-away for your audience.

1     Organization and Formatting

• There are four (4) sections that progress according to the numbers in their respective headings.
• There are two layouts from which you can choose based on how you think apportioning the space between sections 2 and 3 works best for you:
  1. The first goes from top-left down to bottom-left then over and up to top-right and down to bottom-right (top-to-bottom then left-to-right, or “TBLR”).
  2. The second goes from top-left over to top-right then back over and down to bottom-left and over to bottom-right (left-to-right then top-to-bottom, or “LRTB”).
• Each section on the sheet has, below its heading, a text field with a prompt for a short sentence to provide context (replace that prompt with yours) followed by a bullet-list starter “Xxxxx”.
• The top headings (left- and right-columns) are on the respective master layout (named “PMB-TBLR” or “PMB-LRTB”) and should not be moved. The other two headings may be moved up or down (hold the shift key down to maintain vertical alignment) to redistribute space as it better serves you.  Do NOT change the wording of any of the headings.
• Remember, like previous (PUR and CSR) PMBs, this is highlights, what will prep your audience before the meeting and that you will use to lead the discussion at the start of the meeting.
• • It need not be jam packed; you are allowed/encouraged to have relevant TAD pages with you to reference for details as needed.
  • The content should be graphics-rich with minimal text. Aim for (minimum) 75% of the space consumed by graphics (with the exception of the next-steps section which will likely, though not necessarily, be mainly text).
  • But do not try to include all of your graphics relevant to the respective section. Be thoughtfully selective; you can have select TAD pages to reference as noted, and the graphics on the PMB must be large enough to see any important feature on the graphic.
  • Think of each of the four sections as a “slide” dominated by graphics with some bullet points to complement the graphics.
• Regarding graphics:
  • Graphics include annotated CAD, illustrations, plots, and photos as well as tables. Yes, annotate plots as needed (often but not all of the time) to point out what is of particular interest.
  • Graphics used here are copied and pasted from your other docs.
  • Choose graphical elements of substance, not just present as a token non-textual element that is otherwise useless.
  • Be sure to have figure and table numbers so your audience can follow you as you talk them through it.
  • Did you see “annotated” above?!
• Regarding text:
  • The bullet points serve three purposes:
    • guidance for your audience, leading them through the storyline and graphics both during the meeting and for quick pre-meeting preparation,
    • cues for you during the meeting, reminding you not what specifically to say (use your spoken words for that), but what generally to talk about, and
    • refreshers for your audience, reminding them afterwards what you talked about and jogging their memory about some of the details of what they heard you say (your spoken words).
  • These bullet points are short, to-the-point, not copied from your TAD since they are to be very limited and short compared to your more extensive bullet points in the TAD. Each should be no more than a single short sentence or phrase.
  • The bullet points, at this stage, should just come to you naturally, like was described for the RPU, that you just know the project work well enough you can just talk about it (i.e., you can just write some bullet points about it).
  • Again… more graphics, less text!

2     Content Presentation

• Leading into each bullet-point list should be one short, complete sentence providing context for the list/section.
• There are four areas of your work-product you are covering (in this order):
  1. Problem understanding (and definition in engineering terms; i.e., engineering requirements)
  2. Overall solution concept from a system-level view (largely graphical)
  3. Design details (expressed in terms of functionality and exciting/cool design features)
  4. Next steps (basically your status on prototyping and testing plans)
• Some additional guidance follows:
  • Section 1 is a few key bullet points on what your project is, and perhaps what it isn’t, then defined in engineering terms (your engineering requirements tables).
  • The meat of this is Section 2, showing one (or more as appropriate) graphical views of your final solution from a system-level viewpoint. Annotate main subsystems or interesting elements of focus (i.e., ones you are particular proud of in how they serve the needs/function to be met).
  • Section 3 is not your function-structure diagram; the FSD is too much detail to be shown/readable here. And Section 3, at this stage, is not your main system function table or morph chart.  Section 3 should include graphical views zoomed in on function-level details not as discernable in the wider, zoomed-out view(s) of Section 2.  Complement the graphics with a few bullet points describing the features of your design (again, some of the things you feel are interesting in how it meets the needs, or even special design decisions related to material or COTS components chosen).  Being zoom-in graphics of details, the layout with Section 3 at the top-right is often chosen as this provides more space for Section 3.
  • Section 4 is not your verification plan tables; those tables are too much detail to be shown/readable here.  It is a few bullet points on the status of prototyping and plans for testing, the latter being much of your next steps (along with completing the prototyping activities, and with special emphasis on your (hopefully initiated about now) subsystem/function-level testing that happens before full system-level testing).  This is also the place to note whether or not you think a project title change/tweak would make sense (or not) — enter information here for BOTH red-background prompts.^[1]
• This is not “new documentation,” it is just a quick compilation of highlights pulled from other places in your documentation to prep others for the meeting and, furthermore, assist you in leading the meeting before getting into the details of discussion.

3     Examples of Great Work

Example 1

Example2

^[1]  Some projects evolve into something a little different than what we think they will be when we bring them in and get started.  To avoid confusion in the broader audience of your FRV and/or FRP, it may be helpful to adjust the title of some projects to reflect these changes in scope and/or project/problem understanding that may have occurred over the course of the project.  We are asking now so this can be discussed with your PA this week and as needed at the PTR and a decision made before you begin working on your FRV and/or FRP content.  You will NOT change your various templates/documents as this is more a matter of clarity for your broader audiences (FRV and FRP).  Any suggested change (or the word “none”) should be entered in the field after the red-background prompt at the bottom-right corner of the PMB.  Also there, you should enter your current customer contact(s) info (which sometimes changes over the course of a project; we need to be sure to send FRP invites to the right people).