Strategy management is not a document — it is a continuous cycle that translates an organization's aspirations into measurable outcomes. The strategy lifecycle moves through six connected stages, each feeding the next. This page defines the best-practice framework that underpins portfolio-aligned strategy management.

The vision is the organization's long-term aspiration — where it wants to be in 5–10+ years. It is qualitative, inspirational, and stable. A good vision statement is concise (one sentence), memorable, and provides direction without prescribing specific actions.

• A vision does not change annually — it evolves over strategic cycles (typically 3–5 year horizons)
• Everything in the strategy cycle flows downward from the vision
• The vision sits as the root node of the strategy hierarchy

Goals operationalize the vision into 3–6 broad areas of focus for the current strategic period. They answer: What major things must we achieve to move toward our vision?

• Goals are directional and broad — "Become a digital-first organization", "Achieve operational excellence", "Develop our people"
• Goals are typically aligned with BSC perspectives (Financial, Customer, Internal Process, Learning & Growth)
• Each goal will have multiple objectives beneath it

Objectives are specific, measurable targets that make goals actionable. Each objective has an owner, a target KPI or OKR, a target date, a weight (reflecting its relative importance), and a current status.

• Objectives should follow the SMART criteria: Specific, Measurable, Achievable, Relevant, Time-bound
• Weights are critical — they determine how objectives influence portfolio prioritization. A high-weight objective means business requests aligned with it receive higher strategic priority scores in the portfolio layer.
• The gap between an objective's current performance (measured by its KPI) and its target is what drives the need for strategic initiatives
• Objectives cascade from goals and are organized within BSC perspectives

The Balanced Scorecard (BSC) provides the measurement framework for objectives. Each objective is linked to one or more KPIs that track progress. KPIs have defined formulas, data sources, measurement frequency, RAG thresholds, and targets. See the Balanced Scorecard Framework and KPI & OKR Frameworks pages for detailed guidance.

Strategic initiatives are the structured efforts designed to close the gap between current performance and objective targets. Each initiative contains projects (which require portfolio resources and enter the portfolio as Business Requests) and actions (BAU work tracked within the strategy module). See the Strategic Initiatives page for the full framework.

The cycle closes with continuous performance measurement — tracking whether the strategy is achieving its intended outcomes. This includes KPI reporting, benefits realization tracking, strategic initiative progress, and periodic strategy reviews where the organization assesses whether objectives, weights, and priorities need adjustment.

• Performance data feeds back into every earlier stage: are goals still relevant? Are objectives correctly weighted? Are initiatives closing gaps? Are benefits being realized?
• Strategy reviews should occur quarterly (operational review) and annually (strategic refresh)
• Portfolio investment decisions should be reassessed when strategic priorities shift

PMI's Portfolio Management Standard defines three distinct-but-related processes that translate strategy signals into portfolio-mix decisions. Balancing composes the initial mix. Optimization continuously maintains the mix as new demand arrives. Re-balancing corrects the mix when strategic conditions change. Together, they are the mechanism by which the strategy lifecycle's feedback loop becomes portfolio-level action.

Balancing and re-balancing are not a single calculation — they evaluate the portfolio along five dimensions. A portfolio that looks balanced on one dimension can be severely unbalanced on another.

• Strategic balance — coverage across every strategic objective, not just the loud ones
• Category balance — investment distributed across budget categories per policy envelopes
• Risk balance — mix of high / medium / low risk; avoid concentration in a single domain or vendor
• Horizon balance — short-term wins alongside long-term transformation
• Resource balance — demand within capacity; no single team over-committed

The Balanced Scorecard (BSC), developed by Robert Kaplan and David Norton, is a strategic management framework that translates an organization's vision and strategy into a coherent set of performance measures across four perspectives. It is called "balanced" because it goes beyond financial metrics to include customer, process, and learning dimensions — providing a holistic view of organizational performance.

A strategy map is a visual representation of the cause-and-effect relationships between objectives across the four perspectives. It reads bottom-up: investments in Learning & Growth enable improvements in Internal Processes, which drive better Customer outcomes, which ultimately deliver Financial results.

• Each objective appears in its perspective row
• Arrows connect objectives that have causal relationships
• The map makes strategic logic explicit and testable
• Best practice: the strategy map should be auto-generated from the objective hierarchy and defined linkages

Cascading means translating organization-level objectives into department-level and team-level objectives. Each level contributes to the level above:

