* This is ONLY for Standard Projects. | For “Failure-Resolution” Projects go here.

This one sheet serves three purposes:

• brief/quick preparation for your audience prior to the meeting (“pre-meeting briefing”);
• a guide for the CSR 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 the PUR PMB, 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 your IRD content pages at hand 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 sections 3 and 4 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 your IRDs 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 to be 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 in 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 so 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.
• 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 you are covering (in this order):
  1. Problem understanding (and definition in engineering terms; i.e., engineering requirements)
  2. Function-level design
  3. System-level design
  4. Next steps (your plans toward successfully addressing the PCR metrics)
• The three green-text areas are the focus for the content on this sheet, as indicated by the headings on the larger regions on the template. Some additional guidance follows:
  • The top-left 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 bottom-left is not your function-structure diagram; it is too much detail to be shown here at a readable size. Full morph charts are typically too big to be shown here at a readable size.  It could include any or all of the following:
    • your main system function table and a few bullet points;
    • graphics highlighting some of the function-level concepts/ideas that are most exciting/intriguing/interesting; and/or
    • graphics highlighting some of the function-level concepts/ideas that are uncertain at this point as to their ability to truly meet the respective functional need; to create space for this you may need to omit the main system function table in which case you could convey main system functions in a more spatially efficient way.
  • The top-right is your DP Manager round-1 Pugh chart and the DP Manager data sheet for you round-1 winner.
  • The bottom-right “Next Steps” region should be framed in regard to what you will be doing toward successfully meeting the four PCR metrics:
    1. The chosen system-level concept has a good likelihood of meeting the engineering requirements as substantiated by preliminary/feasibility engineering; i.e., the requirements could be met by your concept.
    2. A technically sound plan is in place, on a requirement-by-requirement basis, describing methods for detail-design engineering (so that your engineering requirements should be met by your design) and for prototype verification (showing that your engineering requirements are ultimately met by your physically realized solution).
    3. A detailed and realistic work-plan is in place for completing the detail-design work, procuring materials and components, fabricating the prototype, and testing/refining the prototype.
    4. A financial plan is in place to complete the project within the allocated/secured budget.
• 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

Example 2

* This is ONLY for “Failure-Resolution” Projects. | For Standard Projects go here.

All content above the first section (Memorandum Overview) is pre-filled and should need no edits by you.  If you alerted the SCD program director of errors from the PUD, they should be resolved now.  If new errors (names, project title, customer) are noted, or previously reported errors have not been fixed, please email the SCD Program Director with any corrections needed.

This technical memorandum is accompanied by the Technical Archive Document (TAD) and your Project Planning Document (PPD), updated with refinements AND WITH ALL progress since the PUD.  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, it includes a section summarizing your understanding of the problem followed by a section summarizing your technical progress that is the subject of this review (work refined and completed since the previous review).  Between those two sections is a section covering your engineering requirements as the basis for all your work beyond the problem understanding stage.  The technical memo begins with a brief Memorandum Overview indicating these as the elements of content here with direction to the accompanying documents.

1     Memorandum Overview Section

This is written on your behalf.  Read it carefully to understand exactly what your audience is expecting to see.  Also, it serves as an example for future technical memos where you will have to write the overview on your own.

2     Problem Understanding Section

This section is comprised of the “Problem Understanding” section from your PUD Executive Summary, but ONLY the first FOUR paragraphs (not the fifth/last!).  To bring this content in, select the content in your PUD (all four paragraphs together as a single selection, but NOT including the section heading) and copy.  Then, in the CSR template, select “PASTE HERE” (select the entire paragraph by triple-clicking anywhere in the paragraph) and paste.  The formatting, if you had it right in the PUD, will be correct here; select all of the paragraphs and apply “Normal text” paragraph style to be sure.

That’s it?  Yes and no.  That may be (see below) the entirety of the content, but you are not done.  By now you should have a sense for your team’s best couple writers.  Those two need to work as a team to tune this up even better than it was a few weeks ago.  Now that it has sat out of sight for a couple weeks, you are all able to now see it with fresh eyes.  These two teammates, first one, then the second, should take an hour tuning it up.  Don’t think that after four more weeks you cannot tune it up some!

First, with certainty your understanding of the problem has refined since the PUD.  For instance, all engineering requirements may now be fully defined whereas they were not before, and they may now be prioritized and quantified differently to resolve some uncertainties that may have existed at the PUD submission/signing stage.  By not carrying forward the fifth paragraph from the PUD executive summary, which was also limited to one page, you have at least a little extra room.  You can (should!) use this space to add new and/or improved and/or more complete information, either in regard to engineering requirements (paragraph 4) as noted, or in regard to use of the solution (paragraph 3).

