How to keep large projects on track with business capability mapping

Many organizations find themselves under growing commercial pressure to transition from legacy technology platforms in order to innovate. In the sports and entertainment sector, this pressure to transform is immense and typically extremely complex. The ability to quickly offer new, more engaging and personalized fan experiences has a direct impact on revenue and market share, so moving away from the inflexible technology structures of the past is essential.

However for many senior leaders, the true challenge isn’t the vision, it’s the execution. When platform modernization becomes a “black box” of technical delivery, the gap between boardroom strategy and engineering output begins to widen. Without a clear link between technical activity and business value, even the most ambitious programs risk becoming expensive, directionless exercises in service-building. 

That’s the challenge Thoughtworks uncovered at a leading sports tech company we worked with, where a large, multi-team platform modernization program was threatening to veer off course. 

In this article, we’ll look at the red flags that indicated the program’s underlying issues and show you, step by step, how Thoughtworks applied business capability mapping to get things back on track, restore strategic alignment and ensure the investment had the best chance of success.

Identifying the red flags

The platform modernization program had been running for around a year, and dozens of developers working in 10 or more teams had already built more than 30 services. However, when a new Thoughtworks team arrived to support the program, they quickly discovered a lack of alignment across the teams that could have a major impact on its success.

Through talking to the delivery teams and other stakeholders, we identified five red flags that had to be addressed to ensure successful implementation by the agreed go-live dates:

1. An architecture-first approach

Teams were building services to fit a pre-defined architecture without understanding the “why.” Often, there wasn’t a clear view of why the services were needed or the business value they were intended to deliver. 

This challenge was exacerbated by the fact that, over time, the domain boundaries had eroded. Work was being allocated based on teams’ perceived bandwidth rather than the relevance to their domain, creating further distance between the “why” (business value) and the “how” (technical delivery and architectural fit).

2. Duplicated effort

Conversations with the delivery teams also revealed that there were multiple workstreams building the same thing. For example, two teams thought they were building the user authentication and authorization tools, while another team outside of the program itself was also working on them. This had led to wasted time from duplicated effort, and the risk of implementing multiple competing versions of the same tools.

3. Fragmented capabilities

In some instances, business capabilities that a single team should have owned were split across multiple teams. This was another outcome of assigning work based on availability, not suitability.

This fragmentation meant that any change to a capability, such as adding a new feature, might require time-consuming collaboration across multiple teams, slowing development.

4. Missing capabilities

After speaking with senior stakeholders and teams working on the legacy platform, it became clear that there were important business capabilities that nobody on the modernization program was working on. 

The program’s aim wasn’t to offer feature parity, but the new platform needed to continue providing existing options for revenue generation. For example, granting external users access to tools was seen by leadership as a key way to quickly monetize the new platform. However, none of the delivery teams had considered this capability, so it wasn’t being worked on.

5. Confused terminology

The final red flag was that delivery teams had no shared terminology, or “ubiquitous language,” as it’s known in domain-driven design. Teams used different words to describe important terms that spanned the entire program.

For example, “client configuration,” “client customization” and “personalization” all referred to the same concept, but caused confusion in cross-domain communication. Fundamentally, many of the challenges we identified could be traced back to poor communication.

Getting back on track with business capability mapping

Business capabilities describe what an organization does, and a capability map provides a visual way to track the importance or maturity level of each capability or group of capabilities. Business capability maps are especially useful in migration projects, such as a platform modernization. Gathering the desired capabilities and target maturity levels upfront allows teams to make informed architectural and development decisions aligned to a shared understanding of value delivery.

When a large-scale migration project is already in flight, business capability mapping can still be highly valuable, providing a clear view of the red flags that could be putting the work at risk. So, a team of two Thoughtworkers — a technical lead and a business analyst — set about rapidly mapping the sports tech firm’s business capabilities to highlight the issues and facilitate conversations about how to fix them.

Here’s how they did it.

Step 1: Independent research

The capability mapping team began by reading Confluence pages, Architectural Decision Records, user guides, architecture diagrams and more to establish an initial list of the business capabilities each team was building. 

Step 2: Validation sessions with the teams

One-hour sessions with each team ensured the list of capabilities collated from the research was a true reflection of what was happening in the real world.

Step 3: Visualizing the capabilities

Next, the capability mapping team created a highly visual Miro board to illustrate the capabilities and highlight the problems to be solved.

At this stage, the team took a “Goldilocks” approach, mapping capabilities that weren’t so high-level as to be meaningless, but weren’t so low-level that people would get bogged down in the detail. With over 40 capabilities, grouping them into meaningful categories also made the map easier to navigate.

When multiple teams used different terms for the same thing, the mapping team chose the term most likely to resonate with the most teams. They then populated the capability map with supporting information, so that anyone looking at it could understand what each capability meant — even if their team previously used a different term for it. Example features for each capability on the map provided additional clarity.

Step 4: Using the business capability map 

The next step was to introduce the business capability map, gathering representatives from all the teams in a two-hour online workshop.

In the first part of the workshop, the mapping team introduced the map and answered questions to ensure everyone understood its purpose. In the second half, each team was asked to label each capability that they thought they were solely responsible for, a core contributor to, or a key enabler of. And this is where the true value of the business capability map became apparent — because everyone in the workshop could instantly see the red flags.

In some cases, multiple teams had placed their markers on top of one another, because they all thought they were responsible for the same capability, indicating duplicated effort. One team thought they were responsible for almost everything, as a result of being given work based on perceived bandwidth. It was also easy to see the missing capabilities, where none of the teams thought they were contributing in any way. 

Step 5: Facilitating important conversations

After the workshop, the capability mapping team arranged for the delivery teams to talk to one another to find solutions to the issues they’d visualized.

Where multiple teams thought they were doing the same thing, they established which team would take ownership, or, if the capability needed to remain split, the reasons for doing so. Where a capability had no team aligned, the mapping team spoke with senior stakeholders to clarify its importance and ensure an appropriate team was assigned to own it.

Step 6: Maintaining the business capability map

Importantly, the delivery teams were also empowered to update the map based on the outcomes of their conversation, and to continue updating and evolving it as the platform modernization progressed.

Get set for success

This approach has enabled the company to turn its ambitious modernization strategy into successful execution across all the delivery teams. For leadership, a business capability map is far more than a technical diagram; it is a strategic compass. In the sports and entertainment sector, where the "cost of delay" is measured in lost fans and missed revenue, it provides the clarity needed to turn a stalled modernization into a competitive advantage.

By shifting the focus from architectural components to business capabilities, the organisation achieved three critical outcomes:

• Accelerated decision making: Leadership vision was no longer lost in translation between product managers and engineering teams. With a shared map, stakeholders could make rapid, informed trade-offs based on business value rather than technical guesswork.

• Alignment: It ensured that what was envisioned at the board level had a practical, executable path within the delivery teams. This closed the gap between "ambitious strategy" and "successful execution."

• Efficient investments: By identifying duplicated efforts and "missing" revenue-generating features early, the program stopped burning budget on low-value work. Teams shifted their energy toward the capabilities that actually move the needle for the business.

Turning strategy into execution

Ultimately, capability mapping de-risks the most complex part of any digital transformation: the human element. It replaces fragmented terminology and siloed working with a unified operating language. In a market that demands constant innovation, the ability to move faster in the right direction isn't just a benefit, it's a prerequisite for survival.