Discover & Define - Design - Development - Deployment - UAT - Handover & Closeout
flowchart LR A[Discover <br>& Define] --> B[Design] B --> C[Development] B --> FD[Provisioning] C --> D[Solution <br> Deployment] FD -.-> D D --> E[UAT] E --> F[Handover & Closeout]
Note: The parallel tracks (Development + Foundational Deployment) apply to MVP and Production projects. PoV projects skip Foundational Deployment and generally proceed directly from Development to Closeout.
Hybrid Delivery Model: Structured Upfront, Agile Development and a Structured Release
This model maintains what we do very well, but adds important guardrails and quality controls upfront while clearly defining the requirements to close out the project, the two areas that have needed improvement in past work.
The delivery doctrine above will provide the team with a consistent awareness of what point they are at in a project, timelines and what’s required to move from stage to stage. This has a twofold impact: One, it empowers our engineers to take ownership. Two, it allows for quicker check-ins from the management team when determining the status of a project. When the requirements to exit a stage successfully are clear, communication becomes easier.
Progression between phases is controlled by stage gates — checkpoints where specified documents are reviewed and approved to continue moving forward.
| Phase | Preceded by Stage Gate |
|---|---|
| Discover & Define | Use Case Register |
| Discover & Define | Opportunity Assessment - Business Case |
| Development | Design Gate (SDD) |
| Deployment | Deployment Readiness Gate (Completed PAD) |
| Handover & Closeout | UAT Sign-Off Gate |
Project Types
Calab.ai deliver three types of projects currently:
- adjust to table with further details including description and sales constraints
- PoV — Short build in our environment (e.g. Urban Utilities ‘Site Asset Intelligence Report’, Tilt Renewables ‘Facthub’)
- Pilot — A build completed on a singular environment deployment at a client (e.g. ACU ‘AI Analyst’)
- Production Ready — A production-grade build in multiple environments at a client (e.g. AGL ‘CMPL Solution’)
The project type determines the weight of each stage. Not every activity in every stage is required for every project. Where applicable, each section below indicates what is required per project type.
Delivery Documents
Throughout delivery, three documents form the backbone of Calab.ai’s technical documentation:
| Document | Abbr. | Purpose | Authored During | Updated Throughout |
|---|---|---|---|---|
| Platform Architecture Document | PAD | Describes the foundational platform infrastructure, security, networking, integration patterns, and operational views. Acts as the parent architecture document for all SDDs that target the platform. | Design | Yes — updated when each SDD’s Architectural Impact Assessment is approved. |
| Solution Design Document | SDD | Captures the use-case-specific business process, technical solution design, requirements, test strategy, and architectural impact for a single use case built on the platform described in the PAD. | Design | Yes — updated iteratively as requirements are refined during Development. |
| Detailed Feature Specs | DFS | |||
| User Acceptance Testing Plan | UATP | An Excel workbook containing test scenarios, a test case tracker, and a defect/enhancement tracker for structured UAT execution. Written during UAT preparation and required to exit the UAT stage successfully. | UAT Preparation | Yes — updated during UAT execution with results and defects. |
| Project Plan | PP | |||
| Operational Handbook | OHD |
Naming Convention
Documents follow the convention: INITIATIVE CODE – USE CASE CODE – DOCUMENT TYPE
Examples:
ACU001 – GenAI Platform – PADACU001 – GenAI Triage – SDDAGL003 – CMPL – SDDACU001 – GenAI Triage – UATP
Project Roles
| Role | Description | Typical Holder |
|---|---|---|
| Client Sponsor | Business stakeholder who approves stage gate progression on the client side. | CEO / Managing Director |
| Delivery Lead | Owns the delivery timeline, stage gate progression, and client communication cadence. Accountable for project completion. | Head of Delivery / Lead Engineer |
| Solution Lead | Owns the technical design. Primary author of the PAD. Responsible for architecture decisions and design integrity. May also act as the platform engineer during deployment. | Principal Engineer Engineer / CTO |
| Engineering Team | Builds the solution over sprints. Primary author of the use case specific SDD. May also act as the platform engineer during deployment. | GenAI & Automation Engineers |
1. Discover & Define
Utilising the Microsoft proof of value stages of ‘Kick off – Identify – Explore – Prioritise – Define’, this stage is highly structured and builds an understanding of the client’s wider organisation before ‘coming down the funnel’ and deeply investigating specific use cases. Generally, this stage ends with an executive playback to display progress and outcomes.
There is another focus within this stage, and that’s IT. It is important at this initial stage of a project to understand the IT landscape, conduct gap analysis, build a relationship with the IT teams etc. which will inform the design decisions and the Deployment stage of the delivery. IT discovery sessions directly feed the early sections of the PAD (Business View, Platform Overview, Infrastructure View).
Outputs: Defined Use Case Brief, Executive Playback Deck (presentation), Draft PAD (sections 1–2 commenced from IT landscape discovery),
Sales-to-Delivery Handover
Before kick-off, the sales team hands over to delivery. The handover should include:
- Client context and relationship background (who’s who, communication preferences)
- Commercial scope (SOW, contracted deliverables, timeline, budget)
- Any promises or commitments made during the sales cycle
- Known risks, sensitivities, or political dynamics
- Access to any materials already shared by the client
- Note: Pop in pre kick off meeting for alignment
The Delivery Lead confirms handover completeness before scheduling the kick-off.
Discovery Activities
| ID | Activity | Time | Description | Attendees | Inputs |
|---|---|---|---|---|---|
| 0 | Kick-off – Alignment and project planning | 60 min | Meet and greet delivery team. Discuss future meetings to be booked and information to be collected. | Key Stakeholders involved for the duration of the project who can assist with organising meetings / information collection. | N/A |
| 1 | Define business objectives and scope | 60 min | Surface and define the business problems (e.g. operational inefficiencies, lack of automation, siloed systems). | Business Stakeholders that understand the existing business problem and pain points at a high level. | Business process diagrams or operating procedure documents. |
| 2 | IT landscape discovery (Cloud Architecture & DevOps) | 60 min | Understand current landscape of cloud infrastructure and DevOps practices to ensure designs consider existing capabilities. | IT Stakeholders that understand existing Azure Cloud Infrastructure, DevOps practices for application lifecycle and IaC management. | Azure Architecture and DevOps practices. |
| 3 | IT landscape discovery (Data & AI governance policies) | 60 min | Understand current landscape of cloud data and AI governance policies to ensure designs consider existing governance structures. | IT Stakeholders that understand existing IT security, data classification, and AI governance policies and procedures. | Cloud security, data classification and AI governance policies. |
| 4 | Use case discovery | 120 min | Breakdown the high-level scope / process down into individual opportunities that can be prioritised based on value and complexity. | Business Stakeholders that understand the existing business problem and pain points at a high level. | Business process diagrams or operating procedure documents. |
| 5 | Data & AI landscape gap analysis | 60 min | Assess readiness for deploying AI solutions on Azure based on capabilities relating to use case requirements. | IT Stakeholders that understand existing Azure Data, AI, and Analytics capabilities. | Data, AI, and Analytics Architectural Patterns and/or Policies. |
| 6 | Use case deep dives (shortlisting) | 30–60 min | Gather additional details for shortlisted use cases. Typically several sessions to collect appropriate detail. | Business SME Stakeholders that understand the details and work with the process regularly. | Use case process diagrams. |
| 7 | Use case activation | 60 min | Playback interim assessment on shortlisted use cases to confirm the priority use case for the PoV/MVP. | Business Sponsorship Stakeholders able to validate use case potential to generate value. | N/A |
| 8 | Use case deep dives (focus) | 30–60 min | Develop detailed concepts for the priority use case. Typically several sessions to collect appropriate detail. | Business SME Stakeholders that understand the details and work with the process regularly. | Use case process diagrams. |
| 9 | Executive playback | 60 min | Presentation to display progress, outcomes, and recommended use case(s) to proceed with. Closes out the discovery phase. | Key Stakeholders who have been involved for the duration of the project. | N/A |
2. Design
Define how the approved solution will be implemented. This is where the two core design documents — the PAD and SDD — are authored.
Owner: Solution Lead Input: Backlog of opportunities and business case for initial use case and platform deployment Structure: Inputs, Activites and Outputs, References (Guides/Templates)
Key Relationships Between PAD and SDD
The PAD and SDD are designed to work together:
- The PAD describes the platform — what infrastructure exists, how it’s secured, how systems integrate, and how it’s operated.
- The SDD describes a single use case — what business problem it solves, how the solution works, and what impact it has on the platform.
SDD Governance
The SDD is reviewed at two stage gates: initially at the Design Gate and finalised at the Deployment Readiness Gate.
During development, the engineering team refines the SDD iteratively as details will emerge from the build. Minor refinements are expected and do not require re-approval.
However, if a change materially shifts the solution design or what the solution interacts with (e.g. scope changes, new integration interfaces, revised technology choices, or changes to the architectural impact on the platform), the affected sections require a version increment and re-approval before development continues.
Activities
| Activity | Description | PoV | Pilot | Prod |
|---|---|---|---|---|
| Author the PAD | Document the platform architecture: infrastructure, security, networking, integration patterns, and operational views. For PoV projects built in Calab.ai’s own environment, a lightweight PAD covering the NeuralOps baseline is sufficient. For MVP/Production Ready, the PAD is authored collaboratively with the client’s IT team using findings from Stage 1 IT discovery sessions. | Default platform architecture | Standard | Full |
| Author the SDD | Document the use-case-specific business process, solution design, features, user stories, data architecture, component views, and architectural impact assessment. The SDD references the PAD for platform-level concerns and focuses on what is unique to this use case. | Lightweight | Standard | Full |
| Solution architecture review | Internal peer review of the PAD and SDD before presenting to the client. Ensures design quality and consistency with NeuralOps patterns. | Internal only | Internal + Client IT | Internal + Client IT + Architecture Board |
| Client design walkthrough | Walk the SME through the SDD to confirm the design meets business requirements | Optional | Required | Required |
| Client architecture walkthrough | Walk the client IT team through the PAD to confirm the design meets business requirements and aligns with their IT landscape. | Optional | Required | Required |
Outputs: Approved PAD and SDD
Note: PoV’s end at the completion of Development
3. Development
Build the approved solution over fortnightly sprints. For Pilot and Production Ready projects, two tracks run in parallel after the Design Gate: the engineering team begins building the solution internally against the NeuralOps platform baseline, while foundational infrastructure is provisioned in the client’s environment. Once the client environment is ready, the remaining development work is completed there.
Owner: Solution Lead (technical), Delivery Lead (cadence and client communication), GenAI Engineer (solution build)
Inputs: SDD, PAD, Project Plan (Comms Schedule), Build detailed requirements spec Use case video recordings throughout
Unit tests included
Sprint Cadence (Internal Meetings Only)
| Ceremony | Frequency | Duration | Attendees | Purpose |
|---|---|---|---|---|
| Sprint Planning | Start of each sprint (fortnightly) | 60 min | Engineering Team, Architect Representative, Squad Manager | Select backlog items for the sprint. Clarify requirements from SDD. |
| Daily Standup | Daily | 15 min | Engineering Team, Solution Lead | Surface blockers, align on priorities. Keep within the allocated time. |
| Sprint Retrospective | End of each sprint (fortnightly) | 30 min | Engineering Team, Solution Lead | What went well, what to improve, actions. |
Development Practices
- All work is tracked in GitHub Projects with a fortnightly sprint cadence, regardless of project type or deviation from typical work.
- User stories from the SDD form the sprint backlog.
- Evolving sections of the SDD (see SDD Governance above) are refined iteratively as the build progresses.
- All project-related communication should occur in the dedicated squad chat to maintain visibility across the team and minimise having to fill in individual members of the team.
Track 1: Solution Build (Internal)
The engineering team builds the solution in Calab.ai’s internal environment against the NeuralOps platform baseline. This allows development to begin immediately after the Design Gate without waiting for client infrastructure or access to be provisioned.
For PoV projects, the entire build occurs in Calab.ai’s environment. For MVP and Production Ready projects, development may begin internally and transition to the client environment once Track 2 is complete.
Track 2: Foundational Deployment (Client Infrastructure)
For MVP and Production Ready projects, foundational deployment runs in parallel with Track 1. The Delivery and Tech Leads coordinate with the client’s IT team to ensure this progresses alongside development.
Outputs: Working solution (iterative), Updated SDD (evolving sections refined during build), Updated PAD (if architectural impacts arise)
4. Solution Deployment
Solution deployment promotes the built solution into the target environment(s). For Pilot and Production Ready projects, this involves promoting through client environments.
Inputs: Foundational Deployment completed Owner: Solution Lead (technical), Delivery Lead (coordination and sign-off)
Activities
| Activity | Description | MVP | Prod |
|---|---|---|---|
| Environment promotion | Deploy the solution to the target environment(s) following the deployment approach documented in the SDD (§5.10). | DEV → client env | DEV → PPD → PRD |
| Configuration validation | Validate environment-specific configurations (connection strings, API endpoints, feature flags) are correct. | Standard | Full per environment |
| Smoke testing | Run automated or manual smoke tests to confirm the deployment is functional. | Automated where possible | Automated (Playwright or equivalent) |
| Rollback readiness | Confirm rollback strategy documented in SDD (§5.10) is executable. | Documented | Tested |
Outputs: Solution deployed to target environment(s), Deployment validated
5. UAT
Execute structured acceptance testing against the deployed solution using the UATP (User Acceptance Testing Plan) and obtain sign-off from the relevant client SME. The UATP is authored during UAT preparation and is required to exit this stage.
Owner: Delivery Lead (coordination), Client SME (execution and sign-off) Inputs: Solution development completed and migrated into client environment
Activities
| Activity | Description | MVP | Prod |
|---|---|---|---|
| UAT preparation | Author the UATP: define test scenarios, expected outcomes, and acceptance criteria based on the SDD (§5.9 Test Strategy). Walk the client SME through the test approach. | Documented UATP | Formal UATP with detailed acceptance criteria |
| UAT execution | Client SME executes test scenarios from the UATP against the deployed solution. Calab.ai engineering team is available to support and triage issues. Results are recorded in the UATP. | Client-led with support | Client-led with support |
| Defect triage | Issues identified during UAT are logged in the UATP defect tracker, triaged, and either resolved immediately or logged to the backlog with priority. | Fix and re-test | Fix, re-test, regression |
| UAT sign-off | Client SME confirms the solution meets acceptance criteria and is fit for purpose. The approved UATP is the exit document for this stage. | Written (email or Teams) | Formal sign-off (approved UATP) |
Outputs: Approved completed UATP (Test Cases), Client sign-off obtained
6. Handover & Closeout
Transition the solution to the client’s operational teams and formally close out the project.
Owner: Delivery Lead
Activities
| Activity | Description | Pilot | Prod |
|---|---|---|---|
| Knowledge transfer (UHD - Users) | Walk the client’s support team through the PAD and SDD — focusing on the Support View (PAD §9), Monitoring & Observability (PAD §9.4), and any operational procedures. | Sessions with support team | Sessions with support team |
| Documentation handover | Deliver final versions of the PAD, SDD, and UATP to the client. Ensure all sections are complete, all placeholders resolved, and version control is up to date. | PAD + SDD + UATP | PAD + SDD + UATP + any supplementary operational docs |
| Project closure meeting | Final meeting with the Client Sponsor to confirm all deliverables are complete, obtain formal closure, and discuss any future opportunities. | Formal meeting | Formal meeting with executive stakeholders |
| Internal retrospective | Internal Calab.ai retrospective on the engagement — what went well, what to improve, lessons learned. Feed insights back into the delivery methodology. | Standard | Standard |
Outputs: Final PAD, SDD, and UATP delivered, Client sign-off on project closure, Internal retrospective completed
Stage Gates Overview
Stage gates are the document-driven checkpoints between phases. Each gate requires the specified delivery document(s) — PAD, SDD, or UATP — to be reviewed and approved before progression. The approver varies by project type.
| Gate | Occurs After | Purpose | Document(s) Required | Approver |
|---|---|---|---|---|
| Design Gate | Design | Lock scope, architecture, cost, and timeline before development. | PAD (approved), SDD (approved) | Internal Leads + Client SME, Sponsor and IT (PAD) |
| Deployment Readiness Gate | Development | Confirm both tracks are complete: solution is built and client infrastructure is provisioned and validated. SDD evolving sections are finalised at this gate. | SDD (complete — all sections finalised), Infrastructure validation sign-off (from Track 2) | Internal (Solution Lead + Delivery Lead) |
| UAT Sign-Off Gate | UAT | Formal business acceptance that the solution meets requirements. | Approved UATP (test scenarios passed, defects resolved or accepted) | Client SME |