Author: Parallax

Resource planning tools handle fixed-price projects poorly because they treat hours as a proxy for value, while fixed-price billing follows milestones. Revenue moves when a deliverable is approved rather than when hours are logged, so revenue forecasts and margin visibility both degrade on fixed-fee work.

Resource planning tools are mostly designed around time-and-materials billing, and fixed-price, milestone-based projects don’t fit that model cleanly. Revenue doesn’t track hours, and capacity doesn’t predict cash. The mismatch is structural, and it shapes how agencies plan, price, and forecast across their entire portfolio.

Agencies running a mixed book, some T&M, some fixed-fee, feel this constantly. It appears as a persistent low-grade friction rather than a single failure point. Plans look reasonable until someone asks what Q3 revenue actually looks like, and then the answer requires three spreadsheets and a conversation with the PM who built the project plan.

What T&M tools assume (and why it matters)

Build a resource planning tool from scratch and you’ll probably start with hours. Hours times rate equals revenue. More hours burned equals more cost. Utilization is hours worked divided by hours available. Forecast revenue by projecting hours forward. It’s clean, it’s consistent, and it works well when billing and effort move in lockstep.

Fixed-price projects break every one of those assumptions.

On a fixed-fee engagement, billing is tied to milestones, not hours. A project might be 60% complete by effort but 0% billed if the client hasn’t approved the deliverable that triggers payment. Or it might be 100% billed but only 40% delivered, which is a different kind of problem. Either way, the relationship between hours in the system and dollars in the forecast is indirect at best, misleading at worst.

Capacity planning gets distorted too. If a team is fully allocated to a fixed-price project, the tool shows them as fully booked. But whether that utilization is generating margin depends on whether the project is on budget, not just on whether people are busy. A team can be 100% booked and still be burning money on a fixed-fee engagement that was underscoped in January.

Where this confusion plays out in practice

Prospects evaluating resource planning software name this problem directly. One question that comes up repeatedly: does it make sense to track time on a fixed-price project inside a capacity planning tool? It’s a fair question, and it gets asked often enough to matter. People aren’t sure whether time tracking on fixed-fee work is meaningful, or whether it’s just overhead that feeds a system not built to interpret it.

Both concerns are valid. Time tracking on fixed-price work does serve a purpose, it tells you whether your original estimate was accurate, which informs future pricing. But if the planning tool treats those logged hours as a revenue signal, you’ll get a distorted picture of where you stand financially. Hours burned is not the same as value delivered. And value delivered is not the same as revenue recognized.

Milestone billing adds another layer. When payment is tied to project phases rather than hours, the revenue forecast has to account for when milestones will be hit, not just how many hours are scheduled. Most tools don’t model this natively. You can sometimes approximate it with workarounds: manual revenue entries, custom fields, parallel spreadsheets. But approximations compound. By month three of a six-month engagement, the gap between what the tool shows and what finance actually expects can be significant.

Why this is structural, not a settings problem

Vendors sometimes frame this as a configuration challenge: set up your billing types correctly, use custom rate cards, and map milestones to phases, and the tool can handle it with enough setup.

Some of that is true. Configuration helps at the edges. But the underlying logic of most planning tools still runs on hours-as-proxy-for-value. When you bolt milestone billing onto that foundation, you’re working against the grain of how the system reasons about your business. It’s expensive in time and attention, and it tends to break when project details change.

Fixed-price work also changes the risk profile of capacity planning in ways that T&M logic doesn’t capture. On a T&M engagement, scope creep is the client’s problem financially (within reason). On fixed-price, scope creep is your problem. Capacity planning for fixed-fee work means tracking whether the hours being committed will stay within the budget that was sold, in addition to whether people are available. Those are different questions, and a tool optimized for availability scheduling won’t surface the second one without significant custom work.

What a mixed book actually requires

Few agencies run purely T&M or purely fixed-price. They run both, often within the same client relationship. A retainer for ongoing support, a fixed-fee project for a site redesign, maybe a T&M discovery phase that feeds into a fixed-price build. Each billing model has different implications for how revenue flows, how capacity should be allocated, and how risk accumulates.

Planning across that mix requires a system that can reason about billing type at the project level, not just track hours and multiply by a rate. Revenue recognition needs to follow milestone logic for fixed-price work and time-based logic for T&M. Margin forecasting needs to account for fixed-price projects having a hard ceiling on revenue regardless of effort. Capacity planning needs to flag when a team is allocated to fixed-fee work that’s already over-budget, not just when they’re overloaded in aggregate.

Practically, this means looking for a few specific capabilities when evaluating planning tools:

• Can the system distinguish between project billing types and apply different revenue recognition logic to each?
• Does the forecast model milestone payments separately from hours-based revenue?
• Can you see margin at the project level in real time, not just after the fact in finance?
• When a fixed-price project runs over on hours, does the tool surface that as a margin risk rather than just a utilization signal?

If the answer to most of those is “sort of, with some setup,” treat that as a serious evaluation signal. “Sort of” tends to mean more manual work and less reliable data over time.

How this shapes the evaluation conversation

Agencies that run significant fixed-price volume often enter software evaluations with a specific kind of skepticism. They’ve been burned before, by tools that looked capable in a demo but required workarounds the moment actual project data went in. They ask pointed questions early: does this handle milestone billing? Can it model fixed-fee margin separately from T&M? Where does the data break down?