• Level 1 — Corporate BSC: organization-wide objectives owned by the executive team
• Level 2 — Departmental BSC: each department defines objectives that contribute to corporate objectives
• Level 3 — Team/Individual: individual performance targets aligned with departmental objectives

Best practice supports multi-level BSC with roll-up KPI aggregation. Departmental performance rolls up to corporate scorecard views.

A Key Performance Indicator (KPI) is a quantifiable measure that evaluates how effectively an organization is achieving a specific objective. Well-designed KPIs are the backbone of performance management — they turn strategic intent into measurable reality.

Objectives and Key Results (OKRs) are an alternative goal-setting methodology popularized by Google. An Objective is qualitative and inspirational; Key Results are specific, measurable outcomes that prove the objective was achieved.

• Objective: "Become the most data-driven organization in the region"
• KR1: Deploy AI use cases in 5 departments (0/5 → 5/5)
• KR2: Achieve 80% self-service BI adoption among managers (current: 30%)
• KR3: Reduce data request-to-delivery time from 14 days to 3 days

A strategic initiative is a structured effort designed to close the gap between an objective's current performance (measured by its KPI or OKR) and its target. If an objective's KPI shows the organization is at 30% and the target is 80%, a strategic initiative is the vehicle to get from 30% to 80%.

Strategic initiatives are not single tasks — they are containers that hold multiple pieces of work, categorized as projects or actions.

The Strategic Initiatives Report is the strategy management view that shows the complete picture of each initiative. It combines project status (pulled from portfolio data) with action status (maintained in the strategy layer) to give a single progress view per initiative, per objective, and per strategic goal.

Organizations invest in portfolio components to achieve outcomes — not just to deliver projects. Benefits realization ensures that the expected value of investments is defined upfront, tracked during delivery, and verified after completion. Without it, an organization can deliver every project on time and on budget while still failing to achieve its strategic objectives.

• Define — during intake and authorization, expected benefits are documented: type, description, target value, baseline, measurement method, realization timeline, and owning objective
• Plan — a benefits realization plan identifies when each benefit should begin materializing and what evidence will prove it
• Track — during delivery, leading indicators are monitored. Are the conditions for benefit realization being created?
• Realize — after delivery, actual benefits are measured against the defined targets. Evidence is captured (data, reports, stakeholder confirmation).
• Review — a post-delivery benefits review (typically 3–12 months after go-live) assesses whether the full expected benefit was achieved, partially achieved, or not achieved

Each portfolio component's expected benefits are recorded in a benefits register with:

• Benefit ID, title, and description
• Type (Financial / Operational / Strategic / Social)
• Linked strategic objective (from M2)
• Baseline value and target value
• Measurement formula and data source
• Expected realization date
• Actual realized value (updated post-delivery)
• Evidence / supporting documentation
• Status: Planned → In Progress → Realized → Partially Realized → Not Realized

Portfolio governance is the framework of policies, processes, roles, and decision rights that ensures an organization's investments are selected, prioritized, and managed in alignment with strategic objectives. It answers: Who decides what gets funded? By what criteria? With what oversight?

The PMI Standard for Portfolio Management (4th Edition) defines portfolio management as the coordinated management of one or more portfolios to achieve organizational strategies and objectives. Key principles:

• Strategic alignment — every component in the portfolio must demonstrably support a strategic objective
• Value optimization — the portfolio should maximize value delivery within available resources and risk tolerance
• Governance oversight — structured decision-making with clear authority, accountability, and audit trails
• Balanced risk — portfolio-level risk management, not just project-level, including concentration risk and dependency risk
• Performance management — continuous measurement of portfolio health through KPIs and dashboards
• Communication — transparent reporting to all stakeholders at their appropriate level of detail

AXELOS P3O provides a framework for establishing and operating portfolio, programme, and project offices. Key concepts:

• Hub and spoke model — a central portfolio office (hub) with satellite programme/project offices (spokes) that report into it
• Three types of office — Portfolio Office (strategic), Programme Office (change delivery), Project Office (execution). The PMO serves primarily the Portfolio Office function.
• Governance layers — strategic governance (investment decisions), management governance (delivery oversight), operational governance (execution standards)
• Temporary vs permanent — programme offices may be temporary; the portfolio office is permanent

