Work Packages

Work packages are how you break a project into chunks. Think of them as phases, stages, or major milestones—whatever makes sense for how you work.

A field service project might have packages like “Site Assessment,” “Primary Work,” “Cleanup,” and “Final Inspection.” A maintenance project might be “Survey,” “Equipment Delivery,” “Installation,” and “Testing.”

Why bother with packages?

You could just dump all your tasks into a project without any structure. But as projects grow, that becomes a mess. Work packages give you:

A way to see progress at the phase level, not just task by task
Clear boundaries between “we’re still assessing” and “we’re actually doing the work”
Better resource planning—you can staff different packages differently
A natural way to communicate status (“we’re in Phase 2” means something)

Creating a work package

Open your project and look for Work Packages (usually a tab or section). Click to add one.

Give it a name that describes the phase: “Site Preparation,” “Phase 1: Discovery,” “North Section Work”—whatever fits your project.

Add a description if it’s helpful. This is a good place to note what’s included, what’s not, any prerequisites, or special considerations.

Set start and end dates. These don’t have to be precise—estimates are fine. They help with planning and make it obvious when something’s running late.

Status

Work packages move through statuses:

Not Started — haven’t begun yet
In Progress — actively working on it
Completed — all done
Cancelled — not happening (but you want to keep the record)

Update the status as work progresses. Some setups can do this automatically based on task completion—check with your admin.

How many packages?

There’s no magic number, but most projects work well with 3–7 packages.

Too few and you lose the benefit of breaking things down. Too many and you’re managing packages instead of doing work.

If you find yourself with 15 packages, you’re probably being too granular. If you have just one or two, you might as well not use packages at all.

Sequential vs. parallel

Some packages need to happen in order: you can’t do installation before delivery. Set your dates to reflect this, and note dependencies in the description.

Other packages can happen at the same time: different crews working on different areas, or independent work streams. Overlapping dates are totally fine.

Deleting packages

Be careful. Deleting a work package removes all the tasks inside it. If work has already happened, don’t delete—use the Cancelled status instead to preserve the record.

Only delete if:

The package was created by mistake
You’re restructuring before any work started
You’re cleaning up a test project

Tips

Name consistently. Pick a style (by phase, by work type, by location) and stick with it across projects. Makes it easier for your team to understand any project at a glance.

Don’t overthink it. Packages are supposed to make your life easier. If you’re spending more time managing package structure than doing actual work, simplify.

Use descriptions. A few sentences about what’s included, what the deliverables are, and any special requirements can save confusion later.

Next: Work Items covers the actual tasks inside packages. Importing Tasks shows how to bulk-upload tasks from a spreadsheet.