Why a portfolio is a different job
Managing one project well is a matter of scope, schedule and cost on that project. Managing ten is not simply the same job repeated ten times — it introduces a whole class of problem that does not exist for a single project: the projects compete. They compete for the same machines, the same crews, the same store of material and the same management attention. A tool that handles each project beautifully in isolation can still leave you blind to the one thing that most often sinks a busy shop — two jobs quietly booking the same resource for the same week.
This is why a Gantt-per-project, folder-per-project approach breaks down as the book grows: each project looks fine on its own, so nothing warns you until the welding bay cannot serve two jobs and both slip. Managing a portfolio well means adding a layer above the individual projects — a view of the whole book, a view of how shared resources are loaded across it, and one consistent way of reading every project's health.
The portfolio view — see the whole book
The foundation of portfolio management is a single place that lists every project with its essentials — status, owner, customer, budget, progress and dates — so you see the whole book at a glance rather than opening projects one by one. Organising that list by lifecycle status is what makes it usable: separate tabs for what is active, what is on hold, what is completed and what is inactive let a manager direct attention where it is needed instead of scanning a flat list.
- Active — projects running now, each rolling its tasks up into a live progress and cost position, so the ones needing attention stand out.
- On hold — paused work awaiting a decision or an input, kept visible so nothing silently stalls off the radar.
- Completed — closed projects with their final estimated-versus-actual, the raw material for a sharper next quotation.
- Inactive — shelved projects kept on the record rather than deleted, so the history survives.
Each project in the list is itself a roll-up, so the portfolio view is not a separate summary someone maintains — it is the sum of the live projects beneath it. Drill into any project and you get its WBS, Gantt, Bill of Resources and bills; step back out and you see the book. That two-level navigation is the heart of the Projects & Portfolio feature, and it is what the pillar guide describes as the layer that decides which projects to run.
Resource contention, the core problem
If there is one problem portfolio management exists to solve, it is resource contention. On a build-to-order business, the expensive resources — a welding bay, a crane, a CNC machine, a skilled crew — are shared across projects. Each project's own schedule can be perfectly valid while the portfolio as a whole is impossible, because two projects have independently committed the same resource to the same week. Neither project's Gantt shows the problem; it is a property of the pair, not of either one.
The cost of missing it is high and asymmetric. Caught early, a clash is a calendar decision — shift one project's non-critical task and the conflict evaporates for almost nothing. Caught late, it is a delay that has already happened, forcing overtime, hired plant or a broken customer date to recover. It is one of the biggest drivers of the overruns in why projects overrun on cost and time, and precisely the failure a single-project view can never catch.
Running several projects off several disconnected Gantts?
We can show you a live portfolio — every project in one list and a resource-wise Gantt exposing the clashes between them — in 30 minutes.
The resource-wise Gantt
The tool that solves contention is a second kind of Gantt. An ordinary project Gantt plots tasks against time for one project. A resource-wise Gantt flips the axis of attention: it plots machines and crews against time across every project at once, so each resource's total commitment is visible as a single loaded bar. Where that bar exceeds the resource's capacity, you have found a clash — before any work starts, while it is still just a line on a chart.
The discipline is to make the resource view a habit, not a rescue. Reviewed every week alongside the project Gantts, it turns contention from an emergency into a routine adjustment — you are always resolving next month's clash this week, cheaply. For how that fits the day-to-day tracking rhythm, see how to track project progress, which covers the same Gantt from the single-project side.
Shared masters end the re-keying
A subtler benefit of running the portfolio on one engine is that the building blocks are defined once and shared. When every project draws on the same resource master, the same item master and the same party master, a machine, a material or a customer exists in exactly one place — so its rate, its specification and its details are consistent across every job, and nothing has to be re-keyed as work moves between projects or between modules.
That consistency is what makes cross-project comparison meaningful: if two projects price the same crew from the same resource master, their labour costs are genuinely comparable; if each kept its own rate in its own spreadsheet, they would not be. Shared masters also mean the estimate, the material issue and the bill for any project ride the same foundation as procurement and accounts. Material issued against a task through Inventory & Procurement and bills posted to Fast Billing & Accounts draw on those same masters, portfolio-wide — the connective tissue the pillar guide calls the point of the whole system.
How a portfolio view turned three clashes into calendar decisions
An engineering and fabrication shop runs six projects at once — a mix of ETO machine builds and structural fabrication jobs — on one engine. The portfolio list shows four active, one on hold awaiting client drawings, and one completed with its final estimated-versus-actual feeding the next quote. In the weekly review the resource-wise Gantt reveals the shared CNC machine over-loaded in week nine and the senior welding crew double-booked in week eleven, each across several projects. Spotted a month out, both are resolved by shifting non-critical tasks — dependencies re-flow, customer dates hold, no overtime is spent. Every resource is priced once from the shared master, so the six projects' costs are directly comparable and one set of KPIs reads the same on all of them. This is the profile behind deployments such as Micro India and DVC Process.
Prioritising across projects
With the book and the resource load both visible, prioritisation stops being an argument and becomes a decision on evidence. The signals are consistent because every project is read the same way: status and progress, estimated-versus-actual cost, forecast finish against the promised date, and the demand each places on shared resources. When two projects want the same crew, you are not choosing between abstractions — you are choosing which concrete task yields, with the cost and date consequences of each option visible.
The practice that makes prioritisation stick is to record it on the record. Priority set on the project and its tasks is a decision others can see and the schedule can honour, not a verbal instruction that evaporates by Thursday. And because the completed tab preserves each closed project's estimated-versus-actual, prioritisation gets smarter over time: you learn which kinds of project actually consume the scarce resource, and price and sequence the next ones accordingly. The metrics behind these comparisons are covered in essential project reports & KPIs.
A portfolio review that scales
The routine that keeps a growing book under control is short, weekly, and run from the top down — portfolio first, then into the projects that need it.
How Fast Project Software runs a portfolio
Fast Project Software is built to manage the whole book on one engine, not a plan per project. Mapping portfolio management to the product:
Because it runs on the shared Fast Suite platform, the portfolio, the resource pool, procurement and billing are one connected system rather than a stack of per-project files — cloud or on-premise. INR pricing is indicative; confirm the commercial treatment with your CA. See pricing or the pillar guide.
Frequently asked questions
How do you manage multiple projects at once?
You manage multiple projects by running them on one engine with a portfolio view rather than a plan-per-project: a single list organised by lifecycle status (active, on hold, completed, inactive) each rolling up its own progress and cost, a resource-wise Gantt showing how shared machines and crews are loaded across every project at once, shared resource, item and party masters so nothing is re-keyed, and one consistent set of KPIs read the same way on every job. The shift is from watching projects one at a time to seeing the whole book and the resources they compete for.
What is the hardest part of managing a project portfolio?
The hardest part is resource contention between projects. Each project can look perfectly schedulable on its own Gantt, yet two of them may have booked the same welding bay, crane or crew for the same week. A per-project view never reveals the clash — it only surfaces as a delay when the resource physically cannot be in two places. Seeing the whole portfolio's demand on shared resources in one resource-wise view is what turns that hidden clash into a calendar decision made before work starts.
How do you prioritise across several projects?
Prioritise across projects using consistent, comparable signals: each project's status and progress, its estimated-versus-actual cost, its forecast finish against the promised date, and — critically — the demand each places on shared resources. Because a resource-wise Gantt shows where projects compete for the same machine or crew, prioritisation becomes concrete: you decide which project's non-critical task yields so a more urgent project's critical task proceeds. Priority set on the project and its tasks is recorded, not just discussed.
How does Fast Project Software manage multiple projects?
It lists every project under Active, On Hold, Completed and Inactive tabs, each rolling its tasks up into one progress and cost position. A resource-wise project Gantt shows how machines and crews are loaded across all projects, so contention is visible before it becomes delay. Shared resource, item and party masters mean the same crew, material and customer are defined once and used everywhere, and one consistent set of reports and KPIs reads the same on every project. Dhruv AI adds portfolio dashboards and plain-English questions over the whole book.