Tasks and hours

A task is a line under a work package, identified by its line number and revision. It can carry a task name, planned hours, actual hours, due date and completion date. The dependency field names work that needs to precede it. This gives the owner a way to explain the sequence behind a package plan and to show what effort was actually recorded when a coordinator asks for acceptance.

The package is still the accountable unit. Task hours explain its progress; they do not replace the package’s budgeted hours or its reviewer decision. In the Operations Overview, planned versus actual task hours can be examined alongside the package lifecycle and review backlog. A task whose date has passed or whose dependent work remains open deserves attention before the package is treated as complete.

• Lines. Package Owner gives each task a line number and connects it to the parent package.
• Dependencies. Research Coordinator and Package Owner examine the predecessor text and the proposed sequence before work starts.
• Effort. Package Owner updates actual hours and completion date as the work is performed, leaving planned hours visible for comparison.

Agree what one task line represents. A useful line has an outcome the team can recognize, rather than a broad activity that stays open for the whole project. Use a consistent way to write dependency identifiers so another person can trace the predecessor from the package. Review cycles and available capacity before turning a planned package into active work. The task revision should move with a deliberate scope change, and the owner should explain the changed line to the reviewer.

Choose a cadence for recording actual hours. Waiting until the package is submitted for review makes the comparison less useful to the coordinator. Decide how to handle a task that is complete with fewer or more hours than planned; retain the actual figure and explain the changed scope in the package review.

An owner plans a sample collection task before a study analysis task and records the second task’s dependency on the first. The first has planned hours and a due date. After field work, the owner records actual hours and the completion date. The analysis task can then be assessed against its own plan. If the owner changes the predecessor or adds another task after planning, Research Coordinator checks the dependency chain and the package revision before relying on the baseline.

At review, Independent Reviewer opens the package’s task lines and compares recorded progress with the evidence attachment. A completed study count on a research milestone should have supporting work in the same parent package. Operations Analyst can compare planned and actual hours without treating the comparison as an automatic acceptance decision.

• Task Effort — Task lines with their parent package, planned hours and actual hours side by side.
• Task Dependencies — Task lines whose predecessor needs to be checked during planning or revision.

Use task execution and evidence review to rehearse the work.