Why Operational Actions Remain Open After Everyone Thinks They Are Closed

Every operation runs on action lists - meeting actions, audit actions, defect follow-ups, class recommendations, procurement actions, repair items, HSE actions, management-review actions. Each gets an owner and a due date, the work moves forward, evidence comes back, and eventually the line turns green. Most of the time, that is exactly what should happen.

The trouble starts when "closed" comes to mean that somebody completed the activity written against the action, rather than that the operational condition behind it has actually been resolved. An action can be closed in the tracker while the thing that created it is still sitting in the operation. The gap is the distance between "work done" and "problem gone".

Take an ordinary technical example. A pump starts leaking. The vessel reports it, the superintendent raises a repair action, and the decision is made to replace the seal at the next opportunity. The spare arrives, the job is done, photographs are sent, the Chief Engineer confirms completion, and the action is closed. Nothing obviously wrong with that - until two weeks later the leak comes back.

The first question is usually whether the repair was done properly. Sometimes it was. Maybe the seal was replaced exactly as instructed, but the shaft condition was never checked. Maybe an earlier temporary repair had masked another problem. Maybe vibration had been mentioned weeks before, sitting in a different report. Maybe the pump was tested, but not under the condition where the fault actually shows. The action was completed. The problem was not.

"Done" is only one state

Most action systems really have three states: open, overdue, closed. Real operations have more. An action may be assigned but not started. The work may be physically done but not reported. Evidence may be submitted but not reviewed. The immediate work may be finished while a dependency is still outstanding. The original condition may be corrected but still needs checking under normal operation. Those are all different positions, and a three-state system collapses them into one.

I have sat in enough close-out meetings where an action was called closed because somebody produced an email, a photograph, a service report or a purchase order. Those can all be perfectly valid evidence. They prove that something happened. They do not always prove the problem is gone.

Evidence proves only what it proves

This sounds obvious, and it still gets blurred the moment a file is attached to an action. A purchase order proves the part was ordered, not that it arrived. A delivery note proves it arrived somewhere, not that it reached the vessel. A photograph shows the equipment was opened and repaired, not that the repair held under load. A training attendance sheet proves people attended, not that the process which created the original problem now works differently. A survey booking confirms the survey was arranged, not that it was completed or the certificate endorsed.

The mistake is rarely bad evidence. It is asking the evidence to prove more than it does. Once the file is attached, everyone sees something tangible, the action looks finished, and another red line disappears from the tracker. That is useful administratively. Operationally, there may still be work behind it.

Dependencies are where actions quietly stay open

Take a repair that needs a spare. The technical action says: replace the defective actuator. Procurement orders it. The vessel has a temporary arrangement in place, and the replacement is planned for the next port call. Then procurement closes its action because the PO was issued, and somebody closes the technical follow-up because the temporary arrangement is holding. The vessel keeps operating. Each record now looks reasonable - while the original condition is exactly where it was.

The permanent repair still depends on the spare arriving, the vessel reaching a suitable place, someone being available to do the work, the repair being tested, and perhaps class accepting the final condition. Until those come together, the real action has not disappeared. It has only moved between departments. This is where action lists mislead: they show ownership well, and dependency badly.

Temporary measures have a habit of becoming permanent

Operations need temporary measures - equipment fails, spares take time, access is limited, weather interferes, and the vessel still has to operate. The problem is not using a temporary control. It is forgetting that it was temporary.

A bypass is installed. An extra watch is set. An inspection frequency is raised. Class accepts a condition for a limited period. Management agrees to keep operating until the permanent repair can be made. For a few weeks everyone remembers why. Three months on, the arrangement has become part of normal work, the person who agreed it may have moved on, and the action shows closed because the control was put in place. What gets lost is the second half of the decision - what was supposed to happen afterwards. If the temporary control is the end of the visible action, nothing in the system is pushing the operation back towards its intended condition.

Go back to why the action existed

This is the simplest way to look at closure. If the original condition was an unreliable pump, is the pump now reliable? If the action came from repeated late certificate renewals, is the renewal process working before the dates become urgent? If an audit action came from procedures not reaching vessels, did the distribution process change, or did somebody just send the missing procedure this once? If a defect required a permanent repair, is that repair complete, or is the temporary arrangement simply still holding?

The wording of the action often distracts from this. "Provide evidence." "Conduct training." "Raise purchase request." "Update procedure." All may be necessary. None of them describes the operational result you were actually trying to reach. That result sits one level behind the task.

Some results can only be judged later

There is a practical complication: some results cannot be verified on the day the work is done. A repaired item may need running time. A revised process may need a cycle or two of real operation. A corrective action may need months before anyone can say the same weakness has not returned. A new control may work perfectly while everyone is watching it, then quietly fade once the normal workload returns.

That does not mean keeping every action open forever. It means the system should be able to tell "the work is complete" apart from "the result has been checked". Sometimes that is one action with a later verification step; sometimes the main action closes and a linked effectiveness check stays open. The method matters less than making sure the second part does not vanish because the first part is finished. Otherwise the organisation becomes very good at recording implementation and much weaker at seeing whether implementation changed anything.

One action rarely sits on its own

An operational action usually crosses several records before it is genuinely finished. A defect creates a repair action; the repair needs a spare; the spare creates a purchase request; a temporary control is agreed to keep the vessel running; class may become involved; the permanent work goes into the docking scope; the docking work is done; the defect is finally closed. Six or more records along that chain, each owned by someone different. If they stay connected, management can see the original defect is still live until the chain reaches its end. If they do not, every department closes its own part correctly and management still loses the overall condition. Nothing has to go missing for that to happen.

A closure check worth the minute

Before calling an important operational action closed, a few plain questions do most of the work. What exactly was supposed to change? Was the work actually completed, and what proves it? Were there dependencies behind it? Are any temporary controls still in place? Has the original condition been restored? If the result could only be judged later, was that check actually done? And if the same problem returns in six months, will anyone be able to see what was done this time and whether it worked?

Not every action needs this. A straightforward administrative task should stay straightforward. But the more an action touches safety, reliability, compliance or continued operation, the less a simple green tick tells you - and the more the organisation needs to know what the tick actually means.

An action should not disappear because the assigned activity was completed. It should disappear when the organisation can see that whatever needed to happen next is finished, properly handed on, or still visibly under control. That is the difference between closing the line and closing the problem.