Portfolio Implementation Guide

How to use this guide

This guide helps you put the AI Portfolio Guide into practice. It explains what to do before, during and after a decision about AI work.

Start with one real decision and the tools you already use. You can collect information from reports and spreadsheets. An automatic connection is an option when it is worth maintaining; it is not a starting requirement.

A portfolio is the collection of AI-related work you fund, oversee or run. A bet is a limited commitment of time, money or effort to answer a question. Evidence is the information that helps you judge that question, with its sources and limits visible.

A portfolio board means the people already authorised to make these investment decisions. It could be a business owner, leadership team or committee. This guide does not create a new board or change anyone’s authority.

Working titles such as portfolio lead, chair and supporting team describe work to assign, not new AIPF roles. Use your local names. Examples are invented, and no implementation results are claimed.

AIPF Portfolio in one view

Start with a useful question. Gather the facts needed to answer it, make a decision, act within its conditions and return with the result.

The three AIPF evidence phases still apply: Validate, Show, and Set Boundaries; Prove the End-to-End Evidence Slice; and Decide and Operationalise. In everyday terms: understand and show the idea; test a small connected part; decide on ongoing or wider use.

A gate is the authorised decision at the end of a phase. A routine portfolio meeting is not automatically a gate. Each decision record states whether it is a Gate 1, 2 or 3 decision or a decision taken within a phase.

Each of the three evidence phases can involve several turns of the review cycle. Only Gate 3 can produce a Scale decision. Other decisions can occur at any gate, and a stop condition can interrupt work at any time.

Agree the working arrangements

Decide what this review is responsible for

Write a short operating charter: an agreement about purpose, owners and how decisions will be made. Record:

• The work included, desired outcomes, obligations and priorities.
• Which decisions these people may make, which stay with others and when an issue must go elsewhere.
• Who can approve spending, accept risk, permit release and confirm benefit.
• Review dates, submission deadlines, the date covered by the information and an urgent-decision route.
• Money available and the people needed to deliver, review, adopt and support the work.
• Where decisions, disagreements, conditions and follow-up actions will be kept.

Use existing financial, procurement, risk and release rules. Portfolio visibility does not give someone extra authority. Work already delegated to a product owner stays there unless it exceeds agreed limits or affects a wider decision.

Name the people who will do the work

Assign the Portfolio Guide’s five responsibilities: Portfolio; Financial, Value, and Benefits; Concentration and Risk; Decision-Capacity; Workforce and Competence. Their plain descriptions are in the Portfolio Guide.

The portfolio lead keeps requests moving. The supporting team is the person or team preparing the review and recording its decisions. Sponsors explain their requests. Finance checks financial information. Source owners confirm their records. Benefit owners report results. Specialists check risks and controls.

The chair makes sure the group reaches a decision within its authority. The expenditure owner remains answerable for spending. One person may perform several jobs, but the responsibilities must stay clear.

Include existing work and required work

Include proposals, experiments, research, funded work, running products and shared services. Also include renewal, maintenance, resilience, compliance and closure where relevant.

Give each bet a stable reference, owner, intended result, next request and stop or review condition. A bet can support several products; a product can receive several rounds of support. Research may reduce uncertainty without authorising a build. Required work does not need to pretend it will earn revenue.

Give the person setting up the process access to approved records and the people who own them. Agree one manageable pilot and an upcoming decision. Make time for reviewers and the people who will run the process afterwards.

Set up one working cycle

Use these seven activities to establish the process. Return to an earlier activity when you discover a gap. They are setup guidance, not extra AIPF gates.

Discover

Choose the pilot’s scope and a real decision. Identify existing requests, commitments, forums, reports, records, owners and review capacity. Find the product and family evidence already available.

Keep: the pilot boundary, one representative bet, relevant competing commitments and a list of sources. Name an owner for each access or ownership gap.

Agree

Agree the charter, responsibilities, reporting dates and shared information checklist. Decide which missing facts prevent which decisions. Set active-work limits with the people who will do the reviews.

Keep: agreed owners, definitions, limits and decision authority. Resolve authority gaps before treating the process as ready.

Configure

Set up the request list, stable Bet IDs, five portfolio views, recommendation note, decision record and funding terms. Link to existing sources. Keep the Framework’s decision states distinct, and keep purpose, organisational owner and accounting treatment visible.

Keep: a way to follow one request through its evidence, decision, conditions and result. Existing documents or spreadsheets can do this.

Keep record patterns proportionate. An Investment Recommendation Memo and Internal Funding Terms may be sections, fields or linked views in existing records. They are implementation patterns, not additional mandatory framework artefacts or a requirement for separate documents.

