Written by Teresa Tso

After I shared my first article on how my perspective on consulting has changed (and why I’m excited to do things differently in my new role at Jarvis), I got a lot of responses. Based on the reactions, comments, and messages I got as a response, I could picture many people nodded enthusiastically. Then came the inevitable question: “But how?” 

Fair question. Vision without execution is just an expensive conversation. 

After 17+ years watching the consulting-client gap from both sides, I've learned that the "how" actually matters more than the "what." You can promise sustainable transformation all day long, but if your delivery model is built on the same foundations as traditional consulting, you'll get the same results: impressive go-lives followed by slow unwind to old ways of working. 

At Jarvis, we've built something different. Not incrementally different - structurally different. And I'm going to walk you through exactly how we approach delivery in ways that address the Day 2 challenges I lived through on the client side. 

The Problem with Traditional Consulting Delivery Models 

Before I explain what we do differently, let me be clear about what we're solving for. 

Traditional consulting fails at Day 2 because of three structural problems: 

1. The revolving door problem. Consultants rotate in and out. By the time you hit go-live, the people who understood your original requirements are gone. The people supporting handover never lived through the design decisions. Context evaporates. 

2. The context gap. Internal teams inherit documentation and deliverables, but not always the reasoning behind design decisions or how to adapt them. That missing context becomes a bottleneck to sustainable ownership. 

3. The capacity problem. Consulting teams operate in a bubble with dedicated resources and clear priorities. Your internal teams are juggling seventeen other initiatives. When the consultants leave, their capacity leaves with them, but the work doesn't. 

I’ve lived this firsthand. 

A few years ago, I was leading a new HR services solutions implementation supported by a consulting vendor. We ran multiple workshops to define requirements, and very quickly realized we would need to modify our internal processes to align with platform standards. That shift required real operational decisions and real capacity. 

But my operations teams were already stretched. We couldn’t make decisions quickly enough to match the vendor’s estimated timelines. Their workplan assumed dedicated focus, while ours reflected operational reality. 

So we made trade-offs: reduced scope and prioritized what we could realistically absorb. 

The vendor delivered what fit within the revised boundaries and go-live happened with a compressed knowledge transfer. 

And on Day 2, my team inherited the system. 

We quickly realized that the documentation was incomplete. The reasoning behind certain configurations wasn’t clear. We found ourselves digging into code to reverse-engineer the logic, trying to understand why decisions had been made so we could support and evolve the solution. 

The implementation wasn’t “bad.” 

It was incomplete in a way that only becomes visible after consultants leave. 

That experience changed how I think about delivery. 

Why Our Workforce Structure Actually Matters 

Here's something I never fully appreciated until I sat on the client side: where your consulting team is based fundamentally shapes how they work with you. 

Jarvis operates with a 100% Canadian workforce. This isn't a marketing point. It’s a structural choice that affects how delivery actually unfolds. 

When we’re working on a transformation in Toronto, our team is operating in the same time zone. When a production issue surfaces, escalation doesn’t depend on who is just starting their workday elsewhere. When executives want to meet the team building the solution, they’re meeting the people who will still be there at go-live. 

But the real impact isn’t speed. It’s continuity and operating rhythm.  

On the client side, I’ve worked with vendors structured across multiple global regions. The quality of the people wasn’t the issue. The complexity was. Time zones, national holidays, and rotating availability had to be managed alongside the actual project. For large enhancements or operational stabilization work, we often had to plan around geography as much as we planned around scope. 

I found the process far more seamless when working with teams within the same geography, especially during post go-live support. When you’re stabilizing a system, responding to operational issues, or making iterative enhancements, friction compounds quickly. Delays in alignment or missed context create gaps. 

There’s also something underestimated about proximity. The ability to combine in-person sessions with virtual collaboration reduces communication drift. It tightens feedback loops. It makes it easier to resolve ambiguity before it becomes rework. 

Solving the Capacity Problem 

Let me address the elephant in the room that most consulting firms ignore: when we leave, you lose capacity. 

Traditional consulting says: "We'll train your team." But training doesn't create capacity. Your team still has their existing job responsibilities. Now they also have to absorb, operate, and continuously improve everything we just delivered. 

I’ve seen this reality first-hand. Every transformation project added to our operational load without adding people to carry it. We became experts at managing initiatives in theory while struggling to sustain them in practice. 

This is why Jarvis built a transition model focused on helping clients scale internal capacity. 

Here's how it works: As we approach go-live, if you need ongoing capacity to support what we've built, our consultants can transition to become part of your team. Not as external contractors billing through us indefinitely, but as your employees if that's what makes sense, or as dedicated resources embedded with your team under a staff augmentation model if you need more flexibility. 

The key difference is continuity of people, not just continuity of knowledge. 

When the person who designed your data integration strategy becomes part of your internal team, they bring something documentation can never capture: the accumulated context of why decisions were made, what alternatives were considered, what technical debt exists, and where future optimization opportunities are. 

This isn't meant for every project. Sometimes you genuinely want to develop internal capability and you have the capacity to absorb it. But when you're implementing something new, something complex, or something that will require dedicated focus beyond your current team's capacity, having the option to retain the people who built it changes everything.