How We Run Enterprise Software Delivery at SPARK

Most transformation programmes treat software delivery as a translation problem. The business articulates a requirement; a project manager writes it into a specification; a development team builds it; someone tests it; it gets deployed. The assumption embedded in this model is that good requirements, faithfully executed, produce good outcomes. This assumption is almost always wrong.

Requirements are never complete. Specifications never fully capture intent. The gap between what the business imagined and what the engineering team built is not a failure of communication — it is an inherent property of complex system development. The question is not how to eliminate the gap, but how to design a delivery model that surfaces it early, resolves it continuously, and prevents it from compounding into a costly late-stage rework.

The SPARK delivery model was built to answer that question. It defines how the Solutions team and the Development team collaborate across the full delivery lifecycle — from functional design through to production deployment and security assurance — with explicit handoffs, shared tooling, and governance gates at every stage.

The Core Principle: Two Teams, One Pipeline

The model separates delivery responsibility into two distinct functions with complementary expertise. The Solutions team owns the upstream: functional design, business process mapping, solution architecture, and UX prototype. The Development team owns the downstream: engineering implementation, version control, CI/CD pipeline, and security assurance. Neither team operates independently — the pipeline between them is the product.

This separation is deliberate. Conflating solution design and engineering execution — which is what happens when a single team tries to do both — creates a hidden cost: the people who understand the business problem are different from the people who can build the solution, and forcing both responsibilities onto the same individuals means one always suffers. The Solutions team is recruited for domain knowledge, process thinking, and stakeholder management. The Development team is recruited for engineering rigour, system design, and technical depth. The pipeline is what makes them effective together.

The Eight-Stage Sequence

Stage one is the functional deep dive. The Solutions team immerses in the specific vertical — a business domain, a user group, an operational workflow — using Lucidchart for functional design diagrams and JIRA Confluence as the artefact repository. The output is not a requirements document. It is a shared understanding of the problem: the current state process, the decision points, the friction, and the opportunity. Everything downstream is built on this foundation.

Stage two is solution design. The Solutions team translates the problem understanding into a designed solution: business solution architecture and technical architecture documented in Lucidchart, and a UX/UI prototype in Figma. The prototype is critical — it is the first concrete artefact that stakeholders can react to and that developers can build toward. Getting stakeholder feedback at prototype stage, rather than at development stage, is where the model recovers the most cost.

Stage three is the handoff. The Solutions team transfers the solution design to the Development team via the JIRA Scrum board. This is not a document drop — it is a structured knowledge transfer that includes architecture walkthroughs, prototype walkthroughs, and joint backlog refinement. The development sprint structure is established at this stage: sprint scope, acceptance criteria, and the definition of done for each deliverable.

Stage four is development. Developers build during sprints using VS Code and Cursor as the primary IDEs, with AI code assistance from Claude Code Enterprise and ChatGPT Codex Enterprise, and GitHub Copilot for inline suggestions. The choice to standardise on enterprise-licensed AI assistance rather than personal accounts is a governance decision: it keeps code and context within the organisational boundary, with the same security and data classification controls that apply to other enterprise systems.

Stage five is the ongoing solutions-developer sync. Rather than a single handoff, the Solutions team maintains active engagement through the development sprints — clarifying requirements, reviewing sprint outputs against the intended design, and adjusting the backlog when implementation reveals assumptions that need revisiting. This continuous sync is what prevents the prototype from diverging from the built product.

Stage six is security and compliance. Before any code reaches the integration branch, developers practice pair programming on security-sensitive features, push individual feature branches to GitHub, and submit pull requests for peer code review. No code merges to main without review. This gate exists not just to catch bugs but to maintain the shared codebase quality standard — which matters more as the team scales.

Stage seven is the CI/CD pipeline. GitHub Actions automates the build, test, and deployment pipeline. Unit testing, integration testing, and SAST (static application security testing) are all executed before any deployment proceeds. The pipeline is the enforcement mechanism: it is impossible to deploy code that has not passed the configured checks. This removes the human discipline problem from security assurance — the gate is structural, not procedural.

Stage eight is deployment and pen testing. CICD deploys to the UAT environment. After manual validation in UAT, deployment to PROD proceeds via the Azure Portal or AWS Portal depending on the hosting environment. A penetration test is conducted after UAT and before the PROD release for any solution handling sensitive data or external-facing functionality. Pen testing at this stage — after UAT, before PROD — is the right sequencing: the solution is stable enough to test meaningfully, and findings can still be remediated before live exposure.

The Architecture That Holds It Together

The toolchain is not accidental — it is an architecture. At the top sits the Solutions layer: Lucidchart for architecture documentation, and Figma and Canva for design and prototyping. Below it, the AI code assistance layer (Claude Code Enterprise and ChatGPT Codex Enterprise) connects directly to the development workflow rather than operating as a separate tool that developers context-switch into.

GitHub Enterprise is the integration point for the entire development layer — code editing, version control, and build and testing all connect through GitHub. JIRA Enterprise is the project management integration point — task assignments, bug reports, sprint planning, and issue updates all flow through JIRA, which means the Solutions team and the Development team share a single view of delivery status rather than maintaining parallel tracking systems.

The integration layer — CI/CD pipelines, code sync, pull requests, issue updates — is what makes the individual tools coherent. A code commit in VS Code triggers a GitHub Action, which runs the test suite, updates the JIRA issue status, and notifies the relevant sprint stakeholders. Nothing in this flow requires manual status updates. The system reports its own state.

Why the Handoff Is the Product

The most important design decision in this model is treating the handoff between Solutions and Development as a first-class concern rather than an administrative step. In most delivery models, the handoff is where value leaks: the solutions architect who understood the business problem moves on, and the developers who received a specification build exactly what was written rather than what was intended.

The structured handoff in the SPARK model — with architecture walkthroughs, prototype walkthroughs, and shared JIRA backlogs — is designed to transfer understanding, not just documentation. The Solutions team does not hand over a document and disappear. They remain active through the development sprints, which means that when an implementation decision reveals a design assumption that needs revisiting, the person who made the assumption is still available to revise it.

This has a compounding effect on quality. The early sprints surface assumptions that the prototype did not fully resolve. The corrections made in those sprints inform the design of subsequent features. The team gets better at anticipating the implementation implications of design decisions because the feedback loop between design and implementation is fast and direct. By the third or fourth programme cycle, the Solutions team is producing designs that require significantly less rework during development — not because they are smarter, but because they have heard the implementation feedback enough times to internalise it.

The Governance Dividend

The model is also a governance model. The CICD pipeline enforces the testing standard. The code review gate enforces the quality standard. The pen test enforces the security standard. Each of these could be run as a procedural control — a checklist that teams are supposed to follow. Checklists degrade under pressure. Structural gates do not.

For a programme portfolio running 75+ initiatives across six workstreams, the structural governance is what makes it possible to maintain quality without proportional management overhead. The governance is embedded in the delivery pipeline rather than administered on top of it. The result — zero at-risk or delayed deliverables across the portfolio — is not an accident of talent or effort. It is a function of a delivery model designed to catch problems early, resolve them fast, and prevent them from becoming programme-level issues.

The model is not fixed. It has evolved as the team and the portfolio have grown, and it will continue to evolve. But the core architecture — two complementary teams, a structured handoff, AI-assisted development, automated quality gates, and security assurance before production — reflects what enterprise software delivery actually requires at scale. Not process for process's sake, but structure that enables speed.