Done for You vs. Done with You Consulting: Which Model Fits Your Business?

Seventy percent of digital transformations fail to meet their objectives.⁽¹⁾ That number hasn’t budged despite every new wave of tools and frameworks. Only 28% of AI use cases in Infrastructure and Operations fully succeed and meet ROI expectations.⁽⁴⁾ The tools aren’t usually the problem. The delivery model and the pace usually are.

When senior IT leaders evaluate a consulting engagement, questions tend to focus on scope, timeline, and cost. The question that gets less attention: who owns the outcome after the consultants leave? Done-for-you (DFY) and done-with-you (DWY) consulting answer that very differently. Getting it wrong doesn’t just hurt the project. It shapes what your organization can do on its own for years afterward.

What Does a Done-for-You Consulting Engagement Actually Deliver?

Done-for-you consulting hands full execution to an outside team. The client defines the goal; the partner owns the work. This model suits organizations with critical capability gaps, tight deadlines, or teams already stretched thin. But speed and expertise come at a real cost: large IT projects run an average of 45% over budget and deliver 56% less value than predicted.⁽²⁾

In a DFY engagement, the consulting firm supplies the architects, engineers, and project managers. Your team stays in the loop, but day-to-day execution sits with the vendor. That separation is the whole point. When a critical system needs to go live in 90 days and your engineers are committed elsewhere, you need results, not a capability-building exercise.

Here’s the speed dynamic that matters: DFY moves fast at the start, then can become slow and expensive later. When the engagement ends, institutional knowledge leaves with the consultants. Three months later your team is calling the vendor back for changes that should be routine. That’s the knowledge dependency trap. You’ve bought a solution, but not necessarily the ability to own it long-term, if knowledge transfer wasn’t built in from day one.

That doesn’t make DFY the wrong choice. It makes it a choice with specific trade-offs. Reviewing the differences between staff augmentation vs. consulting is a useful starting point, because the question of who carries institutional knowledge shows up in both conversations.

When DFY Works Well

DFY tends to succeed in three situations: scope is well-defined and unlikely to shift; the technology is specialized enough that building internal expertise isn’t realistic near-term; and the primary constraint is time rather than long-term self-sufficiency. Infrastructure migrations, compliance-driven implementations, and one-time platform integrations often fit this profile. What they share: they’re not ongoing capabilities your team will need to evolve and troubleshoot independently for years. If that’s what you’re actually building, DFY alone is probably the wrong model.

What Is Done-with-You Consulting and Why Is It Growing?

Done-with-you consulting is a co-delivery model where the consulting team works alongside your staff rather than instead of them. Your people contribute to execution, not just oversight. Research consistently connects active involvement to better outcomes: projects with excellent change management are 7x more likely to meet their objectives compared to those with poor change management (88% success vs. 13%).⁽⁵⁾

The speed dynamic here is the inverse of DFY, and this is where many leaders make the wrong call. DWY is slower at the start. Co-delivery requires more coordination than handing the work to experts and waiting. But when DWY is done right, the organization comes out genuinely faster and more self-sufficient. Your team isn’t just familiar with the system. They understand why it was built the way it was, how to extend it, and how to fix it when something breaks. Slower up front, faster and cheaper forever after.

This is especially relevant for AI adoption initiatives. At least 30% of generative AI projects are expected to be abandoned after proof of concept by end of 2025, largely because organizations lack the internal capacity to carry them forward.⁽³⁾ The technology worked in the pilot. Nobody on the internal team had the depth to scale it. That’s a DFY problem wearing a DWY label.

The Capability Transfer Advantage

When consultants work with your team instead of around it, every sprint becomes a learning event. Your engineers see how decisions get made; your architects learn to think like the experts. When the engagement ends, that knowledge stays. Projects with excellent change management see up to 135% higher benefits realization than those with poor change management.⁽⁶⁾ DWY is, structurally, a change management practice built into the delivery model itself.

80% of senior leaders say upskilling is the most effective way to close employee skills gaps.⁽⁷⁾ DWY consulting is applied upskilling. The team learns by doing, on a real initiative, with expert guidance alongside them rather than in front of them at project close.

What DWY Done Right Looks Like Versus Done Wrong

Done right, DWY means knowledge transfer throughout the engagement, not a documentation handover at the end. Your team is involved in design decisions, not just brought in to review what consultants already decided. There’s shared ownership of choices made, so when something needs to change six months later, your people understand the reasoning and can act on it. Consultants are deliberately building your team’s confidence and capability at every stage, not just delivering the work.

Done wrong, DWY looks like this: internal team members shadow consultants in meetings but don’t genuinely contribute. Knowledge transfer is a PowerPoint deck attached to the final invoice. That version isn’t better than DFY. It’s slower and creates the same dependency, because the internal team observed without really learning.

The difference isn’t just process. It’s intent. Consultants genuinely committed to client capability structure the work differently from the start. The ones who aren’t will produce a collaborative-looking engagement that leaves the client just as reliant on outside help as a pure DFY project would have.