Second, and I must stress this, that was not your best work — simple as that.  You were under the gun to get it done, get it submitted, and move forward on your function-level design work.  Now, go though it with close attention to detail and wording with an editorial mindset.  You might only change a dozen words, though you might change a whole lot more.  With the exception of the content refinements/changes above, the changes of this editorial sort are to make its presentation the very best it can be — clear, complete, and concise.  Your page limit is one page, including the section title.  That is, it cannot spill onto page 3 of the technical memo.  Do NOT change the formatting (Times New Roman 12-point, 1.3 line spacing, 1-inch margins, etc. — paragraph style “Normal text” in Google Docs).

Guidance can be found here if needed in support of your efforts to improve on your previous version.

3     Engineering Requirements Section

This is from the PUD, Section 4.  To bring this content in, like above, select the content in your PUD (the engineering requirements tables in (each should be a “drawing” with the image and caption in it), but NOT including the section heading or the lead-in paragraph of the PUD) and copy.  Then, in the CSR template, select “PASTE HERE” (select the entire paragraph by triple-clicking anywhere in the paragraph) and paste.  You should update the table images to their most recent updated form (which should also be what is in your TAD; that is, the most up-to-date versions of those tables as updated/refined since the PUD).  Note that there is a page break placed after the tables and before the Content for Review section.  This section will normally take a single page, unless you have more than one line of design (two related systems/subsystems you are designing, each with its own requirements).  If you have more than one line of design, as a reminder, you need to make some adjustments as is described here.

4     Content for Review Section

While you are not explicitly instructed below to include any specific graphics, remember that as engineers we largely communicate graphically with the text then written “around” the graphics to “fill in the blanks.”  In other words, good graphics in the place of the alternative — piles of text — is anticipated; in fact, this 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 shortly after the PUD-Doc 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.  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 in this case, 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.

Treat this like an executive summary in that this is NOT a diary of what you did, rather it is a summary of the contents of the accompanying TAD and PPD (refresh your memory on executive summaries by referring to Section 3 of Doc-Prep Guidance — Getting Started).

This section should consist of three (3) subsections as described below.

4.1    Subsection 1 — Functional Decomposition

This subsection will likely be 2 – 3 short paragraphs, about 20% of the total of the Content for Review section, with reference to TAD Subsection 2.1.  Make note of the overall system function.  Describe the inputs and outputs to your system, categorized as energy, mass (matter/material), and information.  Note the main system functions required to accomplish the overall system function; provide a comment to confirm that the list is complete and not with excess functionality.  Then briefly describe, in functional terms, the failure that you are to resolve.

Remember, this is not a diary!

4.2    Subsection 2 — Root-Cause Failure Analysis Plan and Progress

This subsection will likely be 4 – 5 paragraphs, about 60% of the total of the Content for Review section, with reference to TAD Subsection 2.2.  This subsection should describe your root-cause failure analysis plan and results to date.  It is possible that you have located the source of the failure of this point.  If so, you may also understand the root-cause, or you may still be working to fully figure out some of the details behind it.  Or, you are still working on locating it in the first place.  If it were easy to find and figure out, someone else would have solved it already.  This is one of the few places in this course where you will report in a way that is similar to how you have done “lab” or “practice session” reports in those respective courses.

First, briefly describe the plan in place for identifying the root cause.  Note the test methods, the data to be acquired, and the types of analysis to be applied to the data.  Next, likely starting a second paragraph, discuss the highlights of the data you have acquired to date.  For each set or round of data, note the implication that results from those data, whether it led to additional new testing or to a conclusion.  Finally, if you have already identified the root cause, close by noting the relevant main system functions, i.e., those relevant to the solution to the failure you have identified.

4.3    Subsection 3 — Initial Solution Ideas

The third and final subsection will be shorter, maybe 20% of the total of the Content for Review section.  Whether or not you have concluded your root-cause failure analysis, you should have come to a good understanding of how the system works and at least narrowed down on the root cause of the failure to be resolved.  With that mindset, describe some of the ideas that have been surfacing for resolving the failure.

5     Next Steps Section

Following each prompt (e.g., Week 09:  ) 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-I task list as spread across the weekly list according to your Term-I 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 reach success at the end of Term-I — approval (preferably non-conditional) to continue on in Term-II.  Keep in mind the four metrics your Project Continuation Review (PCR) panel will consider in making their recommendation to the program director:

