task-ops

A project management checklist from kickoff to handover

September 22, 2026 ・ Pinateca Editorial

Most projects on a small team do not fail in a dramatic way. They drift. A decision nobody wrote down gets remade three weeks later with a different answer. A task that everyone assumed someone else owned sits untouched until the day before the deadline. The client approves a scope in a call, and nobody can find what was actually agreed when the invoice goes out.

A checklist does not make a project succeed. What it does is catch the small, predictable gaps at the point where closing them costs five minutes instead of five days. The checklist below is organized by phase, from kickoff through handover. It is written for teams of roughly two to fifteen people who run several projects at once and do not have a dedicated project office.

Treat it as a starting point. Remove the lines that never apply to your work and add the ones your own past projects have taught you.

Before kickoff: decide whether and how to start

The cheapest point to fix a project is before it starts. Most of the checks here take a single conversation.

Scope and purpose

The goal of the project is written in one or two sentences that the client or sponsor agrees with.
What is explicitly out of scope is written down, not just what is in scope.
The definition of done is concrete. "Launched" is not concrete. "Live on the production domain with the payment flow tested by the client" is.
Known constraints are listed: fixed dates, budget ceilings, required technologies, approval steps.

People and ownership

One person is named as the project lead, with the authority to make day-to-day decisions.
The decision maker on the client or sponsor side is identified by name.
Everyone who will work on the project knows they are on it and has capacity for it. Check actual workload, not just availability on paper.
It is clear who approves changes to scope, budget, and deadline.

Go or no-go

The team has checked whether the deadline is realistic given current commitments.
Risks that could stop the project entirely are named, even if there is no plan for them yet.
If the answer to any of the above is unclear, the project waits until it is clear.

The out-of-scope list deserves special attention. Scope disputes rarely come from what was agreed. They come from what was never discussed, and each side filled the gap with its own assumption.

Kickoff: set up the shared record

Kickoff is where the project gets a home. The aim is that from this day on, anyone asking "where are things" can find the answer without asking a person.

The workspace

A single board or project space exists for this project, and everyone on the team has access.
Client or outside collaborators have access only to what they need to see.
There is one agreed place for files, and one agreed place for decisions. Ideally they are the same place as the tasks.
The old habit of tracking in personal notes or private spreadsheets is explicitly retired for this project.

The structure

Stages for work are agreed, for example Backlog, In progress, Review, Done.
Labels or categories are agreed if the project has distinct streams of work.
Any custom information the team needs on each task, such as estimated hours or client reference, is set up as a field rather than typed into descriptions.

The first conversation

The kickoff meeting covers goal, scope, out of scope, milestones, and who decides what.
A short written summary of the kickoff is attached to the project record, not sent as an email that disappears into inboxes.
Communication rules are agreed: where questions go, how fast replies are expected, and when a meeting is necessary.

A tool comparison is worth doing once, at this stage, rather than mid-project. If you are choosing between board tools, the table at /compare sets out what each one includes on its free plan.

Planning: break the work down

Planning is where vague intent becomes assigned work. The test for a good plan is that every task could be picked up by its owner tomorrow without asking a clarifying question.

Tasks

Every deliverable is broken into tasks small enough to finish in a few days.
Each task has exactly one owner. Shared ownership usually means no ownership.
Each task has a due date, or is explicitly marked as unscheduled backlog.
Larger tasks have subtasks, so progress can be counted instead of estimated.

Schedule

Milestones are placed on a timeline, not just listed.
Dependencies are identified. If task B cannot start until task A is done, that is visible.
The timeline has been checked against holidays, leave, and other projects the same people are working on.
There is buffer before any date that cannot move.

Load

The work assigned to each person has been checked across all projects, not just this one.
Nobody has overlapping heavy weeks without a plan to handle them.

The load check is the one most often skipped. A plan can look perfect inside one project and still be impossible because the same designer is also due to deliver two other projects that week. A view with people down one axis and dates along the other makes this visible in seconds.

Planning view	Question it answers	What to look for
Kanban board	What is in progress and what is waiting?	Piles in one column
Gantt chart	Is the schedule realistic?	Overlapping bars, missing buffer
Calendar	Which weeks are crowded?	Clusters of due dates
Resource view	Is anyone overloaded?	One row much fuller than the rest

During delivery: keep the record current

Once work starts, the checklist shifts from setup to maintenance. These checks are recurring, typically weekly.

Weekly checks

Every in-progress task has moved in the last week, or has a note explaining why not.
Overdue tasks are either rescheduled with a reason or escalated.
Blocked tasks are marked as blocked and someone is responsible for removing the block.
Nothing is sitting in Review longer than the agreed turnaround.
The next milestone is still achievable. If not, the sponsor hears about it this week, not the week of the deadline.

