Tasks and dependencies

Each task line belongs to a work package and carries a line number and revision. The coordinator records a task name, planned hours and due date, then uses the dependency text to explain which work must finish first. Team members enter actual hours and completion dates as delivery proceeds. The package owner can read those lines together to understand whether a schedule remains realistic.

• Order. Use line numbers and dependency notes to make the intended sequence clear.
• Effort. Compare planned and actual hours at task and package level.
• Completion. Record a completion date only when the task work is finished.

Agree how task names and dependencies are written so reviewers can follow the plan. Decide who enters actual hours and when those hours are checked. A schedule proposal should be reviewed against the current task revision. If a dependency changes, the coordinator updates the affected plan before asking a reviewer to approve it.

A package has a preparation task followed by a delivery task. The coordinator records the dependency and due dates, then compares the proposed hours with the package budget. The team member completes preparation and records actual hours. The lead sees that delivery is due soon and can inspect the unfinished line. A completed date on preparation does not by itself complete the whole package; the remaining line and evidence still matter.

A task line is useful only when its place in the package is clear. Keep the line number stable enough for the team to discuss a specific piece of work. Write dependency notes so a coordinator can tell which earlier line affects the due date. During execution, compare actual hours with planned hours on the same line before drawing conclusions from package totals. A late dependent task may explain an overdue package, but the completion date still belongs to the task that was finished. At the handoff, review the whole task set for the current package revision. This keeps a partial completion from looking like acceptance of the package.

• Due task lines — Inspect tasks reaching their due date and the package they belong to.
• Active work packages — Read task progress in the package context.

Follow tasks and dependencies in the operating process. Review the data model when mapping project, package and evidence records.