Skip to main content

Why Strategy Fails in Execution: Finding Where Progress Breaks Down

An unmet strategic goal needs a diagnosis of the decisions, delivery, and assumptions behind it.

Why Strategy Fails in Execution: Finding Where Progress Breaks Down

When a strategic initiative falls behind, the first explanation often determines the response. Calling it a discipline problem leads to closer tracking. Calling it resistance leads to more communication. Calling it a resource problem leads to a request for more people. Each response can be appropriate, but only if it addresses the difficulty actually preventing progress.

An unmet goal does not establish its own cause. The organisation may have left important choices unresolved, assigned work without enough capacity, delivered an unreliable service, or correctly implemented an idea that customers do not value. Several of these problems can occur together.

Understanding execution therefore requires following the intended change into the work and then into use. The purpose is to identify where the expected connection has broken down and what decision could repair it. This gives leadership and delivery teams a more useful starting point than debating whether the strategy or the people deserve the blame.

Define the Result Before Diagnosing the Delay

Consider a maintenance business introducing an online booking service. Leadership expects customers to find an available appointment, confirm the visit, and receive fewer follow-up calls. The business hopes this will reduce administrative work and make booking more convenient.

After launch, online bookings remain low and office staff still spend much of their time arranging visits. It would be premature to conclude that employees resisted the change or that customers prefer telephone service. The service may not show appointments accurately, may exclude common job types, or may be difficult to find. Staff might also have received little preparation for using it.

The investigation should begin with the intended result and the commitments made. Was the first release meant to handle every job type or a limited group? Did the business expect customers to switch immediately, or was this a trial? Were administrative savings included in the approved plan before there was evidence about likely adoption?

These questions establish what success meant at the relevant stage. A limited trial should be assessed against what it was intended to establish. A full service launch needs a broader examination of reliability, coverage, support, and customer use. Comparing either one with an undefined ambition makes it difficult to distinguish an incomplete promise from a disappointing result.

A useful account links the customer problem, the proposed change, and the expected benefit. For this business, the assumption is that access to suitable appointments will allow customers to complete bookings themselves, reducing certain types of staff handling. Each connection can then be examined. If customers can complete bookings but staff must re-enter them elsewhere, the expected reduction in work has a separate dependency.

Follow a Real Case Through the Process

A project plan shows what the organisation intended to build. Following actual bookings shows how the service behaves. Select cases that include an ordinary booking, a request needing clarification, a change of appointment, and a cancellation. Include unsuccessful attempts where the available evidence permits it.

The review might reveal that the online calendar offers a time before the office has confirmed the appropriate technician. Customers receive an apparent confirmation, then a phone call arranging something different. The digital interface works as implemented, but it does not represent a confirmed booking in the operational process.

That finding changes the response. More promotion could bring additional customers into the same problem. Asking office staff to encourage online booking would leave them explaining promises the service cannot reliably meet. The business needs to decide how appointment availability is established and at what point it can make a commitment to the customer.

Looking at real work also helps test claims about resistance. An employee who avoids the new service may have identified a genuine reliability issue. Another may need training, accessible guidance, or support during a busy period. A third may continue an established practice after the relevant problems have been resolved. These situations warrant different responses and should not be collapsed into a single cultural explanation.

The investigation should remain proportionate. A bounded change may need a few well-chosen cases and a discussion with the people doing the work. A widespread service problem may require broader analysis. The aim is enough evidence to identify and test the next decision, rather than a comprehensive process map that delays an obvious correction.

Check Capacity and Authority Together

A delivery team can understand the problem and still lack the conditions needed to address it. Correcting appointment availability may require changes to scheduling rules, access to operational data, and time from experienced staff. Assigning the booking project to a digital team does not automatically provide any of those things.

Examine the relevant commitments together. Office staff may already be covering vacancies and arranging daily schedules. The scheduling supplier may have its own lead times. The person who can approve a new booking rule may also be responsible for service reliability across the business. These are constraints to plan around, rather than evidence that the participants do not support the strategy.

