The honest gap between AI hype and field reality, and how to structure delivery so the team's new speed isn't wasted waiting on the customer.

On AI-accelerated implementations, the bottleneck moves from the team to the customer. This article explains where AI speeds up Adobe Commerce delivery and where it can't, then offers two methodologies for clearing customer dependencies so the team's new speed translates into a faster project.

The gap between expectation and delivery

The promise of AI in project delivery is everywhere right now, and expectations have climbed fast. The reality on the ground is more complicated. AI changes what a small team can produce. Code generation, test creation, documentation drafts, requirements synthesis all move at speeds that didn't exist three years ago. But the team's pace isn't the project's pace.

Take an Adobe Commerce implementation as the running example, though the pattern holds across most enterprise delivery work. By now there's a well-worn observation that AI speeds up coding without speeding up delivery, because the bottleneck just moves somewhere else. Most of that conversation points inward, to code review, testing, integration, and deployment, the internal stages that now have to absorb far more output. That's real. But on an implementation project, the more punishing bottleneck sits somewhere the internal-process conversation rarely looks: outside the delivery team entirely.

Customer SMEs have day jobs. Decisions wait for people who aren't in the room. User acceptance testing happens at the speed of business users who can only spare a few hours a week. The team gets faster. The customer doesn't. On any implementation, the real pace is set by the slowest contributor at any given moment. Before AI, that was often the team itself, so making the team faster made the project faster. With AI in the workflow, the team is rarely the bottleneck anymore. The slowest contributor is now almost always someone outside it.

This is the problem worth solving, and it's solvable. What follows is where AI genuinely moves the needle, where it doesn't, and how to structure delivery so the team's acceleration translates into a faster project instead of a team that spends most of its time waiting.

Where AI moves the needle, and where it doesn't

AI accelerates work bounded by individual or team productivity. A developer writing integration code. A QA engineer building a regression suite. A business systems analyst synthesizing workshop notes into structured user stories. An architect drafting solution options. These compress dramatically when AI is used well.

AI does not accelerate work bounded by other people's availability or authority. User acceptance testing happens at the speed of the business users who execute it. Architecture and integration decisions happen at the speed of the customer's IT leadership who must sign off. Change management happens at the speed of trust-building with end users. None of this compresses because the team has better tools.

The internal bottlenecks, review and verification capacity, can at least be addressed with more automation and better process. The customer-side bottlenecks can't. You cannot automate a client's decision authority or buy back a stakeholder's calendar. That is what makes them the harder constraint, and the one worth designing around first. AI instruments the work. It does not deliver the project. The honest measure of acceleration is end-to-end, kickoff to go-live, and most of the friction in that measure sits outside the team.

The first move: Align with the customer before the work starts

The most effective response to the customer-side bottleneck happens before the first sprint, not during it. If an AI-enabled approach lets the team move faster, the value the customer is paying for only materializes if the customer can keep pace on the parts that are theirs: decisions, reviews, sign-offs, and access. This is not a demand to place on a client. It is something to explain, because it genuinely serves their interest.

The conversation worth having early is a plain one. An AI-enabled delivery approach changes what the project needs from the customer. The team will produce faster, which means decisions and approvals that once sat comfortably in a slower cadence now fall on the critical path. To realize the speed they are paying for, the customer benefits from naming primary and backup SMEs at the outset, agreeing on who holds decision authority, and committing to turnaround expectations on reviews. Framed this way, it is not the delivery team managing the client. It is both sides setting the engagement up so the customer actually receives the outcome the approach promises.

This alignment matters for a second reason: it gives whoever runs the project the standing to act. A PM cannot approach a customer mid-project to request a backup SME or faster decisions without an established mandate. That authority has to be set at the outset, at the leadership-to-customer level, as part of how the engagement is framed. When the rationale is shared and the authority is in place, the in-flight discipline that follows becomes a natural part of the working relationship rather than an imposition.

The in-flight discipline: Work ahead of the team

Even with strong early alignment, no customer keeps perfect pace. The in-flight discipline that handles the rest is straightforward to describe, even though the proof of how much it recovers will come from running it.

If the team is faster but the customer isn't, the project blocks wherever the team's pace runs into a customer response it has to wait for. Story reviews pile up. Architecture and integration approvals stall. UAT participants aren't available when the team reaches them. The faster the team moves, the harder it hits these walls, because AI has widened the gap between how fast the team produces and how fast the customer can respond.

