A Way of Work for the Customer: Phases, Gates and Pricing Models
R&D, PoC, MVP and work packages with gates, the cone of uncertainty, a rough timeline, Fixed Price versus Time & Material, capped T&M and combined models.
Engineering notes
R&D, PoC, MVP and work packages with gates, the cone of uncertainty, a rough timeline, Fixed Price versus Time & Material, capped T&M and combined models.
Gates and the cone of uncertainty
FP, T&M and capped T&M
Combined models by phase and function
Full session notes
Complete English teaching notes derived from the Ukrainian transcript of 27 October and the lecturer’s draw.io diagram. All amounts and durations are illustrative.
Session 13. A way of work for the customer: phases, gates, the cone of uncertainty and pricing models
27 October 2026 · Lecture 8 · 1 h 26 min 07 s. Based on the automatic transcript
IgorSikotskyKPI_L8_27102026.mp4and the draw.io diagram the lecturer drew during the session. This is an edited teaching note, not a verbatim transcript: obvious recognition errors were corrected and terminology was aligned with earlier sessions. All amounts and durations are a teaching illustration for comparing models, not market rates. Editorial additions are marked separately.
Where this session fits: the lead has become a customer — what next
After the first follow-up straight after the conference and the second, expert meeting (Session 12), the lead agrees to work with you: "I can see you understand our problem, let's give it a try." At this point the customer is often slightly lost: he does not know where to start — "eat it all at once or bite by bite". That is exactly why he is looking for a contractor: you have the expertise, the staff and the experience, so you are better placed to give the right input than he is to guess it.
That is why the collaboration model becomes part of the proposal: how you will take the customer through the project from the first day to the last, what he will receive and what it will cost. The session examines this model in two dimensions — time (phases) and money (pricing models).
1. The contact person on the company side
The customer will certainly want to know whom he will be talking to. It is sensible to name the contact already in the proposal:
| Project scale | Who becomes the contact person |
|---|---|
| Long, branched, several teams and roles | A permanent manager (PM); if needed, additional roles: Scrum Master, agile coach, etc. |
| Compact, up to ~10 people in the team | One tech lead, technical manager or architect who covers both technical questions and team leadership |
| A short, separate workstream | The architect or tech lead responsible for that stream |
2. Project phases and their outcomes
The lecturer broke the whole timeline into typical phases. For each phase the customer must be told clearly what the start trigger is and what the outcome is — what exactly he takes away when the phase ends.

| # | Phase | Outcome for the customer | Gate after the phase |
|---|---|---|---|
| 1 | R&D (Research and Development) | Technical feasibility: yes or no, possibly with a short comment such as "yes, if we use this approach"; a narrower cone of uncertainty | G1 |
| 2 | PoC (Proof of Concept) | Hypotheses tested with real components and solutions; a demo that can be shown | G2 |
| 3 | MVP | Feature 1: minimal dependencies on other features and real value for the customer | — |
| 4…N | Work packages (WP 1 … WP n) | Incremental growth of product value, feature by feature | — |
| N+1 | Finalisation | Hand-over of artefacts and archiving of the project | — |
R&D: is it possible at all
The standard output of R&D is technical feasibility: can the idea be implemented with the current state of science and technology. The answer may be very short: "yes, it can" or "no, under no circumstances". The second result is a narrower cone of uncertainty (see Section 4).
PoC: "soldered together on your knee"
The lecturer distinguished two types of projects:
- innovative — with a large share of mathematics, science and search; they usually have both R&D and a PoC;
- technological — a smaller scientific component, but full of ready-made components and frameworks; they almost always have a PoC.
The essence of a PoC is not only to check that something could work (as research does) but to build something that actually works. Example: you need to check that two devices can exchange data over an optical channel. You build two primitive breadboards, fit them with the key components you intend to use in the final product, write a simple communication protocol and see whether it works. A PoC has no features — only functionality is tested.
MVP: the first feature with value
An MVP (Minimum Viable Product; in this course, "minimally useful product") is already a product with value, i.e. with features. The first feature implemented is one that:
- has the fewest dependencies on other features, so it can exist on its own;
- has minimally sufficient value for the customer, so it starts to pay back the investment.
Getting to an MVP is harder than it looks: you have to build the whole project ecosystem and set up the team core. The lecturer’s formula: ecosystem + team core + goal = MVP. An MVP does not generate money by itself, but it generates potential — like potential energy in physics: with it the customer goes to exhibitions and conferences and looks for investors, buyers and partners.
Work packages and finalisation
After the MVP comes a cycle of work packages WP 1, WP 2 … WP n: features are sliced and delivered one after another, adding product value. The last phase is finalisation: hand-over of artefacts and archiving of the project. Support, new features or other continuations are a matter for future agreements and are not part of the current workflow. Tell the customer plainly that you are open to further cooperation, but propose to move step by step — "eat the borscht spoon by spoon".
What the customer receives at the end
The minimum success criterion is a fully completed product in the form the customer wanted from the start. The full result is broader: the customer will want all artefacts produced during the work so that he can reproduce the product or continue development — with you or with another team:
- the product and its technical documentation;
- the development documentation needed to continue without you.
3. Gates: conditions for moving between phases
Gates (G1, G2) follow R&D and the PoC. A gate is a transition condition with three valid outcomes:
- Passed — move on to the next phase.
- Not passed, keep searching — another round of research or a PoC on other components, if the customer is willing to invest time and money. A PoC result may be so damning that it throws the project right back to the start and forces a re-assessment of the whole research.
- Not passed, stop — a hard stop: we leave the project.
There are no gates after the MVP; from there it is a sequence of features. Even so, the customer can stop after any phase — it is his money and his financial right.
Explained like this — R&D, PoC, two gates, MVP, a feature cycle and finalisation — the workflow stops being a "dark forest" for the customer. He sees that you treat risk professionally and manage it. That is why this scheme is worth presenting already at the first meeting about the proposal.
4. The cone of uncertainty

