Program Structure & Roles

2.1 Delivery model overview

Projects and programs are delivered through cross-functional Agile teams organized into streams. Each stream owns a defined scope and delivers value incrementally via Scrum. A centralized governance layer ensures alignment, consistent reporting, and proactive risk management.

2.2 Team & stream structure

Each delivery stream must include, at minimum:

• Product Owner (content & priority)
• Scrum Master (facilitation & process)
• Stream Lead / Project Manager (delivery accountability)
• Developers
• Testers / QA
• Technical Lead or Architect (dedicated or shared)

2.3 Program-level structure

Mandatory when multiple streams are involved, cross-stream dependencies are material, or delivery risk is high:

2.4 Single source of truth

Roles, Responsibilities & Decision Rights

3.1 Core delivery roles

3.2 RACI principles

Rather than large static matrices, each major deliverable or milestone must have one accountable owner plus clear contributors and reviewers. Accountability cannot be delegated even when work is assigned. RACI clarity must be established at initiation, backlog refinement, and release/cutover planning.

3.3 Escalation ownership

• The raiser remains responsible for tracking the issue
• The escalation owner is responsible for decision-making
• All escalations must be logged in the RAID register, discussed in the appropriate governance forum, and closed with a documented decision or action

RAID & Escalation Management

4.1 RAID definitions

4.2 Escalation levels & thresholds

4.3 Escalation SLAs

4.4 RAID register rules

The standardized RAID Google Sheet (PMO-provided template in IH Google Drive) is the mandatory system of record. Each item must include: Type, Description, Owner, Impact (H/M/L), Likelihood (for risks), Mitigation/resolution plan, Target date, and Current status.

4.5 Closure criteria

A RAID item can only be closed when: the risk is mitigated or no longer relevant; the issue is resolved and verified; or the dependency is fulfilled and accepted. Closure must be recorded in the RAID register, linked to related Jira items, and supported by a decision or evidence.

Governance & Meeting Cadence

5.1 Governance forums & cadence

5.2 Meeting discipline

• Meetings are time-boxed — attendees arrive prepared
• Side discussions are taken offline
• Decisions are prioritized over information sharing
• Meetings may be cancelled if there are no decisions/risks to address, or required inputs are not ready

5.3 Governance outputs

Every forum must produce: decisions made (with owner and date), actions agreed (with owner and due date), RAID updates, and escalations if unresolved. Outputs must be captured in Confluence or the RAID register and communicated to impacted teams within 24 hours for scope/timeline/cost/quality decisions.

Communication & Documentation Standards

6.1 Communication principles

• Slack is the primary real-time communication tool
• Asynchronous communication is preferred over meetings where possible
• No project-critical information should exist only in chat history
• All key decisions, actions, and outcomes must be documented and traceable
• Communication must be professional and appropriate for client visibility

6.2 Mandatory Slack channels

6.3 Slack rules

• Use threads for all discussions beyond a single message
• If a decision is made in Slack: state it explicitly ("Decision: …") and document it in Confluence or the relevant tracker
• Never use Slack for final documentation, formal approvals, or long-term tracking of risks, actions, or decisions

6.4 Documentation standards

IH Google Drive is the only approved storage for project documentation, delivery artifacts, plans, designs, reports, and templates. "Anyone with the link" permissions are prohibited — all documents must inherit access from approved IH Google Drive folders following least-privilege principles. Project documentation must never be stored on personal or private drives.

Delivery Lifecycle Overview

7.1 Delivery principles

• Agile/Scrum-based delivery is the default unless explicitly agreed otherwise with the PMO
• Value is delivered incrementally and frequently; early validation is prioritized over late big-bang delivery
• Teams are empowered to self-organize within agreed boundaries
• Transparency, early risk identification, and fast feedback are mandatory
• Governance exists to enable delivery and decision-making — not reporting only
• Documentation is fit-for-purpose, not exhaustive

7.2 Lifecycle stages

Initiation & Delivery Setup

8.1 Intake & triage

All work entering delivery must go through formal intake and triage. Trigger: new initiative request or material change to an existing initiative. Owner: PMO Lead (process) + Sponsor/Requestor (business).

8.2 Kickoff & alignment

A formal kickoff must be completed before sprint delivery begins. Owner: Stream Lead / PM.

Mandatory kickoff checklist

