The Supply Chain Technology team operates across five product squads and one shared development squad. Each product squad covers a defined tech stack domain. The Development Squad is a shared service that allocates outsourced engineering capacity across all product squads, following an Agile delivery approach.

1.1 Squad Model Overview

Five product squads own their respective tech stack domains end-to-end, from discovery through sustain. Each squad operates the four-role model: Solution Architect, Product Manager, Product Owner, and QA Engineer. The QA Engineer role is currently active in the ERP squad only; all other squads have the role planned.

1.2 Role Definitions and Accountability

Each squad role carries distinct accountability. Roles are not interchangeable. The Solution Architect activates at design and integration gates; the Product Manager holds product vision and roadmap; the Product Owner owns sprint-level execution; the QA Engineer governs outsourced developer output against [Organisation] engineering standards.

1.3 PM Coverage Map

SCT technology changes are top-down driven by business strategy and bottom-up shaped by available technology features and project constraints. Three independent but connected domains - Business Requirement, Product Epic and Features, and Project Definition - merge through an iterative roadmap cycle to produce a single plan view.

2.1 Five-Layer Change Driver Model

All SCT tech changes trace to one of five layers. The model is hierarchical: upper layers define the problem space; lower layers define how the solution is delivered. A change that cannot be traced to this hierarchy requires re-evaluation before proceeding.

2.2 3-Way Planning Model: Ops Demand, Tech Supply, and Roadmap

Business requirements, product feature maps, and project definitions are decoupled but connected through a three-way matching roadmap iteration cycle. This produces a single holistic plan view merging business demand, tech supply, and delivery gap planning.

The three domains merge through the project roadmap, project plan, and sprint cycle. business units drive the demand lead via iterative weekly release cycles. Vendor and project input provides capacity and release commitment. System change requirements feed the sprint backlog cycle. The output is implementation and release: UAT, data migration, and go-live readiness.

2.3 SCT vs Business Unit PMO Responsibilities

SCT owns PMO administration for SCTech Tech Stack changes. Non-SCTech Tech Stack projects are Enterprise/SCT Product Squad-led; SCT provides an assistant role for data gathering, system specifications, process, and integration requirements. The Supply Chain group has no dedicated PMO resource. All project administration operates as cross-department shared assigned responsibility, structured like OKR ownership.

2.4 Enterprise Tech Group Database Architect Collaboration Model

SCT operates SaaS platforms on shared [Organisation] infrastructure. The Enterprise Tech Group Database Architect holds authority over infrastructure standards, database configuration, security access controls, and performance governance across all [Organisation] tech stacks. SCT Product Managers and the Solution Architect engage the Enterprise Tech Group Database Architect as a standing collaboration partner across four domains.

SCT operates a five-phase product lifecycle. All SCTech domain projects follow this lifecycle. Phases are sequential with defined sign-off gates between them. Requirement and scope changes trigger change control back to the relevant sign-off gate.

3.1 Phase Overview

3.2 Cross-Functional Business Analysis Framework

The SCT cross-functional BA framework spans ideation to deployment. The Australia team drives ideation and innovation. The Philippines team handles sprint backlog and development. The BA workstream spans the full lifecycle with sign-off gate authority at Discovery, Describe, and Co-create phase exits.

SCT CAB Decision Principles

• No better option exists for achieving the stated requirement
• Agreed risks and opportunities are documented and accepted by the relevant stakeholders
• Change plan readiness is confirmed - deployment checklist, rollback plan, and test coverage are complete

SCT CAB Scope by Period

3.3 Quick-Win Methodology for Logistics

The quick-win methodology delivers Logistics business unit outcomes in two phases. Phase 1 produces a manual process roll-out, enabling the business unit to operate immediately while system development proceeds in parallel. Phase 2 replaces the manual process with system automation.

3.4 Agile for SaaS Methodology

SCT project deliverables follow defined format standards. Each artefact is produced in a specific format: Slide, Spreadsheet, Table, or Swimlane process map. Ownership is assigned by RACI across the BA (SCT), Enterprise/SCT Product Squad, and SaaS/SCT Product Squad layers.

