Many PPM tools are chosen in a demo, on how they look. Many disappoint in the second year, on what the organisation was never ready to do.
A PPM tool should be chosen only after the portfolio process has been designed and the organisation’s project management capability assessed, because the tool can automate a working process but cannot create one. That order sounds obvious. In practice, it is reversed more often than it is followed.
The reason is not carelessness. The tool is the most visible part of portfolio management, and the easiest part to buy. The process, the capability and the change in people’s daily habits are slower, harder to show and impossible to purchase.
The demo sells the interface; the organisation is buying a process
Modern portfolio tools are easy to judge on their surface. They look clean and current. They have drag-and-drop boards, colourful roadmaps and dashboards that refresh in real time. Next to the clunky intranet forms many organisations still use, they feel like progress.
That first impression is genuine, and it is also the least useful information in the evaluation. A demo shows a portfolio that already works: projects registered on time, statuses updated weekly, benefits estimated, risks scored. The dashboard is beautiful because the data behind it is complete.
Your organisation’s data is not. Nobody in the demo asks who registers a new initiative, who decides whether it enters the portfolio, or what happens when a project manager has not updated the status for six weeks. Those questions decide whether the tool will ever look like the demo. They are questions about process, and the vendor cannot answer them for you.
Judging usefulness takes longer than judging looks. It means running your own scenarios through the tool, with your own roles and your own exceptions. Few selection processes budget the time for it, so the decision falls back on what was visible in an hour.
The ERP rule applies here too: process first, then fit-gap
Anyone who has lived through an ERP implementation knows the evergreen rule: design the processes first, then choose the system. It is taught everywhere and broken almost as often. Portfolio management repeats the pattern on a smaller scale, with the same result.
Before a single tool is shortlisted, four things need a designed answer. How does work enter the portfolio, and who decides at the intake gate? Which decisions sit with the sponsor, which with the portfolio governance body, and which with the PMO? How often is the portfolio reviewed, and in which forum? What minimum data does each project have to produce for those decisions to be made?
None of this needs software. It needs a few working sessions and a sponsor willing to settle the decision rights. If the intake gate is not defined, no tool will define it; it will simply offer a form with more fields than anyone fills in.
Only then does the fit-gap analysis make sense. Fit-gap means measuring the tool against the process you designed, scenario by scenario: submit an idea, approve it, re-prioritise two projects, escalate a slipping milestone, prepare the quarterly review. Where the tool fits, configure it. Where it does not, decide whether to change the process, build a workaround, or look at another tool. A long feature list says very little; three scenarios that fail tell you a lot.
The head of PMO is the least reliable judge of usability
User-friendliness matters as much as feature coverage. A tool nobody wants to open produces no data, and a portfolio without data is a spreadsheet with a licence fee. But whose experience of usability counts?
Usually, the person leading the selection is the head of the PMO. That person lives in the tool, understands portfolio logic and sees immediately what each feature could do. I have been that person, and I know the trap from the inside. What looks like an obvious must-have to a head of PMO can be completely indigestible for the organisation: too many fields, too many views, too much change at once.
The real users are occasional ones. A project manager who logs in once a week to update a status. A functional lead who submits two requests a year. A sponsor who opens the dashboard before a monthly review and has five minutes to understand it. If they cannot do their part without training or a reminder, the tool fails, however elegant it looks to its administrator.
So test usability with them, not with the selection team. Give a project manager a scenario and watch where they hesitate. Then configure for the lightest version that still serves the decisions, and add features only when users ask for them.
Open doors for early users close the blueprint
There is a tempting variant of “start light” that does the opposite. To win early users over, the team leaves many doors open: custom fields anyone can add, their own workflows, their own folder structures, free choice of views. The argument is flexibility. Let people experiment, and the best practice will emerge.
It rarely does. Each early user builds a slightly different version of the portfolio, and the designed blueprint drifts before it has been tested. Worse, people form habits in the first weeks, and habits outlast configuration. Months later, pulling a few dozen improvised workflows back into one standard costs more than designing them properly would have.
Less is more. Give early users one way to do each thing, tell them why, and open a door only when someone has a real case for it.
Low capability means no PPM tool yet
There is a harder question underneath the selection: is the organisation ready for a portfolio tool at all?
Portfolio management stands on project management. If projects have no consistent plans, statuses mean whatever their authors want them to mean, and many project managers are accidental project managers doing the job alongside their real one, then a PPM tool will not fix it. It will digitise the inconsistency and present it in a better-looking chart.
In that situation the honest recommendation is to start from the basics. A simple project register, a shared status definition, a weekly review rhythm and a few people trained to run them. A spreadsheet or a list in the collaboration suite the organisation already owns is often enough for the first year.
The signal that the organisation has outgrown it is practical, not aspirational. The register is kept current without chasing. The review forum makes decisions on the data. Dependencies across projects start to matter, and maintaining them by hand starts to cost real time. When the process begins to choke without a tool, the tool will finally have something to automate.
This is not an argument against PPM software. It is an argument for buying it at the right maturity, so that the money pays for scale rather than for an expensive way to discover that the basics are missing.
Every licence is a change for one person at a time
Even with the process designed, capability in place and the right tool configured, the implementation is still a change. It is not an organisational change in the abstract. It is a change in how each project manager, functional lead and sponsor does a small part of their week.
The ADKAR model from Prosci is a useful lens here, because it breaks adoption down to the individual. Awareness: does each user understand why the portfolio needs this data? Desire: do they see anything in it for themselves, or only more reporting upwards? Knowledge: do they know how to do their part in the tool? Ability: can they do it in the flow of a normal week, without help? Reinforcement: does anyone notice when they do, and does anything happen when they do not?
Most tool implementations invest in Knowledge, through training sessions and user guides, and neglect the rest. Reinforcement matters most. If the portfolio review still runs on a separate slide deck, users learn quickly that the tool is optional.
That is why licences are a poor measure of success. Count instead how many projects are kept current without reminders, and whether the governance forum takes its decisions on the tool’s data. Adoption is a separate axis from delivery, as the project health check argues for any project, and a tool rollout can be delivered on time and still not be adopted.
The tool is the last decision in a PPM implementation, not the first.