Imagine standing on the time axis and looking into the future. One month ahead you see fairly clearly how the project will go and what it will cost — the range of uncertainty is small. Four months ahead it is much wider: you are making more assumptions. The further ahead, the lower the accuracy of the estimate — for both time and money.
R&D lets you "move" the apex of the cone forward: you have covered part of the way, your knowledge of the project has grown, and you now build the cone from a new point — with a smaller error in what the project will eventually cost.
Editorial note. The concept goes back to Barry Boehm (1981); the name "cone of uncertainty" was popularised by Steve McConnell. In the classic version, at the initial concept stage an estimate can be off by roughly 0.25× to 4× of the actual value, and the cone narrows only when the team makes decisions that remove uncertainty. It does not narrow "by itself" as time passes — which is exactly why R&D and a PoC are so valuable.
5. A rough timeline for the customer
Next, approximate time frames are laid over the phases. The lecturer set them notionally for now; the course will examine separately where such estimates come from.
| Phase | Duration | Cumulative |
|---|---|---|
| R&D | 1 month | 1 month |
| PoC | 3 months (if the gate is passed) | 4 months |
| MVP | 0.5 month (≈ 2 weeks) | 4.5 months — the first value that can already be sold |
| Work packages (all features) | 7 months | 11.5 months |
| Finalisation (artefact hand-over) | 0.5 month | 12 months |
It is important to keep communication direct: the customer must accept that gates change any rules and may revise the entire plan. Your job is to convince him that each transition makes sense, but never to deceive him. Detailed feature estimates can be provided separately if the customer asks; the lecturer advises protecting yourself and not over-detailing at this stage.
6. Price: Fixed Price, Time & Material and "capped" T&M
The customer now understands what he gets and when. Next he needs to know how much it will cost. The same way of work can be described with several models.

| Phase | Fixed Price (FP) | T&M with an upper limit (T&M^) | Combined model |
|---|---|---|---|
| R&D | 100K | 60K ± 30 % | FP |
| PoC | 150K | 100K | FP |
| MVP | 50K | 40K | T&M^ |
| Work packages | 400K | 300K | T&M^ |
| Finalisation | 5K | 5K | FP |
| Total | 705K | 505K (estimate) | — |
The amounts are illustrative; in the session the lecturer quoted them alternately in dollars and euros. Finalisation is priced almost at the cost of shipping, as a "huge discount" for transparency.
Why the price for the same work differs so much
The key difference between the models is who carries the risk.
- Fixed Price: the risk is on the contractor. We planned it, we will hire the team, we are responsible for engineers, management, delivery, vendors, factories and any delays — none of that is the customer’s concern. He pays 100K and waits a month. If we miss — penalties. This responsibility is what the difference pays for: in the R&D example it is 40K (100K versus 60K).
- Time & Material: the customer pays for time and material actually spent; the risk of under-estimation is his.
The lecturer revealed a "secret" of the services business: the engineer receives the same salary regardless of the contract model — only the company’s margin differs. The margin is the difference between what the company pays the engineer and what it charges the customer for the engineer’s time. It funds offices, administration, lawyers, finance and service departments — tens, hundreds and thousands of people who support projects. In the example, the real engineering cost of R&D is about 10–30K; under T&M the company asks 60K, under FP 100K, and part of that difference exists precisely to cover risks if something goes wrong.
Which risks remain with the contractor under T&M
This was discussed with the students:
| Scenario | Whose risk under T&M | Consequence for the contractor |
|---|---|---|
| A key engineer falls ill and the team misses deadlines | The customer’s | No direct loss |
| Poor estimation makes the project cost grow | Up to a point the customer’s; the contractor even earns more | If the cost grows several-fold, the customer leaves and the company loses the profit it expected |
| The team fails to solve the task | Initially the customer’s | The customer leaves and never returns — a reputational blow |
Reputational risk hurts most with large customers (the lecture’s examples were Volkswagen Group and SpaceX): fail a 100-thousand project and you may land on a blacklist and lose far more money for good.
Under Fixed Price a failure hits the company with all three blows at once:
- lost profit;
- reputational loss;
- a contractual penalty — usually several times the value of the phase (the lecturer’s illustration: a penalty of about 400K for a phase worth 100K).
That is why FP can be up to twice as expensive as T&M, and you should choose it only when you are absolutely sure of what you are doing.
Two kinds of T&M
| Model | What the contractor promises | Responsibility |
|---|---|---|
| T&M (no limit) | An estimate for the phase, e.g. 60K | None: "we estimated 60K, we missed — sorry" |
| T&M^ ("with a cap", upper limit) | The estimate plus a tolerance for market drift; in the lecturer’s practice ±30 % | Reputational: you commit to staying within the tolerance |
The logic of T&M^: "By our estimate the R&D phase will cost 60K; it may come out at 10K or at 60K, but the market is unstable, so we build in a 30 % error margin and will certainly stay within that corridor."
Editorial note. Internationally this model is called capped T&M or T&M with a not-to-exceed (NTE) limit. The exact tolerance is a matter of agreement between the parties; 30 % is the lecturer’s personal practice.
7. A combined model by phase
The models need not be applied to the whole project at once. The lecturer suggested matching the model to the risk of each phase:
| Phase | Model | Why |
|---|---|---|
| R&D | FP | The phase ends with a gate that protects you well |
| PoC | FP | A PoC is risky in itself — the hypothesis may not fire. But there is a gate at the end, so any result is a success: "it did not work" is also an answer. You can even try to get the customer to agree to the upper cost limit, if he goes for it |
| MVP | T&M^ | An embedded project: many dependencies on other companies’ production and on postal services with huge delays |
| Work packages | T&M^ | The same tangle of dependencies |
| Finalisation | FP | The artefacts are yours; you know for sure they will be available |
The result is a "cunning" model: FP where gates protect you; T&M^ where there is a lot of uncertainty; FP at the exit, where everything is under your control.
8. When the customer insists on Fixed Price everywhere
Sometimes the customer wants FP for everything, and without flexibility you will lose him. A second level of balancing is to split a phase by function. The lecturer took the MVP phase and looked "under its bonnet".
MVP goal in the teaching example: implement both sides of the communication path between two devices, A and B. Each has its own electronics, enclosure and firmware, and data travels between them over a radio link. The first MVP must establish the link between these two devices.

