How to Organize a Project into Sections

A section is a named area inside one project. Discovery, build, and review can be sections. Design, copy, and launch can be sections. The section answers "which part of the project is this task in?" It does not answer "what status is it?" and it is not a milestone.

Tasks live in a section. The section has an order, so you can list the areas in an order people recognize. Archiving a section hides that area without deleting the project. None of that moves a task to Done.

Sections, statuses, and dates

Keep the three ideas apart.

Question	Use
Which area of the project?	Section
Where is the work in its life?	Status: a name in Not started, In progress, Done, or Closed
When is it due?	Due date
What must finish first?	A Blocks link

A task in the Build section can be Not started. A task in Review can be Done. People who rename sections to match statuses end up with two boards and trust neither. Status setup is its own job: how to set up task statuses.

"Phase" is fine as a word in conversation if you mean an area of work. It is a bad word if you mean a gate that unlocks the next area. Dayzen has no milestone object and no phase gate. If review must finish before launch tasks start, those are tasks and a Blocks link, even if they sit in different sections.

A structure that stays small

Use as few sections as you would say out loud in a standup.

For a client site: Content, Design, Build, Launch. For an internal tool: Problem, Build, Rollout. If you need a section called Other, the list is already too clever or not finished. Other becomes the junk drawer.

Order the sections in the order you explain the project, not in alphabetical order. People scan top to bottom. A section with no tasks yet is fine for a week. A section that is still empty after the project is moving should be removed or renamed. Empty areas teach people to ignore the structure.

Do not create a section per person. Assignees already exist. A section called "Alex" hides Alex's work from the area it belongs to and breaks the day Alex is out.

What else a section can scope

A section is also a boundary you can share. A guest can be given access to one section instead of every task in the project. That is how you show Design without showing internal Build notes, as long as the tasks are actually in Design. Client access describes the membership and the share levels: view, comment, or edit. The section is the container you point the share at.

A section can also have its own channel, so the conversation about that area is not mixed with the whole project. Who belongs in that room is a channel question. The section still exists even if you never open the channel.

Sharing a section does not change task status, and a channel does not move cards. They are extra uses of the same container.

Moving a task

When work moves from Design to Build, change the section. Leave the status as whatever is true. A task can enter Build already In progress if someone started early, or Not started if Build is waiting. Do not invent a status called "Moved" to record the section change.

If many tasks move every day, the sections are probably statuses in disguise. Check whether you are using sections as columns. Columns belong on the board. Sections should change rarely: when the area was wrong, or when the work genuinely proceeds to another area and you want it grouped there.

One project or several

Sections divide one project. They do not replace a second project. Use another project when the outcome is different, the access should be different for the whole body of work, or the status list should not be shared. Use a section when it is still one outcome and you want one list of tasks with visible areas.

A workspace holds projects. A project holds sections. A section holds tasks. Skipping a level, such as one giant project called "Everything" with sections per client, recreates the board that guests should not see. Put separate clients in separate projects if their access differs. Use sections inside each.

A cleanup pass

After two weeks, read the section names to someone who did not create them. If they put a task in the wrong area, the name is ambiguous. Merge sections that they treat as the same. Split only when a share or a conversation needs a smaller room. Then stop. Reorganizing every Friday is how the structure becomes the work.

Two structures that look tidy and fail

One section per week. "Week 1," "Week 2," and so on feel like a plan. They are dates pretending to be areas. The due date already holds the week. By week 3 the sections are a calendar you cannot view as a calendar, and a task that slips has to be dragged between sections instead of changing a date. Use areas that stay meaningful when the date moves.

One section per status. "Not started," "Doing," "Done" as sections duplicate the board. A task then has to change section and status together, and they will drift. The board is the status picture. The section stays "Build" while the card moves.

A structure that holds up is boring. Content, Design, Build for a site. The names match how you already talk. A new teammate files a task without a meeting. A guest share on Design does not include Build, because the tasks were filed that way from the start, not sorted the night before the client call.

If a task fits two sections, the names overlap. Pick the section where the owner will look, put the task there, and mention the other area in the description only if someone will need the pointer. Do not duplicate the task.

Conclusion

Organize a project into a few sections that name areas of work. Let status, dates, and Blocks answer the other questions. Use a section as the scope of a share or a channel when someone should see or discuss only that area. Do not turn sections into milestones, people, or a second set of statuses. Projects and sections are part of /pms.

One mistake to avoid

Do not rename sections every time a task moves status. The section is the area. The status is the column. If you find yourself dragging a task from Design to Done as a section change, you have built a second board. Put Done back on the status list and leave the task in the area it belongs to, or in a Launch section if the area truly changed.

Share the Design section only after the tasks in it are ones the guest may see. Moving a sensitive task into Design the same day you share it is a common leak. Look at the task list in that section first, then share.