Imagine a manufacturing plant dealing with unexpected equipment downtime.
The interruptions disrupt production schedules, cause delays, and force teams to reorganize activities during their shifts.
After analyzing the incidents, management identifies an opportunity: strengthen preventive inspections before shifts begin.
The proposal seems reasonable.
If certain anomalies are detected early, potential interventions can be assessed before those anomalies cause more serious interruptions.
The decision is communicated to managers. A procedure is developed, responsibilities are assigned, and an implementation date is set.
A few days later, records show that inspections are not taking place as expected.
Managers demand greater commitment.
Supervisors complain about a lack of time.
Operators explain that they need to get the equipment running to meet the production schedule.
Maintenance explains that identifying an anomaly does not mean having immediate capacity to correct it.
And the storeroom reports that certain components are unavailable.
What seemed like a relatively simple improvement has turned into a disagreement between departments.
But is the problem really people's resistance?
Or did the organization decide what should happen without sufficiently understanding the conditions needed to make it happen?
1. A good decision does not guarantee good implementation
Making a decision and successfully carrying it out are different challenges.
An organization may correctly identify an opportunity, select a technically sound alternative, and set legitimate objectives.
None of that guarantees that change will happen as envisioned.
Between a decision and a result lies an operation that is already running, with people, responsibilities, constraints, commitments, and dependencies.
There is also a history of routines developed to deal with situations that do not always appear in formal procedures.
When an initiative ignores these conditions, its implementation may produce effects different from those intended.
In the preventive inspection example, the idea of identifying anomalies early still makes sense.
But its feasibility depends on questions the original decision may not have considered.
Who will perform the inspections?
At what point?
How much time will they require?
What will not get done during that time?
What will happen when an anomaly is found?
Who will have the authority to stop a machine?
How will maintenance absorb new demands?
A technically sound decision must still demonstrate that it can be executed under the organization's real conditions.
These are not secondary questions. They are part of designing the change itself.
2. Operations are not a blank slate
Many initiatives are conceived as though the organization had resources sitting idle, waiting for new instructions.
In practice, operations already have commitments.
People work scheduled hours, equipment has operating limits, materials must be available, and processes follow sequences and dependencies.
A new activity does not appear in an empty space.
It starts competing for time, attention, capacity, and resources with everything already taking place.
Consider the start of a shift again.
If the team needs to carry out an additional inspection, it is necessary to understand how that activity relates to equipment preparation, information handovers between shifts, mandatory safety checks, and the start of production.
Simply adding an obligation to a procedure does not ensure there is capacity to fulfill it.
Sometimes the answer lies in reorganizing tasks.
In other situations, responsibilities must change, resources must be made available, or productivity expectations must be revisited.
And there are cases in which the decision needs to be scaled back because the necessary conditions are not yet in place.
Requiring a new activity without considering available capacity can turn an intended improvement into another source of overload.
The point is not to assume that every team is overloaded.
It is to verify whether there is actual capacity to incorporate the change.
3. Work does not stop at departmental boundaries
Organizations distribute responsibilities across departments to enable specialization, coordination, and control.
Yet results rarely depend on a single department.
In the manufacturing example, production may perform an inspection correctly and identify an anomaly.
But the expected outcome also depends on maintenance's ability to respond, material availability, safety conditions, and decisions about scheduling.
If every department does only its isolated task, the problem may remain.
Imagine this situation:
Production identifies a worn component.
Maintenance receives the request but already has higher-priority interventions.
The storeroom reports that the part needs to be purchased.
Planning maintains the original production target.
Every department may be acting in accordance with its responsibilities.
Even so, the organization may remain exposed to unplanned downtime.
This reveals an important distinction between completing tasks and producing results.
The inspection was performed.
The record was created.
The request was opened.
But the condition that was identified still needs to be addressed.
A completed activity does not necessarily mean that the associated problem has been resolved.
That is why implementing change requires understanding not only who performs each task but also how decisions and information move across departments.
4. More controls do not necessarily mean better control
When implementation proves difficult, a common response is to increase monitoring mechanisms.
New spreadsheets.
More forms.
Additional meetings.
Execution reports.
Compliance indicators.
These tools may be necessary.
The problem arises when they are created without considering existing records, the effort required to maintain them, and whether the information produced is actually used.
Imagine an operator already logging incidents in a maintenance system.
If the new routine requires a parallel spreadsheet with essentially the same data, work will be duplicated.
If the records disagree, someone will have to reconcile them.
And if no one uses the information to make decisions, the control becomes an administrative obligation with no clear contribution to results.
Before creating a new tool, a few questions are essential:
Does the information already exist somewhere else?
Who really needs to receive it?
Which decision will this record support?
How frequently does it need to be updated?
Does the expected benefit justify the effort needed to maintain it?
The value of a control is not in the amount of information recorded, but in its ability to support decisions and make work more reliable.
A control that does not influence decisions may simply represent more work.
5. The people doing the work know constraints that planners may not see
Initiatives are often designed by professionals who understand their technical rationale but do not experience every condition of execution on a daily basis.
That does not invalidate the planning work.
It means that knowledge needs to be complemented.
An operator may know variations in equipment behavior that never appear in reports.
A supervisor may identify conflicts between the schedule and the actual availability of people.
Maintenance may point out dependencies between interventions.
The storeroom may demonstrate supply risks.
Each perspective adds elements to the understanding of operations.
Involving teams, therefore, is not simply presenting a decision and asking for agreement.
It is allowing relevant conditions to become known before demanding results.
Nor does it mean that every objection should prevent change.
A reported difficulty needs to be understood, checked against reality, and assessed in light of the initiative's objectives.
There is a difference between a real constraint, a preference for an existing routine, and a hypothesis that has not yet been examined.
Leadership's role is to distinguish these situations without disregarding the experience of the people doing the work.
6. Starting smaller can be the more responsible decision
An initiative does not need to begin across the entire organization.
In some situations, limiting an initial rollout makes it possible to understand difficulties, test assumptions, and make adjustments with less exposure.
In our manufacturing example, the organization could begin by inspecting a specific group of machines, provided that the scope is technically appropriate and does not compromise safety requirements.
The choice would need to consider criticality, incident history, resource availability, and monitoring conditions.
Before beginning, it would be important to define what the organization intends to learn.
Does the inspection fit into the shift routine?
Do those responsible understand the procedure?
Are identified anomalies handled as required?
Does information reach the people who need to decide?
Are there unexpected consequences for other activities?
The initial goal would not be to prove quickly that the proposal was right.
It would be to verify how it behaves in reality.
A limited rollout is not intended to deliver an early victory. It is intended to generate learning before expanding commitments and risks.
That does not eliminate the need for planning.
On the contrary, it requires clarity about the objective, monitoring criteria, and conditions for expanding or revising the initiative.
7. Completing activities and improving results are not the same thing
Suppose that, after a few weeks, the organization reports that most of the scheduled inspections were completed.
This may indicate adoption of the new routine.
But is it enough to conclude that operations improved?
Not necessarily.
The purpose of the inspections was to help reduce unexpected downtime and its consequences.
It would therefore be necessary to examine what happened to identified anomalies, response capability, equipment availability, and actual interruptions.
Other effects would also need to be checked.
Has the start of shifts become delayed?
Has maintenance accumulated requests?
Has the quality of records improved?
Have teams begun identifying significant problems, or are they merely completing forms?
These questions help distinguish implementation indicators from outcome indicators.
The number of inspections completed tells us that a particular activity took place.
But that figure alone does not demonstrate that downtime was reduced because of it.
Evaluating outcomes requires considering historical baselines, comparable conditions, operational variation, and possible external factors.
Doing what was planned is one important piece of information. Demonstrating that it produced the expected result is another matter.
Confusing the two can lead an organization to declare success before understanding the actual effects.
8. The cost of implementation also needs to be considered
Every change uses resources.
Even without significant purchases, it may require working hours, training, meetings, system adaptations, monitoring, and the reorganization of activities.
These efforts need to be weighed against the expected benefits.
If a new routine consumes significant time without reducing losses, risks, or rework, its cost-benefit relationship needs to be examined.
That does not mean considering only immediate financial savings.
A measure may be necessary to improve safety, reliability, quality, or compliance, even if its benefits do not directly appear as lower expenses.
What matters is making explicit which benefits are expected and which resources will be needed to sustain them.
The cost of inaction must also be considered.
An organization may save money in the short term by postponing necessary interventions while remaining exposed to greater losses from operational failures.
Decision-making requires understanding those relationships, not merely counting the initial effort.
9. Execution connects dimensions that cannot be assessed in isolation
When an initiative runs into difficulties, the explanation may seem simple:
“People did not adopt it.”
“The process does not work.”
“Resources are missing.”
“The cost is too high.”
Yet these situations are often interconnected.
People need to understand their responsibilities and have the conditions required to carry them out.
Processes need to establish clear sequences, interfaces, and criteria.
Products and services depend on the reliability of those activities to meet customer needs.
And profitability is influenced by resource utilization, operating costs, and delivered results.
These dimensions affect one another.
A change that improves a departmental indicator but increases rework in another area may not represent a gain for the organization.
Likewise, shortening an activity at the expense of quality failures can compromise the final result.
The challenge is not to optimize every part in isolation.
It is to understand how the change affects the system as a whole.
That relationship needs to guide both planning and implementation monitoring.
10. Adjusting implementation is not an admission of failure
There is a recurring expectation that well-planned decisions should be executed exactly as originally conceived.
But implementation may reveal constraints that were not sufficiently visible.
It may show that a responsibility needs to be reassigned.
That a particular deadline is incompatible with available capacity.
That the system needs an adaptation.
Or that a seemingly simple step depends on unforeseen conditions.
These discoveries do not automatically mean that the original decision was wrong.
Nor do they justify concluding that it was right.
They provide information for reassessing the proposal.
A mature organization needs to distinguish what should be preserved from what needs to change.
If the objective remains relevant but the execution approach presents difficulties, implementation may need to be adjusted.
If new evidence indicates that the expected benefits are not feasible, the decision itself may need to be reconsidered.
The important thing is not to turn the original plan into something that must be defended regardless of the results observed.
Commitment to an objective does not require unconditional loyalty to the first path chosen.
The ability to revisit decisions is also part of leadership responsibility.
11. What must leaders understand before demanding results?
Let us return to the plant that decided to strengthen preventive inspections.
It would be easy to end the analysis by stating that the solution is to raise operator awareness or demand greater discipline in following the procedure.
But that answer would be insufficient.
Before attributing the difficulty to people's behavior, leaders would need to understand whether the activity was properly incorporated into the routine.
Whether sufficient time and resources are available.
Whether responsibilities are clear.
Whether information flows between departments.
Whether identified anomalies receive treatment.
Whether the records produced support decisions.
And whether observed outcomes match the benefits that motivated the change.
This does not eliminate individual responsibility for following procedures.
It simply recognizes that responsibility and execution conditions need to be examined together.
Leadership does not mean choosing between demanding results and understanding difficulties.
It means establishing criteria to do both consistently.
An organization that demands results without investigating working conditions may increase pressure without increasing its capability.
And an organization that identifies obstacles but never turns that understanding into decisions may also fail to advance.
The balance lies in connecting objectives, execution, evidence, and accountability.
12. Decisions come first. Transformation happens in real work.
Decisions are necessary.
Organizations need to establish priorities, select alternatives, and make commitments.
But the quality of a decision cannot be assessed solely by the coherence of the arguments supporting it.
It also matters how that decision will be put into practice.
An initiative may seem technically sound yet reveal significant difficulties during execution.
It may produce improvements in one area and undesirable effects in another.
It may require additional changes to achieve the expected result.
That is why implementation is not simply about issuing an instruction and checking whether people followed it.
It is about connecting intent to the organization's real operations.
It is about understanding dependencies, making conditions available, monitoring consequences, and taking responsibility for necessary adjustments.
The remaining question is not just whether the decision made sense when it was taken.
It is whether the organization created sufficient conditions for it to work.
In your organization, when a good idea fails to move off the drawing board, is the first reaction to demand greater commitment—or to investigate what is preventing its execution?