Methodology
Deterministic, fully-explainable analytical frameworks. No machine-learned weights, no random sampling.
AI multiplies value, but it can also multiply mistakes.
This platform applies deterministic abstractions to convert qualitative board-level judgement into auditable strategic signals. Every number on every screen can be traced back to a slider, a select, or a published threshold below.
Quadrant placement on the Value × Feasibility map drives the go / scale / pilot / stop decision for each initiative.
Any initiative above the restricted band (Governance ≥ 61) cannot scale until explicit board-level controls are in place; it is removed from the prioritised list regardless of value or feasibility.
Initiatives scoring 70 or above on Strategic Impact are classified as high strategic impact and surfaced in the Board Memo's Strategic Priorities section. (Strategic Impact additionally acts as the final ranking tie-breaker — see § 6 Prioritisation Logic.)
If any portfolio cut (vendor, solution type, AI category, or business unit) exceeds HHI 0.25 on the normalised 0–1 scale, the portfolio steward must actively consider redistribution before approving new initiatives in the dominant segment.
Each initiative is scored on four strategic dimensions: Value & Scale, Feasibility & Explainability, Governance & Risk, and Strategic Impact. Every dimension contains 7–8 subcomponents scored from 0 to 100.
Every initiative is rated on four dimensions, each on a 0–100 scale (full narrative on the Concept page):
- Value & Scale — economic and strategic upside.
- Technical Feasibility & Explainability — buildability, reliability and transparency.
- Governance & Risk — compliance, oversight and model-risk load (deep dive in § 3).
- Strategic Impact — how far the initiative shifts the operating model (deep dive in § 4).
DimensionScore = round( clamp01( mean(subcomponents) ) × 100 )
Subcomponents are weighted equally within their dimension. There are no learned weights — boards can therefore challenge any single subcomponent input and immediately see its impact. Any subcomponent switched off in Settings → Slider configuration is hidden on the Evaluation page and excluded from its dimension's average, so the score reflects only the sliders your board chose to keep.
Each dimension also carries an assessor confidence label (Low / Medium / High) which the memo and prioritisation views surface alongside the score.
Every dimension score now carries an explicit confidence level so the board can read scores in context: a 78 on Value with Low confidence is not the same as a 78 built on a pilot.
- Low — Subjective estimate, single source, no validation. Treat scores as directional.
- Medium — Triangulated from workshops, internal data or partial benchmarks. Defensible but still revisable.
- High — Validated by data, a pilot, or independent external review. Suitable as decision basis.
Aggregates (KPIs, HHI, quadrant counts) are not re-weighted by confidence — confidence is reported alongside scores so the board sees where evidence is thin without changing the underlying math.
Initiatives are classified into bands based on the Governance & Risk score:
- 0–20 · Minimal oversight: routine controls suffice.
- 21–40 · Controlled automation: standard monitoring; periodic review.
- 41–60 · Human-in-the-loop required: model-risk controls, documented decision rights.
- 61–80 · Restricted deployment: active board-level oversight, audit trail and access controls.
- 81–100 · High governance sensitivity: treat as material risk; deploy only with explicit ringfencing.
- 0–40 · Tactical — operational improvement only.
- 41–70 · Strategic enabler — strengthens existing strategy.
- 71–100 · Transformational — reshapes operating model, capabilities, or market posture.
The x-axis (Business Impact) is the equal-weighted average of Value & Scale and Strategic Impact: BusinessImpact = (Value + Strategic) / 2. The y-axis is Feasibility & Explainability. Quadrants are split deterministically at 50 on both axes:
- Scale — Business Impact ≥ 50 and Feasibility ≥ 50. High impact, high reliability — ready for enterprise rollout.
- Assist — Business Impact ≥ 50 and Feasibility < 50. Valuable but not reliable enough for autonomy — keep humans in the loop.
- Pilot — Business Impact < 50 and Feasibility ≥ 50. Technically feasible but unclear business case — pilot before scaling.
- Stop — Business Impact < 50 and Feasibility < 50. Low impact and low feasibility — defer or sunset.
Bubble size additionally emphasises Strategic Impact on its own (so a strategic initiative reads as a larger bubble even when its value score is moderate); bubble colour reflects the governance band.
Each initiative is evaluated against the rules below and assigned to the first category whose rule matches, in the precedence order 1 → 2 → 3 → 4 → 5 → 6 → 7. The list below is shown in the same order the Prioritisation page renders the groups, which is not the same as precedence — the precedence number is given on each rule. Initiatives that satisfy none of rules 1–6 fall into the fallback group Uncategorised / Tactical (precedence 7).
- Quick Wins (precedence 1) — value ≥ 60, feasibility ≥ 60, and governance ≤ 40. High return, low risk, ready to execute.
- Strategic Core Initiatives (precedence 2) — value ≥ 70, feasibility ≥ 50, and strategic ≥ 70. Core bets that are both valuable and strategically central.
- Operating Model Transformation (precedence 6) — strategic ≥ 80, and the initiative did not already match Quick Wins, Strategic Core, High Governance Risk, Long-Term Strategic Bets, or Incremental Optimisation. Deep, business-model-level shifts that aren't better described by an earlier rule.
- Long-Term Strategic Bets (precedence 4) — value ≥ 60, feasibility < 50, and strategic ≥ 60 (after High Governance Risk has already claimed initiatives above its threshold). Strategically attractive but not yet feasible — keep on the horizon.
- Incremental Optimisation (precedence 5) — value < 50, feasibility ≥ 60, and strategic < 50. Easy to ship but limited upside; useful as fillers.
- High Governance Risk (precedence 3) — governance ≥ 70 (and the initiative was not already classified as Quick Wins or Strategic Core). Elevated compliance, regulatory or risk exposure that must be addressed before scaling.
- Uncategorised / Tactical (precedence 7) — fallback for initiatives that don't satisfy any of rules 1–6. Treat as tactical until scores sharpen.
Show details
Ranking inside the queue. Initiatives are first grouped by the category rules above (precedence 1 → 7), then within each category ordered by Value score descending, then — if Value-at-Stake weighting is enabled in Settings and the row sits in Quick Wins / Strategic Core — Year-3 benefit descending. Final tie-break is Strategic Impact descending, then name A→Z, so the result is deterministic and reproducible.
Each portfolio mode can carry an optional annual capacity envelope: a budget cap (in the active currency) plus a free-text narrative. A per-mode Skill Catalogue in Settings lists skills with individual FTE caps. When at least a budget cap is set, the Prioritisation page ranks active initiatives along a single greedy queue and computes a cut-line: every initiative whose cumulative budget stays within the cap and whose required skills do not push any per-skill FTE cap is funded; the rest is parked.
Within each category the queue is ordered by the deterministic ranking rule described in § 6 (Prioritisation Logic); the cut-line is then applied to that ranked queue from top to bottom.
Show details
Trade-off scenarios on the Prioritisation page recompute the cut-line for an adjustable budget cap, stepped in ±5 % increments (down to −95 %; per-skill FTE caps held constant), so a board can see at a glance which initiatives drop out or re-enter under stress.
Per-skill caps act as hard constraints: if an initiative would push any skill above its FTE cap, it is parked with a red Skill bottleneck badge that names the binding skill. Utilisation bars on the Prioritisation page turn green / amber / red so the binding constraint — budget or a specific skill — is visible at a glance.
If no cap is set, the Prioritisation page hides the cut-line and shows a one-line shortcut into Settings; the Board Memo and Board Pack omit the section gracefully — backwards compatible with all existing data.
Dependencies as a hard constraint, with back-fill. The cut-line is computed by an iterative greedy walk over the ranked queue with three hard constraints — budget cap, per-skill FTE cap, and upstream dependencies. A failing item is parked individually (rather than stopping the walk), and the next feasible lower-ranked initiative back-fills the freed budget / FTE; the walk repeats until no item changes state, which propagates dependency chains transitively. An initiative may only stay Funded if all of its active, non-archived upstream dependencies that are not yet In Production are also funded; otherwise it is parked with an Upstream parked badge naming the blocker, and a Parked by dependency overview lists every such item with its blocker. Funded items can therefore appear below parked ones in the ranked sequence.
Quick Win definition. The Quick Wins category requires fast time-to-value. Therefore a Quick Win that depends on an active non-Quick-Win upstream (Strategic Core, Operating Model Transformation, High Governance Risk etc.) is automatically demoted out of Quick Wins — the upstream's pre-work makes it no longer quick. The rule is transitive: if A depends on B, and B is itself demoted, A is also demoted in the next iteration.
Make it fit (v4.2). Every parked row in the ranked sequence carries a Zap button that asks the engine to fund this specific initiative. One click promotes the target plus its transitive upstream dependency chain (cycle-safe; archived, retired and In-Production items skipped), then iteratively recomputes the cut-line with provisional budget trade-off and per-skill FTE bumps. Each pass closes the exact remaining gap — at least 0.5 FTE per binding skill (rounded up to the nearest 0.5) or at least +5 pp on the budget trade-off — and the loop stops as soon as the target is funded, or after 40 passes. The result is committed once as local what-if state alongside the existing trade-off slider; the configured capacity envelope and Skill Catalogue stay untouched and the change is fully reversible. A Full reset button in the Capacity cut-line header reverts the Make-it-fit promotions together with the trade-off and per-skill FTE deltas in a single click.
The scenario bundles eight knobs: budget basis (forward-looking vs. total), the budget trade-off % on the capacity cap, per-skill FTE deltas, Make-it-fit promotions, manual excludes (park with an optional reason), the queue-status filters, the include-In-Production toggle and the Include FTE in Skill Utilisation switch on the Committed panel (run-team FTE occupies the skill caps without competing for budget or rank). The cut-line (§ 7) is recomputed from these inputs on every change — nothing is stored on the initiatives themselves.
The scenario is saved per user and per portfolio mode and survives navigation and reload until Reset to baseline. Editing (and applying) it requires the Can edit Prioritisation member right — admins always have it; without it the page shows the committed baseline read-only and any previously saved scenario is ignored everywhere.
Where it shows up: the Prioritisation page, the Board Memo, both board-pack exports and the Capacity vs budget KPI reflect the full scenario (the memo and both board-pack exports carry a what-if provenance note, the KPI a what-if marker); the Board Actions budget checks use its budget basis and trade-off-adjusted cap only. Every other view stays on the committed baseline.
One click answers: what is the smallest set of knob changes that pulls this parked initiative above the cut-line? It only ever writes what-if knobs:
- Collect the dependency chain. The clicked initiative plus every active, non-archived upstream it (transitively) depends on — In-Production upstreams are already committed and skipped.
- Promote the chain to the top of the ranking, preserving its internal score order. Promotion pins rank, but does not reserve budget: a promoted item whose upstream sits below it is budget-checked only after the rest of the queue has claimed the cap.
- Relax the binding constraint, iteratively (max 40 rounds): recompute the cut-line; for each chain member still parked, a skill block raises that skill's delta by the gap rounded up to the next 0.5 FTE, and a budget block raises the trade-off to exactly the needed % (at least +5 points). Dependency-parked members are skipped — their upstream gets the bump instead. The loop stops when the target funds or nothing is left to raise.
- Write the result into the saved scenario — promotions, trade-off and skill deltas — so the banner, the Board Memo and the budget KPIs reflect it immediately; Reset to baseline clears all of it.
The relaxation is greedy, not optimal — and the capacity it adds is global. A wider cap or a lifted skill cap is claimed by all parked initiatives in rank order, so making one initiative fit can pull cheaper high-ranked neighbours across the line with it.
While an initiative is being scoped and built, every economic figure comes from its business case — the P10/P50/P90 estimates you entered on Evaluate. Once an initiative reaches “In Production” and you start recording actuals — the real annual operating cost and the benefit actually delivered — the app steers on those realised numbers instead. Initiatives that are not in production, or that are On Hold or Retired, always keep their business-case figures byte-for-byte.
effEcon(i) = actuals if status = "In Production" AND actuals recorded business case otherwise
Under actuals, the recorded operating cost becomes a recurring annual cost and the realised benefit range (with its ramp) replaces the business-case benefit. Every derived figure — NPV, risk-adjusted NPV and payback — is then recomputed from these inputs, so the whole portfolio reflects what production is actually delivering.
| View / surface | Figure shown | Source |
|---|---|---|
| Prioritisation — cut-line & budget cap | Budget / forward-looking budget | Business case — budget fields, unaffected by actuals |
| Prioritisation — benefit total & ranking tie-break | Year-3 benefit | Effective (actuals when in production) |
| Portfolio map, quadrants & inventory | NPV, risk-adjusted NPV, benefit | Effective |
| Capacity dashboard | Year-3 benefit totals | Effective |
| Steering KPIs (target achievement & trend) | Realised vs. expected benefit | Target vs. actual (actuals + business case) |
| Board memo — financials | NPV, benefit & production target achievement | Effective + target vs. actual |
| Evaluate page (in production) | Two views: business case (reference) + actuals (primary) | Both |
| Exports & persistence (PDF/PPTX, TSV, backup) | On-screen figures (effective); raw fields stored separately | Both (round-trip) |
The Herfindahl–Hirschman Index is applied to four cuts of the portfolio: vendor strategy, solution type, AI category, and business unit.
HHI = Σ ( share_i × 100 )² where share_i = count_i / total
- HHI < 1500 — Diversified.
- 1500 ≤ HHI < 2500 — Moderate concentration.
- HHI ≥ 2500 — Highly concentrated; the board should challenge the dependency.
Show details
For the Scenarios page, each per-dimension HHI is mapped to a 0–100 risk score using the same thresholds, then blended 35 / 20 / 20 / 15 (vendor / solution type / AI category / business unit) with a further 10 % weight on average operational dependency. The overall reading is then lifted toward the worst single dimension (50 / 50 blend of weighted average and maximum), so a highly concentrated vendor strategy alone pushes the score up even if the other dimensions look balanced. A business-unit × AI-category cluster heatmap on the Concentration page surfaces specific over-exposed combinations beyond the aggregate.
Five named presets (Baseline, Accelerated Adoption, Controlled Scaling, Defensive Posture, Operating Model Transformation) plus Custom, each driven by six explicit levers: adoption speed, governance strictness, automation intensity, organisational readiness, vendor diversification, human oversight.
Show details
Baseline is special. Its slider positions are derived directly from your Inventory — adoption speed = % of active initiatives In Production or Scaling, governance strictness = average governance score, automation intensity = average transformation potential, organisational readiness = average of organisational leverage and integration feasibility, vendor diversification = 100 − vendor HHI risk, human oversight = average human-oversight sub-score. These derived positions also act as the neutral reference for the projection.
Projected outcomes are computed as transparent linear blends of the levers' delta from this Baseline, combined with structural inputs from the portfolio (production-stage share, governance-load average, HHI-based concentration risk, feasibility average). Selecting Baseline therefore overlays Current on top of Baseline by construction; moving any slider produces an honest delta from where the portfolio actually sits today.
Dependency-aware adoption. Each active initiative with at least one upstream dependency that is not yet In Production counts as 'blocked'. A flat haircut of 10 percentage points per blocked initiative, averaged across the active portfolio, is subtracted from the projected Adoption outcome. The Portfolio → Dependencies view visualises the graph; the field that feeds it is the multi-select on the Evaluation drawer.
Status changes advance through three checkpoints: Idea → Pilot, Pilot → Scaling, Scaling → In Production. Each gate carries a short evidence checklist tuned to the active portfolio mode. On Hold and Retired sit outside this ladder — they are reached from any status and are not gated — but they are not merely labels: each changes where the initiative is counted, as set out below.
Every initiative carries exactly one status. Status is its lifecycle position, and it decides where the initiative is counted — it is not just a tag. Four statuses form the advancing ladder above; two sit outside it.
- Idea — a candidate, not yet funded beyond exploration. Counted everywhere and ranked in the prioritisation queue.
- Pilot — a funded experiment testing the case. Counted everywhere and ranked in the queue.
- Scaling — proven and rolling out. Counted everywhere and still an active investment decision, so it stays in the ranked queue.
- In Production — live and operational. This is run-the-business rather than change-the-business, so by default it is excluded from the ranked queue and does not consume the capacity envelope (§ 7), while still counting in every steering view.
- On Hold — deliberately parked. Still part of the portfolio and counted in the steering views, but excluded from the rules that ask what is moving right now, so paused work is not flagged as a problem.
- Retired — finished or decommissioned. The work is over, so it is excluded from every steering, analysis and compliance view: it must not sit on the Portfolio Map, drag a governance or readiness average, consume capacity, or appear in a board pack. It stays in the Inventory so it remains findable and editable.
- Steering, analysis and compliance views (Portfolio Map, Steering KPIs, Governance, Concentration, Scenarios, Operating Model, EU AI Act, Stage Gate Report, Board Memo) — everything except Retired and archived work. This is the live portfolio: the picture as it stands today.
- Board Actions and guardrail breaches — work in flight only: the live portfolio minus On Hold. Deliberately paused work is not chased, so a guardrail card and its digest action always agree.
- Prioritisation queue — Idea, Pilot, Scaling and On Hold by default, each toggleable by status. In Production can be opted in if the envelope is meant as an all-in pool. Retired is never a candidate and can never be promoted by Make it fit.
- Roadmap — excludes Retired, but keeps On Hold: visibly parked work on a timeline is information.
- Inventory — the register. It shows everything that is not archived, Retired included, so finished work stays findable and editable.
- Snapshots — record the portfolio in full, whatever the status. A record must not quietly drop rows; a snapshot filters on the status each initiative held when it was taken, so trends stay like-for-like.
Archiving is a separate flag, not a status, and the two are independent: retired work is routinely left unarchived. Retiring removes an initiative from the steering views; archiving additionally removes it from the Inventory. Because retiring already does the former, the only question archiving still answers is whether the initiative should also leave the register — so when a save changes a status to Retired, the app asks whether to archive it as well. Answering Keep in Inventory leaves it listed.
- Idea → Pilot · first-spend gate
Authorises the first money to be spent. Evidence must show the problem is real, the owner is named and the smallest test that would falsify the Idea is defined. Compliance and risk reviewers sign off on the pilot scope; no production data and no irreversible commitments. Initiatives that cannot clear this gate stay in the backlog, not in the budget.
- Pilot → Scaling · scale-up gate
Authorises the move from a contained pilot to portfolio-funded roll-out. The Pilot must have met its pre-declared success metric with real users or workflows, and the business case has to stand up under audited assumptions. Architecture, operability and compliance posture are validated against target volumes, not pilot footprint. Bypassing this gate is the most common source of cost overruns and is logged explicitly in the decision log.
- Scaling → In Production · operating gate
Hands the initiative over from the change portfolio to the run book. SLAs, on-call ownership, monitoring, model cards and DPIA / risk attestation must all be current (< 180 days). The business case is re-baselined against actual run-rate economics. After this gate the initiative no longer competes for portfolio capacity — it competes for operating budget.
- Business case validated
- DPIA / risk assessment signed
- Owner accountable
- Compliance review
- Human-in-the-loop posture confirmed
Show checklists for the other modes
- Business case validated
- Architecture review
- Owner accountable
- Operability check
- Compliance review
- Hypothesis & success metric defined
- Validation evidence captured
- Stage-gate sponsor sign-off
- Next-step option declared (scale / pivot / stop)
Two governance fields are enforced as hard checks when the lifecycle status changes (AI mode):
- DPIA Status — must be Completed or Not Required before an initiative can move into Scaling or In Production.
- Model Card Status — must be Published or Not Required before an initiative can move into In Production.
Both checks are inactive in Digital and Innovation modes and feed the AI Act readiness score in addition to the hard block.
Note: A Model Card is a voluntary best-practice format — it is not required by the AI Act as such. The legally mandatory documentation is the Technical Documentation (Art. 11 / Annex IV) for high-risk systems and the GPAI documentation (Art. 53), both tracked as Act artefacts. The Model Card field simply lets you record and link this evidence; use the link to point to the actual document.
Bypass — if an initiative is advanced up the ladder manually without completing that gate's checklist, it is stamped as gate-bypassed and an explicit entry is written to the decision log. By default the bypass never blocks the change but is surfaced as a red flag in the inventory, in steering KPIs and in the board pack. Parking (On Hold), retiring and moving back down the ladder are not gated transitions, so they are recorded in the decision log without a bypass stamp. If the "Enforce stage gates" setting is turned on (Settings › Stage Gate), forward status advancements are instead locked until the active gate checklist is complete.
Stale — evidence older than the review interval (180 days, set in Settings › Stage-gate evidence) is treated as stale and surfaces an amber flag — deliberately distinct from the red bypass flag, so an aged review never looks like a skipped one. Open that gate on Evaluate and set a new As-of date on the item to refresh it — passed gates stay editable.
When a portfolio is shared by a team (cloud mode), the platform records who did what, and when, so governance decisions and compliance-relevant edits are traceable — without anyone having to keep a manual log.
Every initiative records the user who created it and the user who last edited it, shown under the initiative title on the Evaluate page. Attribution is assigned by the server from the signed-in session — it cannot be spoofed from the client — and is preserved even if that user is later removed from the organisation.
Beyond just "last edited by", a per-field change history captures the before and after value of each tracked field on every save, attributed to the acting user with a timestamp. It appears as a collapsible Change history panel on the Evaluate page and is read-only for everyone who can view the initiative.
- Status and the four evaluation dimension scores (Value, Feasibility, Governance, Strategic Impact) with their confidence.
- All Core Metadata fields — name, business unit, owner, description, timeline, budget, vendor strategy, solution type, AI category and tags.
- Economics — budget, benefit and cost ranges, ramp-up and discount rate.
- Decision log entries — added, removed or edited.
- The entire EU AI Act section — role, GPAI status, Annex classification, prohibited practices, Art. 50 flags, artefacts, operational obligations, EU-DB registration, AI-literacy record and serious-incident register.
A few operational fields are not tracked, to keep the history focused: the archived flag (an Inventory action), production actuals, stage-gate evidence, dependencies and required-skill allocations.