CM Projects Database — PM Design System

The Core Principle

Properties are for filtering, sorting, and decisions. Body is for narrative, context, and depth. Robert needs to make decisions in milliseconds at the overview level — that's what properties are for. When someone opens a project page, they need the full story: the why, the what exactly, and what was learned. That lives in the body. This prevents two failure modes: property bloat (impossible to scan) and lost institutional knowledge (decisions made in Slack and forgotten).

Field Design — What Lives Where and Why

Field	Type	Status	Purpose / Rationale
Name	title	Keep	Project name. Should be scannable at a glance — not a task, not a sentence, just a clear project identifier.
Client	relation	Keep	Links to the Clients database. Every decision flows from client context. Enables per-client filtering and rollups.
Status	select	Keep	Robert's primary decision filter. `active → stalled → planned → parked → completed → failed`. Drives board views.
Phase	select	New ✓	Where the project sits in its lifecycle: Discovery → Planning → Design → Development → Review → Launch → Optimization → Maintenance. Tells the team what kind of work is needed right now.
Priority	select	Keep	Critical / High / Normal / Low / Someday. Combined with Status, answers "what needs Robert's attention first."
Type	select	Keep	Project / Campaign / System / Product / Maintenance / Research. Determines execution playbook and risk profile.
Assigned To	people	Keep	Single point of accountability. The person responsible for moving this project. Team knows who to ask, Robert knows who to follow up with.
Start Date	date	Keep	Anchors all time-based decisions. Required for timeline views and dependency chains.
Deadline	date	Keep	Target completion date. Creates urgency signals. Enables "what's due in 2 weeks?" filtering. Critical for client communication.
Last Status Update	date	New ✓	Date of last meaningful update. Reveals stale/ghost projects. If this date is >2 weeks ago and Status is active — needs attention.
Next Action	rich_text	Keep	GTD practice field. What is the single next action to move this project forward? If unclear, execution stops.
Description	rich_text	Keep	One-liner scope summary (<150 chars). Not full narrative — that lives in the body. This is for scanning in list view.
Success Criteria	rich_text	New ✓	How will we know this project succeeded? Shape Up practice. Without this, "done" is ambiguous. A project without defined success criteria cannot be called complete.
Blocking Issues	rich_text	New ✓	Active blockers, risks, and dependencies preventing progress. If non-empty, this project is stalled or at risk. Used to drive the Blockers view.
Billable	checkbox	New ✓	Is this a client-billable project? Unchecked = internal CM or 16Fold work. Used to separate revenue work from overhead in views and reporting.
Budget	number ($)	Keep	Allocated budget in dollars. Foundation for financial health visibility.
Total Billable	rollup	Keep	Auto-calculated from linked Time Entries. Real profitability signal. "Are we losing money on this?"
Total Hours	rollup	Keep	Auto-calculated from linked Time Entries. Capacity and estimation reference.
Tasks	relation	Keep	Links to the Tasks database. All tasks for this project live there. Do NOT manage tasks in the project body — use this relation.
Time Entries	relation	Keep	Links to the Time Entries database. Source of truth for hours and billing.
Private	checkbox	Keep	Flag for confidential projects not shared with full team.

⚠ Two Fields to Ignore (Cannot Be Deleted via API)

Task Completion — the rollup is misconfigured. It shows "Assigned To" names instead of a completion percentage. Until Notion adds a "count of completed vs total tasks" formula rollup option, this field is non-functional noise. Hide it from all views. It can only be deleted manually in Notion.

Dependencies — free text with no enforcement. Was replaced conceptually by Blocking Issues (what's stopping us) which is more actionable. Hide from views. Can only be deleted manually in Notion.

Project Template Body Structure

Every project page should follow this structure. The template has been updated in Notion. Use it every time.

📋 Project Brief

What is this project and why does it exist? 2-4 sentences. If you can't explain it in 2-4 sentences, the scope isn't clear enough to execute.

✅ Success Criteria

3 bullet points. What does "done" look like? What are the measurable outcomes? What's the client sign-off condition? Without this, the project never officially ends.

🔲 Scope (In / Out)

Two callout blocks — what's included, what's explicitly excluded. Every unresolved scope item becomes a change order. Document it here before work starts, not after.

🚧 Blocking Issues

Active blockers and dependencies. If green = project is clear to run. Update this whenever something changes. This feeds the Blockers view Robert checks weekly.

📌 Tasks

Pointer to the linked Tasks relation. Don't list tasks in the body — create them in the Tasks DB and link to this project via the Tasks relation above.

🗒 Decisions & Notes Log

Dated bullets. Every major decision, client feedback, pivot, or lesson learned. This is the institutional memory — it's why you don't repeat mistakes or ask the same questions twice.

🔗 Key Links & Assets

Brief/SOW, live deliverable URL, client approval thread, vault folder path. Everything someone needs to find the work without asking.

Recommended Views

Build these views in Notion. Each serves a specific meeting or workflow — not just "different ways to look at the same data."

🎯 Active Projects kanban

Group by Status. Filter out completed/failed. Sorted by Priority. Primary daily view. Drag projects between columns to update status. Standup-ready.

📊 Project Health table

Shows: Name, Client, Status, Phase, Priority, Assigned To, Deadline, Blocking Issues. Sorted by Priority. Weekly team review view. Everything on one screen.

🚨 Blockers table

Filters to only projects where Blocking Issues is not empty. Sorted by Priority. Triage view. If you're in this view, something needs resolving today.

💰 Budget Tracking table

Filter: Billable = checked. Group by Client. Shows Budget, Total Billable, Total Hours. Monthly billing review. Spot over-budget work before it becomes a conversation.

📅 Timeline (by Phase) table

Group by Phase. Shows Start Date, Deadline, Assigned To. Filter out completed. Planning view. Tells you if too much is stuck in Development or Review.

🏠 Internal Work table

Filter: Billable = unchecked. Shows CM and 16Fold projects separately from client work. Overhead visibility. How much non-revenue work is the team carrying?

✅ Completed Archive table

Filter: Status = completed. Sorted by Last Status Update descending. Shows Total Hours, Total Billable, Budget. Revenue and retrospective reference.

How to Use This for Each Project Type

Client Retainer Work (ICON, Toft, Meadow Green, TRC)

Type = project or campaign | Billable = ✅ | Phase tracks where the monthly deliverable cycle sits. Status = active until retainer ends. Next Action = what's due this week.

Website / Technical Builds (Terry's Marine, Ken deliverables)

Type = project | Phase is critical here — Discovery → Planning → Design → Development → Review → Launch. Blocking Issues flags client delays (waiting on content, assets, approvals). Success Criteria = "site live, client signed off, traffic baseline set."

Paid Ad Campaigns (ICON Meta, etc.)

Type = campaign | Billable = ✅ | Budget field is ad spend allocation. Phase = Launch → Optimization (campaigns are never "done"). Success Criteria = specific ROAS or CPA targets.

Internal Systems (16Fold, The Machine, Hermes crons)

Type = system | Billable = unchecked | These don't have deadlines per se — they have milestones. Phase = Development or Optimization. Success Criteria = the specific capability it unlocks.

SEO Projects (CrabtreeMarketing.com, client audits)

Type = project | Billable = ✅ (if client-facing) | Phase = Discovery → Development (the fix package) → Launch (Ken implements). Blocking Issues = "waiting on Ken confirmation."