Methodology

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.

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 → Scoring → 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.

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.

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 In Production 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 organisation's 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 organisation's baseline.

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

Both sides feed the same normalised four-point cashflow window: Y0 is the build, Y1–Y3 are the first three years after go-live — independent of the initiative's timeline dates, so figures stay comparable across initiatives. In the business case the P10/P50/P90 project cost is the one-time investment at Y0 (build, licences, implementation), and the separate annual operating-cost estimate is subtracted from the ramped benefit in each of Y1–Y3. Under actuals there is no Y0 investment: the realised operating cost recurs in every benefit year instead, and the estimate is ignored so nothing is double-counted. NPV, risk-adjusted NPV and payback are always computed from this window.

Under actuals, the recorded operating cost becomes a recurring annual cost and the realised benefit range (with its ramp) replaces the business-case benefit — but only once a benefit actual is recorded. A cost-only actual keeps the business-case benefit forecast and applies the measured operating cost on top, so partial data never zeroes out the expected upside. The blend works in both directions: a benefit-only actual keeps the business case's annual operating-cost estimate as the recurring cost until a cost actual is recorded — an operating cost explicitly recorded as zero counts as a measurement and takes precedence. 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.

Every initiative carries one total budget and an optional forward-looking remainder (the unspent part of the total). The figures do not change meaning on their own — the status decides how each is read and where it is counted:

• Idea — requested. The budget is an ask in the business case, not a commitment. The Board Memo and board pack list it separately as requested.
• Pilot onwards — committed. The first gate approves the first spend, so from Pilot on the full budget counts as committed (Pilot, Scaling, In Production). A status set by hand with an incomplete checklist commits the budget too — it is stamped gate-bypassed, and the memo and pack report that amount as "without gate review".
• On Hold — parked. Reported on its own, neither committed nor requested: a paused initiative may be a parked idea or a parked roll-out. Retired and archived work count in no budget figure.
• Forward-looking = still allocatable. The total budget answers what has been approved; the forward-looking remainder answers what is still to spend, and is the default basis of the capacity cut-line (§ 7). It spans every live initiative, so it includes Idea requests — the reports name the committed part.
• The funding decision. Settings define the change-the-business envelope; the ranked queue (Idea, Pilot, Scaling, On Hold by default) is funded up to the cap, the rest is parked. Parking an initiative whose budget is already committed means stopping or deferring its remaining spend — the capacity section says so. In Production work sits outside the envelope: run-the-business, with its own panel and totals.
• In Production — run-rate. Once actuals are recorded, the annual operating cost and realised benefits replace the business case in every live KPI (§ 9), and under-delivered or unmeasured benefits surface as Board Actions. The annual run-rate is reported as two figures — in production / all initiatives — because the operating-cost estimates of initiatives not yet live count in the total wherever no actuals are recorded. The project budget remains on record as the committed amount.

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.

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. In the Board Memo and board pack, the committed budget of initiatives advanced this way is reported as "without gate review" — the same initiatives the Transitions-at-risk list shows as bypassed.

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.

The Operating Model Impact page translates the portfolio into seven readings, each on a 0–100 scale over the initiatives currently in scope. Every one is a plain mean of its own subscores or a share of statuses — there are no weighted composites, so there is no weighting to defend. They also share no input: no subscore feeds two readings, which is what makes two of them differing mean that two things differ. Two readings may draw on the same evaluation dimension — Oversight & Compliance Load and Operational Dependence both come from Governance & Risk — but never on the same subscore within it.

One band applies throughout: Low 0–33, Medium 34–66, High 67–100. The same band drives the level chip, the bar and the takeaway sentence, so a card cannot label itself one way and advise the other. Colour follows attention, not magnitude: for the four load readings a high index is flagged, for the three readiness readings a low one is.

The indices follow the active filter and cover live initiatives only (archived and retired are excluded). Subscores switched off for the portfolio mode are excluded as well: a reading is the plain mean of whichever of its subscores remain, and one with no enabled input reports “not measured” instead of a stale number.

Each dimension also carries a confidence rating from whoever evaluated the initiative. Where initiatives were rated low confidence on the evaluation dimension a reading draws from, the card says how many. The rating is per dimension, so two cards fed by the same dimension always show the same count — one signal, shown twice, not two. It is reported, never weighted — a low-confidence score is not a smaller score, and folding it in would invent another coefficient. It changes how you read the number, not the number.

