Your sales lead remembers the scope one way. The project manager who got the WhatsApp message remembers it another. The ops director, who heard about it in the Monday standup, is working from a third version stitched together from a forwarded email and two voice notes.
Nobody lied. Nobody was careless. The information just lived in too many places at once — and by the time execution started, the original signal was already corrupted.
This isn't a communication problem. It's what happens when a business that sells projects tries to scale on systems designed for a different kind of work.
Most project businesses grew up informal. The founder knew every client. The team was small enough that a quick conversation covered everything. When a deal closed, the person who sold it usually helped deliver it. Context didn't need a system — it lived in people's heads.
That model works. Until it doesn't.
The break point isn't a specific revenue number or headcount. It's the moment when the business has more active projects than any one person can hold in their head at once. When a new hire can't get up to speed by sitting next to the right person for a week. When a client asks for a status update and the honest answer requires a meeting to find out.
At that point, informal operations don't just create inconvenience. They start destroying margin.
The visible symptoms are easy to name: missed deadlines, scope creep, client complaints. But the real cost is quieter and harder to trace.
It shows up in rework. A deliverable gets built to the spec that ops received, not the spec the client approved — because those two things were never the same document. The difference gets caught at delivery, not at kickoff. Now someone eats three days of work to close the gap.
It shows up in your best people's time. Your senior project manager spends forty minutes every Monday reconstructing the current state of five projects by calling three people and reading through message threads. That's not management — that's archaeology. And it happens every week, on every project, across the whole team.
It shows up in deals you don't know you're losing. A client who felt like communication was "a little off" during the project doesn't renew. They don't write a bad review. They just don't come back. The reason never makes it into a postmortem because there was no postmortem — the project closed, everyone moved on, and the signal died with it.
None of this appears as a line item. It's absorbed into the general friction of running the business. But it compounds.
Most project businesses at this stage don't have zero tools. They have too many, poorly connected.
There's a CRM that sales owns. A project management platform that ops lives in. A finance system that accounting uses to close the books. Possibly a shared drive with proposal templates, a Slack workspace with fifty channels, and a set of spreadsheets that someone built three years ago and everyone is afraid to touch.
Each tool works fine in isolation. The problem is the gaps between them.
When a deal closes in the CRM, nothing automatically moves to the project management tool. Someone has to do that manually — and manually means inconsistently, which means sometimes it happens and sometimes it doesn't, and the only way to know which is to ask. When costs come in against a project, they live in finance and nowhere else, so the project manager making scope decisions has no idea whether they're on budget or not. When a client sends a change request, it arrives in someone's email and gets handled wherever that person decides to handle it — which might be the CRM, might be a Slack message, might be a sticky note that eventually ends up in a shared doc.
The data exists. It's just fragmented across enough places that no one can actually use it.
The difference isn't complexity — it's continuity.
When a deal closes, the project brief, the signed scope, and everything documented during the sales process moves to the delivery team in a structured handoff. The project manager doesn't reconstruct the context from memory or from a chain of forwarded messages — they open the record and it's there.
When the project is live, the commercial lead can see status, costs logged to date, and any flagged issues without asking ops. Not in a dashboard that requires a separate login — in the same place where the deal lives.
When something changes, the change request has a home. It gets logged, reviewed, approved or declined, and either way the record reflects what happened. Six months later, when a client says "but I thought we agreed on X," there's a clear answer.
This isn't an idealized version of how project businesses could work. It's how they do work when the operational architecture is designed for the way they actually sell and deliver — where the project doesn't start fresh in a new system every time a contract gets signed.
The informal systems that got the business to this point aren't going to get worse next year. They're already as bad as they're going to get — until the business grows again.
Every quarter of growth at this stage without fixing the architecture means another quarter of compounding rework, another quarter of margin absorbed by coordination overhead, another quarter of good clients quietly deciding not to come back.
The projects don't get simpler. The team doesn't get smaller. The number of things that need to be tracked only goes in one direction.
If you're running a project business and you're starting to feel the edges of what informal operations can hold — SAP ASAP builds the operational architecture that connects the full cycle, from the moment a deal closes to the moment a project does. You can see exactly how it works before committing to anything at sap-asap.mx/forcompaniesthatsellprojects.