I made a mistake early in my career that still bugs me. I was running a mid-size consulting practice, and we’d just lost a big engagement — client was furious, margin was destroyed, people were burned out. In the post-mortem, everyone pointed at delivery. The project manager dropped the ball. The developers missed deadlines. The QA process was sloppy.
We fired the PM and hired a better one. Problem solved. Right?
Three months later, same type of engagement, same client profile, same disaster. Different PM. Different team. Same outcome.
That’s when it hit me: the problem wasn’t delivery. The problem was everything that happened before delivery started. We’d scoped the work wrong. We’d underestimated the complexity. We’d priced it too low to absorb the risk. By the time the delivery team got their hands on it, the engagement was already underwater. No amount of PM heroics was going to save it.
The Six Stages Nobody Talks About (Together)
Every professional services engagement goes through six stages. I don’t care if you’re a two-person agency or a 5,000-person consultancy — the stages are the same. What varies is how deliberately you manage each one.
Here they are:
- Discovery — Understanding what the client actually needs
- Estimation — Translating needs into effort, resources, and timeline
- Proposal — Packaging scope, price, and approach into a document the client signs
- Activation — Setting up the team, plan, and infrastructure once the deal closes
- Delivery — Doing the actual work
- Learning — Capturing what happened and feeding it back
Most firms have dedicated tooling and process for stages 4 and 5. Maybe 3. The rest is improvised.
Stage 1: Discovery — Where Deals Are Won or Lost
Discovery is the most undervalued stage in the engagement lifecycle. It’s the conversation — or series of conversations — where you figure out what the client actually needs. Not what they say they need. What they actually need.
Here’s what bad discovery looks like: Client says “We need a new website.” Firm says “Great, we do websites.” Proposal goes out. Project starts. Six weeks in, it turns out they also need a CMS migration, their existing analytics setup is a mess, and they want the site to integrate with three internal systems nobody mentioned. Scope creep? No. Discovery failure.
Good discovery is structured. It identifies not just the deliverables but the complexity drivers — the things that make this particular engagement harder or easier than a typical one. Number of stakeholders. Legacy system constraints. Decision-making speed. Data quality. Regulatory requirements.
These drivers should feed directly into estimation. In most firms, they live in someone’s head and get forgotten by the time the estimate is built.
Stage 2: Estimation — The Art Nobody Wants to Systemize
Estimation is where I see the most organizational denial. Everyone knows their estimates are inconsistent. Nobody wants to fix it, because fixing it means confronting how much of their pricing is based on gut feel.
A common pattern: senior estimator opens a blank spreadsheet. Lists the phases. Lists the tasks within each phase. Assigns hours. The hours come from… experience? Memory? A hunch? All of the above, weighted by how much coffee they’ve had.
The output looks precise — “Phase 3: Data Migration, 240 hours” — but the precision is fake. Nobody checked how long data migrations actually took on the last five engagements. Nobody knows if 240 hours includes the inevitable re-work when the source data is messier than expected. The number is a dressed-up guess.
What good estimation looks like: structured service components with historical baselines. Your data migration component has a default range of 200-320 hours, based on the last twelve data migrations you’ve done. Complexity drivers from discovery — source system count, data quality, regulatory requirements — adjust within that range. The estimator still applies judgment, but they’re working from data, not from a blank page.
Stage 3: Proposal — Where Deals Get Mangled
I have a rule of thumb: every manual step between estimation and proposal introduces at least one error. A number gets transposed. A scope item gets dropped. A pricing tier from the last client carries over because someone forgot to update it.
We once sent a proposal to a financial services client with another client’s name in the executive summary. Page three. Nobody caught it until the prospect called to ask who “Meridian Health Systems” was. We did not win that deal.
Beyond the embarrassment factor, the proposal stage is where pricing decisions happen. And pricing is where most firms leak the most margin. The partner decides to discount by 15% to win the deal. The discount comes out of margin, not scope. Nobody tracks whether discounted deals are actually profitable or whether they just create a race to the bottom.
“The proposal isn’t a document. It’s a promise. And most firms build their promises on a foundation of copy-paste and crossed fingers.”
Stage 4: Activation — The Handoff Nobody Designs
Deal closes. Celebration. Then… the delivery team gets a forwarded email. “Hey, we won that thing. Here’s the SOW. Can you set this up?”
The delivery lead opens the SOW. Reads it. Has questions. Goes back to the partner. The partner doesn’t remember the details — they’ve been working on three other deals since then. The delivery lead calls the client to clarify scope, which makes the client nervous because they thought this was all sorted.
Activation is the stage where every shortcut taken in discovery, estimation, and proposal comes home to roost. If the scope is vague, the delivery team has to interpret it. If the estimate doesn’t break down into assignable work, someone has to decompose it from scratch. If the pricing assumed a certain team composition that’s no longer available, someone has to figure out how to deliver with different people at different rates.
A well-managed activation means the delivery team inherits structured context: scope broken into deliverables, estimates broken into assignments, staffing requirements, key milestones, and risk factors identified during discovery. Nobody re-reads the SOW like it’s a mystery novel.
Stage 5: Delivery — The Part You Already Have Tooling For
I won’t spend a lot of time here because this is the stage firms are generally good at. You have PM tools. You track time. You manage resources. You run standups and reviews and retrospectives.
The one thing I’ll say is this: delivery problems are almost never delivery problems. They’re symptoms of problems in stages 1-4 that didn’t surface until work began. Scope creep is usually a discovery failure. Budget overruns are usually estimation failures. Client frustration is usually a proposal that promised something the team can’t deliver at the price quoted.
If your firm keeps fixing delivery and the problems keep coming back, stop looking at delivery. Start looking upstream.
Stage 6: Learning — The Stage That Doesn’t Exist
At most firms, this stage is a fiction. Yes, some teams do retrospectives. Yes, some firms have “lessons learned” templates. But the learning almost never makes it back into the operational systems that need it.
The retro happens. Someone takes notes. The notes go into a shared doc. Nobody reads the shared doc when scoping the next engagement. The same mistakes repeat. The same underestimates happen. The same scope items get missed.
Real learning means actual delivery data — hours versus estimates, margin versus target, scope changes, client satisfaction — feeding back into the estimation and scoping systems. Not into a document. Into the workflow.
When your estimation tool tells you “the last three cloud migrations averaged 15% over the initial estimate, driven by data quality issues,” that’s learning. When a shared doc says “remember to account for data quality” and nobody reads it, that’s theater.
Unpopular Opinion: Retrospectives Are Mostly Performative
I know people love retrospectives. I know they’re supposed to be sacred. And I’m going to say what a lot of people think quietly: most retros are a waste of time.
Not because the conversations aren’t valuable — they usually are. But because the output goes nowhere. Action items get assigned, tracked for a week, then forgotten. Insights get written down and never surface again. The same conversations happen retro after retro because nothing changes in the systems.
A retro that produces “we should estimate data migrations more carefully” is useless unless something in the estimation system changes as a result. A retro that adjusts the baseline hours for data migrations in your service catalog? That’s actual learning. That’s an investment that pays off on every future engagement.
The problem isn’t the retro format. It’s the disconnect between the retro and the operational systems. As long as retro outputs live in documents and operational decisions happen in separate tools (or in people’s heads), the retros are theater.
Case Study Lite: Mapping the Tooling Gap
I worked with a firm that decided to map their actual tooling against the six stages. Here’s what they found:
- Discovery: Salesforce notes (unstructured text fields nobody reads)
- Estimation: Excel spreadsheets (no templates, no historical data, varies by estimator)
- Proposal: PowerPoint + Word (copy-paste from previous proposals)
- Activation: Email (“Hey team, here’s the SOW, let me know if you have questions”)
- Delivery: Jira + Harvest (actual purpose-built tooling)
- Learning: Confluence pages (written once, read never)
They had real systems for one out of six stages. Everything else was cobbled together from general-purpose tools and manual processes. And they were a well-run firm. Profitable. Growing. This wasn’t a dysfunction problem — it was an industry norm that they’d never questioned.
Once they saw it mapped out, the reaction was immediate: “No wonder our estimates are inconsistent.” The gap was right there in front of them.
Why Firms Stay Stuck
If the lifecycle gap is so obvious, why don’t more firms fix it? Three reasons:
First, the pain is distributed. No single person feels the full cost of the gap. The partner who scopes a deal doesn’t feel the delivery overrun. The delivery team that absorbs the overrun doesn’t know why the scope was wrong. The finance team that sees the margin erosion can’t trace it to specific stages.
Second, the tools don’t exist — or didn’t. CRMs handle the front of the pipeline. PSAs handle the back. The middle — scoping, estimation, pricing, proposal — has been a no-man’s land. Firms have used spreadsheets and Word docs because there was nothing better.
Third, it requires admitting the current approach isn’t working. Senior partners who’ve been scoping deals for twenty years don’t love hearing that their process is broken. It’s not a message anyone wants to deliver or receive.
Bottom Line
Take ten minutes tomorrow. Write down the six stages: Discovery, Estimation, Proposal, Activation, Delivery, Learning. Under each one, write what system or process manages that stage at your firm. Not what you wish managed it. What actually does.
If you find real purpose-built tooling for two stages and improvised workarounds for the other four, you’re not behind. You’re normal. But you now have a map of where your margin is leaking.
The firms that close the lifecycle gap don’t do it all at once. They start with the stage that’s causing the most pain — usually estimation or activation — and work outward from there. The key is connecting the stages so data flows through them instead of getting stuck in silos. The compounding effect of connected stages is where the real advantage lives.
Ready to encode your services?
See how Servantium brings CPQ discipline to professional services.