| Group | Roles and functions | Model |
|---|---|---|
| Engineering | Hardware (electronics), Mechanics (enclosures for both devices), Firmware (microcontrollers on both sides and the protocol), System Architect (ties HW, Mech and SW together: how it looks and interacts) | FP |
| Supply | Procurement Manager: buying, shipping, storing in the warehouse, dealing with postal services | T&M |
| Manufacturing | Electronics manufacturing, mechanical manufacturing, assembly | T&M |
The explanation to the customer goes like this: "Since you really want Fixed Price, we will meet you halfway: all the engineering is fixed price. The price and timeline of the engineering part will be exactly what we agree now; if we exceed them, we pay out of our own pocket. Supply and manufacturing are time and material." The reason is simple: the company does not manufacture; it develops and provides production control. The electronics are made, for example, by a Chinese contractor, the mechanics by factories in Bila Tserkva, Kharkiv and Lutsk, the final assembly by yet another plant. The company hands over the drawings and its engineer provides technical supervision. Those suppliers may change their prices, and the company does not want to carry responsibility for them.
Practical takeaways
- A collaboration model is a mandatory part of the proposal: the customer must see the phases, their triggers and outcomes.
- R&D answers "is it possible", the PoC "does it work on real components", the MVP "is there a first value".
- Gates after R&D and the PoC have three valid outcomes: proceed, search again, stop.
- The customer can stop after any phase; anything after finalisation is a matter for new agreements.
- The difference between FP and T&M is the allocation of risk; the FP price includes the cost of that risk.
- Under T&M the contractor still risks lost profit and reputation; under FP a penalty is added.
- T&M^ with a tolerance (e.g. ±30 %) is a compromise between flexibility and responsibility.
- Models can be mixed by phase (FP–FP–T&M^–T&M^–FP) and by function (engineering FP, supply and manufacturing T&M).
Self-check questions
- Why does the customer need a collaboration model already in the proposal?
- Who should be the contact person in a compact versus a branched project?
- How does the outcome of R&D differ from that of a PoC?
- How do innovative and technological projects differ with respect to R&D and PoC?
- Which two conditions must the first MVP feature satisfy?
- What three outcomes are possible at a gate?
- What is the cone of uncertainty, and how does R&D affect it?
- Why is Fixed Price more expensive than Time & Material for the same scope?
- Which risks remain with the contractor under T&M?
- How does T&M differ from T&M with an upper limit?
- Why can a PoC be taken on Fixed Price even though the hypothesis may fail?
- How can a phase be split to accommodate a customer who wants FP everywhere?
Announced next
The lecturer announced that the course will "climb into the rectangles": where the phase durations (1, 3, 0.5, 7 months) come from and why the first two phases can be Fixed Price while the third and fourth cannot. Part of this was already covered in the next session on 28 October. This is an announced plan.
Session materials
- The draw.io diagram from the session: download .drawio (opens in diagrams.net / draw.io).
Verified links
- S. McConnell. The Cone of Uncertainty (Construx white paper): https://www.construx.com/wp-content/uploads/2019/02/CxWhitePaper_ConeOfUncertainty.pdf