Make templates easy to find and reuse

Keep an owned, versioned template index. It should cover requests, source checks, assessment, recommendations, decisions, funding terms, release and results. Each working procedure should identify its template and required information. Preserve blank master templates and show which versions are approved.

Before creating a record, people and AI assistants should consult the procedure and template index. Record the procedure and template versions used. Reuse existing records where appropriate. Keep links to evidence and the work list. Explain local changes to templates; have material departures reviewed before others depend on them.

Check: a new person can find the right template and tell whether it is approved. A missing or unapproved template is a reported gap, not permission to invent an approved record.

Identify which templates are required for the particular task. A missing required template blocks that dependent record task, not unrelated discovery or discussion. An agreed, proportionate record in an existing tool can serve as the approved template.

Connect

Choose manual reports, automatic collection, or a mix for each source. Agree access, ownership, dates, meanings and matching rules. Compare the collected information with an identifiable source report before relying on it.

Keep: a checked, dated set of records, source-owner confirmations and unresolved issues. For automatic collection, name the support and recovery owner.

Pilot

Follow one real bet from source information to decision, authorised action and return of results. Include enough surrounding work to test the resource trade-off.

Try a missing or conflicting figure, stale or incomplete collection, a full review queue and an unmet release condition. Check that each is visible, assigned and cannot quietly become “ready” or “approved”.

Keep: results, corrections and remaining gaps. If the date for reporting results has not arrived, the pilot is incomplete. Name what remains and who will finish it.

Embed

Agree the recurring collection, preparation, meeting, release and review dates. Look at preparation time, corrections, waiting work, late evidence and review overload. Check whether evidence actually changed an amount, condition, sequence or decision.

Remove fields or meetings that add no useful decision information and meet no necessary obligation. Sample rejected and deferred requests to check that good opportunities are not being lost. Faster approval or a higher rejection rate is not a measure of better judgement.

Keep: the next cycle, improvements and unresolved issues, with owners.

Hand over

Have the people who will run the process repeat it. Check access to sources, definitions, mappings, history, open conditions and support. Name who watches for collection failures and retests changes. Keep outstanding evidence returns visible.

Check: the process can run without depending on one adviser or individual. Handover does not prove all outstanding results have arrived.

Check reuse in a fresh AI session

Create a short starter pack with the agreed guides, procedure, template index, setup checklist, AI rules, owners and local adaptations. Make it discoverable from the normal starting point.

Test a fresh AI-assisted session with a small record task. Do not tell it which template to select. Check whether it finds the procedure, chooses the approved template, records both versions and preserves required facts and work links. Label the output as a test record.

Also test a missing or unapproved template. The dependent task must stop and report the gap. Record expected and actual behaviour, human review and unresolved issues. Retest after important changes to guides, templates, tools or permissions.

A new engagement needs its own scope and permissions; it does not inherit another organisation’s approvals or example data. A starter pack’s presence alone does not prove reliable reuse.

Run each review cycle

Use the steps below as working instructions. Local deadlines, limits and titles come from your charter. Owners coordinate the step; Finance, source, risk and expenditure owners keep their own authority.

Capture and screen a request

When: a new request arrives or someone wants to change a commitment. Owner: portfolio lead or supporting team.

Ask for a short request before a full business case: the need or obligation, intended result, owner, evidence so far, previous commitments, alternatives and smallest useful next step.

Check whether it fits the portfolio, overlaps existing work, needs urgent attention, sits within a delegation and is roughly affordable. Look at the people needed to review it. Keep delegated work with its owner. Return incomplete requests for clarification. Advance a request only when the next step is justified and there is capacity.

Finished when: the request has a Bet ID, a recorded reason for its treatment, and a named next action. A request waiting for capacity remains visible.

Collect, check and save the information

When: the reporting date arrives or a correction is authorised. Owner: supporting team with source owners and Finance.

1. Ask for the agreed scope, fields and period using the selected collection route.
2. Match IDs and dates. Check meanings, units, counts and financial totals against their source records.
3. Return conflicting or missing information to its owner. Ask Finance to resolve important financial differences.
4. List unresolved issues and how they affect each decision.
5. Save a dated snapshot: the exact set of information used for the review. Record source versions, conversions, confirmations and exceptions.

Finished when: the snapshot and its limits are clear. Mark each item ready, conditional or not ready for its particular decision. A later correction gets a date and explanation; preserve the earlier snapshot.

Assess within capacity

When: a request needs investigation. Owner: portfolio lead, Decision-Capacity owner and relevant specialists.

