Delivery Production & Resource Allocation Guideline
Department
Summary
How Kiluth runs delivery execution after project activation: estimation, work visibility, logging, burn visibility, and weekly management cadence. Four phases—Pre-Execution Setup, Planning & Estimation, Execution & Monitoring, Handle Scope Changes—with sprint-based execution and variance tracking.
Table of Contents
Purpose
This guideline defines how Kiluth runs delivery execution after project activation: estimation, work visibility, logging, burn visibility, and weekly management cadence.
| Outcome |
|---|
| Work is planned and tracked in a way that protects the team, makes progress visible, and keeps delivery/commercial expectations aligned. |
Go-live and acceptance are covered separately. See Client Acceptance (UAT) & Go-Live Guideline.
Scope
Roles
| Role | Responsibility |
|---|---|
| Project Manager (PM) | Post-activation estimation, task breakdown, visibility plan, sprint ceremonies, burn/variance tracking |
| Account Executive (AE) | Client coordination, scope change management, commercial alignment (when needed) |
| DEV / UX/UI / QA | Task execution, updates, actual manhour logging, review readiness |
| Business Executive | Capacity oversight, approval for deviations, risk escalation support |
Departments
| Department | Responsibility |
|---|---|
| Delivery | Execution and coordination |
| Account Management | Commercial coordination and client alignment |
| Technology / Creative | Implementation by discipline |
| Finance | Invoicing/payment coordination (deposit pre-kickoff; other payments when defined in contract) |
| Legal | Contract/terms validation when scope change affects contractual documents/terms |
| HR | Capacity context when needed |
Definitions
| Term | Definition |
|---|---|
| Project Code / Project ID | Project identifier generated in Kiluth ERPNext (e.g., PROJ-0023) |
| Sprint (Planning Cycle) | The planning frame used to group expectations and review progress. Default is 1 week; 2 weeks may be used when agreed |
| Kickoff complete (standard) | AE kickoff is considered complete when: PM assigned, sprint cadence scheduled, project brief sign-off proof stored/linked by AE, key assumptions/risks logged, comms channels agreed, and initial milestones confirmed |
| Visibility Plan | How PM makes work and progress visible: queue locking (when used), negotiated adjustments, milestones/deadlines, and recurring follow-ups |
| Estimated Manhour | Planned effort for a task (by role when relevant) |
| Actual Manhour | Actual effort logged on completion |
| Variance | Actual minus estimated (per task / per milestone) |
| Overburn | Actual manhours exceed estimated manhours (task or project) |
Operating Model (Sprint + Asana + Visibility)
At Kiluth:
| Operating Model | |
|---|---|
| 1 | Asana is the system of record for work tracking, approvals, and handoffs. |
| 2 | Use checkpoints and decision points: don’t move forward until the previous step is “done”, and branches are explicit. |
| 3 | Handoff order: upstream defines handoff artifacts/exit criteria; downstream defines execution after handoff. |
| Outcome |
|---|
| Everyone can answer: what are we doing this sprint, who owns it, what “done” means, and what is at risk. |
Delivery Execution Process Walkthrough
The delivery execution process follows four sequential phases. Each phase builds on the previous one and must be completed before moving to the next.
Process flow:
- Phase 1: Pre-Execution Setup - Verify project activation and complete kickoff
- Phase 2: Planning & Estimation - Create detailed task breakdown and visibility plan
- Phase 3: Execution & Monitoring - Execute work in sprints, track progress, and monitor variance
- Phase 4: Handle Scope Changes - When scope changes occur, align commercially and get approvals
Note: Phase 3 (Execution & Monitoring) is recurring and continues throughout the project lifecycle. Phases 1 and 2 are one-time setup activities.
Phase 1: Pre-Execution Setup
What you’ll do: Ensure the project is activated and kickoff is complete before starting delivery work.
Step 1: Verify Project Activation
Verify that project activation setup is complete and all prerequisites are met.
Prerequisites: Project has been activated per Scope Definition & Price Assessment Guideline > Phase 5: Contract & Activation Setup.
Process:
| Action | |
|---|---|
| 1 | Verify project code / Project ID exists (e.g., PROJ-0023) |
| 2 | Verify Projects board project card exists and is linked from the deal context |
| 3 | Verify Projects board project card is assigned to AE to signify handoff and kickoff initiation |
| 4 | Verify deposit is confirmed by Finance and recorded by Sales in Asana via comment (include confirmation + date; @mention Finance or Finance reply) |
| 5 | Verify deposit confirmation is recorded per Invoicing & Payment Operations Guideline |
Important: If deposit is delayed, do not activate the project and do not run kickoff. AE owns client follow-up and status updates.
Checkpoint: Proceed only when project code/ID exists, project card exists, deposit is confirmed, and AE confirms readiness for kickoff.
| Outcome |
|---|
| Project activation is verified and all prerequisites are met. AE confirms readiness for kickoff (project card + key links present; deposit confirmed; sign-off proof links for project brief + latest meeting minutes). |
Step 2: Complete Kickoff
Complete the standard kickoff process to prepare for delivery execution.
Prerequisites: Project activation is verified and AE confirms readiness for kickoff.
Process:
| Action | |
|---|---|
| 1 | Assign PM to the project and ensure PM has access to the project context |
| 2 | Set sprint length (1 week default / 2 weeks when agreed) |
| 3 | Schedule sprint cadence and account for it in capacity (see Phase 3: Execution & Monitoring > Weekly Cadence) |
| 4 | Link sign-off proof for project brief (AE responsible; signed document required if it includes contract-related decisions: scope, price, timeline, payment terms, milestones, acceptance criteria/DoD, change requests) |
| 5 | Link sign-off proof for latest meeting minutes (for key decisions and scope alignment; AE owns upkeep) |
| 6 | Log key assumptions and risks |
| 7 | Agree on communication channels and expectations |
| 8 | Confirm initial milestones |
Checkpoint: Proceed only when all kickoff items are complete.
| Outcome |
|---|
| Kickoff is complete. PM is assigned, sprint cadence is scheduled, sign-off proofs are linked, assumptions/risks are logged, comms channels are agreed, and initial milestones are confirmed. |
What happens next: Proceed to Phase 2: Planning & Estimation.
Phase 2: Planning & Estimation
What you’ll do: Create detailed task breakdown, estimates, and visibility plan before execution begins.
Step 1: Post-Activation Estimation
Complete post-activation estimation to create a detailed execution plan.
Prerequisites: Kickoff is complete.
Timing (Default):
| Timing | |
|---|---|
| 1 | Complete within 3 business days of activation (default target) |
| 2 | Earlier if the work is already in motion or deadlines are tight |
Process:
| Action | |
|---|---|
| 1 | Create atomic tasks in Asana with definition of done and acceptance criteria |
| 2 | Add estimated manhours (by role when relevant) to each task |
| 3 | Set milestones and create a realistic timeline (based on capacity) |
| 4 | Document dependencies, assumptions, constraints, and key risks |
Checkpoint: Proceed only when all required artifacts are created.
| Outcome |
|---|
| Execution can start with a shared plan and measurable “done”. Atomic tasks exist with DoD, manhour estimates, milestones, and documented dependencies/risks. |
Step 2: Create Visibility Plan
Create a visibility plan for the sprint to make work and progress visible.
Prerequisites: Post-activation estimation is complete.
Process:
| Action | |
|---|---|
| 1 | Create visibility plan that combines the following components (see checklist below) |
| 2 | If queue locking is used: create calendar blocks that reflect estimated manhours for committed work |
| 3 | If queue locking is used: reference Asana tasks in calendar block descriptions (include link) |
| 4 | Schedule follow-ups for milestones/deadlines and risk points |
| 5 | Communicate the visibility plan to the team |
Visibility plan components:
| Component | What it provides |
|---|---|
| Queue locking (calendar blocks) | Focus protection and a visible queue when calendar visibility helps the team |
| Negotiated flexibility | Team can move blocks and reorder work with PM, while preserving visibility |
| Milestones / deadlines / follow-ups | Recurring checkpoints so progress stays honest and risks surface early |
When queue locking is used - minimum requirements:
| Requirement | |
|---|---|
| 1 | Calendar blocks reflect estimated manhours for committed work |
| 2 | Blocks reference the Asana task (link in description) |
| 3 | Changes are communicated and kept visible (calendar + Asana updates) |
Checkpoint: Proceed only when visibility plan is created and communicated to the team.
| Outcome |
|---|
| Work remains visible and manageable even when plans move. Visibility plan exists with queue locking (when used), milestones/deadlines, and follow-ups scheduled. |
What happens next: Proceed to Phase 3: Execution & Monitoring.
Phase 3: Execution & Monitoring
What you’ll do: Execute work in sprints, track progress, and monitor variance/overburn. This phase is recurring and continues throughout the project lifecycle.
Step 1: Sprint Planning
Agree on sprint priorities, visibility plan, and commitments for the upcoming sprint.
Prerequisites: Visibility plan is created (Phase 2) or previous sprint is complete.
Timing: Monday morning (default cadence)
Process:
| Action | |
|---|---|
| 1 | Review sprint priorities and commitments |
| 2 | Agree on visibility plan for the sprint |
| 3 | Confirm team capacity and availability |
| 4 | Set sprint goals and success criteria |
Checkpoint: Proceed only when sprint planning is complete and team commitments are agreed.
| Outcome |
|---|
| Sprint priorities, visibility plan, and commitments are agreed. Team knows what they’re doing this sprint and what “done” means. |
Step 2: Execute Tasks
Execute work based on the visibility plan and sprint commitments.
Prerequisites: Sprint planning is complete.
Process:
| Action | Owner | |
|---|---|---|
| 1 | Begin work based on the visibility plan | Assignee |
| 2 | Complete task according to definition of done | Assignee |
| 3 | Log actual manhours in Asana | Assignee |
| 4 | Move task to In Review (or equivalent status) | Assignee |
| 5 | PM validates outcome against acceptance criteria | PM |
| 6 | If variance exists, PM documents variance and a short root cause | PM |
Checkpoint: Proceed only when tasks are completed, manhours are logged, and PM has validated outcomes.
| Outcome |
|---|
| Progress and burn are visible without relying on memory or chat history. Tasks are completed, manhours are logged, and variance is documented when it exists. |
Step 3: Weekly Cadence
Follow the weekly cadence to maintain alignment and surface risks early.
Prerequisites: Sprint is in progress.
Default cadence:
| Day | Ceremony | Purpose |
|---|---|---|
| Monday (morning) | Sprint planning | Agree sprint priorities, visibility plan, and commitments |
| Tuesday (morning) | AE + Business Executive sync | Align delivery/commercial priorities and risks |
| Wednesday (morning) | Weekly check-in | Progress check, unblock, adjust visibility plan |
| Friday (morning) | AE + PM sync | Align client expectations, scope changes (if any), delivery status |
| Friday (afternoon) | Sprint retro + QA | Improve process + confirm QA readiness/quality |
For 2-week sprints: Keep the weekly syncs/check-ins, and run planning/retro at sprint boundaries.
Process:
| Action | |
|---|---|
| 1 | Attend scheduled ceremonies according to the cadence |
| 2 | Share progress updates and surface risks |
| 3 | Adjust visibility plan as needed during weekly check-ins |
| 4 | Document decisions and action items in Asana |
Checkpoint: Proceed only when weekly cadence is followed and alignment is maintained.
| Outcome |
|---|
| Team alignment is maintained, risks surface early, and progress is visible. Weekly cadence ceremonies are completed and documented. |
Step 4: Monitor Variance & Overburn
Track estimated vs actual manhours and address variance and overburn.
Prerequisites: Tasks are being executed and manhours are being logged.
Process:
| Action | |
|---|---|
| 1 | Record estimated vs actual manhours (per task / per milestone) |
| 2 | Add a short reason when variance is meaningful (so we learn and adjust early) |
| 3 | If overburn occurs: make it visible (task/project notes) |
| 4 | If overburn occurs: identify root cause (short, factual) |
| 5 | If overburn occurs: decide corrective action (re-estimate, re-scope, adjust timeline/capacity) |
Variance (per task / milestone) - minimum practice:
| Practice | |
|---|---|
| 1 | Record estimated vs actual |
| 2 | Add a short reason when the variance is meaningful (so we learn and adjust early) |
Overburn response:
Overburn is a signal (estimation gap, scope change, complexity) and triggers a response:
| Action | |
|---|---|
| 1 | Make the overburn visible (task/project notes) |
| 2 | Identify root cause (short, factual) |
| 3 | Decide corrective action (re-estimate, re-scope, adjust timeline/capacity) |
Checkpoint: Proceed only when variance is tracked and overburn (if any) is addressed.
| Outcome |
|---|
| Variance is visible and documented. Overburn is identified, root cause is documented, and corrective action is decided. |
What happens next: Continue executing in sprints (return to Step 1: Sprint Planning) until project completion or scope change occurs. If scope change occurs, proceed to Phase 4: Handle Scope Changes.
Phase 4: Handle Scope Changes
What you’ll do: When scope changes occur, align commercially and get approvals before proceeding with changed work.
Step 1: Identify Scope Change
Identify when work exceeds the agreed scope.
Prerequisites: Work is being executed and scope deviation is identified.
Process:
| Action | |
|---|---|
| 1 | PM identifies that work exceeds the agreed scope |
| 2 | PM documents the scope change and impact (short, factual) |
| 3 | PM notifies AE of the scope change |
Checkpoint: Proceed only when scope change is identified and documented.
| Outcome |
|---|
| Scope change is identified and documented. PM and AE are aware of the change. |
Step 2: Commercial Alignment
Align on commercial impact and client communication.
Prerequisites: Scope change is identified.
Process:
| Action | |
|---|---|
| 1 | PM + AE align on commercial impact and client communication |
| 2 | If contractual documents/terms require validation (MSA/SOW/change order/custom clauses): involve Legal |
| 3 | Coordinate with Legal for review if needed (see Contracting & Change Order Workflow Guideline) |
Checkpoint: Proceed only when PM and AE are aligned on commercial impact and Legal is involved (if needed).
| Outcome |
|---|
| PM and AE are aligned on commercial impact. Legal is involved when contractual validation is needed. |
Step 3: Get Approval & Signed Document
Get required approvals and obtain signed change order or updated SOW.
Prerequisites: Commercial alignment is complete.
Process:
| Action | |
|---|---|
| 1 | AE creates Change Request Asana task |
| 2 | AE determines approval chain case-by-case (based on deal/client sensitivity) |
| 3 | Get required approvals (approval chain is case-by-case and decided by AE) |
| 4 | Obtain signed document (change order / updated SOW) - signed document is required before changed work starts |
| 5 | Link signed change order / updated SOW in the Change Request task |
| 6 | Document approvals explicitly in Asana |
Change Request task content (case-by-case, decided by AE):
| Content | |
|---|---|
| 1 | At minimum: include the signed document link |
| 2 | Recommended: short summary + impact on price/timeline/milestones |
Important: Delivery should not start changed work until the chosen approvals are explicitly documented in Asana and signed document exists.
Checkpoint: Proceed only when signed change order / updated SOW exists, approvals are documented in Asana, and AE confirms work can proceed.
| Outcome |
|---|
| Delivery reality and commercial expectations stay aligned (no silent absorption). Signed change order / updated SOW exists and is linked. Approvals are documented in Asana. |
Step 4: Proceed with Changed Work
Proceed with changed work only after approvals and signed document are in place.
Prerequisites: Signed change order / updated SOW exists and approvals are documented in Asana.
Process:
| Action | |
|---|---|
| 1 | Confirm signed document is linked in Change Request task |
| 2 | Confirm approvals are documented in Asana |
| 3 | Update task breakdown and estimates if needed |
| 4 | Proceed with changed work |
Checkpoint: Proceed only when all approvals are in place and signed document exists.
| Outcome |
|---|
| Changed work proceeds with proper approvals and signed documentation. Commercial alignment is maintained. |
What happens next: Return to Phase 3: Execution & Monitoring to continue delivery with the updated scope.
Deviation Process
If the team needs to deviate from this playbook:
| Step | |
|---|---|
| 1 | Document the deviation and why (in Asana/project notes) |
| 2 | Align with Business Executive when the deviation impacts capacity, timeline, or risk |
| 3 | Keep the alternative plan visible (same principle: visibility over enforcement) |
Delivery Execution Checklist (PM Use)
This checklist is used by PM to track progress for each project. Complete each item in order where applicable.
Phase 1: Pre-Execution Setup
Project Activation Setup (Precondition)
| Checklist | |
|---|---|
| 1 | ☐ Project code / Project ID exists (e.g., PROJ-0023) |
| 2 | ☐ Projects board project card exists and is linked from the deal context |
| 3 | ☐ Projects board project card is assigned to AE to signify handoff and kickoff initiation |
| 4 | ☐ AE confirms readiness for kickoff (project card + key links present; deposit confirmed; sign-off proof links for project brief + latest meeting minutes) |
| 5 | ☐ Deposit confirmation is recorded per Invoicing & Payment Operations Guideline |
| 6 | ☐ Deposit is confirmed by Finance and recorded by Sales in Asana via comment (include confirmation + date; @mention Finance or Finance reply) (pre-activation/kickoff). If deposit is delayed, do not activate the project and do not run kickoff (AE owns client follow-up and status updates). |
Kickoff (Standard)
| Checklist | |
|---|---|
| 1 | ☐ PM is assigned and has access to the project context |
| 2 | ☐ Sprint length is set (1 week default / 2 weeks when agreed) |
| 3 | ☐ Sprint cadence is scheduled and accounted for in capacity (Weekly Cadence (Default)) |
| 4 | ☐ Sign-off proof: Link (project brief; AE responsible; signed document required if it includes contract-related decisions: scope, price, timeline, payment terms, milestones, acceptance criteria/DoD, change requests) |
| 5 | ☐ Sign-off proof: Link (latest meeting minutes; for key decisions and scope alignment; AE owns upkeep) |
| 6 | ☐ Key assumptions/risks are logged |
| 7 | ☐ Communication channels and expectations are agreed |
| 8 | ☐ Initial milestones are confirmed |
Phase 2: Planning & Estimation
Post-Activation Estimation
| Checklist | |
|---|---|
| 1 | ☐ Atomic tasks created with definition of done + acceptance criteria |
| 2 | ☐ Estimated manhours added (by role where relevant) |
| 3 | ☐ Milestones/timeline set based on capacity |
| 4 | ☐ Dependencies/assumptions/constraints/risks documented |
Work Visibility Plan
| Checklist | |
|---|---|
| 1 | ☐ Visibility plan agreed (queue locking when used + negotiated adjustments + milestones/deadlines + follow-ups) |
| 2 | ☐ If queue locking is used: calendar blocks created and linked to tasks |
| 3 | ☐ Follow-ups scheduled for milestones/deadlines and risk points |
Phase 3: Execution & Monitoring
Execution & Logging
| Checklist | |
|---|---|
| 1 | ☐ Tasks updated and moved to In Review when ready |
| 2 | ☐ Actual manhours logged on completion |
| 3 | ☐ PM validates and documents meaningful variance (short root cause) |
Overburn / Scope Change
| Checklist | |
|---|---|
| 1 | ☐ Overburn made visible and addressed (root cause + corrective action) |
| 2 | ☐ If scope change: PM + AE aligned on commercial impact; Legal involved when contractual validation is needed |
Phase 4: Handle Scope Changes
| Checklist | |
|---|---|
| 1 | ☐ Scope change identified and documented |
| 2 | ☐ PM + AE aligned on commercial impact |
| 3 | ☐ Legal involved when contractual validation is needed |
| 4 | ☐ Change Request Asana task created by AE |
| 5 | ☐ Signed change order / updated SOW obtained and linked |
| 6 | ☐ Approvals documented in Asana |
| 7 | ☐ Changed work proceeds only after signed document and approvals are in place |