Delivery playbook

Delivery & Managed Services Playbook

The methodology page explains how we think; this page shows how a project is actually governed — who decides, what is accepted, how change is controlled and what you receive each week and each month. The example artefacts below are anonymised illustrations of the format, not real client data.

Short answer

MadeByCat runs projects in defined phases with decision and approval gates, a written RACI, acceptance criteria and a change-control process. Risks, issues and dependencies are tracked in one register and reported weekly. After launch, a stabilisation period leads into managed services with priority levels, incident handling, security updates, performance monitoring, monthly reporting and a continuous-improvement backlog. Response targets and any SLA are defined per contract rather than promised as fixed numbers here.

01

Phases and decision gates

Each phase of the Madebycat Loop ends with a gate: a short, documented decision that the phase output is accepted and the next phase can start. Gates prevent work continuing on assumptions that nobody has approved.

  • Align → Discover: goals, stakeholders, success measures and decision owners agreed.
  • Discover → Architect: research findings and content inventory accepted.
  • Architect → Design: scope, sitemap, content model and technical approach approved.
  • Design → Engineer: key templates, components and prototypes approved.
  • Engineer → Operate: QA, accessibility and content readiness accepted; go-live plan signed off; launch and stabilisation complete.
  • Operate → Evolve: monthly reporting and backlog reviews feed the next improvement cycle.
02

Roles and RACI

Every deliverable has one accountable owner. A RACI (responsible, accountable, consulted, informed) is agreed at kickoff and updated when the team changes.

  • Client project owner — accountable for decisions, approvals and internal stakeholder alignment.
  • MadeByCat project lead — accountable for plan, delivery quality and reporting.
  • Design and engineering leads — responsible for their outputs and for estimating change requests.
  • Content owners — responsible for content supply, legal review and final publishing approval.
  • Infrastructure and third-party providers — responsible for their own systems, referenced in the plan.
03

Acceptance criteria and revision limits

Acceptance criteria are written before work starts: what the deliverable must include, which devices and browsers are tested, and which accessibility and performance checks apply. Design phases include an agreed number of revision rounds; further rounds or changes of direction are handled through change control so the plan stays honest.

04

Change control

New requests are welcome, but they are logged rather than absorbed silently. Each change request is described, estimated for effort and schedule impact, and approved or deferred by the client project owner. Approved changes update the plan and the budget visibly.

05

Risk, issue and dependency tracking

One register holds risks (what might happen), issues (what has happened) and dependencies (what we are waiting for, from whom and by when). Each entry has an owner, a date and a status, and the register is reviewed in the weekly status meeting.

06

Example: weekly status report (anonymised)

Illustrative format only — not client data.

  • Overall status: [Green / Amber / Red] — [one-line reason per workstream].
  • Completed this period: [approved deliverables and closed gates].
  • Planned next period: [deliverables in progress and upcoming reviews].
  • Decisions needed: [decision] · Owner: [client or studio role] · Needed by: [date].
  • Top risks and dependencies: [reference to open register entries].
07

Example: risk register entry (anonymised)

Illustrative format only — not client data.

  • ID: [register reference] · Type: [risk / issue / dependency] · Description: [what might happen, has happened or is awaited].
  • Impact: [affected scope] · Likelihood: [low / medium / high] · Owner: [named role].
  • Mitigation: [agreed action] · Escalation path: [steering forum].
  • Status: [open / monitoring / closed] · Review date: [date].
08

Stabilisation, documentation, training and handover

Go-live is followed by a stabilisation period in which the launch team fixes defects with priority and watches monitoring closely. Documentation covers architecture, deployment, content types and editor workflows. Editors receive training on the CMS, and handover includes access, release history and open backlog — whether the site moves to our managed services, your team or another partner.

09

Managed services: priorities and incident handling

In managed services, requests and incidents are classified by priority so urgent problems are not queued behind routine changes. Incidents follow a written path: detection, acknowledgement, investigation, fix or workaround, communication and — for severe cases — a post-incident review.

Response and resolution targets, working hours and any SLA are defined per contract, based on the site and the client’s needs. We do not publish fixed response times here, and we do not provide 24/7 staffed cover unless it is explicitly contracted.

10

Example: incident priority matrix (anonymised)

Illustrative categories only — actual targets are set in each service description.

  • P1 Critical — site or a core journey unavailable for most users; handled first, with continuous updates.
  • P2 High — a key function degraded or unavailable for some users; handled ahead of scheduled work.
  • P3 Medium — non-critical defect with a workaround; scheduled into the next release.
  • P4 Low — cosmetic issue or minor improvement; added to the backlog and prioritised in review.
11

Security updates, performance monitoring and monthly reporting

CMS, framework and dependency updates are applied on a schedule, with urgent security patches handled through the fast lane. Availability, errors and Core Web Vitals are monitored on key templates. A monthly report summarises what was released, incidents and their handling, performance and accessibility trends, and the backlog proposed for the next period.

12

Example: monthly managed-services report (anonymised)

Illustrative format only — not client data.

  • Releases: [scheduled releases and urgent fixes in the period] · Release notes: [link].
  • Requests: [received / closed / carried over, with agreed dates].
  • Incidents: [priority class P1–P4] · [summary] · Root cause and fix: [documented / pending].
  • Quality: [Core Web Vitals trend on key templates] · Accessibility: [issues found and closed].
  • Next period: [proposed backlog items for client prioritisation].
13

Backlog and continuous improvement

Beyond requests, the team proposes improvements based on analytics, monitoring and editor feedback. The backlog is reviewed with the client regularly, and items are prioritised by impact and effort rather than by who asked loudest.

Frequently asked questions

Do you commit to fixed response times?
Response and resolution targets are agreed per contract and priority level. We do not publish a single fixed number because it depends on the site, hours of cover and the client’s requirements.
Are the example reports real client data?
No. They are anonymised illustrations of the format we use. Real reports are shared only with the client concerned.
What if we want to change scope mid-project?
Changes go through change control: described, estimated for effort and schedule, and approved by your project owner before they enter the plan.
Can we move the site to another team later?
Yes. Code, content and configuration are yours, and handover includes documentation, access and release history.
Do you hold security certifications?
We do not claim security certification or provide penetration testing ourselves. Where required, these are contracted with specialist providers and referenced in the plan.

See how your project would be governed

Share your internal approval process and the teams involved. We will map phases, gates and responsibilities to your organisation.

Contact us→