Your Strategy Is in a PDF. Your Execution Is in 5 Tools. Who Connects Them?

Here is a situation that will sound familiar. Your strategy was finalised in a slide deck. It might also exist as a Confluence page, a Notion document, or a PDF that was emailed to the leadership team in January. It describes what the organisation intends to achieve over the next twelve months.

Now, where is the execution?

Team A uses Jira. Team B uses Azure DevOps because they were acquired eighteen months ago and migration is “on the roadmap.” The infrastructure team tracks work in GitHub Issues. Product uses Linear. And there is a shared spreadsheet somewhere that the PMO maintains for cross-team dependencies.

Between the strategy document and these five execution tools, there is a gap. Not a small gap , a structural void where alignment should be measured but is not. The strategy says what should happen. The tools record what is happening. Nobody is systematically comparing the two.

Why Tool Consolidation Is Not the Answer

The obvious response is to standardise on a single tool. Pick Jira, migrate everyone, enforce compliance. Problem solved.

Except it is not. Tool consolidation projects are expensive, disruptive, and slow. They typically take 12-18 months for a mid-size organisation, during which productivity drops and teams resist the change. Even when completed, the result is a single tool that does many things adequately rather than any one thing well.

More fundamentally, tool consolidation addresses the wrong problem. The problem is not that you have five tools. The problem is that nobody is reading across them to answer strategic questions. Consolidating into one tool reduces the integration challenge but does not create alignment measurement. You just end up with all your unanalysed data in one place instead of five.

The teams chose their tools for good reasons. Engineers prefer tools that match their workflow. Forcing everyone onto a single platform creates friction and resentment without addressing the underlying visibility problem.

The better approach is to leave teams with their preferred tools and build a read-only observation layer that spans all of them.

Read-Only Connectors: Observation Without Intervention

The first principle of cross-tool alignment measurement is non-interference. You are observing execution, not controlling it. This means read-only access to every tool in the chain.

Read-only connectors offer several practical advantages:

No workflow disruption. Teams continue working exactly as they do today. No new fields to fill in. No new processes to follow. No “please update the alignment tag on your tickets” messages. The observation layer is invisible to the people doing the work.

Rapid deployment. Read-only API access can be established in hours, not months. Most modern project management tools have well-documented APIs with read scopes that require minimal security review. You can start collecting data within a week, not after a year-long integration project.

Low political resistance. Asking a team to “let us read your Jira data” is a fundamentally different request from “please migrate to our preferred tool.” The former is an observation. The latter is a mandate. Organisations that struggle with tool standardisation often find cross-tool observation straightforward.

Security simplicity. Read-only access cannot modify, delete, or corrupt data. The risk profile is minimal, which simplifies procurement and security approval.

The result is a data collection layer that spans every tool in the organisation without touching any of them. Strategy remains in its document. Execution remains in its tools. The observation layer sits alongside both, watching the gap.

The Data Normalisation Challenge

Collecting data from five tools gives you data from five tools. It does not give you a unified picture. For that, you need normalisation , the process of translating different data models into a common representation.

This is where the real work lives. Consider how differently a single concept , “a unit of work” , is represented across tools:

• Jira: An issue with a type (story, bug, task), status, assignee, sprint, epic, story points, and custom fields
• Azure DevOps: A work item with a type, state, iteration path, area path, effort, and custom fields with different names
• GitHub Issues: An issue with labels, milestone, assignee, and free-text body
• Linear: An issue with status, priority, project, cycle, and estimate
• Spreadsheet: A row with whatever columns the PMO decided on

Each tool has its own vocabulary, its own status model, its own hierarchy, and its own metadata. “In progress” in Jira might be “Active” in Azure DevOps and “Started” in Linear. A “story” in Jira might be a “product backlog item” in Azure DevOps and simply an “issue” in GitHub.

Normalisation maps these different representations into a common model that allows cross-tool analysis. This is not a trivial exercise, but it is a well-understood one. The key decisions are:

Status mapping. Define a canonical set of statuses (not started, in progress, in review, done, blocked) and map each tool’s statuses to these categories. This allows you to ask “how many work items are currently blocked?” across all tools.

Hierarchy mapping. Map each tool’s hierarchy (epic > story > subtask, or initiative > feature > work item) to a common structure that connects to strategic objectives. This is where the link between strategy and execution is established.

Effort normalisation. Story points, hours, t-shirt sizes, and “no estimate” must be translated into a comparable measure. This is inherently imprecise, but even rough normalisation is more useful than no normalisation.

Temporal alignment. Different tools update at different frequencies and use different timestamp conventions. Normalisation must account for this to avoid comparing stale data from one tool with fresh data from another.

The normalisation layer does not eliminate the differences between tools. It creates a translation layer that allows meaningful comparison despite those differences.

What Unified Alignment Looks Like

With read-only connectors collecting data and a normalisation layer translating it, you can finally answer the question that started this article: who connects the strategy document to the execution tools?

Unified alignment means being able to see, at any moment:

Strategic coverage. Which strategic objectives have active execution work across any tool? Which objectives exist only in the strategy document with no corresponding operational activity? This immediately reveals the gap between aspiration and action.

Cross-team contribution. How are different teams contributing to each strategic objective, regardless of which tools they use? Team A’s Jira stories and Team B’s Azure DevOps work items can be assessed together against the same objective.

Actual effort distribution. Where is organisational effort actually going, across all tools? This prevents the common problem where each team’s data looks fine in isolation but the aggregate picture reveals misalignment.

Temporal trends. How is alignment changing over time? Are certain objectives gaining or losing execution momentum? Is drift occurring in specific areas?

This is not a single dashboard that replaces everything else. It is an analytical layer that sits above your existing tools and answers questions that no individual tool can answer alone.

The Connection Problem Is the Strategy Problem

The gap between your strategy PDF and your five execution tools is not an integration inconvenience. It is the central challenge of strategy execution.

Every organisation that has a strategy and uses tools to execute it has this gap. The question is whether you bridge it with systematic measurement or fill it with assumptions, status meetings, and narrative reporting.

Tool consolidation does not solve it. More meetings do not solve it. Hiring another programme manager does not solve it. What solves it is a layer that reads across all your tools, normalises the data, and compares it with your strategic intent , continuously, automatically, and honestly.

Your strategy document and your execution tools are not going to connect themselves. Something has to bridge that gap. The question is whether that something is a systematic measurement capability or the optimistic belief that everyone is probably doing the right thing.

---

BAS TrustDesk connects to your existing execution tools with read-only access and measures alignment against your strategic objectives. No tool migration required. See how it works with your stack.