Lesson 30 is where every piece from six parts converges into one document. The thing every student must leave with: a proposal is an engineering communication, not a sales pitch, and its job is to give the customer enough accurate information to make a real decision, including the limitations. If they walk out treating the proposal as a document for persuading the customer, or softening a limit to make the system look better, the lesson didn't land. Teach the disclosure standard until they feel it, not until they can recite it.
| Segment | Min | What happens |
|---|---|---|
| Hook and the reframe | 7 | Open cold on the two-skills idea: engineering a system is one skill, turning it into a proposal a customer can sign is another, and most engineers train only the first. Land the design principle on the board: a proposal is an engineering communication, not a sales pitch. Ask who has seen a technically right system lose to a clearer one. |
| The eight deliverables + flow governs | 12 | Put the eight deliverables on the board. Point out that the Quoting Standards Guide names all eight, and land on Maintenance Requirements, the one new engineers skip. Note the executive summary leads the package. Then the governing idea: a quote built from a complete four-layer flow diagram can be defended line by line; one built before the diagram is finished rides on assumptions. |
| Limitations, unsoftened (roleplay) | 13 | The key teaching moment. Hand the room a proposal with a limitation buried in paragraph four. Play the business buyer. Then have them rewrite a softened limit as a stated number. Details in the key-teaching-moment note below. |
| Exceptions, assumptions, margin | 10 | Document the assumption, not the conclusion: "customer confirmed 20 CPM peak throughput on call dated," not "system sized for 20 CPM." An undocumented exception is a dispute waiting. Then where margin leaks: unsafe assumptions (an incomplete MTBH) and incomplete vendor scope (pull cords not in the electrical RFQ, VFDs not specified per motor). The gap between scoped and priced is the engineer's, because the engineer owns the scope. |
| The gate + reviewer (peer review) | 14 | Run the pre-quote gate as a live peer review. Pair students; each runs the other's checklist against the gated no-advance model. Steer them to find the open ! items themselves. Do not tell them. Ask. Land the independent-reviewer habit: a gap found at the gate costs nothing, a gap the customer finds after award costs margin, relationships, or both. |
| Forest and close | 4 | Students commit the Riverside proposal package and cleared checklist to their note. Close on the convergence: every earlier skill arrived in one document. Next lesson carries it into the room. |
| Total | 60 | Baseline session. Expand with the stretch options below if you have 90 minutes. |
Hand the room a proposal with a limitation buried in paragraph four of section three. Play the business buyer and ask, flat: did you know this system cannot handle packages over 30 pounds? Watch the reaction. It was technically in the document, and nobody read it. Then ask the student where that limitation should have been. That question turns "limitations are important" from a slogan into a rule they feel.
Follow it with the unsoftened standard. Give them a softened line, the system is optimized for packages up to about 28 pounds, and have them rewrite it as a stated number: the system maximum product weight is 28 pounds. Make the room say why the soft version protects nothing. The customer who finds a 35-pound carton jamming the sorter three weeks after go-live doesn't remember a gentle qualification. They remember that nobody told them the number.
Every one of these traces back to treating the proposal as persuasion instead of engineering communication. Drive each back to the standard: enough accurate information to make a real decision, limitations included.
Have students assemble the Riverside proposal package from the six-part structure: executive summary, system description, system limitations, assumptions and exceptions, cost driver discussion, and the maintenance conversation. Check one thing specifically: does the maintenance section address Michael by name? That is the single strongest tell in the whole capstone that a student understood the audience. A student who wrote a generic maintenance paragraph missed who they were writing for.
Run the pre-quote gate as a peer review. Pair students and have each run the other's checklist against the gated no-advance model. When you see an open ! item, do not point at it. Ask a question that walks them to it themselves: was the controls quote reviewed against the design scope? Is the maintenance section written? The habit you're building is that a second set of eyes finds what the author can't, and that the gate is where a gap still costs nothing.
Question 1 (the buried, softened limitation). Two things wrong. First, placement: the limit sits in paragraph four of the system description instead of its own labeled System Limitations section, so a reader, especially a business buyer, never lands on it. Second, wording: "optimized for packages up to about 28 pounds" reads as a soft preference, not a boundary. Where it belongs: its own labeled section every reader sees. Why placement matters after installation: buried, the customer signs assuming the system handles their product, then a heavier carton jams weeks later and they were never really told. Why wording matters: the correct form is a stated number, the system maximum product weight is 28 pounds. Strong answers name both faults, move it to its own section, and tie the softening to the false assumption the customer walks away with.
Question 2 (the compressed-schedule gate). Both open items are marked ! , so both are gates, and the gated no-advance model says you don't advance past a gate with open items unless you have a documented reason and a plan to resolve it. So "the PM wants it out today" doesn't clear them. The model requires one of two paths: clear both before delivery (review the controls quote against the design scope; write the maintenance section), or, if genuinely blocked, document each open item with its resolution plan and get sign-off before anything leaves. Name the specific risk in each: an unreviewed controls quote is exactly where margin leaks as a post-award scope gap; a missing maintenance section is the eighth deliverable and, at Riverside, the one Michael is owed. Hand the independent reviewer the completed checklist and the package, and ask them to confirm the two open items and their plans, not rubber-stamp them. Strong answers refuse "just send it" and separate the vendor-scope gap from the missing deliverable.
This is the convergence lesson, and it's where the project-folder habit from Lesson 1 pays off. A student who kept the folder from the start already has the layout, the MTBH table, the flow diagram, the calculations, the limitations, the safety and maintenance requirements, and the business case saved. For that student the proposal is assembly, not creation. They open the folder and the package is most of the way built. The one who scrambled to reconstruct the folder is rebuilding work they already did.
Never say this to the room. The reveal belongs to the student who lived the discipline, and it hits home for the one who kept the notes without being told why. Your only job across seven parts was to make the habit feel normal. If they built it, the payoff is theirs to find when they sit down to assemble this package.