Demand to portfolio to funding¶
Trigger¶
A new business/technology demand needs to be qualified, compared with alternatives and either rejected, redirected or committed into a funded portfolio.
Intended outcome¶
Demand is traceable from intake through capability/architecture/risk/value assessment, sizing/capacity and prioritisation to an explicit funding/portfolio commitment decision.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | Demand & Intake Manager | captures demand with owner, problem/outcome, urgency and evidence status | demand record | No anonymous or outcome-free demand enters prioritisation |
| 2 | Demand & Intake Manager | qualifies completeness, duplicates, mandatory obligations and routing | qualification assessment | Disposition is explicit: reject, redirect, discover or assess |
| 3 | Enterprise Architect | checks business capability fit, reuse and enterprise target-state alignment | capability-fit assessment | Existing capability/service reuse and strategic conflicts are explicit |
| 4 | Application Portfolio Manager | assesses affected application portfolio, lifecycle posture, duplication and invest/tolerate/migrate/retire consequences | application portfolio impact assessment | Impacted applications have an explicit lifecycle posture, duplication/dependency view and accountable owner |
| 5 | Solution Architect | assesses architecture/integration/data/security/operational impact at decision-appropriate depth | architecture impact assessment | Material cross-domain dependencies and constraints are identified |
| 6 | IT Risk Manager | frames risk/opportunity, compliance urgency and value-at-risk alongside benefit evidence | risk/value assessment | Regulatory/risk urgency is evidence-based and not double-counted as value |
| 7 | Resource Manager | coordinates indicative sizing and scarce-capability/capacity demand | estimate and capacity view | Uncertainty ranges and constrained skills/capacity are explicit |
| 8 | Portfolio Manager | applies transparent prioritisation criteria across value, risk, strategy, capacity and dependencies | prioritisation decision | Prioritisation can be reconstructed from declared criteria and exceptions |
| 9 | IT Financial Management / TBM Manager | validates TCO/funding profile and financial comparability | funding economics and cost profile | Cost boundaries, CAPEX/OPEX and transition costs reconcile to the cost model |
| 10 | Portfolio Manager | makes or routes the delegated funding/portfolio commitment decision | portfolio commitment | Commitment has authority, funding/capacity basis and review condition |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
demand-to-portfolio-to-fundingworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.