Most consulting projects come in over budget. The exact share depends on which survey you trust, but every published benchmark puts it above half and most put it around two-thirds. The number that matters more is the one nobody publishes: how many of those overruns came from a bad estimate that nobody flagged at scoping time.
The fix isn’t better estimating tools. It’s knowing when to refuse to estimate.
The move you can take to a client tomorrow is Phase 0: a paid, scoped discovery engagement that produces a real estimate before you commit to a full delivery scope. The sentence to use:
“We can price the implementation after a paid Phase 0 discovery — four to eight weeks, defined deliverable. Pricing it today would be fiction.”
That is the line that protects margin and reputation when the integration target isn’t documented, the data hasn’t been audited, or key technical decisions sit on the client’s side. The rest of this piece is two stories — one where Phase 0 wasn’t used and the firm absorbed a $170K overrun, one where it was — and then the playbook for running Phase 0 cleanly.
Story One: The Estimate Built to Close the Deal
The partner had been working this account for seven months. The client had budget at the end of Q3. There was competitive pressure — two other firms were in the conversation. The scope needed to be signed before September 30th or the budget would evaporate.
The engagement: a three-system data integration, connecting a newly purchased ERP to a legacy CRM and a third-party analytics platform. Estimated at $340,000. Eight weeks. Six-person team.
The estimate came from a template. The partner pulled the closest prior integration engagement — a two-system integration from eighteen months earlier — adjusted the team size, added two weeks, and submitted. Nobody on the delivery team was consulted before the SOW was signed. The PM was onboarded on the Monday after the contract executed.
She read the SOW and found three problems in the first hour.
The legacy CRM had not been documented in the estimate’s assumptions. The prior engagement’s template assumed a well-documented API. This CRM’s API documentation was partial, built by a vendor the client no longer used, and hadn’t been updated in four years.
The analytics platform was a recent acquisition by the client — a SaaS product with a custom data schema that differed significantly from what the integration assumed. The SOW referenced a “standard connector.” No standard connector existed.
The eight-week timeline assumed clean data. The client’s data had never been audited. It turned out to be in three different formats across twelve years of records.
The project ran to fourteen weeks. Final cost: $510,000. The PM spent the first three weeks trying to figure out what the team had agreed to. Two senior consultants worked evenings for six weeks. One of them left the firm three months after the project closed. The client didn’t renew.
The partner had won a $340,000 deal. The firm delivered a $510,000 engagement and collected $340,000 for it. The team absorbed the difference as overtime. Leadership saw a project that went over budget. Nobody connected the overrun back to the template estimate or the commercial pressure that produced it.
The Anatomy of a Bad Estimate
The story above is synthetic. The pattern is not. It runs at firms of every size.
Bad estimates in professional services trace to a small number of causes, and most of them aren’t stupidity or incompetence. They’re rational responses to the wrong incentives.
The partner needed the deal closed. Quarter-end pressure is real. Competitive pressure is real. Budget windows are real. When the choice is between a rigorous estimate that takes two weeks and a template estimate that takes two days, and the deal expires if you don’t move, the template wins. The firm wins the deal and loses margin on delivery. This is completely predictable. It happens anyway.
The scope was priced from a template, not from the work. Templates are useful for genuinely repeatable work. They’re dangerous for work that looks repeatable but isn’t. Every integration looks like every other integration until you open the API documentation. Every migration looks like every other migration until you look at the data. The template’s job is to give you a starting point; the delivery team’s job is to validate whether that starting point fits this specific engagement. When delivery is never consulted before the SOW is signed, the template’s assumptions go live untested.
The team starts the project trying to figure out what they agreed to. This is the downstream symptom of the first two causes. The PM reads a SOW that was written to win a deal, not to deliver one. She finds ambiguities, gaps, and assumptions she would have challenged if she’d been consulted. She adapts, improvises, and carries those open questions forward until they surface as problems. The project is behind before it officially starts.
Caution. Those unrecovered hours don’t just hit one project. They hit the next one too. The bad-estimate template gets reused. The delivery team that absorbed the overrun has moved on — or left the firm — and the PM on the next similar engagement starts from the same bad starting point.
Story Two: The Integration I Scoped Right
I once scoped a three-phase integration. The engagement looked straightforward from the outside: connect three systems, migrate historical data, stand up reporting. The client was sophisticated, the timeline was reasonable, the budget expectation was in range.
Then I started asking questions.
The first rule of scoping is don’t cost something you don’t understand. And no amount of questions were going to help us understand how difficult this work was going to be. The integration target was a custom software being built by a third party not on the call, owned by another department, and it wouldn’t be built for another six months — like hitting a bullet with another bullet while on a unicycle.
There was no API to review. There was no schema to examine. There was no way to know what the integration surface would look like until the software was built. Any estimate we gave would be fiction.
The partner wanted a number. The client wanted a SOW. Everyone in the room had incentives pushing toward “just scope it and we’ll figure it out.”
We didn’t.
Instead, we proposed a Phase 0 / Discovery engagement. A defined, scoped, paid phase of work — six weeks, small team — to do three things: work alongside the third-party development team to understand the integration surface as it was being built, audit the historical data we’d be migrating, and produce a technical architecture document that the full delivery team could actually estimate from.
The Phase 0 deliverable was not software. It was a real estimate — built by the team who would do the work, based on what the work actually was.
The client agreed. Not immediately — there was a conversation about why we couldn’t just give them a number now. The honest answer was: because any number we gave you now would be wrong, and you’d be better served knowing that up front than discovering it in month three.
The Phase 0 Move: When and How to Use It
Phase 0 / Discovery is the right answer when any of the following are true:
- The integration or migration target is not fully built or documented
- The data being worked with has not been audited and its condition is unknown
- Key technical decisions haven’t been made by the client’s team (architecture, platform, vendor selection)
- The scope depends on information that will only be available after the engagement starts
- The complexity of the work scales with variables you can’t measure yet
In those conditions, a committed estimate isn’t an estimate. It’s a guess with a dollar sign. You’re not pricing the work — you’re pricing your best imagination of the work.
The Phase 0 move reframes the ask: instead of committing to a full delivery scope, you commit to figuring out what the full delivery scope should be. You deploy a small team — typically the senior technical lead and a project manager — to do structured discovery: review what exists, audit what you’ll be working with, and produce a technical specification that supports a real estimate.
The output of Phase 0 is a high-level cost estimate based on actual effort and the potential costs given the magnitude of what you found — with no commitments on the full engagement without team involvement. When the estimates come back from the delivery team who actually reviewed the work, you work together with the client to pare the scope into their budget range. That’s a negotiation based on real numbers, not a pitch based on template assumptions.
Some clients push back on Phase 0. They want a full commitment on day one. The right response is to explain why that commitment would hurt them: a committed price built on unknown variables is a price that will change, either through change orders or through your team absorbing overruns they can’t recoup. A Phase 0 price is a commitment to give them a real answer — and then hold to it.
The firms that use Phase 0 consistently have better margins, better delivery outcomes, and fewer mid-project conflicts. The phase costs the client something. What it buys is a project that starts from a real scope, not a fictional one.
The Team-Attrition Feedback Loop
Bad estimates don’t just destroy margin on one project. They destroy the team that absorbs them.
Don’t let your teams absorb bad estimates. You lose your best people, and the knowledge goes out the door.
The number of times I’ve worked with project teams that left mid-project from other firms is astronomical. And they always tell you about how they were being managed, overworked, underappreciated. The story is always the same: the estimate was wrong, the team was expected to make it right, nobody acknowledged that the team was working 50 hours to deliver 40 hours of billed work, and eventually the best people — the ones who care the most, the ones who stay late and fix things — updated their LinkedIn profiles and left.
The cost of replacing a senior consultant is somewhere between 1.5x and 2x their annual salary when you factor in recruiting, onboarding, and the six to twelve months before a replacement is fully productive. Nobody connects that cost back to the bad estimate that caused the burnout. In the system, it shows up as an unrelated attrition event.
But it isn’t unrelated. The senior engineer who left carried three years of institutional knowledge about your client’s systems, your firm’s delivery patterns, and the workarounds that make your tooling actually work. That knowledge doesn’t transfer in an offboarding conversation. It leaves.
The next delivery team starts slightly behind because the person who knew the shortcuts is gone. The next estimate is slightly worse because the person who knew what the prior project actually took is gone. The defect compounds.
The pattern I see repeatedly: a firm runs two or three years of under-resourced delivery, burns through its best people, and then wonders why its margins are deteriorating and its newer consultants keep making the same mistakes the departing seniors would have caught. The root cause is estimates that treated the delivery team as a cost buffer rather than a finite human resource.
What Scoping Discipline Looks Like in Practice
The firms that estimate well share a small number of practices. None of them are complicated. All of them require someone with authority to hold the line.
One rule: don’t cost something you don’t understand. This sounds obvious. It is routinely violated under commercial pressure. The partner who holds this line — who says “we need two more weeks of discovery before we can price this” when the client wants a SOW in three days — is doing the client a service, even when the client doesn’t see it that way yet.
Delivery must be in the estimate. Not as a reviewer. Not as a sign-off after the SOW is written. As a co-author, at the table when the scope is being built. The PM and the technical lead should have input into the estimate before it goes out the door. If they would have priced it differently, that difference should be resolved before the client sees the number.
When estimates come in from the delivery team, work together to fit the scope to the budget. This is not the same as cutting scope to hit a number. It’s building the scope collaboratively — starting from what the delivery team says it will actually take, and then making conscious decisions about what to include, defer, or descope. The client participates in this conversation. The alternative — scoping to the client’s budget and hoping delivery comes in under — is what produces the Story One pattern.
Phase 0 is a product, not an excuse. Some firms use “we need to do discovery first” as a way to delay commitment. Phase 0 done right is a committed scope with a defined deliverable: a real estimate, produced by the people who will do the work, based on what the work actually is. It has a timeline. It has a price. It has an output. It is not an open-ended exploration, it is a specific engagement with a specific purpose.
