How to talk about SDLC automation without a made-up ROI

Every automation pitch eventually offers a return. Some of those numbers are modeled from the buyer's own baseline. Many are borrowed from a slide the buyer did not generate. S·CORP will not hand you a return we did not measure in your pipeline. What we will do is say which clocks are worth timing, who has to agree the baseline is real, and how an automated path should behave once you have one.

Software delivery automation is not a bot that writes code. It is the removal of private rituals between a decision and production: environment setup, review, test evidence, change approval, release, and the record that lets someone explain the release later. AI can sit inside that path. It does not replace the path.

Count the path you have, not the path you wish you had

Before anyone proposes a tool, write the path a normal change takes today. Not the happy path in the engineering handbook. The path a team actually uses when the change is ordinary, and the path they use when they are afraid. Those are often different, and the second one is where time and risk hide.

Pick units a sponsor can audit. Lead time from "ready to build" to "running in production." The number of handoffs that require a person to retype information that already exists in a system. The share of changes that leave a ticket, a commit, and a deploy record tied together. The number of environment defects found after a deploy that were really "the environment was not the one we tested." You do not need an industry study to know whether your own team can answer those questions. If they cannot, that is the first finding.

Agree the baseline in writing with the people who do the work. A baseline taken from a steering-committee estimate will be argued later, and the argument will be used to dismiss the automation. A baseline taken from a month of ordinary changes, with the team in the room, is harder to wave away.

Automate the evidence, not just the step

A pipeline that is faster and silent is not an improvement in a regulated business. Banking, insurance, and any firm that answers to customers about uptime needs the release to be explainable. The automation should attach the evidence to the change: what tests ran, what was skipped and why, who approved, which artifact was deployed, and how to roll back. If the evidence lives in a chat log, it does not exist for the person who has to answer next quarter.

ISO 27001 shows up here as change management and operations security, not as a logo. The control is "we can show what changed." PCI DSS shows up if the system is in the cardholder-data environment: separation of duties and a record of the change are not optional flavor. An agent that opens a pull request can be useful. An agent that approves its own path to production is a missing control.

AI inside the pipeline has a narrow, honest job. It can draft a test, summarize a diff for a reviewer, or point at a log line that matches a known failure. It should not be the approver. The reviewer remains accountable, which means the review surface has to show the diff and the evidence, not a paragraph that says the diff was fine.

Where the return actually comes from

The return, when it is real, comes from a shorter and more predictable path, fewer repeated setup failures, and less time spent reconstructing what happened. It is specific to the baseline you wrote down. A team that already deploys small changes with evidence will see a different result from a team whose release is a weekend ceremony. Anyone who quotes you a single percentage for both teams is not talking about your SDLC.

Model the return in the unit the finance partner already trusts. Hours returned to engineering. Lead time. Failed deployments that no longer need a bridge call. The effort of an environment that can be rebuilt instead of nursed. Put the assumptions next to the model, including the assumption you are least sure about. If the model only works when nothing goes wrong, it is not a model.

Do not bury adoption. An automated path that half the teams quietly bypass is not the path. The bypass is the path. Measure the share of changes that actually go through the automated route. If that share is low, the work is product work on the path, not a campaign telling people to comply.

What to refuse in the business case

Refuse a case that depends on headcount you have not agreed to remove. Automation that frees time does not automatically reduce a team. Sometimes the point is to spend the same people on work that was not getting done: security fixes, test depth, customer-facing defects. Say which one it is.

Refuse a case that treats the model as the asset and the pipeline as a detail. The asset is a delivery system a new team can join without a private orientation. Refuse a case with no rollback and no owner for the pipeline itself. The pipeline is production. It needs an owner, a change process, and a way to tell that it is lying.

NIST's AI Risk Management Framework still applies when the "AI" is a helper inside the toolchain. Govern the use, map where generated code or generated tests can land, measure whether reviewers catch defects the helper introduced, and manage the vendor who hosts the helper. The same data rules apply: source code, customer data in fixtures, and secrets do not belong in a vendor trace you have not read.

A practical sequence

Start with one team and one class of change. Instrument the baseline for a short, agreed window. Automate the step that most often forces a person to retype or to wait: usually environment creation, test evidence, or the link between ticket and deploy. Put a person on the approval. Review the first set of changes with the team that owns the operation, not with a slide. Then decide whether the path is fit to extend.

That sequence will not fit on a single return-on-investment tile, and it should not. The tile can come after the baseline is real. If a vendor or a partner cannot work in that order, they are selling the number, not the path.