Agree limits for the work that is scarce: specialist reviews, investigations, difficult decisions in one meeting or starts needing heavy integration. Show waiting time and blocked work as well as active work.

When the queue is full, wait, finish or stop something already active, or record an authorised trade-off. Say what is displaced. A senior sponsor does not get an invisible exception. Genuine urgency follows the agreed route and gets reviewed afterwards. Required work still needs people and time.

Give each investigation a question, owner, effort limit and due date. Seek the evidence that could change the next decision. Use existing product and family findings, including contrary results, instead of repeating every review.

Finished when: the findings, options, remaining questions and recommended next action are clear. A small test can be sensible while uncertainty remains; larger or harder-to-reverse commitments need stronger evidence.

Prepare and share the decision pack

When: the preparation deadline arrives. Owner: supporting team, checking with accountable owners.

Start with the whole portfolio: available resources, existing commitments, review shortages, disappointing benefits, shared risks, overdue conditions and decisions due. Separate information updates from requests for a decision.

For each decision, write an Investment Recommendation Memo—a short note containing:

• The exact request, owner and next limited commitment.
• Intended value or obligation; supporting and contrary evidence; what remains uncertain.
• Past decisions and funding, actual spending, outstanding commitments, requested amount and ongoing costs.
• Real alternatives, such as a smaller test, different sequence, shared solution, deferral or stop.
• Effects on other work and the people needed to deliver, review, adopt and support it.
• The recommendation, reasons, specialist views and disagreements.
• Proposed conditions, benefit and evidence owners, stop triggers, return date and authorised decision forum.

Give people time to read and challenge it. Link to sources. Do not let a single score hide the difference between revenue, service, resilience and mandatory outcomes.

Finished when: the versioned pack makes the decision and open issues clear. Return items missing evidence essential for that decision. Explain when an uncertainty is the reason for a small test. Tell readers about important late changes and preserve the original pack.

Run the portfolio meeting

When: a scheduled review or authorised urgent decision is due. Owner: chair; supporting team records the result.

1. Confirm authority, attendance requirements and conflicts of interest. Route matters outside this forum’s powers to the right owner.
2. Review earlier promises first: evidence due, open conditions, incidents, cost changes and benefit shortfalls.
3. Check remaining money and the people available to deliver, review and support the work.
4. Hear the request, recommendation, evidence and alternatives. Ask what other work would wait.
5. Challenge important claims and hear disagreements. Ask what finding would change the decision.
6. Decide and record the owner, scope, limits, conditions, next review and which gate the decision belongs to.
7. Read the actions back. Make sure affected owners understand what may happen and what must wait.

Finished when: the record includes reasons and dissent, and owners understand the actions. If evidence or authority is insufficient, record the gap and next action without implying approval.

Record terms and control release

When: a decision supports a commitment or changes its conditions. Owner: expenditure owner, supported by Finance and relevant control owners.

Write Internal Funding Terms: the agreed limits and conditions for this round of work. Include the Bet ID and round, decision reference, purpose, money and effort limits, funding source, accounting treatment, milestone, conditions, evidence due, benefit owner, stop triggers and return date.

Keep the decision separate from release: permission to make funds available or start the affected work. Confirm required Finance, procurement, access, risk and operating approvals. Check that people can deliver and absorb the change.

Record release status and the authority reference separately. If a condition is unmet, hold the affected release or work, tell its owner and return important changes to the right decision-maker. Do not quietly rewrite the decision to fit what is available.

Finished when: the terms match the decision and each affected release is either authorised or visibly held. Agreement in principle cannot bypass an open condition.

Review results and reconsider commitment

When: results are due or a stop/review trigger occurs. Owner: portfolio lead coordinates; the authorised decision-maker decides.

Compare results with the terms actually agreed. The benefit owner supplies the starting position, period, method, observed result and limits. Finance supplies spending and remaining commitments. Product and family owners supply tests, acceptance and operating evidence.

Include training, adoption, human review, maintenance, support and AI usage costs. Explain how a shared benefit is counted once. Time released is not a cash saving unless evidence shows how it becomes one.

Review again when evidence is late, results disappoint, costs change materially, an incident occurs or an important assumption no longer holds. Set these triggers in advance.

Make stopping effective: end further commitments within authority, notify affected owners, reassign capacity, handle service and contractual obligations, and preserve the evidence. An obligation may still need a replacement approach. Any recovery work needs its own question, limit and return date. Deferral needs a condition for reconsideration.

Finished when: results lead to a clear next decision or closure, with owners and actions. A late report is not automatic permission to continue.

Reference checks for the people running the cycle

