Session 12. The expert meeting, RFI/RFC/RFQ and the proposal: how a conversation about the company becomes a conversation about the project

20 October 2026 · Lecture 7 · 1 h 26 min 48 s. Based on the automatic transcript IgorSikorskyKPI_L7_20102026.mp4. This is an edited teaching note, not a verbatim transcript: obvious recognition errors were corrected and terminology was aligned with earlier sessions. The customer Otto, his company and the technical task are a teaching scenario. The industrial installation example was given by the lecturer only in general terms, without details covered by an NDA. The session was interrupted by an air-raid alert; this did not affect the content of the note.

Where this session fits: the last step before a concrete request

In Sessions 10–11 the team moved from an exhibition contact to the first follow-up: it presented the company, its expertise, locations and tools, and heard what really "hurts" the customer. Session 12 covers the second follow-up — an expert meeting after which the conversation must move from "who we are" to "which project we are doing". The main outcome of this meeting is a formal request from the customer: an RFI, RFC, RFQ or requirements straight away.

The lecturer stressed that everything in the course consists of recommendations based on his own experience and that of colleagues, not the only possible procedure. They should be adapted to the specific customer, market and company culture.

0. Organisation: assessment and the large independent assignment

• The course credit can be obtained automatically with 60 points or more; students below that threshold take a written credit test.
• Attendance also earns points, so being present matters.
• After the second assessment there will be a large independent assignment — simulating an engineering company: a static website, a simulated trip to a conference or exhibition, obtaining a lead, converting it into a customer, requirements, a proposal, a project in GitHub or Jira, team allocation and a release. The work will be accompanied by regular meetings, roughly twice a week.
• Examination questions will cover the whole course; the list will be provided in advance.

1. Why a second follow-up

The first meeting at the conference created an acquaintance. The first follow-up presented the company broadly: years on the market, engineering capacity, competences, tools, locations, certifications. Its real purpose was to understand what hurts the customer and which "pill" should be offered.

In the teaching scenario the customer Otto wants non-destructive diagnostics of an internal combustion engine: without dismantling the engine and without human involvement, check whether the camshafts, valve rocker arms or chamber walls in the cylinder head are damaged. Dismantling is expensive and immediately requires replacement parts, so the value of a solution is obvious. The second follow-up is the meeting where the company shows narrow expertise for exactly this problem. The ideal result is to convert Otto into a customer already at this stage.

2. Decomposing the problem: who is needed in the meeting

Even a short description of the problem immediately breaks down into several engineering disciplines:

That makes five strong specialists. But if this group simply turns up at the meeting, it will fail: Otto will be overwhelmed by the number of people, and unprepared experts will just stare at him in silence. That is why homework is required.

3. Homework: a tailored presentation and a message to the customer

The previous presentation covered the whole company: web, mobile, cloud, AI, embedded, automotive, robotics, fintech, healthcare, mining. Now it has to be rewritten for the identified need. The number of offices and the overall size of the company are no longer relevant. The key message is roughly: "As a follow-up to our previous meeting, we would like to show our expertise in the topics we believe are useful specifically for you. We have prepared several cases and would like to hear how closely they match your problem."

The expected outcome of the meeting is a deep understanding of the problem and of possible ways to solve it. You need to establish exactly what the customer already has. Perhaps hardware, firmware and mechanics are ready and only engineers are missing. Perhaps there is nothing, and then the proposal must describe the full vision: from the system level to the implementation.

Play fair: tell Otto that you are preparing a new presentation and will bring your specialist experts. He can then bring his own specialists and prepare documents that explain his need better. If the customer agrees to such a second meeting, mutual interest has already been established.

4. The invitation: time slots, communication tool and agenda

An invitation to the expert meeting has three mandatory components.

1. Time slots. Offer about three options one day apart and spread them across morning, midday and evening. Always leave room for the customer to propose a time of his own.
2. Communication tool. The first meeting took place in the environment convenient for you, for example Google Meet. Now ask what the customer prefers: Google Meet, Microsoft Teams, Slack or something else. If he chooses Teams, organise yourselves to generate the invitation there. Adapting to the customer's business tools shows flexibility and respect.
3. Agenda. The person must understand what he is being invited to. List five or six items, for example: a short recap of the context, decomposition of the task, cases by discipline, discussion of the customer's problem, next steps.