Direct answers matter here more than polished ones. A tool that handles T&M well and fixed-price partially is still useful, especially if it’s the planning and forecasting layer rather than the billing system. But agencies need to know where the edges are so they can build their workflows around them. Overselling capability creates problems downstream when the tool doesn’t perform as expected in production.

Parallax approaches this directly: fixed-price project support is a known gap in the current product, and it’s one that shapes both the roadmap and the evaluation conversation. Agencies with heavy fixed-fee volume need to weigh that directly against the planning and forecasting value Parallax delivers on the rest of their portfolio. For some shops, the T&M and mixed-model capabilities are enough to justify the platform. For others, the fixed-price gap is disqualifying until it’s closed.

Either way, knowing where a tool actually stands is more useful than discovering it six months into implementation.

What to do in the meantime

If your book includes meaningful fixed-price volume, a few things help at the margins even before your planning tool catches up.

First, separate your revenue forecast by billing type. Don’t let T&M and fixed-price revenue flow into the same model without distinguishing them. Fixed-price revenue should be tied to milestone dates, not hours scheduled. If you’re using a spreadsheet to do this alongside your planning tool, that’s not a failure, it’s a reasonable response to a structural gap.

Second, track hours on fixed-price projects even if the tool doesn’t use them for revenue forecasting. Estimate accuracy on fixed-fee work is one of the most useful inputs to future pricing. If you don’t know whether your $80K project actually took $60K or $110K in delivery effort, you can’t price the next one confidently.

Third, flag fixed-price projects explicitly in your capacity planning reviews. When a project is over-hours relative to its budget, that’s a margin risk that won’t appear automatically in a utilization report. Someone needs to be watching it manually until the tool can watch it for you.

None of this is elegant, but it reflects where the tooling currently stands and what agencies can do to stay ahead of the problem while better solutions develop.

If you’re working through how fixed-price projects fit into your planning stack and want to walk through what that looks like with your actual work mix, we’re glad to think through it with you.

Billing model mismatches don’t announce themselves. They accumulate in the gap between what your planning tool shows and what your finance team sees at month end.

To measure project profitability, subtract direct project costs from revenue, using loaded labor cost instead of billed rate, then divide by revenue and multiply by 100. To forecast it, multiply hours logged by loaded cost, add the projected cost of the remaining hours, and compare the total to the approved budget at least every two weeks.

Project profitability is the percentage of a project’s revenue left after what it actually cost to deliver. Many agencies can calculate that percentage. Few can see it while there’s still time to do anything about it.

That gap appears constantly in conversations with agency leaders. The complaint is rarely “we don’t know our margins.” It sounds more like: the project looked fine at kickoff, looked fine at the midpoint check-in, and then the numbers came in at close. Finance and operations leaders describe this more than almost anything else when the topic turns to margin: not seeing a project go underwater until it already has.

This post covers the formula, how to measure it project by project, and the part most guides skip: forecasting it while the work is still in progress.

What “project profitability” actually measures

Project profitability is a delivery-level number, not a firm-level one. It answers one question: on this specific engagement, how much of what the client paid turned into margin after paying for the people and expenses that delivered it.

Agency profitability works differently. It rolls up every project plus overhead, sales cost, and everything else it takes to run the firm. You can run a string of profitable projects and still have a stressed agency if overhead is heavy or utilization is low. You can also have a healthy firm carrying one or two projects that are bleeding money. Both numbers matter. Project profitability is the one a delivery team can actually manage week to week.

The project profitability formula

It isn’t complicated:

Project margin = (Project revenue − Direct project costs) ÷ Project revenue × 100

Direct project costs mean labor at loaded cost, subcontractor fees, and any direct expenses tied to delivering the work. That excludes overhead and sales and marketing. Just what it took to do this specific job.

Here’s a worked example, using made-up round numbers. These figures are an illustration only, not a target or a benchmark for your firm.

Say a project sells for $100,000. Two people work on it: a strategist billed at $150/hour who costs the firm $90/hour loaded (salary, benefits, and payroll taxes divided into an hourly rate), and a designer billed at $125/hour who costs $70/hour loaded. The strategist logs 200 hours. The designer logs 350 hours. There’s also a $5,000 contractor invoice for a specialty animation.

Direct cost: (200 × $90) + (350 × $70) + $5,000 = $18,000 + $24,500 + $5,000 = $47,500.

Margin: ($100,000 − $47,500) ÷ $100,000 × 100 = 52.5%.

That’s the whole calculation. What takes work is getting an accurate loaded cost rate (many agencies underestimate it by using base salary instead of the fully burdened number) and catching it early enough to matter.

How to measure it per project

Measuring project profitability accurately comes down to three inputs.

Revenue is usually straightforward. It’s whatever the project sold for, adjusted for any approved change orders.

Direct cost is where the error usually creeps in. Loaded labor cost, not billed rate, is what belongs in the calculation. A $100/hour billed developer earning an $85,000 salary with benefits typically has a loaded cost closer to $60 to $70/hour, depending on how your firm allocates payroll taxes, benefits, and paid time off into that rate. Using billed rate instead of loaded cost overstates margin and makes a project look healthier than it is.

