| name | canonical-project-orchestration |
| description | Drive extreme clarity in complex, cross-functional projects by establishing a single source of truth, shared vocabulary, and structured decision frameworks. Use this when launching high-stakes initiatives, resolving stakeholder misalignment, or taking over "gnarly" projects where information is fragmented. |
Canonical Project Orchestration
Complex projects often fail not due to bad strategy, but due to "context fragmentation"—where different stakeholders have different understandings of the same facts. This framework eliminates misalignment by enforcing a "canonical" environment where every word, document, and decision is standardized.
1. Create the Canonical Document
The Canonical Doc is the one place anyone can go to get all information about a project. It must link to all sub-docs, but remain the primary entry point.
Required Components:
- Workstreams: Define the discrete areas of work.
- Single-Threaded Owners (STOs): Assign one specific person to every workstream and sub-workstream. There must be one "throat to choke" for every deliverable.
- Process Mechanics: List the canonical meeting times, the canonical email alias, and the one canonical chat channel. Explicitly forbid creating "permutation" chats that exclude key stakeholders.
- The "School Pyramid": Break the project down into curriculums. Start with the "Kindergarten" level (basic building blocks) before moving to PhD-level technical details. Ensure every stakeholder understands the Kindergarten level before proceeding.
2. Enforce Extreme Clarity
Clarity is achieved when everyone is on the same page, even if they don't agree.
- Canonical Nomenclature: Define your terms. Write out a glossary if necessary.
- Example: Explicitly define the difference between "Consistency" (how often reviewers agree) and "Accuracy" (how often the decision is correct against ground truth).
- Numbered Lists Only: Never use bulleted lists. You cannot easily refer to a "bullet" in a meeting. Numbered lists allow for precise feedback (e.g., "I have a concern with item number four").
- Visual Real-Time Editing: Never leave a meeting with "verbal agreements." Project the document or slide and edit the text in real-time. Add a star next to the chosen option and document the "Next Steps" while everyone is watching.
3. The Traffic Light Decision Framework
When presenting a decision to leadership or a cross-functional group, use a "Traffic Light" visual instead of a list of pros and cons.
The Structure:
- Rows: Present exactly three options (Option A, B, and the Recommendation).
- Columns: List the criteria for evaluation (e.g., Legal, Privacy, Engineering Feasibility, User Impact).
- Cells: Use color-coding (Red, Yellow, Green) to show how each option stacks up against the criteria.
- The Recommendation: Always provide a clear "Recommended Option" with the rationale for why its "Greens" outweigh its "Reds."
Examples
Example 1: Resolving a "Gnarly" Launch
- Context: A project involving 10+ teams (Legal, Policy, Product, Eng) is stalled because everyone is using different terms for "User Safety."
- Application: Create a Canonical Doc. Establish "Canonical Nomenclature" that defines "Safety" vs. "Privacy." Assign an STO to the "Age Verification" workstream.
- Output: A single URL that holds the schedule, the STO list, and the "Traffic Light" table for the final go/no-go decision.
Example 2: Moving from PhD to Kindergarten Level
- Context: An AI project is so technical that stakeholders from Marketing and Policy cannot follow the updates.
- Application: Use the "School Pyramid" approach. Re-write the executive summary as a "Kindergarten curriculum" that explains the basic model inputs before discussing the "PhD-level" optimization weights.
- Output: Stakeholder alignment and faster approval cycles because the non-technical team members finally understand the trade-offs.
Common Pitfalls
- Accepting Pairwise Conversations: Avoid hashing out details in 1:1s that change the project direction. Move those conversations to the "Canonical Chat" so everyone has the same context.
- Assuming Execution equals Strategy: If a project fails, you need to know if the strategy was wrong or the execution was poor. Perfect the execution (via the Canonical Doc) so you can accurately judge the strategy.
- Over-complicating the First-Read: If you send a pre-read less than 24 hours before a meeting, cancel the meeting. You cannot have extreme clarity if half the room hasn't processed the data.
- Failing to Recurse: For large projects, ensure the sub-workstreams also have their own (linked) Canonical Docs and STOs. Clarity must "recurse" all the way down.
