The spreadsheet that everyone believed until Tuesday
It is Monday morning. Your capacity spreadsheet is a thing of beauty. Every person shows 100 percent allocated, no more, no less. Green cells all the way down. You send it to the leadership team and feel, for one glorious hour, like a person who has their act together.
Then Tuesday happens.
Two of your senior developers are quietly firefighting a production issue that is not on any plan. A key analyst is out sick. And someone in sales just promised a customer a feature that needs the exact person your spreadsheet already had booked at 100 percent.
If you have lived that, you already know the uncomfortable truth. A capacity plan that looks perfect is often the least trustworthy kind. Perfect usually means it is hiding something.
Let me define three words before we go further, because people mash them together and then wonder why nothing lines up.
- Demand is all the work asking for people: projects, support, maintenance, that vague thing the CFO mentioned.
- Capacity is the hours your people can actually give to that work, after real life.
- Resource management is the matching of the two, over time, for specific skills.
Most plans fail at the seams between these three. So let us look at where.
Headcount is not capacity, and skills are not interchangeable
The first lie most plans tell is that a person is a unit.
You have twelve engineers, so you have twelve units of engineering. Tidy. Wrong. If a project needs someone who understands your billing system, and only two people on earth do, then for that work you do not have twelve engineers. You have two. And both of them are usually busy.
This is the trap of planning by headcount instead of by skill. On the summary chart it looks like you have plenty of slack. In reality the whole portfolio is waiting on one database specialist named Priya, who is also the only person who can approve the migration, who is also on vacation in July.
Capacity is specific. It usually lives in named people with named skills, not in an average.
The fix is not glamorous. You have to model your scarce skills separately from your general pool. You do not need to track every role at that resolution. You need to track the two or three skills that everything seems to bottleneck on. Those are the ones worth naming.
The maintenance work you forgot to subtract
Here is the second lie. Plans tend to assume people spend their whole week on project work.
They do not. Nobody does.
Think about a realistic week for a mid-level developer. There is the standup. There is the support ticket that becomes a two hour investigation. There is the code review for another team. There is the recruiting interview. There is the security training with the deadline that will not move. By the time you add it up, the project-available portion of a forty hour week is often closer to twenty-five.
When you plan at 100 percent of nominal hours, you are planning against a person who does not exist.
A more honest approach is to plan against realistic availability. Take your run-the-business load (support, maintenance, meetings, the general tax of being employed) and subtract it first. Plan projects against what remains. Many PMOs land somewhere between 60 and 75 percent of nominal time as genuinely project-available, though your number will differ and you should measure it rather than guess.
And leave a buffer. A plan booked to the last hour has no room to absorb the Tuesday surprise, and Tuesday always comes.
A worked example: the two roadmaps and one Priya
Let me make this concrete.
Say you have two priority projects for Q3. Project Atlas is a customer-facing billing upgrade the sales team has already half-promised. Project Beacon is an internal reporting overhaul the CFO wants. Both are approved. Both are important. Both, it turns out, need Priya the billing specialist for a critical stretch.
The naive plan puts them side by side, both starting in July, both green, because on the headcount chart you have enough engineers for both.
Then you look at skills instead of headcount. Priya can realistically give about twenty project hours a week after her support duties. Atlas needs her for roughly fifteen of those hours across six weeks. Beacon needs her for a similar block, overlapping almost exactly. You cannot have both. One of them slips, whether you plan for it or not.
So you make the tradeoff on purpose rather than by accident.
You sequence them. Atlas goes first because a half-made external promise carries more risk than an internal want. By risk here I mean the chance and cost of a broken commitment, not general uncertainty. Beacon starts three weeks later, when Priya's Atlas work tapers.
Is this slower? Yes. Beacon's sponsor will not love it. But a staggered plan that finishes both is usually better than a parallel plan that stalls both and burns Priya out in the process. The honest conversation about which project waits is far easier to have in June than in August.
That is the whole game: surface the contention early, name it, and choose.
Where a tool earns its keep (and where it does not)
Once you are planning by skill, subtracting real load, and sequencing around bottlenecks, the arithmetic gets heavy. Dependencies interact. Move one project and three others shift. A spreadsheet can do this. It just starts to fight you around the third scenario.
This is the point where a portfolio tool helps: it holds demand, capacity, and dependencies in one place so you can see the collisions before they happen.
Perspective does this with a roadmap optimizer that sequences work around dependencies, resource contention, and a safety buffer. That said, the discipline matters far more than the software. A shared spreadsheet with an honest availability number and a named list of scarce skills will beat a fancy tool full of fantasy allocations every time.
The method is the point. The tool just saves you from doing it by hand.
How to start this week
You do not need a transformation program. Try this:
- List your top three bottleneck skills, the ones everything seems to wait on. Name the actual people, not the role count.
- For each of those people, estimate their genuinely project-available hours per week after support, meetings, and maintenance. Ask them; they know better than your spreadsheet.
- Take your two most important active projects and check whether they compete for the same scarce person at the same time. Just those two, for now.
- If they collide, decide the sequence on purpose, using a clear rule (for example, external commitments before internal wants), and write down why.
- Add a buffer. Do not book anyone's scarce time past about 80 percent. Leave room for Tuesday.
None of this makes the hard tradeoffs disappear. It just moves them into daylight, where you can argue about them with facts instead of vibes.
A plan that admits its limits is worth more than a plan that pretends it has none.