Project vs program vs portfolio: one company, three decisions
A barcode rollout, a dispatch improvement program and an invoice project all need the same integration team. See what each level manages when the work won't fit.
The barcode rollout has an approved plan. So does the invoice automation project. Both teams have booked the same integration team for next month.
Each plan looks reasonable on its own. Put them together with production support, and there aren't enough days to do the work.
A project delivers a defined result. A program coordinates related work to obtain benefits that the projects cannot achieve as well separately. A portfolio brings investments and other work together so an organisation can choose priorities and commit resources.
Those differences show up in the decisions people need to make. Changing everyone's job title won't resolve the integration team's workload.
Let's use one fictional distributor to make the distinction concrete.
Project, program and portfolio compared
The distributor wants fewer orders to miss their confirmed dispatch date. It needs changes to promise-date rules in its ERP business system, warehouse barcode checks and shift training.
| Level | What it manages | Decision in this company |
|---|---|---|
| Project | Temporary work producing a defined result | Has the barcode pilot met its agreed acceptance checks? |
| Program | Related projects and activities coordinated for combined benefits | Are promise rules, warehouse checks and training ready to work together? |
| Portfolio | A selected collection of programs, projects and other work aligned with strategy | How much capacity goes to dispatch improvements, invoices and ongoing support? |
PMI defines a project as temporary work creating a unique product, service or result. Its portfolio standard, third edition, distinguishes coordinated program benefits from portfolio selection and prioritisation. A portfolio can include operations, and its components need not be directly related.
The diagram below puts those responsibilities in the same view. The projects inside the dispatch program contribute to one operating outcome. Invoice automation is a separate project; daily support remains ongoing work.
One barcode project can finish before the benefit arrives
For the barcode project, the agreed result includes tested scans, correct order records, trained pilot users and an accepted handover. The work breakdown structure example shows how to define those deliverables before scheduling them.
The project manager needs to manage scope, cost, dependencies and acceptance. If someone asks for an extra dashboard, the scope change example shows why that request needs an explicit decision.
But working barcodes can't fix a promise date set before stock will be available. They may prevent a wrong dispatch without reducing lateness. Closing the barcode project doesn't establish that the business has achieved the wider benefit.
That is where the program's coordination matters.
A program connects delivery to the shared outcome
In our example, three projects form a dispatch improvement program: revise the ERP promise rules, introduce barcode verification and prepare the shifts for the combined method.
The program needs to coordinate their rollout. Training against rules that will change next week wastes effort. New rules without a tested warehouse handoff could create a different delay. Someone needs to settle the sequence across projects and keep the intended service improvement in view.
The operations director owns the dispatch outcome in this fictional setup. The review follows orders against a consistent confirmed deadline, checks picking errors and explains changes in volume or mix. The benefits realisation article covers that ownership beyond project delivery.
Calling any large project a program doesn't create this relationship. Nor does using the same supplier or specialist. The reason to coordinate these three projects is the combined operating result and the dependencies needed to achieve it.
A portfolio decides what can be committed together
The finance team also wants invoice automation. Meanwhile, the business still needs support for its existing systems. These requests compete with the dispatch program for the people who can change and test the integrations.
For the next four weeks, assume 20 specialist-days are available after other commitments. The requested work totals 28 days: 10 for promise rules, eight for barcode work, six for invoices and four for ongoing support.
Shift training uses different people and is outside this particular capacity pool. It still needs its own allocation and a coordinated date.
One business / connected decisions
Which work can the company commit to?
The dispatch program coordinates three related projects. Invoice automation and ongoing support also need a place in the wider allocation.
Dispatch improvement program
Combined outcome: fewer late dispatches, with order accuracy protected.
Coordinate rules, warehouse handoff and readiness across shifts.
Invoice automation
Standalone project
Production support
Ongoing operations
Only the integration team's specialist-days are counted below. Training needs other people and its own dates.
Allocated in this window28 days0 requested days deferred
Against 20 available days8 days overAggregate capacity only, not a dated schedule
Swipe the chart sideways or focus it and use arrow keys. Exact values are in the table.
| Work | Requested | Allocated | Deferred |
|---|---|---|---|
| ERP promise rules | 10 | 10 | 0 |
| Barcode project | 8 | 8 | 0 |
| Invoice automation | 6 | 6 | 0 |
| Ongoing support | 4 | 4 | 0 |
| Total | 28 | 28 | 0 |
All 28 days remain in this window. Any shortage needs an explicit decision before these commitments can be accepted.
Allocation assumptions
All estimates refer to the same four-week window and interchangeable specialist capacity. Deferred work is not eliminated or completed. Ongoing support remains four days in every option. No overtime, task dependencies, calendars, skill differences, costs or benefit values are modelled. More available days need confirmation; moving the slider does not authorise extra staffing.
Accepting every request leaves the period eight days over capacity. Deferring invoices removes six days, so two days of overload remain. The barcode and promise-rule plans still need a decision.
In the phased option, the company allocates 10 days to promise rules, six to barcode work and four to support. That fits the assumed 20 days. Two barcode days and six invoice days move outside this window; they haven't disappeared.
This option illustrates a choice, not a recommendation. Perhaps delaying invoices creates a larger cost. Perhaps a mandatory support commitment cannot wait, or phasing barcode work postpones the whole dispatch benefit. The decision needs those consequences beside the capacity numbers.
A resource total is the start of the schedule
Even the 20-day option may be impossible on the proposed dates. The same specialist could be needed in two places on Tuesday, or a test environment might be unavailable until the final week.
The portfolio decision authorises priorities and allocations. The program and project plans then need to reconcile the actual dependencies and dates. Critical path explains the dependency side; a resource total alone doesn't perform that analysis.
If capacity falls to 16 days, our phased option is four days over. If it rises to 24, all 28 requested days still don't fit. Moving the slider makes the shortage visible without pretending the estimates are certain.
Don't fill the apparent gap by silently removing the four days of support. That is a change to an operating commitment, with someone responsible for accepting its consequences.
Bring the decision to the right level
A failed barcode acceptance test belongs with the project team and its approval path. A conflict between training and the combined rollout needs program coordination. A dispute over whether invoices should take capacity from dispatch needs the organisation's investment and priority authority.
In a small business, the same person may make all three decisions. The distinction still helps them say which commitment they are changing and whose plan must follow.
Hoshin Kanri and OKRs connect the discussion to strategic priorities. A portfolio review makes those priorities concrete when several worthwhile requests cannot all proceed now.
For the next review, bring one view of requested work, available capacity and consequences of deferral. Then update each affected plan to match the decision. Separate project approvals are much easier to trust when they agree with the company's total commitments.
Sources and example notes
- PMI: What is a Project?, temporary work and a unique result.
- PMI: The Standard for Portfolio Management, third edition, 2013, printed pages 3–5 and 11. Portfolio components, coordinated benefits, strategic alignment and resource allocation. This is the cited edition, not a claim about the latest edition.
The company, work packages, roles and allocation choices are fictional. Specialist-days measure effort within one four-week window, not duration, payroll savings or a complete schedule. No benefit is assumed to be achieved merely because work fits the allocation.