A good invitation simultaneously shows respect, flexibility, an investment of time and money, and a concrete goal. This is exactly the kind of message a customer reads as a sign of a good deal.

5. One email thread from the first contact to the contract

All communication — the first email after the conference, agreements, invitations, presentations and follow-ups — should be kept in one email thread. After the contract is signed, this thread is closed and a new, engineering thread is started.

The reason is practical: when escalations arise later, it is easy to find the original agreements and show exactly how they were worded. At the start both sides are, so to speak, in love, but projects sometimes end in conflict. For the "divorce" to follow rules that are favourable and transparent for you, you need a signed contract and a documented history of agreements.

6. The cost of an expert meeting

From this point on, pre-sale starts to cost real money. Four or five highly qualified architects and leads are the most expensive people in the company. As soon as they take part in a meeting, their time has to be paid for, even though there is no project yet. So decide in advance exactly whom to bring, how many people and how long the meeting will be. It is an investment that must be consciously limited.

7. Roles in the meeting: the familiar face, Engagement and the experts

The lecturer used a hunting analogy: there are beaters, who drive the game along the right path, and shooters, who wait at their positions. Engagement are the beaters; architects, engineers and the familiar face are the shooters. In companies, engagement is often a separate unit of people who are always full of energy and keep up the pace of communication.

Who shares the screen first? The one who invites. You assembled the team and prepared the presentation, so you start sharing.

8. Meeting script

1. Warm-up. The Engagement Manager greets Otto, asks how he and his business are doing and asks a few prepared questions that he senses are of interest to the customer. Everyone's camera is on: Otto must see the familiar face.
2. Round of introductions. If time is short, Engagement quickly names each participant and role. If there is more time, or he is confident that colleagues present themselves well, each person introduces himself or herself.
3. The customer introduces himself. Engagement asks Otto to introduce himself — not because he is unknown, but as a sign of respect. If colleagues came with him, they introduce themselves too.
4. Opening slides. Engagement shows the agenda and the system decomposition: robotics, computer vision, AI, embedded.
5. Expert cases. Engagement hands over control of the presentation to the experts in turn: two cases on computer vision, two on robotics and so on. After each block he asks: "Otto, what do you think? Does this resonate with your problem?"
6. Asking the customer. After the last block, do not wait for the customer to start talking on his own. Ask directly: "Please tell us what your problem is and what exactly you are trying to solve. We want to understand how we can help."
7. Open discussion. For about 10–15 minutes the experts of both sides talk directly.
8. Summary and next step. Engagement summarises the conversation and offers to prepare a proposal.

The lecturer compared the architect to a lift operator in a high-rise building: he asks which floor you need and on the way learns what is happening on each floor. The architect carries information between levels of the system and between people, pauses on slides, asks again, notices a raised eyebrow, a look away or the customer reaching for his phone.

9. Open discussion with a conductor: the second screen and the internal chat

When the open discussion starts, every member of your team should have two screens: one shows the conversation with the customer, the other the team's internal chat. Engagement, the manager and other non-engineering participants stay out of the technical debate. They watch and steer: if one of the engineers enters an unnecessary dispute or pressures the customer, a short "stop" appears in the chat and the colleague changes tone.

It is an orchestra, and the internal chat is the conductor's baton. Openly contradicting the customer at this stage is risky; support and clarification work better.

10. Closing: the promised request and the reminder "lever"

At the end Engagement says something like: "The intensity of this conversation shows that we speak the same language and understand how to do this. Let us prepare a proposal for you." The customer replies that he will send an RFI, RFQ or RFC. The team, in turn, promises to send the presentation as a follow-up.

This promise is a lever. If the customer forgets to send the request, the email with the presentation becomes another natural occasion to remind him: "Here is the promised presentation; we are waiting for the RFI." The customer often has not written the request document yet: he will not say so in the meeting, but will spend a day or two on a spreadsheet of questions. After a few reminders the request usually arrives.

