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.
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 is assigned, sprint cadence is scheduled, project brief sign-off proof is stored/linked by AE (storage location is ad-hoc and decided by AE per client/project; access/visibility is decided by AE case-by-case based on client sensitivity; if restricted, AE provides a workable fallback case-by-case via a redacted Asana summary and/or a restricted link shared to the executing stakeholders; optional: include a 1-line quote of the approval text), key assumptions/risks are logged, comms channels are agreed, and initial milestones are 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.
PM + AE align on commercial impact and client communication
2
Legal is involved when contractual documents/terms require validation (MSA/SOW/change order/custom clauses)
3
Scope change requires a signed document (change order / updated SOW) before changed work starts.
4
Approval chain is case-by-case and decided by AE (based on deal/client sensitivity). Delivery should not start changed work until the chosen approvals are explicitly documented in Asana.
5
AE creates the Change Request Asana task and links the signed change order / updated SOW.
6
Change Request task content is case-by-case and decided by AE; at minimum include the signed document link (recommended: short summary + impact on price/timeline/milestones).
☐ 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
Post-Activation Estimation
Checklist
1
☐ Atomic tasks created with definition of done + acceptance criteria
2
☐ Estimated manhours added (by role where relevant)