Each input tile is rounded to a whole number for display, while the index is computed from the unrounded values — so averaging the tiles by hand can land one point away from the index shown. The index is the accurate figure; the tiles are rounded so the card stays readable.

The Capabilities page reads two things: the organisation's capability map (Settings → Taxonomy; domains with the capabilities under them, each with a current and a target maturity on a 1–5 scale and an importance) and the capability links each initiative records on its Evaluation page (which capability, what kind of change, the level it brings the capability to). Nothing here feeds the four scoring dimensions.

Each link carries a kind: improve (raise a capability the organisation already has; the default), new (build one it does not have yet), replace (swap the current way of doing it for a new one) and retire (phase it out). Improve, new and replace are recorded for the reader and count the same: each brings the capability to the link's level, and that level feeds the projection, the gaps and the radars. Retire is the only kind that changes the projection: it brings no level and covers no gap. When the retiring initiative counts (Idea to In Production), the capability shows red on the map (even when another initiative raises it) and gets a retire step on the timeline, unless the same initiative also brings it a level. Every link, retire included, still counts for concentration and the on-hold Board Action, and takes its share of the initiative's budget.

Projected maturity is, per capability, the highest level its initiatives bring — never below the current level. An initiative In Production counts as achieved; Idea, Pilot and Scaling count as planned at the initiative's end date; On Hold and Retired do not count, and archived initiatives are out of scope. A link without a level means the capability's target; a retire link brings no level and is flagged instead.

A gap is a target above the projected level. It is uncovered when no counting initiative touches the capability, partially covered when initiatives exist but leave it short. Gaps list differentiating capabilities first, then core, then supporting; within an importance, uncovered before partial, larger gap first.

Spend attribution splits each initiative's budget evenly across its linked capabilities (links into capabilities the map no longer holds are ignored, and the split is over the links that remain). An initiative on hold still attributes its budget; a retired or archived one does not. Concentration flags a supporting capability that draws three or more initiatives, or a quarter or more of the attributed spend.

The timeline lists every counting link as a maturity step: achieved steps first, then the planned ones by the calendar quarter of the initiative's end date, then steps whose initiative carries no usable end date. The active filter applies to the whole page, so the figures follow the same scope as every other steering view.

Radar charts draw three rings on the maturity scale: the current level, the projected level and the target. The Capabilities page shows one radar per domain (one axis per capability, from three capabilities up); the board memo and the board pack open the capability chapter with one domain-level radar, each axis the plain mean of the domain's capabilities. The rings use the projection rules above, so a radar can never disagree with the tiles.

Board Actions read the same derivation for two rules: a capability whose target no counting initiative works towards (the Gaps tab lists it as uncovered) is a strategic gap, high severity for a differentiating capability and medium for a core one; a capability whose linked initiatives are all on hold is a medium-severity stall. Supporting gaps stay on the Gaps tab without an action, and a capability raises at most one of the two actions.

Capabilities