The PMO operates through defined functional roles. Two complementary role groups carry the portfolio management methodology — one focused on planning and analysis, the other on governance and compliance. These are capability groupings, not a mandated reporting structure; organizations may map them onto their own org chart in the way that best suits them.

Organizations adopt portfolio governance progressively. Understanding maturity helps set realistic expectations:

• Level 1 — Reactive: no formal intake, ad-hoc project selection, no portfolio view, spreadsheet tracking
• Level 2 — Defined: intake process exists, basic portfolio dashboard, manual reporting, some governance committees
• Level 3 — Managed: structured stage-gates, budget tracking, resource management, regular portfolio reviews, KPIs defined
• Level 4 — Optimized: configurable workflows, automated reporting, dependency management, capacity forecasting, benefits realization
• Level 5 — Strategic: full strategy-to-delivery integration, AI-powered insights, continuous optimization, cross-portfolio governance

Category-Based Portfolio Management supports organizations from Level 2 through Level 5, with the configurability to match the organization's current maturity and grow with them.

Not everything an organization does belongs in a portfolio. Portfolios govern investments — work that consumes shared resources (budget, manpower from resource pools, or assets) and requires governance oversight to ensure alignment and optimize value. Business-as-usual (BAU) operations — the normal ongoing work of departments — stay outside the portfolio and are managed through departmental processes.

Classification determines governance weight. A BI dashboard request that takes two weeks should not go through the same 8-gate process as a $5M infrastructure program. The classification assigned to a component determines which workflow it follows, how many gates it passes through, and how much tracking overhead is applied. Getting classification right means the right governance for the right work.

Some component types are not always Demand or always Project — their classification depends on the specific instance's complexity. Examples:

• Infrastructure upgrade: a simple system patch = Demand. A multi-site network redesign with 5 teams and 3 vendors = Project.
• Training program: a 2-day workshop with internal trainers = Demand. A 6-month organizational capability program with external firm = Project.
• GPU/hardware procurement: ordering cloud GPUs = Demand. Building an on-premise data center with power, cooling, and networking = Project.

The PMO assesses complexity during screening/feasibility and assigns the appropriate classification. The classification can be changed during the demand pipeline if new information emerges.

When a business unit wants to assess their framework, tools, processes, or capabilities, the classification depends on who does the work:

The Special Projects Portfolio exists for work that is not typically classified as a project — it does not require investment governance — but the department or PMO wants to manage it with project discipline for structure, visibility, and tracking. Examples: internal assessments, cross-departmental coordination initiatives, pilot programs, process improvement campaigns.

A stage-gate framework divides the lifecycle of a portfolio component into distinct phases (stages) separated by decision points (gates). At each gate, a designated authority reviews the component's readiness and makes a decision: advance, defer, reject, or return for rework. The framework ensures that investments progress through increasing levels of scrutiny before resources are fully committed.

Before a component reaches the authorization gate, the Portfolio Planning team assembles an Authorization Package — a complete decision-ready bundle. The default package contains:

• Feasibility Report — scope clarity assessment, technical feasibility, risk identification
• Strategic Alignment Score — weighted scoring from the Strategic Prioritization Model
• Budget Envelope Recommendation — validated cost estimate with budget category and allocation code
• Capacity Clearance — resource availability confirmation from function leaders
• Dependency Impact Statement — all registered dependencies and their current status
• Category Owner Endorsement — formal endorsement from the relevant budget category owner

The package contents are configurable per portfolio and per component type. Organizations may remove components that don't apply (e.g., Demand-classified items may not require a full feasibility report) or add components such as SME recommendation, vendor evaluation, or regulatory clearance.

The following gate parameters should be configurable per portfolio, per component type:

• Number of gates and their names
• Which gates are mandatory vs optional
• Required fields/checklist items at each gate
• Who can approve each gate (role, group, committee)
• Which decisions are available at each gate
• SLA target for decision (days)
• Whether SME review is required at specific gates
• Whether endorsement is required and from whom
• Auto-escalation rules when SLA is exceeded

• Single entry point — all demand enters through one Business Request form, regardless of portfolio or component type. No side doors.
• Guided submission — a multi-step wizard reduces errors and ensures completeness. The form adapts based on the target portfolio's intake criteria.
• Strategic alignment at source — the requester declares alignment with a strategic objective (Cascaded / Contributing / Aligned) and provides a rationale. This is a self-assessment, not a gate decision.
• Central demand pool — all submitted requests land in a single PMO-managed queue before being routed to the appropriate portfolio
• PMO routes, not the requester — the requester describes what they need; the PMO determines which portfolio, which component type, and which workflow applies