Timing is the third input. It’s the one most billing systems get wrong by design. A monthly billing report tells you what happened last month. It doesn’t tell you whether the project currently in flight is on track. That’s a different question, and it needs a different cadence: a check at least every two weeks against the current budget and current scope, not just at month-end close.

We’ve written more about why this data ends up scattered across systems that were never built to answer this question together. If you want the structural version, see why agency project profitability is so hard to predict.

Forecasting it before the project ends

Measuring tells you what already happened. Forecasting tells you where the project is headed while there’s still runway to change course. That distinction matters more than most profitability guides admit, because by the time a monthly report or a project-close review shows a margin problem, the hours are already spent.

An in-flight forecast is simpler than it sounds. Take hours logged to date and multiply by loaded cost. Add the projected cost of hours remaining in the current scope, then compare that total against the approved budget. If the projection is trending past budget while the project still has six weeks left, that’s six weeks to have a conversation about scope, staffing, or a change order. If the same trend only appears at the final invoice, there’s no conversation left to have. It’s just a write-off.

This is where estimation accuracy and margin protection connect. A forecast is only as good as the scope and hours it’s projecting against, which is why the estimate you started with matters just as much as the tracking you do afterward.

Estimation methods: the input your forecast depends on

Every profitability forecast starts with an estimate, and the method behind that estimate shapes how much you can trust the result later. A few approaches come up most often at agencies, and each breaks down in a specific way.

Bottom-up estimation builds the estimate from the smallest deliverables up: scope each task, estimate hours for each, then total it. It tends to be the most accurate method for well-defined work, forcing the estimator to list every piece instead of eyeballing the whole. It breaks down fast when the scope itself is unclear. A bottom-up estimate built on an undefined scope is just as uncertain as any other method. It just looks more precise.

Analogous estimation compares the new project to a similar one already delivered and scales the hours to match. It’s fast. That makes it useful early in a sales cycle, before a detailed scope exists. It breaks down when “similar” is doing more work than it should. A rebrand for a 50-person client and a rebrand for a 500-person client aren’t the same project just because the deliverable list matches.

Parametric estimation uses a rate per unit, hours per page or screen, and multiplies by the number of units. It’s consistent and easy to defend to a client, right up until custom work enters the mix that doesn’t fit the standard unit. Many projects eventually have some.

Three-point estimation asks for an optimistic, pessimistic, and most-likely hour estimate for each major piece, then blends them into a range. It doesn’t remove uncertainty so much as surface it, which is smarter when scope is genuinely unclear. This is usually the right method for discovery-phase work or anything with a client who hasn’t fully defined what they want yet.

None of these methods is universally correct. Bottom-up for defined scope, analogous for fast early-stage sizing, three-point when the scope is still forming. What matters more than the method is what happens after the project closes: comparing the estimate to the actual hours, by category, and tracking where you were consistently high or low. Ten projects of that comparison teach an agency more about its own estimating blind spots than any framework on its own.

Contingency isn’t padding

One estimating habit deserves its own mention: naming a contingency instead of hiding it. A “client feedback and revision” line of 10 to 15% on a design phase acknowledges something specific: feedback cycles are hours that happen on almost every project, whether or not they’re written into the scope. The difference between a contingency and padding is whether you can say what it covers and when it gets used. Teams that do this tend to price more accurately than teams that bury it as invisible margin and hope it’s enough.

If you’re evaluating a platform to help with this

Some agencies get to this point and start looking at software. Full professional services automation platforms, Kantata among them, promise a connected view across sales, delivery, and financials once you’re fully implemented. Kantata’s own site frames it as “instant margin and risk clarity,” which is the right goal. The tradeoff is what it takes to get there: a full platform typically means replacing or layering your CRM, project management, and time tracking under one system. Moving all of it takes time.

A lighter option connects the pipeline, capacity, and cost data already in your existing tools, without asking a firm to migrate off systems that are already working. Weigh that distinction before signing anything. For a closer look at Kantata specifically, see Kantata alternatives for agencies.

Utilization is the other lever tied up in all of this. It sits upstream of margin in a different way than estimation does, and it deserves its own explanation. See agency utilization rate: forecasting it, not just measuring it for that piece, and agency profit margin benchmarks if you’re trying to figure out what range is realistic for your agency type.

We’d be glad to walk through what an in-flight margin check could look like for your projects.

None of this requires new software to start. A two-week check-in cadence and an accurate loaded cost rate will catch most of what currently turns into a surprise at project close. Getting ahead of this has less to do with a sophisticated formula and more to do with not waiting for the invoice to say what’s already true.

Yes. Resource management software can forecast staffing when it connects your pipeline and capacity data, showing who you’ll need and when, weeks before a project starts. That much is table stakes for any decent planning tool now.

What most of that software won’t do is tell you what the staffing mix you picked is costing against the margin you sold. Forecasting who’s available is the easy half of the problem. Seeing what a resourcing decision does to project profit while the project is still running is the part that’s actually missing. That gap, between knowing you have a staffing question and seeing its cost in real time, is where margin disappears before anyone can act on it.

This isn’t exactly a secret. Ask any finance lead at a 50-person agency whether a senior strategist costs more on a project than a mid-level designer, and you’ll get a look that says obviously. The forecasting tools can tell you that senior person is available. None of them tell you, mid-project, what swapping them in just did to your margin.

