The estimate looked healthy. The team delivered. The customer was happy. Somehow, the P&L came in lower than it should have. Again.
Every delivery leader I work with has watched this pattern play out. The project estimate looks healthy at the start. The team executes reasonably well. The customer is satisfied at the end. And yet, when the P&L closes, the margin came in below where it should have. Not catastrophically. Just consistently, project after project, quarter after quarter.
The usual suspects get blamed first. Scope creep. Estimation error. Bad customer discipline. Sometimes those are the culprits. But often, when we dig into the delivery data with clients, none of those explanations account for what actually happened. The scope held. The estimate was reasonable. The customer was reasonable. The margin still eroded.
What’s happening is more structural and less visible. It’s not one thing going wrong. It’s a series of small inefficiencies built into the way most project-driven organizations have architected their delivery model. Each one looks minor on its own. Added together, they’re the reason the margin math doesn’t work.
Here’s what’s actually happening, and why the usual fixes don’t help.
Where the margin actually goes
When we work with delivery leaders to diagnose margin erosion, the leaks tend to show up in the same five places. None of them are dramatic. All of them compound.
- PMs spending senior time on administrative work. Your project managers are expensive resources. When they’re updating spreadsheets, chasing status inputs, formatting reports, and reconciling data across systems, they aren’t doing the billable, client-facing, revenue-generating work they’re actually being paid to do. Every hour of admin work by a senior PM is an hour of margin you’re paying full rate for and getting no return on.
- Data quality gaps forcing rework and re-planning. When the project data is incomplete, inconsistent, or lagging behind reality, decisions get made on bad information. Which means those decisions have to be revisited. Which means the team plans, replans, and re-replans on the same scope. Each cycle costs time you didn’t bill for.
- Late risk identification. Risks caught in month three are usually fixable. Risks caught in month five are usually expensive. And risks caught in month seven often eat the remaining margin entirely. The reason risks get caught late isn’t that PMs aren’t looking. It’s that they don’t have time to look upstream because they’re buried in current-week firefighting.
- Change orders that don’t get billed. This one is particularly painful because the revenue was there for the taking. But when a PM is stretched thin, catching a subtle scope change, documenting it, and getting the change order signed feels like extra work on top of the actual delivery. So it gets postponed. And then forgotten. And then absorbed into the original scope at your expense.
- Utilization losses from stale resource data. When leadership can’t see clearly who has capacity and who is overallocated, resource decisions get made on outdated information. People end up idle when they could be billable. Other people end up overloaded and start missing details, which produces more rework, which produces more overload.
Any one of these on its own is manageable. All five happening at once, across every project in the portfolio, is the reason the margin math doesn’t work.
Why the usual fixes don’t solve it
When delivery leaders recognize the pattern, the instinct is to attack it with the tools they already have. Almost always, those attempts either fail outright or produce modest improvement at high cost. Here’s why.
Buying a better PM tool doesn’t work. New software adds administrative burden to the same overloaded PMs. The tool may be capable of producing better data, but only if the PMs feed it consistently, which they can’t, because they’re already underwater. The tool ends up half-populated and half-trusted. See last week’s article on why software implementations fail.
Hiring more senior PMs doesn’t work. More senior PMs cost more, do the same double-duty of leadership plus administration, and produce the same output problem at a higher price point. You’ve added cost without changing the underlying architecture that’s causing the leaks.
Adding process discipline doesn’t work. New standards, templates, checklists, and reporting cadences all require PM time to implement. If the PMs don’t have time to comply, the process discipline gets subverted or ignored. The organization is now paying for process infrastructure that isn’t being followed, which is worse than not having it at all.
Reporting harder doesn’t work. Better dashboards, cleaner report formats, and more frequent status meetings produce prettier reports on top of the same bad data underneath. Leadership feels more informed. The margin problem continues.
The reason none of these work is that they’re all trying to fix the problem at the wrong layer. The problem isn’t the tools. It isn’t the PMs. It isn’t the process. It’s the architecture of the delivery model itself.
The architectural problem
Most project-driven organizations have architected their delivery model around a single role that’s asked to do two fundamentally different jobs at the same time.
Job one is leadership work. Client relationships, technical judgment, stakeholder navigation, risk assessment, decision-making under ambiguity. This is the work that requires senior expertise, and it’s what your customers are actually paying for when they engage a PM on their project.
Job two is administrative work. Data entry, schedule maintenance, status collection, coordination, report formatting, change order documentation, resource allocation updates. This work is essential to the delivery operation. It just doesn’t require senior expertise. It requires focus, consistency, and the time to actually do it well.
When you ask one person to do both, one of two things happens. Either the leadership work suffers because the PM is drowning in administrative tasks. Or the administrative work suffers because the PM is prioritizing client-facing delivery, which is the right call in the moment but produces the exact data quality gaps that erode margin later. Usually both happen at once.
This is a math problem, not a performance problem. Even a great PM can’t do both jobs at once without one suffering. The architecture is the ceiling, not the person.
What the right architecture looks like
The delivery models that produce healthy margins have separated these two functions. The PM handles the leadership work. A dedicated administrative function handles the operational scaffolding. This is not a new idea. Healthcare, construction, and manufacturing figured this out decades ago. Project-driven professional services firms are often the last to adopt it.
In practice, the administrative function shows up as a Project Admin, Scheduler, Project Coordinator, or similar role, often shared across multiple PMs at a one-to-many ratio. Their job is to keep the data current, the schedules accurate, the reports timely, the change orders documented, and the resource picture clean. They enable the PM to do the work only the PM can do.
The immediate objection most executives raise is cost. Another headcount that can’t be billed. Pure operational overhead. In practice, this framing is wrong, and the math proves it out consistently. That role isn’t overhead. It’s the missing link that unlocks the return on every other investment already made in the delivery operation. Better tools finally get used properly. Senior PMs finally spend their time on senior work. Data quality reaches the threshold where leadership can actually make decisions on it. Change orders get caught and billed. The leaks close.
What happens when companies actually test it
The pattern is predictable enough that we’ve run it as a proof of concept with clients who were skeptical. Here’s one example.
An aerospace manufacturing client came to us convinced their PPM tool was broken. Reports were unreliable. Leadership couldn’t trust the data. The obvious answer was to evaluate replacement platforms. When we looked at the actual situation, the tool was fine. The problem was that the data going into it was incomplete, inconsistent, and produced by PMs who didn’t have time to feed it properly. Changing the tool would have moved the same problem into a more expensive container.
We placed a Project Scheduler alongside their PM team at no cost to prove the point. Within weeks, the data quality in the existing tool improved dramatically. Reports became reliable. Leadership could see the true portfolio picture for the first time. The client didn’t need a new tool. They needed the missing role that made the tool actually work. They subsequently built out a full scheduling function of their own.
The pattern is consistent across the companies who have tested this. Data quality shifts within the first month. PM utilization increases because they’re spending their time on the work they’re actually being paid for. Change orders that used to get lost start getting captured and billed, which alone often covers the cost of the role. And leadership finally gets project data they can trust for decisions.
The role that looked like overhead pays for itself. And the companies that have seen it work do not go back.
Where to start
If your project margins have been eroding and you can’t diagnose exactly why, the answer probably isn’t inside your current tools, your current PMs, or your current processes. It’s a question about how the delivery model itself is architected, and whether the people you’re asking to lead your projects have been set up to actually do that job.
The diagnostic is straightforward. Look at where your senior PMs are actually spending their time. If more than 30% of it is going to administrative work, data hygiene, and reporting, you have this problem. If your project data is consistently late, incomplete, or distrusted by leadership, you have this problem. If your change orders are getting caught in retrospective reviews rather than in the moment, you have this problem. If none of your PM tools have delivered the reporting quality that was promised at implementation, you have this problem.
The fix isn’t a tool or a hire. It’s a change in how the work is architected. That’s the conversation worth having.
Diagnosing margin erosion in a project-driven business?
EPMA helps delivery leaders diagnose where margin is actually leaking in their project operations, and design the architectural fixes that produce measurable results. If you’re seeing the pattern in your own P&L and want an experienced set of eyes on it, let’s talk.