• Check for completeness — are all mandatory fields filled?
• Check for duplicates — does this request overlap with an existing component or another pending request?
• Check for eligibility — is the requester authorized to submit? Is the request within scope of the PMO's mandate?
• Route to correct portfolio based on content and intake criteria

Feasibility is where the PMO validates the request's viability. A feasibility checklist should cover:

• Strategic alignment validation — PMO independently re-assesses the requester's declared alignment level. Can confirm, adjust, or reject alignment.
• Technical feasibility — is this achievable with available technology and skills?
• Resource availability — are the required role types available in the resource pool? What is the capacity situation?
• Budget availability — does the target budget category have headroom for this allocation?
• Risk assessment — initial risk identification. Are there dependencies on other components?
• Estimate validation — are the requester's cost, duration, and resource estimates realistic?

Every component — Demand or Project — must pass through Approved / Planned before authorization. At this stage:

• Budget is formally allocated (if funding required) with a budget allocation number
• OR the component is officially approved as feasible by the demand team (for non-funded demands)
• Planned start date is set — this becomes the trigger for the authorization request
• Dependency check is performed — if dependencies exist and are unresolved, they are flagged

At submission, the requester declares alignment with a strategic objective by selecting one of the three tiers above, then provides a written alignment rationale (mandatory). During feasibility, the PMO independently validates the declared level — confirming, adjusting, or rejecting the alignment. Both the original declaration and PMO validation are recorded in the audit trail.

Authorization is the investment decision. The authorizer should consider:

• Strategic value — weighted strategic alignment score, objective importance
• Financial impact — cost, ROI estimate, budget category health
• Resource impact — capacity available, over-commitment risk
• Risk profile — dependency status (any high-risk flags?), component complexity, vendor risk
• Portfolio balance — does this authorization maintain a healthy portfolio mix, or does it over-concentrate in one area?
• SME recommendation — what do the subject matter experts advise?
• Endorsement status — has the category owner endorsed?

Best practice recommends a formal Strategic Prioritization Model that scores each component against weighted dimensions during the classification and feasibility stages. The score feeds directly into authorization prioritization — higher-scoring components are authorized before lower-scoring ones when resources or budget are constrained. Recommended scoring dimensions:

• Strategic Fit (e.g., 30% weight) — how strongly does this component align with a strategic objective? Cascaded alignment scores highest.
• Financial Impact (e.g., 25%) — expected financial benefit or cost avoidance, relative to investment size
• Risk of Inaction (e.g., 20%) — what happens if this is not authorized? Regulatory risk, competitive risk, operational risk
• Interdependency (e.g., 15%) — does this component enable or unblock other components? High dependency = higher priority.
• Organizational Readiness (e.g., 10%) — are the resources, skills, and infrastructure available to deliver this successfully?

Dimensions, weights, and scoring scales should be configurable per portfolio. The model produces a composite score that drives prioritization at the authorization queue.

When the PMO's duplicate detection or feasibility assessment catches an investment that should not proceed — a duplicate of existing work, a poorly justified business case, or a redundant technology purchase — the avoided budget commitment should be recorded. This is the money the organization did not waste because the PMO's governance process caught it.

• Every rejected or redirected duplicate is logged with its estimated budget value
• Avoided commitment is tracked as a cumulative KPI per fiscal year
• The running total appears in the Monthly Portfolio Report (MPR) and is reported to governance committees as a measure of PMO value
• Over time, the cumulative avoided commitment often exceeds the PMO's own operating cost — demonstrating clear return on investment

The following examples show how intake criteria, classification, and governance weight translate into real-world workflows across different portfolio types:

No component should remain in "Delivery" indefinitely. Best practice requires completion tracking to ensure every authorized component reaches a terminal state — either Fulfilled (for Demand-classified items) or Closed (for Project-classified items with formal closure gate).

• Roadmap accuracy — delivered components are removed from the active roadmap, freeing visual space and capacity for new work
• Financial reconciliation — completion triggers final financial settlement: actual spend confirmed against budget allocation, remaining funds released to the budget category, variance recorded
• KPI integrity — delivery success rate, cycle time, and capacity utilization KPIs all depend on components reaching a terminal state

