Advisory OS Advisory OS
James Whitfield — Meridian Partners
Constraint Priority Matrix • Session Prep
March 17, 2026
Client GPS
  • Build 1 — Onboarding SOP: Implement (testing with 2 clients)
  • Build 2 — Project status protocol: Design
  • Build 3 — PM tool reconfiguration: Queued
  • Build 4 — Resource visibility dashboard: Queued

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.

Pattern Detection

Patterns Identified
🔁
C1 Recurring (3rd cycle) — Client onboarding has surfaced in three consecutive constraint briefs. Each time it was deprioritized in favor of urgent client fires. This is the third attempt to solve it, and the escalating pattern below shows why it can no longer wait.
📈
C1 Escalating — Average time-to-first-deliverable has grown from 3 weeks to 6 weeks over the last two quarters. Two prospective clients cited slow onboarding in their decision not to proceed with Meridian.
↔️
C2 + C3 Solve Together — Reconfiguring the PM tool (C2) without defining the communication protocol (C3) produces a tool nobody uses consistently. Defining the protocol without fixing the tool produces a process with no infrastructure. Both pass all three Solve Together tests: shared window creates a multiplier that sequential solving would not.
📦
C1 → C4 → C5 Same Root Cause — All three trace back to the absence of a defined onboarding operating system. Without a standard process for how clients enter the firm (C1), there is no structured way to assign resources (C4) or transfer context when consultants rotate (C5). Solving C1 upstream will partially resolve C4 and C5 downstream.

Prioritized Constraints

#1
Client Onboarding Process Not Defined
New clients wait 3–6 weeks before receiving their first deliverable. No standardized intake, scoping, or handoff sequence exists. Each partner and senior consultant improvises their own approach, creating inconsistent client experiences and unpredictable timelines.
Upstream This Week 🔁 Recurring 📈 Escalating 📦 Same Root Cause Ops OS
Tier 1 — Solve This Week

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.

#2
Project Management Tool Configuration Outdated
The firm's PM tool was configured two years ago for a different team size and service model. Current project stages, status labels, and workflow automations do not match how Meridian actually operates. Consultants work around the tool instead of through it.
Upstream ↔️ Solve Together w/ C3 Ops OS
Tier 2 — Queue

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.

#3
Client Communication Protocol Missing
No standard exists for client status updates. Some consultants send weekly emails. Some call when there is news. Some wait for clients to ask. The result: clients experience silence for weeks and then a burst of updates, eroding confidence in the firm's organization.
Upstream ↔️ Solve Together w/ C2 Ops OS
Tier 2 — Queue

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.

#4
Resource Allocation Visibility Gap
James does not know who is working on what at any given time. Resource allocation is managed informally through hallway conversations and partner memory. When a new client signs, there is no way to assess team capacity without asking every senior consultant individually.
⬇️ Downstream 📦 Same Root Cause Queue Ops OS
Tier 3 — Monitor

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.

#5
Knowledge Transfer Between Consultants
When consultants rotate off a project or leave the firm, client context is lost. There is no handoff protocol, no project documentation standard, and no structured way to bring a new consultant up to speed. Clients experience this as starting over.
⬇️ Downstream 📦 Same Root Cause Queue Ops OS
Tier 3 — Queue

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.

Visual Matrix

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
⬆️ Upstream (solve first) ⬇️ Downstream (find cause) 🔁 Recurring 📈 Escalating 📦 Same Root Cause ↔️ Solve Together

Session Prep

Session Prep — James Whitfield
Monday, March 17, 2026
Recommended Focus
C1 — Client Onboarding Process Not Defined
Review pilot results from the 2-client SOP test. Identify what worked, what broke, and what needs to change before expanding to all new clients.
Why This One
  • 3rd cycle recurring: This constraint has been identified and deprioritized twice before. The pattern of deferral is itself a constraint — breaking it now signals a shift in how Meridian operates.
  • Escalating impact: Time-to-first-deliverable has doubled. Two lost prospects cited slow onboarding. The cost of waiting is no longer theoretical — it is measurable in lost revenue.
  • Upstream leverage: C1 is the root cause of C4 (resource visibility) and C5 (knowledge transfer). Solving C1 partially resolves two Tier 3 constraints without additional builds.
Pre-Work Needed
James: Bring specific feedback from the 2 pilot clients. What did they experience during onboarding? Where did they wait? What questions did they have that the SOP did not answer?

Kathryn: Review pilot SOP against the original intake-to-first-deliverable timeline. Identify the steps where delays occurred and prepare 2–3 recommended adjustments.
Questions to Ask
  • Of the 2 pilot clients, how many days elapsed between signed agreement and first deliverable? How does that compare to the 10-business-day target?
  • Where in the onboarding sequence did the longest delay occur — intake, scoping, resource assignment, or deliverable production?
  • Did the consultants assigned to the pilot clients follow the SOP as written, or did they modify steps? If they modified, what did they change and why?
  • What is the current pipeline of new clients expected in the next 30 days? Is there time to iterate on the SOP before the next cohort arrives?
  • When the SOP is working, what does James want his role to be in onboarding — approval gate, informed observer, or fully delegated?
Capability Category
Ops OS — Standardized SOP deployment. Build the onboarding operating system as a repeatable process: intake, scoping, assignment, deliverable, and feedback loop. Structure first, then automate.
Pattern to Surface with Client
This is the third time onboarding has been identified as the top constraint. The first two times, it was deprioritized because urgent client work took precedence. The pattern itself is diagnostic: the firm keeps choosing reactive work over building the system that would prevent reactive work. Now that Build 1 is in Implement with real pilot data, this is the first time Meridian has tangible evidence that solving C1 is possible — not theoretical. Use the pilot results to demonstrate that the SOP works, then connect it forward: C2 and C3 (Solve Together) become actionable once C1 is proven, and C4 and C5 begin to self-resolve.

Brief History

February 2026 — Meeting Structure
Internal meetings consumed 12+ hours per week with no agendas, no decisions logged, and no follow-up tracking. Partners attended every meeting regardless of relevance. Solution deployed: Async update protocol — eliminated 60% of recurring meetings, replaced with structured written updates. Remaining meetings require a pre-circulated agenda and produce a decision log within 24 hours.
Solved Ops 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.