Use this section when setting up or checking records. It provides the detail behind the simpler steps above. A necessary check still applies even if only a specialist performs it.

Apply the shared information fields

Use the Framework’s shared information checklist at product, family and portfolio level. It gives each field’s meaning and main source owner, and how to mark missing information. The portfolio cycle adds the money rules below.

Keep actual, committed and forecast amounts separate. A forecast may already include actuals or commitments; define this before adding figures. Record currency, period and accounting treatment. Finance resolves incompatible figures. Capital spending (CAPEX) and running costs (OPEX) do not, by themselves, determine who decides.

Keep a source register naming the agreed record for each important fact. A work-tracking tool may show progress; it cannot by itself prove benefit or spending authority.

Collect reports manually

Use approved reports or exports when they can supply the information reliably. The board agrees what it needs; source owners provide it. Board members do not need to combine spreadsheets themselves.

1. Ask for a defined set. State scope, fields, format, reporting date, owner and deadline. Collect only what is needed.
2. Export from the agreed source. Record report filters, period and extraction time. Obtain finance, delivery, benefit, risk and capacity records from their owners.
3. Keep the original. Transfer through approved, access-controlled storage. Retain a dated source copy; corrections create a new version.
4. Check completeness. Confirm owner, dates, columns, units, count and coverage. Look for duplicate IDs, missing records or changed formats. Check financial totals against the source report. Set aside unexpected sensitive fields for authorised review.
5. Match the records. Link them to Bet IDs. Record any conversions and keep original values. List unmatched records and conflicting figures; do not guess.
6. Resolve and confirm. Source owners explain differences. Finance confirms material financial checks. Show any remaining issue and its effect on readiness.
7. Save the review snapshot. Keep source versions, matching rules, conversions, confirmations and exceptions together. Date and explain late corrections.

Result: original exports, a checked portfolio view and an issue list that can be reproduced next time. Reduce retyping where possible. A spreadsheet formula still needs correct inputs and checking.

Collect records automatically through an API

An API is a way for one system to request information from another. Use it when recurring collection is worth the setup and support. It changes the collection method, not who owns the facts or decisions.

The technical owner performs these checks. Other readers need to know that the checked result has a source, date, owner and visible failures.

1. Limit access. Use an approved source and suitably restricted read access. Manage credentials through approved security arrangements; never put them in decision packs.
2. Define the request. Agree fields, filters, period, update timing, IDs and completeness checks. Cover results delivered in several pages or batches, changed/deleted records, time zones and format changes.
3. Test against a trusted report. Compare the same scope and period. Test missing records, duplicates, failed requests, changed fields and old data as well as successful collection.
4. Record each run. Keep a run ID, source, times, request/mapping version, counts and completion status. Use a controlled reporting area, not an editable decision record. Check that every expected batch arrived.
5. Apply the same checks as manual collection. Confirm meanings, units, totals, coverage and exceptions with source owners and Finance.
6. Show failures. Mark incomplete, failed or stale collection. Keep the last checked snapshot with its date and warning, or withhold affected information. Notify its owner. Use an approved manual export if suitable; do not hide gaps with unrelated periods.
7. Release only the checked snapshot. Give the supporting team its sources and exceptions. Monitor age, failures and differences. Name the support owner and retest after access, field or mapping changes.

Result: a supported information feed. Read access does not authorise changing source records, approving bets or releasing funds.

Combine routes without hiding differences

You may use manual reports for one source and an API for another. Record route and date. Match IDs and reporting periods before combining them. Do not count an item twice because both routes supplied it.

Preserve original values and explain conversions. Compare record coverage and control totals before using the snapshot. Finance resolves financial differences; other source owners resolve meaning. Show unresolved differences, their decision impact, owner and next action.

Keep a reliable manual route when it is sufficient. An automatic route should justify its maintenance and recovery effort.

Use five connected views

Create the Portfolio Guide’s five artefacts as views of these same records. They can be tabs, reports or linked notes.

Keep disagreements and uncertainty visible. A summary must not turn “ready for discussion” into “approved”, or “scale requested” into “scale justified”. Link to the original evidence rather than asking AI to manufacture certainty.

Connect product and family records to the decision

Use the Framework’s phase handoff table to see what product and family records supply at each phase and what each portfolio gate returns. Repeat or combine those steps as the work requires; they are not extra gates. Keep claims attached to their sources, context and limits, and tell affected owners when something important changes.

A family is useful for shared decisions, not compulsory reporting. Products can connect directly to the portfolio. Only changes outside a person’s authority need a different decision-maker.

Check the AI rules and people’s ability to intervene