• Estimated end date passed — when a component's planned completion date arrives and it has not been marked Fulfilled or Closed, the PMO is alerted (configurable grace period)
• Overdue escalation — if unclosed beyond the grace period, the component is escalated and flagged in the MPR as "Delivery Overdue — Pending Completion"
• Fulfilled (Demand) — lightweight confirmation: delivery owner confirms work complete, financials reconciled, component moved to completed register
• Closed (Project) — formal closure gate (G7): deliverables accepted, lessons captured, financial settlement, operational handover confirmed

The PMO's category structure is designed so that each category maps to a distinct class of investment — cloud infrastructure, application development, AI use cases, advisory services, facilities/CapEx, capability development. Any well-specified component lands unambiguously in one of them.

Government appropriations are structured around budget chapters and line items — capital spending, operating spending, professional services, training, IT, assets — not around strategic initiatives. Public-sector portfolios that attempt to budget at the strategic-initiative layer create reconciliation gaps with Ministry-of-Finance classifications, GFS / IPSAS reporting, and annual appropriation structures.

Category-Based Portfolio Management aligns with this reality: the PMO's budget categories map to official government budget lines. Every component's allocation number ties to a chapter-and-line combination that the finance function can reconcile upstream into the public budget. Strategic initiatives remain strategy-layer constructs for KPI and OKR reporting — they sit above the budget chain, never inside it.

The lifecycle tracks a component's financial progression from early planning estimates through to final reconciliation. At each state, the portfolio's financial position updates in real time.

• Variance = (Actual − Planned) ÷ Planned × 100
• Positive variance = overspend. Negative variance = underspend. Both can be problems.
• RAG thresholds should be configurable — the strip above shows the typical defaults
• Variance should be tracked at component level, category level, and portfolio level
• Early warning: when projected spend (based on burn rate) is forecast to exceed budget, the system should alert before it happens — not after

• EAC (Estimate at Completion) = Actual to Date + Estimate to Complete. Updated monthly.
• Burn rate trending — compare monthly spend velocity against planned disbursement schedule
• Category-level forecasting — aggregate component EACs to predict category and portfolio year-end position
• Reallocation triggers — when a category is forecast to underspend significantly, the PMO should consider reallocating to categories that are over-subscribed

Best practice recommends providing a Budget Category-Based View alongside the traditional portfolio-based view. Financial controllers and CFOs think in budget lines, not portfolio structures. The category view shows:

• Total budget per category, allocated, committed, actual spend, remaining, and variance
• Which portfolios are drawing from the category and how much each consumes
• All components funded by the category across all portfolios
• Waterfall chart: budget → allocated → committed → actual → remaining
• Forecast vs envelope with early warning on projected overspend

This is especially important for cross-portfolio budget categories (e.g., "Cloud Infrastructure" funding both IT and Data & AI portfolios) where the category balance is consumed by multiple governance streams.

Each Category Owner should prepare a Category Performance Pack for the governance review cycle. The pack provides a category-level view of investment health and is a key input to the Portfolio Review Committee. Recommended contents:

• Category budget utilization — allocated vs. consumed, variance, forecast to year-end
• Component status summary — count by status (active, pipeline, deferred, completed), RAG breakdown
• Intake pipeline — new requests since last period, pending validations, endorsement queue
• Dependency extract — intra-category open items, cross-category flags requiring coordination
• Key risks and escalations — items requiring governance committee attention
• Benefits realization status — for completed or in-delivery components with defined benefits

• Named resources, not headcount — the resource pool tracks specific individuals with their skills, availability, and current load — not abstract FTE numbers
• Function leaders assign — the PMO requests resources; the function leader (department head) decides who from their team is assigned. This respects organizational authority.
• Capacity is finite — a person cannot be assigned to 150% FTE. The system must warn before over-commitment occurs, not after.
• Role types are portfolio-specific — a Data & AI portfolio needs "Data Scientist"; Facilities needs "Safety Officer." Role types are configurable.
• Forward visibility — capacity forecasting (3–6 months) allows the PMO to anticipate gaps before they become crises

The recommended assignment model follows four steps:

• 1. Request — requester specifies role types, estimated FTE, and preferred timing during intake
• 2. Validate — PMO checks capacity during feasibility. Are the requested role types available in the forecast period?
• 3. Assign — function leader assigns a named individual from their pool, specifying FTE allocation and assignment period
• 4. Confirm — PMO confirms. Resource load updates. Over-commitment warnings fire if needed.