4.1 Deliverable RACI by Phase

4.2 Document Format Reference

4.3 Architecture Document Types by Stack Domain

SCT manages 13 tech stack domains across two stack components: Delivery Technology and Interactive Technology. Each domain has a designated PM owner and a full set of architecture documents.

5.1 Domain Map Overview

5.2 Delivery Tech Stack

• ERP ([ERP Platform]) covers 8 capabilities: Plan, Purchase, Move, Inventory, Pick and Pack, Consign, Ship, and Track and Trace
• Carrier consignment integrators ([Carrier Consignment Integrator], [Carrier Consignment Integrator]) handle outbound consignment creation
• TMS ([TMS Platform]) covers trip planning, vehicle skillsets, and driver operations
• [Carrier Scan Data Platform] provides carrier scan event ingestion, milestone mapping, and predictive EDD
• AI capabilities available: Recognition, Correlation, Interpretation, and Storytelling offerings
• RPA capabilities available: Read, Drive, Convert, and Send offerings

5.3 Interactive Tech Stack

• Communication: [Contact Centre Platform] channels - Voice, Email, Chats, Social Media (all Digital First Omnichannel)
• Knowledge Decision: Knowledge management via [Knowledge Management Platform]; quick search index; policy and business rules; process flow sequence
• Self-Serve Workflow: Understand problem, self-serve agreement, assign workflow - powered by [Core Platform] (pre-configured and un-preconfigured rules)
• Collaboration: Customer cases, Operations cases, and Sales opportunity via [Case Management Platform] Service Cloud and Sales Cloud

5.4 Transport Tech Stack Vision

5.5 ERP Tech Stack Vision

5.6 CCaaS Stack

• [Contact Centre Platform] CX capabilities: Voice, Email Omnichannel, Chat Omnichannel, Social Media Omnichannel, Work Item Routing
• [Contact Centre Platform] WE capabilities: Workforce Management, Workforce Optimisation, Quality Management, Reporting
• [Integration Automation Platform] handles PO detail handoff from [Core Platform] to [Case Management Platform]; all customer interaction notes in [Case Management Platform] are handed to [Core Platform] via [Integration Automation Platform]
• [Chatbot Platform] ([Chatbot Platform]) chatbot uses [Knowledge Management Platform] articles as knowledge base; creates a [Case Management Platform] case after each handled chat

5.7 [Case Management Platform] Business Capability Map

Each role owns a defined set of deliverables. Deliverables are specific named artefacts, not activity descriptions. Use this section for performance reviews, onboarding, and project planning.

6.1 Solution Architect

• Technical design document and blueprint
• Conceptual and logical data models
• Object model diagram
• Database schema
• Integration flow diagram
• Non-Functional Requirements (NFRs)
• Technology stack recommendation
• Position paper for architecture and integration decisions (Appendix C)
• SCT Change Advisory Board lead (for tech architecture decisions)

6.2 Product Manager

• Product feature value-level ownership
• Product strategy and vision document
• Vendor engagement and performance record
• Past feature release (capability hierarchy)
• Future feature pipeline (18 months)
• Feature release roadblock dependency log
• Business process flow diagram
• Capability map and product hierarchy
• Product roadmap
• Business case and financial modelling
• Tech market landscape analysis
• Product service level agreement definition

6.3 Product Owner

• User story-level execution
• Prioritised product backlog
• Epics, user stories, and acceptance criteria
• Feature release roadblock dependency log
• Sprint goals and iteration plan
• Definition of Done tracking
• Backlog refinement and grooming sessions
• Stakeholder review and acceptance log
• Business change request and user change management
• Platform configuration and master data records
• UAT coordination and business user sign-off log

6.4 QA Engineer

• Test strategy document (regression, functional, integration, UAT coverage)
• Sprint-level test plans aligned to delivery scope
• Test case execution records against consultant deliverables
• Defect log with triage status and resolution cycle tracking
• Code review records with standards compliance findings
• Traceability matrix (business requirements to test cases to delivered objects)
• Release readiness assessment and quality gate sign-off
• SCT CAB representation report (change scope, impact, and risk mitigation)
• Post-deployment validation records during hypercare
• QA SOPs and testing standards documentation

