Shared Delivery
Bus & Trolleybus (BT) Access Control Fast Track
1. Problem
A city authority needs a passenger access control system for bus and trolleybus routes: validators in vehicles, driver information devices, and a central data collection server. Standard domain — well-understood requirements, mature component ecosystem.
The customer has a capable internal IT department: analysts who can write the Technical Assignment, and a DevOps team ready to handle deployment independently. The vendor is engaged only for development.
The development team works in pure Scrum. The patent-pending method does not constrain the development methodology — engineering stages and product horizons remain fixed regardless of how sprints are organized within each stage.
The question: what is the actual vendor scope, and what does it cost?
2. Choice
TWP only
Choice #4 — TA and IM excluded from vendor scope
TA is provided by the customer (excluded from vendor scope). IM is handled by the customer's IT team (excluded from vendor scope). The vendor delivers only TWP — Techno-Working Project — which merges TP and WP into a single stage without an intermediate acceptance boundary.
At 40–60% reuse and with an experienced Scrum team, the boundary between technical design and implementation is fluid. TWP reflects this reality more accurately than separate TP and WP stages.
3. Target Stage
The vendor delivers one horizon: H3 (Release Candidate). Production Release (H4) is handled by the customer's IT team after acceptance.
4. Mapping Note
For this project, 6 functions were selected via the Function Mapping Procedure (FMP). Full function composition is available inside the calculator.
5. Report View
Team configuration: TWP=8 | Fund: 235 days/year per FTE | Delivery model: Pure Development Contract
TA: provided by customer (excluded). IM: handled by customer (excluded).
| Horizon | Stage | Product Stage | Labor (pd) | Team (FTE) | Time from Start | Scope |
|---|---|---|---|---|---|---|
| H0 | TA — Technical Assignment | Requirements Baseline | 377 | — | — | Customer |
| H3 | TWP — Techno-Working Project | Release Candidate (without MVP) | 2 288 | 8 | 1.22 yrs | Vendor |
| H4 | IM — Implementation | Production Release | 670 | — | — | Customer |
| Vendor Total | 2 287 pd | 8 FTE | 1.22 years | |||
| Full Turnkey (vendor does everything) | Case 4 — Pure Dev Contract | Saving | |
|---|---|---|---|
| Total Labor | 3 335 pd | 2 287 pd | −1 048 pd (−31%) |
| Total Duration | ~3.5 yrs | 1.22 yrs | −2.3 yrs (−65%) |
6. Decision
Accept the configuration with one mandatory precondition: the incoming TA must pass a formal review before TWP starts. If TA coverage is below 70% — return for revision. An incomplete TA at this configuration has no buffer: TWP starts with ambiguity that no one can resolve mid-sprint.
TWP is the correct choice here: 40–60% reuse and an experienced Scrum team mean the boundary between design and implementation is real but thin. Merging TP and WP into TWP removes an artificial acceptance gate and reflects how the work actually flows.
7. VC Interpretation
Redistributing responsibility between customer and vendor is not an organizational preference — it is an engineering decision with a measurable effect. Transferring TA and IM to the customer reduces vendor contract scope by 31% and cuts contract duration by 65%.
For the investor financing the vendor: the contract is smaller, cleaner, and faster. The risk is transferred to the quality of the customer's TA and the readiness of their DevOps team — both must be verified before signing.
The Scrum methodology used internally by the development team does not affect this analysis. The patent-pending method operates at the level of engineering stages and product maturity — not at the level of sprint planning or backlog management.
Delivery model: Pure Development Contract | Patent Pending — Ukraine