Brainforge Knowledge

operating-allocation-audit-2026

8 min read

Operating Audit And Allocation System Plan

Goal

Create a practical delivery operating model where operating.app remains the near-term source of truth for allocations, but its live assignment data is audited, operationally owned, and mirrored into a shared database/reporting layer so leaders can trust it daily.

What We Know From Current Context

  • Existing delivery doctrine already says systems of record must reflect reality and that leadership sync should review cross-account risk and capacity. See knowledge/delivery/04-standards-and-sops/consolidated-delivery-standards.md, knowledge/delivery/01-roles-and-responsibilities/service-lead/ic-management-guide.md, and knowledge/delivery/02-meetings-and-cadence/weekly-leadership-sync.md.
  • Current pain appears to be stale or inconsistent allocation data, limited permissions/admin bottlenecks, and unclear ownership for keeping hours current. This shows up in recent allocation and ops transcripts, including knowledge/clients/unassigned/transcripts/2026-03-12_pranav_-_brylle_-_abc_allocations_monthl_246fecaf.md, knowledge/clients/unassigned/transcripts/2026-03-18_abc_roadmap_and_allocations_final_check-_6b174ec2.md, and knowledge/clients/unassigned/transcripts/2026-03-17_operations_weekly_sync_809a4ba4.md.
  • The active operating-model work already includes delivery systems-of-record framing and an operating page/roster artifact in knowledge/plans/active/delivery-folder-restructure-and-operating-model-plan-2026.md and knowledge/plans/active/delivery-charter-rubric-operating-model-2026.md.

Proposed Operating Model

  • Keep operating.app as the near-term write system for allocations.
  • Service Lines & Sub-services: Brainforge has 3 service lines (AI, Data, Strategy & Analytics), each with sub-services. An SL owns sub-service allocations and staffing.
  • Client Allocation Ownership: Each client has a CSO (client narrative, plan, external commitments) and an SL (technical truth, delivery execution). Some clients have a combined CSO/SL role (e.g., Zoran for Amble, Demilade for Magic Spoon).
  • Service Leads maintain service-level IC allocations inside Operating for their sub-service line.
  • CSOs confirm client/workstream demand, upcoming changes, and priority shifts that drive allocation changes.
  • Head of Delivery owns policy, audit cadence, exception handling, and portfolio-level capacity decisions.
  • Mirror allocation data from Operating into a shared database for visibility, QA, and downstream reporting.

Note on roles: Engagement Planner (EP) was sunset after Q1 2026. The CSO/SL partnership is the core delivery model, with some clients having a single person in both roles.

Ownership Design

Service Line Layer (Sub-service Ownership)

  • Service Lead (SL): Owns allocations for their sub-service line. Updates and confirms named IC allocations, weekly-hour targets, service assignments, and known upcoming changes for their roster. Each sub-service (e.g., “Workflow Automation” under AI, or “Data Infrastructure” under Data) has an assigned SL who acts as the DRI for staffing.

Client Layer (Per-Client Ownership)

  • Client Success Owner (CSO): Owns the client narrative, plan, and external commitments. Confirms which clients/workstreams are active, expected over the next 2-6 weeks, and whether requested capacity matches plan reality. Drives allocation changes based on client priorities.
  • Service Lead (SL): Owns technical truth and delivery execution for the client. Maintains IC-level allocations and ensures the “story matches build.”
  • Combined CSO/SL: Some clients have a single person owning both roles (e.g., Zoran for Amble, Demilade for Magic Spoon). This person must explicitly switch hats when confirming client demand vs. technical allocations.

Infrastructure & Governance Layer

  • Ops or Systems Owner: runs sync job, data-quality checks, and exception queue for missing, stale, or conflicting records.
  • Head of Delivery: reviews exceptions and uses weekly leadership sync to resolve portfolio conflicts or under/over-allocation across service lines.

Daily And Weekly Cadence

  • Daily: SLs update IC allocation changes in Operating before a fixed cutoff; sync job copies current state into the shared database; exception report flags stale or invalid records.
  • Daily: CSOs review client-level changes and exceptions, confirming demand matches plan reality. For combined CSO/SL clients, the single owner reviews both layers.
  • Weekly: SLs confirm sub-service roster integrity; CSOs confirm client narrative accuracy.
  • Weekly: leadership sync uses the mirrored database to review portfolio capacity, conflicts, PTO impact, and accounts with allocation drift—especially highlighting combined CSO/SL clients where a single person manages both layers.
  • Monthly: audit actual time usage vs planned allocation to refine trust in the model; review service line capacity trends and identify where Operating discipline is weak.

Audit Workstream

  1. Inventory current Operating objects, fields, permissions, update paths, and who can edit what.
  2. Audit CSO/SL assignment completeness: For every client project, verify both CSO and SL are assigned. Flag clients with missing CSO or SL assignments (e.g., “LMNT Analytics” shows no project owner in Operating).
  3. Audit combined CSO/SL roles: Identify which clients have a single person as both CSO and SL (Amble, Magic Spoon). Document the risk and mitigation.
  4. Audit service line taxonomy: Map how service lines and sub-services are (or aren’t) represented in Operating. Identify gaps between the GTM service hierarchy and Operating data.
  5. Pull a current-state snapshot of allocations and compare it against known reality from active client plans, Linear ownership, and recent leadership discussions.
  6. Classify issues by type: stale hours, missing assignments, wrong service owner, missing CSO/SL assignments, permission bottlenecks, duplicate/conflicting records, and missing future-dated changes.
  7. Define the minimum viable truth model for live assignment: person, service line, sub-service, client/workstream, role (CSO/SL/IC), hours/week, effective dates, status, owner, and last-confirmed timestamp.
  8. Produce a remediation backlog split into process fixes, permission fixes, and integration/data fixes.

