Guide

Project Management: A Practical Guide With a Worked Plan

Make project management practical: agree on the result, organize the work, expose blockers, and accept the finished deliverable with evidence.

By the Space Office team · Published October 20, 2026 · Updated October 20, 2026 · 15 min read

Project management is the work of organizing a temporary effort to deliver an agreed result within defined constraints. Set the purpose, scope, owner, acceptance criteria, sequence, resources, and review points; then track decisions and changes until the result is accepted. In Space Office, Hydrogen can coordinate Chromium’s frontend implementation and Carbon’s testing for a bounded website project. A human owner approves scope, access, tradeoffs, acceptance, and release.

Key takeaways

• Define the result and its acceptance criteria before turning a request into tasks.
• Give each work package an owner, a prerequisite, and evidence of completion.
• Plan waiting, review, and available capacity alongside implementation work.
• Use short status updates to surface decisions, blockers, and changes.
• Close the project with an accepted handoff; review business outcomes separately.

Download the free project management worksheet to write a brief, connect tasks, record risks and changes, and prepare acceptance. The bicycle-shop example below is fictional. For the separate question of what an AI coordinator can do, read the AI project manager guide.

What project management needs to produce

Start with a change someone needs, such as replacing a confusing service-request page. The project has a beginning, an intended result, and a point at which an authorized owner can accept or stop the work. Day-to-day activity continues afterward: somebody still handles enquiries, maintains the page, and corrects service information. Name that ongoing responsibility while planning the temporary effort.

The Association for Project Management’s explanation connects project objectives with acceptance criteria, a finite timescale, and a budget. A practical small-team version is a shared agreement about the result, its constraints, and the evidence needed to accept it. A task board helps maintain that agreement when it records decisions and prerequisites as well as activity.

A released page provides evidence that a deliverable exists. Its effect on workload or sales needs later observation. Keep both questions in the plan so the team can finish a bounded project without declaring an unmeasured commercial success. If the expected benefit becomes implausible before release, the owner can reconsider whether completing the original work is still worthwhile.

Write a brief with scope and acceptance criteria

Describe the problem in terms the owner can verify. For example: people currently email incomplete repair requests, and the shop repeatedly asks which bicycle and service they mean. Record where that observation came from, who experiences the problem, and what remains uncertain. A few examples may justify an investigation; they do not establish how often every customer encounters the issue.

Next define the result and its boundaries. A page that collects a repair enquiry is different from a booking system that reserves workshop capacity. State what the customer can do, what happens after submission, and which existing service handles the message. List exclusions such as payments, automatic quotes, customer accounts, and calendar reservations. These boundaries let someone assess a new request without reconstructing the original conversation.

1. 1Name the business owner who can approve scope, priorities, and final acceptance.
2. 2Describe the deliverable and the customer action it supports.
3. 3Record required inputs, existing systems, access boundaries, and unresolved questions.
4. 4Write observable acceptance checks and name who verifies each one.
5. 5Agree the schedule, available review capacity, spending boundaries, and escalation route.

Acceptance criteria should describe an observable condition. Replace 'make the form good' with checks such as visible field labels, keyboard access, a useful required-field error, successful delivery to the approved inbox, and an accurate confirmation message. Describe the expected behavior for an unsuccessful submission too. A screenshot of a button cannot establish that the message reached its destination.

Keep the brief short enough to review, with links to supporting material instead of copied versions of every document. Give it a version and an approval date. Use the AI-team briefing guide when preparing the inputs for specialists. Changes to a source document should trigger a check of the affected requirement rather than silently changing an already approved promise.

Choose a way of working that fits the uncertainty

Some work is well understood at the start. Other work needs a prototype or a conversation before the requirements become clear. Choose the planning approach from that uncertainty and the cost of a wrong decision. A small project can keep a fixed release boundary while reviewing an early layout, then revise the implementation details from what the owner learns.

