Skip to main content

How we work

Qbits delivers DevOps transformation as a structured engagement, not a tooling project. Work moves through five phases — initiation, discovery, analysis, recommendation and delivery — with a defined gate between each. Every phase produces artefacts the customer keeps.

The model exists for a practical reason: most DevOps initiatives fail on organisational readiness rather than technology. Establishing stakeholder alignment and organisational context before recommending tooling is what makes the technical work stick.

The five phases​

  1. Initiation — align on the problem Stakeholders agree on goals, scope, timelines and success measures. We gather background on the organisation, technical estate and pain points, and request existing documentation for review.

  2. Discovery — understand how work actually happens Cross-functional workshops and structured interviews establish current workflows, team structures, collaboration models and the bottlenecks that block adoption.

  3. Analysis — measure the gap We assess maturity across culture, process and technology, compare current practice against the target capability set, and risk-assess the transformation itself.

  4. Recommendation — agree the change A prioritised roadmap with owners, sequencing, KPIs and a change-management plan covering Legal, Finance, HR and Sales as well as engineering.

  5. Delivery — implement, verify, hand over Implementation against the standards in this library, verified with evidence, followed by formal handover, training and a review.

Phase detail and deliverables​

PhaseKey activitiesArtefacts you receive
InitiationKick-off; background gathering; document request and reviewKick-off pack and minutes, background brief, document review summary, agreed success measures
DiscoveryWorkshops; stakeholder interviews; current-state mappingWorkshop plan and report, interview guide and summary, stakeholder map
AnalysisMaturity assessment; gap analysis; risk assessmentMaturity scorecard, gap assessment and summary, risk register, risk management report
RecommendationRoadmap; organisational change plan; KPI framework; executive sponsorshipChange recommendations, sponsorship plan, communication plan, KPI tracking baseline, pilot plan
DeliveryBuild to standard; pilot; rollout; handoverArchitecture and pipeline documentation, runbooks, readiness checklists, handover pack, completion report

Gates​

Each phase closes with a gate. A gate is not a sign-off ritual — it is the point where a phase's evidence is checked against the next phase's assumptions. If the evidence is missing, the next phase does not start.

Gate 1 — Scope
Goals, scope and success measures are agreed and written down. Access and stakeholders are confirmed.
Gate 2 — Understanding
Current state is documented with evidence from the people who do the work, not only from management.
Gate 3 — Baseline
Maturity scores and gaps are agreed with the customer. The baseline is what improvement will later be measured against.
Gate 4 — Commitment
Roadmap, owners, budget and executive sponsorship are in place before implementation begins.
Gate 5 — Acceptance
Delivery is validated against the readiness checklist, documented, and accepted by the customer.

Delivery cadence​

Delivery runs in short increments with explicit checkpoints rather than a single end-of-project review.

  • Weekly — delivery stand-up, risk and blocker review, pipeline and environment status.
  • Per increment — demo against acceptance criteria, retrospective, backlog re-prioritisation.
  • Per milestone — customer satisfaction checkpoint, KPI review against the baseline.
  • Per change to scope — change request through the change manager and, where material, the Change Advisory Board.
  • At handover — readiness review, runbook walkthrough, game day, formal acceptance.

What "done" means​

A phase is done when the artefact exists, the customer has seen it, and the next phase can proceed without rework. For delivery specifically, "done" means:

  1. The workload is deployed through an automated pipeline — no console changes in production.
  2. Infrastructure and policy are in version control and reproducible.
  3. Monitoring, alarms and dashboards are live and tied to agreed workload health KPIs.
  4. Runbooks exist for routine operations and known failure modes, and have been exercised.
  5. Backups are configured, and a restore has been tested against the agreed RTO/RPO.
  6. Documentation and training have been handed over and accepted.