Each milestone has a baseline date (the plan), an optional forecast (today's expectation; empty means the baseline still holds) and a done date. The forecast or, without one, the baseline is the due date every rule below reads.

A milestone with a done date is done. An open one is overdue from the day after its due date, slipped when the forecast lies after the baseline but has not passed yet, and on track otherwise. Days are calendar days in your own time zone, so the due date itself still counts as on track.

The slip is the number of days from the baseline to the done date (done) or to the due date (open); a positive number means later than planned. Editing the baseline resets the plan, so the slip is measured against it from then on.

The roadmap draws each milestone as a diamond on its initiative's bar (done, open, slipped with a line back to the baseline, overdue). The inventory shows the next open milestone and the number overdue, sorts by it and filters to initiatives with an overdue milestone. While a status report is written, the number of overdue milestones appears next to the timeline rating.

The Board Memo and the Board Pack carry the chapter "Milestones: missed and next 90 days": every overdue milestone, and every open one due within 90 days from today, each list ordered by due date and capped at 10 rows with the rest counted. On Hold initiatives are left out, as in Board Actions: parked work is not a delivery signal. The chapter appears only when an initiative in scope has a milestone.

Board Actions add two delivery rules: an initiative with at least one overdue milestone (medium severity, naming the earliest), and an initiative whose planned end date has passed while it is still at Idea, Pilot or Scaling (high severity). Neither rule applies to On Hold or Retired initiatives, and the timeline rule not to In Production ones.

Each initiative keeps a risk register on its Evaluation page. It sits next to the Governance score, which stays the inherent rating of the initiative (regulatory exposure, reputational and cyber risk, auditability). The register holds the concrete risks a team manages, each with an owner and a mitigation plan.

Probability and impact run from 1 to 5. The score is their product (1–25) and falls into a band: low 1–4, medium 5–9, high 10–16, critical 20–25. The residual pair is the expectation after mitigation. Open and mitigating risks are live; a risk that occurred is an issue and keeps its history; closed risks no longer count.

The Governance page shows a heat map of the live risks of the filtered portfolio (On Hold initiatives included, like everything on that page; the status filter narrows it) by current or residual probability and impact (a risk without a residual keeps its current place) and the top 10 risks by score; a cell lists the risks in it.

The Board Memo and the Board Pack carry the chapter “Risks and issues”: the heat map on current scores, every high and critical live risk, the issues and the risks whose score rose since the baseline snapshot, each list capped at 10 rows with the rest counted. The baseline is the snapshot chosen for the pack, else the newest one (the memo always compares with the newest); an issue that occurred before the baseline day counts as old even when the snapshot holds no register yet; without any snapshot the chapter lists every issue and no rises. A risk is matched to its baseline copy by id, else by its title. On Hold initiatives are left out, as in the milestone chapter. The chapter appears only when an initiative in scope has a risk.

Board Actions add two risk rules. A high or critical live risk without an owner, or without a follow-up linked to it (open or done), raises one action per initiative, high severity when one of them is critical, else medium. A risk whose score rose since the newest snapshot (in a pack: its baseline) on an initiative at Pilot or Scaling, the stages heading to a gate, raises a medium action. On Hold and Retired initiatives raise neither.

Early warnings suggest a risk from data the initiative already holds, for initiatives in flight (Idea, Pilot, Scaling, In Production; On Hold, Retired and archived ones raise none). Four rules: an open milestone whose forecast is 30 or more days after its baseline, or one that was already late in the newest snapshot, is still late and is now forecast later than then; the same status-report dimension red in the latest two reports; for Idea, Pilot and Scaling, a skill the initiative itself requires whose demand across the delivery pipeline exceeds its FTE cap (the same demand as the capacity Board Action; one warning per initiative, naming the skills); and a planned end date that has passed before production. The Evaluate risk section offers each with “Add as risk”, its category and a note filled in; the Governance page lists the initiatives with warnings (skill warnings are counted once there, as the capacity Board Action covers them). Nothing is added on its own. A warning disappears for good once a risk with exactly its title (English or German, ignoring case) is in the register, whatever its status, so “Dismiss” records it as a closed risk with a dismissal note; deleting that risk brings the warning back.

A follow-up is an agreed next step: a title, an assignee and a due date, with an optional done date and note. The assignee is a workspace member (so it appears in their own list) and/or a free-text name for people outside the tool; the name stays when a backup is restored into another workspace.

Done once it has a done date; overdue once the due day has fully passed (the day itself is still on time); due within 7 days when the due day lies within the next 7 days; otherwise open.

A follow-up can point at one of the same initiative's risks or milestones. The follow-ups linked to a risk are its mitigation actions: Board Actions count a high or critical risk as mitigated only when it has an owner and at least one linked follow-up, open or done. The mitigation plan text is the strategy, not an action. Removing a risk or milestone clears the links to it.

The inventory column Next follow-up shows the open one due first, and the filter Overdue follow-ups keeps initiatives with at least one. Board Actions raise one action per initiative with overdue follow-ups, medium, high once the oldest is 30 or more days late; On Hold and Retired initiatives raise none. The home page lists your own open follow-ups when you are signed in, else the portfolio's overdue and due-this-week ones.

People reads every person field the same way. A person is their member id when the field links a member, else their name (trimmed, ignoring case), so a typed "Anna" and the member Anna count as two people until someone picks the member. My items lists, for live initiatives: initiatives you own (overdue when the planned end or a milestone has passed), live risks you own (due on their review date), open follow-ups, AI Act obligations you own that are not done, obligations you approve without an approval date, artefacts not approved (Outdated, or approved but past its review age, counts as overdue), incidents not closed (an open one is due on its reporting deadline), and decisions you own from the last 90 days. The Overview counts the same items per person and flags anyone with 3 or more overdue follow-ups, 5 or more in-flight initiatives owned, or 2 or more critical risks. The filter Person keeps initiatives where any person field names that person; on the Overview it also keeps only the picked people's rows. A typed name that matches a member's name is marked "not linked", any other typed name "not a member"; an admin links such a name to the one member of that name in every field at once (a name two members share is never linked).

Each initiative can rate eight quality factors of the solution it delivers, after the product-quality model of ISO/IEC 25010:2023: reliability and availability, security, safety, performance and scalability, usability, maintainability, compatibility and integration, and data quality (ISO/IEC 25012). The list is the same in every mode; labels and help texts follow the mode.

Per factor the initiative sets a required level (Low, Medium, High: how much the factor matters here) and a current state from 1 to 5 (1 unknown or poor, 2 weak, 3 adequate, 4 good, 5 proven in production), with an optional target date and a note for evidence or an SLA figure. A factor left unset does not count, so the section can be filled step by step.

A gap is a factor required High with state 1 or 2, or required Medium with state 1. A factor without both a required level and a state is no gap. The collapsed section shows how many factors are rated, the number of gaps and the weakest factor (when there is a gap or a state of 3 or lower).

Quality factors do not change any score: not the four dimensions, the composite score, the quadrant or the prioritisation. Like the risk register next to the Governance score, they report and warn. Data quality appears twice on purpose: the Feasibility slider rates how feasible the initiative is, the factor rates the state of what was delivered.

Across the portfolio, an initiative in Scaling or In Production with a High-required factor at state 1 or 2 raises the Board Action Quality gap before scaling (medium). The Governance page counts the in-flight initiatives with a gap per factor, the Inventory has the filter Quality gaps and the column of the same name, and the board memo and pack carry a chapter Quality gaps (top 10, most urgent first: High before Medium, later stage first) whenever an in-flight initiative in scope has a rated factor. On Hold and retired work is left out.

The NIS2 view lists 13 measures: the ten of Art. 21(2) and three governance items (approval, Art. 20(1); training, Art. 20(2); reporting process, Art. 23). Each has a status: not started, in progress, implemented or not applicable. Coverage is implemented ÷ applicable; not applicable measures are left out. The measures belong to the organisation, so no filter narrows them, and nothing feeds an initiative score.

A gap is an applicable measure that is not implemented. It is treated when a linked initiative is in flight (Idea to In Production; not On Hold, retired or archived). A gap whose target date has passed is overdue.

The approval is the management body's newest recorded decision (on one day, the later recorded). It is outdated 12 months after its date, and changed when a measure's status differs from the snapshot recorded with it; outdated wins over changed.

Training is tracked per person in the register: the newest training plus the interval set in Settings (default 12 months) gives the next due date. After that day it is overdue, within 30 days it is due soon. An overdue or soon due training appears under the person on People.

The incident register records when the entity became aware of an incident, to the minute. A significant incident (Art. 23(3)) runs through three reports to the CSIRT or the authority: the early warning within 24 hours, the notification within 72 hours, and the final report one month after the notification as sent (until it is sent, after the notification's deadline). The month runs on the calendar of the jurisdiction set in Settings (EU: Brussels time), so every viewer and the Composer get the same deadline. A report is due soon 12 hours before its deadline (7 days for the final report), overdue once the deadline has passed, and late when it was sent after it. A later report sent covers an earlier one not recorded on its own (sent together). A non-significant incident, a financial entity under DORA (Art. 19 applies) and an entity not in scope have no NIS2 deadlines. An incident asks its owner on People for the next report, then for closure; a closed incident stays listed while a report is still owed.

Board Actions, at most one of each: NIS2 gaps without a treating initiative (high for an essential entity, medium otherwise), approval missing or outdated (high) or changed since the approval (medium), management training overdue (medium) and incident report overdue (high). None fire for an entity not in scope; for a financial entity under DORA they are medium at most. The Governance page has a NIS2 card, the Inventory filters by NIS2 measure, and the board memo and pack carry a NIS2 chapter in Risk & Compliance while the module is on; its incident line counts the incidents of the last 12 months, the significant ones, those whose reports due so far were all sent in time, and the incidents with a report overdue now.

Orientation, not legal advice. Directive (EU) 2022/2555, Art. 20, 21 and 23.

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.