Project Portfolio
A portfolio-level view spanning platform modernization, customer experience, data & analytics, and corporate systems as four concurrent, multi-year programs, each split into two work-streams. The dependencies aren’t confined inside a single program the way most templates’ are — ERP go-live gates both legacy decommissioning and the HR systems migration, and a start-to-finish link keeps the checkout platform’s cutover honest against when the new public API actually starts. Built for a PMO or portfolio manager who needs to zoom out past any single project and show how the programs actually depend on each other.
- Platform Modernization
- Customer Initiatives
- Data & Analytics
- Corporate Systems
Templates are a Pro feature — every project starts editable, and this one drops straight in once you're signed in.
A portfolio chart exists to answer an uncomfortable question: have we committed to more than we can deliver, and does one programme's date secretly depend on another's? It's not a planning tool for any individual project, and it should never be detailed enough to be mistaken for one. This template covers two and a third years, four programmes, and the handful of real cross-programme dependencies that actually bind them together.
Who this project portfolio template is for
This is for a PMO lead, a transformation director, or an executive who owns a slate of programmes rather than any single one. It assumes multiple concurrent efforts with a shared funding pool, a governance body that reviews them together, and at least one programme whose start date genuinely gates another's.
The audience is a steering committee, an executive team, or a board. They're making portfolio decisions — start, stop, defer, refund — and they need to see the whole set at once, including where the dependencies actually are, which is the one thing individual project plans structurally can't show them.
What goes on a portfolio timeline?
Four top-level lanes, each split into two work-streams.
Platform Modernization splits into Infrastructure (network and security modernization, the core platform replatform, and legacy system decommission) and Core Services (a service mesh and API gateway, then public API v3).
Customer Initiatives splits into Web Experience (a self-service portal rebuild, a personalization engine, then checkout platform migration) and Mobile Experience (a mobile app rebuild, then an offline-first sync layer).
Data & Analytics splits into Data Platform (warehouse consolidation, a real-time streaming platform, then data governance) and Analytics & BI (self-serve BI, then predictive analytics).
Corporate Systems splits into ERP Modernization (core modules going live, then finance and procurement, then supply chain) and HR Systems (an HRIS migration, then payroll consolidation).
Seven milestones sit across the timeline — a kickoff, four programme-level delivery dates, a ribbon-only steering review, and a close-out.
How long are portfolio items?
Every bar on this chart is sized in months, not weeks of work. Platform Modernization spans about a year and nine months, driven by the core services work-stream running longer than infrastructure; Customer Initiatives runs the longest at about two years two months; Data & Analytics spans about two years; Corporate Systems runs just over two years.
Two observations matter more than the individual numbers.
First, most work-streams here run six months or longer. If something on your portfolio chart is a six-week effort, it's not a portfolio item — it belongs on a team's own plan, and putting it here dilutes the chart.
Second, all four programmes overlap through most of the middle two years. That's the chart's real content. Nobody wrote "we are overcommitted" anywhere on it; the geometry says so, and geometry is much harder to argue with in a governance meeting than a slide asserting the same thing.
Why there are dependencies here — and why so few
This template has sixteen links, which is more than most portfolio charts and still a small fraction of what a program roadmap would carry for the same twenty tasks. Most of them stay inside their own programme: the network and security work is tied to the core platform replatform via finish-to-finish, the service mesh is tied to the replatform's start, and each programme's second work-stream mostly follows its first.
Two links genuinely cross programme boundaries, and they're the ones worth drawing attention to. ERP go-live is start-to-start with both legacy decommissioning and the HR systems migration — both depend on ERP go-live starting, not finishing, because both draw on capabilities the ERP programme establishes early rather than waiting for its full three-year rollout. And the public API's start gates checkout's finish, a start-to-finish link: checkout is being rebuilt against interfaces the API programme exposes, so it can't be called done until that work has begun.
Every other relationship between programmes is left undrawn on purpose. At portfolio scale, most cross-programme relationships are financial and human, not sequential — the mobile app rebuild doesn't wait for the data warehouse, it competes with it for budget and engineers. Drawing an arrow there would imply a sequencing constraint that doesn't exist. Add a link only when one programme genuinely can't proceed without another, the way ERP go-live gates the two programmes it does here.
What to change for your own portfolio
Group by funding line, not by team
Lanes should match how money is allocated and decisions are made. If your board approves by business unit, the lanes are business units — that's the cut they'll reason about.
Set the steering review to a real meeting date
The review milestone is a decision point. Place it on the date the committee actually convenes, and the chart becomes a governance instrument rather than a picture.
Audit every cross-programme link before you keep it
This template has two. If you're tempted to add a third, check it's a genuine "can't start without" constraint and not a preference — the two here both connect a programme's start to another's start or finish, never a soft dependency.
Draw what's committed, not what's hoped
A portfolio chart including unfunded aspirations is the fastest way to lose the committee's trust. Keep a second chart for the pipeline if you need one.
Baseline annually
Portfolio drift is slow and therefore easy to miss. A year-old baseline beside the current view is often the single most persuasive artefact in an annual planning session.
Common mistakes on portfolio charts
Mixing altitudes. A two-year replatform and a three-week integration on the same chart makes both harder to read.
Too many lanes. More than about six top-level programmes and the chart stops being scannable. Nest work-streams under a programme instead of adding more top-level rows.
Dependency spaghetti. Arrows between programmes that merely compete for budget suggest sequence where the real constraint is capacity.
No decision points. A portfolio chart with no governance milestones is a status picture. With them, it's an agenda.
Day or week zoom. At this horizon, anything finer than months turns the chart into noise.
Presenting the portfolio
This chart's entire purpose is to be looked at by a group of people at once. Export a PDF for the board pack and a PNG for the slide, refresh it before each steering review, and keep the prior version alongside. Nobody in the room needs an account or access to your project tools to read it — which is exactly why the portfolio view works as a shared reference rather than as one person's spreadsheet.
Questions about this template
- What is a project portfolio timeline?
- A single chart showing every major programme an organisation has committed to, drawn at multi-year scale so overlaps and cross-programme dependencies are both visible. This template spans about two and a third years across four programmes, each split into two work-streams, twenty tasks in total. It's not a plan for any one project — it's the view that shows whether the whole set is deliverable, and where one programme's date is actually resting on another's.
- How many programmes should be on a portfolio chart?
- Enough to represent the real commitment and few enough to read, which in practice means four to six top-level lanes. This template ships with four, each nested into two work-streams so twenty tasks stay legible without forty separate rows at the top level.
- Why does ERP go-live gate both legacy decommissioning and the HR migration?
- Because both genuinely depend on it starting, not on it finishing. Legacy decommissioning and the HR systems migration are both linked to ERP go-live as start-to-start dependencies — real cross-programme constraints, not the aspirational arrows most portfolio charts avoid. When a dependency crosses a funding boundary like this, it's worth drawing, because the two programme owners need to see it.
- What does the start-to-finish link between the public API and checkout mean?
- That checkout's platform migration can't be considered *finished* until the new public API has *started*. Checkout is being rebuilt against interfaces the API v3 work exposes, so its completion is gated by that work beginning, not by it being fully done — a looser and more realistic constraint than forcing checkout to wait for API v3's entire multi-quarter rollout.
- What timescale should a portfolio chart use?
- Quarters or months, never days. This template covers roughly two and a third years, and at day resolution it would be unreadable. Zooming out isn't a loss of information at this altitude — precision beyond the quarter is false on a horizon this long anyway.
- How is a portfolio chart different from a program roadmap?
- Altitude and purpose. A program roadmap coordinates teams working toward shared delivery dates, so dependencies and milestones matter throughout. A portfolio chart mostly compares independent investments competing for the same money — dependencies appear only where a programme genuinely can't start without another, which is why this template has just four of them across twenty tasks.