1     Salutation

Begin with the salutation.  Replace the placeholder “Xxxxx” in the salutation with the name of your main/technical contact in whatever way you are referring to him/her — for example:

• Dear Mr. Smith (the formal default)
  – OR –     Dear Richard (if now on a first-name basis)
  – OR –     Dear Rich (if he also goes by a shared “nickname”)
  – NOT–     Dear Mr. Richard Smith (awkward, form-letterish)
• Dear Ms. Jones (the formal default)
  – OR –     Dear Susan (if now on a first-name basis)
  – OR –     Dear Sue (if she also goes by a shared “nickname”)
  – NOT–     Dear Ms. Susan Jones (awkward, form-letterish)

In other words, if you are not on a first-name basis and, thus, refer to him/her with Mr. or Ms. or Dr., etc. being a title of respect, then just use their last name, not first and last.  Note that professionally, Ms. is often used over Mrs. or Miss and eliminates the risk of inaccurately identifying her as married or unmarried, respectively.  Of course, Dr. is the appropriate professional title for someone, male or female, with a doctorate degree (Ph.D., D.Ed., M.D., D.O, D.D.S, etc.) and there are other more specific ones like Prof., Dean, Judge, Senator, … that may be appropriate.

2     Content

Your customer cover letter will begin by briefly describing what documents are accompanying it, following the opening phrase “Attached please find” that is included in the template.  When doing so, do not simply copy and paste from the latest — the PCR cover letter — and change PCR to PTR and cut some specifics of content.  Further, unlike the internal review that included the PMB, the tech-memo, and some TAD pages, this release is simply this cover letter with a single attachment — the PMB.  In other words, please take care that you do not indicate items being attached that are not.  With just a little thought this is easy to do right and well.

It should continue in a second paragraph beginning with when the review meeting took place and who participated.  Continue with a brief description of the outcome of your review, including any substantive suggestions/feedback/direction you received.  Obviously, this paragraph cannot be written before your review meeting.  Thus, write it after your review meeting and feedback is provided (replacing the placeholder “OUTCOME DESCRIPTION PENDING REVIEW MEETING”).

In a third paragraph (replacing “START THIRD PARAGRAPH HERE”), which CAN AND SHOULD be written BEFORE the review meeting, you should then give a brief indication of where you are headed and what can be expected at the end of the semester/project (hint:  on-campus plus streamed final report presentation, followed by a web-conference project closeout meeting, then delivery of any prototype and a written final report covering the results of the project).

The letter should then conclude with a solicitation of comments from your customer.  Since this is important to avoid confusion as to what you are asking for (and since some teams otherwise have not included this), it is in the template for you as “There is no specific feedback we are seeking; however, please let us know at your earliest convenience if you have any comments, corrections, or concerns.”

Your added paragraphs must be short enough so that the entire letter (including the cc directives on the bottom) fits on one page without change of formatting (its already single-line spacing).

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).

All content above the first section (Memorandum Overview) is pre-filled and should need no edits by you.  This technical memorandum is accompanied by the Technical Archive Document (TAD).  At this stage, there is no need to include your Project Planning Document (PPD) as you are on your way, or not at this point.  The purpose of this technical memo is to allow those participating in the review meeting to (re)acquaint themselves to the problem at hand and to see a summarized preview of the content that is the subject of the review.  As such, like your past technical memos, it begins with a section summarizing your understanding of the problem.  That is followed by a section summarizing your technical progress that is the subject of this review (work refined and completed since the previous review).  As with previous technical memos, this one begins with a brief Memorandum Overview indicating these as the elements of content here with direction to the accompanying document.

1     Memorandum Overview Section

Like the PCR, this is again written on your behalf.  BUT, read it carefully to understand exactly what your audience is expecting to see.  It is your final example to learn from here; though, admittedly, it is nearly identical to the previous ones in form, just updated in specifics.  As you move beyond capstone design and into your career, you will usually be starting with a blank sheet of paper on something like this.

2     Problem Understanding Section

This section is comprised of the (what should be) four paragraphs of the “Problem Understanding” section from your PCR tech-memo.  To bring this content in, select the content in your PCR tech-memo (all four paragraphs together as a single selection, but NOT including the section heading) and copy.  Then, in the PCR template, select “PASTE PROBLEM UNDERSTANDING HERE” (select the entire paragraph by triple-clicking anywhere in the paragraph) and paste.  The formatting, if you had it right in the CSR tech-memo, will be correct here; you can select all of the paragraphs and apply “Normal text” paragraph style to be sure.

3     Engineering Requirements Section

This is a direct carryforward from the PCR; while it may seem like old news at this point your requirements fundamentally define what you aim to deliver; furthermore, inclusion here serves the purpose of a quick reference by your audience.  To bring this content in, like above, select the content in your PCR tech-memo (the “Engineering Requirements” section less the section heading) and copy.  Then, in the PTR template, select “PASTE ENGINEERING REQUIREMENTS HERE” (select the entire paragraph by triple-clicking anywhere in the paragraph) and paste.  The formatting, if you had it right in the PCR tech-memo, will be correct here.

4     Overall Solution Concept Section

This is from the PCR technical memo (per guidance for Standard Projects), Section 1; as such, it is expected to be approximately 1½ – 2 pages (2 pages max) in the format provided in the template (Times New Roman 12-point, 1.3 line spacing, 1-inch margins, etc.).

4.1    Standard Projects

