An organization may approve a goal to improve customer experience while its teams keep working in exactly the same way. Stating the goal does not create the change. People need to know what will change in service delivery, decisions and daily resources. This article explains how to connect strategy to operations, choose workable initiatives and check whether project completion produces the intended result.
Begin with the strategic choice and intended result
Strategy sets the direction and choices guiding an organization: whom it serves, what value it offers and where it concentrates resources. A strategic objective describes a result it wants to achieve. “Improve customer service” needs clarification. Does it mean faster responses, resolving problems first time or serving a new customer group?
Resolve conflicting priorities before assigning tasks. If you want more personalized service, lower cost and faster delivery, define each expectation and the acceptable trade-offs. Do not leave teams to discover the conflict during implementation. NIST’s Baldrige guidance emphasizes a limited set of priorities connected to actions, resources and monitoring that allows adaptation.
Identify the capability before choosing the project
A business capability is something the organization must be able to do to carry out its choice. Meeting a service deadline requires clear request intake, reliable workload estimates and appropriate task allocation. The gap might be in skills, data or authority rather than the absence of a new technology system.
Compare the required capability with current practice. Does the organization know request volumes and due dates? Can employees access the information they need? Who decides when resources are insufficient? Record the gap and its evidence, then choose the response. Buying a platform before answering these questions may move uncertainty onto a new screen instead of resolving it.
Design the operating arrangements and decision authority
An operating model explains how roles, processes, information, technology and partners work together to deliver value. It is broader than an organization chart. The structure may stay unchanged while request intake, approval authority or handoffs between units change. Not every objective needs a complete redesign; the size of the change depends on the gap.
Assign a process owner to oversee the result from beginning to end, with clear authority and an escalation route for matters beyond it. Accountability for delay is insufficient if the owner cannot resolve conflicts between departments. Specify what each team receives, its acceptance conditions and what it passes to the next stage. This helps prevent one unit improving at the expense of the whole service.
Translate the change into usable daily work
Map the current service journey and identify what must change to achieve the intended result. Translate those changes into responsibilities, procedures, tools and information needed by practitioners. If approval authority changes, update the procedure, system and training together. Announcing the decision alone does not prevent employees from following the old route.
Distinguish recurring operational work from a temporary initiative. Handling customer requests is an ongoing process; redesigning their intake is an initiative with a beginning and an end. Plan the handover into operations: who provides support after launch, updates instructions and reviews results? Technical delivery alone does not establish that employees can use the change effectively.
Hypothetical example: from a service promise to an execution plan
Suppose an organization delivers a standardized service and wants to increase requests completed within 2 working days from 70% to 90% within 6 months. Measurement starts when a complete request is received under published conditions. These are illustrative assumptions, not client results or suitable targets for every organization. Monitor the time spent completing missing information too, so part of the customer’s wait is not hidden.
The team traces delayed cases and finds some waiting for manual allocation while others are returned for missing information. It proposes testing a clearer intake form and daily request allocation, with an authorized backup when the responsible person is absent. Each change has an owner, deadline and test scope. Automation can wait until the new rules work and the investment is justified.
For 200 requests in a measurement cohort with complete follow-up, 70% means 140 completed on time. At the same volume, the 90% target requires 180 on-time completions: 40 additional requests meeting the deadline. This is a difference in timeliness, not necessarily an increase in total requests completed. The response might involve reducing waiting rather than adding working hours.
If volume rises to 300 requests, the same target requires 270 on-time completions. Review demand and capacity assumptions alongside the percentage. Define how requests whose service deadlines have not yet elapsed are tracked, and do not mix them with confirmed overdue cases. These details make the objective measurable and useful for decisions.
Balance the initiative portfolio with existing work
An initiative portfolio brings together the change activities an organization chooses to implement and manage. An approved budget does not make every initiative feasible at the same time. Several projects may need the same analyst or operational team. Examine available hours, skills and dependencies, and identify what must finish before other work can start.
In a simple hypothetical example, suppose change capacity is 100 hours per month and two initiatives require 70 and 60 hours. Demand is 130 hours, leaving a 30-hour gap. Approving both schedules does not remove it. Options include resequencing, reducing scope or providing authorized additional capacity. Allocating change resources must not silently undermine existing service commitments.
Measure the benefit, not just project closure
An output is what the initiative delivers, such as a new intake form. An outcome is a change in performance or behaviour, such as fewer returned requests. A benefit is the intended value, such as more reliable service for customers. PMI’s benefits realization framework focuses on identifying, delivering and sustaining benefits after the work moves into operations.
Connect the Key Performance Indicator (KPI) to the objective and establish its formula, source, measurement frequency and owner. In the example, the number of trained employees does not prove the 90% target was achieved. Track on-time completion alongside solution quality, rework and complaints. Early indicators, such as the proportion of requests with complete information, can help, but their relationship to the result still needs testing.
Use reviews to make a clear decision: continue, adjust or stop. Examine assumptions, results and risks instead of simply reading through a task list. If a benefit appears, assign responsibility for sustaining it after project closure. If it does not, distinguish an implementation problem from a strategic assumption that needs reconsideration.
Does every department need a copy of the same target?
No. Each needs a clear contribution to the shared result. Technology may own system availability, operations may own work allocation and human resources may support practitioner competence. Repeating one percentage across every departmental plan can hide these different responsibilities. Combine contribution measures with the overall outcome measure and identify who resolves conflicts.
Start with one decision you can trace into practice
Choose an important objective and identify what must change in one process to achieve it. Record the gap, change, owner, resources and measurement method, then test implementation within an appropriate scope. Make the result reviewable and adapt the plan using evidence. Strategy becomes operational when participants understand their decisions and responsibilities, and management knows whether the impact that justified the change has been achieved.
