Operating Model & Execution
Operating model and execution: how leadership decisions reach the teams
The question is not which framework to roll out. It is how the organisation actually works: where value flows, who decides what, at what pace, and how execution reports back to strategy. We design that operating model, launch it and build it into the tools. SAFe is one of the means we use where it helps. It is never the point.
Why operating models fail
The same causes come back from one organisation to the next.
- Trains or product teams cut along the existing organisation chart rather than along value streams. The dependencies you meant to remove are still there, with extra ceremonies on top.
- Roles that exist only on slides. Until an Epic Owner or a Business Owner exists in the HR role framework, nobody has the time or the mandate to do the job.
- A PI Planning prepared the week before, where dependencies are discovered in the room.
- A portfolio that keeps funding projects while teams work in product mode.
- A tool left on default settings that cannot represent the model, so the model stays on slides.
What we put in place
The operating model covers the Execution and Teams links of the Strategy-to-Execution chain: the way decisions taken at the top turn into planned, visible work.
Value streams and the organisation of execution. Identifying value streams, choosing between an organisation by products, by projects or by trains (ARTs) according to the nature of the work, sizing, and choosing the first scope to launch. How the work is cut is the most structuring decision of all. We take it in workshops with the business and IT.
Roles and decision rights. Who makes trade-offs, who prioritises, who commits: Release Train Engineer, Product Management, Product Owner, Epic Owner, Business Owner, Lead Architect. Where needed, these roles are created in the HR role framework. Each role is supported in its real practice.
Governance cadence. A decision rhythm the organisation can keep: quarterly planning, portfolio reviews, priority reviews. Every forum has the decisions it is expected to take.
PI Planning and synchronisation. Preparing and facilitating PI Planning, synchronisation between teams and between trains, reviews and demos. A PI Planning is largely won before the event: capacity, dependencies, feature readiness. See what AI adds to that preparation.
VMO and LACE. The VMO links the trains to the portfolio. The LACE drives the change, equips it and measures it. We set them up, lead them where needed, and make them self-sufficient.
Execution visibility. PI objectives, flow metrics and Epic progress, fed from Jira. This is what allows the portfolio to decide on facts.
The tools, from the design stage. Every object in the model has its counterpart in the tool before it is adopted: the object hierarchy in Jira or Jira Align, the governance reference in Confluence, the link to the portfolio tool where funding is managed. See Tools & Data.
SAFe used where it helps, never imposed
We know SAFe in depth: value streams, ARTs, PI Planning, LACE, VMO, Lean Portfolio Management. We keep what addresses the organisation’s real difficulties, adapt it, and say so when a practice adds nothing in your context. SAFe applied to the letter in an organisation that is not ready produces ritual, not decisions.
What it has made possible
International financial services group. The IT function moved from project-based governance to a Lean-Agile operating model that connects strategy, funding and execution. 3 ARTs were launched, and the model was built into Clarity and Jira, from governance to teams. The trains were not the goal. They are the visible part of a model in which funding and portfolio governance changed at the same time as execution. Read the case study
Our working rule
No steering view that needs continuous manual entry. The rule applies to PI objectives, dependencies, flow metrics and Epic progress.
FAQ
Frequently asked questions
Do we have to adopt SAFe in full?
No. We start from what the organisation actually does, keep what addresses its difficulties, and say so when a practice adds nothing in its context.
Where do we start?
With a diagnostic of two to four weeks: value streams, existing governance forums, decision paths, how Jira and Clarity are really used. It leads to an achievable target and to the choice of a first scope, where the need is clearest and the sponsor most committed.
How long does it take to launch a first train?
Two to four months for a train that runs and is supported by its tools: identifying the value stream, forming the train, preparing the roles, the first PI Planning, and the Jira set-up that goes with it.
Can you step in when a transformation is already under way?
Yes. It is common: trains exist, but the portfolio has not followed, or the tool does not represent the model. We start with a review of the current state before proposing anything.
Do you support the people who hold the roles?
Yes, as part of the engagement: preparing the roles, support in real situations, help with the first events, then handover of the practices to internal teams.
Related expertise
Go further
- Strategy-to-ExecutionHow strategy becomes measurable priorities, funding, portfolio decisions and work for teams, with practical mechanisms built into your tools and data.Read more
- Lean Portfolio ManagementLean Portfolio Management that actually runs: strategic themes, Portfolio Kanban, WSJF, capacity funding and governance forums, built into Clarity and Jira.Read more
An operating model to launch, or to get moving again
Describe your situation in a few lines. We will tell you where we would start.