As a starting point, copy from your PCR tech-memo.  To bring this content in, like above, select the content in your PCR tech-memo (the “Final System-Level Concept” section less the section heading) and copy.  Then, in the PTR template, select “PASTE/WRITE SOLUTION CONCEPT HERE” (select the entire paragraph by triple-clicking anywhere in the paragraph) and paste.  The formatting, if you had it right in the PCR tech-memo, will be correct here.

Your evaluator for this one is new, and needs a good, concise overview of the concept that is the basis of the reminder of the project work.  And, it needs to be absolutely current and complete.  As such, you must be sure to update and refine this section from the pasted content that is simply a starting point.  As a reminder of what this section should look like, see the PCR Doc-prep Guidance for the Final System-Level Concept subsection.

4.2    “Failure Resolution” Projects

At the time of your PCR, you most likely did not have your final system-level concept in place; and, recall that it was referred to as your “solution” concept/design rather than “system-level” concept/design, in that you were likely focused on a portion of the overall system, the portion where the root-cause of the failure lies.  At this point in the project, just refer to it as your system-level concept.

Since you were not complete in this regard at the PCR, you need to write this section based on your work since the PCR.  The Standard Project PCR Doc-prep Guidance for the Final System-Level Concept subsection may be helpful in writing this section.  Select “PASTE/WRITE SOLUTION CONCEPT HERE” in the template and start typing.

5     Content for Review Section

While you are not explicitly instructed below to include any specific graphics, remember that engineers largely communicate graphically with the text then written “around” the graphics to “fill in the blanks.”  A few good graphics in the place of the alternative — piles of text — is expected in a quality piece of work here (and “good” means also annotated!).  To help you place graphics in Google Docs with captions that remain attached, a link to a source having a figure+caption placeholder, a table+caption placeholder, and instructions for their use is available in the Figures and Tables Placement Template (FTT) provided at the same time as and with the PTR-TM template.

That said, the text of this section of the tech-memo, in the format provided in the template (paragraph style “Normal text” in Google Docs), should be approximately 1¾ – 2 pages of text (2 pages max; be complete but you must also be selective to make it fit and not spill over to a third page!).  Add to that graphics (table and figures).  That means that with graphics of legible size it may be 5 – 6 pages.  That means 3 – 4 pages worth of graphics; if you have fewer than six (6) graphical elements, you are falling short.  Repeating from the CSR and the PCR… while a good graphic does take time to produce, making it seem that writing text is faster, writing good text takes much longer and more iterations than most students realize.  And again, like previously, the graphics are not much work at this point since the images generally come straight from the TAD with the simple addition of a caption.

As a reminder again from the previous tech-memo guidance, this is to be treated like an executive summary.  That is, this is NOT a diary of what you did, rather it is a summary of the contents of the accompanying TAD (refresh your memory as needed on the content nature of executive summaries by referring to Section 3 of Doc-Prep Guidance — Getting Started).  This is repeated yet again because it is so important to get these summaries right, and in particular not write them as a diary of what you did in generating the work-product (findings and results) that makes up the content.

This section should consist of two (2) subsections as described below.

5.1    Subsection 1 — Detail Design

This subsection should summarize the design decisions related to size, shape, and material with an emphasis on the results of your engineering that supports the decisions.  Decisions, and any resulting design features (aligned with required functionality), should be concisely but completely described.  Those related to safety, manufacturability, and material selection should be covered first and foremost.  Secondarily, make note of any design decisions and resulting features that promote reliability, maintainability/serviceability, aesthetics, human factors (ease of use), and environmental impact.  Do not write fluff.  These must be real design features motivated by these other considerations, not afterthoughts; if you did not design to these considerations, make brief note that “no design decisions and features related to XXXX, YYYYY, and ZZZZZ have been considered.”  Here, XXXXX, YYYYY, and ZZZZZ are reliability, maintainability/serviceability, aesthetics, …

5.2    Subsection 2 — Prototype Verification Plan

This subsection should summarize the fully mature prototype verification plan you now have.  It should be evolved from what you presented at the PCR.  Make note of accommodations — space, instrumentation, and data analysis software — as needed, that are in place or are soon to be put in place.  Hypothesize which testing you anticipate to be the most challenging, or the area of your design you expect to be most likely to require refinement once test results are in hand.  Specifically address your imminent plans for function-level/subsystem testing to take place before your entire prototype is assembled for system-level testing.

6     Next Steps Section

Following each prompt (e.g., Week 08:  ) following the Next Steps section heading, write 1 – 3 sentences describing what your activities will be in each of those weeks.  This draws from your Term-II task list as spread across the weekly list according to your Term-II timeline.  The challenge here is to be concise yet descriptive.  Your objective is to instill confidence that you know what you need to work on to realize success at the end of the project, by the Wednesday of finals week.  If certain activities will span multiple weeks, do not repeat their description each week, simply indicate it is “continuing from week(s) XX” where XX are the previous week number(s), for example, “week 11” or “weeks 11 – 12.”  Really, you are down to two main activities:  prototype manufacture and prototype testing and refinement (hopefully starting about now at the subsystem/function-level, then later at the system level).  You talked about your prototype testing and refinement (prototype verification plan) above; be sure to also emphasize your activities for prototype manufacture here.

This section should be ½ – ¾ page in length.

This section should be ½-¾ page in length.

_{Google Docs is a trademark of Google LLC.}