Showing Posts From

Ai advisory dependency

The Hidden Cost of AI Advisory: When Strategy Work Creates Dependency, Not Capability

The Hidden Cost of AI Advisory: When Strategy Work Creates Dependency, Not Capability

There are two fundamentally different things an AI advisory engagement can deliver. One leaves you with a document and a roadmap. The other leaves you with the capability to execute. Both look similar on a proposal. The difference only becomes visible at the end of the engagement — when you find out whether your team can run without the advisors in the room. Most clients don't ask which model they're buying until they're already in it. By then, the incentive structure of the engagement has been set, the dependency has been built, and reorienting toward capability transfer requires renegotiation that's awkward to initiate. This is not, for the most part, deliberate. It's the product of an economic model that is structurally oriented toward ongoing engagement rather than client independence. Understanding that structure is the first step to buying against it. The two models A capability-building engagement is designed to make itself unnecessary. The advisory team works alongside the client's team, explicitly transferring knowledge and judgment at each stage. The client's people understand what's being built and why. By the end of the engagement, they can maintain, extend, and adapt it without the advisor present. The measure of success is whether the client can operate independently. A dependency-creating engagement is designed around the advisor's continued presence. The advisory team does the work, produces deliverables, and runs the process. Client team members observe but don't deeply understand. At the end, the deliverables are handed over, but the knowledge that produced them stays with the advisory team. The client has a roadmap and a strategy document. The next step of execution requires bringing the advisors back in. Both are defensible business models. One serves the client's long-term interest. The other serves the firm's. The client's job is to identify which they're buying and decide whether it's what they want. Why dependency is the default Advisory firms are businesses. Their revenue comes from advisory engagements. Building client capability that makes future engagements unnecessary is economically irrational from the firm's perspective. This isn't cynicism — it's how markets work. A firm that builds client dependency retains revenue more predictably than one that builds client independence. The partners who sell engagements are measured on revenue. The incentive structure flows from there. The firms that build genuine client capability do so either because they're competing on reputation in a market where long-term client relationships matter more than repeat engagement revenue, or because their principals have personal commitments to a different model. These firms exist. They're a minority. The practical consequence for clients: assume the default is dependency and require explicit proof of the contrary. Don't assume that a firm that talks about knowledge transfer in its proposal actually delivers it — the language is easy to include and rarely audited. How to spot a dependency-creating engagement before you sign The warning signs appear in the proposal and in the discovery conversation, if you know what to look for. Staffing structure that concentrates expertise externally. If the senior AI practitioners are all on the advisory side and the client team is positioned as project management and coordination, the knowledge will stay with the advisors. In a capability-building engagement, the client team is working alongside practitioners, not managing them. Deliverables defined as documents rather than capabilities. A strategy document, a roadmap, an architecture design — these are outputs that the advisory team produces. A team that can evaluate AI use cases, a working deployment pipeline, a model monitoring process the client team operates — these are capabilities the client retains. If the SOW describes the first category and is silent on the second, that's what you're buying. No knowledge transfer milestones. Capability-building engagements have explicit milestones for what the client team can do at each stage of the engagement. If the project plan has delivery milestones but no client capability milestones, the knowledge transfer is aspirational rather than contractual. Vague handoff criteria. "We'll transition knowledge at the end of the engagement" without specifying what that means, who will assess it, and what criteria define successful handoff is a dependency structure dressed as capability transfer. The "we'll be available after the engagement" framing. This is the softest version of the dependency model — the engagement ends but ongoing support is positioned as the natural next step. For a capability-building engagement, ongoing support should be the exception for genuinely novel problems, not the expected path for running what was built. What to demand contractually Protecting against dependency requires it to be explicit in the contract, not assumed from the proposal language. Capability transfer milestones written into the SOW. At each project phase, specify what the client team can do independently: run the model evaluation process, deploy a model to the serving infrastructure, interpret monitoring outputs and make retraining decisions, conduct a data quality assessment for a new use case. These are testable. If the advisory team can't commit to them, they're not building capability. Shadowing requirements. Client team members should be doing work alongside advisory practitioners, not observing presentations of completed work. The difference between embedded working and presentation-based delivery is the difference between capability transfer and information transfer. Documentation standards written for internal operation. The documentation produced during the engagement should be sufficient for the client team to operate what was built after the engagement ends. "Sufficient" means tested — have someone on the client team who wasn't in the room use the documentation to execute a task. If they can't, the documentation isn't complete. Handoff assessment. A defined point — typically at engagement close — where the client team's independent capability is assessed against the milestones defined in the SOW. If the milestones aren't met, the engagement isn't complete. This changes the incentive structure. The key-person risk inside consulting engagements Advisory engagements have their own key-person risk, and it's more acute than clients typically recognize. The senior practitioner who ran the AI program at the client may have been that one person at the advisory firm who actually understood what they were building. When the engagement ends and that person moves to the next client, the institutional knowledge about the client's system moves with them. This is different from normal consulting key-person risk, because AI systems require operational understanding to run correctly. If something breaks in the monitoring pipeline six months after the engagement ends and the person who built it is no longer available, you're rebuilding from documentation — or calling the advisory firm back in. The mitigation is the same as for the dependency issue generally: the client team needs to genuinely understand the system, not just manage it. That requires them to have been involved in building it, not just receiving it. What good looks like at the end A capability-building engagement ends with the client team demonstrating specific capabilities, not receiving a final report. The lead data scientist on the client side can explain why specific model choices were made and what the tradeoffs were. The ML engineer can run the retraining pipeline independently. The product owner can read the monitoring dashboards and knows what threshold triggers a review. The program lead can run a data quality assessment for a new use case without advisory support. These are concrete things. They can be tested before the engagement closes. They require the advisory team to have spent the engagement building them, not producing deliverables about them. If you're evaluating an AI advisory engagement, ask the firm to describe specifically what your team will be able to do at the end that it can't do now — and ask them to put it in the contract. The answer to that question tells you more about the engagement model than any amount of proposal language about partnership, knowledge transfer, and client-centricity.

Read full article