This document explains the current platform/app operating model around the etn/acdc/atc customized Odoo Platform, what each role is responsible for, and how those responsibilities map to the learning library.

1) How Change, Product and Project are interrelated

Change management is the outer frame, because organisational change defines why the organisation needs to move. Product management translates that change into platform or app capabilities, while project management delivers those capabilities through one project or, when scope and dependencies require it, through multiple coordinated projects.

Change Management Methodology itself is out of scope here. KomITi supports clients by offering its own developed Product Management Methodology and related Project Management methodologies as a service, but each client decides how to integrate those two methodologies into its own Change Management Methodology. That is why Change Management is shown in blue in this diagram: it represents the client-owned outer context around the KomITi methodologies explained here.

2) Roles

The goal is not for the candidate to become a project manager or product manager, but to understand who makes which decision, who defines the problem and scope, who drives delivery, who owns operational stability and service governance after go-live, and which role a developer should address for each type of question across the platform organization.

These roles matter because unclear ownership creates wasted work, wrong assumptions, and misdirected questions across delivery teams and client-side participants. Distinguishing the four roles early keeps platform direction, app scope, delivery coordination, and service accountability consistently understood.

• Change Manager owns platform direction, app alignment, and organisational change intent.
• Delivery Manager performs the program-management function across apps and delivery streams.
• Product Owner owns one app's value, priorities, and service-management accountability.
• App delivery lead owns app-level delivery coordination and execution sequencing.

2.1) Change Manager

Change Manager is the business-side owner of organisational change around the customized Odoo platform — why the platform exists, which organisational capabilities it should support, what belongs in/out of platform scope, and which change outcomes matter across etn/acdc/atc.

Change Manager is best positioned as a client-side employee who has end-to-end visibility into the business processes the platform supports. Technical background is also strongly preferred for this role, because platform direction, app alignment, and change intent are much easier to define well when the person can reason across both process and technical constraints.

Key references: organisational change management, business ownership practices, platform-governance practices, and enterprise transformation thinking.

Example questions a developer addresses to Change Manager:

"Should this capability exist on the shared platform at all?"

"Which organisational change is this platform release supposed to enable?"

2.2) Delivery Manager

Delivery Manager is the role that, in this operating model, performs the function that PMI would describe as program management — cross-app dependency management, sequencing, governance, release coordination, stakeholder alignment, and delivery visibility across multiple application streams.

Delivery Manager does not own app-level business rules, but owns the coordination layer above individual apps so that work lands in the right order, with the right dependencies resolved, and with a realistic rollout path.

PMBOK and PMI program-management thinking fit this role best. Scrum does not define a Program Manager role, so this responsibility lives outside the Scrum team and focuses on coordination across teams/apps rather than team-internal delivery mechanics.

Example questions a developer addresses to Delivery Manager:

"Which app goes first in this release wave and what are the dependencies?"

"Which milestone, handoff, or rollout gate must be met before promotion?"

2.3) Product Owner

Product Owner is the owner of one application's business meaning, scope, and priorities — why that app matters, which rules are genuine business obligations, what should be accepted into the app backlog, and what success looks like for that application.

End-to-end responsibility makes it recommended that Product Owner also acts as the Service Manager for that app after go-live. That means service ownership, prioritization of incidents/requests, operational review, vendor/support coordination, and ensuring SLA/OLA expectations are actually owned by someone with full application accountability.

Product Owner does not have to have a technical background, although having one is an advantage. Product Owner must, however, have excellent knowledge of the business domain for which the app is being customized, because without strong domain knowledge the person cannot reliably judge priorities, business rules, or whether the customization is actually solving the right problem.

In Scrum terms this role aligns most closely with Product Owner accountability, but here it is explicitly extended with live-service accountability. Key references: Scrum Guide, ITIL, ISO/IEC 20000, and business ownership practices.

Example questions a developer addresses to Product Owner:

