Do Not Start
Unified Metropolitan Transit Control System
1. Problem
A metropolitan authority wants a unified passenger access control system covering all six transport modes simultaneously: tram, trolleybus, bus, suburban rail, metro, and funicular. The full scope includes validators on all vehicle types, ticket vending machines, card preparation workstations, inspector validators, driver information devices, a central database server, long-term tape archive, fare evasion detection, and a unified multi-modal ticket component. The network is heterogeneous — six independent subsystems with different hardware and protocols unified under a single ticket and central server.
The investor sets the same condition as in Case 1: Production Release within the political and budget cycle — approximately 3–4 years. The team is confident. The question is whether the math agrees.
2. Choice
TA → PP → TP → WP → IM
Full cycle — Choice #1
Same choice as Case 1. The full lifecycle is required — this is a public infrastructure project with regulatory documentation obligations. No shortcut is available without abandoning compliance.
3. Target Stage
4. Mapping Note
For this project, 11 functions were selected via the Function Mapping Procedure (FMP). Full function composition is available inside the calculator.
5. Report View
Team configuration: TA=3, PP=3, TP=4, WP=20, IM=8 | Fund: 235 days/year per FTE
| Horizon | Stage | Product Stage | Labor (pd) | Team (FTE) | Time from Start |
|---|---|---|---|---|---|
| H0 | TA — Technical Assignment | Requirements Baseline | 1 020 | 3 | 1.45 yrs |
| H1 | PP — Preliminary Project | Prototype | 793 | 3 | 2.57 yrs |
| H2 | TP — Technical Project | MVP | 793 | 4 | 3.41 yrs |
| H3 | WP — Working Project | Release Candidate | 6 220 | 20 | 4.74 yrs |
| H4 | IM — Implementation | Production Release | 1 813 | 8 | 5.70 yrs |
| Total | 10 639 pd | — | 5.70 years | ||
| Comparison: Case 1 vs Case 2 — same method, different scale | |||
|---|---|---|---|
| Case 1 — Trams | Case 2 — Metropolis | Growth | |
| Functions | 5 | 11 | +120% |
| Total Labor | 3 541 pd | 10 639 pd | ×3.0 |
| WP team | 10 FTE | 20 FTE | ×2.0 |
| Total Duration | 3.36 yrs | 5.70 yrs | ×1.7 |
6. Decision
Do not start in the current scope. This is not a judgment about the team's capability — it is a mathematical result of three factors acting simultaneously:
- Volume: 11 functions vs 5 in Case 1 — labor grows 3×.
- Complexity: two High Complexity markers (Hard Real-Time + SCADA) and two Medium markers vs one of each in Case 1.
- Reuse: ≤20% vs 20–40% in Case 1 — six heterogeneous subsystems with a unified ticket have virtually no ready-made solutions.
The correct path is to redesign the scope: either implement the first subsystem as a standalone project (as in Case 1), or split the full system into sequential phases with separate funding rounds.
7. VC Interpretation
The team says "we'll manage." The calculation says "no team configuration fits the window." This discrepancy is not a negotiation point — it is a structural fact.
Financing this project in its current scope means financing a future scope revision in 8–10 months, after the money has been spent. The calculator makes this visible before the contract is signed.
The right investment structure here is not a single tranche for the full system — but a phased approach: fund Case 1 first (one subsystem, Open Path), prove the technology, then expand scope in subsequent rounds.
Delivery model: Full Turnkey | Patent Pending — Ukraine