What “billable utilization” actually means (and how it’s different from billability)

Billable utilization is the percentage of someone’s available hours spent on client-billable work.

Utilization gets used loosely enough that two people in the same meeting mean different things by it. Billable utilization measures billable hours against available hours: actual capacity to work, factoring in time off and internal meetings. If someone has 32 available hours after time off and internal meetings, and 24 of those went to client work, their billable utilization is 75 percent, where dividing by the full week would give 60.

Billability is a related but separate question: whether a role is expected to bill at all, and at what rate. An account lead who spends most of the week on strategy and relationship management might carry a lower billability target by design. That’s not a performance problem. It’s the job. Utilization measures how well someone hits the target they were given. Billability sets what that target should be in the first place.

Utilization and billability get confused because they live in the same dashboard and both look like they’re answering “is this person working enough billable hours.” One measures effort against a target. The other sets the target. A team can hit its utilization numbers and still be misallocated, if the billability target underneath those numbers was wrong to begin with.

Knowing the cost and seeing the cost are two different things

Agencies usually have the raw inputs somewhere. Salary data sits in HR systems or payroll. Billing rates live in a spreadsheet or a CRM. Project hours get tracked in a PM tool. Utilization appears in a dashboard, if someone built one.

A single view that connects those inputs to delivery in motion is rare. The view that matters comes during the project, before it closes and ahead of the monthly finance review, when there’s still time to do something about it.

What follows is a specific kind of operational blindness. Leaders know, in the abstract, that putting two senior engineers on a fixed-fee project instead of one senior and one mid-level will compress margin. They just don’t see it happening until the project wraps and the numbers look worse than expected.

By then, the decision is already made. The margin is already gone.

Why the gap persists even in well-run agencies

It’s tempting to frame this as a data problem, but the data already exists. The issue is structural.

PM tools are built to manage delivery. They track tasks, timelines, hours, and who’s assigned to what. They’re good at answering “is this project on schedule?” They weren’t designed to answer “what is this staffing configuration costing us relative to what we sold?”

Finance systems run in the opposite direction. They’re built to explain what already happened, revenue recognized and margin realized after the fact. Accurate, but retrospective by design.

Neither system sits in the middle and says: here’s how your current resource mix is tracking against the margin you need on this project, right now, while you can still adjust.

Agencies improvise instead. One team lead thinks target hours feel too high and says so in a status meeting. Elsewhere, a finance lead pulls a report and notices something looks off. A resource manager tries to reconcile utilization data with project budgets in a spreadsheet. Everyone works the problem from their corner of the org, without a shared view of what’s actually happening.

Effort isn’t in short supply here. What’s missing is the infrastructure to connect it.

What this looks like in practice

Here’s a pattern that repeats often. A project gets scoped with a specific staffing model in mind, a mix of roles at rates that support the margin target. The project kicks off and delivery starts. Somewhere in week three, a senior person gets pulled in to cover a gap. There’s no formal decision to change the staffing model. It just happens, because that’s how delivery works.

Hours still get logged. The project still looks “on track” in the PM tool. But the cost structure has shifted. The margin assumption baked into the original scope no longer holds, and it stays invisible until the project closes and finance runs the numbers.

At that point, the post-mortem conversation starts. “We were over on senior hours.” “The mix wasn’t what we planned.” “We need to be more careful next time.” All true. All too late.

A similar pattern plays out with target hours. When the hours allocated to a role feel disconnected from how long that work actually takes, it’s often a sign that cost assumptions were set at the proposal stage and never updated to reflect delivery reality. The plan and the project drift apart, gradually, over weeks.

Idle knowledge has a cost

There’s a specific kind of operational cost that never appears on any line item. Call it the cost of knowledge you can’t act on.

Leaders know which resources cost more. They know which project types tend to run over on senior hours. They know which clients generate scope pressure that shifts the staffing mix. That knowledge is real, earned from experience. But if there’s no system that surfaces it during delivery, it stays in people’s heads. Applied inconsistently. Rarely fast enough to protect margin on the current project.

Finance teams sometimes build workarounds: shared trackers people “tap into” to get a rough sense of where costs are running, manual exports from the PM tool matched against rate cards in a spreadsheet. These systems work, to a point. They’re better than nothing. But they require someone to maintain them, someone to know to check them, and enough lead time to act on what they find. All three conditions are rarely true at the same time.

That same gap between knowing and seeing is exactly where margin disappears, piece by piece, across dozens of small staffing decisions that each made sense in the moment, none of which anyone could evaluate against the project’s cost structure in real time.

What closing this gap actually requires

Closing it doesn’t mean replacing the tools agencies already use. PM tools do what they were built to do. Finance systems do what they were built to do. The missing piece is a layer that connects them, one that holds the cost context and maps it to delivery as it happens.

That means knowing, for any active project, what the current staffing mix is costing relative to the margin target. Surfacing it when a resource substitution shifts the cost structure in a way that matters. And giving the resource manager and the project lead a shared view of the same reality, rather than two different exports from two different systems someone has to reconcile by hand.

It also means making the information available early enough to be useful. A weekly finance review is too slow. By the time a cost overrun appears in a report, the decisions that caused it are already two weeks in the past.

