Client Delivery
Part of Project documentation and decisions
Linking project decisions to the affected tasks
Record a project decision, identify affected tasks and confirm that each owner has the current instruction.
When a decision changes task instructions, ownership or expected output, record it separately and reference it from every affected task. Update those tasks and tell their owners what changed. A link alone does not carry out the decision.
Key Facts on Decision Tracking in Australian Project Delivery
- Change Control TriggerApply when modifying an approved project baseline—common in government and infrastructure projects.
- Task Owner NotificationAlways confirm updates reach the person doing the work—critical for compliance with Australian workplace standards.
Make the decision actionable
Record the question, outcome, authorised decision-maker, date, reason and any conditions. Give the decision a stable reference. If it is temporary or depends on a later check, state when it must be reviewed. Identify the people whose work must change.
For example, if a team decides to use a revised specification for its next prototype, the decision should identify the applicable specification version. Procurement and testing tasks may then need different instructions, and each owner needs to know the action required for their task.
Check the effect before editing
Look at work under way, queued work and handovers to other teams. For each task that may be affected, ask whether its instruction changes, whether completed output needs review and who will confirm the update. Avoid rewriting a completed task's history to make the new instruction appear to have applied all along. Create a revision or follow-up task where needed.
If the decision changes an approved project baseline, follow the project's change-control route before treating the changed work as authorised. Routine task clarification may not require that route.
Change Control vs Routine Clarification: When to Apply Each
- Change Control Required?Yes – if the decision alters an approved project baseline (e.g., scope, budget, timeline).
- Routine Task ClarificationNo – if only instructions for a task are refined without changing baseline. May not need formal approval.
- ExampleSwitching to a new prototype specification requires change control; clarifying test steps does not.
Connect the records both ways
The decision record should list the affected task IDs or work packages. Each changed task should reference the decision and state the applicable version or condition. The task can describe the action briefly; the decision record holds the reasoning.
If direct links are unavailable, use stable IDs in both records. Check that task owners can open what they need. A reference to a restricted document may be traceable to an administrator but unhelpful to the person doing the work.
Pros and Cons of Using Stable References for Decisions
- ProsEnsures traceability, supports audit readiness, prevents confusion from outdated links. Useful for ATO compliance and internal governance.
- ConsRequires discipline to maintain. Risk of broken links if IDs aren’t managed centrally. Can be hard to access for non-technical team members.
Confirm the update reached the work
Ask affected owners whether the revised task is clear and whether work already done needs review. Record exceptions and their owners. Check that no affected task still cites a superseded instruction without explanation.
When a later decision replaces an earlier one, mark the earlier record as superseded and point to its successor. The current task should show which decision applies now; its history should still explain why the work changed.
