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 deterministic engineering 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, labor intensity, and delivery duration?
2. Choice
TWP only
Choice #4 — TA and IM excluded from vendor scope
The customer provides the Technical Assignment (TA) and handles Implementation (IM), while the vendor delivers the Techno-Working Project (TWP). TWP 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
Engineering resource allocation: TWP=8 | Annual working time: 235 days/year per FTE | Delivery model: Vendor Development Scope
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 287 | 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 — Shared Delivery | Difference | |
|---|---|---|---|
| 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 calculated route 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. Engineering Feasibility Analysis
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 delivery scope by 31% and cuts delivery duration by 65%.
For the project sponsor working with the vendor: the vendor delivery scope 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 TWP starts.
The Scrum methodology used internally by the development team does not affect this analysis. The deterministic engineering method operates at the level of engineering stages and product maturity — not at the level of sprint planning or backlog management.
Delivery model: Vendor Development Scope