* 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.
| © 2017, William J. Endres | Updated February 18, 2023 |