Parallax sits in exactly this position, between pipeline and delivery, connecting resource cost to project-level planning in real time. When a staffing mix shifts on an active project, the margin impact surfaces before the numbers are final. Forecasting who’s available is table stakes now. Seeing what that forecast costs the business is the piece still missing from most planning tools.

Signs the gap is active

If any of these are true at your agency, the cost visibility gap is probably active:

• Post-project reviews regularly surface staffing mix as a margin driver, missed during delivery.
• Target hours on projects feel like they came from a different reality than how the work actually runs.
• Resource substitutions happen informally, without anyone calculating the cost impact before they’re made.
• Finance and delivery operate from separate data sources that get reconciled after the fact, not in real time.

None of these are signs the team is doing something wrong. The infrastructure was never built to connect cost to delivery while a project is still running, and that gap is what these patterns point to.

We’d be glad to walk through what that view could look like for your projects.

That’s the planning gap. It costs margin, every time.

Many agency forecasts stop at one to two weeks because the tools behind them were built around committed work rather than forward-looking demand. Delivery data sits in the PM tool, financial data in accounting, and pipeline data in the CRM, and none of them connect into one forward view.

Many agencies can only trust their resource picture one to two weeks out. Everything beyond that is assumption, too thin a foundation to price confidently, hire responsibly, or catch margin risk before it locks in. The constraint is the tools, not the effort agencies put in: the systems in place were built to manage work already committed, not to see what’s coming.

Two weeks is a scheduling window, not a planning horizon

There’s a difference between knowing what your team is doing this week and knowing whether your business can absorb the next project without burning margin. Scheduling answers the first question. Planning answers the second. Many agencies are running on scheduling data and calling it a forecast.

PM tools are good at what they were built for: tracking tasks, timelines, and workload on active projects. They’re not built to look forward across the portfolio and tell you where capacity will tighten in six weeks, or whether the deal in your pipeline can be staffed at the margin you quoted. When you try to use them for that, you’re asking them to reason backwards from committed work instead of forwards from demand.

The result is a planning horizon that stops at roughly two weeks. Within that window, you can see who’s assigned to what. Beyond it, you’re working from assumptions that haven’t been tested against what capacity and demand will actually look like.

The decisions that hurt you don’t wait for your forecast to catch up

Pricing a project, approving a hire, and committing to a start date are decisions made weeks or months before the work begins. If your reliable visibility ends at two weeks, you’re making those calls with almost no data that actually applies to the moment the decision will play out.

Pricing is the clearest example. A project gets scoped and sold based on assumptions about who will staff it, how long it will take, and what the utilization picture looks like during delivery. If those assumptions were built on a two-week planning window, they’re stale before the contract is signed. By the time the project kicks off, the team you planned for is allocated elsewhere, the timeline has compressed, and the margin you quoted is already under pressure.

Hiring works the same way. The decision to bring on a contractor or open a full-time role usually happens after the pressure is already visible. That’s not a failure of judgment. It’s a failure of timing. When your forecast doesn’t extend far enough to show the gap forming, you can’t act early enough to fill it cleanly.

Why the window stays short even at well-run agencies

Short planning horizons are a structural outcome of how agencies connect their tools, not a sign that an agency is disorganized.

Delivery data lives in the PM tool. Financial data lives in the accounting system. Pipeline data lives in the CRM. None of these systems talk to each other in a way that produces a forward-looking view of capacity, demand, and margin together. Ops teams do what makes sense in response: they pull what they can, build a spreadsheet, and work with the window that data supports. That window is usually two weeks.

Spreadsheets are filling a gap here, not causing the problem. No single system in the typical agency stack was built to connect pipeline probability, current capacity, and financial targets into a picture of what’s likely to happen in weeks four through twelve. Spreadsheets step into that gap because something has to. But they freeze assumptions at the moment they’re built. The moment delivery shifts or a deal moves, the model is out of date.

This is what the planning gap actually is: a structural absence of forward-looking infrastructure, not a process failure.

What a longer horizon actually changes

Extending reliable visibility from two weeks to six or eight weeks doesn’t sound dramatic. In practice, it changes the quality of almost every business decision an agency makes.

Pricing gets grounded in the capacity you actually have. Instead of assuming you’ll have the right people available at the right time, you can see whether you actually will before you commit to a number. That’s the difference between a margin target and a margin guess.

Hiring gets ahead of the problem. When you can see a capacity gap forming four weeks from now, you have time to source a contractor, adjust project timelines, or redistribute work before the gap becomes a crisis. Reactive hiring is expensive. It’s also almost always avoidable with a longer view.

Scope conversations happen earlier. If a project is tracking toward overrun in week three, catching it in week one means you still have options. You can have a conversation with the client, adjust resourcing, or reprice. Catching it in week five means you’re absorbing the loss.

None of this requires perfect forecasting. It requires a reliable enough view, far enough out, that decisions land before they’re forced.

The evaluation question many agencies skip

When agencies evaluate planning tools, the conversation usually centers on features: integrations, reporting views, time tracking, dashboards. Those are reasonable things to assess. But there’s a more fundamental question that often gets skipped.

How far out does this tool give me a reliable resource picture?

