PPM for Project Portfolios: Choosing a System Without Excel

When the project portfolio no longer fits in Excel

While you have 3–5 projects, Excel feels convenient: one sheet for the plan, another for people, a third for budget. But when projects grow to 10 or more, maintaining spreadsheets takes more time than managing the work.

The problem isn’t Excel as a tool, but that a portfolio is a living system. Tasks move every day, people switch between initiatives, and money is spent off-plan. A spreadsheet doesn’t know that a change in one project should immediately affect team workload and cost forecasts.

Typical pains follow: the same data lives in different file versions, reports are assembled manually, and the consolidated picture is ready only “by Monday” (when decisions were already made on Friday). As a result, the portfolio looks manageable only on paper.

Spreadsheets most often lose the most important things: real people workload (who is doing what and how many hours remain), actual costs and their link to work, and priorities. A project can be “green” on schedule but already have half the budget spent and key specialists pulled from a more important initiative.

When leaders need quick answers, Excel starts to slow down. Common questions are:

• which 3 projects will deliver the biggest impact this quarter and why;
• where are overloads and which teams have no free capacity left;
• which projects to pause if the budget is cut by 10%;
• why actual costs differ from the plan and where the deviation happened;
• what happens to the portfolio if a key specialist goes on vacation or is moved to another project.

If you can’t answer these in 5–10 minutes without rechecking numbers, the portfolio has outgrown spreadsheets. Usually at that point a request appears for a PPM system where projects, resources and budgets are linked and updated in one place.

What PPM is in simple terms and what it solves

PPM (Project Portfolio Management) manages not a single project but the whole set of company projects as one portfolio. If project management answers “how to deliver this work on time and on budget,” PPM answers another question: “which projects should we do at all, in what order, and with which resources and funds.”

A PPM system gives a unified view: how many initiatives you have, which move business goals, where people are lacking, and what happens to money when all projects are combined.

There are several basic entities inside PPM that are often confused:

• portfolio — the entire set of projects and programs owned by leadership;
• program — a group of related projects that deliver a combined outcome;
• project — a specific piece of work with deadlines, scope and expected impact;
• resources — people and their workloads (sometimes equipment and contractors too);
• budget — plan and actual spending, often broken down by categories.

Risks and dependencies almost always live alongside these: one project can “stop” because another didn’t deliver a system, didn’t free a team, or delayed procurement.

PPM roles are also broader than in a single project. The portfolio owner and PMO set rules and priorities. Project managers maintain plans and statuses. Finance looks at limits, payments and economic effect. IT handles access, integrations and data quality so reports are reliable.

The value of PPM is supporting management decisions, not just producing “pretty” reports. When a new important initiative appears, the system helps quickly understand what must be shifted or stopped based on data: key specialists’ workloads and budget impact.

A typical scenario: a company has 25–30 projects and the same lead architects and analysts are needed across them. In Excel each project individually looks doable, but together they don’t fit into the calendar. PPM highlights resource conflicts and helps honestly choose what to do now, what to postpone, and what to close to avoid spreading money and team thin.

Functions needed to connect projects, resources and budgets

If the goal is to leave Excel, a PPM system should not just store plans but link three things: schedules, people and money. Then any change is visible immediately: move an activity — you see who is overloaded and how the budget forecast changes.

Plans and schedules without manual "stitching"

The backbone of a portfolio is clear project plans. You need phases, dependencies and milestones to see the critical path and real causes of delays, instead of rewriting dates across multiple files.

Unified templates (for IT, construction, procurement), locking a baseline plan and showing deviations help. This is important when there are many projects and each manager plans differently.

Resources and budgets as a single picture

For resources, it’s not just a list of participants but workload over time and by role: analysts, developers, engineers, legal, procurement. You need clear shortage signals and replacement options: who can pick up a task if a key specialist goes on leave or resigns.

For finance the minimum is plan, actual and forecast. Often costs must be split by categories and periods, and sometimes CAPEX and OPEX tracked separately. A practical feature is linking budget to work: if a task stretches for a month, the cost forecast should recalculate automatically, not after manual updates.

