90% of new clients receive their first deliverable within 10 business days. Every active project has a visible status. James reviews a dashboard instead of orchestrating.
Accelerating. First onboarding SOP tested with 2 clients this week. Build 2 in active design. Momentum is real for the first time since engagement started.
Directly blocks James's goal of 90% of new clients receiving first deliverable within 10 business days. Current state is 3–6 weeks. Without a defined onboarding process, no amount of downstream fixes will close that gap.
Every week this sits: new clients form their impression of Meridian during the silence. Two prospects already cited slow starts in their decision to go elsewhere. The firm is losing revenue it already won.
Tier 1 because it is upstream of C4 and C5, recurring across 3 cycles, and escalating. This is the root cause constraint. Solving it creates the structural foundation that makes C2–C5 solvable or self-resolving.
Ops OS — Build a standardized client onboarding SOP: intake form, scoping checklist, resource assignment protocol, and first-deliverable timeline. Deploy with 2 pilot clients this week. Iterate based on pilot feedback before firm-wide rollout.
Blocks the goal of every project having a visible status. If the tool does not reflect actual workflow stages, no dashboard built on top of it will be accurate. James cannot review what the system does not track.
Each week the tool stays misconfigured, consultants maintain their own tracking systems (spreadsheets, notes, memory). Every workaround increases the cost of eventual migration and deepens the habit of working outside the system.
Tier 2 because it is upstream and high-impact, but depends on C1 defining the onboarding workflow first. The tool must be reconfigured to match the new process, not the old one. Solve Together with C3 — the tool and the communication protocol are two halves of the same operating layer.
Ops OS — Audit current PM tool configuration against actual workflow. Map new project stages, status labels, and automations to match the onboarding SOP (once deployed). Reconfigure in a staging environment, test with one project, then migrate.
Directly blocks the visible-status goal. Even if the PM tool is reconfigured, clients do not log in to check project status. A communication protocol is the delivery mechanism for visibility — it is how the client experiences the system.
Every week without a protocol, James fields ad-hoc client inquiries that his team should be handling proactively. His time is consumed orchestrating instead of advising — the exact pattern he wants to eliminate.
Tier 2, secondary to C2. The protocol needs the tool infrastructure to automate and enforce it. Solve Together with C2 because building the protocol without the tool creates manual overhead, and fixing the tool without the protocol creates infrastructure nobody uses consistently.
Ops OS — Define a standard client communication cadence (weekly status email, milestone alerts, escalation triggers). Build the protocol to generate from PM tool data so updates are system-driven, not memory-driven. Deploy alongside C2 tool reconfiguration.
Blocks James's goal of reviewing a dashboard instead of orchestrating. Without visibility into who is allocated where, he remains the central coordinator — the bottleneck he is trying to remove.
Low independent cost while C1 is unsolved. Once onboarding is standardized and the PM tool is reconfigured, resource visibility becomes solvable through tool configuration rather than a separate build. Premature investment here would build on a broken foundation.
Tier 3 because it is downstream of C1 and C2. A standardized onboarding process (C1) creates predictable resource needs. A properly configured PM tool (C2) makes those assignments visible. This constraint is expected to partially self-resolve as upstream systems deploy.
Ops OS — Monitor during C1 and C2 deployment. Once onboarding SOP and PM tool are live, assess remaining gap. Likely solved by adding a resource allocation view to the reconfigured PM tool rather than building a separate system.
Threatens the 10-business-day deliverable goal indirectly. If a consultant rotates mid-engagement, the new consultant spends weeks reconstructing context instead of delivering. The client's experience resets to zero.
Moderate but deferred. Knowledge transfer failures happen at transition points, not continuously. The cost is real but episodic. Solving C1 and C2 first creates the documentation infrastructure that makes knowledge transfer possible.
Tier 3, queued behind C1 and C2. A defined onboarding process (C1) creates standardized project documentation. A configured PM tool (C2) stores that documentation in a findable location. Knowledge transfer becomes a protocol layer on top of existing infrastructure, not a standalone build.
Ops OS — Queue until C1 and C2 are deployed. Then design a knowledge transfer protocol: project handoff checklist, required documentation standard, and structured transition meeting format. Build on the documentation created by the onboarding SOP and stored in the reconfigured PM tool.
| Capability | This Week | Queue |
|---|---|---|
| Authority OS | — | — |
| Ops OS | Client Onboarding Process | PM Tool Configuration Communication Protocol Resource Allocation Visibility Knowledge Transfer |
| Visibility OS | — | — |
| Prospecting OS | — | — |
| Services OS | — | — |
| Product OS | — | — |
Connection: The async update protocol solved internal communication structure. C3 (Client Communication Protocol Missing) is the external-facing equivalent — same pattern of unstructured communication, different audience. The internal solve provides a template for the client-facing protocol.