The customer can't fully close that gap, even with the best intentions. Their availability is still shaped by their day jobs and their own priorities. The remaining gap is closed on the delivery side, by getting ahead of it.

So the core practice is this: the PM works one to two sprints ahead of the team, clearing every customer dependency before the team arrives at the work that needs it. Look ahead, identify each customer touchpoint required for upcoming sprints, and initiate those requests now, not when the team needs them. On a Commerce build, that means the integration approval requested two sprints ago has come back, the payment or ERP sandbox access requested early is available, and the business users who validate storefront and checkout flows are already booked for UAT. This is where the authority established at the start does its work: the PM has the standing to make these requests because the engagement was framed to expect them.

None of this requires reinventing how teams work, and that's deliberate. The temptation in a moment of new technology is to design an elaborate new process around it, but the more reliable move is to keep the framework teams already know and adapt the one practice the new conditions make essential. Good project managers have always worked ahead. AI didn't create the need to work ahead of the customer. It removed the slack that used to hide the cost of not doing it. When the team produced at a human pace, occasional customer delays were absorbed into the natural rhythm of the work. When the team produces at an AI-accelerated pace, those same delays become the dominant cost, because the team is now fast enough to spend most of its time waiting. Working ahead is what should convert the team's speed into project speed instead of idle capacity.

Two methodologies for working ahead

Both methodologies organize the same practice, the PM working ahead of the team. They differ only in where that dependency work lives. Pick the one that fits your team's context, or adapt a third from them.

What both methodologies share

Beyond working ahead, both methodologies rest on three practices.

• Deliberate AI usage across every role. Developers pair with AI for code generation and review. QA generates test cases and regression suites. The BSA synthesizes workshop transcripts and drafts requirements. The technical architect produces solution options and technical documentation. The PM drafts project artifacts and status reports. AI handles production work, humans handle judgment work. Humans stay editor-in-chief on every output.

• Light tracking through two custom Jira fields. AI hours and Human hours on every ticket. Enough data to see patterns, not so much that logging discipline collapses by Sprint 4. Make logging part of the Definition of Done. Tickets that close without time fields filled signal that the discipline is optional, so don't allow it.

• One retrospective question every sprint. Where did AI help most, where did it help least, and what prompts or approaches worked well? Qualitative answers accumulate in a running log that, by go-live, explains the patterns the numbers only describe.

Methodology 1: Two parallel sprint tracks

Two tracks run within each sprint.

The PM Track clears customer dependencies for upcoming work. PM, BSA, and technical architect log dependency-clearing tickets here, with the same AI hours and Human hours fields as execution work. AI prepares materials for customer review where applicable.

The Execution Track is the team's build, test, and delivery work on dependencies the PM track has already cleared.

Both tracks share sprint ceremonies. Tickets are tagged to identify which track they belong to, and filtering separates the views when needed.

In practice, a Sprint 4 backlog might hold twelve execution tickets and six PM-track tickets. During standup, the PM would report progress on an integration approval for Sprint 5 work alongside developers reporting on Sprint 4 builds. Sprint review shows both tracks. Leadership sees dependency-clearing as committed, visible work, and the customer sees what the team is doing to stay unblocked.

• What it gives you: explicit accountability for dependency clearing as sprint commitments, AI usage data on PM activities and not just execution, and full visibility for customer and leadership.

• What you pay for it: sprint capacity conflicts when execution work feels urgent and PM-track work gets deprioritized, higher coordination overhead than single-track, a heavier reliance on PM discipline to keep both tracks aligned, and the risk that if PM-track work slips, future sprints block.

This methodology fits teams with strong PMs, clear track ownership, and leadership that wants visibility into dependency work.

Methodology 2: Single-track agile with dependency work outside the sprint

Standard agile sprints, standard ceremonies, and a sprint backlog that holds only execution work.

PM dependency clearing happens as normal project management activity outside the sprint. PM, BSA, and technical architect handle customer touchpoints, approvals, scheduling, and decisions as part of their normal responsibilities, tracked in whatever tools the PM already uses, or in a separate Jira epic if visibility matters.

In practice, a Sprint 4 backlog might hold twelve execution tickets and no PM tickets. Standup covers execution work. The PM reports dependency status separately in weekly updates. Sprint review focuses on execution outcomes, and when a customer approval finally arrives, it's a project update rather than a sprint event.

