A project structure that worked in your previous system may need adjustment after migration to Drum. The key question is whether its deliverables match the work you intend to bill to your client.
Deliverables connect the work to client billing
In Drum, a deliverable groups related tasks within a project. Aligning deliverables with the stages or services you bill makes it easier to prepare invoices, whether you bill at milestones or monthly.
Tasks describe the work within each deliverable. Several tasks can provide the detail your team needs to manage a single stage or service billed to the client. A separate task therefore does not necessarily need a separate deliverable.
Why one Design deliverable might become two
Suppose your migrated project has one Design deliverable containing a concept design task and a schematic design task. That structure groups both stages under the same deliverable.
If you intend to invoice concept design and schematic design separately, giving each stage its own deliverable makes the project structure match that billing approach:
Concept Design contains the concept design task.
Schematic Design contains the schematic design task.
Each design stage now has its own deliverable, with the task budget shown beneath it.
If both stages are managed and billed together, a single Design deliverable may still suit the project. The reason to split it is the intended billing structure, rather than the number of tasks. Each resulting deliverable can still contain several tasks.
Time allocation determines which task budget is used
Recorded time is allocated to a task and draws down that task’s budget. The deliverable groups the work for billing, while the task allocation determines which budget the time uses. A project can therefore have the intended deliverables but still need its time allocations reviewed.
Renaming or moving an existing task changes its name or place in the structure. Creating a replacement introduces a different task: time recorded against the previous task needs to be reviewed and reassigned where appropriate to count against the intended budget.
Why review the structure soon after migration?
Reviewing ongoing projects early makes the first invoicing milestone easier to prepare for. If restructuring is needed, you can address it before more time is recorded against the old structure.
You can instead review a project when its first invoice is due. The trade-off is that your team may have continued recording time in the meantime, leaving more allocations to check.
If the migrated structure already matches how you manage and bill the work, it may be suitable as it is.
For the practical steps, read Restructure a project after migration.