KEVOS · Templates & Examples · Project Templates
Product Development Portfolio Schedule Register
A reusable portfolio register for active, completed, blocked, awaiting-commitment and resource-pending product-development projects.
Executive summary
The portfolio-level source contains 271 tasks and organises product-development work into active development, completed/inactive projects, items awaiting external commitment, and projects pending approval/resources. Completed work is also grouped by financial year, and on-hold work is explicitly separated. This page turns that structure into a reusable portfolio schedule/register template.
Why use a portfolio schedule
Individual project schedules answer “what needs to happen inside this project?” A portfolio register answers “which projects are active, blocked, completed or waiting for a decision, and where should limited attention and resources go?” The supplied portfolio file is not a detailed network schedule for every project. Instead, it acts as a high-level control list with status groupings and date/progress information.
That distinction is useful. A portfolio schedule should not attempt to duplicate every leaf task from every project. It should hold the minimum information required to govern the project population and link each entry to its detailed plan.
Source-derived portfolio states
| Portfolio state | Meaning in the supplied source | Recommended governance use |
|---|---|---|
| Active product development | Projects currently being progressed. | Review current forecast, next gate, blockers and resource needs. |
| Completed & inactive | Closed or no-longer-active work. | Retain for historical traceability and performance learning. |
| Awaiting external commitment | Work cannot meaningfully progress until a customer/stakeholder commitment is received. | Keep visible without consuming active-delivery status. |
| Pending approval / resources | Projects awaiting internal authority or capacity. | Use for prioritisation and resource-allocation decisions. |
| Projects on hold | Explicitly paused work within the inactive/completed structure. | Retain hold reason, owner and restart trigger. |
Recommended portfolio register fields
| Field | Purpose |
|---|---|
| Portfolio status | Active, awaiting commitment, pending approval/resources, on hold, completed, cancelled/inactive. |
| Project title / anonymous ID | Stable identifier that links to the detailed project schedule. |
| Project owner / accountable role | Role responsible for status and escalation. |
| Current phase | Concept, development, tooling quotation, tooling/testing, production/launch or another approved phase. |
| % complete / health | High-level progress indicator supported by the detailed schedule. |
| Forecast finish | Current expected project completion date. |
| Next gate | Next material approval or decision event. |
| Blocker / hold reason | What is preventing progress, if anything. |
| Decision required | Specific approval, commitment or resource decision needed. |
| Priority | Relative portfolio priority using an agreed method. |
| Last review / next review | Keeps blocked projects from becoming stale. |
| Detailed schedule link | Clean link or internal reference to the current project plan. |
Portfolio workflow
- Capture new demand. Add a project with enough information to identify the opportunity, expected deliverable and decision owner.
- Classify the state. If commitment or resources are not yet available, do not call the project active simply because it exists.
- Prioritise before activating. Compare value, urgency, strategic importance, technical risk and resource demand using the organisation’s approved method.
- Link the detailed plan. Once active, the portfolio record should point to the detailed schedule rather than duplicating it.
- Review active projects by exception. Focus on forecast movement, next gate, blockers and decisions rather than reading every task.
- Move blocked work visibly. Use awaiting-commitment, pending-resource or on-hold status as appropriate.
- Close and archive. Completed work can be grouped by financial year as in the source, while retaining lessons and actual completion information.
Portfolio dashboard questions
How many projects are active, waiting, on hold and completed?
Which active phase is consuming constrained design, tooling or testing capacity?
Which projects need a commitment, approval or resource decision this review cycle?
Which project finishes or next gates have moved since the last review?
Which blocked projects have exceeded their review interval without a new decision?
Which projects reached production/closure this financial year?
Do not confuse portfolio percentage with delivery certainty
The portfolio source contains percentage-complete values, including partial progress for active and blocked work. A single percentage is not enough to judge project health. A project can be highly complete but blocked on a critical final approval, while another can be early in development but progressing exactly to plan.
Use percentage as context, then govern by forecast, next gate, blocker, decision and risk. This prevents the portfolio from rewarding cosmetic progress updates that do not improve the probability of completion.
Ageing and restart control
Blocked categories are useful only if they include a review mechanism. For an item awaiting commitment, record who is expected to respond and the next follow-up date. For a resource-pending item, record the capacity decision or prioritisation review. For an on-hold project, record the restart condition and the impact of elapsed time on design validity, supplier quotation, tooling condition or test requirements.
When a project restarts after a long hold, do not simply reactivate the old dates. Revalidate the technical configuration, supply assumptions, test plan and remaining duration first.
Related KEVOS templates
Using portfolio states to make capacity decisions
The portfolio schedule is most useful when project state determines how capacity is counted. An active project should consume forecast engineering, tooling, test or workshop capacity. A project awaiting external commitment may remain visible but should not be treated as fully committed workload unless a restart window is credible. A project pending approval/resources should show the decision or resource constraint that prevents activation. Completed/inactive work should remain searchable for history but should not clutter the live execution view.
At each portfolio review, examine not only project dates but also the concentration of future demand by stage. Several projects entering detailed development at once may overload design capacity; several tools reaching first-off-tool status together may overload testing; several releases may create a procurement or logistics spike. The recurring stage structure across the source projects makes this kind of forward-looking capacity view possible even when individual products differ.
Portfolio review outputs
- Confirmed state for every project: active, hold/waiting, pending decision/resource, completed or inactive.
- A small set of near-term gates and dates that management is expected to act on.
- Visible resource or support-function collisions across projects.
- Explicit restart conditions for projects that are waiting on external commitment or internal approval.
- Archive/closure of finished work so active views remain usable.
- Escalations where portfolio priority and available capacity are inconsistent.
Avoid solving overload by assigning identical “high priority” labels to many projects. Portfolio priority should result in an explicit ordering or resource decision. When two projects compete for the same scarce test rig, tooling resource or workshop slot, the portfolio review should decide which one moves first and record the consequence for the other forecast.
Minimum data for a useful portfolio row
Keep the executive portfolio view deliberately small: project identifier, current state, accountable role, current stage, next gate, forecast gate date, overall finish forecast, priority and one concise constraint or decision. Detailed project tasks remain in the individual schedule. The portfolio view should answer “where is each project, what happens next, and what requires a decision?” without becoming a second full project plan that must be manually synchronised.