Project Task Creation & Approval Playbook

A Guide for Predictable Delivery in Implementation Projects

Introduction

In implementation projects, the most common source of failure is not poor execution but committing work that is ambiguous, underdefined, or dependent on unknowns. Tasks often fail because their outcomes are unclear, prerequisites are missing, or the person assigned does not have authority or the right skills. This playbook exists to guide team members in creating tasks that are predictable, verifiable, and actionable, ensuring project plans are reliable and execution is smooth.

A task is not just an action; it is a verifiable outcome. If you cannot define what “done” looks like in a measurable way, the work belongs in a discovery or decision category rather than a task. By focusing on deterministic tasks, the team can minimise rework, reduce delays, and maintain clarity in execution.

​

Understanding Deterministic Work

Before drafting a task, it is crucial to distinguish between deterministic and non-deterministic work. Deterministic work has a clearly defined outcome, known methods, and the assignee has the necessary authority and skill. This is the work that can enter a project plan. Non-deterministic work — such as research, experimentation, or decisions where outcomes are uncertain — should not be treated as a task. Instead, it should be explicitly classified as Discovery or Decision work.

Treating non-deterministic work as a task introduces risk and false predictability. By strictly enforcing deterministic task creation, teams can ensure that every item in the plan is actionable, measurable, and complete.

Anatomy of a Task

A well-formed task is a complete, accountable unit of work. Each task should contain several attributes that make it verifiable, traceable, and schedulable. Understanding these attributes and why they matter is essential for creating tasks that are likely to succeed.

Title: The title of a task should describe the observable outcome, not the effort required. For example, “Check invoices” is ambiguous, while “All customer invoices include GST and client PO number” is precise and verifiable. A clear, atomic title ensures that anyone reviewing the task can understand the intended result immediately. Additionally, the title should be a summary of the body/description

Body / Description: The description provides context, instructions, references to specifications or SoW items, and guidance on how the outcome should be achieved. This section is where you embed examples, warnings, and clarifications. Avoid introducing unknowns or leaving the task open to interpretation.

Allocated Time and Estimated Effort: Assigning an estimated time helps with realistic scheduling and resource planning. Estimates should be based on prior experience and include buffers only when justified. This allows project managers to anticipate workload and prevent hidden schedule slippage.

Time Consumed / Tracking: Recording actual effort provides feedback for continuous improvement. Comparing estimates against actual time taken helps refine planning for future tasks.

Assignee / Owner: Each task must have a single owner with the authority and skills to complete it. Clear ownership prevents confusion and ensures accountability.

Dependencies / Blocked By: Explicitly list any prerequisites or dependencies required before the task can start. Hidden dependencies are a common source of delay, so transparency is critical.

Sub-tasks: Complex work should be broken into smaller, independently verifiable sub-tasks. Each sub-task must itself be deterministic, ensuring progress is measurable and trackable.

Linked SoW / Contract Reference: Whenever relevant, link tasks to specific deliverables or contractual obligations. This traceability supports accountability, auditability, and clear client communication.

Success Criteria / Evidence / Completion Artefacts: Define what constitutes proof of completion. This could be a document, a system report, or any artefact that clearly demonstrates the task is done. Evidence must be objective and verifiable.

Status / Binary Completion: Track tasks strictly as Done or Not Done. Partial completion creates ambiguity and undermines the integrity of project planning.

Progress: Percentage complete - Especially for larger tasks to enable project managers to accurately plan

Priority / Risk Indicators: Optionally, tasks may include indicators of risk or urgency, derived from the pre-commit evaluation. This helps in scheduling critical work and identifying fragile tasks.

Notes / Attachments: Include supporting information or clarifications that aid understanding, but avoid assumptions that compromise determinism.

Formulating a Task

When creating a task, the guiding principle is that it should describe an outcome rather than an action. Tasks must be atomic, focusing on a single verifiable result. Sub-tasks and dependencies should also meet the same deterministic criteria. For instance, instead of writing “Update warehouse system,” a proper task would be “All warehouse locations enforce maximum capacity of 500 units.” This defines a measurable, achievable outcome that can be confirmed without ambiguity.

Pre-Commit Assessment: 8 Principles

Once a task is drafted, the team should evaluate it using a pre-commit assessment. This ensures that the task is ready for inclusion in the project plan. The assessment evaluates the task against eight core principles:

1. Outcome Known: The exact end state is fully defined.
2. Authority Held: The assignee has the authority to complete the task independently.
3. Inputs Available: All required inputs are present or guaranteed.
4. Scope Bounded: The task is fully bounded and predictable.
5. Known Capability: The assignee possesses the necessary skills and tools.
6. Binary Completion: Completion can be determined without subjective interpretation.
7. Evidence Defined: There is explicit evidence to confirm completion.
8. Dependencies Explicit: All dependencies are declared and assigned.

Every task must pass a pre-commit assessment before being accepted into the project plan. This ensures the task is deterministic, verifiable, and actionable. Each principle is explained below with guidance and examples.

1. Outcome Known

• Meaning: The exact end state of the task is fully defined. There should be no ambiguity about what constitutes success.
• Why it matters: If the outcome is unclear, the task cannot be verified and may lead to rework.
• How to evaluate: Ask, “If this task is complete, what exactly will exist or be observable?”
• Example:
  • Bad: “Check invoices” → unclear what “check” means.
  • Good: “All customer invoices include GST and client PO number” → clear, observable result.

2. Authority Held

