Incomplete and Long-Running Cases
Cases crossing the window boundary distort every duration. The two handling options, and why filtering flatters the cycle time.
Procedure
Every log has cases that started before the window or have not finished. How they are handled changes the headline figure substantially.
The distortion
A case that started before the window appears to begin at whatever activity fell inside it, so its duration is understated.
A case not yet finished has no end, so it is either excluded or given an artificial one.
Both errors run in the same direction: they make the process look faster.
Which is why filtering to complete cases is the more dangerous option, despite being the default in most tools.
The two options
Filter to cases entirely within the window. Clean durations, biased sample. Long cases are systematically excluded, and long cases are the problem.
Include all cases and report incomplete ones separately, with their current age. Messier, honest, and it surfaces the backlog.
Report both figures and state which the headline uses. The gap between them is itself informative.
Sizing the bias
Count cases excluded by the filter, as a proportion.
Compare the duration distribution of included cases against the age distribution of excluded ones.
Where the excluded cases are systematically older, the filter is removing the tail, and the reported median is not the process median.
A high exclusion rate makes the headline figure close to meaningless, which is worth knowing before it is quoted.
Widening the window
The obvious fix and it has a limit.
Source system retention caps how far back you can go, and archived history is frequently purged.
A window shorter than the longest case duration cannot measure that case, which sounds obvious and is routinely violated.
Rule of thumb: the window should exceed the ninetieth percentile duration by a comfortable margin, and if it cannot, say so.
The open case backlog
Frequently the more useful finding.
Cases open beyond a defined age, counted and aged.
Grouped by where they are stuck, which is the last activity recorded.
Grouped by attribute, which usually identifies a predictable subset.
This is a live operational finding rather than a historical analysis, and it is the one an operation acts on fastest.
Alert on it, since a case stuck for ninety days is rarely stuck for a good reason.
Cases that never complete
Some processes have cases that legitimately stay open — a contract, an ongoing service, a chronic case.
These need a rule: excluded from duration analysis, counted separately as ongoing.
Distinguish them from abandoned cases, which look identical in the log and mean something entirely different.
A reason code or a status distinguishing "ongoing" from "stalled" is worth asking for, and it converts a large ambiguous population into two clear ones.
Deciding what to do with them
Every log contains cases that started before the window or have not finished, and the handling changes the numbers.
Exclude them from duration analysis, because their measured length is an artefact of the window.
Keep them for variant analysis, where a partial path is still real behaviour.
Report the proportion excluded, always.
Test the sensitivity: recompute the headline duration including and excluding them. A large difference means the window is too short for the process.
Widen the window rather than adjusting the cases, which is the only honest fix.