To make the portfolio manageable, a few core capabilities usually suffice:

• end-to-end schedule with dependencies and milestones;
• resource matrix with workload and conflicts over time;
• budgeting by projects and periods (plan, actual, forecast);
• portfolio reports on status, deviations and risks;
• change control through requests and approvals.

Dashboards are not for beauty but to quickly answer executives’ questions: which projects are red and why, what blocks deadlines, where are people missing, how the budget forecast changes. Critically, reports must update automatically from system data, not once a week manually.

Excel’s separate pain is changes. That’s why PPM systems benefit from change requests (scope, schedule, budget), approval workflows and a decision history. Example: the business asks to add functionality mid-project. If the change goes through the system, you immediately see that another developer is needed for two weeks and the budget grows by 3 million, and portfolio priority helps decide which project to shift.

Planview, Project Server/Project Online and similar: how they differ

PPM tools solve similar problems but emphasize different things. One focuses on portfolio and finances, another on detailed scheduling and an integrated ecosystem.

Planview is often chosen where the portfolio is large and leadership needs a view of priorities, benefits and finances. Strengths include demand management (initiatives before start), resource "what-if" scenarios, financial planning and stakeholder dashboards. It’s convenient when you need quick answers about which projects to stop, where to add people, or where there is overspend.

Microsoft Project Server and Project Online are stronger where schedule discipline and integration with Microsoft 365 matter. If teams work in Teams, Outlook, SharePoint, and schedulers are used to Microsoft Project, the entry barrier is lower. This approach often wins in detailed calendar planning, critical path, task-level workload management and integrations within the same stack.

Don’t confuse tool classes. PPM is about portfolio (prioritization, budgets, benefits, risks, consolidated reporting). EPM often focuses on project management standards and execution control. Task trackers cover team work but rarely provide a reliable organization-wide view of budgets and resources.

Other common options include Jira Align (when many development teams need a portfolio layer on top of Agile), ServiceNow (when projects are tightly linked to IT services and processes), Smartsheet or Monday (fast start and simple reports with moderate financial needs), and local solutions (when localization and regulatory or procurement requirements are critical).

Also check licensing and cost growth. A common trap: a pilot is cheap, but after onboarding leaders, finance, resource managers and integrations the price jumps. Look at payment model (per user or per role), cost of financial and portfolio modules, and admin and development costs a year out.

Simple guideline: if the main question is "which initiatives to fund and with what", portfolio platforms like Planview often win. If the main question is "how to precisely plan and control execution inside Microsoft ecosystem", Project Online or Project Server is often more convenient.

Criteria for choosing a tool for your organization

Choice rarely comes down to "which brand is best." More important is which one meets your security requirements, data needs and established processes, and truly replaces Excel instead of adding another layer of manual work.

Cloud or on-prem

Start with constraints. If you’re in the public sector, have sensitive data or strict regulations, the solution may need to be on-prem. If requirements are less strict, cloud is usually simpler to launch and maintain.

Answer a few questions in writing first:

• which project data is confidential and where is it allowed to be stored;
• do you need an audit trail and history of changes;
• is work required in an isolated environment or offline access;
• who approves access models and how often are they reviewed;
• which security standards and certifications must the vendor have.

After this, some options will drop out on their own.

Integrations, reporting, resources and finance

Next, look at seams between systems. If budget and actual live in ERP or accounting, and people and rates in HR, without integrations you’ll be back to manual transfers.

Check whether the tool can work with what you already have: AD/SSO for login, Service Desk for requests, BI for data marts, exchange with financial and HR systems. It’s important not only that “a connector exists” but how it works: scheduled or real-time, who supports it, how errors are handled.

Assess reporting from two perspectives. Top management usually needs 5–7 clear indicators (schedule, money, risks, status). PMO needs details: workload, deviations, reasons, plan versions.

Test resource planning on a real case: 10 key specialists allocated by roles and rates for a quarter, then one goes on vacation and two projects change priority. If the plan recalculates without manual hacks, that’s a good sign.

For finance: ensure budgets, actuals and forecasts follow one logic, with clear approval rules and no copying numbers between systems.

