Delivery model
A project is confirmed only when its outcomes, scope boundaries, success criteria and responsibilities are written down and agreed. Everything else is a conversation that will be re-litigated later.
Scoping process
Five stages, each with a named owner and a defined output that feeds the next.
| Stage | Owner (RACI) | Activities | Output |
|---|---|---|---|
| 1. Needs assessment | Sales (R), PM (A), Technical lead (C) | Structured questionnaire covering business context, current environment, application components, delivery pain points, compliance needs and target outcomes. Reviewed for completeness by the technical lead. | Completed needs assessment |
| 2. Discovery workshop | PM (R), Technical lead (A) | Current-state architecture, workload inventory, DevOps maturity across source control, IaC, CI/CD, observability and security; constraints; prioritised objectives. | Findings, prioritised objectives, constraints |
| 3. Project charter | PM (R), Sponsor (A) | Executive summary, SMART objectives, business case, in and out of scope, success criteria, KPIs, deliverables, budget, milestones, stakeholders, assumptions, risks. | Approved charter |
| 4. Statement of work | Sales (R), PM (A), Technical lead (C) | Target architecture, expected AWS cost, phased plan with effort, deliverables, milestones, out-of-scope list, responsibilities, acceptance criteria, change control, commercial terms. | Signed SOW — the scope baseline |
| 5. Kick-off | PM (R), Technical lead (C), Client (I) | Confirms scope, deliverables, milestones, RACI, communication plan and reporting cadence. | Kick-off record and summary |
Scoping criteria
A project is confirmed only when every item below is defined and agreed.
Business objectives
Business drivers and SMART goals, with the success criteria and KPIs that show they were met.
Current state
Existing environment, application components, hosting, data and limitations, documented from assessment and discovery.
Target state
Target AWS architecture, diagrammed, with expected AWS cost estimated per service.
In-scope work
Selected phases and tasks from the standard plan, each with an effort estimate in days.
Out of scope
An explicit list. An empty out-of-scope section is a scope dispute waiting to happen.
Deliverables
Tangible, verifiable outputs with acceptance criteria.
Milestones
Dates and the decision or artefact each milestone produces.
Responsibilities
RACI across Qbits and the customer for every scoping and delivery activity.
Assumptions and constraints
Access, availability of customer staff, existing tooling, procurement lead times, regulatory constraints.
Acceptance criteria
How the customer will determine that a deliverable is complete.
Change control
The procedure that applies after signature.
Standard technical plan
Work is selected from a nine-phase menu, each phase with a defined set of tasks and an effort estimate. Not every engagement needs every phase; the menu makes the selection explicit and the estimate comparable.
| Phase | Content |
|---|---|
| 1. Planning and preparation | Requirements confirmation, access, tooling, project setup |
| 2. AWS account setup | Organisation, accounts, identity, guardrails |
| 3. Network fabric and baseline IaC | VPC, subnets, routing, baseline Terraform |
| 4. Migration execution | Workload migration, data transfer, cutover |
| 5. DevOps practices and system design | Pipelines, IaC modules, environment topology |
| 6. Security and observability | Controls, detection, monitoring, dashboards |
| 7. Testing | Functional, load, resilience, security |
| 8. Knowledge transfer and handover | Documentation, training, game day |
| 9. Project closure | Acceptance, review, retrospective, closure report |
Project management
A dedicated project manager is assigned to every engagement. The PM owns:
- The plan, the critical path and the risk register.
- Status reporting and the communication plan.
- Change control and the change register.
- Stakeholder management and escalation.
- Acceptance and closure.
Roles
| Role | Responsibility |
|---|---|
| Project sponsor (customer) | Owns the outcome; removes organisational blockers; approves scope and budget changes |
| Project manager | Plan, risk, change, communication, reporting |
| Technical lead | Architecture decisions, technical quality, delivery risk |
| Delivery engineers | Implementation against the standards |
| Security lead | Security review, control design, incident readiness |
| Customer technical owner | Access, environment knowledge, acceptance |
| Change manager | Change register, CAB coordination |
Reporting cadence
| Report | Frequency | Content |
|---|---|---|
| Stand-up | Daily or weekly | Progress, blockers, next steps |
| Status report | Weekly | RAG status, milestones, risks, decisions needed |
| Steering update | Monthly | Outcome progress, budget, escalations |
| Milestone review | Per milestone | Deliverables, acceptance, KPI movement |
| Closure report | End | Outcome against objectives, lessons, handover state |
RACI
Every activity has exactly one accountable owner. A RACI with several A's is not a RACI; it is a disagreement that has not been resolved.
| Activity | Qbits PM | Qbits Tech Lead | Customer Sponsor | Customer Tech |
|---|---|---|---|---|
| Scope definition | A | C | A | C |
| Architecture | C | A | I | C |
| Environment access | R | C | A | R |
| Implementation | R | A | I | C |
| Security review | C | R | I | A |
| Acceptance | R | C | A | R |
| Change approval | R | C | A | C |