Decisions and changes

Decisions are recorded on the task they affect, with the reason.
Any change to scope is written down and approved by the person who owns scope.
Change requests that affect budget or deadline are not started until approved.

Communication

Status questions are answered by pointing at the board, not by writing a separate summary.
Updates given in private messages are moved to the task record.
The client or sponsor receives regular updates in an agreed format, drawn from the project record.

Early warning signs

The same task has been rescheduled more than once.
One person is mentioned as a blocker on multiple tasks.
Comments on a task show a disagreement that nobody has resolved.
The team stops updating the board. This usually means the board does not match how the work actually flows, and the stages need adjusting.

Running the weekly check in fifteen minutes

The weekly checks only survive if they are quick. A format that works for many small teams is to open the board and walk it from right to left. Start with Review, because finished work waiting for a reviewer is the easiest delay to remove. Then look at In progress and ask one question per card: has this moved since last week? Then open the timeline and look only at the next milestone. Skip anything that is on track. The meeting is for exceptions, not for reading every card aloud.

If the check regularly runs over, the cause is usually one of two things. Either the tasks are too large, so every card needs discussion, or updates are happening in the meeting rather than before it. Breaking tasks into subtasks fixes the first. Asking owners to update their cards before the meeting starts fixes the second, and after a few weeks the habit tends to hold on its own.

Much of the chasing in this phase can be handed to the tool. Notifications for assignments, mentions, and approaching due dates do the reminding. If your tool supports automation, a card reaching Done can post to a team channel automatically. The options for connecting other services are listed at /integrations.

Before handover: close the loose ends

The final phase is where invoices get disputed and future projects inherit mess. A short, strict checklist pays for itself here.

Deliverables

Every deliverable listed in scope has been delivered and accepted.
Acceptance is recorded, with who accepted and when.
Anything delivered that was out of original scope is listed with the approval that authorized it.
Open tasks are either finished, explicitly moved to a follow-up project, or closed as not doing.

Documentation

The client or next owner has the credentials, files, and instructions they need.
Known issues and limitations are written down and shared.
Decisions that a future maintainer would need to understand are findable, ideally still attached to the tasks they relate to.

Money and time

Time or effort spent is totalled and checked against the budget.
Any overrun has a documented reason tied to approved changes.
The final invoice matches the recorded scope and changes.

Access

Outside collaborators who no longer need access have been removed.
Shared credentials created for the project are rotated or handed over.

After the project: learn something

This phase takes one hour and is the one most often dropped. It is also what makes the next project run better than this one.

Review

A short retrospective covers three questions: what went well, what went badly, and what to do differently.
Estimates are compared with actuals for the main tasks, to calibrate future planning.
Problems are traced to a cause in the process, not to a person.

Carry forward

Any change to how the team works is added to this checklist, so the lesson is not lost.
Reusable structures such as the task list, stages, and labels are saved as a template for similar future projects.
The project board is archived, not deleted, so the record remains searchable.

Archiving matters more than it seems. Six months later someone will ask why a particular decision was made, and the answer will be in a comment on a card that only exists if the board was kept.

What to change first

Take the next project that starts this month and run the "Before kickoff" and "Kickoff" sections in full, with the out-of-scope list written down and every task given one owner. Add the weekly delivery checks as a recurring task on the board itself so the checklist reminds the team rather than relying on memory. Pinateca includes kanban, Gantt, calendar, and resource boards free for up to 5 people and 10 boards if you want one place to try it.

Q1. What should be on a basic project management checklist?

At minimum: a written goal and definition of done, an out-of-scope list, a named decision maker, every task with one owner and a due date, a weekly check for overdue and blocked work, and a formal acceptance step at handover. Everything else can be added as your own projects reveal gaps.

Q2. How is a project checklist different from a project plan?

A project plan describes the specific work for one project: its tasks, dates, and owners. A checklist describes the steps every project should go through regardless of its content. The checklist is reused across projects, and one of its items is to make sure a plan exists.

Q3. How often should the checklist be reviewed during a project?

The phase checks for kickoff, planning, and handover are run once at each phase. The delivery checks work best weekly, often as part of a regular team meeting. Putting the weekly check on the board as a recurring task stops it from being forgotten when the team gets busy.

Q4. Does a small team really need a formal checklist?

Small teams tend to rely on memory because everyone knows everything, until the team is running several projects at once. The checklist does not need to be formal or long. A single page with the lines that have caught real problems before is enough, and it saves time when someone new joins.

Q5. Should the checklist live in a document or in the project tool?

Keeping it inside the project tool usually works better, for example as a template card with subtasks that is copied into each new project. The team then ticks items in the same place they manage work, and progress through the checklist is visible to everyone.

Back to the blog