Custom project portfolio management software development
Most organisations do not lack good project proposals; they lack people to carry them out. Yet everything looks green: each proposal is approved individually, each project plan is sound on its own, and halfway through it becomes clear that the same architect, the same data resource and the same department are booked into four plans. Portfolio management is the level at which such clashes are resolved: which projects we do, in what order, where the capacity lies, and whether they deliver what the business case promised. Appfront builds bespoke software for that decision process, from intake and scoring to phase gates, benefits realisation and reporting to the board and oversight bodies.
Portfolio management begins where project management ends
Decisions about work are made at three levels, each asking a different question. On the shop floor, the concern is flow: which work we start now, what is blocking, how long it takes for something to move from left to right. Within a project, the concern is control over a defined assignment: planning, budget, risks, milestones and delivery. At portfolio level, the concern is composition: which projects may exist, which gets priority, what gets postponed, what we stop, and whether we keep the promise we made to the organisation.
That last level is missing from most toolkits. There is project tooling, there is a spreadsheet listing projects, and there is a board meeting in which that list is discussed. What is missing is a place where the request, the weighted assessment, the capacity required per role, the phase decision and the benefits after delivery all hang off the same record. The consequence is predictable: the project list lives in four versions, the board sees figures that are already outdated by the time they are read aloud, and a decision to stop is hardly possible because nobody can see what will be freed up as a result.
Portfolio management also only becomes interesting when resources are scarce. As long as everything can be done, no choice is needed and a list will suffice. Once there are more proposals than delivery capacity, the question becomes one of allocation: every yes is a no to something else, even if that no is never stated explicitly. Software that makes this visible is not administration, but a decision-making instrument.
In practice there are four kinds of users of a system like this, and each of them wants something different. The requester wants to know where their proposal stands and what is still expected of them. The portfolio manager or PMO maintains the list, collects assumptions and prepares the decision round. The team lead or resource manager is asked to commit capacity they also need for day-to-day work. And the executive team makes the decision, and needs the shortest picture that is still useful for that. A portfolio system that serves only one of those four well will be bypassed by the other three, and after one round the list is incomplete again.
Are you in the right place? This page is about the level above the individual project. If you want to manage a single project, with planning, budget, milestones and time recording within that one assignment, you need custom project management software. If it concerns the shop floor, boards, columns, blockers and how long work has been in progress, that is the level below the project and not what is described here. This is about which projects there are, not about how to run any one of them.
The number is the problem
Every proposal is defensible on its own. The damage lies in the sum: too much concurrent work slows everything down and nothing gets finished.
Capacity is a shared pool
Projects share the same specialists with each other and with day-to-day work. That pool is allocated at portfolio level, or it is not allocated at all.
Benefits arrive after go-live
The project stops at go-live, and the promise in the business case only starts then. Someone has to keep measuring whether it comes true.
Choosing between projects that all seem urgent
Ask an executive team which of the ongoing projects has the highest priority and the answer is often that all four are important. That is not unwillingness; it is the absence of a shared yardstick. Without one, whatever arrives loudest wins: the client threatening to cancel, the regulator with a deadline, the manager who presents best. Urgency crowds out importance, and maintenance that nobody comes to defend quietly slips back until it returns as an incident.
A portfolio also consists of more than projects someone wants. Some work is required because a regulation or contract mandates it, some because a system is reaching end of life, and some because it moves the organisation forward. These three categories compete for the same people, but cannot be compared with the same arguments. A mandatory programme always loses a discussion about return and always wins a discussion about risk. Unless that difference is reflected in the assessment, you are comparing apples with obligations.
A scorecard that guides the conversation rather than settling it
What works in practice is a scorecard set in advance, outside the heat of an individual proposal. It contains the criteria your organisation genuinely applies: contribution to strategic objectives, expected benefits and how firm they are, risk if it does not happen, dependency on other projects, mandatory basis, and feasibility given the people who have to deliver it. Each criterion receives a weighting, and that weighting is a strategic decision the executive team makes once, rather than again for every proposal.
The software does not calculate the decision. What it does is make the assessment reproducible: who gave which score, which assumption it rests on, and what happens to the ranking when an assumption changes. The last part is the most valuable. Halve the estimated benefit of the highest-scoring proposal and see whether it still sits at the top; double the estimated effort and see what falls out of the plan. Such a sensitivity view moves the discussion from opinions to assumptions, and assumptions can be debated.
Equally important is that the scorecard makes visible where assessors disagree. Two people who give the same total on the basis of opposing scores appear to agree when they do not. A portfolio round that shows only totals misses precisely the point where discussion is needed. That is why the system keeps scores per criterion and per assessor, together with the rationale, even after the decision has been made. In a later round, you can then trace why a proposal did or did not go ahead.
Dependencies determine the sequence
A ranking by score alone is not yet an executable sequence. Projects depend on one another. One delivers an integration that another is waiting for, two tracks touch the same core system and cannot go live at the same time, and a third can only start once a register has been cleaned up. Whoever does not record these links plans a portfolio that fits on paper but stalls in execution, after which the delay is laid at the feet of the project leads.
For that reason, every proposal should be accompanied by two questions that together go far enough: which project must be finished before this can start, and which project will run into trouble if this one is postponed or stopped? The answers sometimes shift the ranking considerably, because a mid-scoring proposal that is blocking three others belongs at the front, whereas a high-scoring proposal that is waiting on something else does not. Here too, the system calculates nothing. It makes the chain visible, including the point where postponement ripples through to projects that nobody linked to that decision.
Saying no without alienating the applicant
A portfolio that can only give a green light is not a portfolio. Yet saying no is organisationally costly, which is why it often happens covertly: the proposal is approved but never staffed. That is the worst outcome, because the applicant continues to count on something that will not happen, and the project occupies a place in reporting without making progress. A better approach is an explicit status: rejected with a stated reason, on hold until a named condition is met, or under consideration with an expected start round.
Putting something on hold requires its own administration. A proposal waiting for the replacement of a core system should automatically return to the agenda once that replacement is complete, together with its original rationale and the question of whether that rationale still holds. Without such a mechanism, good work disappears into an archive and resurfaces as a new proposal, reassessed by people who did not attend the first round. Finally, reprioritisation should follow a fixed rhythm. A portfolio that is revised only during budgeting is a snapshot for the rest of the year, one that nobody dares to touch any more.
What portfolio management software must be able to do
These six components are not standalone modules but a chain. A scorecard without a capacity view produces a ranking that cannot be executed. Capacity without phase gates gives insight without the ability to intervene. Phase gates without a benefits register lead to decisions whose outcomes are never fed back. Without the reporting layer, everything stays locked in the system and the board is left relying on a spreadsheet.
What you choose not to build is equally decisive. A portfolio layer need not be a task list, a document management system or a second timesheet register. It should read project data from the systems where the work already takes place, and store only what arises at portfolio level: the request, the assessment, the decision, the committed resourcing and the benefits. That separation keeps the data-entry burden low, and data-entry burden is the principal reason portfolio systems fall into disuse after the first round. Every item that a project manager has to enter twice is an item that, in time, will be wrong in at least one of the two systems.
Single-entry intake
Every idea comes in the same way, with a brief justification, a requester and a category, so the list is complete before any choice is made.
Weighted scorecard
Criteria with an agreed weighting, scores per assessor with justification, and a ranking that can be recalculated if an assumption changes.
Capacity demand by role
The requested effort across all projects and day-to-day work, added up per role and per person, with any overbooking visible before the plan is fixed.
Phase gates with a decision file
The same questions and the same documents at every gate, with a recorded decision: proceed, adjust, hold or stop, and who approved it.
Business case and benefits register
Every benefit has an owner in the line, a measurement definition and a baseline, so the promise can still be checked after delivery.
Portfolio reporting and scenarios
One view for the board and oversight, with the ability to model a scenario before anything changes in the actual plan.
Capacity is the real constraint, not the budget
In many organisations money is the least scarce resource in the portfolio. Budget can be moved; people cannot. An approved amount does not produce an enterprise architect, an experienced product owner or a manager who will take over the system later. Yet the portfolio is steered by money in most cases, because money has a unit everyone understands, while the availability of people does not seem to have one. That is exactly where the delay arises, which is later attributed to the projects.
The pattern is familiar. Each project calculates neatly the effort it thinks it needs, and each plan is internally consistent. Add them together and you see that five plans each claim a fifth of the same specialist, that this same specialist also handles maintenance, and that nothing has been set aside for incidents. Such a portfolio is not tight; it is demonstrably unachievable, and that was already visible before the start. Adding up is technically trivial but organisationally difficult, because it makes clear that a choice has to be made.
There is also a loss that nobody plans for. Someone working on four projects at once loses effort to switching, catching up and re-reading after each interruption. At portfolio level, that is an argument for doing less concurrently and more in sequence: the same work, the same people, but finished sooner and with fewer half-completed projects on the books. Software helps by showing concurrency per person, not just total utilisation.
Almost every portfolio also includes a handful of people through whom everything passes: the architect who must see every design, the sole administrator of a core system, the lawyer who reviews every contract. They determine what the portfolio can genuinely handle, and yet they are precisely the ones missing from a capacity overview built around departments. Such an overview reports spare capacity in the team while the person holding the key has already been overloaded. It is worth tracking these roles separately and having the same conversation as about money: who gets them, for what, and what gets pushed back as a result. That conversation also yields the only structural solution, namely making what currently sits in one person's head transferable.
From available hours to real availability
A capacity picture based on gross availability promises effort that does not exist. Leave, absence, training, meetings and the day-to-day work that continues while a project runs all come off the contractual time. What remains is the net project time, and in practice that is well under half for people with a maintenance task. A portfolio built on gross hours therefore falls structurally behind without anything having gone wrong.
In practice, it works at two speeds. For proposals that have not yet started, plan at role level: so much capacity from an integration specialist, so much from a tester, without names. Once a project passes the gate, replace that with the people who will actually do the work. Both views need to coexist, because the first is needed to choose and the second to deliver. Then compare the planned capacity with the capacity actually booked. That gap tells you whether your estimates hold up, and it will improve the next portfolio round more than any good intention.
For the detailed side of planning, rostering and scheduling hands-on work, a portfolio system is the wrong tool. That belongs in custom planning and scheduling software, or in rosters within workforce planning software. The portfolio does not need to know who is working on Tuesday afternoon, only whether the whole fits.
- Requested capacity per role, totalled across all projects
- Line work and maintenance included, not just project hours
- Net availability rather than contracted hours
- Key people shown separately as a portfolio constraint
- Concurrency per person visible, not just totals
- Planned capacity alongside booked capacity as a correction
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Phase gates, benefits and the decision to stop
In most organisations, the business case is an entry ticket. It is written to secure approval, and after that no one looks at it again. That is a pity, because the assumptions behind the approval change during delivery: the scope shifts, a supplier drops out, the market moves, and the benefit turns out smaller or larger than expected. A business case that is recalculated at each phase gate using what you now know is a management tool. A business case that disappears into a folder after approval is just paper.
Phase gates give that recalculation a place. The idea is old and proven: divide a project into phases and, at the end of each phase, take an explicit decision, always asking the same questions and reviewing the same documents. Is the rationale still valid, does the estimate still hold, are the risks manageable, is the capacity there, and does it still deliver enough to justify the rest of the investment? Methodological frameworks approach this differently, from the phased decision models used in product development to the phase transitions in common project methods and the international guidelines for portfolio management. The format matters less than the discipline: the same questions, every time, even when the answer is bad news. In the public sector, external review is added to this. The Dutch Adviescollege ICT-toetsing (ICT Assessment Board) is an independent body established by law that advises the cabinet and parliament on the risks and chances of success of ICT projects within central government, and its advice is public.
A gate with only one outcome is not a gate. The decision should genuinely be able to go either way: proceed as planned, proceed with a revised scope, hold until a condition is met, or stop. The last is the hardest decision in any portfolio, and not because the figures are unclear. Money has already been spent, people are attached to the work, and someone has put their name to it. Software does not remove that discomfort, but it can help the question be asked cleanly: not what the project has cost so far, but what it will still cost compared with what it will still deliver, and which people are freed up for the projects now waiting. In this way, stopping becomes a portfolio decision with a positive side, rather than a loss report.
Between two gates, the forecast should keep moving. A project that gives an estimate at the start and leaves it unchanged until delivery is not reporting a forecast but a wish. More useful is an adjustment at each round, with the reason given and the previous figure shown alongside it. This builds a learning record that makes the portfolio smarter: which kinds of projects are structurally estimated too optimistically in your organisation, where bad news is reported late, and which risks recur across several projects. At portfolio level, risk also deserves a view of its own. Five projects that each take an acceptable risk on the same supplier, the same platform or the same department together form a concentration that none of the five project risk registers shows. Adding up similar risks in this way is typical portfolio work.
Benefits realisation starts after go-live
The promise in a business case is almost never about software. It is about less manual work, fewer errors, faster response, lower downtime and better-founded decisions. Those outcomes only materialise once the organisation works differently, which is to say after the moment the project proudly closes. That is why the project manager is the wrong owner of a benefit: they are no longer there when it is due to occur. Benefits land in the line, so each benefit should have an owner in the line.
Three things make a benefit verifiable. A measurement definition that leaves no room for interpretation, a baseline taken before anything changed, and an agreed moment at which it is measured again. Without a baseline, every later outcome is merely an assertion. Watch out for double counting as well: if three projects all claim the same saving in the same department, that saving appears three times in the portfolio report and once in reality. A benefits register that records where each benefit lands prevents this. Soft benefits may well be included, provided they are labelled as soft and are not quietly added into a total alongside hard amounts.
Finally, benefits realisation only works if the benefit lands somewhere where its absence is noticed. In practice this means a link to the budget of the department claiming the benefit: what appears in the business case as a saving should come back in the next budget round as lower costs or as capacity redeployed elsewhere. If that link is missing, the benefit is an argument used only at approval and binds nobody afterwards. Software cannot enforce that link, but it can keep the promise, the owner and the measurement together, and raise the question with the right person in good time.
What the board and oversight bodies really need
Executives do not ask for more detail; they ask for meaning. A portfolio report that mainly shows coloured indicators invites optimism: nobody marks their own project red, so everything stays amber until it is too late. More useful is a picture that shows the movement: what has changed since the previous round, which forecast has been adjusted, which assumption no longer holds, and which decision is now being asked of the board. This calls for a single set of figures that comes from the same system as the project administration, rather than a presentation compiled by hand, whose provenance can no longer be traced after two steps.
For a board of supervisory directors or a supervisory board, traceability matters too. They need to be able to see which decision was taken when, on the basis of which documents and with what justification, even after the people involved have left. A portfolio system that stores decisions and versions provides that audit trail as a by-product. If you want to tackle the reporting layer as a standalone topic, custom KPI dashboard development fits well alongside it. If the focus is specifically on large capital investments with contract management and forecasts per investment, then investment project management software is the closer starting point.
When an off-the-shelf package is the better choice
Portfolio management is not an empty corner of the software market. Mature products exist in three forms: a portfolio module on top of the project tooling you already use, a standalone portfolio suite, and portfolio functionality within a broader package for administration or IT management. For some readers of this page, such a package is the wiser route, and we would rather say so here than halfway through a tender process.
If your decision-making follows the usual pattern of request, weighted assessment, capacity check, stage gate and portfolio reporting, you can buy that off the shelf, including maintenance and new versions. Your effort shifts from building to configuring, and with portfolio software that is still a considerable effort. Be honest about the root cause, however. If the core issue is that the board does not make choices, that requesters present their benefits more favourably than they are, or that nobody prepares the portfolio round, then no system will solve that. Software makes discipline visible and enforceable, but it does not create it.
Custom development pays off in fewer situations than vendors suggest. The strongest reason is a weighting model that is genuinely yours. Think of a healthcare organisation that weighs projects against available treatment capacity, a grid operator bound by statutory deadlines and safety obligations, or an organisation where subsidy conditions and co-financing determine what may start when. Forcing such logic into a packaged form means losing precisely the distinctive part of the trade-off.
The second reason is a portfolio that has to weigh more than projects. If project work competes with operations, with production capacity, with a fleet or with staffing in a core process, then the assumption behind many packages, namely that everything can be modelled as a project, is precisely the problem. The third reason is integration: portfolio figures are only reliable when they come from the source, from the financial administration, time registration, HR data and project tooling. If you want the package to be the leading system in all those cases, you end up building integrations against the grain. If the decision hinges mainly on control and risk, then IT risk management software is an adjacent starting point.
A conversation with us usually does not begin with a list of functional requirements, but with your current project list on the table. In one round, that generally shows where the pain lies. If there is work on it that should have been stopped long ago, the decision process is the subject. If the benefits of most projects cannot be expressed in a number, the starting point is the business case. If the list is accurate but nobody dares to reprioritise it, the discussion is about reporting and authority, not functionality. Starting from the complaint rather than from a module list prevents you from commissioning a system that neatly records what isn't happening.
There is a flip side too: with a custom build, the ongoing development and keeping up with changing reporting requirements sit with your own organisation. Often the middle route is the best answer: a package for project administration and delivery, and custom work for the portfolio layer where choices are made, weighted and accounted for.
- Package when your decision-making follows the usual pattern
- Package when portfolio discipline still needs to grow
- Custom build with your own weighting or prioritisation logic
- Custom build when not all work is a project
- Custom build when the figures must come from your own source systems
- Middle route: package for delivery, custom work for the portfolio layer
Frequently asked questions about portfolio management software
Project management is about delivering a project that has already been approved: planning, budget, risks, quality and handover within that single assignment. Portfolio management is about deciding which projects should exist, in what order and at the expense of what, given scarce people and a strategy. The portfolio chooses and reprioritises; the project delivers. If you need control over one project, custom project management software is the better fit.
With a scorecard set in advance, with an explicit weighting for each criterion: contribution to strategic goals, expected benefits, risk, dependencies, mandatory obligations and whether the people needed are available. The software does not make that decision for you, but it shows where the scores diverge and which assumptions carry the outcome. The discussion then centres on those assumptions rather than on who lobbies hardest.
Because every project counts on people who are not exclusively its own. Five plans that each require a fifth of the same architect are each sound on their own, yet together they are unworkable as soon as someone falls ill or line work takes precedence. Portfolio software totals the requested input per person or role across all projects and the line work combined, and shows the overcommitment before the portfolio plan is adopted.
Not the project manager, who is gone once the project is handed over. Benefits land in the line organisation, so each benefit should have an owner in the line, with a measurement definition, a baseline and an agreed measurement point. Without those three, benefits realisation is merely an intention. Software helps by keeping the benefit open after handover and continuing to ask the owner, even when the project has been administratively closed.
Often yes, and for many organisations that is the wiser route. Mature PPM packages exist, ranging from portfolio modules on top of existing project tooling to standalone portfolio suites. If your decision-making follows the usual pattern of request, scorecard, phase gate and portfolio reporting, you buy that in and your effort shifts from building to configuring. Custom work pays off when you have your own prioritisation logic, or when the portfolio must weigh other work alongside projects.
The source code and documentation belong to the client and sit in a repository to which you have access yourself. On handover, a description of the architecture, the data models, the integrations and the deployment is included, so another party can take over without first having to reverse-engineer anything. We work with mainstream technology, because that determines how many parties can take on the maintenance.
Related services
Bespoke project management software
If you do not want to choose between projects but rather deliver one well, with planning, budget monitoring, milestones and time recording within that assignment, custom project management software is the right level.
Software for investment projects
If the focus is mainly on large capital investments, with budget monitoring per investment, contracts and forecasts through to handover, software for investment projects is a closer match.
Custom KPI dashboard
If the reporting layer is your real question, with a single view for the board and oversight drawn from the source systems, then a custom KPI dashboard is the direct entry point.
Set your portfolio alongside your capacity
Tell us how a project proposal gets approved with you, who divides the time of your scarce specialists, and what happens when a project no longer meets its business case. Those three answers usually show whether a package, custom development or a combination suits you best, and which part of the portfolio process you would like to pin down first.