{"id":1630,"date":"2017-01-12T06:02:16","date_gmt":"2017-01-12T11:02:16","guid":{"rendered":"http:\/\/me.sites.mtu.edu\/meemscd\/?p=1630"},"modified":"2023-02-18T16:15:20","modified_gmt":"2023-02-18T21:15:20","slug":"dg-pcr-tech-memo-fr","status":"publish","type":"post","link":"https:\/\/me.sites.mtu.edu\/meemscd\/dg-pcr-tech-memo-fr\/","title":{"rendered":"Project Continuation Review (PCR) \u2014 Tech-Memo*"},"content":{"rendered":"

* This is ONLY<\/em> for \u201cFailure-Resolution\u201d Projects. | For Standard Projects go here<\/a>.<\/strong><\/span><\/p>\n

Before continuing, if you have NOT<\/em> reached the point of
\nsystem-level concept generation and assessment,
\nsee the program director prior to completing your documents for submission.<\/strong><\/span><\/p>\n

All content above the first section (Memorandum Overview<\/em>) is pre-filled and should need no edits by you.\u00a0 This technical memorandum is accompanied by the TAD and your PPD, updated<\/strong> with refinements and with ALL<\/em> progress<\/strong> up to this point.\u00a0 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.\u00a0 As such, like your CSR tech-memo, 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\/or completed since the previous review).\u00a0 Between those two sections is a section covering your engineering requirements, as those are critical to assessing your engineering work, all of which has been driven by meeting those requirements.\u00a0 As with your CSR tech-memo, this one begins with a brief Memorandum Overview<\/em> indicating these as the elements of content here with direction to the accompanying documents.<\/p>\n

1\u00a0\u00a0\u00a0\u00a0 Memorandum Overview Section<\/h2>\n

Like the CSR, this is again written on your behalf.\u00a0 BUT<\/em><\/strong>, read it carefully so you understand what your audience is expecting to see.\u00a0 It also serves as an example for future technical memos where you will have to write the overview on your own.<\/p>\n

2\u00a0\u00a0\u00a0\u00a0 Problem Understanding Section<\/h2>\n

This section is comprised of the \u201cProblem Understanding\u201d section from your CSR tech-memo.\u00a0 To bring this content in, select the content in your CSR tech-memo (all four paragraphs together as a single selection, but NOT<\/em><\/strong> including the section heading) and copy.\u00a0 Then, in the PCR template, select \u201cPASTE PROBLEM UNDERSTANDING HERE\u201d (select the entire paragraph by triple-clicking anywhere in the paragraph) and paste.\u00a0 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 \u201cNormal text\u201d paragraph style to be sure.<\/p>\n

That\u2019s it?\u00a0 Like for the CSR, your best two writers should take one more (and final) time through to make this the best you possibly can.\u00a0 This is the first piece of \u201cDecision-Critical Documents\u00a0\u2014 Make the Opening Count\u201d (Section 2 of Chapter 5 in Math to Mettle<\/em>) as described in the book.\u00a0 Please revisit that section if you need to refresh your memory on just how important this memo is, in particular this first section your review panelists will read.<\/p>\n

Don\u2019t think that after another four weeks since the CSR you cannot tune it up just a little bit more.<\/strong>\u00a0 Maybe not a full hour of rework this time, but a half hour by each of the two best writers.\u00a0 However, it is NOT UNCOMMON<\/em> for a team to have a SUBSTANTIVELY<\/em> refined understanding, or an understanding that has outright changed as the project evolved in and through the concept selection stage.<\/strong>\u00a0 In this case, give this section an equally substantive updating<\/strong> in the appropriate paragraphs.\u00a0 I have seen times where a team has rewritten a good 80% of this section at this stage to better reflect where the project has evolved\u00a0\u2014 and with great effect.\u00a0 Remember\u2026 Make the Opening Count!<\/strong><\/p>\n

And if introducing a graphic helps, DO SO<\/em>\u2026 a good one<\/strong> (often occupying less space than trying to explain with text!).\u00a0 Still, your page limit remains one page, including the section title.\u00a0 That is, it cannot spill onto page 3 of the tech-memo.\u00a0 Do NOT<\/em> change the formatting<\/strong> (Times New Roman 12-point, 1.3 line spacing<\/strong>, 1-inch margins, etc.\u00a0\u2014 paragraph style \u201cNormal text\u201d in Google Docs<\/em>).<\/p>\n

Guidance can be found here<\/a>, from the original writing of this content, if helpful in support of your efforts here.<\/span><\/p>\n

3\u00a0\u00a0\u00a0\u00a0 Engineering Requirements Section<\/h2>\n

This is a direct carryforward from the CSR.\u00a0 To bring this content in, like above, select the content in your CSR tech-memo (the \u201cEngineering Requirements\u201d section less the section heading) and copy. \u00a0Then, in the PCR template, select \u201cPASTE ENGINEERING REQUIREMENTS HERE\u201d (select the entire paragraph by triple-clicking anywhere in the paragraph) and paste.\u00a0 The formatting, if you had it right in the CSR tech-memo, will be correct here.<\/p>\n

4\u00a0\u00a0\u00a0\u00a0 Content for Review Section<\/h2>\n

While you are not explicitly instructed below to include any specific<\/em><\/strong> graphics, remember that as engineers we largely communicate graphically with the text then written \u201caround\u201d the graphics to \u201cfill in the blanks.\u201d\u00a0 In other words, good<\/em><\/strong> graphics in the place of the alternative\u00a0\u2014 piles of text\u00a0\u2014 is anticipated; in fact, this is expected in a quality piece of work here (and \u201cgood<\/em>\u201d means also annotated!)<\/strong>.\u00a0 To help you place graphics in Google Docs<\/em> 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.<\/p>\n

That said, this section of the tech-memo, in the format provided in the template (paragraph style \u201cNormal text\u201d in Google Docs<\/em>), should be approximately 4\u00a0\u2013 4\u00bd pages (4\u00bd pages max<\/strong>; be complete but you must also be selective to make it fit<\/strong> and not spill over to a fifth page!) .\u00a0 Add to that graphics (table and figures).\u00a0 That means that with graphics of legible size it may be 7\u00a0\u2013 8 pages.\u00a0 That means 3\u00a0\u2013 4 pages worth of graphics; if you have fewer than six (6) graphical elements, you are falling short.\u00a0 Repeating from the CSR stage\u2026 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.\u00a0 And again, like at the CSR stage, 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.<\/p>\n

As a reminder again from the CSR tech-memo guidance, this is to be treated like an executive summary.\u00a0 That is, this is NOT<\/em> a diary of what you did<\/strong>, rather it is a summary of the contents of the accompanying TAD and PPD (refresh your memory as needed on the content nature of executive summaries by referring to Section 3 of Doc-Prep Guidance\u00a0\u2014 Getting Started<\/a>).\u00a0 This is repeated again because it is so important to get these summaries right<\/strong>, 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.<\/p>\n

This section should consist of three (3) subsections as described below.<\/p>\n

4.1\u00a0\u00a0\u00a0 Subsection 1\u00a0\u2014 Root-Cause Failure Analysis<\/h3>\n

This subsection will comprise one figure (consuming about \u00bd a page), possibly more graphics\/figure(s) as needed to convey your results (see below), and 3\u00a0\u2013 5 paragraphs, about 35\u00a0\u2013 45% of the total of the Content for Review<\/em> section (2 pages max<\/strong>).\u00a0 When it comes to describing the results of your root-cause analysis, remember this is not a diary; don\u2019t tell a story of what you did in the root-cause analysis (your brief description of the root-cause analysis plan aside), just jump to the results. \u00a0First cover results of any intermediate steps, and then the final result that derives from those intermediate steps.<\/p>\n

The first paragraph will begin as provided in the template with \u201cFigure 1 illustrates the overall existing system in which the noted failure takes place.\u201d\u00a0 The referenced graphic, just below this first paragraph, should be well annotated, show the system you are working with, and, to whatever extent possible, highlight the failure (or location of the failure) itself.\u00a0 This first paragraph should continue (select \u201cCONTINUE HERE-RCFA1\u201d and start typing) by thoroughly, but concisely, describing the plan you executed to determine the root-cause of failure.\u00a0 There is no need to describe the failure itself, under the presumption that you already described it in the Problem Understanding<\/em> section.<\/p>\n

The second paragraph (select \u201cCONTINUE HERE-RCFA2\u201d and start typing) begins describing the results of your root-cause analysis.\u00a0 Spread this into 2\u00a0\u2013 3 paragraphs as makes sense to break the findings down in a logical way.\u00a0 As noted, additional graphics (tables and\/or plots of data, for instance) are likely helpful in conveying your results; tables should have a caption reading \u201cTable #\u00a0\u00a0Xxxxx\u201d above<\/em><\/strong> the table (figure captions being below a figure). \u00a0Repeating from above, there is a link to a helpful source included in the comment on the cover page along with the link to this guidance.<\/p>\n

Conclude with a final short paragraph summarizing the root cause and, in general terms, what you will do to resolve it.\u00a0 On the latter, don\u2019t get detailed; the details<\/em><\/strong> of your resolution, or solution, come-in immediately in the next subsection.<\/p>\n

4.2\u00a0\u00a0\u00a0 Subsection 2\u00a0\u2014 Solution Design Progress<\/h3>\n

Usually in these types of projects, the solution to the failure addresses a portion of the overall existing system.\u00a0 Your solution is still generally a combination of multiple function-level concepts as the makeup of a \u201csystem.\u201d\u00a0 But, not being the whole or overall system, to avoid confusion, refer to it here as your \u201csolution\u201d concept\/design rather than \u201csystem-level\u201d concept\/design.\u00a0 This guidance for Subsection 2 of the tech-memo presupposes you have at least completed one round of solution concept generation and assessment; if you have not, see the program director immediately for other guidance.<\/strong><\/p>\n

This subsection will comprise one figure (consuming about \u00bd page) and 3\u00a0\u2013 4 paragraphs, about 35\u00a0\u2013 45% of the total of the Content for Review<\/em> section (2 pages max<\/strong>).\u00a0 Remember again, this is not a diary; don\u2019t tell a story of what you did in the concept generation and assessment process, just jump to the final result and focus on the result.<\/p>\n

The first paragraph will begin as provided in the template with \u201cA graphical rendering of our likely solution concept is provided in Figure 2.\u201d\u00a0 This first paragraph should continue (select \u201cCONTINUE HERE-SDP1\u201d and start typing) by thoroughly, but concisely, describing how your likely (top candidate for final[1]<\/a><\/sup>) solution concept works and how it is made.\u00a0 This is a fine-tuned version of what is on its system-level concept datasheet of TAD Subsection 4.1.\u00a0 The referenced graphic, just below this first paragraph, should be the most awesome, enticing, intriguing graphic of your likely solution concept that you can produce, likely pulled from TAD Subsection 4.3.\u00a0 And I mean A REALLY GOOD ONE<\/em><\/strong>.\u00a0 One you may adjust and tweak FOUR OR FIVE TIMES<\/em> over a couple days and then place back into Subsection 4.3 of the TAD.<\/strong>\u00a0 It should provide annotations\/callouts that are meaningful in relation to, but not limited to, the key components, subsystems, features, and\/or main system functions.\u00a0 The first paragraph and Figure 2 should just about consume one page. \u00a0Adjust the figure number in the text and caption if you used more than one figure in the preceding section.<\/strong><\/p>\n

The next paragraph, after the figure, should begin with the text included in the template, that is, \u201cFrom a functional standpoint, the system\u201d then select \u201cCONTINUE HERE-SDP2\u201d and begin typing.\u00a0 Here, functionally describe your solution concept, referencing Figure 1 as appropriate.\u00a0 You are expanding on the \u201chow it works\u201d of the first paragraph, but without being repetitive (make the earlier coverage more concise as needed to avoid that).\u00a0 Describe the ways in which the main system functions are achieved; in other words, state the function-level concepts that comprise the system, but do so in a narrative form, perhaps a bullet-point list, but use descriptive phrases, not just a laundry list of 1\u20133-word concept names\/identifiers.\u00a0 That is, however you lay it out, do not just use the names of the function-level concepts; rather, describe them in brevity.\u00a0 Also, do not use the names of the main system functions; rather, use, and adjust as needed, their descriptions from the main systems function list of TAD Subsection 2.1 (maybe use the main system functions table here).\u00a0 The point is, work the function-level concepts, and the main system function descriptions associated with each, into this narrative in way that is smooth, flowing, concise yet complete and not confusing.\u00a0 If this is getting too long to meet the page limit for this section, along with the paragraph(s) noted next, trim off some of the less prominent, less interesting functions (i.e., focus on those directly connected to the failure and its solution).<\/p>\n

From there, continue with 1\u00a0\u2013 2 paragraphs describing your reasoning for why this is the best solution concept.\u00a0 Include highlights of the engineering that supports your decisions, as related to at least three (3) engineering requirements.<\/p>\n

Conclude with a brief paragraph describing solution concept design decisions related to safety and manufacturability<\/strong>.<\/p>\n

4.3\u00a0\u00a0\u00a0 Subsection 3\u00a0\u2014 Continuation Planning<\/h3>\n

The third and final subsection will be shorter, 4 short paragraphs, maybe 20% (about 1 page, 1 page max<\/strong>) of the total of the Content for Review<\/em> section.\u00a0 The first paragraph of this subsection is written for you. \u00a0This subsection is where you convince your audience that you have a solid, three-fold plan to complete the project.\u00a0 To use the specific wording from the CSR stage\u2026 you need to persuade your review panel that you have:<\/p>\n