Shared Database Design

Use a simple replicated schema first, with history and auditability. Must support the 3-layer model: Service Lines → Sub-services → Clients.

flowchart LR
operating[OperatingApp] --> syncJob[SyncJob]
syncJob --> allocationDb[AllocationDatabase]
allocationDb --> qaView[QAAndExceptionViews]
allocationDb --> leadershipView[LeadershipCapacityViews]
allocationDb --> downstream[DashboardsAndInternalTools]
sl[ServiceLeads<br/>Sub-service Owners] --> operating
cso[CSOs<br/>Client Narrative] --> operating
opsOwner[OpsOrSystemsOwner] --> qaView
hod[HeadOfDelivery] --> leadershipView

Core tables/views to plan for:

  • people — all ICs, CSOs, SLs with their primary role and service line affiliation
  • clients — client engagements with CSO and SL assignments
  • service_lines — the 3 lines: AI, Data, Strategy & Analytics
  • sub_services — sub-service groupings (e.g., “Workflow Automation” under AI)
  • sub_service_ownership — which SL owns which sub-service
  • allocations_current — live assignments
  • allocations_history — point-in-time snapshots
  • allocation_exceptions — stale, missing, or conflicting records
  • capacity_summary_by_person — availability vs. allocated hours
  • capacity_summary_by_client — client-level capacity view
  • capacity_summary_by_service_line — service line-level view

Essential fields:

  • person id/name
  • service line (AI/Data/Strategy)
  • sub-service (for SL ownership)
  • client or workstream
  • role on assignment (CSO, SL, IC role)
  • hours per week or allocation percentage
  • start date / end date
  • active status
  • CSO assigned to client
  • SL assigned to client
  • source system record id
  • last synced at
  • last confirmed by
  • stale flag / validation status

Special handling: For combined CSO/SL clients, store both roles explicitly in the database even if the same person holds them.

Key Policy Decisions To Encode In Docs

  • One clear writer per allocation record, even if multiple people inform it.
  • Every client must have a CSO and SL assigned, even if the same person holds both roles.
  • Combined CSO/SL roles should be documented as a risk to be mitigated (single point of failure, conflicting incentives).
  • SLs own sub-service allocations; CSOs own client demand confirmation. When one person holds both, they must explicitly “switch hats.”
  • Future changes should be entered with effective dates, not remembered in Slack.
  • Unknown or tentative staffing should be explicit and labeled, not hidden in notes.
  • If Operating and lived reality diverge, the issue is not reporting; it is a delivery control failure.
  • Weekly leadership review should use exception-based reporting, not manual round-robin status collection.

Likely Repo Outputs

  • Update knowledge/delivery/01-roles-and-responsibilities/service-lead/role-definition.md to explicitly include sub-service allocation ownership and the CSO/SL partnership model.
  • Update knowledge/delivery/01-roles-and-responsibilities/service-lead/ic-management-guide.md with daily/weekly allocation-maintenance expectations for sub-service rosters.
  • Update knowledge/delivery/01-roles-and-responsibilities/cso/role-definition.md to clarify CSO allocation responsibilities and the combined CSO/SL scenario.
  • Update knowledge/delivery/00-head-of-delivery/expectations-by-cadence.md to add portfolio allocation audit/review expectations by service line.
  • Add or expand a lifecycle/systems-of-record doc under knowledge/delivery/03-project-lifecycle/ to define Operating vs shared database roles, including the 3 service line structure.
  • Document the combined CSO/SL pattern: when it happens, how to mitigate risk, and escalation paths.

Execution Sequence

  1. Audit current Operating setup and access model.
  2. Audit CSO/SL assignments: Identify every client project, confirm CSO and SL assignments, flag gaps, and document combined CSO/SL clients.
  3. Audit service line mapping: Map the GTM service hierarchy (3 lines, sub-services) to Operating data. Identify where service line information lives (or doesn’t).
  4. Define the source-of-truth data model and owner matrix (CSO/SL/service line/sub-service/IC).
  5. Design the sync path from Operating into a shared database.
  6. Define exception reporting and leadership review workflow by service line.
  7. Update delivery docs so role ownership (CSO/SL) and cadence are explicit, including combined role guidance.
  8. Prioritize the implementation backlog for process, permissions, and integration work.

Success Criteria

  • Every live allocation has a named owner, effective dates, and a last-confirmed timestamp.
  • Every client project has both a CSO and SL assigned (even if the same person holds both roles).
  • SLs know exactly what they must update daily versus weekly for their sub-service roster.
  • CSOs know exactly what they must confirm daily/weekly for client demand and narrative.
  • Combined CSO/SL clients have explicit role clarity and escalation paths.
  • Service line and sub-service taxonomy is queryable in the shared database.
  • Head of Delivery gets exception-driven portfolio visibility by service line and client.
  • Allocation data is queryable outside Operating without waiting for a future replacement.
  • Operating can remain the write surface for now without blocking broader access and reporting.

Graph View