6.5 Development and Deployment Manager

• Development and deployment planning and scheduling
• Work Breakdown Structure and actual cost report
• Deployment pipeline status report
• Code quality and technical debt register
• CI/CD pipeline status and code repository maintenance
• Tech Incident Report including Root Cause Analysis
• Test coverage record
• Technical Deployment Log

6.6 Product Configuration and Internal Control

• Access control and licence management register
• Data security requirements documentation
• Data and transaction traffic usage report
• Data retention policy and implementation record
• SOP and Internal Annex Control Action Register
• Incident response plan
• QBR reporting and engagement record
• Internal control audit log
• Software asset management register
• Configuration change log
• Product knowledge register
• Super user training records
• Tech incident management log

SCT applies structured change governance to all tech stack changes through two tiers of CAB. The SCT CAB is the internal governance mechanism for reviewing and approving all SCT tech specification changes before implementation. Above SCT, the Enterprise Tech Group CAB governs changes at the enterprise level; SCT holds a standing representative seat at Enterprise Tech Group CAB. Project charter sign-off gates control phase progression. Roadmap freeze rules protect peak operational periods.

7.1 SCT CAB Process

SCT CAB Decision Criteria

• No better option: the proposed change is the best available approach to meet the stated requirement
• Agreed risks and opportunities: all material risks are documented, and relevant stakeholders have accepted them
• Change plan readiness: deployment checklist, rollback plan, test coverage, and business communication are complete

7.2 Change Management Components

7.3 Roadmap Governance and Freeze Rules

7.4 Project Charter and Sign-Off Gates

Every SCTech domain project requires a project charter. The charter is a live document; details and scope change during problem, data, process design, and tech fit-gap assessment. All charter changes route to project sponsor sign-off. The charter carries four live architecture documents: Approach, Feature Glidepath, High-Level Model and Process Flow, and Mechanics.

SCT PMs operate to a defined cadence across daily, sprint, monthly, and quarterly cycles. The cadence ensures alignment between squad delivery, business unit stakeholders, and vendor performance without relying on ad hoc scheduling.

8.1 Cadence Calendar

8.2 Sprint Cycle Standards

• Sprint length: one week, aligned to the weekly release cadence
• Sprint backlog items derive from the system change specification and prioritised product backlog - not directly from business requirements
• Sprint goal is set at planning and confirmed by the PM and Product Owner jointly
• Failed tests during the Scale phase return to the sprint backlog; the sprint goal is adjusted and re-committed
• Work Breakdown Structure tracks actual cost against planned cost per sprint; the Development Manager owns this record
• Definition of Done applies to every user story before the Product Owner accepts it
• Sprint velocity is tracked by the Development Manager and reported at the monthly roadmap review

8.3 Vendor and SaaS QBR Structure

SCT prioritises features through a structured scoring framework applied jointly by the PM and the business unit sponsor. Prioritisation feeds the 18-month product pipeline and the sprint backlog iteration cycle.

9.1 Prioritisation Criteria and Scoring

Each feature request is scored across five criteria. The PM and business unit sponsor score independently; scores are reconciled at the monthly roadmap review. Items scoring below 10 total are deferred to the next review cycle unless an escalation applies.

9.2 Roadmap Iteration Cycle

• Demand input: business unit submits business requirement with problem statement, objective, benefit, and business scope at the monthly roadmap review
• Supply assessment: PM and Solution Architect assess available SaaS features, integration options, and development capacity against the demand
• Gap planning: PM produces a gap plan identifying the project definition required - charter, RACI, fit-gap map, system change specification, and change management components
• Roadmap update: PM updates the 18-month pipeline with the prioritised feature, estimated delivery quarter, and dependency flags
• Sprint feed: confirmed roadmap items are broken into sprint backlog items by the Product Owner at the next backlog refinement session

9.3 Backlog Management Rules