• Meaning: The assignee has the authority to complete the task without requiring approval or intervention from others.
• Why it matters: Tasks assigned to someone without authority will stall, causing delays.
• How to evaluate: Ask, “Can the assignee take full responsibility and deliver this outcome?”
• Example:
  • Bad: “Approve invoice discrepancies” assigned to a junior who cannot authorise payments.
  • Good: Task assigned to the finance officer with approval authority.

3. Inputs Available

• Meaning: All materials, data, resources, and information required to complete the task are present or guaranteed.
• Why it matters: Missing inputs block execution and invalidate planning.
• How to evaluate: Ask, “Are all files, systems, or approvals needed available now?”
• Example:
  • Bad: “Reconcile stock discrepancies” without receiving updated inventory counts.
  • Good: “Reconcile stock discrepancies using the latest inventory report dated [DD/MM/YYYY].”

4. Scope Bounded

• Meaning: The task has clearly defined boundaries; it is not open-ended or infinite.
• Why it matters: Undefined scope leads to “mission creep” and delayed delivery.
• How to evaluate: Ask, “Does this task have a start and finish? Can it be completed independently?”
• Example:
  • Bad: “Improve warehouse efficiency” → open-ended.
  • Good: “Relocate top 50 most popular SKUs to shipping area to reduce picking time” → bounded.

5. Known Capability

• Meaning: The assignee has the skills, tools, and knowledge to complete the task.
• Why it matters: Without capability, the task may fail or require unexpected support.
• How to evaluate: Ask, “Does the assignee have experience or training to execute this task?”
• Example:
  • Bad: Assigning a system configuration task to someone unfamiliar with the platform.
  • Good: Assigning the same task to a trained system administrator.

6. Binary Completion

• Meaning: Task completion can be measured as done or not done — no “almost” or “partially” done.
• Why it matters: Partial completion creates ambiguity and undermines planning reliability.
• How to evaluate: Ask, “Can a reviewer clearly verify whether this task is complete?”
• Example:
  • Bad: “Review invoices” → what constitutes a full review?
  • Good: “All invoices from October 2025 are verified for GST and client PO number.”

7. Evidence Defined

• Meaning: There is clear evidence that the task has been completed. Evidence should be objective and verifiable.
• Why it matters: Without evidence, completion is subjective and disputes arise.
• How to evaluate: Ask, “What artefact or record proves this task is done?”
• Example:
  • Bad: “Clean warehouse” → no proof defined.
  • Good: “Warehouse aisles 1–10 cleaned and photographed; logs uploaded to project folder.”

8. Dependencies Explicit

• Meaning: All tasks, approvals, or conditions that must occur before this task are clearly documented.
• Why it matters: Hidden dependencies block work, disrupt schedules, and reduce predictability.
• How to evaluate: Ask, “Is anything required from other teams or tasks clearly listed?”
• Example:
  • Bad: “Deploy system update” → assumes database backup is complete, but not documented.
  • Good: “Deploy system update after DB backup (Task #123) is completed and verified.”

Scoring and Action

• Pass all 8 principles: Task is approved for inclusion in the project plan.
• Fail 1–2 principles: Task requires rework before approval.
• Fail more than 2: Task is invalid as deterministic work; reclassify as discovery or decision work.

By evaluating each task against these principles, team members ensure that only high-quality, verifiable, actionable tasks enter the project plan. This dramatically increases predictability, reduces rework, and aligns execution with project objectives.

Execution Guidance

Once approved, a task should be treated as a mechanical unit of work. Partial completion or scope changes should not be allowed. Sub-tasks, evidence, and dependencies should be tracked carefully. If assumptions become invalid or obstacles arise that compromise the determinism of the task, the task should be cancelled and re-created to maintain the integrity of the plan.

Traceability

Every task should be linked to the broader project framework, including SoW items, deliverables, or contractual clauses. This traceability allows for auditability, reporting, and post-mortem review. It ensures that every piece of work contributes directly to the project’s objectives and that accountability is maintained throughout.

Examples

Consider a task initially drafted as “Check invoices.” This is vague and leaves room for interpretation. A proper, deterministic task would be “All customer invoices include GST and client PO number,” which is measurable, verifiable, and leaves no ambiguity.

For discovery work, a draft like “Determine optimal backup frequency” is not a task because the outcome is unknown. It should be classified as Discovery. Once the outcome is defined, such as “Nightly automated backups run successfully and reports are generated,” it can become a delivery task.

Sub-tasks illustrate how complex work can be broken down. For the task “Implement warehouse location capacity limits,” sub-tasks could include configuring system rules, testing locations with sample inventory, and validating reports against the limits. Each sub-task is itself deterministic and independently verifiable.

Task Title and Pre-Commit Assessment

Task Title Guidance

The title of a task is the first thing anyone sees, and it must clearly convey the intended outcome. The recommended format is:

[Object] [is/has/does] [verifiable state]

This format ensures the title is actionable, measurable, and unambiguous, but it also serves as a summary of the information contained in the body or description. In other words, someone reading the title alone should have a good sense of the expected outcome without needing to read the full description — though the body provides the full context, instructions, references, and examples.

For example:

• Bad title: “Update warehouse system” — vague, no measurable outcome.
• Good title: “All warehouse locations enforce maximum capacity of 500 units” — clearly states the observable result, matches the body description, and is verifiable.

The body then explains how this outcome is achieved, including steps, dependencies, sub-tasks, supporting documents, or examples. The title is the summary, the body is the instruction and context.