Manage a project with BaseHalf

Project management is often treated as task management. Tasks matter, but they are only the visible edge of the work. The harder part is preserving the context behind the tasks: why the project exists, what decisions were made, which risks are active, what evidence supports the plan, and what changed after each meeting.

BaseHalf is useful when a project has too much context for one document and too many moving parts for one chat thread. A project Map gives the work a visible shape. Each Point holds one piece of the project that can be opened, revised, referenced, and reused.

Start with a project charter Point

Create one Point that explains the project in plain language. This Point is the anchor for the whole Map.

Create a project Map for the onboarding launch.
Split the work into charter, goals, workstreams, decisions,
risks, meeting notes, open questions, and weekly reviews.

The charter Point should be short enough to read in one minute:

• the outcome the project is trying to create
• the users or customers affected
• the deadline or launch window
• the non-goals
• the main constraints
• the current owner

For the example project, the charter might say:

Launch a clearer onboarding path for new teams before the June release.
The project includes first-run product guidance, plan selection, analytics events,
and help docs. It does not include a full billing rewrite or a new admin console.

This is not a polished strategy document. It is the stable point of reference that keeps later work from drifting.

Split the Map by responsibility

Do not put every task in one Point. Split the project into Points by responsibility and context type.

Start with these project Points:

• Charter: what the project is and is not.
• Stakeholders: who needs to review, approve, or be informed.
• Milestones: the shape of the timeline.
• Workstreams: product, engineering, design, data, support, docs, and go-to-market.
• Decisions: choices that constrain later work.
• Risks: things that could change the plan.
• Open questions: unknowns that need a decision, source, or owner.
• Meeting notes: raw updates from recurring project meetings.
• Weekly review: the current state of the project after each review.

This structure makes the project easier to inspect. A task tracker can tell you that "analytics QA" is due Friday. The Map should tell you why analytics QA matters, which events are in scope, which product decision changed the event names, and who needs the final report.

Model workstreams as Points

Create one Point per workstream. A workstream Point should contain the context needed to keep that part of the project moving.

For the onboarding launch, the workstream Points might be:

• Product flow: activation goal, screens affected, product constraints, open decisions.
• Design: prototypes, review notes, accessibility concerns, edge cases.
• Engineering: implementation plan, dependencies, integration risks, QA checklist.
• Data: event taxonomy, success metrics, dashboards, launch-readiness checks.
• Support: expected customer questions, support macros, escalation path.
• Docs: help center updates, screenshots, release note language.
• Go-to-market: internal announcement, customer email, launch timing.

Each workstream Point should include only the material that belongs to that stream. If the engineering Point contains the launch email and the support macro, split them. The Map becomes weaker when every Point tries to be the whole project.

Turn decisions into reusable context

Projects change when decisions change. That is why decisions deserve their own Points.

For each important decision, write:

• the decision in one sentence
• the alternatives considered
• the reason for the current choice
• the evidence or constraint behind it
• the date or meeting where it became stable
• the condition that would reopen it

Example:

Decision: keep plan selection inside onboarding instead of sending users to Billing.

Reason: the product team wants activation to stay in one flow, and support data shows
new teams drop off when they are redirected too early.

Reopen if: conversion drops after launch, pricing copy becomes too complex, or billing
requires settings that cannot be safely embedded.

Reference this Decision Point from the Product flow, Engineering, Data, Support, and Docs Points. The decision now becomes context that can be reused without being copied into every place.

Keep risks active

A risk Point is not a warning label. It should change behavior.

For each risk, add:

• what could go wrong
• why it matters
• the signal that would confirm the risk
• the mitigation or owner
• the next review date

Weak risk:

Launch may be delayed.

Useful risk:

Billing integration may block launch because plan selection depends on a pricing API
that is still changing. If the final API contract is not stable by week three,
ship onboarding without in-flow plan selection and link to Billing as a fallback.
Owner: engineering lead. Review: Friday.

The second version is useful because it creates a trigger, fallback, and owner. It can be referenced from the Engineering and Milestones Points.

Import meetings without burying the project

Meeting notes are noisy. They contain updates, decisions, questions, jokes, repeated context, and action items. Do not let them become the project record by themselves.

After each project meeting, paste the notes into a Meeting Point and ask BaseHalf to extract:

From these meeting notes, update the project Map.
Separate new decisions, changed risks, open questions,
blocked tasks, and follow-up owners.
Do not overwrite stable project context unless the notes clearly change it.

Keep the raw meeting notes as a source Point. Then promote useful material into the right project Points:

• decisions into Decision Points
• new blockers into Risk or Open question Points
• owner changes into Workstream Points
• timeline changes into Milestones
• follow-up tasks into the next Weekly review

This keeps meetings useful without letting the Map become a transcript archive.

Use a weekly review Point

Every week, create or update one Weekly review Point. This Point should be the project state someone can read before asking, "Where are we?"

Use a stable format:

• Status: on track, at risk, blocked, or changed.
• This week: what actually moved.
• Decisions: what became stable.
• Risks: what changed or still needs attention.
• Open questions: what blocks the next move.
• Next actions: the smallest set of actions that matter now.

Ask BaseHalf to draft the weekly review from connected context:

Draft this week's project review from the connected workstream,
decision, risk, and meeting Points. Keep it factual.
Call out changed decisions and unresolved risks.

The weekly review should not replace the Map. It is a checkpoint that helps the team continue without rereading every Point.

Handle scope changes explicitly

Scope changes are where many projects lose their memory. A new request appears, the team agrees quickly, and two weeks later nobody remembers whether the work was added, deferred, or rejected.

Make scope changes visible with one Point per proposed change.

For each scope change Point, write:

• the requested change
• who requested it
• why it matters
• affected workstreams
• cost or timeline impact
• decision: accept, defer, reject, or split

Example:

Scope change: add role-based onboarding paths for Admin, Editor, and Viewer.

Impact: requires additional product copy, design states, event names, and support docs.
Decision: defer. Keep one general onboarding path for launch and create a post-launch
research Point for role-based paths.

Reference the scope change from the Charter and Milestones Points. The Map now preserves the reasoning, not only the final task list.

When to use a task tool

BaseHalf should not replace every project management system. Use a task tool when you need assignment, due dates, sprint planning, notifications, or reporting.

Use BaseHalf for the context around that execution:

• why a task exists
• what decision it depends on
• which source or meeting created it
• what risk it mitigates
• what draft or asset it should use
• what context a teammate needs before picking it up

The clean pattern is simple: BaseHalf holds the thinking system; your task tool holds the execution queue. Link from tasks back to the relevant Point when the context matters.

A complete project Map

For a complex launch, a useful Map might contain:

• 1 charter Point
• 5 to 8 workstream Points
• 6 to 12 decision Points
• 4 to 8 active risk Points
• 3 to 10 open question Points
• 1 meeting Point per recurring meeting
• 1 weekly review Point per week
• source Points for customer notes, analytics, specs, prototypes, and docs

That may sound like more structure than a simple project needs. It is. Use it when the cost of forgetting context is higher than the cost of maintaining the Map.

For a one-day task, use a checklist. For a six-week cross-functional launch, use a Map.

What good looks like

A good project Map makes these questions easy to answer:

• What are we trying to ship?
• What changed since last week?
• Which decisions constrain the work?
• Which risks are active?
• Which open question blocks progress?
• Which task has enough context for someone else to resume?
• Which context should be reused in the next project?

The goal is not to make project management heavier. The goal is to stop losing the reasoning that makes the project possible.