Atlassian’s agile project-management guide describes short cycles of work and feedback. That is useful when the next version can answer a specific unresolved question. State that question before calling a task an experiment: can the owner understand the request flow, can a customer find the conditions, or does the proposed component fit the existing site?

A method name does not resolve ownership or capacity. Avoid adding meetings and labels that nobody uses to make decisions. For the bicycle page, one early layout review can settle the wording and request flow before the full build. Later QA can then check that approved flow. If a review changes the service promise, update the brief and explain the effect on the plan.

Connect work packages, dependencies, and capacity

Break the deliverable into pieces small enough that a reviewer can tell whether each is ready. A work package might be an approved layout, a functioning form connection, or a tested release candidate. Describe its input, responsible owner, output, acceptance check, and next recipient. Assign one responsible owner even when several people contribute.

Connect the prerequisites explicitly. The form connection needs the approved endpoint details; the confirmation message needs the shop’s actual response process; acceptance testing needs a working candidate and agreed checks. Some preparation can happen in parallel. Carbon can prepare test cases from the brief while Chromium builds the page, but end-to-end message delivery still requires the integrated form.

A schedule must include review and waiting time. An implementation estimate of four hours says little about elapsed time if access arrives two days later or the approver is unavailable. Ask when each owner can actually work and decide. Keep proposed dates visibly provisional until the required inputs and reviewers are confirmed. Where waiting threatens a milestone, name the decision that could unblock it.

Asana’s project-plan guide groups goals, roles, resources, deliverables, dependencies, and communication in a shared plan. Use a compact version for a small project: a brief, a linked task list, a decision log, and an acceptance record. A spreadsheet or board can hold those records if the team keeps it current and knows which version is authoritative.

Track the resource constraints that could change a decision. These may include owner review hours, supplier costs, approved tool usage, and access to an existing system. Preserve the basis of an estimate and record actual usage separately. A schedule is a forecast of work and decisions; update it when the evidence changes instead of preserving an attractive date with unacknowledged extra effort.

Worked example: plan a bicycle-shop request page

This fictional example illustrates a planning and review process. It is not customer work, a delivery benchmark, or a measured business improvement. A bicycle-repair shop wants a mobile-friendly page that sends service enquiries to its existing approved form endpoint. The page collects a name, email, bicycle category, and repair request. The owner contacts the customer afterward; submitting the form does not reserve a repair slot.

The approved scope includes the page, accessible form behavior, truthful response copy, use of the existing endpoint, and a handoff note. Payments, live availability, automatic quotes, and customer accounts are excluded. The plan covers ten working days, including waiting and review. These are assumed example dates, not ten full days of implementation or a Space Office delivery promise.

The ten checks cover approved copy, enquiry-versus-booking wording, phone layout, keyboard navigation, visible labels, required-field validation, useful error messages, inbox delivery, an accurate confirmation, and an alternative contact route when the form fails. Each check has a written expected result. This makes the review about agreed behavior rather than whether a reviewer likes the page.

In the example’s first test pass, seven checks pass and three fail: keyboard focus, required-field validation, and inbox delivery. Chromium fixes the two frontend defects. The shop owner corrects the existing endpoint’s configuration. Carbon then reruns all ten checks, which pass in the example record. The owner reviews the evidence before accepting the candidate. Passing these checks does not establish that every possible fault has been found.

The owner initially allocates six hours: two for the brief and inputs, one for layout review, two for acceptance, and one for release and handoff. The configuration issue adds one hour, making seven assumed owner hours in total. Record that variance. It helps explain the project’s actual resource use without confusing a ten-day calendar window with seven hours of owner participation.

Track status, risks, issues, and changes

Use a small set of states with clear entry conditions. Ready means the task has its inputs and can begin. Active means someone is working on it. Blocked means a named prerequisite is missing. Review means the proposed output is waiting for a defined check. Accepted means the responsible reviewer has accepted the required evidence. A busy task should not become accepted simply because its deadline arrived.