"Is this really a business rule for this app, or only a technical idea?"

"Who owns the incident priority and service expectation after this app goes live?"

2.4) App delivery lead

App delivery lead is the owner of app-level delivery execution — planning the implementation sequence inside one app, coordinating day-to-day delivery, clearing blockers, preparing handoff, and keeping delivery status visible.

App delivery lead does not own cross-app program governance like Delivery Manager, and does not own business/service accountability like Product Owner. This role owns the execution lane for one app.

Key references: PMBOK project-delivery discipline, PRINCE2, ISO 21502, and team-level execution practices that work alongside Scrum delivery teams.

Example questions a developer addresses to App delivery lead:

"What is the implementation sequence inside this app and what is blocked right now?"

"When is the expected demo, verification, and handoff for this app change?"

2.5) How roles appear in the library module example

• Change Manager confirms that the library app belongs on the shared Odoo platform and that it supports the intended organisational change.
• Delivery Manager coordinates when the library app lands relative to other apps, shared dependencies, and release gates.
• Product Owner confirms that ISBN validation, member limits, lifecycle rules, and post-go-live support priorities are genuinely needed for the library app.
• App delivery lead drives the execution sequence so the skeleton is done first, then MVP, then business logic, then website UI.

3) Program Roadmap and Streams

A typical program starts with a roadmap of milestones in calendar weeks (CW), and is divided into delivery streams (Odoo, Fabric, Power BI), with the Odoo stream further split into app squads. To see the indicative roadmap and streams diagrams — milestones from contract sign-off (CW: X) to the first Power BI report mock-up (CW: X+24) — visit the Services page on www.komiti.eu.

The sections below explain the responsibilities and deliverables of each stream.

3.1) Odoo stream

Odoo stream starts with analysis of needs, because the organisation must define high-level scope and priorities before delivery begins. After that analysis, the team sizes and provisions the Odoo infrastructure. Deliverables from Odoo Infra Work Package include:

• Odoo infrastructure provisioned — the target runtime is installed and ready for platform work.
• Infrastructure Solution Design — the main infrastructure blueprint that defines the target Odoo architecture and build decisions.
• Current-State Assessment (As-Is) — the document that describes the existing environment before the target solution is built.

Odoo PoC follows, then Odoo App projects continue as the main delivery stream.

3.2) Microsoft Fabric stream

Microsoft Fabric stream runs in parallel with the Odoo App projects. This stream provisions the data platform, extracts data object by object, and supports the later AI PoC work.

3.3) Power BI stream

Power BI stream builds on the Fabric foundation afterwards. This stream turns prepared data into reports and dashboards for business users.

4) What you should learn from this

• When you are not sure whether a capability belongs on the shared platform, you address the question to Change Manager.
• When you are not sure whether something is truly a business rule for one app or who owns service expectations after go-live, you address the question to Product Owner.
• When you are not sure how a change fits into the wider release wave or dependency graph, you address the question to Delivery Manager.
• When you are not sure about execution sequence, implementation status, or handoff inside one app, you address the question to App delivery lead.
• When you are not sure in which system or layer the problem lives, first read 03_infrastructure.html to distinguish delivery/infra/runtime/application/functional domain.
• Do not assume scope or rules. Document what you know and what you assume.

5) Summary — one sentence per role

• Change Manager: defines why the shared platform exists and which organisational change it is meant to enable.
• Delivery Manager: performs the program-management function across apps, releases, and dependencies.
• Product Owner: owns one app's business priorities and also carries the service-management accountability after go-live.
• App delivery lead: coordinates the execution sequence and handoff for one app's delivery stream.

When the module lives in production, these roles still apply: Change Manager steers platform direction and organisational change intent, Delivery Manager coordinates the wider delivery program, Product Owner carries both business and service accountability for the app, App delivery lead drives execution, and the developer delivers per ENGINEERING_CODEX.md standards.