• What it gives you: the standard agile structure the team already understands, no sprint capacity conflicts, lower coordination overhead, and a clean separation between sprint commitments and PM activity.

• What you pay for it: less visibility into PM dependency work, full reliance on PM discipline outside sprint accountability, AI usage on PM activities that may go untracked, and a team that may not see how much work the PM is doing to keep them unblocked.

This methodology fits teams with strong PM habits, leadership that doesn't need granular visibility into dependency clearing, and a preference for simpler structure.

Choosing between them

Both methodologies organize the same practice: the PM works ahead so customer dependencies are cleared before the team needs them. They differ only in whether that work lives inside the sprint as tracked tickets or outside it as standard project management.

The right choice depends on the PM's working style, the team's familiarity with agile structures, the complexity of the customer side (how many SMEs, how many decision points, how much governance overhead), and how much explicit visibility leadership and the customer expect.

A team with a senior PM, complex customer governance, and leadership demanding granular reporting will lean toward two-track. A team with a streamlined customer, strong PM habits, and a preference for minimal overhead will lean toward single-track. A team with neither constraint may design a third approach that fits its context better. These two are starting points, not prescriptions.

What stays true regardless of methodology

Some practices hold no matter which structure you choose.

• Trust nothing blindly. Every AI output is a draft. Code suggestions need review, generated test cases need validation, and synthesized requirements need confirmation against the source. The team's job is editorial.

• Customer SME commitment starts at alignment and holds through execution. The early conversation sets the expectation; the project still has to honor it in practice. Keep primary and backup SMEs named, keep decision authority clear, and treat a slipped commitment as a signal to revisit the alignment, not as a surprise. The standing to do this comes from the framing set at the start.

• Keep change management as its own workstream. AI generates training materials and communication drafts well. It does not build user trust, manage resistance, or replace facilitated training. If no one is named as change management owner before kickoff, it doesn't happen, and a technically successful implementation can still fail at go-live if users don't adopt it.

Why this matters now

The AI era is changing what's possible inside the team faster than most delivery processes are evolving to handle it. Continuing to run projects exactly as before, and hoping AI helps somewhere, leaves most of AI's value on the table. The process has to evolve to capture what the tools can give.

Most AI advice for project delivery assumes the constraint is somewhere inside the delivery org, whether that's coding, review, or verification. In implementation work, the real constraint sits at the boundary between the team and everything outside it: customers, third parties, governance bodies, end users. That boundary is best addressed in two places at once: at the start, by aligning with the customer on what the AI-enabled approach needs from them and why it serves their outcome, and in flight, by working ahead so the team's capacity is never wasted waiting. AI gives the team capacity it didn't have before. Good project discipline directs that capacity at the right things and protects it from being wasted on work that has to wait for the customer anyway. Neither AI nor discipline alone is sufficient.

The takeaway is less about which structure wins and more about the shift in mindset: stop treating project execution as fixed, and start treating it as a variable that AI is forcing every delivery team to reconsider. AI instruments the work. Discipline delivers the project. The friction inside the team can be removed. The friction outside the team cannot. The discipline is in managing both.

Actionable takeaways

• The bottleneck has moved. With AI in the workflow, the delivery team is rarely the slowest contributor. On an implementation, the constraint is usually at the customer boundary: decisions, approvals, SME availability, and UAT.

• Address the boundary in two places. Align with the customer before kickoff on what an AI-enabled approach needs from them and why it serves their outcome, then work ahead during delivery to clear what alignment alone can't.

• Secure authority early. Establish at the leadership-to-customer level that the PM can request backup SMEs and timely decisions. Without that mandate set at the outset, working ahead stalls.

• Keep the framework, adapt one practice. Don't reinvent agile. Keep standard sprints and ceremonies, and make working ahead of the customer the deliberate addition.

• Use AI across every role, with humans as editor-in-chief. Developers, QA, BSA, TA, and PM all use AI for production work; people own the judgment and review.

• Track lightly. Two Jira fields, AI hours and Human hours, plus one retrospective question per sprint, give enough signal to optimize without logging fatigue.

• Pick the structure that fits your team. Two-track gives visibility and accountability at the cost of coordination overhead; single-track is simpler but makes dependency work less visible. Choose deliberately.