The sponsor should resolve the choices those conditions create. The business might narrow the online service to predictable jobs, fund additional preparation, change the release sequence, or revise the expected benefit. Execution requires these trade-offs to reach the actual allocation of time and responsibility.

Authority needs the same examination. If Operations owns technician scheduling but the project manager owns the delivery date, neither should silently change the other’s commitment. They need an agreed decision route for changes that affect both. A named project owner is useful only when that person knows what they can decide and how unresolved issues will be settled.

This does not require removing independent review or making every decision locally. Some changes affect contracts, safety, access, or other obligations and need appropriate scrutiny. The practical requirement is a workable route through that scrutiny, with the necessary information and a clear decision owner.

Verify That the Change Can Be Used and Supported

Completing the planned features establishes one kind of progress. It does not establish that the service works adequately under ordinary conditions. The maintenance business needs to examine whether appointment information remains accurate, changes reach the right people, and failures can be detected and corrected.

Acceptance should include examples drawn from the operational requirements. What happens when two customers select the same remaining appointment? Can a customer amend a booking after the office has assigned a technician? Who handles a confirmation that fails to arrive? These questions connect the implementation to the promise the business is making.

Delivery quality is part of the diagnosis. Unreliable integrations, incomplete testing, confusing interactions, or poor preparation can directly undermine the result. Organisational constraints may explain some of those failures, but the explanation should lead to corrective action rather than make the defects irrelevant.

Staff also need a workable transition. They should know which requests belong in the new service, how to handle exceptions, and where to report a problem. The plan should account for the period when old and new processes coexist. Assuming immediate adoption can remove capacity just when people need additional time to learn and resolve early issues.

Operational ownership should be explicit before the project team moves on. Someone needs to maintain scheduling rules, monitor failed bookings, and decide when a problem requires a service change. A successful demonstration leaves these responsibilities largely untested; evidence from routine use provides a stronger basis for accepting the service.

Separate Implementation From the Business Assumption

Suppose the booking service becomes reliable and customers who use it can complete their requests. Administrative work still falls less than expected. The business now needs to investigate the reasoning behind the forecast rather than continue treating every shortfall as a delivery defect.

Customers may need advice before selecting a job type. The online channel may attract additional demand instead of replacing calls. Staff may spend less time entering bookings but more time clarifying incomplete requests. These possibilities change the value of the service without necessarily showing that the implementation failed.

HM Treasury’s Magenta Book distinguishes questions about implementation from questions about impact. Although written for government evaluation, that distinction is useful here: establishing whether the service was introduced as intended is different from establishing whether it produced the expected benefit.

Comparison needs care. A decline in office workload after launch might also reflect seasonal demand or a change in staffing. A stable workload might conceal increased demand that the service helped absorb. A simple before-and-after figure can inform investigation, but it may not isolate the effect of online booking.

The business should use an evaluation approach proportionate to the decision. A limited trial can combine service records, customer feedback, staff observations, and a suitable comparison where feasible. Where causal evidence remains weak, the conclusion should say so. A decision to continue can still be reasonable when the uncertainty and the next evidence required are explicit.

Match the Response to the Finding

The investigation should finish with a decision someone can carry out. If appointment data is unreliable, assign the correction and establish how it will be verified. If the service covers too few useful cases, decide whether to expand it. If customers need advice first, test a booking journey that provides that help. If the expected savings are no longer credible, revise the business case and the commitments that depend on it.

Some responses sit within the delivery team’s authority. Others require leadership to change scope, resources, or the strategic assumption itself. A review needs to distinguish these levels so that teams are neither waiting unnecessarily nor being asked to resolve choices beyond their remit.

Record what the decision is expected to change and when the result can reasonably be assessed. This creates a feedback loop between evidence and action, rather than another reporting cycle in which the same issue remains visible but unresolved.

Execution can expose weaknesses in a strategy, and sound strategy can be undermined by poor delivery. Treating either explanation as the default limits what the organisation can learn. Following the commitment through real work, operational use, and business results makes it possible to identify the difference and direct effort where it can improve the outcome.