• The product backlog is owned by the Product Owner; the PM sets priority direction jointly with the business unit sponsor
• Every backlog item must have a linked business requirement, user story, acceptance criteria, and Definition of Done criteria before entering a sprint
• Items without a linked business requirement are parked in the icebox and reviewed at the next backlog refinement session
• The top 10 backlog items are groomed to sprint-ready state at every refinement session
• Backlog items do not enter the sprint until the Product Owner confirms they are technically feasible and fully scoped
• Scope changes to in-sprint items require PM and Product Owner joint approval; significant changes trigger change control back to the relevant sign-off gate
• Backlog items not progressed in 3 cycles are escalated for PM decision: defer, cancel, or expedite

SCT PMs engage with four stakeholder tiers: SCT leadership, business unit operations, [Organisation] product and engineering, and external vendors. Each tier has defined engagement protocols, decision rights, and communication expectations.

10.1 Stakeholder Map

10.2 Engagement Protocol

• Lead with the business outcome: open every stakeholder communication with the result or decision required, not the activity or process context
• Escalate blockers within one sprint: any blocker that cannot be resolved within the current sprint cycle escalates to the SCT Head and the relevant business unit sponsor before the next sprint planning session
• Document all decisions: every feature prioritisation decision, scope change, and SCT CAB outcome is recorded in the relevant log
• Confirm acceptance in writing: Product Owner acceptance of sprint items, business user UAT sign-off, and project sponsor charter approval are confirmed in writing before proceeding

10.3 Business Unit Collaboration Principles

SCT maintains a structured knowledge management service covering SOP creation, [Knowledge Management Platform] filing, and the product knowledge register. PMs hold accountability for the currency and completeness of knowledge assets within their squad domain.

11.1 SOP Creation Workflow

11.2 [Knowledge Management Platform] Filing and Indexing

• SOPs file under the capability process map structure: Capability → Process → SOP
• Architecture documents file under the relevant stack domain: Domain → Document Type
• Carrier playbooks file under the Transport domain; each carrier has a dedicated playbook page
• Product knowledge registers file under the relevant squad domain
• All files are version-controlled with a last-updated date and review cycle date
• The searchable index is updated within 24 hours of a new or revised document being filed
• Documents older than the defined review cycle trigger an alert to the PM for review or retirement

11.3 Product Knowledge Register Maintenance

SCT manages three distinct budget lines: SaaS licence costs, developer vendor spend, and project cost tracked through Work Breakdown Structure (WBS). Budget planning is owned jointly by Finance, the Supply Chain Group, and the SCT Head. During execution, the Product Manager owns budget planning detail and projection; the Product Manager and Product Owner track actual spend against WBS commitments throughout delivery.

12.1 Budget Ownership Model

12.2 Budget Planning Cycle

12.3 In-Delivery Cost Tracking

12.4 Vendor Invoice Approval Process

• PM receives invoice from vendor and validates against the contract rate, WBS deliverables completed in the invoiced period, and licence entitlement purchased
• PM flags any discrepancy to the vendor before submitting to SCT Head - no invoice proceeds to approval with an unresolved discrepancy
• SCT Head approves the invoice and submits to Finance for payment processing
• PM records the approved invoice in the product knowledge register under the SaaS vendor details section
• Developer vendor invoices that include scope outside the approved WBS are rejected and returned to the vendor with a written scope clarification

The Definition of Done applies to every user story before the Product Owner accepts it. A story is done only when all criteria below are met. Partial completion does not qualify.

Tech incidents generate corrective actions. Where a corrective action requires a system change, it enters the product backlog through a defined pipeline. Incidents do not bypass the backlog or sprint prioritisation process except for P1 escalations.

A position paper is a short, structured decision document produced by the Solution Architect when a technology, integration, or architecture choice carries material risk, cost, or irreversibility. It is not a design document and not a requirements document. It states a problem, evaluates the available options, and recommends one. The reasoning is made explicit so that the SCT Head, PM, and business unit sponsor can make an informed decision and own it.

