A Practical Resource vs Capacity Planning and Management Model for Portfolio Project Delivery
I was recently asked how I would manage a situation where a delivery portfolio is already planned and prioritised, but new work and new priorities keep appearing. It’s a familiar problem in project delivery, and even more so when you’re in a client-vendor relationship. It clearly becomes much harder when you’re responsible for a large portfolio rather than a handful of projects. I started thinking about what I would actually want in front of me if I had 20 major programmes, five projects, 100 engineers with varying skillsets, 20 QA testers, and the executives asked on a grey Tuesday morning, whether we could take on another major client launch. I would want to be able to give a reasonable answer without having 10 meetings first or downright refusing due to being overcapacity.
The obvious starting point would be the existing plan, but a list of projects and delivery dates wouldn’t give me enough information to answer the question. Projects tend to expand and fill the capacity we have regardless of the actual resources they require, so you almost always get the answer “we’re at full capacity”. But not everyone is working every minute of the day. There is a lot of waiting and chasing for dependencies. I’d need to know what resources those existing programmes are expected to consume over the coming months, which capabilities they need and how much capacity remains in each area. I’d also want to be able to get to that information quickly, without opening 25 project plans or asking every delivery manager to go and calculate their team’s availability. This information needs to be available in real time.
Looking at capacity by capability rather than headcount
Having 100 engineers sounds like a lot of capacity until you start looking at what those engineers actually do. They might be distributed across platform engineering, payments integration, regulatory technical compliance, frontend, backend, third party integrations, data engineering, reporting, and other specialist areas. The people in those groups aren’t necessarily interchangeable and sometimes multi-skilled. A new client launch might need 5 engineers with a particular engineering skill at exactly the same time as several existing programmes need them.
The overall engineering headcount could therefore look perfectly healthy while one capability is already fully allocated. The same problem can appear later in the delivery lifecycle with QA. There might be enough engineering capacity to start several programmes, but if they all reach testing at roughly the same time, the constraint simply moves further down the delivery process.
For that reason, I’d want the portfolio resource view to combine three dimensions: 1) programme 2) capability 3) per month. The first step is to determine which capability or skillset each program will require each month (or sprint if you prefer). It could look like this:
Capability Demands Per Project Per Month (Person)
| Programme | Engineering Capability Required | September | October | November | December |
|---|---|---|---|---|---|
| Programme: A | Platform | 3 | 3 | 2 | 1 |
| Programme: A | Payments | 2 | 2 | 1 | 0 |
| Programme: A | QA | 1 | 2 | 3 | 2 |
| Programme: B | Platform | 2 | 3 | 3 | 2 |
| Programme: B | QA | 1 | 2 | 2 | 3 |
| Project: Platform Upgrade | Platform Core | 2 | 2 | 2 | 2 |
This gives me the demand side of the picture. I can see which capabilities or skillsets each programme expects to use and when it expects to use them. Second step is to roll them up to see the total demand vs total capacity per capability or skillset. This would show me the capacity or headway available per month. For a single month, it would look like this:
Capability vs Capacity Matrix (4-month Total Sep to Dec)
| Engineering Capability | Total Capacity (person) | Existing Portfolio Demand (person) | Spare Capacity Available (person) |
|---|---|---|---|
| Platform | 22 | 20 | 2 |
| Payments Integration | 14 | 12 | 2 |
| Frontend | 18 | 15 | 3 |
| Platform / Core | 20 | 17 | 3 |
| Third Party Integrations | 14 | 11 | 3 |
| Data Engineering, Reporting | 12 | 10 | 2 |
| QA | 20 | 17 | 3 |
This is good but I’d want to see those numbers by month over 4 months rather than as a single total figure for 4 months. Programs rarely finish in a month and even if they do, they won’t require complex capacity resource management. If I have a new program that requires one backend engineer for 3 months and then 2 frontend engineers for the following 2 months, then I know what to look for in order to accommodate the new project. It would be a lot better than saying we simply don’t have capacity, to say we have some spare backend capacity next month but we’ll struggle when we get to the frontend development in 2 months. That’s a much more intelligent conversation to have and your demands from the executives become more clear: We can deliver the backend work but we need additional frontend resources in 2 months.
Adding a new programme without immediately changing the plan
Suppose a new client launch now appears with an important commercial deadline. I wouldn’t immediately add it to the committed portfolio and start moving everybody around. I’d add its resource requirements as a separate scenario so that I could see the effect on the existing plan first.
If we have 22 Platform engineers in December and the existing programmes require 20 of them, there are two people available. If the new launch requires another five, we now have a shortage of three people in that particular capability and month. Payments might still have enough capacity, front end might be fine and QA might not become constrained until February when the programme reaches testing.
That gives me a much more useful picture of the problem. I know which part of the new programme fits into the existing portfolio and which part doesn’t, and I know when the difficulty occurs. I can then look at the detailed December allocations for Platform and see which existing programmes are consuming those 20 people.
Perhaps a lower-priority platform upgrade is using three engineers during December. Another programme might have work scheduled in December that could reasonably move into January. There may also be programmes that can’t move because they have contractual, regulatory or equally important commercial deadlines. I’m not assuming that moving existing work will always solve the problem, but at least the discussion is now based on something more useful than a general statement that engineering is too busy. The executives will come to you to ask “what do you need to deliver this new project, without stopping anything else” and you need to be able to answer that question pretty quickly.
What actually changes when the priority changes?
This is the interesting part when it comes to portfolio planning. Organisations quite reasonably change their priorities as circumstances change, particularly where client commitments, regulation and commercial opportunities are involved. The difficulty comes when a new piece of work is declared a priority but all the existing work remains exactly where it was. If the portfolio is already close to capacity, something eventually has to change. That might mean moving lower-priority work, changing the sequence of the new programme, reducing its initial scope, bringing in additional specialist capacity or agreeing a different delivery date. In some cases there may be enough headroom to absorb the new work without affecting anything else, which is exactly what the capacity model should also be able to show.
The delivery team can use the information to work through those possibilities before taking the decision back to leadership. If the new launch needs three more Platform / Wallet engineers in December, for example, I’d want to identify two or three credible ways of creating that capacity and show what each one does to the rest of the portfolio. Leadership can then make the commercial prioritisation decision with a clear understanding of the consequences.
This also avoids putting the delivery function in the position of somehow being expected to make every new request fit. Good resource management can improve sequencing and make much better use of the people available, but it can’t manufacture specialist capacity that doesn’t exist. Where there is a genuine constraint, the useful contribution is to identify it early and explain the realistic choices available.
Keep the underlying spreadsheet simple
Although the output is a three-dimensional portfolio matrix, I wouldn’t maintain the source data as a huge grid. That would quickly become difficult to update as programmes start and finish, dates change and new capabilities are added. I’d keep the underlying demand data in a simple format where each row represents one programme, one capability and one month:
| Programme | Capability | Month | FTE required |
|---|---|---|---|
| Programme A | Payments | Nov-26 | 2 |
| Programme A | Payments | Dec-26 | 2 |
| Programme A | QA | Dec-26 | 3 |
| Programme B | Platform | Dec-26 | 4 |
The available capacity can sit in another table:
| Capability | Month | Available FTE |
|---|---|---|
| Payments | Nov-26 | 14 |
| Payments | Dec-26 | 14 |
| QA | Dec-26 | 20 |
| Platform / Wallet | Dec-26 | 22 |
The portfolio matrix is then simply a view of that information. This makes the model much easier to extend because another programme, month or capability can be added to the source data without redesigning the spreadsheet.
I also wouldn’t start by trying to maintain individual allocations for all 120 people at portfolio level. If the model tells me that QA will be four people short in February, I can then go into the detailed resource allocation with the relevant managers and work out which individual testers are committed where. For the initial portfolio decision, the capability-level constraint is what I need to understand.
Download the sample resource capacity planning matrix template
I’ve created a sample Excel workbook to show how this could work. The example has 20 programmes and five smaller projects running across a portfolio with 100 engineers divided between six engineering capability groups, plus a separate team of 20 QA testers. The portfolio already has a significant amount of committed work, so there’s some spare capacity but not enough to absorb anything that comes along without thinking about it.
The workbook then introduces an urgent new client launch. The first view shows the existing demand and spare capacity by capability and month, while the second adds the resource requirements for the new launch and shows the resulting capacity position. Areas with plenty of headroom remain green, tighter areas turn amber and months where demand exceeds the available capability turn red. The detailed section underneath lets you see which existing programmes are consuming the constrained resource.
The example numbers are deliberately illustrative rather than an attempt to represent a real organisation. You can replace the programmes, capabilities, monthly demand and available resources with your own information and use the same structure.
Using the model for portfolio decisions
This is a good model to quickly answer the questions that come up whenever priorities change. If somebody asks whether we can start another client launch in November, I should be able to see which parts of the organisation have room, which capabilities are likely to become constrained and which existing programmes are creating those constraints.
From there, I can work with the relevant delivery and engineering leads on alternatives and come back with something concrete. We might be able to accommodate the launch by moving a lower-priority piece of work by a month. We might have enough capacity to begin discovery and integration work immediately but need to delay another part of the programme until specialist engineers become available. We might need temporary capacity, or the numbers might show that the requested date simply isn’t realistic without affecting another important commitment.
Hope you find it useful. Let me know what you think in the comments.