100% pilot adoption. Standardized processes across six continents. Zero dependency on outside consultants after I left. That's the short version of what happened when I helped one of the Big Four consulting firms move 120,000 distributed consultants toward agile ways of working, powered by Atlassian's Jira.
The longer version involves a lot of spreadsheets, difficult conversations about organizational change, and the realization that rolling out a tool is the easy part. Getting people to actually use it the way it was intended? That's where the real work lives.
Why a 120,000-Person Consulting Firm Needed Agile Transformation
This was 2014-2015. I was consulting with Adaptavist, one of Atlassian's top partners at the time. The client was a Big Four firm with 120,000 consultants spread across offices globally. Their existing project management approach relied heavily on document-centric workflows: Word documents passed around via email, versioned by filename ("Project_Plan_v7_FINAL_FINAL2.docx"), tracked in SharePoint libraries that nobody could find.
The problems were predictable but severe. Document versioning conflicts wasted hours every week. Program managers couldn't get a real-time view of project status without chasing people down. Consultants in different time zones were working from different versions of the truth. And as the firm grew, these friction points weren't scaling linearly. They were compounding.
Leadership wanted to modernize. They'd identified Jira and the broader Atlassian stack as the platform. But they'd also tried tool rollouts before and watched them fail. The problem was never the technology. It was adoption.
That's where I came in.
Building an Atlassian Implementation Strategy for a Global Enterprise
My first instinct was to resist the urge to boil the ocean. With 120,000 users spread across dozens of practice areas and hundreds of offices, a "big bang" rollout would have been organizational suicide. Instead, I worked with the client's leadership to design a phased adoption strategy that treated the rollout as an organizational change initiative, not just a technical deployment.
We started by establishing program management frameworks inside Jira that mapped to how the firm actually worked. This meant spending weeks understanding existing workflows before touching any configuration. I sat in on project standups, reviewed how teams tracked deliverables, and documented the informal processes people used to get things done. Because here's the thing about large organizations: the formal process and the actual process are rarely the same thing. If you build your tool around the formal process, nobody uses it.
The Jira configuration I designed reflected the reality on the ground. Custom workflows mirrored existing approval chains. Dashboards gave program managers the real-time visibility they'd been begging for. And reporting structures aligned with how the firm measured success, not how Atlassian's defaults assumed you'd measure it.
Discovering Four Siloed Work Streams and Taking PMO-Level Leadership
What I actually found when I got into the details was worse than expected. The firm had already identified groups of teams and organized them into four different work streams, each with a dedicated project manager. They had attempted to adopt the Scaled Agile Framework (SAFe) and were going to build custom tooling on top of Jira and Confluence. They had all these teams, they were going to do release trains – but nobody was actually coordinating anything.
The four project managers across the four different work streams weren't even talking to each other, even though they were at the same company working toward the same goals. It took me a while to find that out. The discovery work – all the talking and listening in the previous phase – is what got me there.
I came in at the level of the project management office to take leadership across all four work streams. Once I was able to get all four working in tandem and going in the same direction, I established a role for the ultimate decider – the person with whom the buck stops. Initially that was me, and then I got a staff member to take on that role permanently. That single change – having one person who could make cross-cutting decisions and hold all four streams accountable to each other – made a huge difference in building momentum and driving the transformation forward.
Standardizing Global Processes Without Crushing Local Autonomy
Here's where a lot of enterprise agile transformations go wrong. They standardize everything to the point where teams in Mumbai are forced into the exact same workflow as teams in Manhattan, regardless of the fact that they work differently, serve different clients, and face different constraints.
I took a different approach. We established a core framework: mandatory elements that every team had to use so that enterprise-level reporting and governance worked. Things like standardized issue types, consistent status categories, and shared custom fields for financial tracking. But within that framework, individual teams had flexibility to customize their boards, add team-specific fields, and adapt workflows to their context.
This balance between global consistency and local autonomy was critical. It meant the firm could generate portfolio-level dashboards showing status across all practice areas while still letting individual teams work in ways that made sense for their specific engagements.
Organizational Change Management Alongside Technical Implementation
The technical implementation was maybe 30% of the work. The other 70% was change management.
I developed training programs tailored to different roles. Project managers got deep-dive sessions on Jira workflows and dashboard creation. Team members got streamlined onboarding focused on the three or four things they'd actually do every day. Executives got high-level walkthroughs of the reporting capabilities so they could pull the insights they needed without needing to understand the underlying configuration.
But training alone doesn't drive adoption. People revert to what's comfortable unless you address the underlying reasons they resist change. For some teams, the resistance was about control: they'd built elaborate personal tracking systems in Excel and didn't want to give them up. For others, it was about visibility: working in Jira meant their progress (or lack of it) was suddenly transparent.
I addressed both head-on. For the control issue, I showed teams how Jira's filtering and personal dashboards could replicate everything their spreadsheets did, with less manual effort. For the visibility concern, I worked with leadership to frame transparency as a support mechanism rather than a surveillance tool. When teams fell behind, the response was "what do you need?" not "why aren't you done?"
Building Sustainable Internal Capability Instead of Consultant Dependency
This is something I feel strongly about. A lot of consultants structure their engagements to create dependency. If the client always needs you to configure things, run trainings, and solve problems, you've guaranteed yourself a long-term revenue stream. But you haven't actually helped the client.
From day one, I was training internal champions. Every pilot team had at least two people who received advanced Jira administration training. I documented everything: configuration decisions, workflow rationale, training materials, troubleshooting guides. By the end of the engagement, the client's internal team could handle new team onboarding, configuration changes, and ongoing optimization without calling Adaptavist.
Did this mean less future revenue for Adaptavist? Probably. Was it the right thing for the client? Absolutely. And frankly, it's better for long-term business too. Clients who feel well-served come back when they have new challenges, and they refer you to others.
Enterprise Agile Transformation Results and Long-Term Impact
The numbers tell part of the story:
- 100% adoption across all pilot teams, leading to accelerated enterprise rollout
- Standardized project management processes across offices on six continents
- Significant reduction in document versioning issues as teams moved to Jira and Confluence as the single source of truth
- Sustainable internal capability with trained champions able to manage the platform independently
But the numbers don't capture everything. The bigger shift was cultural. Teams started talking about work differently. They moved from "I'll send you the updated document" to "check the board." Status meetings got shorter or disappeared entirely because the information was already visible. And program managers, for the first time, could see across their entire portfolio without waiting for someone to compile a report.
We also retained them as a long-term client. They came to us whenever they needed help in the future, which signaled to me that they were happy with our work and that we'd done a good job for them.
The transformation wasn't perfect. Some teams adopted faster than others. A few edge cases required workflow compromises that weren't ideal. And the firm's appetite for change management investment didn't always match the pace of the technical rollout. These are normal tensions in any large-scale transformation, and pretending they don't exist doesn't help anyone.
What mattered was that the trajectory was right. The firm moved from fragmented, document-centric project management to a unified, transparent, agile-influenced approach that scaled across 120,000 people. And they did it in a way that stuck after I walked out the door.
FAQ: Enterprise Agile Transformation
How long does an enterprise agile transformation take for a company with 100,000+ employees?
It's a year or two for a company of that size. Our role was about a year – intensively for around eight months, then part-time for the remainder. After that, they took it on internally for another year. At that point, we'd already equipped them, built up their champions, enterprise architects, and deciders, and got everything sorted so they could stand on their own and take it over the finish line. They were very happy with that handoff.
Can Jira scale to support 120,000 users across a global enterprise?
Yes, but the tool is the easy part. Jira's architecture supports large-scale deployments, and Atlassian's Data Center (now Cloud Enterprise) products are built for this. The harder challenge is designing workflows and governance structures that work across diverse teams without becoming so rigid they're unusable. The configuration decisions you make early on determine whether the platform scales gracefully or becomes a mess.
What's the biggest risk in a large-scale agile transformation?
Treating it as a tool rollout instead of an organizational change initiative. I've seen companies spend millions on Atlassian licenses and configuration, then wonder why nobody uses the system. The tool is the enabler, not the transformation. You need to invest equally in training, change management, and cultural alignment, or you'll end up with an expensive piece of shelfware.
Related Case Studies
- Rescuing a Stalled 80-Person Product Team at Stride – Another large-scale organizational transformation, this time rebuilding process and purpose for a product team that had lost its way.
- Machine Translation at CoinDesk: Automating Multilingual News for Global Growth – A different kind of scale challenge: expanding a digital product across languages and markets.