Tools & Data

Tools & Data: making the operating model executable

The operating model defines how decisions should work. The tools and the data make those decisions executable and measurable. So the question is rarely which tool is best. It is which governance model you want to run, and which tool can represent it without contortions. Taken in that order, the choice becomes simple. Taken the other way round, it produces an expensive tool nobody keeps up to date.

Start from the decisions, not the tools

Tools & Data is the last link of the Strategy-to-Execution chain. The decisions it has to serve are designed upstream, in Lean Portfolio Management and in the operating model. Each of those decisions needs data to be taken, and a place where its outcome is recorded.

The decision	The data it needs	Where that data lives
Which initiatives enter the portfolio, and in what order	Strategic themes, business cases, prioritisation inputs, available capacity	The portfolio tool: Clarity, Planisware or equivalent
How much each theme and value stream receives	Investment split, budgets, forecasts, actuals	The portfolio tool and the finance systems
Whether an initiative continues or stops	Epic progress, benefit hypothesis, spend against guardrails	The portfolio tool, fed from execution
What teams plan and deliver next	Features, stories, dependencies, team capacity	Jira or the execution tool in place
Who decides what, in which forum, on what criteria	Roles, forums, decision rules	Confluence or equivalent

Decisions travel down the chain; execution data travels back up. Each layer carries one level of decision, and data moves between the layers without being keyed in twice.

Data owned at source

One source for each data item, never written from both sides. Data that can be changed in two systems always ends up diverging, and on the day it diverges nobody trusts any of it.

That is why we agree the portfolio data model before configuring anything: which object carries which decision, which system owns funding data, which owns execution data, and how governance data (decisions taken, stop criteria, forum outcomes) is recorded so it can be traced later.

The second rule follows from the first: no dashboard that depends on manual re-entry. If a data item cannot come automatically from its source, we change the source or drop the view. A figure keyed in by hand every week is wrong within a month.

The tools we work with

Tool	What it does well	What it is not built for
Broadcom Clarity	Financial and capacity governance of a portfolio, depth of the data model	Day-to-day agile execution
Planisware	Portfolio and project steering where planning depth and cost control matter	Light use, fast set-up
Oracle Primavera	Planning and scheduling of large, complex programmes	Scaled agile delivery
Jira	Team execution, workflows, usable flow data	Portfolio view and financial management
Jira Align	Connecting Jira execution to the portfolio level, trains and PIs	Detailed budget management
Confluence	Governance reference, journeys by role, documentation kept current	Quantified steering

We resell none of these products and take no commission. If the tool you already have is the right one, we will say so. That is what makes our recommendation usable. The Clarity PPM and Jira and Confluence pages go into each in more depth.

Primavera on large programmes

On large programmes and complex delivery environments, detailed scheduling often lives in Oracle Primavera: thousands of activities, critical paths, contractor schedules. Primavera is not a portfolio governance tool, and we do not use it as one. Where it is already part of the planning and portfolio landscape, the question is how its schedule data informs portfolio decisions without a second, manual version of the truth: which milestones and forecasts move up to the portfolio tool, at what level of detail, and who owns them. We define how Primavera connects to the portfolio layer and governance reporting so that programme dates and portfolio decisions can rely on consistent data.

What we do

Choosing a tool. Requirements drawn from the target governance model, a comparison grid built on your criteria, a gap analysis against what you already have, and an estimate of the full cost. The tool is chosen after the model is designed, never before.

Configuration and implementation. Data model, objects, workflows, permissions, dashboards, feed rules. We start from the operating model, often designed with you, and translate it into the tool object by object, knowing which decision each view has to serve.

Integration between tools. The most neglected subject in most organisations: Jira to Clarity, Jira to Jira Align, and feeds into resource and finance systems.

Taking over an existing set-up. An audit of the configuration and custom development in place, what serves a purpose and what was added for reasons nobody remembers, then bringing it back into line. A large part of our work is taking over configurations built by others.

Keeping it running. Upgrades and migrations, including the move to SaaS, without interrupting governance. Administration and changes, until handover to your teams when you want to take it back.

Automating flows and reporting

A portfolio produces data all the time. The problem is almost never a lack of data. It is how scattered it is and what it costs to consolidate: a tracking spreadsheet updated by hand every week, Clarity exports reworked in Excel and loaded somewhere else, a committee that spends its first half hour agreeing on the numbers.

Automation review. We map your governance processes, identify what is manual and repetitive, and assess for each candidate the time it consumes, the difficulty and the expected gain.
Reporting fed from source. Views built directly on Jira, Clarity or your databases: value streams, capacity, Epic progress, budget consumption.
Reliable scripts. Development and repair of GEL scripts, NSQL and SQL queries and XOG flows that hold up under volume and edge cases. See Clarity PPM.
Data governance. Before anything is built: which data leaves your information system, where processing is hosted, who can access what. Agreed with your IT and security teams at the start.

Automation moves data and removes re-entry. AI prepares and analyses decisions: see AI-Augmented Strategy & Execution.

What it has made possible

Financial institution. Lean Portfolio Management designed in workshops, then made operational in Clarity and Jira. Read the case study

International industrial group. Shared portfolio data to govern a strategic portfolio worth several billion euros, with industrialised reporting. Read the case study

FAQ

Frequently asked questions

Do we have to choose between Clarity and Jira?

Rarely. They do not work at the same level. Clarity carries investment decisions and capacity, Jira carries execution. The real question is where the boundary between them sits and how data moves across it.

We already have a tool nobody uses. What should we do?

Review how it is actually used before deciding anything. In most cases the problem is not the tool but the model it was asked to carry, or the data entry it imposes. Replacing the tool without dealing with that repeats the same failure, with a new invoice.

Does automation mean sending our data to an external service?

Not necessarily. Processing can stay inside your information system, run on hosting in a region you choose, or use an external service on non-sensitive data. That choice is made with your IT function at the scoping stage.

Related expertise

Go further

A tool to choose, take over or connect

Describe your context in a few lines. We will tell you what we think, including whether the tool you already have is the right one.

Describe your tools