• Sponsor, PO, Stream Lead/PM, Scrum Master identified
• Delivery objectives and success criteria agreed
• High-level scope and exclusions confirmed
• Initial backlog or scope outline reviewed
• Initial RAID items captured in RAID Google Sheet
• Governance forums and cadence confirmed
• Communication channels agreed (Slack channels created)
• Documentation locations confirmed (IH Google Drive / Confluence)

8.3 Jira & Confluence setup standards

Delivery may not start until tooling is set up. Owner: Stream Lead / Scrum Master.

• Jira project and board created; issue hierarchy defined (Epics, Stories, Bugs); workflow aligned; required fields enabled
• Confluence space created with standard page structure

8.4 Initiation exit criteria

Scrum Delivery SOPs

9.1 Backlog refinement

9.2 Sprint planning

9.3 Daily Scrum

9.4 Sprint review / demo

Trigger: end of each sprint. Owner: Product Owner. Duration: 60–90 min. Show only completed, accepted stories. Demonstrate working functionality — not slides. Capture all feedback as backlog items via standard refinement process. Material scope changes must follow Change Control (Section 12).

9.5 Sprint retrospective

Trigger: end of every sprint (unless explicitly tailored). Owner: Scrum Master. Duration: 60–90 min. Structure: review previous actions → reflect (what went well / didn't / improve) → identify root causes → agree 1–3 actionable improvements → assign named owners with target dates. Document in Confluence. Focus on process and collaboration, not individual performance.

9.6 Scrum of Scrums

Owner: PMO Lead or Program Delivery Lead. Duration: 30–60 min. Frequency: weekly (twice weekly for high-risk programs). Each stream answers: on track? blocking or blocked? Each meeting: dependency review from RAID → cross-stream risk review → integration/release alignment → escalations & decisions. Output: updated RAID, clear cross-stream action owners, escalations raised.

Quality Gates — DoR & DoD

10.1 Definition of Ready (DoR)

User Story — DoR

A user story is Ready when ALL of the following criteria are met:

• Clear and concise description in standard format (As a / I want / So that)
• Specific and testable acceptance criteria provided
• Sign-off of acceptance criteria received from the Product Owner
• All dependencies identified and documented
• Team has reviewed and has a shared understanding of what needs to be done
• Technical approach has been discussed and validated for feasibility
• Necessary data for the user story is available
• Story has been estimated in story points by the full team
• Story has been prioritized for the upcoming sprint
• Feedback from relevant stakeholders is addressed
• No unresolved impediments preventing the team from starting work

Sprint — DoR

• Clear and achievable sprint goals identified
• Sprint backlog contains prioritized, well-refined stories meeting DoR
• Sprint backlog contains enough stories for the full sprint duration
• Potential sprint risks identified and mitigated
• Necessary environments available and configured
• All team members have necessary access and permissions
• Sprint planning completed; tasks agreed for each story
• No known blockers that would prevent sprint from proceeding

10.2 Definition of Done (DoD)

User Story — DoD

• Code complete per project coding standards, naming conventions, and best practices
• Apex unit tests written and passing with ≥90% code coverage (unless waived by Lead Architect)
• Implementation reviewed and approved by a peer or lead
• Changes tracked and migrated to QA; included in the pipeline
• Implemented metadata list documented on the user story (API mappings, triggers, elements)
• Test cases created and reviewed
• Guidance provided to QA team when moving to QA Testing
• Feature passed QA testing including functional and regression testing
• All critical bugs identified by QA are fixed
• Testing results documented by QA team
• 100% delivered and passed QA code deployed to target environment

Sprint — DoD

• All committed user stories meet their individual DoD and are marked Ready for UAT
• All critical and high-priority bugs resolved and tested (or moved to next sprint as highest priority)
• Internal sprint demo or walkthrough completed
• All deliverables packaged and prepared for UAT/production release if required
• Training materials or user guides prepared (if applicable)
• External demo completed; client feedback captured and reflected in backlog

Status Reporting Standards

11.1 Reporting cadence

• Stream Status Report Submission: Weekly, end of business Friday
• PMO Review & Consolidation: Completed by end of business Monday
• Executive / SteerCo Reporting: As per governance cadence (bi-weekly or monthly)

11.2 Standard status report content

11.3 RAG status definitions

11.4 Non-compliance handling

Initial: PMO notifies the Stream Lead; correction requested immediately. Repeated (2+ consecutive cycles): escalated to Program Delivery Director and discussed in PMO & Stream Leads governance forum. Accountability for accuracy cannot be delegated.

Change Control

12.1 Principle: backlog is the primary change mechanism

All new requirements, feedback, or enhancement ideas must be captured as backlog items. Changes must not bypass the backlog and enter delivery directly. Typical sources: sprint review feedback, stakeholder requests, technical discoveries, integration constraints, regulatory updates.

12.2 Formal change thresholds

12.3 Change approval workflow (major changes)

12.4 Handling mid-sprint changes

Jira Standards & Hygiene

13.1 Issue hierarchy

13.2 Naming conventions

Issue summaries must be concise, descriptive, and action-oriented.

Format: [Stream/Area] Brief description of work — e.g., [CPQ] Add validation for contract renewal date

Bug summaries must begin with the environment tag: [QA] Error when saving Quote Line Item / [UAT] Contract PDF missing header logo / [PROD] Deployment rollback button unresponsive

13.3 Required fields (all issues)

13.4 Story pointing rules

Story pointing is done in refinement sessions by the full development team. Velocity is guidance — never a performance target. Any story estimated above 13 points must be broken down.

13.5 Jira hygiene rules

• Never commit more story points than team velocity; reserve ~15% capacity for bug fixing
• Work on stories in priority order
• Update statuses daily — must be current before each stand-up
• Add comments when a story takes longer than estimated or is blocked
• If blocked, move to 'Blocker' status with a comment explaining why
• All acceptance criteria changes after 'Ready for QA': strike through old criteria (do not delete), add new, tag stakeholders, add comment explaining the change

13.6 Jira workflow statuses (CCI project)

To Do → Ready for Development → In Progress → Blocker → Code Review → Ready for QA → QA In Progress → QA Fail → Ready for UAT → UAT In Progress → Approval Requested → Ready for Stage → Deployed to Prod → Done

Defect / Bug Management

14.1 Bug linking rules

All bugs must be linked to a user story to maintain traceability and support impact analysis.

14.2 Bug priority standards

14.3 Environment validation rules

• Bugs raised in QA: validate only in QA environment during retesting
• Bugs raised in UAT: validate in both QA and UAT environments before closure to ensure consistency

14.4 Bug closure workflow

If a bug linked to a story is not marked as 'blocks' and its priority is Medium or Minor, the story can proceed to Ready for UAT without waiting for the bug to be resolved.

14.5 Root cause analysis

The Root Cause field must be completed by the Development Team for every bug before closure. This feeds quality improvement, defect prevention, and reporting metrics. Root cause categories should include: requirement gap, design error, coding error, environment/configuration, test data, external dependency.

PMO Hygiene Audit Process

The Weekly PMO Audit ensures bug management standards, Jira hygiene, and reporting processes are consistently followed across all streams.

15.1 Audit scope & cadence

• Frequency: Weekly, every Friday morning
• Conducted by: PMO Team
• Reported to: Stream Leads, QA Leads, and Program Director at weekly Scrum of Scrums
• Scope: All bugs and Jira issues raised during the week across all environments (QA, UAT, PROD)

15.2 Audit checklist

15.3 Reporting & non-compliance

Audit findings summary sent to all Stream Leads and QA Leads every Friday EOD. Key items highlighted: non-compliant bugs with direct links for action, streams with repeated non-compliance, top improvement areas. PMO flags critical hygiene issues to Stream Leads for immediate correction. Repeated non-compliance escalated to Program Director and discussed at weekly PMO & Stream Leads Sync.

Release & Cutover Management

16.1 Release planning & calendar

A release calendar must be maintained and shared with all delivery teams and stakeholders. Each release must have: a release ID, target environment, release owner (Stream Lead/PM), planned date, actual date, and release notes. Release dates must be reflected in the RAID register as dependencies for all upstream delivery work.

16.2 Release readiness criteria

No release may proceed until all of the following are confirmed:

• All user stories in scope meet the Definition of Done
• All critical and major bugs resolved and retested
• UAT sign-off received from the Product Owner and business stakeholders
• Deployment runbook documented and reviewed by the technical team
• Rollback plan defined and tested (where applicable)
• Go/no-go decision documented by the Stream Lead/PM
• All impacted teams notified of the release window
• Monitoring and alerting confirmed in place for production
• Support/hypercare team identified and briefed

16.3 Cutover planning & rehearsal

For complex or high-risk releases, a cutover plan is mandatory. The cutover plan must include:

• Step-by-step deployment sequence with assigned owners and estimated durations
• Environment dependencies and sequencing
• Data migration steps (if applicable) with validation checkpoints
• Communication plan for internal teams and end users
• Smoke test plan post-deployment
• Rollback trigger criteria and rollback steps

For major releases, at least one rehearsal of the cutover plan must be conducted in a non-production environment before go-live.

16.4 Go-live, rollback & hypercare

Go-live: Execute deployment runbook as approved. All steps logged with timestamps. Smoke test executed immediately after deployment. Business validation by PO within agreed window.

Rollback: Rollback is triggered when smoke tests fail or critical issues are identified within the rollback window. The decision to roll back rests with the Stream Lead/PM in consultation with the Technical Lead. All rollback decisions must be logged and communicated immediately to stakeholders.

Hypercare: A defined period (typically 5–10 working days) of heightened support post-release. The support team monitors for defects, tracks tickets, and provides daily status updates to the PMO. Hypercare formally closes when defect rate stabilizes and business confirms normal operation.

Closure & Handover

17.1 Deliverable acceptance

All deliverables must be formally accepted before the project closes. Each deliverable must have:

• Documented acceptance criteria (defined at initiation)
• Evidence of testing and validation (QA results, UAT sign-off)
• Written acceptance confirmation from the Product Owner or business stakeholder

Partially completed deliverables must be either completed, formally descoped via Change Control, or transitioned to a subsequent project with documented acknowledgment.

17.2 Documentation completion

The following must be complete and filed in IH Google Drive and Confluence before project closure:

• Final status report and project summary
• All sprint summaries and retrospective notes
• Updated RAID register with all items closed or formally transitioned
• Release notes and deployment documentation
• Test results, defect logs, and UAT sign-offs
• Architecture and technical design documentation
• Training materials and user guides (if applicable)
• Change log with all approved changes traceable to delivery

17.3 Transition to operations / product ownership

Ownership must be explicitly transferred — never assumed. The handover includes:

• Operational runbooks and support documentation
• Access and permissions transferred to the operations/product team
• Outstanding defects documented and prioritized for the receiving team
• Known risks and dependencies communicated to the new owner
• Formal handover meeting with the operations/product team

17.4 Closure confirmation & sign-off

The project is formally closed when: all deliverables are accepted in writing, all documentation is complete and filed, ownership has been transitioned, and the PMO Lead confirms closure in the PMO register. A closure notice must be sent to all stakeholders including: summary of outcomes, key metrics (velocity, quality, timeline vs plan), and confirmation of handover.

Benefits & Lessons Learned

18.1 Benefits review

A benefits review must be conducted at project closure and, for longer programs, at key milestones. The review compares realized outcomes against the objectives defined at initiation. Key questions:

• Were the intended business outcomes achieved?
• Were scope, timeline, and cost targets met? If not, what were the variances and why?
• What is the measurable value delivered (quantitative where possible)?
• What additional benefits or unexpected outcomes were realized?

Benefits review outputs must be filed in Confluence and shared with the Program Sponsor and PMO.

18.2 Lessons learned capture

Lessons learned must be captured at the end of every project — not only when things go wrong. The process:

18.3 Continuous improvement input to PMO

The PMO reviews lessons learned from all completed projects quarterly. Actionable improvements are incorporated into the next playbook version cycle. Changes to mandatory standards require formal PMO Lead approval and versioning. Teams are encouraged to submit improvement suggestions to the PMO at any time — not only at project closure.

AI Ways of Working (2026)

19.1 Approved AI use cases

19.2 Guardrails & accountability

• The human who submits, approves, or publishes an AI-assisted artifact owns it fully
• AI-generated outputs must not be submitted to clients without human review
• AI must not be used to process confidential client data, PII, or proprietary commercial information in public/third-party tools unless approved by legal/compliance
• All AI tool usage on project work must be disclosed to the PMO if requested
• Prompt engineering is encouraged — a prompt library is maintained in Appendix J

19.3 Data classification & confidentiality rules

Initiation Checklist

Use this interactive checklist to confirm a project is ready to begin sprint delivery. Check off items as they are completed.

Sprint Readiness Checklist

Use before each sprint to confirm the team is ready to commit and execute.

Release Readiness Checklist

Complete this checklist before any production deployment. The go/no-go decision must be formally documented.