Co-creation & change management methodology#
Part of the LDT Governance and Trust Framework — instantiates the iSHARE Data Space Template page Co-Creation & Change Management Methodology (© iSHARE Foundation, see Legal notices).
Purpose#
Co-creation is the template's answer to a specific failure mode: a rulebook written by one party, for others, that nobody implements. It is a collaborative, incremental process in which policy, business, technical and legal contributors jointly define the problem and develop the rules — consultation replaced by shared ownership, and iteration in place of a single review round. The template's claim is that this produces rules that are actually implementable and actually accepted, and that ownership of the governance framework ends up with the people who have to operate it.
Change management is the second half, and the template is explicit that it only begins after the first complete version of the rulebook is delivered. Before that there is nothing stable to manage change against.
LDT instantiation — how EUTwinLink runs it#
The template's seven co-creation steps map onto the PD4 process as follows. The mapping is deliberately literal, so a partner who knows the template can see where they are in it.
| Template step | How the LDT does it | Where it lives |
|---|---|---|
| 1 · Prepare your foundation | This repository — a working fork of the Template, structurally complete before contributions start. | Scheme overview · Template parity |
| 2 · Map stakeholders & responsibilities | One named owner per building block, per partner, with due dates. | Building-block register |
| 3 · Explain the co-creation approach | This page, plus the contribution instructions; the guiding-questions pages carry the template's own questions verbatim so partners answer the real questions. | CONTRIBUTING |
| 4 · Plan & prioritise | Blocks already DRAFTED by iSHARE go first so partners react to text rather than to a blank page; blocks with external legal dependencies (L1) start earliest. | Building-block register |
| 5 · Align with your roadmap | Internal release timeline v0.1 → v0.5 → v0.9 → v1.0, ending before the PD4 submission with review time still in hand. | Building-block register |
| 6 · Run & document sessions | Monthly TIPS Committee, minuted; decisions land in the repo as merge requests, not only in minutes. | TIPS minutes · merge requests |
| 7 · Consolidate & iterate | The WP4 lead integrates, legal reviews, TIPS approves; the integrated draft becomes PD4. | Scheme overview |
Roles, in the template's terms: iSHARE Foundation is Change Manager and main coordinator (WP4 lead); the WP4 task leads facilitate sessions; all 11 consortium partners are contributors via merge request; the Steering Committee resolves conflicts per the Consortium Agreement; the TIPS Committee acts as the Change Advisory Group, reviewing major changes and cross-block consistency.
Change management — active from v1.0#
Until PD4 v1.0 is approved, changes are simply contributions. From v1.0 onwards the template's seven-step change process applies, in this form:
- Identify — anyone may open an issue against a block.
- Propose — a merge request with the proposed text, not a description of it.
- Plan — what implementing the change requires of participants and operators.
- Analyse impact — which other blocks, policies, credentials or contracts move. Cross-block impact is the reason TIPS reviews rather than the block owner alone.
- Decide — TIPS approves, rejects or defers, minuted with a reason.
- Implement — merge, version bump, changelog entry.
- Assess — review at the following TIPS; lessons recorded.
Two LDT-specific rules on top of the template:
- Upstream drift is a standing agenda item. Template or framework updates enter through the sync process in Alignment with the iSHARE Trust Framework, so upstream changes are visible as diffs instead of surfacing years later.
- Silence is not approval. A block left OPEN past its due date is escalated by the WP4 lead at the next TIPS, because PD4 acceptance is a payment condition and an unowned block is a schedule risk, not a documentation gap.
Expected outcomes#
A collaboratively built, versioned governance framework; a documented rationale for every decision (in TIPS minutes and merge-request history); and a process that keeps working after the project ends — which, given that permanence after M18 is still open, is the point.
PD4 mapping#
Feeds PD4 chapter 1 (how the scheme was produced) and chapter 9 (annexes: change process).