Portfolio and practice review
The portfolio review decides which commitments receive the practice's limited engineering, domain, platform, and operating capacity. The practice review asks whether an FDE practice is still the right organisational response to the work. Both are the practice lead's decisions, and both run on the evidence the engagement records produce.
- Enterprise
- Prepared by
- Date
- Version
Source: article three, "Manage the portfolio as a set of continuing commitments", "Define measures as evidence for specific questions", "Expand, reorganise, or close the practice", and "Bring the decisions together in a practice review".
Who fills this in, and what it decides
The practice lead maintains the portfolio view (section 1) continuously and completes the rest at each portfolio review. The FDE lead of each engagement confirms its row. The finance partner confirms the value evidence. The practice review (sections 5 and 6) happens on a fixed cycle and is presented to whoever funds the practice. The portfolio review feeds one decision per engagement: fund, sequence, pause, or stop. The practice review feeds one decision for the practice: expand, reorganise, partner, transfer responsibilities, or close.
Roles named in this document:
- Practice lead
- governs the portfolio and approves practice-level commitments.
- FDE lead
- owns delivery evidence for one engagement.
- Business workflow owner
- owns the process and the meaning of a useful result.
- Service owner
- owns deployment, support, dependencies, and technical change after release.
- Platform product owner
- owns shared capabilities and the maintenance they need.
- Finance partner
- agrees the value definitions and the cost allocation.
1. The portfolio view
One row per engagement. Accepting another engagement commits more than build time: the commitment continues after launch while ownership or shared maintenance is unresolved. Active engineering and waiting stay distinct, because waiting still costs coordination and context recovery, and blocked work creates excess demand when several dependencies resolve together.
Column definitions. Current stage: the delivery stage the engagement is in. Next decision: the choice needed before more capacity or scope is committed. Evidence status: established findings, unresolved uncertainty, and the linked records. Dependency: the data, platform, control, domain, or receiving-team work that can block progress, with its owner. Capacity: the engineering, domain review, platform, control, and support commitments, split into active and waiting. Future obligation: operation, maintenance, evaluation, support, and reassessment after release.
| Engagement | Owners (business, FDE, service) | Current stage | Next decision | Evidence status | Dependency and its owner | Capacity, active and waiting | Future obligation |
|---|---|---|---|---|---|---|---|
| requirementsfeasibilitylimited workflowcontrolled releasetransferoperation | |||||||
| requirementsfeasibilitylimited workflowcontrolled releasetransferoperation | |||||||
| requirementsfeasibilitylimited workflowcontrolled releasetransferoperation |
2. Blocked engagements
A blocked engagement needs an explicit decision, not nominal activity. Leaders can fund the missing capacity, narrow the proposal, or pause. The record names the dependency and the condition for restarting.
| Engagement | Dependency | Owner of the dependency | Decision | Condition for restarting | Decided by |
|---|---|---|---|---|---|
| fundnarrowpause |
3. The next increment
Compare the next increment of spending with current alternatives, not with what has already been spent. A nearly completed solution can still deserve cancellation if its remaining cost and obligations exceed its likely benefit. A difficult investigation can deserve continuation if its result resolves an important uncertainty. Shared engineering gets the same test: the work it removes and the teams likely to use it, against the consequence of delaying a local requirement.
| Engagement or shared proposal | Next increment cost | Expected result, from the measurement plan | Obligations it adds | Alternative use of the same capacity | Decision |
|---|---|---|---|---|---|
| fundsequencepausestop | |||||
| fundsequencepausestop |
4. Measures as evidence for specific questions
Measures are recorded observations that help answer a management question. A single score can hide a weak result in one area behind a strong result in another, so each measure carries its question and its interpretation limit. The practice lead records the current and previous values; the finance partner confirms the last row.
| Question | Evidence that helps | Why interpretation needs care | This period | Previous period |
|---|---|---|---|---|
| Does work progress through delivery? | Time by stage, waiting, rework, and active capacity | Faster delivery can reflect easier case selection | ||
| Do solutions remain useful? | Continued use with quality, outcome, and support evidence | Continued existence does not establish value; a recent release has had less time to show problems than an older one, and planned retirement differs from abandonment | ||
| Can receiving teams sustain operation? | Demonstrated capability and subsequent support demand | A signed handover can conceal dependence | ||
| Does learning improve later work? | Adaptation effort and maintained improvements used by later teams | Reuse counts omit suitability and maintenance | ||
| Does specialist assistance change? | Assistance required for comparable workflow families | The share may rise because the enterprise begins harder workflows, or fall because help stops being recorded | ||
| Does the practice justify further investment? | Outcomes, costs, continuing obligations, and credible alternatives | Attribution and observation periods limit conclusions |
Match the strength of the conclusion to the evidence. An adoption count demonstrates distribution. A claim that a component reduces delivery effort needs observations about integration and support against a comparison. A reliability claim needs failures and observation periods.
5. Where work waits, and why
Additional engineers help only when engineering capacity limits worthwhile work. The current constraint may be domain review, data access, release decisions, or receiving teams, and adding delivery capacity increases demand on those groups. Record where time went and where work waited before deciding what capacity to add.
| Where time went this period | Share | Where work waited | Share | Constraint it points to |
|---|---|---|---|---|
| Implementation | For domain review | |||
| Review and documentation | For data or identity access | |||
| Support and incidents | For a release decision | |||
| Transfer | For receiving-team capacity | |||
| Professional development | For platform work |
- The capacity the enterprise actually needs, on this evidence
- Conditions new staff will not inherit (relationships, informal access to experts)
6. Practice renewal
Renewal returns to the original organisational problem. It asks whether the enterprise still needs a distinct arrangement for this class of work, and whether the practice provides an acceptable combination of outcomes, cost, quality, and continuing ownership compared with the available alternatives. No single measure settles it: reduced assistance may reflect stronger capability or hidden support, and continued service operation may coexist with limited value.
- Does the enterprise still have the repeated delivery problem from the diagnosis, evidence
- Workflow families that now need standard components and advice, not delivery
- Workflow families that now justify a permanent product team
- Integrations that now justify platform investment instead of another engagement
- Decision
- expand | revise the mandate | partner | transfer responsibilities | close
- Decided by, and date
If the decision is to close or transfer responsibilities, the work the engagements created still needs owners. Closing the team does not remove it.
| Obligation that moves | New owner | Capacity required | Accepted on |
|---|---|---|---|
| Supported solutions | |||
| Shared assets and their backlog | |||
| Access responsibilities | |||
| Evaluation collections | |||
| Outstanding maintenance |
7. The practice review record
Every finding gets a consequence, a named action, an owner, and a funded next commitment. The specimen rows follow the article's closing example and are hypothetical: a screening brief that helps with public-company targets while private-target evidence stays unreliable, senior-review queues grow, the receiving team still needs help with retrieval failures, and a second coverage group asks for access under different permissions.
| Finding | Consequence | Action | Owner | Due | Funded from |
|---|---|---|---|---|---|
| Private-target evidence is unreliable (specimen) | The population is not supported by the release evidence | Narrow processing to public-company targets while the failure is investigated | FDE lead with the release authority | Engagement allocation | |
| Senior-review queues are growing (specimen) | Faster preparation has moved work, not removed it | Address review capacity before adding intake | Business workflow owner | Business unit | |
| Receiving team cannot diagnose retrieval failures (specimen) | A transfer condition is unmet | Add retrieval diagnosis to the readiness exercises; define any continuing specialist support | Service owner with the FDE lead | Service allocation | |
| Second coverage group requests access (specimen) | Different permissions and valuation conventions make this a new release decision | Assess the differences first; use it to test whether the retrieval improvement serves more than one solution | Practice lead | Portfolio decision | |
- Reviewed by, and date
- Presented to, and date
- Next practice review