Approach
This site shows no client references: the systems we build would expose the organisations that entrust them to us. What we can show is how we work.
Sequence
What has to keep running, whatever happens?
We start by identifying the functions whose interruption has real consequences, and by mapping what already exists. This stage almost always reveals dependencies the organisation was unaware of, and systems nobody knows how to restart.
DeliverablesSystems map, ranking of functions, risk matrix.
How do we get out of this system in ten years?
The question of the exit is asked before the question of the entry. It determines the formats, the interfaces, the ownership of the code and the contractual clauses. An architecture you cannot leave is an architecture that should not have been chosen.
DeliverablesArchitecture dossier, reversibility plan, security requirements.
Is this increment usable in production, yes or no?
Every increment has exit criteria defined before it starts and checked on delivery. An increment is not finished because the schedule says so, but because its criteria are met. Variances appear early, while they can still be corrected.
DeliverablesDelivered increments, operating documentation, reproducible tests.
What happens if it fails on the night of the cutover?
The cutover is rehearsed before it is performed, with a proven rollback scenario. The client’s operations teams hold the controls during the rehearsal; they do not watch it.
DeliverablesCutover plan, rollback procedure, recovery exercise.
Can your teams manage without us?
Transfer is not end-of-project training. It begins during delivery and ends with a period in which the client’s teams operate alone, with our assistance held back. The engagement concludes when that period passes without us.
DeliverablesDocumentation, mentoring, supervised period of autonomous operation.
Convictions
A supplier whose revenue depends on the client being unable to do without it has no reason to transfer the expertise. We would rather be chosen for the next engagement than retained by the impossibility of leaving.
A security requirement introduced after design costs ten times more and protects half as well. It belongs in the acceptance criteria of every increment, not in a final audit.
Operating documentation, architecture diagrams and recovery procedures are deliverables, on the same footing as the code. Without them, the system belongs to whoever wrote it.
On decisions with significant effect, an automated process proposes and a responsible officer decides. The rule holds even when it slows the chain down.
End of engagement
The share of operational responsibility we hold decreases from one phase to the next. An engagement in which that share does not decrease is not progressing: it is installing a dependency.
Division of operational responsibility
Framing
Konect 9 / organisation 3
Requirements, exit criteria and the reversibility plan are established.
Build
Konect 8 / organisation 4
The organisation’s teams take part in design, not in acceptance testing alone.
Go-live
Konect 5 / organisation 7
Operation is conducted jointly, against written procedures.
Supported operation
Konect 2 / organisation 10
The organisation operates; Konect steps in on request.
Autonomy
Client organisation, alone
The engagement ends. The system runs without outside assistance.
Verification
During a pre-qualification or a consultation, and at the request of an identified organisation, we send directly the material that cannot appear on a public site.
Consultations · Pre-qualifications · Partnerships
Describe your priority, its operating context and the intended outcome. We will route the enquiry to the right person.