The key change after this meeting: before it, the conversation was about competences, the company, the team — about anything except the project. After it, the entire conversation concerns the project the customer is interested in.

11. What the customer may send: "asking" or "telling"

As in Session 04, RFC here means Request for Clarification in course terminology. In wider procurement practice, a request to "describe your solution" is more often called an RFP (Request for Proposal), while in software engineering RFC usually means Request for Comments. So in a real process the document name should be spelled out on first use.

12. RFI: a spreadsheet of questions with a "false bottom"

A typical RFI is an Excel spreadsheet: one column of questions and a second one for answers. Examples of questions from the lecture:

• Do you have Model-Based Development competence? Follow-up: which tools do you use for model-based development and for model-based testing? A possible answer: MATLAB/Simulink, OpenModelica; for testing — Simulink Test, for model and code coverage — Simulink Coverage.
• Do you have expertise in Embedded Engineering? Follow-up: which microcontrollers do you work with? The answer is a list of families, for example STM32 (STMicroelectronics), NXP, Xilinx (now AMD).
• Do you have experience with System on Chip (SoC)?
• Is your company, or are the engineers assigned to the project, certified against a functional-safety standard? If so, which one?

Follow-up questions need no answer if you answered "no" to the main question. An RFI ranges from one page to 10–20 pages. Such questionnaires often have a "false bottom": the same question reappears elsewhere from a different angle to test consistency. Your answers must therefore not contradict each other.

Expect the customer to analyse your answers against his own template, possibly with AI, and score your technological fit. That is no reason to embellish: untruths surface sooner or later. If you do not meet the requirements, this is simply not your customer.

13. RFC and the proposal: how much to disclose

Sometimes after the meeting the customer realises that you understand the process better than he does. He then sends neither requirements nor user stories, only a short RFC of two sentences: "Hello. Could you please describe in Word, Markdown or another format your vision of a solution to our problem discussed in the meeting?"

The answer to an RFC is a proposal, whose structure was covered in earlier sessions: summary, architectural view, design view, implementation plan, risks, commercial section. It can run from two pages to a hundred; the largest proposal in the lecturer's practice had about a hundred pages. Architects write it, and the team invests its own time. An RFC immediately after the meeting is a very good sign: the customer does not know how to solve the task and wants you to show creativity.

The danger, accurately named by one of the students in class: the team creates, free of charge, a document that effectively solves the problem, and the customer says thank you and disappears. The lecturer gave an example from his practice (without details because of an NDA). A large plant had an installation with a hazardous leak that could not be measured directly. A mathematical and computer model of the leak into the environment was needed. In the proposal the lecturer described a method for determining the leak volume based on MATLAB/Simulink modelling and analytical calculations. The customer then thanked him and disappeared: the local engineers had enough to implement the solution themselves.

The line between "too little" and "too much" is very thin. Too little, and the customer will not believe you can do it. Too much, and he will do it himself.

14. Proposal format and versioning

Historically, a proposal is written in a word processor (Microsoft Word, LibreOffice, OpenOffice), because it combines text, illustrations, formulas and tables. Mandatory attributes of such a document:

• author — the person who created the initial version; remains the author permanently;
• last changed by — who made the latest changes;
• revision history at the beginning of the document — what exactly changed between release versions and in which sections.

The number before the dot is the release number for the customer; the number after the dot counts internal iterations. However many times the document goes back and forth inside the company, the first version sent out is always 1.0.

The lecturer prefers Excel: each tab works as a separate section (introduction, architecture and so on), the data are structured, and the financial part — quantity, duration and cost — can be calculated directly in the document, transparently for both sides. In the AI era Markdown has spread: it is a convenient format for joint work between people and language models, and small modern companies readily accept it. Large conservative companies have their own rules on AI use, so with them it is better to work traditionally at first, in Word or Excel, and to propose Markdown later if they have that practice.

15. RFQ: part of the first proposal and a quarterly request

The first proposal always contains a commercial section: quantity and price — the cost of engineering time and material resources. At the start, therefore, the RFQ is closely tied to the RFC.

