Owner: Project Manager (PM)
Contributors: Head of Delivery (HoD) — standards authority ·
All delivery team members — Jira board users
Department: D4 — Delivery
Entity: PrivateAI
Status: v1.0 · Active
Version: 1.0 | Last updated: 2026-07-18
What this workflow does: Governs how all delivery work is planned, tracked,
and reported across every engagement type — the Jira standards, sprint conventions,
board structures, reporting cadence, blocker escalation rules, and the definition
of done that apply universally across DEL-02, DEL-03, DEL-04, and all other
delivery workflows.
What triggers it: Always active — applies from the moment a new engagement
is confirmed and a Jira board is set up through to engagement close and board
archival. Every delivery team member follows these standards on every engagement.
What it produces: A consistently structured, current, and accurate Jira board
per engagement — the single source of delivery truth — plus weekly status summaries,
blocker escalation logs, and a clean board handover at engagement close.
Why it matters: Inconsistent task management is the most common cause of
missed deliverables, billing disputes, and client surprises. DEL-08 is the
foundation that every other delivery workflow builds on — if the board is wrong,
everything downstream is wrong.
| Role | Department | Responsibility |
|---|---|---|
| PM | D4 | Primary owner — sets up and maintains Jira boards, runs sprint ceremonies, produces status summaries, manages blockers, closes boards at engagement end |
| HoD | D4 | Standards authority — approves board structure before first sprint, reviews blocker escalations, signs off board closure |
| All delivery team members | D4 | Update their own Jira cards daily — status, hours logged, blockers flagged |
Every new engagement gets its own Jira project. The PM sets up the board before
the first sprint or delivery week begins.
Mandatory board configuration:
| Element | Standard |
|---|---|
| Project name | [Client code] — [Engagement type] — [Start month YYYY] e.g. ACME-AIe-Jul2026 |
| Board type | Scrum (AI Projects, AIc) · Kanban (AIe ongoing) |
| Columns | To Do · In Progress · In Review · Done · Blocked |
| Epic structure | One epic per scope section or delivery phase |
| Labels | aie / aic / ai-project / internal / reachback / blocker / change-request |
| Custom fields | Contracted hours · Hours logged · Delivery week or sprint number |
| Access | PM · HoD · Account Lead (view) · Client (view-only if agreed in SOF) |
HoD board approval: HoD reviews and approves the board structure before the
first sprint or delivery week begins. No delivery work is tracked on an unapproved
board.
Every Jira card must have:
| Field | Requirement |
|---|---|
| Title | Clear, action-oriented — what is being done, not just a topic |
| Description | What, why, acceptance criteria, and any dependencies |
| Assignee | Single owner — never unassigned |
| Due date | Specific date or sprint end |
| Epic | Linked to the correct epic |
| Hours logged | Updated daily by the assignee |
| Status | Kept current — never left in wrong column |
Definition of done (applies to every card):
A card is Done when:
Step 1 — Create Jira project and board
Step 2 — HoD board approval
Step 3 — Load initial backlog
Step 4 — Sprint planning (Scrum boards — AI Projects, AIc)
Step 5 — Daily board updates
Step 6 — Blocker management
blocker labelStep 7 — Weekly status summary
Step 8 — Sprint review (Scrum boards)
Step 9 — Change request management
change-request labelled card in Jira. PM assesses time and cost impact withStep 10 — Hours and budget tracking
Step 11 — Stale task detection 🤖
Step 12 — Engagement close — board archival
| Tool | How it's used | Agent-ready |
|---|---|---|
| Jira | Primary system of record — all engagement boards, cards, sprints, worklogs, blockers, change requests | Yes — confirmed |
| Google Workspace | Weekly status summaries, change request documentation, board review notes | Yes — API + MCP |
| Discord | Internal blocker escalation notifications · weekly summary sharing | Yes — API |
| Google Meet | Sprint planning, sprint review, blocker resolution calls | Yes |
| n8n | Planned: stale task detection, blocker alerts, weekly summary auto-draft | Yes — native |
Board approval (Step 2)
| Condition | Action | Owner |
|---|---|---|
| Board structure correct | Approve — proceed | HoD |
| Changes needed | PM corrects — resubmit | PM → HoD |
Blocker escalation (Step 6)
| Blocker type | Action | Owner |
|---|---|---|
| Technical | Escalate to HoD same day | PM → HoD |
| Client-side | Notify Account Lead same day | PM → Account Lead |
| Internal | PM resolves or escalates to HoD | PM → HoD |
Hours and budget (Step 10)
| Signal | Action | Owner |
|---|---|---|
| Within contracted band | Continue | PM monitors |
| Approaching ±10% limit | Flag to Account Lead | PM → Account Lead |
| Overage | HoD + Account Lead + SOF amendment | PM → HoD + Account Lead |
Change request (Step 9)
| Client decision | Action | Owner |
|---|---|---|
| Approves | Add to backlog · amend SOF if commercial | PM + Account Lead |
| Declines | Close card with decline noted | PM |
| Scenario | How to handle | Escalation |
|---|---|---|
| Team member not updating cards daily | PM flags same day. If recurring, HoD notified — feeds DEL-11 performance review. | PM → HoD |
| Sprint scope cannot be completed in time | PM flags to HoD by sprint day 3 at the latest. Scope adjusted or sprint extended. Client informed by Account Lead. | PM → HoD → Account Lead |
| Client requests access to live Jira board | PM configures view-only access if agreed in SOF. Never edit access to client. | PM + Account Lead confirm SOF |
| Board structure needs mid-engagement change | PM proposes change to HoD. HoD approves. PM implements and notifies team. | PM → HoD |
| Hours logging gap discovered mid-engagement | PM audits and corrects based on stand-up logs and communication records. Note the gap in the weekly summary. | PM — no escalation unless material |
| Engagement extended beyond original timeline | PM creates new sprint(s) or extends Kanban board. HoD notified. SOF amendment if commercial impact. | PM → Account Lead → HoD |
| Metric | Type | Target |
|---|---|---|
| Jira board approved before first delivery day (%) | Process | 100% |
| Cards updated daily by all team members (%) | Process | 100% — weekly PM audit |
| Blockers flagged within same day (%) | Process | 100% |
| No blocker unaddressed > 24 hours (%) | Leading | 100% |
| Weekly status summary sent by Friday (%) | Process | 100% |
| Board archived within 5 days of engagement close (%) | Process | 100% |
| Hours logged within contracted band ±10% (%) | Leading | 100% |
| Step | Current state | Suggested automation | Tool | Effort |
|---|---|---|---|---|
| Step 11 — Stale task detection | Manual weekly check | n8n AI triage agent: daily scan for cards not updated > 3 days → Discord alert to PM and assignee | n8n + Jira | Medium |
| Step 7 — Weekly status summary | Manual | n8n Friday trigger → pull Jira data → auto-draft status summary → PM reviews and shares | n8n + Jira + Google Docs | Medium |
| Step 6 — Blocker alert | Manual (PM checks daily) | n8n: Jira blocker label added → immediate Discord notification to PM and HoD | n8n + Jira + Discord | Low |
| Step 10 — Hours tracking alert | Manual weekly check | n8n weekly worklog pull → flag if approaching ±10% of contracted band → notify PM | n8n + Jira | Low |
| Step 12 — Board archival reminder | Manual | n8n: engagement close event → 5-day countdown → reminder to PM to archive board | n8n + Jira | Low |
This workflow governs task management for:
Downstream (feeds into):
| Version | Date | Description | Author |
|---|---|---|---|
| 1.0 | 2026-07-18 | Initial release — Jira board standards, card standards, definition of done, sprint and Kanban conventions, blocker escalation SLAs, change request management, stale task detection (manual + planned automation), board archival process. | Hamza Tasneem (HoD) |