AI Boardroom Discussions · August 17, 2026

The SDLC hasn't changed — we've just gotten faster at the part that matters least

Waterfall, Agile, or AI-accelerated: 70% of project success is decided in the front end, 20% after go-live, and only 10% in the build — the part that still gets nearly all the attention.

The 30-second version

Upfront requirements gathering

Talking point

The requirements phase is now arguably longer than the build it precedes. That inversion is new; the consequence of skipping it is not.

Content angle

“Your build got 20x faster. Your requirements didn't.” Show the phase weighting and let the imbalance make the argument.

Question to ask in the room

How much of your last AI project's rework traced back to a requirement nobody wrote down?

Lens: Field note on delivery and AI executive readiness. The 70/10/20 weighting reflects where outcomes are consistently decided across engagements, not time spent. It is orientation for executive conversations, not a benchmark study.

Front-End · 70%

Where the project is won or lost — before anyone touches a build. AI acceleration has not moved a single item on this list.

Upfront requirements gathering

Done right, once — instead of discovered in production.

Talking point

The requirements phase is now arguably longer than the build it precedes. That inversion is new; the consequence of skipping it is not.

Content angle

“Your build got 20x faster. Your requirements didn't.” Show the phase weighting and let the imbalance make the argument.

Question to ask

How much of your last AI project's rework traced back to a requirement nobody wrote down?

Executive sponsorship — a seat, not a signature

C-suite engagement, and increasingly boardroom visibility, before the first requirement is written.

Talking point

One thing hasn't gotten easier just because build got faster: you still need real sponsorship to make the front end stick. A name on a charter is not sponsorship.

Content angle

“The one input AI can't compress.” Position sponsorship as the scarce resource in AI delivery.

Question to ask

Who at the executive table would personally lose something if this project quietly stalled?

Reasonable timelines and clear accountability

Set before pressure sets them for you; assigned before day one, not after the first miss.

Talking point

AI-compressed builds create the illusion that the whole project compressed. Timelines get set to the demo, then accountability gets assigned to whoever is standing closest when it slips.

Content angle

“Demo speed is not delivery speed.” Contrast the pilot timeline with the adoption timeline.

Question to ask

Was your timeline derived from the work, or from the date someone already promised?

Real stakeholder time

Invested by the people who will actually use it.

Talking point

Stakeholder time is the cost line that never appears in the business case and always appears in the post-mortem.

Content angle

“The unbudgeted line item.” Make stakeholder hours an explicit ask in the charter.

Question to ask

How many hours of your actual end users' time is budgeted into this project?

Build · 10%

The part everyone still watches — the status meetings, the headcount, the budget scrutiny.

From one-third of the project to one-twentieth

That's how much the build timeline has compressed.

Talking point

Build has gone from roughly a third of the effort to something closer to a twentieth — and it still absorbs nearly all the executive attention and anxiety.

Content angle

“We optimized the 10%.” One chart: the phase that shrank versus the phase that decides.

Question to ask

In your last steering committee, how much of the agenda was build status versus adoption readiness?

Post-Build · 20%

Where the deal actually gets closed. Go-live isn't the finish line.

QA and testing as a gate, not a checkbox

Talking point

Faster builds produce more code to validate, not less. Compressing QA to protect a go-live date moves the defect, it doesn't remove it.

Content angle

“Speed moves defects downstream.” Where AI-accelerated delivery quietly relocates risk.

Question to ask

Who has authority to hold a go-live date on quality grounds?

“Done” does not equal “adopted”

The lesson every Agile team relearns, project after project.

Talking point

Someone must own adoption, not just deployment. Front-end plus post-build now carry nine-tenths of the outcome.

Content angle

“Deployed is not adopted.” Tie AI ROI claims to usage evidence rather than release notes.

Question to ask

Ninety days after go-live, what number tells you this was worth doing?

Bottom line

Front-end plus post-build now carry 90% of the outcome

  1. Reweight your governance: if build is 10% of the outcome, it shouldn't be 80% of the steering agenda.
  2. Name an accountable executive sponsor before requirements, not after the first miss.
  3. Budget end-user hours explicitly — stakeholder time is the most common unfunded dependency.
  4. Treat QA as a gate with authority to hold a date, and assign someone to own adoption past go-live.

Where a reasonable executive would push back

Keep reading

Next briefs

Get the briefs in your inbox

AI in the News, Legal Signal, Security & Compliance, and ROI briefs — written for executives in regulated industries. No spam, unsubscribe anytime.