Step-by-step selection plan: from requirements to pilot

The main risk isn’t choosing the wrong brand, but lacking internal agreements on how to manage data and decisions. Use short cycles: fewer promises, more real checks.

1) Frame requirements as questions, not "wish lists"

Gather 10–15 key questions from PMO, finance and IT. Good examples: who approves the budget and where versions are stored; how workload is calculated — by hours or rates; what reports leadership needs weekly; what counts as actual — timesheets, invoices, payments, write-offs. Answers quickly show which processes exist and which must be introduced.

2) Describe current data and its quality

Before demos, document where projects, rates and actual costs live: Excel, ERP/1C, accounting, Jira, email, files on disk. Note what “drifts”: different project names, no unified role dictionary, rates stored inconsistently, actuals delayed.

3) Narrow to 3–4 systems and prepare demo scenarios

Don’t ask to “show everything.” Create 3–5 recurring scenarios: project start, budget change, schedule shift, resource reallocation, portfolio report. Then Planview, Microsoft Project Online/Project Server and others are compared on the same actions, not on pretty slides.

4) Run a pilot in 1–2 departments and measure impact

A pilot should be small but real: 10–20 projects, real people and approvals. Agree in advance how you’ll measure success: time spent collecting status reduced, fewer manual corrections, single numbers for workload and cost forecast. In production or integrator companies it’s often convenient to start with IT and finance, where resources and budget limits are critical.

5) Agree on data ownership and responsibilities

Before scaling, decide who administers the system, who maintains directories (units, roles, rates), who ensures plan and actual quality, and how rules change. Without this, even a good tool becomes "another Excel," only inside an interface.

If you follow these steps, by the end of the pilot you’ll have not only a chosen platform but a working scheme: which data to enter, who verifies it, and what portfolio decisions can actually be made.

Common mistakes during PPM implementation

The first mistake is trying to launch PPM as an "ideal showcase of everything." Teams dive into complex configuration, approvals and pretty reports while basics (unified statuses, responsibilities, fact updates) remain vague. Early benefit is small and people go back to Excel.

Second, migrating Excel as-is. Spreadsheets often rely on personal conventions: how workload is calculated, where rates are stored, what "80% complete" means. If you transfer this without review, you’ll get the same confusion in a PPM UI. It’s easier to agree on minimal rules first: mandatory fields, allowed statuses, what is a plan and what is actual.

Third, no owner for directories and data. If no one owns people, roles, rates, calendar, project structure and statuses, data quickly diverges. The system doesn’t "lie" because it’s bad — it does because the source of truth isn’t assigned.

A common failure cause is missing rules for updating actuals and forecasts. For example, project managers update schedules monthly while finance expects weekly numbers. Or time entries appear after the fact, when it’s too late to manage resource overload.

Another underestimated topic is training and support. Users need the meaning, not just button training: why fill data and how it affects decisions. Otherwise the system feels like "control for control’s sake."

Minimum practices to avoid failure:

• start with a few scenarios: portfolio status, key role workload, basic budget and forecast;
• assign data owners and an update schedule (e.g., actuals weekly, forecast biweekly);
• fix a glossary: statuses, work types, rules for percent complete;
• run short role-based training and create a support channel;
• pilot on a limited portfolio (e.g., 10 projects) before scaling.

Example: in a company with 30 IT and infrastructure projects, project managers keep schedules but don’t update resource forecasts. After a month, the report shows "all green," while key engineers are overloaded and deadlines slip. If you assign an owner for the role directory and require weekly actual time updates, overloads become visible earlier.

Short checklist: are you ready to move from Excel?

Moving to PPM usually comes not from tool hype but from this simple fact: people spend time reconciling files but still lack transparency. If you recognize yourself in the points below, it’s time to plan replacing Excel with a unified portfolio management environment.

This isn’t about perfect maturity but the minimum without which any tool quickly becomes "a file nobody updates."

