The Workflow Is Not Broken. It Is Executing the Price.

The overwork, the scope creep, the thin margins. Most of it was decided before delivery ever started.

Wednesday's load test put five questions to your H2 plan. The one that tends to sting is the capacity question: which line item assumes capacity you do not have?

Here is where that capacity usually went. It is already consumed, executing engagements that were priced underwater before the first hour of delivery was logged.

That is worth slowing down for, because it changes what kind of problem you have.

Three problems that look operational

Ask the founder of a small services firm what hurts, and you usually hear some mix of the same three things.

Chronic overwork. The team runs hot all the time. Evenings and weekends have become part of the plan, even though nobody put them there.

Permanent scope creep. Engagements grow past their boundaries so reliably that the growth stops feeling like an exception. It is just how projects go here.

Margin squeeze. The work gets done, clients are reasonably happy, and there is still less left over than the spreadsheet promised.

All three present as operations problems. They feel like process problems, so they get process fixes. Better project management. Tighter handoffs. A new tool, a firmer kickoff checklist.

And the fixes rarely hold, because in most cases these problems were not created in delivery at all.

Priced in before the work began

They were created earlier, in the scope and price conversation, before anyone touched the work.

When an engagement is priced too low or scoped too loosely, the delivery team inherits a closed commitment: this much work, for this much money, by this date. The operation does not get a vote. So it does what a loyal operation does. It absorbs.

The absorption has familiar names. The missing hours come out of nights and weekends, which is overwork. The boundary the price never defended cannot be held by delivery either, which is scope creep. The gap between what was promised and what was charged comes out of the bottom line, which is margin squeeze.

Here is the uncomfortable part. Usually nobody decided any of this on purpose. The price was set under deal pressure, or anchored to last year, or to what the client seemed willing to pay. The scope stayed vague because pinning it down felt like friction in a sale that was finally going well. A pricing decision got made by default, and the operation has been faithfully executing it ever since.

That is why no process redesign can fix these problems. You cannot redesign a workflow out of a commitment the workflow never made.

This is not the wrong-layer problem

Earlier this spring we wrote about what it costs to keep diagnosing the wrong layer. That piece was about misdiagnosis: a problem lives on one layer of the business and gets treated on another, so the fix never lands.

This is a different situation, and a stranger one. Nothing here is being misdiagnosed, because nothing is malfunctioning. The delivery system is doing exactly what it was built to do: deliver the promised scope at the agreed price, whatever that takes. The system is working as designed.

The design was just accidental. Nobody sat down and chose a business where the team donates its evenings to subsidize the fee. That design emerged, one underpriced engagement at a time. The workflow is not broken. It is executing the price.

Three questions that find the layer

When a problem keeps coming back no matter what you fix, it is worth asking which layer it actually lives on. Three questions usually settle it.

Does the problem appear on every engagement, or only some? Workflow problems tend to be uneven. They cluster around certain project types, certain handoffs, certain people. A problem that shows up on nearly every engagement, regardless of client or team, is usually structural. Pricing is the first structure worth checking.

Did the problem exist before delivery started? Go back to the scope and price conversation. If the hours could never have fit inside the fee, the overwork was scheduled the day the proposal was accepted. Delivery just made it visible.

Would a perfect process still lose money at this price? Imagine flawless execution: no rework, no waiting, no dropped handoffs. If the engagement still does not pay for the work it requires, the problem is not in the process, and no amount of redesign will move it.

To be clear, this is not the usual advice. The usual advice is raise your rates, and sometimes that is right. But it skips the diagnostic. A pricing fix applied to a genuine workflow problem fails exactly as often as the reverse. The point of the three questions is narrower and comes first: know which layer the problem lives on before you change anything.

If your answers point at the pricing layer, there is a hard piece of news and an easier one. The hard piece is that the fix is a different kind of conversation than a process fix, and it happens with clients, not with tools. The easier piece is that it is a conversation you control. It is far cheaper to have it on paper, before the next engagement is signed, than to keep absorbing it in delivery for months afterward.

Continue the series

This is part 4 of a 5-part series on Load-Test the Plan. Then Look at the Price.. The full arc:

• Monday: Your H2 Plan Is a Forecast of Your Bottleneck
• Tuesday: The Line You Copied From January
• Wednesday: The 15-Minute H2 Load Test
• Thursday: The Workflow Is Not Broken. It Is Executing the Price. (this post)
• Friday: Utilization Is High Because Pricing Is Broken

Content and Accuracy Disclaimer

This article was drafted with AI assistance and reviewed by the Altvina team. We rigorously fact-check all content to ensure reliability.

Should you notice any inaccuracies or outdated information, please contact us so we can correct it. Your feedback helps us maintain high standards of accuracy and transparency.