**Strategic Delivery Frameworks — aligning collaborative models and AI-native workflows to your goals.** The technology decisions get the attention; the engagement model determines whether the technology gets delivered. This page describes how we structure partnerships — from staff augmentation through managed services to AI-native delivery — and the principles that make each tier work.
How a delivery partnership is structured determines almost everything that happens within it: who owns the backlog, who bears the risk if outcomes slip, how value is measured, who escalates when something goes wrong, what the path looks like when the engagement matures. In our experience across hundreds of engagements, the single biggest predictor of success is not the technology stack, the team size, or the budget — it is the clarity of accountability. Who owns what. Who bears what risk. How value is measured.
This page describes our framework not as a sales pitch for a particular model, but as a diagnostic. By the end, you should have a shared language for where you are today and where you want to go.
Every engagement has a Responsibility–Risk pair. Responsibility is what each party does — sourcing, governing, delivering, accepting. Risk is who bears the cost when something goes wrong — missed deadlines, scope creep, quality issues, retention, ramp-down. The cleanest engagements have these mapped explicitly: client owns A, partner owns B, the boundary between them is sharp and rehearsed. The most painful engagements have ambiguity at the boundary — both parties assumed the other was handling something, and the gap surfaces during a real problem.
The principle parallels Deming's articulation of clear ownership in quality management — a system without clear accountability cannot be improved because no one owns improvement.
The framework has three tiers, each appropriate for different organisational situations. Staffing & Resource Augmentation — engineers embedded in your team under your governance — fits when you have strong internal delivery leadership, defined backlogs, and need to scale capacity without permanent headcount. Managed Capacity — a governed delivery unit with a Service Delivery Lead, accountable for KPIs tied to outcomes — fits when you want delivery accountability without surrendering architectural ownership. Managed Services — end-to-end solution ownership with partner-driven governance — fits when you have a defined outcome and want a partner accountable for it. Picking the right tier requires honest assessment of where you are; over-buying complicates engagements unnecessarily, under-buying leaves accountability gaps.
The tiering parallels the SAFe Configurations — not because the framework's specifics apply, but because the idea of selecting the right operating model for the organisation's actual situation is foundational to delivery success.
Most mature engagements move along a trajectory: Staffing → Managed Capacity → Managed Services. The trajectory exists not because we want clients to spend more, but because trust is built over engagements. A client sees how we deliver, how we govern, how our people perform under pressure — and that observed track record is what justifies handing over more accountability. The arrow is not a sales tactic; it is a description of how trust between organisations gets built. Engagements that try to start at Managed Services without the relationship history typically struggle, because both parties are still learning each other when they should be operating.
Charles Handy — The Empty Raincoat and the broader literature on outsourcing maturity models — articulating how partnership trust progresses through demonstrated outcomes, not through commercial commitment.
In Staffing tier, the natural KPI is hours — engineers placed, hours billed. This is the right metric for that tier because Ascendion's accountability is the placement, not the outcome. In Managed Capacity and above, hours become misleading: the question that matters is "are deliverables landing on time, are outcomes hitting the targets we jointly defined, is the transition to steady state seamless?" Aligning KPIs to outcomes — even where the contract is on T&M — changes how the team operates, because it pulls focus toward the things clients actually want, not the things engineering hours measure.
The contracting vehicles trace to Performance-Based Contracting (Outcomes-Based Contracting) — a procurement discipline that aligns commercial incentive with delivery results rather than effort.
AAVA is our AI-native delivery model — a multi-agent framework that augments human engineers across the lifecycle. Discovery agents extract requirements from existing artefacts; design agents generate architectural options; coding agents produce implementations under human review; testing agents generate and execute test suites; documentation agents keep specs current. The discipline that makes this productive rather than chaotic is the human accountability — agents accelerate the work; humans approve the outputs, hold the architectural judgment, and own the integration. Done well, AAVA compresses cycle times by 2–4x without reducing quality. Done poorly — agents generating volumes of work without human review — it produces fast unreviewable output.
The pattern parallels the broader literature on AI-augmented software engineering — productive use depends on integrating agents into existing engineering workflows rather than treating them as autonomous replacements.
The most commonly botched part of any engagement is the transition out — when the project moves to operational steady state and the client team takes over. Sloppy transitions leave the client team without the knowledge they need; over-engineered transitions stretch the engagement uselessly while the team is already on next things. The discipline is operationalising the transition: knowledge transfer plans documented before delivery completes, runbooks written and exercised, on-call rotations dual-staffed with handover, retrospectives including the receiving team. Clients consistently tell us the transition was painful with prior vendors — and our investment in making it not painful is part of the difference.
The discipline is articulated in ITIL Service Transition — the canonical reference for moving services from project delivery to operational steady state, with the disciplines (transition planning, knowledge management, change management) that make it survivable.
The diagram below shows the three-tier engagement framework with the maturity arrow, the four engagement vehicles (Time & Materials, Fixed Price, Milestones-based, Outcomes-based) appropriate to each tier, and the AAVA AI-native delivery model that augments engineering across all tiers.
A client whose internal delivery leadership is strong but is short on capacity buys a Managed Services engagement. The partner takes ownership of decisions the client wanted to retain; the engagement struggles because the model doesn't match the actual need.
Match the tier to the actual need, not to perceived sophistication. Strong internal leadership + capacity gap = Staffing or Managed Capacity. Weak internal leadership + clear outcome target = Managed Services. The honest assessment matters more than the impressive label.
A client with no delivery leadership buys staffing. Engineers arrive without governance; outcomes drift; the engagement consumes effort without producing value, and the client's frustration grows.
Recognise that staffing requires internal delivery leadership to translate engineers into outcomes. Without that leadership, Managed Capacity or Managed Services is the appropriate model — accept the cost in exchange for outcome accountability.
The engagement is on T&M, the partner reports hours billed weekly, both parties feel productive. Six months in, the client realises they have a lot of effort consumed and unclear outcomes. The KPI structure rewarded effort, so effort is what arrived.
Even on T&M, the KPIs measure outcomes. Deliverables landing on time, quality bars met, milestones reached. Hours are tracked; outcomes are evaluated. The conversation in steering committees is about the latter, not the former.
AI agents produce code, tests, and documentation faster than humans can review thoroughly. Reviews become rubber stamps; quality issues sneak through; the volume of work obscures the issues until production reveals them.
Human review gates appropriate to risk. The acceleration target is meaningful work shipped, not raw artefacts produced. AAVA's value comes from compressing cycle time on well-understood work, not from bypassing engineering judgment on novel work.
The engagement ends; documentation is hastily written; the receiving team gets a knowledge-transfer session and a wiki link. The first incident reveals what wasn't transferred; the receiving team escalates back to the partner repeatedly; the engagement informally extends because the formal end didn't actually end it.
Transition planned from kickoff, exercised before formal completion, validated by the receiving team operating autonomously. The engagement closes when transition is verified, not when the original scope is delivered.
Both parties have agreed who owns what and who bears risk for what; the boundary is sharp; ambiguity is recognised as a problem to fix before kickoff, not a detail to handle later.
Honest assessment of internal leadership, backlog clarity, and risk appetite drives the choice; over-buying is recognised as expensive theatre, under-buying is recognised as accountability gap.
The vehicle reinforces the engagement's intent rather than obscuring it; T&M for discovery and evolving scope, Fixed Price for stable scope, Milestones for checkpointed delivery, Outcomes for mature partnerships.
Even on hourly contracts, the steering conversation is about deliverables landing, quality met, transition viable; hours are tracked, outcomes are evaluated.
Single accountable point on the partner side; owns governance, KPI tracking, and proactive escalation; the client always has someone to ask.
The team that arrives at month one is the team that arrives at month twelve, evolved with the stack; engineer growth is part of the engagement's value, not a hiring concern absorbed silently.
AI agents accelerate; humans review and judge; the engineering quality bar is held by humans, with AAVA compressing the work needed to meet it rather than bypassing the standard.
Documentation, runbooks, and operational know-how are deliverables; the receiving team is involved in later phases; transition success criteria are documented and verified.
When something goes wrong, the path is rehearsed; both parties know who calls whom; the response is calibrated, not chaotic.
The trajectory from current tier to the next is named, with the conditions (trust, demonstrated outcomes, evolved scope) that would justify progression; the partnership is going somewhere, not parked.