A tool that shows you beautiful dashboards of what happened last month doesn’t close the planning gap. A tool that shows you task assignments for active projects doesn’t close it either. The question is whether the system can connect pipeline demand to current capacity to financial targets and show you where the pressure is forming before it locks in.

That’s a different capability than scheduling. And it’s the one that actually changes how pricing, hiring, and margin decisions get made.

Short horizons surface in the financials, eventually

The two-week trap doesn’t announce itself. It surfaces in patterns that are easy to attribute to other causes.

Margin misses that seem project-specific. Hiring decisions that always feel rushed. Pricing that felt right at signing but eroded by delivery. Contractors brought in at the last minute because the gap wasn’t visible until it was urgent. Each of these looks like an execution problem. Many of these are planning problems that started weeks earlier, when the window was too short to see what was coming.

The financial system shows you what happened, eventually. The planning system should show you what’s about to happen. Many agencies have one without the other.

Closing the gap doesn’t mean replacing your stack

The instinct when this problem becomes visible is to look for a new PM tool, or a better CRM, or a more sophisticated accounting system. Those tools are doing exactly what they were built to do; replacing them isn’t the fix.

What’s missing is a layer that sits above the stack and connects the data those tools already hold into a forward-looking view. Pipeline probability from the CRM. Capacity from the PM tool. Financial targets from accounting. When those inputs are connected and updated continuously, the planning horizon extends naturally. The picture is finally being assembled from the right sources.

Parallax is built to be that layer. It doesn’t replace the tools your team already uses. It connects them in a way that produces the forward visibility that none of them can produce alone. The goal is a reliable resource picture that extends far enough out to actually inform pricing, hiring, and scope decisions before they’re locked.

We’d be glad to walk through what a six to eight week view of your own work could look like.

Two weeks is enough to manage the week. It’s not enough to run the business.

A resource planning tool is useful for agencies when it connects pipeline demand and team capacity to actuals well enough to show whether the firm can take on more work, and when. Few tools do all of that, so what’s right depends on whether the agency’s gap is scheduling or forecasting.

There’s no shortage of resource planning tools. What’s actually in short supply is a comparison you can trust.

The typical review runs through the same feature checklist: can it schedule, track time, and flag who’s overallocated? Those are useful questions, but they miss the one agencies actually need answered: can we take on more work, and when?

This comparison is organized around that question. It covers forecasting as well as scheduling.

What makes a resource planning tool useful for agencies?

A resource planning tool is useful for agencies when it connects pipeline demand, team capacity, and actuals well enough to drive staffing, pricing, and utilization decisions.

Few tools hit all three. Most hit one or two. The comparison below groups tools by where they actually land, not where their marketing suggests they do.

Category 1: Scheduling tools (great at assignment, limited on forecasting)

Float

Float is the most-used resource scheduling tool in the category, sitting at the top of G2 Resource Management for multiple consecutive seasons. It earns that ranking on scheduling: drag-and-drop assignment, clean visibility into who is on what, straightforward onboarding. For teams whose primary question is “who is available next week,” Float answers it well.

Where Float has limitations in a forecasting context: it’s built around the schedule view, not the pipeline. It doesn’t connect to CRM data, which means capacity planning requires the user to manually build demand into the tool rather than pulling it from where pipeline lives. Financial margin tracking exists (added as a product feature in 2025) but it’s not the primary use case.

Pricing: $7/person/month (Starter) and $12/person/month (Pro), with a 30-day free trial and an entry price that scales cleanly.

Runn

Runn positions as “strategic resource management” with a half-year and full-year planning view. Among the scheduling-focused tools, it has the strongest capacity planning features: hiring reports, utilization projections, and a financial margin layer. It integrates with 13 HR platforms including BambooHR and HiBob, which helps with headcount data accuracy.

Limitations: 20-seat minimum for any plan, which prices out smaller teams. As of September 2026, Runn has added SmartMatch AI (Beta) on the Advanced plan, but it’s still limited compared to all-in-one platforms on the finance side.

Pricing: $7/resource/month (Lite), $11/resource/month (Standard). 30-day free trial.

Where scheduling tools fit best: Teams whose main bottleneck is assignment visibility, not planning. An agency that needs to see who’s available across concurrent projects and schedule work cleanly will do well here. An agency asking “do we have capacity to win another retainer?” needs more.

Category 2: All-in-one platforms (broad capabilities, significant adoption cost)

Productive

Productive is purpose-built for agencies and consultancies. The platform covers the full agency lifecycle: CRM, resource planning, project management (Gantt), budgeting and profitability, invoicing, financial reporting, and time tracking. For an agency willing to migrate their stack, it reduces the number of tools dramatically.

AI features (Productive AI) are live: AI-powered reporting and time tracking. Ultimate adds AI agents for custom workflows. Integrations cover Xero, QuickBooks, Jira, Slack, and HubSpot.

Adoption is the tradeoff. An agency already running Monday, HubSpot, and Harvest isn’t switching to Productive lightly. Implementation time, training, and data migration all cost more than the subscription line suggests.

Pricing: Essential runs $10-12/user/month, Professional is $25/user/month (annual billing), and Ultimate is custom, quote only. 14-day free trial. For a 50-person agency on the Professional plan, expect $15K/year.

Scoro

