* This is ONLY for “Failure-Resolution” Projects. | For Standard Projects go here.
Before continuing, if you have NOT reached the point of
system-level concept generation and assessment,
see the program director prior to completing your documents for submission.
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 TAD and your PPD, updated with refinements and with ALL progress up to 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 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). 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. As with your CSR tech-memo, this one begins with a brief Memorandum Overview indicating these as the elements of content here with direction to the accompanying documents.
1 Memorandum Overview Section
Like the CSR, this is again written on your behalf. BUT, read it carefully so you understand what your audience is expecting to see. It also 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 CSR tech-memo. To bring this content in, select the content in your CSR 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.
That’s it? Like for the CSR, your best two writers should take one more (and final) time through to make this the best you possibly can. This is the first piece of “Decision-Critical Documents — Make the Opening Count” (Section 2 of Chapter 5 in Math to Mettle) as described in the book. 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.
Don’t think that after another four weeks since the CSR you cannot tune it up just a little bit more. Maybe not a full hour of rework this time, but a half hour by each of the two best writers. However, it is NOT UNCOMMON for a team to have a SUBSTANTIVELY refined understanding, or an understanding that has outright changed as the project evolved in and through the concept selection stage. In this case, give this section an equally substantive updating in the appropriate paragraphs. 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 — and with great effect. Remember… Make the Opening Count!
And if introducing a graphic helps, DO SO… a good one (often occupying less space than trying to explain with text!). Still, your page limit remains one page, including the section title. That is, it cannot spill onto page 3 of the tech-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, from the original writing of this content, if helpful in support of your efforts here.
3 Engineering Requirements Section
This is a direct carryforward from the CSR. To bring this content in, like above, select the content in your CSR tech-memo (the “Engineering Requirements” section less the section heading) and copy. Then, in the PCR 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 CSR tech-memo, will be correct 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, this section of the tech-memo, in the format provided in the template (paragraph style “Normal text” in Google Docs), should be approximately 4 – 4½ pages (4½ pages max; be complete but you must also be selective to make it fit and not spill over to a fifth page!) . Add to that graphics (table and figures). That means that with graphics of legible size it may be 7 – 8 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 stage… 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 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.
As a reminder again from the CSR 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 and PPD (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 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 three (3) subsections as described below.
4.1 Subsection 1 — Root-Cause Failure Analysis
This subsection will comprise one figure (consuming about ½ a page), possibly more graphics/figure(s) as needed to convey your results (see below), and 3 – 5 paragraphs, about 35 – 45% of the total of the Content for Review section (2 pages max). When it comes to describing the results of your root-cause analysis, remember this is not a diary; don’t 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. First cover results of any intermediate steps, and then the final result that derives from those intermediate steps.
The first paragraph will begin as provided in the template with “Figure 1 illustrates the overall existing system in which the noted failure takes place.” 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. This first paragraph should continue (select “CONTINUE HERE-RCFA1” and start typing) by thoroughly, but concisely, describing the plan you executed to determine the root-cause of failure. There is no need to describe the failure itself, under the presumption that you already described it in the Problem Understanding section.
The second paragraph (select “CONTINUE HERE-RCFA2” and start typing) begins describing the results of your root-cause analysis. Spread this into 2 – 3 paragraphs as makes sense to break the findings down in a logical way. 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 “Table # Xxxxx” above the table (figure captions being below a figure). Repeating 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.
Conclude with a final short paragraph summarizing the root cause and, in general terms, what you will do to resolve it. On the latter, don’t get detailed; the details of your resolution, or solution, come-in immediately in the next subsection.
4.2 Subsection 2 — Solution Design Progress
Usually in these types of projects, the solution to the failure addresses a portion of the overall existing system. Your solution is still generally a combination of multiple function-level concepts as the makeup of a “system.” But, not being the whole or overall system, to avoid confusion, refer to it here as your “solution” concept/design rather than “system-level” concept/design. 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.
This subsection will comprise one figure (consuming about ½ page) and 3 – 4 paragraphs, about 35 – 45% of the total of the Content for Review section (2 pages max). Remember again, this is not a diary; don’t 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.
The first paragraph will begin as provided in the template with “A graphical rendering of our likely solution concept is provided in Figure 2.” This first paragraph should continue (select “CONTINUE HERE-SDP1” and start typing) by thoroughly, but concisely, describing how your likely (top candidate for final[1]) solution concept works and how it is made. This is a fine-tuned version of what is on its system-level concept datasheet of TAD Subsection 4.1. 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. And I mean A REALLY GOOD ONE. One you may adjust and tweak FOUR OR FIVE TIMES over a couple days and then place back into Subsection 4.3 of the TAD. 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. The first paragraph and Figure 2 should just about consume one page. Adjust the figure number in the text and caption if you used more than one figure in the preceding section.
The next paragraph, after the figure, should begin with the text included in the template, that is, “From a functional standpoint, the system” then select “CONTINUE HERE-SDP2” and begin typing. Here, functionally describe your solution concept, referencing Figure 1 as appropriate. You are expanding on the “how it works” of the first paragraph, but without being repetitive (make the earlier coverage more concise as needed to avoid that). 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–3-word concept names/identifiers. That is, however you lay it out, do not just use the names of the function-level concepts; rather, describe them in brevity. 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). 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. 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).
From there, continue with 1 – 2 paragraphs describing your reasoning for why this is the best solution concept. Include highlights of the engineering that supports your decisions, as related to at least three (3) engineering requirements.
Conclude with a brief paragraph describing solution concept design decisions related to safety and manufacturability.
4.3 Subsection 3 — Continuation Planning
The third and final subsection will be shorter, 4 short paragraphs, maybe 20% (about 1 page, 1 page max) of the total of the Content for Review section. The first paragraph of this subsection is written for you. This subsection is where you convince your audience that you have a solid, three-fold plan to complete the project. To use the specific wording from the CSR stage… you need to persuade your review panel that you have:
- a technically sound plan 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.
The second paragraph of this subsection should begin with the text included in the template, that is, “Some of the methods to be used in our preliminary/feasibility engineering (ref. TAD Subsection 5.2), and later in detail-design engineering (ref. TAD Subsection 6.1), include” then select “CONTINUE HERE-CP1” and begin typing. Provide a summary of supporting engineering methods you will be applying in your preliminary/feasibility and detail-design 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).
The third paragraph of this subsection should begin with the text included in the template, that is, “Some of the methods to be used in our prototype testing (ref. TAD Subsection 6.2) include” then select “CONTINUE HERE-CP2” and begin typing. Provide a summary of supporting engineering methods you will be applying in your prototype testing work. You should cover three (3) unique elements of engineering work to be done (“unique” meaning … (see above)).
Conclude with a short fourth paragraph referencing your Term-II tasks list and timeline in the accompanying Project Planning Document (PPD). I could provide this last sentence (or two) for you, as boilerplate, but with the many examples thus far, think about how to state it in our own words. Then close with affirmative statements that you will meet your budget (give numbers — expected cost and the allocated budget and any supplement, noting evidence supporting the secured supplement). Remember, this audience is not well versed in our acronyms, like PPD.
Google Docs is a trademark of Google LLC.
[1] In those projects where the root-cause must be first identified you may not have determined a best solution concept by the PCR stage. This is rare, but does happen at times. For this reason, the solution concept is referred to as the “likely” concept. If you have not concluded on a best solution concept, focus on the best of the latest complete round of solution (system-level) concept generation and assessment. If you have concluded on a best solution concept, great. However, even in this case, there is a good chance you have not completed the preliminary/feasibility engineering work yet; those results, soon down the road, could bring adjustments to this “likely” solution then making it “final.”
| © 2017, William J. Endres |
Updated February 18, 2023 |
