60 lines
3.0 KiB
Markdown
60 lines
3.0 KiB
Markdown
|
# Tasklist Rules
|
||
|
|
|
||
|
|
## Default Work Structure
|
||
|
|
|
||
|
|
Use Basecamp To-dos as the default structure for planned project work. A To-do is the right unit when work has a clear action, owner, timing, and completion definition.
|
||
|
|
|
||
|
|
Use Card Table only for reactive or pipeline work, such as incoming requests, intake queues, review stages, sales-style pipelines, support flows, or work that moves through repeatable status columns before it is ready for a committed To-do list.
|
||
|
|
|
||
|
|
## Assignment Rules
|
||
|
|
|
||
|
|
Every task set needs a named directly responsible individual (DRI). The DRI is accountable for keeping the task list coherent, resolving unclear ownership, and making sure work moves forward.
|
||
|
|
|
||
|
|
Use hybrid assignment:
|
||
|
|
|
||
|
|
- Near-term tasks need named owners.
|
||
|
|
- Dependency-critical tasks need named owners.
|
||
|
|
- Client-facing or approval-heavy tasks need named owners.
|
||
|
|
- Later uncertain work may use role placeholders, such as `Designer`, `Developer`, `Client reviewer`, or `Legal reviewer`.
|
||
|
|
- Each role placeholder needs a staffing-resolution task with a named owner and a date or milestone-relative trigger.
|
||
|
|
|
||
|
|
## Due Date Rules
|
||
|
|
|
||
|
|
Use hybrid due dates:
|
||
|
|
|
||
|
|
- Use fixed dates for near-term work, dependency-critical work, launch-critical work, meetings, reviews, and external commitments.
|
||
|
|
- Use milestone-relative timing for later uncertain work, such as `3 business days after content approval` or `1 week before launch`.
|
||
|
|
- Convert all milestone-relative timing to fixed Basecamp due dates before creating the final Basecamp To-dos.
|
||
|
|
- If timing is uncertain, name the decision point that will convert relative timing into fixed dates.
|
||
|
|
|
||
|
|
## Task Output Contract
|
||
|
|
|
||
|
|
Each task should include:
|
||
|
|
|
||
|
|
- **Title:** Action-oriented, specific, and short.
|
||
|
|
- **Owner:** Named person or role placeholder.
|
||
|
|
- **Owner type:** `named DRI`, `named owner`, or `role placeholder`.
|
||
|
|
- **Timing type:** `fixed date`, `milestone-relative`, or `sequence-only`.
|
||
|
|
- **Due or relative timing:** Date, milestone-relative timing, or ordering note.
|
||
|
|
- **Description:** Context needed to do the work without rereading the full plan.
|
||
|
|
- **Done means:** Observable completion condition.
|
||
|
|
- **Dependency:** Upstream task, decision, asset, approval, or `none`.
|
||
|
|
- **Confidence:** `high`, `medium`, or `low`, based on clarity of scope, owner, and timing.
|
||
|
|
|
||
|
|
## Task Quality Checklist
|
||
|
|
|
||
|
|
Before creating To-dos in Basecamp, confirm that:
|
||
|
|
|
||
|
|
- To-dos are used for committed planned work.
|
||
|
|
- Card Table is reserved for reactive or pipeline work.
|
||
|
|
- A named DRI exists for the task list or project area.
|
||
|
|
- Near-term and dependency-critical tasks have named owners.
|
||
|
|
- Role placeholders are limited to later uncertain work.
|
||
|
|
- Every role placeholder has a staffing-resolution task.
|
||
|
|
- Fixed dates are used where commitments or dependencies require them.
|
||
|
|
- Milestone-relative timing has a clear conversion trigger.
|
||
|
|
- All Basecamp-ready tasks have fixed due dates where Basecamp dates are required.
|
||
|
|
- Each task states what done means.
|
||
|
|
- Dependencies are explicit or marked as none.
|
||
|
|
- Low-confidence tasks identify what must be clarified next.
|