Scoro covers similar ground at a higher price point and with more emphasis on financial depth. The platform is strong on profitability and margin visibility, with dashboards that surface utilization, project performance, and billing in the same view.

Scoro’s ELI AI companion adds natural language querying, and the company’s MCP server connects ELI to external AI tools including Claude. It’s one of the more aggressive AI investments in the category.

Limitations: pricing runs higher than Productive at the top end (Scoro’s priciest bundle reaches $57/user/month against Productive’s $25 published Professional rate), a 5-seat minimum, and a steeper learning curve. Reviews consistently flag implementation complexity.

Pricing: Scoro no longer sells a single Growth plan. It now sells four app bundles, from $17/user/month (Time-billing) to $57/user/month (End-to-end), annual billing, 5-seat minimum. 14-day free trial. For a 50-person agency, that runs roughly $10K to $34K a year depending on the bundle.

Where all-in-one platforms fit best: Agencies actively consolidating. If the pain is tool fragmentation and the agency is willing to invest in migration, the all-in-one approach pays off over time. A team three weeks into a new PM tool, trying to add resource planning without disruption, should look elsewhere.

Category 3: Overlay tools (add forecasting to your existing stack)

Parallax

Parallax layers onto the tools agencies already have rather than replacing them. It connects pipeline (from CRM), capacity (from headcount and time tracking), and actuals (from time reporting) in a single view focused specifically on the forecasting layer.

Specific use case: an agency wants to see, in one place, what work is coming based on their weighted pipeline, whether they have the capacity to deliver it, and where plan versus actual is diverging. That question requires data from three systems. Parallax is the overlay that holds the connection together.

Fix My Project (part of the Maslow AI toolkit) is the AI feature currently live: it analyzes project health and flags at-risk engagements before they become fire drills.

This approach is also the fastest to deploy. Agencies that have tried all-in-one platforms before and walked back the implementation tend to find the overlay model more realistic for their current stack situation.

Pricing: ~$30K ACV. No per-seat model; Parallax charges at the firm level.

Where overlay tools fit best: Agencies that have an established PM and time-tracking stack they’re keeping, and whose gap is specifically the forecasting and planning layer connecting pipeline to capacity to delivery.

Category 4: Spreadsheets (still the default for many agencies)

Spreadsheets remain the capacity planning layer at a lot of agencies, including well-run ones. They fill the gap between the PM tool (which knows what’s committed) and the CRM (which knows what’s in the pipeline). Flexible, fast, no implementation cost.

Volatility is the limitation. A spreadsheet model that was accurate in January is usually wrong by March, not because anyone built it wrong, but because it wasn’t built to absorb changes. Every scope change, late hire, and pipeline shift requires a manual update. Most spreadsheets don’t get those updates consistently.

Spreadsheet use is a signal about where an agency sits on the maturity curve for resource planning. The test that matters: how long does it take to answer “can we take on one more retainer this quarter?” More than ten minutes means the spreadsheet is becoming a bottleneck.

How to choose

A few questions narrow the list quickly.

Is your primary question “who is available next week” or “can we take on more work”? The first question points to scheduling, where Float or Runn fit. The second points to forecasting, where the choice is between an all-in-one platform and an overlay.

Are you willing to migrate your PM and CRM data? Yes: Productive or Scoro. No: overlay approach or scheduling-only.

Is your team at the adoption capacity for a platform implementation? Answer that one straight. An agency that has tried and walked back an all-in-one implementation in the past three years should think twice before starting another one.

How many seats? Under 20 people: Float or Productive at the lower tier. 20 to 100 people: any of these depending on the above questions. Over 100 people: all-in-one and overlay options are the realistic set.

If the comparison above narrows your shortlist to one or two options and you want to think through the forecasting angle specifically, we are glad to be useful in that conversation. Plenty of agencies have a scheduling tool they like and a forecasting problem they’re still working around.

Tools don’t solve the planning gap. But the right tool makes the gap visible. That’s more than many agencies have.

A resource plan holds up against actuals when it is built to absorb changes and surface divergence quickly, so it gets corrected instead of replaced. That takes five steps: start from pipeline demand, plan capacity by role, connect the plan to a time-tracking baseline, set a reconciliation cadence before launch, and define divergence triggers in advance.

Resource plans usually work fine on the day they’re built. Three weeks later, a senior designer goes on leave, a proposal closes earlier than expected, and a client pushes their timeline. The plan is still technically “in place,” though updates stopped, and it no longer matches reality.

Building a resource plan that holds up against actuals is a different exercise than building one that looks complete at kickoff. It requires a few structural choices up front. Choices most planning guides skip entirely.

What makes a resource plan “hold up” against actuals?

A resource plan holds up against actuals when it’s designed to absorb changes, surface divergence quickly, and inform corrections rather than get replaced.

Plans usually fail at the last two. They’re built to exist, not to be used as a tracking tool. A plan that holds up has a reconciliation cadence baked in from day one. It treats divergence as information, not failure. And it distinguishes between changes that matter for decisions and noise that can be ignored.

Five steps below build a plan with those properties from the start.

Step 1: Start with pipeline demand, not project assignments

The most common mistake in resource planning is starting with the project schedule instead of the pipeline.

When you build the plan from existing projects, you’re answering “who is working on what is already committed.” That’s useful. But it misses the work that’s about to be committed: the 70% probability deal closing next month, the renewal conversation that’s going well.

