* 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. 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 — Final System-Level Concept
This subsection will comprise one figure (consuming about ½ a page) and 3 – 4 paragraphs, about 40 – 50% 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 and your thinking behind getting there, your “why” behind the decisions that culminate in the final result.
The first paragraph will begin as provided in the template with “A graphical rendering of our selected system-level concept is provided in Figure 1.” This first paragraph should continue (select “CONTINUE HERE-FSLC1” and start typing) by thoroughly, but concisely, describing how your selected system-level 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 system-level 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 1 should just about consume one page.
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-FSLC2” and begin typing. Here, functionally describe your system-level 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, and 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 and/or less interesting functions.
From there, continue with 1 – 2 paragraphs describing your reasoning for why this is the best system-level 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 system-level concept design decisions related to safety and manufacturability.
4.2 Subsection 2 — System-Level Design
This subsection will likely be 3 – 4 paragraphs, about 30 – 40% of the total of the Content for Review section (1½ pages max). This subsection should begin with the text included in the template, that is, “Our preliminary/feasibility engineering supports our selected concept’s potential to meet our engineering requirements. Results are found in Subsection 5.3 of our accompanying TAD, with details in TAD Appendix C. Highlights of that work include” then select “CONTINUE HERE-SLD” and begin typing.
This is where you persuade your audience that your selected system-level concept could work, i.e., that it could function in a way that meets the engineering requirements. To use the specific wording from the CSR stage… you need to persuade your review panel that 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 the concept.
This subsection must summarize your preliminary/feasibility engineering work that provides support of your claim that your final system-level concept can work. GET QUANTITATIVE! We are engineers, and this is the engineering behind (in support of) YOUR SALE. You are selling your audience to further invest in you (your team) and the continuation of your project based on this concept — by the way, side-note, the correct phrase used here is “based on,” not what many use these days — “based off of.”[1][2] You should cover three (3) unique elements of engineering work (“unique” meaning that some engineering requirements will employ the same engineering methods; we are interested in three methods, not three requirements covered by the same/single method).
4.3 Subsection 3 — Continuation Planning
The third and final subsection will be shorter, 4 short paragraphs, maybe 20% (¾ – 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 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 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] http://www.quickanddirtytips.com/education/grammar/based-off-versus-based-on
[2] http://itknowledgeexchange.techtarget.com/writing-for-business/based-off-based-on/
| © 2017, William J. Endres | Updated February 18, 2023 |