What to Expect From Your Implementation Partner in the Age of AI

In my last edition, I argued that most AI initiatives don’t fail because of the technology — they fail because the foundation underneath it wasn’t ready. But there is a question that lives just beneath that one, and it is the one I hear most often from CFOs once the strategy conversation is over: once you know what you need to build, how do you know who can actually build it with you?

That question matters more now than it did two or three years ago, because the answer has changed. The implementation model that most partners are still selling was not designed for where we are today. Understanding why, as well as what a better model looks like, is what determines whether a transformation delivers or stalls.

How the Old Model Worked

The traditional implementation partner was built on a sequence of labor. This step happens, then this step, and the whole timeline is arranged around keeping the partner’s available resources utilized. That sequencing is rarely aligned with how the customer needs to work and instead is aligned with how the partner needs to staff.

Offshore capacity was what kept that model affordable. It could work, but it carried real friction — communication gaps, time zone constraints, limits on when meaningful work could actually happen. Underneath it all was a linear, serial timeline that moved at the pace of available people. When something slipped, the answer was more people. That assumption is what AI is now dismantling.

What Good Looks Like Now

In my experience, discovery is where the difference becomes most visible, and it is a useful place to start because it sets the foundation for everything that follows. Traditionally, discovery meant a consultant coming in and asking how you would like something to work, which, frankly, is not always the right question. Those sessions produced notes that went back to the partner’s team, who would eventually return with what they heard.

In a genuinely AI-native process, those sessions are recorded across every functional area, and the output becomes the starting point for initial configuration directly. Instead of a document, discovery becomes a foundation — one that can be matched immediately against Oracle’s best practices and one that surfaces early what day two looks like for that organization, which is where change management actually has to begin.

The same logic carries through the rest of the implementation. Data conversion, historically one of the longest poles in the tent, is almost perfectly suited to AI because at its core it is a mapping issue. Development work compounds on itself when prior engagements are treated as a library rather than a sunk cost. But the two places where I see the sharpest difference between a partner who has rebuilt their methodology and one who has rebranded it are testing and governance — and both deserve more than the passing mention they usually get.

Where Testing Actually Changes

Testing is where implementation timelines historically go to die. It sits at the end of the plan, which means it absorbs every delay that came before it, and it is staffed largely by your people — the ones who still have day jobs. When a go-live slips, testing is almost always where that slip becomes visible.

The traditional version of it is mostly manual labor. Someone writes test scripts by hand from a requirements document, business users execute them one at a time, and results are tracked in spreadsheets that are stale by the afternoon. Defects get logged, routed, retested, and the cycle repeats. Very little of that work requires judgment. It requires patience, availability, and time — three things your team does not have much of.

In an AI-native process, the scripts are generated from the requirements captured in discovery and the system as it is actually configured, which means they trace back to the same foundation everything else was built on. Regression testing stops being an event and becomes something that runs continuously, so a change made in week twenty gets validated in week twenty rather than surfacing in a test cycle three months later. When something fails, it comes back with a first pass at the likely cause and what similar failures looked like on prior projects, so your team spends its time deciding rather than diagnosing.

What that changes for you is the shape of the burden, not the ownership of it. Your business users still own user acceptance. No AI is going to tell you whether a process matches the way your business actually needs to run, and it should not try. But your people arrive at UAT testing a system that has already been exercised, instead of discovering basic breakage for the first time in a room with a projector and a deadline behind them.

The part most partners leave out is what you keep. Those test assets should not be a project artifact that dies at go-live. Oracle ships updates quarterly, and every one of those quarters raises the same question: what did this break? A living regression suite that your team owns — one that doubles as the training material you needed to build anyway — is the difference between a quarterly update being a two-week fire drill and a routine event. Ask a prospective partner what happens to their test scripts after go-live. The answer tells you whether they were building an asset for you or a deliverable for themselves.

Governance Stops Being a Reporting Exercise

Governance is where the old model hides most of its weight, and it is the piece that tends to get the least scrutiny, because it reads as overhead rather than delivery.
Look closely at a traditional program and you will find an enormous amount of effort spent assembling state — status reports, risk and issue logs, dashboards, change control forms, steering committee decks. When we took our own methodology apart, what we found was that the majority of project management time went into collecting and formatting that information rather than acting on it. That is a reporting function, and a substantial line item, being carried on the books as governance.

There is also a timing problem, and it gets worse as delivery gets faster. A weekly status report describes a project as it was several days ago. At a traditional pace, that lag is tolerable. When AI compresses the work, a governance cadence built around weekly manual assembly cannot keep up, and you end up steering with a picture of a project that has already moved on.

AI-native governance addresses both. Status assembles itself from the actual work — configuration, conversion runs, development activity, test results — rather than being narrated by someone a few days after the fact. Risk and issue logs stay current instead of being reconstructed the night before a steering meeting. Change requests arrive with a drafted impact analysis on scope, timeline, and cost, so the conversation starts with an assessment instead of waiting on one. And underneath all of it, the engagement is continuously matched against the patterns of previous projects — where implementations like yours have historically gotten into trouble, and what the early indicators were. That is what turns governance from a record of what already happened into a warning about what is coming.

What does not change is who decides. Escalation judgment, tradeoff calls, whether to accept a scope change and what you are willing to pay for it — those stay human, and they should. What changes is that project managers stop being status collectors and become exception handlers, which is what you were paying for in the first place.
For a CFO, that is the practical value: the number you are looking at on Thursday is true on Thursday.

Before You Sign

While guiding the teams I work with at Argano, I’ve also found that the pace of that progress depends as much on the client as on the partner. Compression numbers vary significantly by phase, and the more important variable is how much your organization can actually absorb. The people on your project still have day jobs. If the transformation matters enough to prioritize, staff for it as its own dedicated effort — that is when real acceleration becomes possible.

The best thing you can do before signing a contract is have a potential partner walk you through their methodology in detail. What you are listening for is whether AI is genuinely load-bearing in that process or whether it has been layered on top of something that would function without it.

I also suggest asking how well-versed they are in the native AI and agentic capabilities being built into Oracle or whichever platform you are running, and how they plan to keep you current as those capabilities continue to ship. Then ask how they will map that native functionality against the actual gaps in your process — because that translation is where most partners fall short.

Two questions are worth asking specifically, because they are hard to answer with a slide. Ask how test scripts get created, how often they run, and who owns them after go-live. And ask to see what their governance reporting actually looks like — whether it is a dashboard someone populates on Thursday nights, or an output of the work itself.

The contract will tell you as much as the methodology will. Pure time and materials is one way to structure an engagement, but the more revealing question is whether the partner is willing to commit to an outcome for a price, essentially putting skin in the game alongside you. We are not fully there as an industry, but the speed AI makes possible is what puts that conversation on the table at all. A partner who will not entertain it is telling you something about where they actually stand.

The Most Important Question

After everything else — the methodology review, the platform questions, the contract conversation — there is one direct question that cuts through all of it.
Ask them what breaks if you remove AI from their delivery process.

If the answer is nothing, what you are looking at is a familiar model with a new label. The sequencing is the same, the labor assumptions are the same, and the risk profile is the same. AI was sprinkled on top, not built in.

When the methodology collapses without it, that is because AI is doing real work at every stage — accelerating discovery, driving configuration, compressing testing, monitoring delivery. 
 

Connect with an Argano Expert! 

Need specialized insights for your business challenges? Facing complex business technology questions? Don't navigate alone. Connect with an Argano subject matter expert who will personally respond within 24 hours.