Plan outcome-based work with objectives and tasks

Objectives and tasks work best when they describe a chain from client outcome to reviewable evidence. The hierarchy is deliberately small: a project contains objectives, and each objective contains tasks. The quality comes from what each record says, not from adding more nesting.

The screenshot is a real capture from Aurora Studio’s fictional GridFlex Customer Portal. The left tree keeps the plan navigable; the focused pane connects delivery status, schedule, effort, purpose, allocation, pricing, and invoice evidence.

Write objectives as outcomes

An objective should explain what becomes true for the client or operating team when a coherent part of the project succeeds. “Enable secure self-service” is stronger than “Authentication work” because it names the outcome and leaves room for multiple implementation tasks.

A durable objective description includes:

• Purpose: why the outcome matters.
• Scope: the boundaries of the work needed to reach it.
• Success evidence: what a reviewer can observe, measure, or accept.

Keep implementation detail at the task level unless it defines the objective’s boundary. If an objective becomes a container for unrelated work, split it. If it can be completed by a single small action, it may be a task instead.

Make tasks independently reviewable

A task should represent a meaningful piece of delivery that can receive a status, target date, planned effort, assignments, rates, source reference, acceptance context, visibility decision, and conversation.

Use a verb and a concrete result: “Prototype the consumption dashboard” or “Implement identity and household access.” Avoid titles such as “Frontend,” “Miscellaneous,” or “Work package 3” unless the shared project vocabulary gives them an unambiguous meaning.

In the description, state what is included, what is excluded, and what evidence closes the task. Evidence may be a reviewed artifact, test result, deployment, signed decision, client acceptance, or other verifiable outcome. Completion should not depend on private knowledge held by one person.

Treat status as an operating signal

Use Not started when no delivery work is active, In progress when work is actively moving, On hold when progress is intentionally blocked or paused, and Completed when the acceptance evidence exists. Cancelled and moved work remains historical evidence and is excluded from current delivery totals.

Do not delete a task merely because the plan changed. Move or cancel it when the historical decision matters. This keeps client reports, financial evidence, and later revision comparisons understandable.

Completed tasks can be reopened when new facts invalidate completion. Record the reason in the task conversation or supporting notes so the status change has context.

Plan schedule and effort at the task level

Task dates feed the objective span and timeline. Use a target date that represents a real commitment or review point. If the work has a start window, record it; otherwise avoid artificial precision.

Planned effort explains the expected amount of work, not the elapsed calendar duration. Allocate effort among people when ownership is known. Leave a visible unassigned portion when it is not. A transparent 40-hour gap is more useful than an invented owner.

Tracked time is performance evidence. Linking recorded entries to a task does not rewrite planned hours or automatically make the entry billable. Compare plan and actual to ask whether scope, estimation, execution, or source mapping needs attention.

Price work without obscuring the basis

Applicable rates come from the organization’s rate catalogue and project memberships. An assignment can capture the person, planned hours, selected rate, and resulting cost snapshot. Preserve historical snapshots when rates or memberships later change.

Before invoicing, confirm that every billed portion has a valid rate and commercial basis. Planned projects can be invoiced in stages, so one task may have invoiced effort and value while another remains open. The commercial snapshot in the focused objective helps a reviewer connect delivery to invoices without opening every invoice record.

Use visibility as publication, not decoration

A project must be visible to client viewers before any of its objectives or tasks can appear to them. Each objective and task then has its own publication control. A task is exposed only when both it and its parent objective are published.

Review the client-facing description, status, schedule, planned effort, budget implication, and conversation audience before publishing. Internal notes, rates, raw invoice records, unbilled-work details, sources, private conversations, and staff contact details remain outside the client projection. Team identities appear only when team sharing is enabled.

Publication is reversible, but removing visibility changes what a client can see. Treat it as an editorial decision with a responsible owner.

Keep conversations attached to the work

Task conversations avoid splitting delivery context across email, chat, and memory. Choose the audience for each message: internal-only discussion stays private; client-visible discussion belongs only on published work and should be written for that audience.

Use questions when a response is required, then resolve them explicitly. Read positions help teams understand whether a conversation has been seen. Publishing a task does not publish its internal messages.

Reorder for meaning, not appearance

The objective tree supports mouse and keyboard reordering. Order objectives by the story the project should tell—often outcome sequence, release phase, or client priority. Order tasks within an objective by dependency or review sequence.

Reordering does not move a task between objectives. A deliberate move preserves moved history rather than silently changing its origin. Use favourites for shared priority and My tasks for assigned focus; neither replaces clear project ordering.

A weekly plan-maintenance checklist

For each active objective:

1. Confirm that purpose, scope, and success evidence still match the agreement.
2. Review held, overdue, and near-term tasks.
3. Check status against actual evidence.
4. Confirm owners, unassigned effort, rates, and target dates.
5. Reconcile tracked time where it informs plan performance.
6. Review client visibility and conversation audiences.
7. Preserve moved or cancelled history when scope changes.
8. Open the project overview and timeline to verify the roll-up story.

The result is not a perfect plan. It is a plan whose current state, uncertainty, commercial basis, and next decision are visible. Use client sharing when the plan is ready for external readers and the audit history guide when a review needs to understand how it evolved.