The RFQ becomes a separate document after the project starts: roughly once a quarter the customer asks for an estimate of the next quarter's costs. By then Jira, a GitHub Project or another tracking tool exists, but the forecast of future costs is still issued as a document. It covers engineering work, materials and related costs such as courier and postal services.

Another common path: the customer iteratively reviews your proposal and returns comments ("rewrite this part differently"). In effect he is building the architecture of the future system at your expense. It is a shrewd approach, but in the lecturer's experience such stories usually convert into a contract.

16. The best case: requirements and a team estimate

If the customer knows well what he wants, he sends requirements at three levels: system requirements (how the system behaves), software requirements and hardware requirements. In that case you are expected to provide an RFQ already at the first stage.

One person cannot estimate the whole system. You need to gather the team, ask each member to estimate individual features or requirements and describe how they see the implementation. The list of expected durations becomes the answer to the RFQ, for example: "feature X — 2 to 10 days at a rate of 400 US dollars per day for an engineer of a given level" (the rate is illustrative). This shows the customer what kind of money is involved.

17. Problems that estimation will bring

The estimation stage comes with internal problems — they will be the subject of the next sessions:

1. No one to estimate. In the "golden age" of Ukrainian IT (roughly 2016–2018, before COVID-19), companies kept engineers in a "pool" on the bench, ready for new projects. Today this practice has almost disappeared.
2. Involving external experts. A specialist you know from another company can help, but has to be paid; a payment model is required.
3. Freelancing as a source of resources, and its risks.
4. Accountability for the estimate. An external expert may underestimate a task because he will not be the one doing it. How do you obtain a thoughtful estimate, and how do you bring the people who estimated into the project?
5. Cost of engineering and of the product. In embedded, engineering time is joined by mechanics, PCB design, component procurement, assembly, validation and verification, logistics and customs clearance.
6. Risk analysis of late delivery for both sides.
7. Fixed Price or Time & Material in today's European embedded practice.

Practical takeaways

• The second follow-up is prepared for the customer's specific problem, not for a general company profile.
• The invitation contains several slots, a choice of communication tool and an agenda.
• All communication before the contract is kept in one email thread.
• The familiar face is always present, Engagement runs the meeting, and experts present cases and ask questions.
• The goal of the meeting is to obtain an RFI, RFC, RFQ or requirements; without them further work is a waste of time and money.
• RFI answers must be honest and consistent with each other.
• The depth of a proposal depends on where the complexity lies: in the technology or in the technical implementation.
• A proposal has an author, a revision history and a clear version numbering.

Self-check questions

• How does the second follow-up differ from the first in purpose and presentation content?
• Which specialists should be involved in the non-destructive engine diagnostics task, and why not all of them at once?
• What must an invitation to an expert meeting contain?
• Why keep all correspondence before the contract in one email thread?
• What is the role of the familiar face, and why does that person write the very first email?
• Who shares the screen first, and who opens the meeting?
• Why does the team need a second screen and an internal chat during the open discussion?
• How does the "customer asks" mode differ from the "customer tells" mode?
• What is the "false bottom" in an RFI, and how do you avoid the trap of contradictory answers?
• When should a proposal be written in general terms, and when in maximum detail?
• How does the proposal version number change between internal reviews and submissions to the customer?
• Why does the RFQ exist separately from the RFC once the project has started?

What was announced next

The lecturer announced for the coming sessions: human resources for estimation when the "pool" is empty, paying external experts, freelancing, accountability for estimates, cost analysis of engineering and hardware, risk analysis, and a comparison of Fixed Price and Time & Material. The course will then move on to signing the contract, user stories and internal requirements, team decomposition, hiring and defining management roles. Separate practical sessions will be devoted to writing a proposal and completing an RFI. This is an announced plan, not sessions that have already taken place.

Verified references

• ISO/IEC/IEEE 29148:2018, Systems and software engineering — Requirements engineering: https://www.iso.org/standard/72089.html
• Simulink Test (MathWorks): https://www.mathworks.com/products/simulink-test.html
• Simulink Coverage (MathWorks): https://www.mathworks.com/products/simulink-coverage.html
• OpenModelica: https://openmodelica.org/