• The chosen system-level concept has a good likelihood of meeting the engineering requirements as substantiated by preliminary/feasibility engineering; i.e., the requirements could realistically be met by your concept.
• A technically sound plan is in place, on a requirement-by-requirement basis, describing methods for detail-design engineering (so that your engineering requirements should be met by your design) and for prototype verification (showing that your engineering requirements are ultimately met by your physically realized solution).
• A detailed and realistic work-plan is in place for completing the detail-design work, procuring materials and components, fabricating the prototype, and testing/refining the prototype.
• A financial plan is in place to complete the project within the allocated/secured budget.

Of course, you are in week-9 at the point of this review, so that week’s work is in progress and continuing for the reminder of week-9.  This section should be ½-¾ page in length.

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

* This is ONLY for Standard Projects. | For “Failure-Resolution” Projects go here.

All content above the first section (Memorandum Overview) is pre-filled and should need no edits by you.  If you alerted the SCD program director of errors from the PUD, they should be resolved now.  If new errors (names, project title, customer) are noted, or previously reported errors have not been fixed, please email the SCD Program Director with any corrections needed.

This technical memorandum is accompanied by the Technical Archive Document (TAD) and your Project Planning Document (PPD), updated with refinements AND WITH ALL progress since the PUD.  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, it includes a section summarizing your understanding of the problem followed by a section summarizing your technical progress that is the subject of this review (work refined and completed since the previous review).  Between those two sections is a section covering your engineering requirements as the basis for all your work beyond the problem understanding stage.  The technical memo begins with a brief Memorandum Overview indicating these as the elements of content here with direction to the accompanying documents.

1     Memorandum Overview Section

This is written on your behalf.  Read it carefully to understand exactly what your audience is expecting to see.  Also, it serves as an example for future technical memos where you will have to write the overview on your own.

2     Problem Understanding Section

This section is comprised of the “Problem Understanding” section from your PUD Executive Summary, but ONLY the first FOUR paragraphs (not the fifth/last!).  To bring this content in, select the content in your PUD (all four paragraphs together as a single selection, but NOT including the section heading), and copy.  Then, in the CSR template, select “PASTE HERE” (select the entire paragraph by triple-clicking anywhere in the paragraph).  Then paste.  The formatting, if you had it right in the PUD, will be correct here; select all of the paragraphs and apply “Normal text” paragraph style to be sure.

That’s it?  Yes and no.  That may be (see below) the entirety of the content, but you are not done.  By now you should have a sense for your team’s best couple writers.  Those two need to work as a team to tune this up even better than it was a few weeks ago.  Now that it has sat out of sight for a couple weeks, you are all able to now see it with fresh eyes.  These two teammates, first one, then the second, should take an hour tuning it up.  Don’t think that after four more weeks you cannot tune it up some!

First, with certainty your understanding of the problem has refined since the PUD.  For instance, all engineering requirements may now be fully defined whereas they were not before, and they may now be prioritized and quantified differently to resolve some uncertainties that may have existed at the PUD submission/signing stage.  By not carrying forward the fifth paragraph from the PUD executive summary, which was also limited to one page, you have at least a little extra room.  You can (should!) use this space to add new and/or improved and/or more complete information, either in regard to engineering requirements (paragraph 4) as noted, or in regard to use of the solution (paragraph 3).

Second, and I must stress this, that was not your best work — simple as that.  You were under the gun to get it done, get it submitted, and move forward on your function-level design work.  Now, go though it with close attention to detail and wording with an editorial mindset.  You might only change a dozen words, though you might change a whole lot more.  With the exception of the content refinements/changes above, the changes of this editorial sort are to make its presentation the very best it can be — clear, complete, and concise.  Your page limit is one page, including the section title.  That is, it cannot spill onto page 3 of the technical memo.  Do NOT change the formatting (Times New Roman 12-point, 1.3 line spacing, 1-inch margins, etc. — paragraph style “Normal text” in Google Docs).

Guidance can be found here if needed in support of your efforts to improve on your previous version.

3     Engineering Requirements Section

This is from the PUD, Section 4.  To bring this content in, like above, select the content in your PUD (the engineering requirements tables in (each should be a “drawing” with the image and caption in it), but NOT including the section heading or the lead-in paragraph of the PUD) and copy.  Then, in the CSR template, select “PASTE HERE” (select the entire paragraph by triple-clicking anywhere in the paragraph) and paste.  You should update the table images to their most recent updated form (which should also be what is in your TAD; that is, the most up-to-date versions of those tables as updated/refined since the PUD).  Note that there is a page break placed after the tables and before the Content for Review section.  This section will normally take a single page, unless you have more than one line of design (two related systems/subsystems you are designing, each with its own requirements).  If you have more than one line of design, as a reminder, you need to make some adjustments as is described here.

4     Content for Review Section