• Dependencies must be explicitly registered — not assumed or tracked informally
• Cross-portfolio dependencies are the highest-risk items — they span governance boundaries
• Every dependency has an owner responsible for resolution and a resolution SLA
• Dependencies should be checked at authorization — unresolved dependencies trigger high-risk flags

When dependencies create conflicts (a predecessor is delayed, blocking a successor; two components compete for the same resource window), the conflict must be resolved through a structured governance pathway:

• Tier 1 — PMO Resolution (configurable SLA, e.g., 5 business days) — the PMO resolves through sequencing adjustment, deferral recommendation, or facilitated agreement between component owners. If resolved: decision record issued, roadmap updated, all parties notified.
• Tier 2 — Portfolio Review Committee (next governance cycle) — if unresolved at Tier 1, escalated to the Portfolio Review Committee. PRC may approve a roadmap sequencing adjustment, authorize a scope exception, or defer one of the conflicting components. Decision record mandatory; roadmap updated within 2 business days of the session.
• Tier 3 — Executive / Investment Committee (configurable SLA, e.g., 15 business days) — if the conflict involves a strategic-level rebalancing decision (e.g., affecting >20% of the portfolio or a major strategic initiative), escalated to the executive investment committee for final decision. The PMO implements the decision and notifies all parties.

• Avoid — eliminate the risk by changing the plan (remove the activity, use a different approach)
• Mitigate — reduce probability or impact through proactive actions
• Transfer — shift the risk to a third party (insurance, contract clauses, vendor responsibility)
• Accept — acknowledge the risk and prepare a contingency plan if it materializes

• No uncontrolled changes — any modification to an authorized component's scope, timeline, budget, or resources must go through a formal change request
• Impact before decision — every change request must have an impact assessment before it reaches a decision-maker
• Proportional governance — minor changes (within configurable thresholds) can be auto-approved or approved by PM. Major changes require committee decision.
• Full traceability — every change request is permanently recorded regardless of outcome

Before a change decision is made, the impact assessment should cover:

• How many dependent components are affected?
• What is the cascading schedule impact?
• What is the budget delta (increase or decrease)?
• Does the budget category have headroom for the increase?
• Are there resource conflicts created?
• Does the change affect the portfolio roadmap critical path?
• Does the change alter the component's strategic alignment or benefits?

