Session 08. Practical Workshop: Auditing Business Artifacts and Structuring a Technical Proposal

30 September 2026 · practical session · 1 hour 16 minutes 22 seconds. Source: transcript P3. Because of air-raid alerts and incomplete attendance, the session partly became a demonstration and individual review. Plans for a repeat workshop mentioned in the source were proposals, not confirmed events.

The session's place in the course narrative

On 29 September, teams were assigned to create a corporate identity, personal contact cards and a one-pager. On 30 September, it was time for review: do these artifacts meet consistent requirements and can they actually initiate technical cooperation? The second part illustrates what follows an exhibition: request → technical proposal → proof of concept → staged delivery.

1. Reviewing student business cards: operational defects

The lecturer reviews materials submitted by two groups. Positive features include a consistent palette, logo, defined roles, corporate contact details, two-sided cards and QR codes. A basic audit nonetheless reveals defects: surname before given name in English; one color system for cards and another for the one-pager; mismatched domains on the cards and poster; an incorrect partner logo; an inaccurate illustration of a platform; and missing direct contact information on the one-pager.

These defects should not be excused simply because the work is educational. They reproduce typical integration failures in which two deliverables are designed independently although both should describe exactly the same product or organization.

2. Who is who in an engineering company

Student roles provide an opportunity to discuss a common, though not universal, corporate hierarchy:

Owners → C-level → functional directors → managers → engineers and specialists.

An owner owns the company; the CEO manages it within defined corporate authority; the CTO and CFO are accountable for their respective functions. A director leads a major discipline and may have a delegated budget; an engineering, project or technical manager coordinates execution and escalation; engineers and technical leads produce technical outcomes. Formal authority and budgets depend on the actual company, legal structure and policies. This is an educational example, not a legal rule.

Senior, Middle, Junior and Trainee denote competency grades used in staffing and compensation, not management positions and not automatic spending authority. A Lead Engineer should have a real technical-coordination responsibility, usually involving a team whose existence and responsibilities ought to be reflected in the proposed organization chart.

3. Why a one-pager needs an evidence-based structure

The review identifies strengths in the student one-pagers: a recognizable embedded focus, ECU/ADAS/verification as competence areas, clear descriptions of roles and small-scale production capability. Yet the material may be overloaded with text and lack enough technical visual explanations. Another problem is an unfocused service list: automotive ECUs and EV charging stations may both be valid areas of work, but should be presented as distinct directions, each linked clearly to the team's expertise.

Key check: if a potential customer stops at the booth, can they identify the team's specialization within ten seconds? If not, revise the information hierarchy and strengthen the connection between the technical visual and the value proposition.

4. From RFI / RFQ / RFC to a proposal

Following a conference introduction and a follow-up meeting, a prospective customer may send:

• RFI — Request for Information: questions about capability, track record, tools, resources and the company's delivery capacity.
• RFQ — Request for Quotation: a request for cost estimates, pricing assumptions, licences, equipment and expenses.
• RFC — Request for Clarification: in this course scenario, clarification of an approach to solving a technical problem, followed by a proposal. Other fields use the abbreviation RFC differently; interpret it according to the actual customer's context.

A proposal is not simply a price list. It combines an engineering model, verification approach, delivery plan, team and commercial framework. In the recording, the lecturer presents an anonymized real proposal for an ECU Switching System, developed after several technical meetings. Numerical details and project stories are retrospective professional experience, not templates or norms valid for every project.

5. Structure of a strong technical proposal

1. Executive Summary. Why the project matters, its value, planned stages, indicative duration and budget, and engagement model.
2. Glossary / Abbreviations. Shared terminology for engineers, procurement and management.
3. Introduction and communication history. Background, subject, agreements and assumptions.
4. Requirements baseline. Received documents and references, requirements and outstanding uncertainties.
5. High-level architecture. System structure, interfaces, data paths, power and control.
6. Detailed design hypotheses. Candidate modules, components, physical concepts and dependencies.
7. Validation and Verification. The strategy for demonstrating that the solution works as required.
8. Stages, deliverables and schedule. PoC, minimum useful product, documentation, milestones and Gantt chart.
9. Team and resources. Engineering roles, allocation, work sequence and capacity.
10. Commercial framework. Fixed Price or Time & Materials, exclusions and assumptions.
11. Appendices and version history. Detailed drawings, lengthy tables and revision tracking.

This is one example of an engineering proposal structure; individual customers may request a different order. The lecturer stresses that executives are likely to begin with the Executive Summary, whereas technical reviewers examine diagrams, assumptions and test methods. In the cited 40-page example, a substantial portion is devoted to architecture and the detailed breakdown of modules.

6. Architecture before contract: prove that the problem is understood

At proposal stage there is no finished product. However, a modular concept, CAD sketches, a block diagram, interface descriptions and selected physical evidence allow the customer to assess the feasibility of the solution. Visualization must complement technical reasoning: a picture addresses “what might it look like?”, whereas an engineering schematic addresses “how would it work?”.

In the ECU Switcher demonstration, the lecturer describes a PoC built on an evaluation board, UART communication, an experimental bench setup and thermal imaging. This is an example of reducing engineering risk early; it is not proof that a final device complies with all requirements. The public notes do not reproduce confidential customer files or commercial figures from the case.

7. PoC → MVP → documentation and repeatability

A PoC tests a risky engineering hypothesis. An MVP provides the minimum functionality that delivers practical value and must have explicit acceptance criteria. Production documentation makes it possible to repeat assembly, testing and support. Each stage requires defined outputs: a demonstration record or PoC report; a list of accepted MVP functions; and the source files and production instructions needed for reproduction.

An illustrative estimation expression (not a statistical formula): E = Σ(rᵢ × tᵢ), where E denotes estimated person-hours, rᵢ is the number of specialists in role i, and tᵢ is the estimated effort per specialist in that role. This is a simple consistency check on the resource plan; a financial estimate also needs rates, reserves, materials and explicit assumptions.

8. Commercial model and revision control

The illustrative project used Time & Materials because its technical subject was novel and the scope could not be fully predicted. This does not remove the need to monitor and agree budgets, duration, changes, risks and work scope. A proposal may undergo several revisions; after initial review, maintain a version/change log recording version, date, changes, author and the customer's decision.

9. Student assignments and acceptance criteria

1. Audit every business card and one-pager using the defect checklist.
2. Create a concise organization chart with responsibilities, and explain every participant's role.
3. Identify one customer problem the company could solve, distinguishing the need from a preferred technology.
4. Draft the table of contents for a proposal addressing that request.
5. Select the riskiest hypothesis and define the smallest PoC capable of testing it.
6. Prepare verifiable references and do not portray fictional role-play partnerships as real.

Outcome: the team is prepared for a realistic customer-meeting simulation. The next session enacts the initial contact, objections and agreement to follow up; writing the detailed technical proposal will be a task for the subsequent stage.