While you are not explicitly instructed below to include any specific graphics, remember that as engineers we largely communicate graphically with the text then written “around” the graphics to “fill in the blanks.”  In other words, good graphics in the place of the alternative — piles of text — is anticipated; in fact, this 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 shortly after the PUD-Doc 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.  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 in this case, 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.

Treat this like an executive summary in that this is NOT a diary of what you did, rather it is a summary of the contents of the accompanying TAD and PPD (refresh your memory on executive summaries by referring to Section 3 of Doc-Prep Guidance — Getting Started).

This section should consist of three (3) subsections as described below.

4.1    Subsection 1 — Function-Level Design

This subsection will likely be 2 – 4 short paragraphs, about 40% of the total of the Content for Review section.  This subsection should summarize the content of your function-level design work (Section 2 of the TAD).  Make note of the overall system function.  Describe the inputs and outputs to your system, categorized as energy, mass (matter/material), and information.  Note the main system functions required to accomplish the overall system function; provide a comment to confirm that the list is complete and not with excess functionality.  Then pick the three function-level concepts you are most excited about, that you find intriguing, including those that may still be questionable or uncertain as to their ability to meet the required function; these are the ideas you think are representative of the greatest potential of your function-level thinking.  Now, briefly (but with completeness) describe them, making note of any that fall in the “uncertain” category/status.  Conclude with summarizing highlights of information gathered.

Remember, this is not a diary!

4.2    Subsection 2 — System-Level Concept Evolution

This subsection, too, will likely be 3 – 4 short paragraphs and a graphic of the best of your latest complete round of system-level concepting (Pugh analysis), about 40% of the total of the Content for Review section.  This subsection should summarize the content of your system-level design work completed thus far, as captured in Section 3 of the TAD.  It is expected that you have at least one full round of system-level concept generation and assessment complete; more is fine.  Begin with the first round, then, if and only if you have completed a second round, share that outcome.

To start, write a brief explanation of your datum for the first round.  Then, provide a two-sentence summary of each of the first-round designs.  Then, in a second paragraph, explain what you learned from the full round-one analysis that helps (or helped, if round-two is started) you set your direction in the next round.  In other words, indicate any trends or signs identified from the first round that are shaping (or shaped) your thinking and direction in the second round.  This is about conveying your thinking to your audience.  Your thinking is made up of both the rationale behind the +/−/= decisions and how you learn from each round beyond just selecting a best concept from that round.

In a third paragraph, focus on the outcome of the first round — the best concept from that round, the ways in which it is better than the datum, and why (rationale) it is better in those ways; not, it may not be better overall, but in one or more certain ways it hopefully is.  If you have completed a second round, add a fourth paragraph like the third, but for the second round.  Include, then, a graphic of the best from you’re the latest complete round (first or second; if you are actually into a third, don’t get into that here).

Again, remember this is not a diary.  And remember to be quantitative wherever possible.

4.3    Subsection 3 — Preliminary/Feasibility Engineering Plan

The third and final subsection will be shorter, maybe 20% of the total of the Content for Review section.  This subsection should begin with the text included in the template, that is, “An initial draft of the design-stage verification plan has been completed.  At this stage the focus is on methods that will be applied in the preliminary/feasibility engineering activities; methods to be applied later in detail-design engineering will be determined after our final system-level concept is selected.”  Select “START HERE” and begin typing, continuing with a summary of supporting engineering methods you will be applying in your preliminary/feasibility engineering work.  You should cover three (3) unique elements of engineering work to be done (“unique” meaning that some engineering requirements will employ the same methods; we are interested in three methods, not three requirements covered by the same/single method).

5     Next Steps Section

Following each prompt (e.g., Week 09:  ) that follow the Next Steps section heading, write 1 – 3 sentences describing what your activities will be in each of those weeks.  This content draws from your Term-I task list as spread across the weekly list according to your Term-I 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 reach success at the end of Term-I — approval (preferably non-conditional) to continue on with the project in Term-II.  Keep in mind the four metrics your Project Continuation Review (PCR) panel will consider in making their recommendation to the program director:

• The chosen system-level concept has a good likelihood of meeting the engineering requirements as substantiated by preliminary/feasibility engineering; i.e., that the requirements could realistically be met by your concept.
• A technically sound plan is in place, on a requirement-by-requirement basis, describing methods for detail-design engineering (so that your engineering requirements should be met by your design) and for prototype verification (showing that your engineering requirements are ultimately met by your physically realized solution).
• A detailed and realistic work-plan is in place for completing the detail-design work, procuring materials and components, fabricating the prototype, and testing/refining the prototype.
• A financial plan is in place to complete the project within the allocated/secured budget.

Of course, you are in week-9 at the point of this review, so that week’s work is in progress and continuing for the reminder of week-9.  This section should be ½ – ¾ page in length.

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