The portfolio roadmap is the strategic timeline view — it answers: What is happening across our portfolios, when, and do we have the capacity to deliver it? It is not a project schedule (that is the project delivery function's domain); it is the investment timeline that executives and PMO heads use for portfolio-level decision-making.

Best practice recommends a category swimlane model as the default roadmap view — one horizontal lane per budget category. Each lane shows its components with per-category constraints applied:

• Each swimlane reflects the category's budget envelope ceiling and capacity constraints
• Components show: budget, strategic objective link, start/end dates, and RAG status
• Three component states per lane: Active Pipeline Deferred
• Cross-category dependencies rendered as connector lines between swimlanes
• Additional categories appear as pipeline-only lanes until formally onboarded with a Category Owner

• Component-type filtering is essential — users must be able to choose which component types appear. A CIO viewing the roadmap may want to see only Projects, not every BI request.
• Dependencies must be visible — connector lines between dependent components. Cross-portfolio dependencies highlighted distinctly.
• Capacity must be overlaid — a roadmap without capacity data is aspirational, not actionable. The capacity heat map (resources × months, colour-coded by utilization) grounds the roadmap in reality.
• Scenario planning before commitment — before authorizing or deferring components, the PMO should be able to simulate the impact on the roadmap (cascading date shifts, resource conflicts, budget impact).
• Changes trigger governance — dragging a component on the roadmap is a change request, not a whiteboard exercise. If an authorized component's dates change, the change management workflow is triggered.

• Show current assignments as solid capacity consumption
• Show pipeline demand (not-yet-authorized) as tentative/lighter shade
• Flag periods where forecasted demand exceeds available capacity (recruitment/contracting signal)
• Department-level and role-type-level aggregation

Governance committees are the human decision layer. The system provides data, analysis, and recommendations — but investment decisions, escalations, and strategic trade-offs are made by people in structured committees with clear authority and accountability.

A decision authority matrix maps: For this type of decision × this threshold → who has authority? Example:

• Enterprise/Strategic component, budget >5M SAR → Executive Steering Committee
• Enterprise component, budget ≤5M SAR → Investment Authorization Panel
• Non-Enterprise/Operational component → Category Owner + PMO Head (no panel required)
• Change request >5% budget → Change Advisory Board
• Change request ≤5% budget → Portfolio Manager
• Resource conflict across portfolios → Resource Allocation Committee

All thresholds and mappings should be configurable per portfolio.

Escalation routes information upward to where authority exists. It does not transfer accountability. The PMO Head remains accountable for all PMO escalations regardless of which committee makes the final decision. All SLAs and thresholds below are configurable defaults.

The delivery methodology assigned to a portfolio component determines how it is planned, executed, and tracked. Choosing the wrong methodology creates friction — forcing an agile team through waterfall gates, or leaving a complex infrastructure program without a structured plan. Methodology is assigned per component at authorization, and the delivery function adapts its tools accordingly.

Methodology defines the overall delivery approach; supporting techniques sit inside every methodology and give project managers concrete tools for planning, estimating, and deciding. The techniques below are the adopted defaults across the portfolio. Each attaches to a specific point in the Stage-Gate Framework and is recorded in the Authorization Package or Project Charter so that how a number was produced is auditable, not just the number itself.

The Work Breakdown Structure decomposes authorized scope into a hierarchy of deliverables and work packages. The WBS is the foundation for bottom-up estimation, schedule development, responsibility assignment (RACI), and earned-value analysis. Every work package should be small enough to estimate with confidence and assign to a single owner.

• Level 1 — Component (project or demand)
• Level 2 — Major deliverables or delivery phases
• Level 3 — Sub-deliverables
• Level 4+ — Work packages (estimate-ready, assignable, trackable)

The WBS is created during M3 Charter / Planning (G4–G5) and becomes the baseline for progress measurement throughout delivery.

• Qualitative (Probability × Impact matrix) — the default, covered on the Dependency & Risk page. Used for every risk registered.
• Expected Monetary Value (EMV) — Probability × Impact expressed in SAR. Used for material risks where a contingency reserve, insurance, or go/no-go decision is required.
• Monte Carlo Simulation — stochastic simulation of schedule and cost across input distributions. Used on large or high-uncertainty programs to derive confidence-weighted completion dates and budget envelopes (P50 / P80 figures).
• Decision Trees — used when a risk has alternative responses with different payoffs (e.g., build vs buy vs delay). Makes expected-value reasoning explicit.

The project charter is the first formal deliverable of project delivery. It translates the authorization decision into a delivery plan. The charter formalizes what the project will deliver, how, when, with whom, and under what constraints — all within the parameters approved at authorization.

Project-classified components follow a structured delivery lifecycle after authorization. The phases and gates below represent the delivery portion of the overall lifecycle (G4–G7 from the Stage-Gate Framework). Demand-classified components typically skip this structure — they go directly to execution after authorization.

For software development components using the SDLC (V-Model) methodology, the SDLC-specific phases map to the portfolio's G4–G7 framework as follows:

• Weekly — PM updates % complete, current risks/issues, next period's plan
• Monthly — status feeds into PMO dashboard and MPR. Budget actuals updated. Milestone status reviewed.
• Gate reviews — formal checkpoint with gate criteria assessment, go/no-go decision

The PMO Scorecard is a single-page executive view that aggregates the most critical KPIs from all domains — governance, planning, financial, and resource — into one health check. It answers: Is the PMO doing its job?

A component's overall RAG is not a schedule measurement. Schedule performance is one of several health dimensions, and relying on it alone produces Green components that later fail on budget, quality, or resources. Every component is assessed across the dimensions below, and the overall RAG aggregates them.

The overall PMO Score is a weighted average: each KPI's RAG status is converted to a numeric value (Green = 100, Amber = 60, Red = 20), multiplied by its weight, and summed. The result is an overall PMO health percentage displayed as a single RAG indicator.

• Green (≥ 80%) — PMO is performing well across all functions
• Amber (60–79%) — some areas need attention but no critical failures
• Red (< 60%) — significant governance or performance gaps requiring immediate action

• PMI Pulse of the Profession — annual survey data on project/portfolio management trends
• Gartner PPM Magic Quadrant — vendor landscape analysis (for competitive positioning context)
• IDC Worldwide PPM Software Forecast — market sizing and growth data
• ISO 21504:2015 — Guidance on portfolio management
• ISO 21502:2020 — Guidance on project management