Methodology

Five phases. One delivery discipline.

Every engagement runs through the same five phases — sized to scope, but never skipped. The endpoint is a platform your team owns, with documentation deep enough to outlast staff turnover and a residual-risk register your audit function can sign for.

Discuss an engagement All services
At a glance

The five phases.

Sequenced so each phase produces the artefacts the next phase depends on.

Phase Goal Typical duration
01 — Assess Discover the current state and produce the case for the work. 1–3 weeks
02 — Design Produce a reference architecture and operating model that engineering can build against. 3–6 weeks
03 — Deploy Build the platform and onboard the first workloads, sequenced so each layer is fully ready before the next depends on it. 8–20 weeks
04 — Operate Stand up the day-2 operations practice that survives staff turnover. 4–8 weeks (overlapping with Deploy)
05 — Hand over Transfer ownership so the customer's team owns the platform with documentation deep enough to outlast staff turnover. 2–4 weeks
01
Phase 01

Assess

1–3 weeks

Discover the current state and produce the case for the work.

Activities

  • Stakeholder interviews and current-state walkthrough
  • Technical-debt and architectural-risk profile
  • Regulatory and compliance mapping to current platform
  • Use-case prioritisation (where AI is in scope)
  • Build-vs-buy and effort-vs-impact ranking

Deliverables

  • Current-state diagnostic with named gaps and concrete impact
  • Recommended engagement scope with ranked options
  • Indicative budget, timeline, and risk register
  • Go/no-go recommendation

Team shape: Lead engineer + practice lead from CompTech Lab; sponsor and 2–4 technical stakeholders from the customer side.

02
Phase 02

Design

3–6 weeks

Produce a reference architecture and operating model that engineering can build against.

Activities

  • Reference architecture across platform, identity, security, and integration boundaries
  • Operating model: GitOps shape, on-call structure, change management
  • Architecture decisions (ADRs) for every non-obvious choice
  • Risk register with mitigation strategies
  • Detailed implementation plan and acceptance criteria

Deliverables

  • Reference architecture document (diagrams + narrative)
  • ADR set for non-obvious decisions
  • Operating model definition (responsibility matrix, on-call, change paths)
  • Implementation plan with sequenced workstreams
  • Acceptance criteria for each major milestone

Team shape: Lead engineer + 1–2 senior engineers from CompTech Lab; platform-lead and security-lead from the customer side; architecture-review board if one exists.

03
Phase 03

Deploy

8–20 weeks

Build the platform and onboard the first workloads, sequenced so each layer is fully ready before the next depends on it.

Activities

  • Foundation: networking, DNS, identity, credential custody, image supply, source control
  • Platform: cluster install (connected, disconnected, or hybrid), GitOps bootstrap, multi-cluster management
  • Security posture: runtime security, supply chain, secret custody, audit logging
  • Application delivery path: build, scan, sign, deploy
  • First workload onboarding with the customer's application team

Deliverables

  • Running platform matching the reference architecture
  • Install manual reproducible against a fresh environment
  • Application delivery path tested end-to-end
  • Runbooks for installed components
  • First-workload-onboarded evidence

Team shape: Full CompTech Lab pod (3–6 engineers depending on scope); customer platform and application team in joint working sessions.

04
Phase 04

Operate

4–8 weeks (overlapping with Deploy)

Stand up the day-2 operations practice that survives staff turnover.

Activities

  • SRE practice bring-up: SLOs, error budgets, alerting baselines
  • On-call structure, escalation paths, postmortem cadence
  • Incident response runbooks indexed by failure mode
  • Observability stack (metrics, logs, traces) wired through platform and applications
  • Cost and capacity baselines tied to FinOps reporting
  • Backup, DR, and restore drills

Deliverables

  • Operating model document with named responsibilities
  • Runbook library indexed by failure mode, verified against the live system
  • Observability dashboards tied to SLOs
  • Postmortem template and the first round of postmortems
  • DR drill evidence with documented RPO/RTO

Team shape: Operations lead from CompTech Lab + customer platform team operating as a single pod.

05
Phase 05

Hand over

2–4 weeks

Transfer ownership so the customer's team owns the platform with documentation deep enough to outlast staff turnover.

Activities

  • Architecture decision walkthrough (ADR-by-ADR)
  • Runbook walkthrough and joint failure-injection drills
  • Residual-risk register review
  • Documentation gap-fill pass
  • Handover sign-off and knowledge-transfer attestations

Deliverables

  • Documented residual-risk register accepted by the customer's audit function
  • Knowledge-transfer attestations from named customer engineers
  • Final handover document linking every artefact
  • 12-month outlook of recommended next investments
  • Optional: bridge managed-services scope for capability gaps

Team shape: Lead engineer + practice lead from CompTech Lab; customer platform team taking over operations.

Engagement contracting

How we contract and bill.

The five-phase methodology maps to a small set of contracting models. We do not run open-ended retainers; every engagement is bounded by either a scope or a clock.

Time-boxed engagement (default)

A fixed duration with defined scope and deliverables. Most platform, security, AI, and data engagements run on this model. Phase boundaries are checkpoints; scope changes are agreed in writing before they affect the budget.

Phase-by-phase

For larger or higher-risk programmes, we contract Phase 01 (Assess) separately so the case for the engagement is jointly built before the larger commitment. Common where the customer needs internal approval based on the Phase 01 output.

Bridge managed services

A time-boxed operations engagement during the period when the customer's team is building capability to take ownership. Always bounded by a calendar end-date or a capability-handover trigger. Not a permanent retainer.

Sub-contracting

We engage as a sub-contractor under partner master agreements (Red Hat consulting, Cisco SI engagements, customer-preferred SI primes) where that is the contractually simpler route for the customer.

Start an engagement

Have a programme that needs this discipline?

Send us a short note describing the problem. We’ll come back with a Phase 01 scope, a definition of done, and what we’d need from your team.

Contact us