Why the Crawl, Walk, Run Framework Still Matters

The crawl, walk, run framework stages transformation into three phases of increasing autonomy: build foundations and validate assumptions (crawl), expand scope with guided execution (walk), then operate independently at scale (run). It’s a durable framework because it matches the pace of organizational learning to the pace of technical delivery. Trying to run before your team can walk is one of the most reliable ways to watch a transformation stall.

Most organizations underinvest in the crawl phase, and that’s precisely where done-with-you consulting delivers its highest value. The crawl phase is where data quality gets assessed, integration assumptions get stress-tested, and team readiness gaps surface before they become project-stopping problems. Rushing through it to show early progress is a false economy. Organizations that invest in a deliberate crawl phase tend to move faster in the walk and run phases because they’ve built on solid ground, not optimistic assumptions.

Mapping the Framework to Delivery Model

The crawl phase almost always benefits from DWY delivery. The work is exploratory and decisions are being made, not just executed. Co-creation between consultants and internal staff generates the most compound value here, because those decisions shape everything that follows. By the walk phase, many organizations are ready to carry a larger share of execution while consultants shift toward coaching and quality checks. The run phase, ideally, is fully internal. If the engagement was structured well, the consulting team has worked itself out of a job.

How Do You Know Which Delivery Model Fits Your Project?

The right model depends on three variables: internal capacity, strategic ownership, and timeline pressure. Only 26% of corporate transformations create enduring value,⁽⁸⁾ and the delivery model is one of the few factors leaders can actually control at the start. Getting this decision right early is far cheaper than inheriting a dependency you didn’t plan for.

Start with an honest capacity assessment. If key staff are already committed to other initiatives, DWY on top of existing workloads creates burnout risk rather than capability growth. In that scenario, DFY may be the pragmatic choice, with a structured knowledge transfer plan built into the statement of work from day one. Not bolted on at the end. Built in from the start.

Then consider strategic ownership. Is this a one-time implementation or an ongoing capability? A compliance-driven data migration might genuinely be a DFY project. A shift to AI-assisted operations is not. If you’re building something your team will need to evolve for the next five years, you need to own it from year one. The leaders who get this wrong are optimizing for the wrong phase. DFY moving fast looks better than DWY moving slowly for the first 90 days. That logic stops making sense when you’re still calling the vendor 18 months later for changes your team should own.

When Does a Blended DFY and DWY Approach Make Sense?

A blended model uses DFY where speed and specialist depth are the priority, and DWY where internal capability development is the goal. Most real-world engagements benefit from some version of this. The question isn’t which model to pick. It’s where each model applies within the same initiative, and whether the handoffs between them are planned or accidental.

A common blended pattern: architecture and infrastructure work is DFY, delivered by specialists at pace. Process redesign and user adoption work is DWY, because those outcomes depend entirely on whether your team understands and owns the change. In a cloud migration paired with an operational transformation, for instance, the technical migration might be pure DFY, but how your operations team troubleshoots, responds to the new environment, and scales needs to be co-delivered. Otherwise you’ve moved your infrastructure and left your team standing in the same place they started.

Structuring a Blended Engagement

Effective blended engagements define handoff points explicitly in the statement of work. Which workstreams are DFY, and why? Which are DWY, and what does “done with you” actually mean in practice for each one? Vague language about knowledge transfer produces vague results. For a broader view of how to structure these conversations, the IT consulting engagements overview covers the full range of delivery options and where each tends to apply.

What Does Sustainable Transformation Actually Require?

Sustainable transformation requires your organization to own the capability, not just the outcome. Most metrics organizations track during a consulting engagement measure delivery, not durability. Only 26% of corporate transformations create enduring value.⁽⁸⁾ The ones that do share something concrete: the internal team was part of building the thing, not just handed the keys when the project closed.

Ownership looks like your architects making design decisions, not just reviewing them. Your operations team contributing to runbooks, not inheriting them. Your leaders understanding the change management implications of each technical decision before the post-mortem. None of that happens automatically. It requires a delivery model structured to produce it and a consulting partner honest enough to insist on it even when it’s slower.

The organizations that succeed with AI and modernization aren’t the ones that chased speed in the wrong phase. They’re the ones honest enough to match their delivery model to their actual maturity, available bandwidth, and long-term ownership goals. That means resisting the pressure to go DFY when you actually need DWY, even if the timeline looks better on a slide. And it means resisting the performance of collaboration in DWY when what you’re delivering is a slower version of DFY with more meetings. IT staffing and workforce solutions can bridge specific skill gaps on the internal side, which in turn makes DWY delivery a realistic option rather than a stretch goal.

The honest conclusion: there’s no model that produces good outcomes on its own. DFY without a knowledge transfer plan creates dependency. DWY without genuine client involvement creates the same dependency, just more slowly and with more meetings. What actually works is matching the model to the situation, planning the knowledge transfer before the engagement starts, and holding both sides accountable to it throughout.

Frequently Asked Questions