The gap between strategy and execution is an enduring problem in business. What’s more, this disconnect is often a cause of significant waste —  of time, money and employee energy. And while we can try to overcome these challenges through workshops or process reviews and audits, such attempts often compound the issue. At its worst it can damage organizational culture. 

So, how can we correct this? In this blog post we’ll explore how organizations can better connect strategy to implementation and ensure those discussions and initiatives actually deliver lasting value.

Identifying the causes of strategic disconnection

Before we explore what can be done we first need to look at the causes of the  disconnect between strategy and execution. Based on our experience with many different kinds of clients, these are always upstream of specific initiatives or workshops. So, getting to grips with these root causes gives teams and organizations a far better chance of ensuring that any strategy conversations and work has a tangible and sustainable impact.

We see there being four key symptoms of disconnection, all of which have discrete but equally important causes. Let’s take a look at them now:

  • Strategy and execution teams ‘don’t get each other’ — it feels like they are pulling in different directions because there’s no common standardized language and because of incoherence between levels of hierarchy, regions and functions.

  • Strategy is defined with little to no connection to the downstream process — sometimes a strategy document is viewed as a goal in itself, not as a step towards that goal.

  • Improvement metrics aren’t connected to strategic organizational goals — Product team metrics are sometimes retrofitted to the business objectives or focus on the product instead of the customer.

  • Shared functions (like finance or technology) wield outsized influence over strategic decisions — while this is sometimes helpful in the short-term, it means decisions are made without accounting for organizational needs in a more holistic manner.

None of these issues are easy to solve. They all require the effort of the majority of the people in the organization to build a view of the organization. 

Let’s dive deeper into how that can be done.

Defining and clarifying your business architecture

It’s vital to consolidate and clarify the multiple terms flying around in the organization to describe different things. This includes just about everything: capabilities, capacity, goals, aims, objectives, processes, activities, tasks, strategy, business direction.

In our experience, not only have we noticed just how many different terms organizations are trying to handle, we’ve also noticed it’s common for many to be used interchangeably. So, instead of our business architecture — the elements that make up an organization from how it works to how it talks about itself — being a source of stability, it instead increases confusion.

We recommend a simple set of principles to define terms not just to describe the architecture, but also to guide the language of the actual capabilities and processes:

  1. Don’t reinvent the wheel. Start with industry standards. Carefully evaluate what's already available as an industry standard and use it as a default to begin with before deciding to start from scratch. The International Standards Organization (ISO) has already done a lot of work in consolidating the language around this space, as part of ISO:19440. 

  2. Use plain language everyone can understand. Even if ISO has done a lot of the groundwork, there is a lot that can be done based on those standards to make the language simpler, and clearer. For example, ISO defines a capability “Business Implementation Management” which we typically recommend our clients to just call “Strategy Management”.

  3. Involve your people from the start with clear rationale: If you are already dreading the messy debates that could happen from this exercise, you’re not far off the mark. These are difficult conversations that take a lot of patience and time to get through. However, any siloed system will need exactly these types of conversations to happen if any progress is to be made. Encourage these debates and channel them toward designing a base model.

Three basic concepts

We’ll need to define three basic ideas to get started.

  • Service domain: a logical grouping of related business scenarios and capabilities within a company with a clear set of goals. 

  • Business scenario: What each service domain needs to execute to achieve its goals.

  • Business capabilities: What’s required for a service domain to execute on a business scenario. These are technologies (cloud storage; a billing system) or particular skills (architecture; accounting).

If we are to have productive conversations across the organisation, we will need everyone to first be aligned on these three terms. They form the basis of the business architecture required to align strategy and execution.

TIP: Create a clear, short document which can be circulated and outlines examples from your business to act as a reference and provide clarity. Make it easily accessible by sharing in your organisation’s knowledge management tool or system. 

This process of definition and related mapping should provide us with visibility on just what business capabilities are used by which parts of the business. More importantly, we also now will have standard language that will eliminate misunderstandings and redundant work by multiple teams working across the organization.

How does this drive the business?

Creating a holistic view of the business is valuable because it helps us to visualize the connections between high level business goals to implementation — which could be a process, a skill, or even an API. 

Once we have certain artifacts in place — like, say, an OKR document, Lean Value Tree, architectural diagrams or standard operating procedures set of Standard Operating Procedures, Technology Architecture, a People plan and a Business Capability Map, there are further connections we need to draw.

This should be done like this:

  1. Create a list of all business capabilities tagged to the lines of business that depend on them.

  2. Map all the processes that depend on each capability.

  3. Consolidate similar processes across regions, business units and functional units.

To demonstrate, this is how it might look in practice. Imagine an example of a mortgage loan processing.