Project Delivery Policy

1. Delivery lifecycle

Projects follow a consistent lifecycle: discovery and requirement analysis; solution strategy and architecture; UI/UX design; development in increments; testing and QA; security review; deployment; training and handover; then support and optimisation.

Not every project uses every phase in full, but the sequence is deliberate — particularly that architecture precedes build and security review precedes deployment.

2. Communication and cadence

Each project has a named Cyntra point of contact and an agreed communication channel.

You receive a written status update at an agreed interval — normally weekly — covering progress, upcoming work, risks and any outstanding dependencies on your side.

Working software is demonstrated at each increment, normally fortnightly, so progress is observable rather than described.

Project status, milestones, files and updates are visible in your client portal at any time.

3. Project status definitions

Statuses used in the client portal: Discovery, Proposal Approved, Deposit Paid, Design, Development, Internal Testing, Client Review, Revision, Security Review, Deployment, Training, Live, Maintenance, Completed, On Hold, Cancelled.

Health indicators: On Track, At Risk, Blocked. We change health to At Risk as soon as we see a credible threat to scope, schedule or quality — not after it materialises.

4. Milestones and acceptance

Projects are structured around milestones with defined deliverables, acceptance criteria and, where applicable, payment triggers.

Milestone acceptance follows the process in the Service Agreement Policy: a review window, then acceptance or a written variance list.

5. Risk and issue management

Risks are recorded with owner, impact and mitigation, and reviewed in status reporting. We raise risks early even when uncomfortable.

Issues affecting delivery are escalated to your named stakeholder within one business day of identification.

6. Escalation path

First: your project point of contact. Second: the Cyntra delivery manager for the engagement. Third: a Cyntra director at [email protected].

We aim to acknowledge escalations within one business day and respond substantively within three.

7. Timeline dependencies

Timelines assume: feedback within agreed review windows; availability of nominated stakeholders; provision of content, data and access as scheduled; and timely third-party responses where an integration depends on them.

Where these slip, we adjust the plan transparently rather than silently compressing testing or quality.

8. Handover and closure

Closure includes: deployment to production; documentation covering architecture, operations and administration; training sessions with recordings; transfer of repositories and infrastructure access; and a defined post-launch support period.

A closure review captures what worked and what did not. We use it to improve, and you receive the summary.

9. Projects on hold

Projects may be placed on hold at your request. Reserved delivery capacity cannot be held indefinitely; after 30 days on hold, resumption is subject to scheduling availability and may require re-baselining.

Amounts for work performed before a hold remain payable on normal terms.