• There is a single project directory: consistent names, owner, status, phases and clear rules for what "in progress," "on hold," and "closed" mean.
• Resource owners (people and teams) are assigned and there are simple rules for planning workload: who confirms assignments, how vacations are accounted for, what to do with "urgent top-down tasks."
• It’s clear where actual costs come from and how often they’re updated: accounting, ERP, purchase requests, timesheets, or at least an agreed template. Frequency matters more than exact accuracy in the first month.
• 3–5 mandatory reports for leadership are defined: portfolio progress, schedule deviations, key specialists’ load, budget plan vs actual, list of risks and blockers.
• There is a regular update regimen: who and when updates plan, risks and comments, and what happens if someone doesn’t. Better short and regular than "once a quarter and perfect."

If at least three of the five items are met, you can start a pilot. If fewer, first agree on basic rules: status glossary, resource owners, source of actuals and the minimum report set.

Practical example: in a portfolio of 20–30 projects the same architect appears in every plan but is actually overloaded and deadlines slip. Once a unified workload view and a rule for confirming resources are in place, half the conflicts become visible in advance. Effect appears before full rollout.

Example scenario: a company portfolio of 30 projects

Imagine a company running 30 projects at once: infrastructure upgrades, software implementations, workstation and server updates in branches. Six teams work across them (infrastructure, development, security, support, analytics, rollout). The annual budget is shared, but people limits are strict: few key specialists are needed across initiatives.

At the start of the quarter a portfolio committee reviews requests. Each request in the PPM system has clear fields: goal, expected benefit, risk, schedule, cost, role-based staffing needs (e.g., architect, DBA, security engineer), dependencies and mandatory requirements (regulatory, contractual, critical equipment replacement). Projects are then ranked on a single priority scale and checked for funding. If there’s money but no people, a project doesn’t start: it’s queued, split into phases, or moved to preparation.

Workload planning is done by role and availability, not by feeling. For the quarter you see the architect at 120% in April because three projects grabbed them simultaneously. Then one project moves to May, another stays in preparation (no active architect tasks), and the third remains critical.

Once a week project managers update actuals: completed work, hours spent, paid invoices. The system recalculates the forecast to quarter end: where overspend will occur, where money remains, where deadlines slip. Fewer arguments about numbers happen because everyone looks at one source, not multiple Excel versions.

A few dashboards usually suffice for quick decisions:

• portfolio map: priority vs cost and status (in progress, on hold, at risk);
• key role workload by week: where overloads are and who is missing;
• budget: plan, actual and forecast by projects and programs;
• risks and dependencies: what blocks starts and what can break schedules.

Using these screens, the portfolio team decides faster what to continue, pause or close, without manual consolidation and version alignment.

Next steps: how to start implementation and avoid failure

Start with a short pilot, not with brand selection. A good PPM shows value in 3–6 weeks: a single portfolio view, clear statuses, key people workload and a budget forecast on at least a plan vs actual level.

Compile a short vendor list (usually 2–4) and ask for a pilot using your data. Demos with "pretty examples" often mislead: it’s more important to see how the tool handles your typical projects, approvals and reports.

Before the pilot prepare a minimal dataset. This saves weeks and immediately reveals accounting gaps:

• list of projects with owners, dates, stages and goals;
• list of resources (people and teams) and their availability;
• rates and cost accounting rules (internal, contractors);
• project budgets and cost categories;
• status template: 5–7 fields updated weekly.

Next, plan infrastructure and access. Even cloud tools require discipline: who sees finances, who changes plans, who approves portfolio. For server options (e.g., Project Server) decide where servers will be hosted, backup procedures, and what workstations project managers and finance need.

To avoid stalling, plan in phases and set readiness criteria per phase. A common order works well:

• portfolio: unified project list, priorities, statuses, basic reports;
• resources: availability calendar, workload, conflicts;
• finance: budgets, plan-actual, forecast to project end;
• integrations: accounting systems, HR, service desk, BI.

If you need an integrator, check in advance whether they cover not only PPM configuration but also infrastructure, workstations, access rights and support. When rollout depends on servers, workstations and maintenance, it’s convenient to bundle these tasks. For example, GSE.kz (gse.kz) as a system integrator in Kazakhstan can assist with selecting and supplying servers and workstations, deploying infrastructure and organizing 24/7 support through a service network.