The AI Model Harness means the rules and checks around AI use. Link the product’s relevant tests, permissions, acceptance and operating results to the bet. The Product Guide explains it; this guide does not require a new technical interface.

Controls apply to AI performing Portfolio work itself. Product or Family evidence does not validate a Portfolio assistant’s own summaries, calculations or actions. Check its source fidelity, calculations, permissions, logs and escalation behaviour for the actual task; link those evaluated controls to the Autonomy Boundary Map.

Record permitted actions, owners, trained reviewers and stop conditions in the Autonomy Boundary Map. Check whether the same tools or sources influence both a recommendation and its review. Similar AI answers may share a blind spot.

The Workforce and Competence owner checks whether people can evaluate, intervene and recover. Changed models, sources, tools or access may need new tests. More automation needs evidence and support; a busy portfolio is not enough reason to allow it.

Handle problems openly

Worked example

One request, limited reviewer time

This example is fictional. Amounts and effort illustrate decisions, not standard AIPF limits.

A service team wants to test AI-assisted summaries before a staff member prepares a response. BET-017 is the service test. BET-009 is required work that needs the same specialist.

Capture. The sponsor proposes two weeks of work and four specialist days. The forecast cost of the proposed work is AUD 12,000. This already includes AUD 3,000 committed under an earlier decision.

Assess. Finance confirms that adding the AUD 3,000 again would double-count it. Only two specialist days are available without delaying BET-009. The team compares a smaller test, a later start and deferral.

Decide. At Gate 1, the authorised owner chooses Proceed with a smaller test than requested. Its total cost limit is AUD 6,000, including the existing AUD 3,000 commitment; only AUD 3,000 of new commitment is authorised. The limit is two specialist days. BET-009 is not displaced. The result is due in two weeks. This early-test decision is not Scale.

Release. The funding terms repeat those amounts and limits. Approval to use the required information is still missing, so affected work is held. It starts only after the appropriate owner confirms access, other required conditions and capacity. The release reference is recorded separately.

Review. In this fictional result, summary preparation is quicker but staff need longer to check it. Overall benefit is still uncertain. Finance reports actual spending and any remaining commitments. The decision is Revise: change the test and return with another limited request. No cash saving or wider-use permission is claimed.

Follow the same facts through all three guides

The product record holds the original test, cases, results and limits. The family record checks whether the receiving service can use the summary and records extra checking work. The portfolio record compares that result with cost, scarce reviewer time and alternatives.

The decision returns to the product owner with the permitted change, effort limit and human-review requirement. All three records link to the same result. A knowledge-source correction would identify affected tests and decisions; it would not silently rewrite their history.

The five portfolio views show the bet, reviewer constraint, shared dependencies, benefit uncertainty and allowed AI actions. Evidence that is late, cost beyond the limit or a failed control triggers review.

Check that people can repeat the cycle

Before expanding the process, ask someone who did not assemble the example to find the request, sources, decision, funding terms, release status and results. Have them explain the next allowed action and an unmet-condition case.

HarbourBridge companion: demonstrated and incomplete coverage

The HarbourBridge case study summarises the rehearsal and technical evidence. It distinguishes recorded application from retrospective interpretation and explains the limits without requiring access to private demonstration tools.

HarbourBridge illustrates synthetic portfolio comparison, constrained reviewer capacity, simulated decisions and a bounded technical test of the decision-support capability. It does not establish real investment approval, realised benefits, completed Phase 2 evidence for the underlying initiatives, or coverage of every scope and phase. Keep this companion alongside the generic example above. Neither a particular tool nor access to the demonstration is required to use the guide.

On the HarbourBridge board, Closed is a terminal workflow state once the commitment and remaining obligations are resolved. It is not a fourth phase, an extra cycle step or proof of success.

Sources

Reading that informed this revision

Atlassian Agile informed the use of plain explanations and examples. Its work-in-progress guide explains limiting active work. LeSS and Scrum.org’s Scaling Scrum encourage attention to the whole result and unnecessary coordination. The Nexus Guide focuses on dependencies between teams working on one product.

The graphical overview here is an original explanation of AIPF’s investment cycle. It does not reproduce the LeSS image, a Sprint diagram or their team structures. AIPF’s portfolio decisions are distinct from multi-team Scrum delivery.

Related guides

• AI Product Flow Framework
• AI Portfolio Guide
• AI Product Family Guide
• AI Product Guide

Acknowledgements

Authors

Written by Rick Molony and Ghulam Akbar, with AI assistance.

Licence

This guide is offered under the Creative Commons Attribution 4.0 International licence.