Start by pulling your weighted pipeline. Group work by start date range, not by client. If three proposals are likely to start in the same six-week window, that’s a capacity signal, not three separate scheduling decisions.

Building the demand side first lets you spot the crunch before it turns into three simultaneous kickoffs and one overloaded team. That’s eight weeks of lead time versus one week of triage.

Step 2: Build capacity at the role level first

Naming individuals to projects twelve weeks out is fiction. You don’t know yet who will be available, what project will slip, or who will be hired. Plans built at the individual level that far out get rebuilt constantly.

Build capacity at the role level: senior strategist, mid-level developer, project manager. How many of each do you have at 80% billable capacity over the next three months? Where are the holes?

When a commitment is four weeks out or closer, then name individuals. Beyond that, work in roles and percentages. A capacity view that says “we have two senior developer slots available in Q3” is actionable. A schedule that names specific developers to Q3 projects is usually wrong by the time Q3 arrives.

Role-level capacity also makes scenario planning possible. If a key hire falls through, how does the picture change? You can answer that in twenty minutes when the plan works at the role level. Name-level plans require a full rebuild.

Step 3: Connect the plan to a time-tracking baseline

A resource plan without a time-tracking baseline is a forecast with no feedback loop.

Automated or not, what the connection needs is straightforward: a consistent way to look at what was planned for the week and what was actually logged, plus a shared agreement on what size of gap actually matters.

Some teams do this manually in a weekly spreadsheet. Others pull it from their PSA or time-tracking tool. The mechanism matters less than the habit. A plan that gets compared to actuals every week, even loosely, is more accurate than one that gets compared to actuals at the monthly billing cycle.

Timesheet data is only useful if it feeds back into the plan. That loop is what makes a resource plan a planning tool rather than a scheduling artifact.

Step 4: Set a reconciliation cadence before the plan goes live

Before publishing the plan, agree on how often it will be reconciled. Not reviewed. Reconciled. That means comparing what was planned to what happened and deciding what to update.

Weekly reconciliation for the active horizon (next four weeks). Monthly reconciliation for the medium-range view (five to twelve weeks). Quarterly refresh for anything beyond that.

Skipping the reconciliation cadence is the single most common reason resource plans become shelfware. Without a scheduled moment to close the loop, the plan drifts from reality until someone decides to rebuild it from scratch. By then, the decisions it could have informed have already been made without it.

Weekly reconciliation anchors well to the resourcing meeting, but only if the agenda explicitly includes plan-versus-actual comparison. A meeting that just discusses next week’s assignments is scheduling, not planning.

Step 5: Define your divergence triggers before they happen

When the plan and actuals start to diverge, you need a framework for deciding whether it matters.

A senior designer is two days over on a project. Does that change anything? A client milestone slips by a week. How does that ripple? A new hire starts three weeks later than expected. What now?

Define triggers in advance: if utilization runs more than 10 points above the plan for two weeks in a row, flag it. If a new project commits without a corresponding capacity adjustment, flag it. If the pipeline-weighted demand changes by more than 20%, trigger a mid-cycle refresh.

These thresholds are simple by design, meant to surface things that matter before they compound rather than to nail exact precision. Without triggers, you’re waiting for someone to notice; with triggers, the plan tells you.

What to do when the plan breaks

Plans break. Always. That’s not a failure in the plan. It’s data.

When the plan and reality diverge significantly, three questions help decide what to do.

First, is the divergence inside the project, or does it change the firm’s capacity picture? A project running long that’s fully staffed affects that project. A project running long that’s pulling from the same pool as two other upcoming engagements is a capacity conversation.

Second, was the divergence foreseeable? If the risk appeared in the plan but wasn’t flagged, that’s a process issue, so build a trigger for it. If it wasn’t foreseeable, such as an unplanned scope change or a key hire departure, treat it as a one-time correction.

Third, how long does the firm have to respond? Eight weeks leads to different options than two weeks. Responding to plan divergence is a lot like resource forecasting in general: lead time is the resource.

Rebuilding the plan from scratch every time something changes is a symptom of a plan that was built to be right, not to be used. Build the plan for use, and update it instead of replacing it.

A simple resource plan template to start

No special tool is required, just four tabs in a spreadsheet, and that’s enough structure to work from.

Tab one: pipeline demand (weighted by probability and sorted by projected start date). Tab two: capacity (roles, headcount, percent available, planned leave). Tab three: the active schedule (who is on what for the next four weeks, by name and role). Tab four: the reconciliation log (week-by-week comparison of planned vs actual, two columns, notes on gaps).

Four tabs are enough to start. A fifth tab for scenario planning (what happens if the biggest pipeline deal closes early, or doesn’t close) is optional but useful once you’ve run the base version for a quarter.

When the spreadsheet starts to break under the weight of these questions, that’s a signal. Spreadsheets are fine. The planning layer has outgrown what one spreadsheet can hold together.

If your resource plan consistently looks good at the start of the month and irrelevant by the end, the problem is the reconciliation structure around it, not the plan itself. We’ve helped teams build that loop. Happy to talk through what it looks like in practice.

A plan that holds up is measured less by being right at the start than by how quickly it notices when it’s wrong.