*Empower your internal project teams to build culturally aligned tech-adoption strategies that protects your ROI – without risking consulting dependency or AI-slop.*

Between Consulting and AI: What Tech Adoption Actually Needs

There's a pattern every CIO recognizes. A major tech rollout goes live on time, on budget, and technically clean — and six months later, half the organization is quietly working around it on spreadsheets. The system isn't broken. People just don't trust what changing means for them.

That's the part of enterprise software adoption that gets dismissed as soft. It's also where most of the value of your investment is won or lost. When you implement an ERP, a CRM, or an AI tool, you aren't just installing code. You're reshaping workflows, decision rights, daily routines — and, more than any of that, professional identities. That kind of change is deeply emotional for an organization, even if no one says so out loud.

Right now, most CIOs are also under more pressure than ever to deliver this kind of change faster, with less budget, and with visible business impact. The pipeline keeps growing while in-house change and communications capacity hasn't kept up. Faced with that gap, organizations tend to end up at one of two doors.

Two doors

The first is the traditional consulting route. There's a lot to respect about it: deep methodology, experienced practitioners, mature delivery models. But you've probably noticed the pattern. The strategy lives in a deck that arrives a week before go-live. The smartest people on your team have spent six months in workshops. And once the consultants leave, your organization is no better equipped to handle the next rollout than it was before this one. A client of ours described that experience recently as feeling like "a hostile takeover" — not because the consultants were bad, but because the model isn't designed to leave capability behind.

The second door is doing it yourself with AI. Faster, cheaper, more flexible — in theory. And for a lot of the repetitive content work that change communications involves, it genuinely is. The harder question is what happens when you ask AI to do the strategic work: shape the narrative, sequence the stakeholder journey, calibrate a message for the specific culture and history of your company. AI will give you something that looks polished. But if you've never run an AI launch or S/4HANA program before, how do you tell whether the output is genuinely good or just confident-sounding? You don't have the framework to assess what's missing — and your employees will sense that the strategy doesn't quite fit them long before they can articulate why.

Both paths tend to converge on the same outcome: a technically clean rollout that quietly underperforms because the people inside it never bought in.

A better question

The interesting question, then, isn't "consulting or AI?" It's where in the process each one actually helps.

Most of the work of landing a major tech change is, honestly, logistics. Coordinating stakeholders. Drafting templates. Tracking who's said what to whom. Maintaining a cascading toolkit for local teams. None of this requires senior judgment, and the cost and time savings from automating it are real.

But every program also has moments where judgment is everything. Diagnosing why a country head has gone quiet. Reframing a message for a workforce that's already been through three reorganizations. Knowing when to slow down rather than accelerate communications. These are the moments where expensive failures happen, and where experienced humans add value that no LLM can replicate today.

If you separate those two layers cleanly — software for the machine room, judgment for the pivot points — something useful happens. You stop paying consultants to do work software can do faster. You stop letting AI handle decisions it can't actually make. And almost as a side effect, your own project team gets stronger at this, because they're doing the strategic thinking themselves, supported rather than replaced.

What this looks like in practice

At COSYN, we've built that principle into a product we call the Change Playbook. The point isn't the tool – it's the model – so I'll keep this short.

The Change Playbook walks a project team through the end-to-end journey of landing a tech change – strategy, planning, asset creation, cascading to local communicators, and measurement — and applies the same question at every step: what can software do well, and where do you genuinely need a human in the room? Strategy intake happens through a guided structure with well-timed workshops to discuss reputational tensions, risks and opportuntities. Asset creation leans on AI where AI is good enough, and on human craft where it isn't. Local communicators get their tasks delivered straight into their calendars — because, as every experienced program leader knows, for a country head running a plant in Brazil, your global SAP rollout is priority twenty. If it isn't dead simple to act on, it doesn't happen.

And adoption signals are tracked before go-live, not after. Waiting until launch to find out whether a program is landing means you've already lost the chance to correct course.

The strategic point

None of this is about replacing your people, and none of it is about replacing experienced advisors. It's about being honest about where each kind of work sits.

Every major tech program is also a quiet decision about whether you're building internal change capability or renting it. Most organizations have rented it for too long – partly because it was the only option. That isn't true anymore. The technology on your roadmap will keep changing. The need for someone in your organization who knows how to land it won't.

This post accompanies the latest episode of A Change in Conversation, where Arne Kötting and his co-founder Matthijs Voordenberg walk through how the Change Playbook works in practice.