A position paper is the right artefact when a decision cannot be reversed without significant cost or rework, when two or more viable options exist and the choice is not obvious, or when the decision affects more than one squad domain or system boundary.

C.1 When to Write a Position Paper

Produce a position paper before committing to any of the following:

• A new system integration or change to an existing integration method (API, flat file, stored procedure, or middleware)
• A SaaS platform configuration decision that cannot be undone without vendor involvement or data migration
• An architecture choice that affects shared [Organisation] infrastructure, requiring Enterprise Tech Group Database Architect review
• A build-vs-configure-vs-buy decision for a capability gap
• A vendor selection or vendor replacement decision
• Any decision that the PM or SCT Head flags as requiring documented rationale before proceeding

C.2 Position Paper Elements

Each position paper contains seven mandatory elements. Incomplete position papers are returned without review.

C.3 Quality Standard

A position paper meets the standard when:

• The problem statement can be read in isolation and the reader immediately understands what decision is being made
• Every option in the assessment could be implemented - no straw-man options included to make the recommendation look obvious
• The recommendation traces directly to the assessment - no conclusion not supported by the evidence in the document
• The document is no longer than two pages excluding the sign-off block - if longer, the scope is too broad and the problem statement needs to be narrowed
• A non-technical business stakeholder can read the recommendation and risks section and understand what is being decided and what could go wrong

A position paper does not meet the standard when:

• It recommends an option without documenting at least one disadvantage of that option
• It lists more than four options - more than four signals the problem statement is under-defined
• The context section describes project history rather than the specific conditions driving the decision
• The risk section lists generic risks (e.g. project delay, budget overrun) without tying them to the specific recommended option

C.4 Sign-off Authority

The Work Breakdown Structure (WBS) is the authoritative cost control document for every SCT project. The PM builds the WBS at project charter initiation. The Development and Deployment Manager validates engineering effort estimates and tracks actuals each sprint. The SCT Head approves the WBS before any developer vendor engagement commences. No vendor invoice is approved against work that is not traceable to an approved WBS line item.

D.1 WBS Hierarchy

Every SCT project WBS follows a four-level hierarchy. Each level rolls up to the level above. Cost and effort are always entered at Level 4 (task). Totals aggregate upward automatically through the hierarchy.

D.2 WBS Element Definitions

Every task (Level 4) in the WBS carries the following elements. All fields are mandatory before the task enters the approved WBS. Incomplete tasks are not approved by the SCT Head and do not proceed to developer vendor engagement.

D.3 WBS Governance Rules

• The PM builds the initial WBS at project charter initiation. The WBS is submitted to the SCT Head for approval before any developer vendor engagement commences.
• The Development and Deployment Manager updates actual cost and sprint status each sprint. The PM reviews the WBS at every sprint planning session.
• Any change to scope, estimated hours, cost rate, or sprint allocation that affects the total work package cost requires a WBS amendment approved by the SCT Head before work continues.
• Vendor invoices reference the WBS code and work package. The PM validates every invoice line against the corresponding WBS task before submitting the invoice to the SCT Head for payment approval.
• Tasks with status Blocked or Deferred for more than one sprint are escalated to the SCT Head with a written resolution plan.
• The WBS is version-controlled. Each approved version is saved with a date stamp. Superseded versions are retained in the product knowledge register for audit purposes.
• At project close, the Development and Deployment Manager produces a final WBS actual vs. planned cost report. The PM presents this report to the SCT Head and includes it in the post roll-out validation deliverable.

D.4 WBS Template Structure

The standard SCT WBS template uses the column structure below. One row per task. The spreadsheet auto-calculates Total Cost (Planned) and Variance columns. The template is maintained in [Knowledge Management Platform] under the SCT Knowledge Management space.

Complete all items within the first 30 days. Week 1 items are pre-requisites for attending sprint ceremonies. Weeks 3–4 items are pre-requisites for taking full PM accountability for the squad domain.

The following documents are the authoritative references for SCT methodology, architecture, process hierarchy, and operating model. All squad members read the documents relevant to their role before commencing work in those domains.