Software EngineeringAI-Native SDLC Transformation
SDLC AI Maturity Audit
A two-week audit of your engineering team's development lifecycle, scored phase by phase across planning, development, testing, deployment and monitoring, with a DORA baseline (DORA stands for Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore — four metrics that measure how fast and reliably a team ships software), a prioritised tooling recommendation, and a 90-day AI adoption roadmap.
SDLC AI Maturity Audit
$15K–$28K
- Duration: 2 weeks
- Tier: Diagnose
- Format: Fixed scope
You leave withPhase-by-phase SDLC audit, tooling recommendation, adoption roadmap and DORA baseline
Book a Free SessionSound familiar?
We bought Copilot licences six months ago. Some engineers use it, most do not, and I cannot tell you if it is moving the needle. We have three AI tools in the stack and nobody was properly trained on any of them. My CTO is asking for DORA metrics and I am pulling numbers from three different tools that do not agree with each other. I know we are behind. I just do not know where to start.
What you leave with
SDLC maturity scorecard
Format: PDF and Word
How we know it’s acceptableEach phase scored against the rubric; every score supported by a finding from interviews or data; no unsubstantiated ratings.
DORA baseline
Format: Spreadsheet
How we know it’s acceptableEach metric from actual data or clearly flagged as estimated, with the estimation basis stated.
Tooling recommendation
Format: Structured document
How we know it’s acceptableEach recommendation mapped to a specific gap, with effort and impact rating; no tool recommended without a stated rationale.
90-day adoption roadmap
Format: Document
How we know it’s acceptableEach step sequenced by SDLC phase, with owner type and effort estimate; confirmed by the client at the readout.
Executive summary
Format: One page
How we know it’s acceptableReadable by a non-technical executive; approved by the buyer before final delivery.
Readout session
Format: Live call, recorded
How we know it’s acceptableAttended by the engineering lead and the decision-maker.
How it runs
2 weeks
Week 1, days 1–2
Kick-off and data gathering
Review the existing tooling inventory, pull or proxy deployment logs, and run structured interviews with two to three engineering leads across SDLC phases.
OutA confirmed scope document listing the phases, teams, and tools in scope.
Week 1, days 3–5
Phase scoring and DORA baseline
Score each SDLC phase against the maturity rubric; calculate DORA metrics from available data or establish proxy measures with the basis clearly noted; collect supporting evidence from interviews.
OutScored phase matrix and DORA numbers with source notes.
Week 2, days 1–3
Tooling analysis and roadmap drafting
Map current tools to identified gaps; prioritise recommendations by impact and effort; sequence the 90-day adoption roadmap.
OutDraft tooling recommendation and roadmap for client review.
Week 2, days 4–5
Final report, executive summary, and readout
Write and format the full findings report and one-page executive summary; run the readout session.
OutFinal report, executive summary, and recorded readout call.
Is this right for you?
This is for you if
- Buyerthe person responsible for engineering velocity and development quality. Usually a VP of Engineering, a CTO, or a Head of Platform who feels the gap between how their team builds software today and what an AI-supported development process should look like.
- Also has to say yesthe engineering lead or principal engineer who knows the actual tooling and day-to-day workflows in detail, and who will be responsible for acting on the roadmap after the readout. At larger organisations, a Head of Developer Experience or a DevOps lead may also need to be involved before a decision is made.
This is the wrong answer if
- The team has fewer than eight engineers. The audit is built around multi-phase handoffs and workflow patterns. A very small team does not have enough process structure to audit meaningfully. Start with a Possibilities Session instead.
- The client wants implementation, not assessment. If they already know which tools to adopt and how, a build sprint is the right move. The Audit tells you what to prioritise; it does not do the prioritised work.
- There is no existing CI/CD practice or version control. DORA metrics require deployment history to measure. Without a baseline, there is nothing to audit or improve against.
- They want a vendor shortlist or procurement support. Tooling recommendations are part of the Audit; negotiating licences or running an RFP is not.
- The goal is to assess individual engineer productivity. This audit looks at workflows and tooling at the team level. It does not evaluate individuals.
What’s included, and what isn’t
In scope
- assessment of all SDLC phases for one engineering organisation
- DORA baseline using existing tooling data or reasonable proxy measures
- tooling recommendation for all phases assessed
- 90-day adoption roadmap
- executive summary and readout session
Out of scope
- implementing any tooling recommendations (that is a build engagement)
- training engineers on specific tools (the Cohort AI-Native Engineering Programme or the Claude Code Rollout Programme)
- procuring or licensing tools on the client's behalf
- assessing non-engineering teams or business workflows
- producing a vendor market comparison or RFP
- security or compliance review of the tools assessed
- any ongoing monitoring after the readout
Before we start
Before day one
- Access to deployment metrics, or a named engineer who can pull them before day three.
- A list of current tools in use across the SDLC, including any AI tools.
- Availability of two to three engineering leads for structured interviews in week one, no more than two hours each.
- A named point of contact who can chase access and answer questions within the same working day.
- A decision-maker available at the start of the engagement to confirm scope and at the readout session.
What we’ll need from your team
- An engineering lead or principal engineer: three to four hours in week one for structured interviews and follow-up questions.
- A DevOps or platform engineer: two to three hours to provide access to deployment metrics and pipeline configuration.
- A decision-maker: one hour at the start of the engagement to confirm scope, available within 24 hours for scope questions, and at the readout session.
Pricing
What we need to give you a quote
- Number of engineers and teams in scope.
- Current tech stack and deployment toolchain.
- Whether deployment metrics are tracked and in which tool.
- What AI tools are currently in use, if any, and for which SDLC phases.
- What has prompted this: a deadline, a board question, a competitive pressure, or a specific pain point.
- Whether there is a phase they already know is the biggest problem.
After we hand over
Who owns it after we leave
The client's engineering lead or VP of Engineering owns the adoption roadmap and tracks progress against it. Monitoring DORA metrics at 30, 60, and 90 days requires someone with continued access to deployment data. Agree who that person is at kick-off, not at the readout.
What we measure
- DORA baseline at audit close
- Percentage of roadmap items completed at 90 days
- A 90-day DORA re-check if the client agrees to share results
What comes next
- The Claude Code Rollout Programmeif the roadmap identifies AI coding tools as the highest-impact change. The Claude Code Rollout Programme executes the rollout the Audit specifies.
- The Cohort AI-Native Engineering Programmeif the gap is individual engineer capability rather than process and tooling.
- A build sprintif the Audit surfaces a specific workflow, integration, or tool setup that needs building before adoption can happen.
Questions buyers ask us
Using tools and getting value from them are different things. The audit tells you which tools are actually changing how your team works, which SDLC phases are still completely unassisted, and what the gap between current and AI-native looks like. If you are already optimised, the audit confirms it and gives you a baseline to report on.
The team's time commitment is capped at structured interviews with two to three engineering leads in week one, no more than two hours each, plus access to deployment data. We fit around the normal sprint. The audit does not slow delivery down.
Internal assessments tend to score familiar tools charitably and miss phases where no one is looking. The value of an external audit is the benchmark and the outside view. If you have done it internally, we can start from your output and go further.
DORA metrics were designed for exactly this situation. A low DORA baseline is not a problem; it is the starting point. The audit establishes where you are, not where you should be. The roadmap shows how to get there.
The roadmap is sequenced by impact and effort, not locked to a fixed calendar. The first steps are chosen because they are achievable within a normal sprint cycle regardless of shifting priorities. The Audit does not ask you to freeze the quarter.