Keep status updates short and decision-oriented. Record what changed since the last update, the evidence available, the next action and owner, and any decision needed by a specific time. Include the consequence of waiting. 'Endpoint details missing; the owner needs to confirm them before integration testing' is useful. 'The team is working hard and remains focused' leaves the next person without an actionable request.

Separate a risk from an existing issue. A risk might be that the owner will be unavailable for acceptance; agree a review slot or an authorized substitute. An issue is that a required endpoint currently rejects the test submission. Give it an owner, a next diagnostic action, and an effect on the milestone. Escalate an unresolved decision to the person who can make it instead of repeatedly assigning it to the implementer.

A new request needs a visible scope decision. If the bicycle-shop owner asks for card payments during the build, record the request, why it matters, affected dependencies, and the information needed to estimate it. In this example, the owner defers payments to a separately scoped project. The current page remains an enquiry route. If the owner instead approves the addition, update the plan and acceptance criteria before implementing it.

Do not use percentage-complete estimates as a substitute for evidence. Five finished cosmetic tasks can coexist with one unresolved submission failure. Report the acceptance condition and the dependency that matters to release. Use the AI-output review guide when checking specialist work, while keeping business decisions with the authorized owner.

Use Space Office for a bounded project workflow

Give Hydrogen a project brief with approved facts, the existing page or repository, the requested deliverable, the review schedule, and explicit exclusions. Identify who answers service questions, who controls system access, and who accepts the output. Provide only the information needed for the task. Missing input should appear as an open question with an owner, rather than an invented assumption buried in a draft.

1. 1Hydrogen turns the approved brief into coordinated work packages, checks prerequisites, and routes work to the selected specialists.
2. 2Chromium prepares the frontend implementation within the agreed page, component, accessibility, and integration boundaries.
3. 3Carbon prepares and runs the QA checks, records reproducible failures, and verifies the revised candidate against the agreed criteria.
4. 4Hydrogen reviews the returned work and assembles the deliverable, test evidence, unresolved questions, and handoff notes.
5. 5The human owner verifies business facts, approves access and changes, accepts or rejects the candidate, and authorizes any release.

Check the live specialist roster and Hydrogen coordination workflow before selecting roles. The example uses Chromium and Carbon because the task concerns an approved frontend and its QA. A new data layer, infrastructure change, or other missing discipline needs separate scoping and appropriate expertise. The existing endpoint is an explicit input, not an assumed capability supplied by the example’s two specialists.

Naming an agent does not grant repository, inbox, or deployment access. Supply authorized access separately when implementation requires it, and keep the release decision explicit. Use the current pricing page to check subscription and operating costs for the proposed setup. A reviewed task plan can help organize work, but it does not transfer the owner’s accountability for priorities, facts, customer promises, or acceptance.

Close project management with an accepted handoff

Prepare a small acceptance packet: the approved scope version, the delivered artifact, the test record, known limitations, deferred changes, and the owner’s decision. If a criterion remains unmet, record whether the work needs revision or whether the owner is explicitly changing the requirement. A silent exception leaves the next operator with a promise that nobody has actually verified.

The handoff should say where the result lives, who operates it, how to recognize a failure, and who can restore the previous version or arrange a repair. In the example, the shop owner needs to know which inbox receives enquiries and what customers can do if submission fails. Assign maintenance and future service-copy updates before closing the temporary project.

Review the expected business outcome after an agreed observation period. Suitable enquiry counts, recurring customer questions, and the time spent clarifying requests can inform the next change when their definitions and sources are recorded. Those observations may also reflect traffic, demand, staffing, or service changes. They do not automatically isolate the effect of the new page.

Useful project management keeps an agreed result connected to the work, decisions, and evidence needed to deliver it. Start with a clear brief, expose dependencies early, update the plan when facts change, and close with a handoff the owner can accept. That record gives the next project a better starting point than a board full of completed activity.